PageIndex 深層解析：ベクトルなし推論型 RAG、AI を人間の専門家のようにドキュメントを読ませる
PageIndex は Vectify AI チームによってオープンソース化されたベクトルなし、推論型 RAG フレームワークです（GitHub 14.8k+ stars）。これは、長いドキュメントを階層的なツリーインデックスに変換し、LLM を使用してツリー上で推論的な検索を行い、FinanceBench 金融ドキュメント Q&A ベンチマークで 98.7% の精度を達成します。
1. 背景：従来の RAG の 5 つの課題
RAG は、大規模言語モデルアプリケーションの事実上の標準となっています。主流のソリューションでは、前処理段階でドキュメントを固定長のチャンクに分割し、embedding モデルを介してベクトルに変換し、ベクトルデータベースに保存します。クエリ時には、ユーザーの質問に対して同様の embedding を行い、ベクトル類似度検索によって Top-K の結果をリコールし、LLM の入力コンテキストとして連結します。
このプロセスは、短いテキストや一般的なシナリオでは効果的ですが、専門的な長いドキュメント（財務報告書、法律、技術マニュアルなど）のシナリオでは、5 つの根本的な問題が明らかになります。
1) 類似性 ≠ 関連性。 ベクトル検索は、「意味的に最も類似したテキストブロック = 最も関連性の高い回答ソース」という仮定に基づいています。しかし、専門的なドキュメントでは、多くの段落が近似した意味を共有していますが、重要な詳細において大きな違いがあります。
2) ハードチャンキングはコンテキストの完全性を破壊します。 512 または 1024 トークンの固定ウィンドウでドキュメントを分割すると、文、段落、さらには論理的なセクション全体が切り捨てられ、重要なコンテキストが失われます。
3) クエリの意図と知識空間のミスマッチ。 ユーザーのクエリは「内容」ではなく「意図」を表現しており、query embedding と document embedding は異なる意味空間に存在します。
4) ドキュメント内の参照を処理できません。 専門的なドキュメントでは、「詳細は付録 G を参照」「表 5.3 を参照」などの参照がよく見られます。これらの参照と参照されるコンテンツの間には意味的な類似性が存在しないため、ベクトル検索では一致させることができません。
5) 独立したクエリ、会話履歴を利用できません。 毎回、検索は query を独立したリクエストとみなし、以前の会話のコンテキストと組み合わせて漸進的な検索を行うことができません。
2. PageIndex 全体アーキテクチャ
PageIndex は、ベクトルなし（Vectorless）、推論ベース（Reasoning-based）の RAG フレームワークです。その中心的なアイデアは、モデルにベクトル空間で近似マッチングをさせるよりも、ドキュメントの構造化された表現で推論させることです。つまり、「何が似ているか」だけでなく、「どこを見るべきか」を決定します。
PageIndex は、人間の専門家が長いドキュメントを読む方法をシミュレートします。まず、目次を見て、質問に基づいて関連する章を判断し、目標のコンテンツが見つかるまで階層的に深く掘り下げます。このプロセスは、次の 2 つのステップで実現されます。
- ツリー構造インデックスの構築：PDF/Markdown ドキュメントを階層化された JSON ツリーに変換します。これは「LLM に最適化された目次」に似ています。
- 推論式ツリー検索：LLM は、質問に基づいてツリー上で推論ナビゲーションを行い、関連するノードを特定し、コンテンツを抽出して回答を生成します。
3. コアモジュールの分解
3.1 PDF 処理パイプライン
PageIndex の PDF 処理パイプラインは、tree_parser() 関数によって編成されており、コアプロセスには、目次検出（3 つのモード分岐）、前書きの追加、フラットリストから階層ツリーへの変換、大きなノードの再帰的な細分化、ノードの充実化、JSON ツリー構造の出力が含まれます。
3 つの処理モード：
- process_toc_with_page_numbers（目次あり + ページ番号あり）：LLM を使用して元の目次を構造化された JSON に変換し、論理ページ番号を物理ページ番号にマッピングします。
- process_no_toc（目次なし）：LLM が本文の内容から直接階層構造を推論します。
- process_toc_no_page_numbers（目次あり、ページ番号なし）：構造を抽出してから、物理ページ番号を推論して追加します。
3.2 ツリー構造データモデル
ツリー内の各ノードには、title、node_id、start_index、end_index、summary、prefix_summary、text、nodes（子ノードの配列）などのフィールドが含まれます。
3.3 推論式検索メカニズム
検索段階では、ベクトル計算に依存しません。LLM は、ユーザーの質問とドキュメントのツリー構造を受け取り、ノードのタイトルと要約に基づいて推論を行い、「思考プロセス」と関連する node_id のリストを出力します。システムは、node_id に基づいて node_map から対応するノードの完全なテキストを抽出し、コンテキストとして連結して LLM に渡し、最終的な回答を生成します。
4. コアデザインのハイライト
- ベクトルなしアーキテクチャ：embedding モデルとベクトルデータベースが不要になり、インフラストラクチャのコストが削減され、デプロイメントが簡素化されます。
- ドキュメントの自然な構造を保持：ドキュメント固有の章/セクション/サブセクションでコンテンツを整理し、チャンクを跨ぐコンテキストの損失を回避します。
- 検索の解釈可能性：毎回、検索は完全な推論チェーンを返し、コンプライアンス要件の高いシナリオで明らかな利点があります。
5. 評価結果
Mafin 2.5 は、PageIndex に基づく金融ドキュメント Q&A システムです。FinanceBench（金融ドキュメント QA ベンチマークテスト）でのパフォーマンスは 98.7% の精度に達し、Perplexity（45%）および GPT-4o（31%）を大幅に上回っています。
6. 適用可能なシナリオ
**適しているもの：**明確な階層構造を持つ長いドキュメント（財務報告書、規制、教科書、マニュアル）、数十ページから数百ページの長さ
**適していないもの：**構造化されていないコンテンツのドキュメント、OCR 処理されていないスキャン、表/グラフがメインのドキュメント、ミリ秒単位のリアルタイム応答が必要なシナリオ
7. まとめ
PageIndex の主な貢献は、実用的なベクトルなし RAG パラダイムを提案したことです。ドキュメントの自然な構造を使用してツリーインデックスを構築し、LLM 推論をベクトル類似度検索の代わりに使用します。このソリューションは、明確な階層構造を持つ専門的な長いドキュメントのシナリオで優れたパフォーマンスを発揮し、解釈可能性と監査可能性も従来のソリューションよりも大幅に優れています。
