RAGの新常識｜ベクトルDBなしで精度を上げる「PageIndex」をわかりやすく解説

目次

---

1. まずはRAGってなに？

最近よく耳にする RAG（Retrieval-Augmented Generation）。
これは「AI が文章を作る前に、必要な情報を検索して取り込む」仕組みです。

これまで多くの RAG は ベクトル DB という技術を使ってきました。
文章を数値に変換して「似ている文章」を探すのですが、“似ている”＝“欲しい情報” とは限らないのが悩みどころ。

例えばマニュアルの似たような段落がヒットしてしまい、肝心な条件や例外を見落とす…そんな問題がよく起こります。

---

2. PageIndexの登場背景とコンセプト

そこで登場したのが PageIndex。
これは Vectify AI が考案した新しい RAG の仕組みで、発想はとてもシンプル。

人間が分厚い本を読むとき、まずは 目次を見て、探したい章を開き、さらに小見出しを辿って目的の場所に行く ことがありますよね。

PageIndex は、まさにこの流れを AI にやらせるのです。
「似ている文章」ではなく「本当に関連している箇所」にたどり着けるようになります。

---

3. ベクトルDBとの違いをわかりやすく

• ベクトル DB：文章を数値化して「雰囲気の似た部分」を検索
• PageIndex：文書を「目次ツリー」にして AI が道順を辿る

つまり、ベクトル DB は「言葉の似てる度合い」を頼りに探すのに対し、PageIndex は「人が読む流れ」を真似するんです。

この違いによって、検索の透明性が上がり、「どの章を辿ってその答えに行きついたのか」も説明できるようになります。

---

4. PageIndexの仕組み：OCR / Tree / Retrieval

PageIndex は大きく 3 つのステップで動きます。

✅ OCR（文書をきれいに読み取る）

普通の OCR はページごとに処理するので、見出しやリストがバラバラになりがち。
PageIndex の OCR は文書全体を一つの構造として理解し、見出しや表を保ったままきれいにデータ化します。

✅ Tree Generation（目次ツリーを作る）

文書をそのまま目次のような階層構造に変換。
章・節・小節のまとまりを持ったツリーができるので、長い報告書でも迷子にならずナビゲーション可能です。

✅ Retrieval（木を辿って検索）

AI は質問に合わせてツリーを探索し、関連する部分をすべて拾ってくる。
さらに「どのページ」「どの章」を辿ったかがわかるので、根拠つきの検索結果になります。

---

5. 比較表：ベクトルDB方式 vs PageIndex

---

6. どんな場面で役立つの？

PageIndex は特に次のようなシーンで効果を発揮します。

• 契約書や規約の検索
  似た文言が並ぶ中で、条件や免責事項の違いを正確に拾える。

• 技術マニュアルや製品仕様
  大量の手順や例外がある文書でも、関連する節をまとめて抽出できる。

• 財務報告や法務文書
  ページ番号つきで参照できるため、監査や説明責任に強い。

一方で、何百万件もの短いテキストをざっくり横断するような検索なら、従来のベクトル DB の方がスピードに強みがあります。

---

7. 導入するならここに気をつけたい

• 最初は 1 つの文書から試す：長大な PDF を処理してみるのが実感を得やすいです。
• ツリー生成の粒度を調整：章立てを細かく切りすぎず、自然な階層にするのがポイント。
• 根拠のログを保存：探索経路やページ番号を残すことで、あとから「どこから答えを取ったのか」を確認できます。
• キャッシュ活用：更新頻度の低い文書は一度処理して保存すれば、繰り返し検索が速くなります。

---

8. まとめ：RAGの次の一手はPageIndex

• PageIndex はVectify AIが開発した新しい RAG の仕組み。
• 文書を目次ツリーにして AI が探索するので、関連性が高く、根拠が明確。
• ベクトル DB 不要で、オンプレ環境や機密文書の検索にも向いています。
• 契約・技術・財務のように「正確さ」が重要なシーンで特に力を発揮します。

OpenBridge では、PageIndex を活用した RAG 基盤の設計や実装をサポートしています。
「ベクトル DB ではうまく答えにたどり着けない」「もっと根拠のある検索が欲しい」── そんな課題をお持ちなら、ぜひ一度ご相談ください。