AnswersAgents & RAG

Why Does RAG Fail on Financial Tables?

Why do RAG pipelines that handle prose well return wrong numbers from 10-Ks, earnings decks, and fund reports, and what fixes retrieval at the level of a table cell?

3 min readJuly 2026

The short answer

RAG fails on financial tables because single-vector retrieval compresses a whole page into one summary embedding. A table is hundreds of independent facts, and a summary keeps the topic ("a quarterly income statement") while averaging away which row said what. The query that needed one cell lands on the right document and the wrong number.

Token-level retrieval fixes the failure at its source: with one embedding per token, the query's "net interest margin" and "Q3 2024" match the exact row and column that answer it, instead of dissolving into an average of every row on the page.

Why are tables the worst case for embeddings?

A financial table is not one fact; it is hundreds of independent facts packed into rows that look almost identical. The meaning of any cell lives at the intersection of its row label, its column header, and its value, and a single ~1,000-dimensional summary vector has nowhere to keep those intersections. This is a capacity limit, not a model-quality problem: a 2025 result proves that fixed-size single vectors cannot represent all the combinations of content that may be jointly relevant to a query.

Prose degrades gracefully under this compression, because a paragraph usually makes one point and the summary keeps it. A table degrades catastrophically, because the summary keeps "this page is financial results" and drops the 400 numbers that made it useful.

The same filing page, indexed two ways.

Page-level embedding

10-K page with a table

One summary vector

topic survives, cells average away

Query matches the page

Right document, wrong number

Token-level embedding

10-K page with a table

One embedding per token

Query matches the row and column

The cell stays findable

Why does finance feel this hardest?

Financial documents are table-dense, and the answers people need are numbers. Your analyst asks for Q3 2024 net interest margin, the pipeline retrieves the right 10-Q, and the model gets a page whose summary vector matched the topic. It answers fluently with a figure from the wrong column, and a plausible wrong number in finance is worse than no answer at all.

Agent workloads compound the problem, because agents fire many precise probes like "FY2024 provision for credit losses" where each probe has exactly one right cell.

What does the evidence show?

The gap is measurable in both forms, retrieval quality and end-to-end answers.

At the retrieval level, TopK evaluated its compact late-interaction model against Qwen3-VL-Embedding-8B, a dense embedding model 80× larger, on ViDoRe v3 enterprise documents (June 2026). On the finance set, recall rose from 58.90% to 80.91%, part of a +34% recall and +30% nDCG@10 average improvement, and the dense model won no domain at all.

End to end, on ViDoRe v3 finance documents, TopK's File Search answered 84.59% of questions correctly, versus 72.17% for Gemini File Search and 63.75% for Bedrock Knowledge Base, judged by GPT-5.

What actually fixes it?

Index at token granularity. Multi-vector retrieval keeps one embedding per token and scores with MaxSim, so query terms match cells instead of page summaries. Visual late-interaction models (ColPali, ColQwen) extend the same part-matches-part idea to scanned pages and rendered tables, where cell structure never survives text extraction in the first place. The full decision framework is in when to use multi-vector embeddings.

TopK runs this stack in production: semantic_index embeds and serves token-level retrieval from one schema annotation, and File Search builds on it to answer questions over uploaded filings with page-level citations. The finance numbers above are its published, dated results.