PageIndexとは？ベクトルDBを使わない推論型RAG文書インデックスを解説

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex は興味深いRAGプロジェクトです。「また別のベクトルDBを作る」ことから始めるのではなく、長文書をまず目次のようなツリー構造に整理し、そのツリーに沿ってLLMに推論型検索を行わせます。

この記事の整理時点で、GitHubページでは約31.8k stars、2.7k forksが表示されており、ライセンスはMITです。READMEでの位置づけは Vectorless, Reasoning-based RAG、つまりベクトルDBを使わない、推論ベースのRAGです。

何を解決しようとしているのか

従来のRAGでよくある流れは、文書をチャンク化し、ベクトル化し、ベクトルDBに格納し、類似度検索で断片を取得するというものです。この方法はシンプルで汎用的、かつ成熟していますが、長い専門文書ではいくつかの問題が起きやすくなります。

類似度は本当の関連性と同じではない。
チャンク化によって文書構造が分断され、章や節の関係が失われる。
検索結果の説明性が弱く、なぜその箇所がヒットしたのか説明しにくい。
財務報告、規制文書、法律文書、技術マニュアルのような資料では、章をまたいだ推論が必要になることが多い。

PageIndexの考え方は逆です。まず文書を意味的なツリーとして構成し、モデルが人間のように目次を読み、章を開き、階層的に関連内容を探します。

PageIndexの基本ワークフロー

READMEでは、PageIndexの検索は二つのステップに分けられています。

文書に対して Table-of-Contents のようなツリー構造インデックスを生成する。
ツリー検索によって reasoning-based retrieval を行う。

このツリーは単なるファイルディレクトリではなく、LLMが使うための文書構造です。ノードにはタイトル、ページ範囲、要約、子ノードなどの情報が含まれます。これにより、モデルは質問に答えるときに大量のバラバラなchunkへいきなり向き合う必要がありません。まずどの章に入るべきか判断し、その後さらに下へ検索できます。

この方式は、構造が明確で内容が長い文書に向いています。たとえば次のような文書です。

財務報告やSEC filings。
規制資料やコンプライアンス文書。
学術教材や論文。
法律文書。
技術マニュアルや製品ドキュメント。
モデルのコンテキストウィンドウを超える大型PDF。

従来のベクトルRAGとの違い

PageIndexの主な特徴は五つにまとめられます。

第一に、Vector DBを必要としません。ベクトル類似度検索だけに頼るのではなく、文書構造とLLMの推論によって内容を特定します。

第二に、従来型のchunkingを行いません。文書は固定長の断片ではなく、自然な章や節に沿って整理されます。

第三に、説明性が高くなります。検索経路をページ、章、ツリーノードに対応させられるため、「ベクトル類似度でこの段落に当たった」より追跡しやすくなります。

第四に、検索はコンテキスト認識型です。質問、会話履歴、ドメイン背景がツリー検索の経路に影響します。

第五に、人間の専門家が文書を読む方法に近いことです。人は普通、文書全体を小さく切って類似度を計算するのではなく、まず目次を見て、章を特定し、最後に詳細を読みます。

これはベクトルDBに価値がないという意味ではありません。より正確には、PageIndexは「意味的な類似だけでは足りず、構造と推論が必要になる」長文書検索に向いた方式です。

ローカルでの実行方法

READMEにはローカルでのセルフホスト方法が示されています。まず依存関係をインストールします。

`1`	`pip3 install --upgrade -r requirements.txt`

次に、プロジェクトのルートディレクトリに .env を作成し、LLM API keyを書き込みます。プロジェクトは LiteLLM によって複数モデルをサポートします。

`1`	`OPENAI_API_KEY=your_openai_key_here`

PDFからPageIndex構造を生成します。

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

Markdownも処理できます。

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

主なオプション引数は次の通りです。

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

READMEでは、ローカルのオープンソース版は標準的なPDF解析を使うとも説明されています。複雑なPDFでは、プロジェクト側のクラウドサービスが拡張OCR、ツリー構築、検索パイプラインを提供します。

Agentic Vectorless RAGの例

このプロジェクトには、セルフホストしたPageIndexとOpenAI Agents SDKを使う agentic vectorless RAG の例もあります。オプション依存関係を入れて実行します。

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

この例の価値は、PageIndexを「文書ツリーを生成する」段階から「Agentが文書ツリーを使って検索する」段階へ進めていることです。企業ナレッジベース、財務報告Q&A、規制文書Q&A、技術文書Agentを作っているなら、READMEだけを読むより、この例を一度動かす価値があります。

クラウドサービス、MCP、API

PageIndexは単なるGitHub repoではありません。プロジェクトページにはいくつかの入口も示されています。

セルフホスト：オープンソースコードをローカルで実行し、実験や制御された展開に向く。
Chat Platform：ChatGPT風の文書分析プラットフォーム。
MCP / API：既存のAgentや自動化フローへ組み込みやすい。
Enterprise：プライベートまたはオンプレミス展開向け。

これは単なるdemoではなく、「推論型文書検索」を統合可能な文書インテリジェンス基盤にしようとしていることを示しています。

向いている場面

PageIndexは次のようなタスクに向いています。

長いPDFのQ&A。
財務報告、年次報告、目論見書、規制文書の分析。
法律・コンプライアンス文書検索。
技術マニュアルQ&A。
複数章にまたがる教材や論文の検索。
説明可能な検索経路が必要な企業ナレッジベース。
Agentに構造化された文書コンテキストを提供すること。

資料が短い、構造がほとんどない、または普通のFAQに近い場合は、従来のembedding + vector DBで十分かもしれません。PageIndexの利点は、長文書、強い構造、専門領域、推論が必要な質問でより出やすくなります。

注意点

第一に、PageIndexは依然としてLLMに依存します。ツリー構築、要約、検索品質は、モデル能力、プロンプト、文書解析品質の影響を受けます。

第二に、ローカル版は標準的なPDF解析を使います。複雑なスキャン文書、図表が多いPDF、レイアウトが乱れた資料では、OCRやより強い前処理が必要になる場合があります。

第三に、ベクトルDBなしはゼロコストを意味しません。ツリー構築自体もモデル呼び出しと時間を消費します。大規模文書コレクションでは特にそうです。

第四に、PageIndexは文書構造インデックスと推論検索のフレームワークに近く、すべてのRAG技術スタックを直接置き換えるものではありません。実際の本番環境では、ベクトル検索、キーワード検索、権限制御、キャッシュ、監査システムと組み合わせて使うこともあります。

まとめ

PageIndexの面白さは、RAGの重点を「テキスト類似度による取得」から「文書構造 + LLM推論」へ移していることです。長文書や専門文書では、この方向は注目に値します。

企業文書Q&A、財務報告分析、規制文書検索、技術マニュアルAgentを作っているなら、PageIndexは新しいRAGアーキテクチャの参考になります。最初からすべてを細かく切ってベクトルDBに入れるのではなく、まず文書に構造を与え、その構造に沿ってモデルに推論させるという考え方です。

参考：

GitHub：VectifyAI/PageIndex

文書検索 on KnightLiブログ