PageIndex - 文書の階層索引をLLMが探索するベクトル不要のRAG

READMEが比較対象とするVector RAGは、文書を分割してベクトル索引を作り、質問との意味的類似度で文章を取得する方式だ。PageIndexの問題提起は、この類似度と回答への関連性が一致しない場合にある。質問と表現が近い文章を取得しても根拠が足りず、表現が異なる関連箇所を取り逃がす可能性がある。

長い専門文書では、文書全体の構成や分野の文脈を踏まえて読む場所を選ぶ必要がある。公式説明は、質問の埋め込みを使う検索と、会話履歴や分野知識を含む文脈を使う探索を対比する。PageIndexは後者の判断をLLMに担わせる。ただし、これは方式の狙いであり、Vector RAG全般に対する精度優位を示すものではない。比較すべきなのは、同じ文書と質問で必要な根拠を取得できるかだ。

もう一つの比較対象は、質問のたびにPDF全体をモデルへ渡す方式である。READMEは、文書が長くなるほど入力費用が増え、コンテキスト上限にも制約されると説明する。PageIndexは先に索引を作り、以後の質問ではその索引を再利用して、必要と判断した箇所を読む。

この分離は、同じ文書への質問が続く用途で意味を持つ。初回の索引作成には時間と費用がかかるため、質問一回の費用だけで採否は決められない。全文入力との比較では、索引作成を含めた総費用と、実際に何回質問するかを合わせて考える必要がある。公式の費用比較も質問時の費用差を示すもので、索引作成まで含めた総費用の優位を保証してはいない。

2026年10月1日の観測では、GitHub Trendingの日次17位、当日1,097スター増、総38,129スター、3,306フォークが記録されている。階層索引と推論による検索という設計は、文書検索の仕組みを見直す題材として説明価値がある。ただし、この観測は関心の強さを示すもので、継続的な成長や検索品質の証拠ではない。

公式リポジトリはVectifyAI/PageIndexで、言語はPython、ライセンスはMIT。取得したリリース一覧の最新項目は、2026年9月28日公開のv0.2.20だった。技術説明の根拠はREADMEと部分的なリリースノートであり、実装やリンク先の評価資料は未確認である。公開説明で分かる設計と、導入前に確かめるべき挙動を分けて読む必要がある。

READMEのQuickstartでは、PythonパッケージpageindexのPageIndexClientに、索引用のindexとチャット用のchatを別々に設定する。submit_documentへPDFを渡すとdoc_idが返り、chatへ質問とdoc_idを渡して対象文書を指定する。この呼び出し関係が、登録時の索引作成と、質問時の探索を分ける入口になる。

重要なのは、二つのモデルが同じ仕事をするわけではない点だ。公式説明では、索引用モデルはノードの要約と索引の改善を担い、チャットモデルは質問に応じてツリーを探索する。READMEは前者には基本的なモデルでもよいとし、後者には費用を許容できる範囲で最良のモデルを推奨する。構造を準備する処理と、関連箇所を判断する処理で、モデル選択の基準を分けた構成である。

ローカル版の既定エンジンFlashについて、リリースノートはレイアウト統計からLLMなしで木構造を生成すると説明する。信頼できる埋め込みブックマークも利用する。したがって、ツリー全体をLLMに自由に生成させる方式と理解すると、構造抽出とモデル処理の境界を見誤る。

その後、LLMがノードの要約や索引の改善を担当する。ツリー最適化のoptimize="merge"は、LLMを使わない決定的な処理だ。既定の"full"ではLLMによる展開も加わり、複数ノードの展開提案を並行して実行する。ここで分かるのは、構造抽出、決定的な最適化、LLMによる改善という役割分担までである。レイアウトから階層を決める具体的な規則や、展開提案の採否を判断する詳細は、提供資料からは説明できない。

生成したツリー索引は、Localではローカルディレクトリに、Cloudでは管理ストレージに保存される。後続の質問ではこの索引を再利用する。ツリーは文書内の読む場所を示す階層であり、ノードは要約・展開・読み取りの対象になる。「固定長チャンクを作らない」という説明を、文書を扱う単位が存在しないという意味に取るべきではない。

質問時には、チャットモデルがツリーを推論で探索し、必要と判断したノードの内容を読んで回答に使う。リリースノートはLocalとCloudの双方に、treeやpage contentの文書操作を提供すると説明する。索引を見ることと本文を読むことが分かれているため、全文を毎回入力する方式とは情報の取得経路が異なる。READMEの引用粒度はLocalがページ単位、Cloudがブロック単位だ。ただし、具体的な巡回順序や探索アルゴリズムは確認できない。

