0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@TOMOSIA-LinhND(Mr. 404)
in

階層型RAG完全ガイド：Part 4 - Multi-Level Retrieval & RAPTOR

0
Posted at

知識ツリーによるマルチレベル要約と全域的情報集約

連載「階層型RAG完全ガイド」について:
本シリーズは全5回を通じて、特定のフレームワーク（LangChain, LlamaIndex等）に依存せず、本番環境で真に機能する**検索システム設計（Retrieval System Design）**の基礎から応用までを網羅的に解説します。

1. 課題：数行の文章では答えられない「大域的な質問」

Part 3 までで解説した手法（Flat, Parent–Child, Multi-Rep）は、特定のピンポイントな情報を取り出す局所的質問（Local Queries） に対して極めて強力です。

  • 「昼食手当の支給額はいくらか？」 $\rightarrow$ 第4条の該当行を見れば即答可能。
  • 「504 Gateway Timeoutエラーの対処法は？」 $\rightarrow$ トラブルシューティングの1段落を見れば解決。

しかし、実際の業務において経営層やアナリストが求めるのは、ドキュメント全体を俯瞰した大域的・網羅的な質問（Global Sensemaking Queries） です。

  • 「過去5年間にわたる有価証券報告書から見る、当社の事業戦略の主要な転換点は何か？」
  • 「直近20件のシステム監査報告書で繰り返し指摘されている重大なセキュリティリスクの傾向は？」
  • 「この技術標準書全体を貫く基本的な設計思想は何か？」
Local Query  ──> 1〜2箇所の特定段落に解が存在 ──> Flat / Parent–Child で十分対応可能
Global Query ──> 100ページ以上に情報が分散    ──> 局所的RAGでは取得漏れ・偏りが発生

従来のRAGでこのような大域的質問を投げると、類似度スコアがたまたま高かった5〜10個の断片テキストだけが抽出されます。その結果、LLMは全体のわずか5%の断片的な情報だけを根拠に回答を作成し、偏った見解やハルシネーションを出力してしまいます。

この「全体把握の壁」を打ち破るのが、Multi-Level Retrieval および RAPTOR です。

2. Recursive Retrieval & Index Nodes：階層ルーティング

RAPTORの詳細に入る前に、まず再帰的検索（Recursive Retrieval）における Index Node（インデックスノード） の概念を整理します。

データベース内のノードは、必ずしも生のテキストを保持している必要はありません。他の専門インデックスやRetrieverへの**「参照ポインタ」**として機能させることができます。

例：大手メガバンクの自動音声応答（IVR）

銀行の代表番号に電話をかけたときのルーティングを思い浮かべてください。

  • 音声ガイダンス：「カードの紛失・盗難は1番を、口座開設や諸手続きは2番を、住宅ローンに関するご相談は3番を押してください。」
  • 「1番」を押すと専門のデスクへ転送：「クレジットカードは1番を、キャッシュカードは2番を...」

500人の行員を1つの大部屋に集めてランダムに電話を取らせるのではなく、段階的にトピックを絞り込む（再帰的階層化） ことで、専門の担当者へ最短で誘導します。

クエリが入力されると：

  1. ルートのRouterが質問のドメイン（財務、人事、技術など）を判定。
  2. 該当する Sub-Retriever を再帰的に呼び出し。
  3. 下位のインデックスから目的のドキュメントをピンポイントで検索します。

3. RAPTOR：再帰的抽象化によるツリー型検索

RAPTOR（Recursive Abstractive Processing for Tree-Organized Retrieval：スタンフォード大学研究チームがICLR 2024で発表）は、テキストをボトムアップ（下から上へ）で再帰的にクラスタリング＆要約し、マルチレベルの知識ツリーを自動構築する画期的なアーキテクチャです。

例：日本企業の報告・意思決定ピラミッド

大企業における情報の集約プロセスを考えてみてください。

  • 現場担当者（Leaf Nodes）： 毎日の個別取引、システムログ、議事録など膨大で詳細な生データを作成。
  • 課長（Level 1 Summary）： 課内の数十件の報告を集約し、週次の「課別サマリー（1ページ）」を作成。
  • 部長（Level 2 Summary）： 各課のサマリーを統合し、部門全体の「月次報告（2ページ）」を作成。
  • 社長・役員（Root Summary）： 全部門の月次報告を統合した「経営戦略ハイライト」だけを読んで全体方針を決定。

株主から「今期の全社的な成長要因は何か？」と問われた際、社長は数万枚の領収書をめくる必要はなく、最上位の経営サマリーを参照するだけで即答できます。

