もしあなたがまだ「チャンキング→埋め込み→ベクトルDB→類似度検索」という RAG パイプラインを使っているなら、PageIndex は 2026 年における最も重要な目覚ましとなるかもしれない。
痛点
従来の RAG パイプラインの各ステップは情報を失っている：
- チャンキング：连贯した文書を断片に切り分け、文脈関係が断裂する
- 埋め込み：セマンティクスを固定次元ベクトルに圧縮、詳細が失われる
- ベクトルDB検索：コサイン類似度に基づく検索だが、「類似」は「関連」を意味しない
- コンテキスト拼接：断片をプロンプトに詰め込み、LLM に意味の再構築を強いる
PageIndex のアプローチは：なぜ LLM に人間のように文書を構造的に閲覧させないのか？
PageIndex のソリューション
PageIndex の核心メカニズムは文書ツリー索引である：
- 文書に対して階層的ツリー構造を構築（章→節→項）
- LLM はルートノードから始め、関連するリーフノードまで層ごとにナビゲートする
- 各ステップで LLM が自律的に次にどの枝を探るか決定する
- 最終的に最も関連性の高い完全なコンテンツセグメントのみを読み取る、断片的なチャンクではない
このプロセスは埋め込みとベクトル検索を完全にスキップし、モデルが本の目次をめくるように情報を位置づけることを可能にする。
データ比較
| 次元 | 従来の RAG | PageIndex |
|---|---|---|
| ベクトルDBが必要か | 是（Pinecone/Milvus など） | 否 |
| 埋め込みモデルが必要か | 是 | 否 |
| チャンキングが必要か | 是 | 否 |
| 類似度検索が必要か | 是 | 否 |
| FinanceBench | 約80-85% | 98.7% |
| 長文書処理 | 情報の断片化 | 階層構造を保持 |
| デプロイの複雑さ | 複数コンポーネント（embedder + vector DB + retriever） | 単一コンポーネント |
98.7% の FinanceBench スコアは、ベクトル検索ベースのすべての RAG アプローチを上回る。これは単なる限界改善ではなく、方法論レベルの圧勝だ。
なぜ今なのか？
PageIndex の成功は 2 つの前提条件に依存しており、これらは 2026 年になって初めて真に成熟した：
- LLM のコンテキストウィンドウが十分に大きい：1M+ トークンのコンテキストにより、モデルは文書ツリー全体を同時に処理できる
- LLM のナビゲーション能力が十分に強い：モデルはツリー構造上で複数ステップの意思決定を行う必要があり、各ステップで正しい枝を選択する必要がある
つまり、PageIndex は「LLM を必要としない」のではなく、「より強力な LLM を必要とする」。モデルが十分に賢ければ、従来の埋め込みとベクトル検索は不要な中間層に過ぎなくなる。
はじめに
# インストール
pip install pageindex
# 基本的な使い方
from pageindex import PageIndex
# 文書索引の構築
index = PageIndex.from_documents([
"financial_report_2026.pdf",
"annual_summary.md"
])
# クエリ（LLM が自律的にツリー構造をナビゲート）
result = index.query("2026年第1四半期の収益成長の主な要因は？")適用シナリオと制限
| 適している | 適していない |
|---|---|
| 長文書（100ページ以上のレポート、マニュアル） | 短文の集合（ソーシャルメディアの投稿、短いレビュー） |
| 構造化文書（明確な章階層を持つ） | 非構造化テキストストリーム |
| 金融/法務など高精度が要求されるシナリオ | 超低レイテンシが必要なリアルタイム検索 |
| インフラ依存を減らしたいチーム | 成熟したベクトルDBパイプラインで良好なパフォーマンスを得ているチーム |
三つの判断
インクリメント：埋め込み + ベクトルDB + チャンキングを完全にスキップする RAG アプローチは、これまで大規模な検証がなかった。98.7% の FinanceBench スコアは実績である。
ノイズ：現在は FinanceBench のみの詳細データ。他のベンチマーク（HotpotQA、2WikiMultihopQA）でのパフォーマンスは未発表。超大規模文書セットでのツリー索引構築コストは検証待ち。
シグナル：5,775 いいね + 9,809 ブックマークの X ツイートは、コミュニティがこの方向に高い関心を寄せていることを示している。「ベクトルデータベース不要の RAG」が話題の中心になるとき、ベクトルデータベースベンダーは製品ポジションを真剣に再考する必要がある。