Where LLMs Actually Help in Quant Workflows
The honest answer is narrower than the hype — LLMs are strong at reading text at volume and weak at anything that requires actually knowing what a price will do.
Prerequisites: Large Language Models
There's a simple test for whether an LLM belongs in a given step of a quant workflow: could a diligent, fast-reading intern do this job correctly given the same document? If yes, an LLM is often a strong fit. If the job actually requires knowing what will happen to a price — something no amount of reading tells you, because it isn't in the text — an LLM is the wrong tool no matter how fluent its answer sounds.
The reliable uses are all reading-and-writing tasks at volume. The unreliable uses are all "just tell me what will happen" tasks. Confusing the two is the single most common mistake in applying LLMs to trading.
Where they earn their keep
Turning unstructured documents into structured data — pulling a guidance number out of a transcript, tagging risk factors in a filing — is the strongest fit, because the answer is checkable against the source text. See Structured Extraction From Filings With LLMs. Summarizing and triaging high volumes of text — flagging which of a thousand overnight news items are worth a human's attention — plays to the same strength: the model doesn't need to be right about markets, only about what a document says. Drafting a first pass of a research note, a client summary, or documentation, with a human editing before it goes anywhere, saves real time without asking the model to make a judgment call that matters.
Where they don't
Predicting returns directly from a prompt — "will this stock go up" — asks the model to produce a number it has no grounding to produce; it will still answer, fluently and with unwarranted confidence, because refusing to answer isn't something a next-token predictor naturally does. Backtesting anything involving an LLM's judgment on historical text risks contamination — the model may already "know," from training data, how a historical event resolved, and that hindsight leaks into what looks like foresight. Any task requiring the model to have genuinely current information — today's price, this morning's data release — fails unless the model is explicitly given that information in the prompt, because its training data has a cutoff and it will guess rather than admit ignorance.
A simple example
A research team wants to know whether a company's tone on a quarterly call changed versus the prior quarter. An LLM comparing two transcripts and describing the shift in emphasis — more hedging language around supply chain, say — is a reading task it's well suited to, and a human can verify the claim by checking the quoted passages. The same team asking the model whether that tone shift means the stock will beat consensus next quarter is asking it to forecast, which the model will do anyway, confidently, with no real basis for the answer.
An LLM never says "I don't know how markets will react to this" unless specifically prompted to consider that possibility — by default it produces a plausible-sounding answer to whatever's asked, forecasting included. Treat fluency as evidence of nothing.
A useful middle category
Between "clearly reliable" and "clearly unreliable" sits a set of tasks worth naming, because teams keep reaching for LLMs here and getting burned in a specific way: anything where the model has to make a judgment call that looks like reading but is actually forecasting in disguise. Classifying a news headline as "bullish" or "bearish" seems like a reading task, but deciding whether a given fact is good or bad for a stock requires knowing how the market will interpret it, which depends on prior expectations the article itself doesn't state. A model can do this reasonably well on obvious cases — a guidance cut is bad news — and unreliably on the genuinely interesting cases, where the same fact could be read either way depending on context the model doesn't have. Treat this middle category as forecasting with extra steps, not as reading, and validate it the same way you would validate a signal: against realized outcomes, not against how plausible the reasoning sounds.
A rule of thumb for new use cases
Before wiring an LLM into any new step of a workflow, write down what a wrong answer costs and how a wrong answer would be noticed. A wrong entity match in a news pipeline is cheap to notice — the story clearly isn't about the company it got attached to — and cheap to fix. A wrong read on whether a filing understates risk is expensive to notice, because there's no obvious tell that the model missed something, and by the time it matters the decision built on it is already made. Reserve LLM involvement, without a human check, for the cases where being wrong is both rare and visible; add a review step everywhere else.
Further reading
- Kim et al., Financial Statement Analysis with Large Language Models (2024)