780ページある州政府の決算書のなかに「1,234」という数字が現れたとして、それが10万単位（lakh）なのか1000万単位（crore）なのかは、そのままでは判別できない。単位はたいてい表のヘッダー側に書かれていて、数値からの距離は中央値で13行、90パーセンタイルだと26行も離れている。文書を数百文字ごとに切ってベクトル埋め込みするふつうのRAGでは、数値と単位ヘッダーが同じチャンクに収まらない。結果として、桁が2つズレた答えを、それらしい自信とともに返す。
この「埋め込み検索は構造化文書で構造的に壊れる」という主張を、実データで測った論文が8月6日にarXivへ出ている。Sagar Tamangらの Beyond Top-K: Replacing Black-Box Retrieval with Interpretable Agentic Operations(arXiv:2608.06305)だ。結論を先に言うと、埋め込みをまるごと捨てた素朴な手法のほうが、精度で大きく上回った。
なぜ埋め込みは決算書で溺れるのか
一般的なRAG(Retrieval-Augmented Generation、検索で拾った文脈をLLMに渡す仕組み)は、文書をチャンクに割り、各チャンクをベクトルに変換し、質問ベクトルに近い上位k件を返す。意味の近さで引くこの方式は、言い換えや同義語には強い。だが今回の対象文書(Gujarat Finance Accounts 2024–25、780ページ、19,198行)は、非空行の86.8%が表の行だった。
問題は数字そのものにある。文書中の58,791個の数値トークンは、実際には15,960種類の値へ収束する。同じような数字が埋め込み空間にひしめき、質問と「意味的に近い」チャンクが大量に競合してしまう。企業名・勘定科目・桁揃えされた数値といった、決算書でいちばん効く手がかりは、埋め込みがもっとも均してしまう情報だ。表計算のシートをコピー機で薄く印刷して、罫線も桁も滲んで読めなくなる状態に近い。それが埋め込みが数値に対してやっていることだ。
READ:grepと行番号読みだけのエージェント
提案手法 READ(Reliable Embedding-free Agentic Document-search)は、埋め込みを一切使わない。代わりに、決定的な3種類の操作をエージェントに渡す。正規化した字句検索、見出し構造の把握、行番号で範囲を指定した読み出しだ。これらは Model Context Protocol(MCP、ツールをLLMへ標準化された形で公開する仕組み)のサーバとして、次の道具立てで実装されている。
memory_grep(pattern, context=0..10) # 行単位の検索。前後の文脈行を指定可
memory_outline(file) # 見出しと、その行・ページ範囲を返す
memory_read(a, b) # a行目からb行目を読む(1回400行まで)
memory_list(dir) # ファイル列挙
エージェントはまずgrepで数値やラベルの在処を探し、outlineで自分が文書のどこにいるかを掴み、証拠の位置を見てから読む範囲を決める。ポイントは、単位ヘッダーを取り込むために範囲を上方向へ広げられることだ。しかも全操作が「文書と引数の純粋関数」なので、同じ手順を再実行すれば同じ結果が出る。類似度スコアという不透明な数字ではなく、再生可能な監査ログが残る。ここは実務でかなり効く。なぜその行を引いたのかを、後から人間が追える。
素朴なほうが勝ち、しかも本命はBM25
評価は、文書から人手で作った51問(単純参照・算術・集計・ナビゲーション・回答不能など6カテゴリ)で行われた。バックエンドのLLMはGemini-2.5-pro。主な結果はこうなった。
| 手法 | 正答率 | 補足 |
|---|---|---|
| READ(4操作) | 58.8% | 埋め込みなし |
| READ(naive-grep版) | 66.7% | 正規化なしの素のgrep |
| BM25 | 51.0% | 疎な字句検索 |
| Dense(最良調整) | 35.3% | 2000字・k=16 |
| Hybrid(RRF+リランカー) | 29.4% | dense+BM25融合 |
| Agentic RAG | 27.5% | ベクトル検索ツール付き |
| Dense(既定) | 15.7% | 2000字・k=8 |
READはk=8のdense検索に対して統計的に明確な差(McNemar検定、Holm補正後 p=2×10⁻⁵)をつけた。だが本当に興味深いのはBM25との比較だ。READ 58.8%に対しBM25 51.0%、その差は有意ではない(p=1.00)。正規化を外した素のgrep版はむしろ66.7%まで上がる。つまりこの結果は「エージェントが賢いから勝った」のではなく、「埋め込みをやめたから勝った」と読むのが正しい。著者自身がそう明言している。ベクトルDBを立てて、融合して、リランカーまで足したHybridが、素のBM25に負けているのが象徴的だ。
この方向性は独立した研究とも符合する。Akarsuらの From BM25 to Corrective RAG(arXiv:2604.01733)は、7,318件の財務文書・23,088クエリという桁違いの規模で10種の検索手法を比較し、「BM25が最新のdense検索を財務文書で上回る」と報告した。ただし両者で食い違う点もある。Akarsuらの総合勝者はHybrid+ニューラルリランカー(Recall@5=0.816)だったのに対し、READの単一文書ではHybridがBM25に負けた。ここから引き出せるのは、「dense単独が数値・表データの弱点」という部分は再現性が高く、その先(素の字句検索で十分か、Hybrid+良質なリランカーが要るか)は文書とパイプライン次第、という現実的な結論だ。
どこまで真に受けるか、そして何を試すか
冷静に見ると、READの実験には弱点が多い。文書1本・LLM1種・51問という小ささで、しかもベンチマークを作ったのが評価対象システムの著者本人だ。回答の根拠一致率(groundedness)はREAD 58.0%と、BM25の67.3%より低い。多く読むぶん、拾った本文にない数字を口走る隙が増えるからだ。コストとレイテンシもREADが不利(1問あたり$0.058対BM25の$0.020、31.4秒対dense12.7秒)。だからこれは「決着」ではなく強い信号だ。
それでも、現場のエンジニアが持ち帰れる指針ははっきりしている。埋め込みは意味の近さを引く道具であって、正確な数値や識別子の照合には向いていない。表と数字が主体のコーパスに、反射的にベクトルDBを立てる前に、まずgrepと行範囲読みを試す価値がある。監査ログが残り、単価も安く、実装も軽い。「とりあえず全部embedして top-k」という既定路線を、少なくとも構造化文書では一度疑ってみる。今回いちばん学びになったのは、精度を上げたのが高度なモデルではなく、余計な抽象化を一枚はがしたことだった、という点だ。
※本記事は一次情報の調査をAIが行い、事実確認のうえ執筆・公開しています。