しばらくの間 RAG パイプラインを構築してきましたが、同じ壁にぶつかり続けました。単純な文書ではリトリーブは問題なく機能しますが、密度の高い財務レポート、法的提出、技術マニュアルを投げると一気に崩れてしまいます。
原因を探るのに少し時間を費やしましたが、基本的には 1 点に集約されます — 類似度は関連性と同じではない。 クエリに対して最も高いコサイン類似度を持つチャンクが、実際の回答を含んでいるとは限りません。特に、回答が付録にあってクロスリファレンスが指す場合、または表面的なテキストの一致だけでなく文書の構造を理解する必要がある場合にはそうです。
完全に異なるアプローチを取る PageIndex (github.com/VectifyAI/PageIndex、21.5k スター) に出会い、埋め込みなし、ベクトルDBなし、チャンク化なしという前提を捨てた方法が紹介されていました。代わりに文書の階層ツリーインデックスを構築し（豊かな ToC のようなもの）、そのツリー上で 推論 して回答を見つけます。要は、人間の専門家が実際に文書をナビゲートする方法を模倣しているのです。
彼らの Mafin 2.5 システムはこのアプローチで FinanceBench で 98.7% を達成しており、同じベンチマークでの通常のベクトル RAG の数値を大幅に上回っています。
私がベクトル RAG で頻繁に遭遇した失敗モード:
- ハードなチャンク化が文書構造を破壊する
- 「Appendix G を参照」といった相互参照はリトリーバーには完全に見えません
- 各クエリは状態を持たず、ターンを跨ぐ記憶がありません
- 監査証跡がなく、理由の説明がなくコサイン類似度スコアだけが返ってくる
他の人が同じ問題に直面したことがあるか、どのような回避策を取っているか気になります。また、PageIndex を BM25 + ベクトルのようなハイブリッド手法と比較したベンチマークを行った人がいるかどうかにも興味があります。
より詳しい解説と図を含む完全版を希望する方は、深掘りした解説記事をどうぞ: https://medium.com/data-science-collective/your-rag-system-isnt-retrieving-it-s-guessing-809dd8f378df
