Why RAG Alone Fails for Equity Research
Retrieval-augmented generation reads filings like prose. Equity research lives in tables, footnotes and vintages, where one wrong digit is a wrong answer.
Retrieval-augmented generation is a genuinely useful pattern, and it is also the wrong tool to point at a balance sheet and trust blindly. RAG retrieves relevant text and lets a language model write a fluent answer, which is exactly why it fails at equity research: it optimises for plausible prose, while research demands the correct digit, from the correct period, traceable back to the correct filing.
This is not a knock on the technique. It is a statement about the gap between “sounds right” and “is right” in a domain where those two are frequently not the same document, let alone the same sentence.
What RAG actually does
Strip away the acronym and RAG is three steps. First, retrieve: given a question, find the passages in your corpus that look most relevant, usually by matching the meaning of the question against pre-computed chunks of text. Second, augment: paste those passages into the model’s context window. Third, generate: ask the language model to answer using what it was handed.
For a lot of tasks this is excellent. Ask “what did management say about capacity expansion” and RAG will pull the relevant paragraphs from a transcript and summarise them well. The pattern shines when the answer is qualitative, lives in one place, and tolerates paraphrase.
Equity research is mostly the opposite. The answer is quantitative, lives in several places at once, and tolerates no paraphrase at all.
Numbers do not live in prose
Open any annual report or quarterly result and look at where the important figures actually sit. They are in tables. Revenue, EBITDA, finance costs, deferred tax, segment splits, related-party transactions: rows and columns, with headers three lines up and units declared once at the top of the statement.
Chunking, the step that slices documents into retrievable pieces, is built for flowing text. Point it at a table and it mangles the structure. A chunk boundary can fall between a number and the row label that gives it meaning. The unit (“Rs in crore” versus “Rs in lakh”) can end up in a different chunk from the value it governs. A footnote that says “excluding exceptional items” can be retrieved without the line it qualifies, or the line can be retrieved without the footnote.
A language model handed a naked number will confidently attach it to whatever the question asked about. It has no way to know the value belonged to a different segment, a different subsidiary, or a different unit.
The footnotes are where this gets dangerous, because footnotes are where the caveats live. Contingent liabilities, changes in accounting policy, the composition of “other income”, the treatment of a one-off gain: these are exactly the details a serious analyst reads first and exactly the details naive chunking is most likely to sever from the numbers they modify.
Time and vintage are part of the answer
“What was the company’s profit?” is not a well-formed question until you fix the period and the version. Which quarter. Full year or trailing twelve months. Standalone or consolidated. And critically, as originally filed, or as later restated.
Indian issuers restate and reclassify. A figure reported in the March quarter can be revised when the audited annual numbers land, or reclassified when a segment definition changes, or adjusted for a demerger or a scheme of arrangement. Prior-period comparatives get re-cast. The “same” line item can carry two different values depending on which filing you are standing in.
Retrieval has no native concept of this. It ranks chunks by similarity to your question, and both the original and the restated figure look similarly relevant. Ask a plain RAG system for a number and you may get whichever version happened to rank higher, with no signal about which vintage it is. For anything that matters, point-in-time discipline (what was knowable, and in what form, on a given date) is not a nicety. It is the difference between an audit trail and a guess.
Precision is unforgiving
Most machine-learning tasks are graded on a curve. A summary that captures 90 percent of the meaning is a good summary. A recommendation engine that is right most of the time is a useful engine.
Financial figures are graded pass or fail. Rs 1,240 crore and Rs 12,400 crore are not “close”. A margin of 14 percent and 41 percent are not a rounding disagreement. One transposed digit, one misread unit, one line item confused for its neighbour, and the answer is simply wrong, no matter how fluent the paragraph around it reads.
This is the uncomfortable truth about language models and numbers: fluency and accuracy are decoupled. The model will produce a grammatical, confident, well-structured answer whether the figure inside it is right or not. There is no wobble in the prose to warn you. In research, that smoothness is a liability, because it hides the error instead of flagging it.
Real questions span many documents
Here is the deeper problem, the one that no amount of better chunking fixes on its own. The questions that actually matter in research are almost never answerable from a single retrieved passage.
Consider what an analyst genuinely wants to know:
| The question | What it actually requires |
|---|---|
| How has the gross margin trended over five years? | The same margin, defined the same way, reconciled across five annual reports |
| Did receivables grow faster than revenue? | Two line items, matched period by period, growth computed, not quoted |
| Is “other income” masking a weak operating quarter? | The segment split plus the footnote defining the bucket, read together |
| How does leverage compare to the sector? | The same ratio computed identically across several companies’ filings |
Every one of these is a reconciliation task. It needs figures pulled from different documents and different periods, checked for consistent definitions, and then combined arithmetically. Retrieval fetches passages; it does not line them up, does not verify that “revenue” means the same thing in both, and does not do the subtraction. Hand those passages to a language model and hope it does the arithmetic in its head, and you have re-introduced every precision problem above, now compounded across sources.
Transcripts say the plausible thing, not the true number
There is a subtler failure specific to earnings calls and management commentary. This is the most quotable, most retrievable text in the entire corpus, and it is also the most hedged.
Management speaks in ranges and intentions: “we expect margins to remain healthy”, “demand has been reasonably resilient”, “we are comfortable with our debt levels”. When you ask a retrieval system a quantitative question, this language often ranks highly, because it is phrased in the vocabulary of your question. So the system surfaces confident, on-topic, human-sounding sentences, and a language model happily treats them as the answer.
But the healthy margin in the transcript is not the margin in the statements. The comfortable debt level is a sentiment, not the finance cost line. Retrieval rewards text that sounds like an answer. Research needs the figure that is the answer, which is sitting in a table the transcript never quotes.
What serious financial AI has to add
None of this means language models have no place in research. It means retrieval is the floor, not the building. To be trustworthy on filings, a system has to add structure on top of retrieval, in a few general directions that follow directly from the failures above.
- Structure over chunks. Financial statements are parsed as what they are (line items, periods, units, and the footnotes that qualify them) rather than sliced as prose. A number is only useful when it stays welded to its label, its period and its unit.
- Point-in-time grounding. Every figure carries when it was knowable and in what form, so as-filed and restated versions are distinct, dated records, not interchangeable text.
- Verification against the source. A generated number is checked back against the underlying statement before it is shown, so fluency never stands in for correctness.
- Linking every number to the filing. Each figure traces to the specific document, statement and line it came from, so a human can click through and confirm rather than trust the paragraph.
This is the principle Altys is built on for Indian equities: point-in-time, source-linked data, so that the language model is reasoning over verified structure rather than improvising over retrieved snippets. The model is still the model. What changes is what it is allowed to stand on.
Altys Labs is not a SEBI-registered Research Analyst or Investment Adviser. Nothing here is a recommendation, a target or a prediction, and companies are referenced only as neutral illustrations.
The practical takeaway
If you are evaluating an AI tool for equity research, do not ask whether it uses RAG. Almost everything does, and that tells you very little. Ask the questions that separate plausible from correct:
- When it gives you a number, can it show you the exact line in the exact filing it came from?
- Does it distinguish as-filed figures from restated ones, and tell you which you are looking at?
- Can it hold units, periods and footnotes together, or does it read tables as loose text?
- When a question spans five reports, does it reconcile the figures, or just quote the nearest-sounding passage?
A tool that cannot answer these is doing retrieval and calling it research. In a domain where one wrong digit is a wrong answer, that gap is the whole job.
Frequently asked questions
What is RAG in simple terms?
Retrieval-augmented generation retrieves chunks of relevant text from a document set and feeds them to a language model, which then writes an answer grounded in that text instead of from memory alone.
Why does naive RAG struggle with financial statements?
Financial statements are tables and footnotes, not prose. Chunking splits rows from their headers and periods, so the model retrieves plausible-looking numbers that are attached to the wrong line item, quarter or unit.
Can RAG answer questions that span multiple filings?
Not on its own. Real research questions require reconciling figures across several documents and periods. Plain retrieval surfaces passages one at a time and has no mechanism to line up matching definitions or restatements.