Localは、公式説明ではサーバー、ベクトルDB、PageIndex APIキーなしで利用できる。Cloudへ切り替える構成では、文書解析、OCR、画像理解、ツリー構築、管理ストレージをサービス側が担う。READMEの例はindex="cloud"で索引作成・保存先を切り替える。これは単なる保存場所の変更にとどまらず、扱える文書と提供機能の範囲も変える選択だ。

リリースノートは、文書の保存先とチャットモデルの選択を分け、Cloudの文書ツールに対してプロセス内のQAエンジンを実行すると説明する。Cloud利用を、回答生成まで一括してサービスへ委ねる構成と同一視することはできない。一方、その説明の後半は取得本文が切れており、ページ内容の詳しい送信経路は確認できない。Localの例もOPENAI_API_KEYを使うため、ローカル保存から完全オフライン処理を推定することはできない。

適合しやすいのは、章立てのある長いテキスト主体のPDFを、継続的な質問応答の対象にする用途だ。READMEは財務・法務・規制文書、技術マニュアルなどを挙げる。Pythonアプリケーションで登録時に索引を準備し、以後の質問で再利用する構成なら、PageIndexの処理分離を生かしやすい。

Vector RAGに対しては、文書検索部分のベクトル索引と類似度検索を、階層索引とLLM探索へ置き換える候補となる。既存エージェントに対しては文書検索ツールとして組み込む位置づけで、READMEはOpenAI Agents SDKやClaude Agent SDKとの統合を案内する。ただし、一文書内のツリー探索と、多数の文書から対象を選ぶ仕組みは区別が必要だ。文書集合を対象とするPageIndex File Systemは、Cloud限定のファイル階層索引として説明されている。

開発側は、gpt-5.6-lunaを使うローカル索引作成について、9〜1,098ページの9 PDFで約0.001ドル／ページ、約13秒〜4.5分と報告する。費用図の参照線は0.0011ドル／ページだ。実行環境、反復回数、料金条件、並行度の詳細は提供資料になく、固定単価や処理時間の保証としては扱えない。

全文入力との比較では、gpt-5.6-solを使い、プロンプトキャッシュを除外し、両方式が同じ回答を返した文書を対象としている。直接PDF入力の質問費用はPageIndex比で、52ページが2.1倍、85ページが3.4倍、198ページが7.8倍、420ページが16.6倍と報告される。比較対象の805ページ文書は、直接入力側のコンテキスト上限を超えたという。これは限定条件での質問費用の比較であり、索引作成を含む総費用や、キャッシュを使う運用、別モデルへの一般化には追加検証が必要だ。

READMEはFinanceBenchでPageIndexの正答率98.7%、比較対象のvector RAGは50%と記載する。ただし、リンク先の評価本文は提供されておらず、モデル、検索設定、質問集合、採点手順、現在のSDKとの対応を確認できない。この数値から、手元の文書でも同じ差が出るとは判断できない。

現行Localの別の評価説明は、34 PDF・1,945ページに含まれる本文中の事実を問う62問で、Flash索引・OCRなしに限定される。FinanceBenchの結果と設定が一致するかは不明だ。LocalはOCRと画像理解を持たないため、スキャンPDFや画像主体の文書にはそのまま適用できない。Cloudはそれらを対応範囲に含むが、日本語文書の評価、表・図の抽出精度、文書更新時の差分索引は提供資料で確認できない。未確認の機能を、対応済みとも非対応とも断定しないことが重要である。

検索がチャットモデルの判断に依存する以上、索引用モデルを安価にできることと、質問時の費用を抑えられることは別の論点だ。提供資料には質問時の遅延分布、探索の停止条件、再試行やフォールバックが示されていない。厳密な応答時間や費用上限が必要な用途では、実際の質問集合で探索の運用特性を確かめる必要がある。

機密文書では、Localという名称よりも送信経路を確認すべきだ。READMEのLocal例はモデルAPIキーを設定し、Cloud例はそれに加えてPageIndex APIキーを設定する。ローカル保存だけでは文書内容の外部送信範囲を判断できず、閉域利用にはモデル構成と経路の検証が要る。Cloudへの移行では、管理ストレージに文書処理を委ねることに加え、データ保持・削除条件も確認対象になる。提供資料だけでは、これらの運用要件への適合は結論できない。