RAPTORツリー構築の4ステップ

  1. ステップ1：リーフチャンクの生成（Level 0）： 元ドキュメントを100〜200トークンの短いチャンクに分割し、ベクトル埋め込みを算出。
  2. ステップ2：意味的クラスタリング（Semantic Clustering）：
    • 次元削減アルゴリズム UMAP と混合ガウスモデル（GMM：Gaussian Mixture Models）を組み合わせ、意味的に近いチャンク群をクラスタリング。
    • 特徴： 1つのチャンクが複数の話題にまたがる場合、複数のクラスタに重複して所属できる（Soft Clustering） 点が強力です。
  3. ステップ3：再帰的要約（Recursive Summarization）：
    • LLMが各クラスタ内の全テキストを読み込み、「クラスタ要約文」を生成。
    • 生成された要約文を再びベクトル化し、さらにクラスタリング $\rightarrow$ 要約を繰り返す。
    • 最終的に最上位の Root Summaries に到達するまで階層を積み上げます。
  4. ステップ4：インデックスの平坦化（Index Flattening）：
    • 最下層の生チャンクから、各階層の要約、最上位のRoot要約に至るすべてのノードを同一のVector DBに一括格納します（メタデータに layer_level を付与）。

4. クエリ実行戦略：Tree Traversal vs Collapsed Search

RAPTORツリーを探索する手法には、主に2つのアプローチがあります。

┌──────────────────────────────────────────────────────────────────────────┐
│ アプローチ1：TREE TRAVERSAL（ツリー下降走査）                            │
│ ルートから開始 ──> 最も類似度の高い要約を選択 ──> 子へ降りる ──> リーフ  │
│ • メリット : 厳密なロジックツリーに沿って絞り込める。                   │
│ • デメリット: 上位の判定を一度誤るとリカバリー不能（Error Propagation）。│
└──────────────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────────┐
│ アプローチ2：COLLAPSED SEARCH（全階層一括検索 - 本番環境推奨）          │
│ 最下層リーフ＋中間要約＋最上位要約の全ノードに対して同時に類似度検索     │
│ • ピンポイントな質問 ──> 最下層のLeaf Chunkが自動的にヒット。           │
│ • 全体的な概要質問   ──> 上位のSummary Nodeが自動的にヒット。           │
│ • メリット : 経路選択の失敗がなく、並列検索により高速・堅牢。            │
└──────────────────────────────────────────────────────────────────────────┘

5. コスト、レイテンシ、そして実務上のトレードオフ

RAPTORは圧倒的な文脈把握力を誇りますが、事前計算コストとのトレードオフを理解する必要があります。

評価軸 Flat RAG Parent–Child RAPTOR
インデックス時LLMコスト $0$（Embeddingのみ） $0$（テキスト分割のみ） 高（多段要約の生成コスト）
Vector DB格納数 $N$ 件 $1.2N$ 件 $2.5N \sim 4N$ 件
インデックス構築時間 数秒〜数分 数分 ドキュメント量に応じ数十分〜数時間
検索レイテンシ 極めて高速（< 100ms） 高速（< 150ms） Collapsed Searchで高速（< 200ms）
大域的質問の回答力 低（断片化・見落とし） 低 極めて高い（業界トップクラス）

ドキュメントの差分更新（Incremental Updates）：
RAPTORの最大の課題は、ドキュメントが頻繁に更新される場合のツリー再構築コストです。本番環境では、ドキュメント全体を1つの巨大ツリーにするのではなく、ファイル単位・月次レポート単位でRAPTORツリーを分割作成し、最上位にRouterを配置する運用が現実的です。

6. アーキテクチャ比較：Flat vs Parent–Child vs RAPTOR

7. 本番運用のための最適化テクニック

  1. クラスタ要約には軽量モデルを採用： レベル1の細かな要約生成に最上位モデルを使う必要はありません。GPT-4o-mini, Claude 3.5 Haiku, Llama-3.1-8B 等を採用することで、構築コストを約90%削減できます。
  2. クラスタサイズの厳格な制限： 1つのクラスタに含まれるチャンク数を最大10〜15件に制限し、要約プロンプトのコンテキスト溢れとトークン消費を抑制します。
  3. 要約レイヤーの永続化とキャッシュ： 一度生成した中間要約はDocument Storeに永続保存し、ドキュメントの他用途での分析パイプラインにも再利用できるようにします。

8. Part 4のまとめと次回予告

本章のキーポイント

  • 局所的RAGは、ドキュメント全体を横断する「大域的質問」に対して構造的に破綻する。
  • RAPTORはボトムアップのクラスタリングと再帰的要約により、抽象度の異なる多段階インデックスを構築する。
  • 検索時は Collapsed Search（全層一括検索） を採用することで、質問の抽象度に応じた最適な階層の情報が自動的に抽出される。

👉 次回 階層型RAG完全ガイド：Part 5 - GraphRAG & 本番アーキテクチャ設計 では、シリーズの集大成として、マイクロソフトが提唱する「GraphRAG（ナレッジグラフ検索）」の原理、エンタープライズ本番アーキテクチャの完全設計図、そして**【付録A：検索品質評価（Evaluation）】と【付録B：本番導入10ステップチェックリスト】**を完全公開します！

参考文献

  1. Sarthi, P., et al. (2024). RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (ICLR 2024) - arXiv:2401.18059
  2. Stanford University Research. Official RAPTOR Open Source Repository
  3. LlamaIndex Documentation. RAPTOR Pack & Recursive Node Retrieval
  4. LangChain AI Cookbook. Building RAPTOR from Scratch with LangChain
  5. McInnes, L., et al. (2018). UMAP: Uniform Manifold Approximation and Projection for Dimension Reduction
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?