ベクトル検索なしでRAGが動く時代へ

これまでRAGといえば、ドキュメントを細かく分割してベクトル化し、類似検索で関連チャンクを取り出すのが定番の流れだった。精度はベクトルの質に依存し、埋め込みモデルの選定、チャンキング戦略、ベクトルDBのセットアップと、触り始めるまでの準備が思ったより多かった。

PageIndexはそこを根本から変えようとしている。アプローチはシンプルで、ドキュメントに「目次（インデックス）」を付け、LLMがその構造を読んで必要な箇所を推論で特定する。ベクトルDBも埋め込みモデルも要らない。GitHubで3.5万スターを超えており、同カテゴリのツールとしては異例の注目を集めている。

従来のRAGが苦手としていたのは、意味的に近いが内容として違う文章を混同するケース、そして提案書・LP・契約書のように「構造」で意味が決まるドキュメントをうまく扱えないケースだ。ベクトル検索はあくまで「似ている文章を探す」仕組みであって、「この章のこの節が答えだ」という推論はできない。

PageIndexが取るのは推論ベースの検索。ドキュメントをインデックス化しておくことで、LLMが目次を手がかりに「どこを見るべきか」を判断する。これは人間がPDFを読む際に章立てを確認してから該当ページを開く動作に近い。構造化されたドキュメント——提案書、マニュアル、サービス紹介資料——を扱う場面では、ベクトル検索より素直な回答が得られる可能性がある。

注意したいのは、この手法はLLMのコンテキスト処理に依存している点だ。ドキュメントが長大になるほど、どのLLMを組み合わせるかが精度に影響する。ベクトルDBが不要な代わりに、LLM側の性能への依存度が上がるトレードオフがある。

PageIndexがどれだけ注目を集めていても、ベクトル検索が完全に不要になるわけではない。ざっくりとした判断軸として整理しておきたい。

PageIndexが向くケース

• 提案書・マニュアル・規約など、章立てや見出しがある構造化ドキュメント
• 社内ナレッジの検索など、ドキュメント数が限定的な用途
• セットアップを最小限にして素早く動かしたい場面

ベクトル検索が向くケース

• ウェブのクロールデータや構造が不均一な大量テキスト
• 意味的な近さで幅広く拾いたい横断検索
• すでにベクトルDBが稼働しているシステムへの組み込み

「新しいアプローチが出た＝既存が全部古くなる」ではなく、ドキュメントの性質と用途によって使い分ける判断が求められる段階に入っている。RAGの選択肢が増えたと受け取るのが現実的だ。