今回の論文
今回取り上げるのは、Stanford University の Parth Sarthi、Salman Abdullah、Aditi Tuli、Shubh Khanna、Anna Goldie、Christopher D. Manning による 2024 年の論文「RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval」です。公開元は arXiv で、研究分野は RAG と長文ドキュメント検索です。URL は https://arxiv.org/abs/2401.18059 です。
この論文を選んだ理由は、RAG を作るときに多くの人が最初にぶつかる「長い文書をどう分割し、どう検索するか」という問題に、かなり実装寄りの答えを出しているからです。単に埋め込みモデルを変えるのではなく、検索対象そのものの作り方を変える発想なので、社内文書検索、仕様書QA、論文検索、ナレッジベース構築などにそのまま応用しやすいです。
どんな技術か
RAPTOR は、長い文書をそのまま細かいチャンクに切って検索するのではなく、チャンクをまとめて要約し、その要約をさらにまとめることで、文書全体を木構造にして検索する技術です。葉には元の細かいチャンクがあり、上の階層に行くほど広い範囲をまとめた要約が置かれます。
普通の RAG は「どの一節を取るか」は得意でも、「文書全体として何を言っているか」や「離れた場所にある情報をまとめる」ことが苦手です。RAPTOR はそこを補うために、詳細と要約の両方を検索対象に入れます。つまり、局所的な事実も、文書全体の論旨も、同じ検索基盤の上で扱えるようにした手法です。
課題
この技術が解決しようとしている課題は、長文ドキュメントを対象にした RAG で、必要な情報が必ずしも 1 つの短いチャンクに収まらないことです。たとえば仕様書、論文、書籍、長い議事録では、答えに必要な情報が複数箇所に分散していることが珍しくありません。
難しいのは、検索器が通常は短い連続チャンク単位で候補を返す点です。この方法だと、局所的には似ていても全体の文脈を欠いた断片が上位に来やすくなります。逆に、文書全体をそのまま長いコンテキストとして LLM に渡す方法は、推論コストが高く、モデルが長文中の重要箇所をうまく使えないこともあります。
既存手法の限界は、チャンク化が平坦であることです。文書の階層構造や話題のまとまりを検索基盤に取り込めていないため、「概要を知りたい質問」と「具体的な記述を知りたい質問」の両方に同じ粒度で対応しなければなりません。実際の AI システムでは、社内ナレッジ検索、法務文書 QA、研究支援、顧客対応支援のように長文を扱う場面で、この問題が精度低下や幻覚の原因になります。
用語解説
- チャンク分割
- 長い文書を一定長の小片に分ける前処理です。通常のRAGではこの小片がそのまま検索単位になりますが、RAPTORではこの葉ノードが後段の要約ツリーの土台になります。
- 埋め込みベクトル
- テキストの意味を数値ベクトルに変換したものです。RAPTORでは元チャンクだけでなく要約ノードも埋め込み化し、異なる階層のノードを同じ検索空間で比較できるようにしています。
- クラスタリング
- 意味が近いテキスト同士をまとめる処理です。RAPTORの重要点は、文書中で隣接しているかどうかではなく、意味的に近いかどうかでまとめる点にあります。
- アブストラクティブ要約
- 元文をそのまま抜き出すのではなく、内容を言い換えて短くまとめる要約方式です。RAPTORはこの要約を再帰的に作ることで、詳細から概略まで複数レベルの表現を持てるようにしています。
- 階層検索
- 1段のインデックスではなく、粗い要約から細かい原文まで段階的に検索する考え方です。RAPTORを理解する上では、検索対象を増やす話ではなく、粒度を設計する話だと捉えると読みやすいです。
技術の仕組み
RAPTOR の基本アイデアは、文書を「そのまま切って並べる」のではなく、「意味の近い部分をまとめ、その要約を上位ノードとして持つ木構造に変える」ことです。論文ではまず文書をおおむね 100 トークン前後の短いチャンクに分け、これを葉ノードにします。文の途中で無理に切らず、文単位のまとまりを保つのも小さいですが重要な工夫です。
次に各チャンクを埋め込みベクトル化し、意味の近いチャンクをクラスタリングします。ここで RAPTOR は Gaussian Mixture Model と UMAP を組み合わせています。埋め込み空間は高次元なので、そのままではクラスタリングしづらく、まず次元圧縮で大まかな構造を取り出し、その上で確率的にクラスタを作ります。さらにソフトクラスタリングを採用しており、1つのチャンクが複数クラスタに属しうる設計です。これは、実際の文書では 1 つの段落が複数トピックにまたがるため理にかなっています。
クラスタができたら、その中のテキスト群を LLM で要約し、新しい親ノードを作ります。親ノードのテキストも再び埋め込み化され、同じ手順でさらに上位のクラスタと要約が作られます。これを繰り返すことで、葉には原文チャンク、上層には中間要約、最上層には文書全体のテーマに近い要約が並ぶツリーができます。
推論時の検索方法は 2 つあります。1 つは tree traversal で、上の階層から順に関連度の高いノードを選び、その子ノードに降りていく方式です。これは「まず概要を絞ってから詳細を見る」動きに近く、探索空間を絞りやすいです。もう 1 つは collapsed tree で、階層を潰して全ノードを候補にし、関連度が高いものからトークン上限まで詰める方式です。こちらは質問に対して、要約ノードと原文ノードを混在させて柔軟に拾えるのが強みです。
重要なのは、RAPTOR が単なる要約前処理ではないことです。要約したら原文を捨てるのではなく、原文も要約も両方保持します。これにより、「全体像を押さえるための上位ノード」と「根拠を取るための下位ノード」を同時に LLM に渡せます。長文RAGでよくある「要約だけだと細部が落ちる」「生チャンクだけだと全体像が見えない」という二択を崩したのが、この論文の技術的な価値です。
実験と結果
論文では、RAPTOR が長文理解に本当に効くかを検証するため、複数の質問応答データセットで比較実験を行っています。対象は書籍や映画の長い物語を扱う NarrativeQA、論文全文を対象にする QASPER、長めの文章を読んで推論する QuALITY です。つまり、どれも「短い断片だけでは答えにくい」タイプのタスクです。
まず QASPER では、GPT-3、GPT-4、UnifiedQA 3B を読み手として使った比較で、RAPTOR は BM25 や DPR より高い F1 を示しました。論文中の表では、GPT-4 で BM25 が 50.2、DPR が 53.0 に対し、RAPTOR は 55.7 でした。UnifiedQA 3B でも BM25 の 26.4、DPR の 32.1 に対し、RAPTOR は 36.6 まで伸びています。論文全文のような長い技術文書では、局所チャンク検索だけでは足りず、階層的な要約表現が効いていると読めます。
QuALITY でも改善は明確です。論文の controlled comparison では、GPT-3 を使った場合に BM25 が 57.3、DPR が 60.4、RAPTOR が 62.4 でした。UnifiedQA 3B でも BM25 の 49.9、DPR の 53.9 に対して RAPTOR は 56.6 です。さらに GPT-4 と組み合わせた結果では、QuALITY 全体で 82.6% の精度を出し、当時の既存最高水準を大きく上回ったと報告しています。特に難問サブセットでの改善が大きく、複数箇所をまたいだ推論との相性の良さが見えます。
NarrativeQA でも、SBERT、BM25、DPR といった検索器それぞれに対して RAPTOR ありの方が良い結果でした。論文では UnifiedQA 3B を用いた設定で、たとえば SBERT ベースの比較で ROUGE-L が 29.26% から 30.87% に、METEOR が 18.15% から 19.20% に改善しています。改善幅だけ見ると爆発的ではありませんが、すでに強いベースラインに対して一貫して上積みできているのが重要です。
結果から言えるのは、RAPTOR は「検索器を置き換える万能手法」ではなく、「長文の知識構造を RAG が扱いやすい形に変える手法」だということです。特に、文書全体の論旨、複数章に散った根拠、抽象と具体を行き来する質問に効きやすいと解釈できます。
何に使える？
この技術が使えそうなのは、まず社内ドキュメントや製品仕様書を対象にした RAG です。長い設計書や運用手順書では、質問に必要な情報が前提説明と具体手順に分かれていることが多いため、上位要約と下位根拠を同時に取れる RAPTOR の設計が向いています。
研究支援や論文検索にも相性が良いです。論文は、要旨、手法、実験、考察が離れた節に分かれるので、通常のチャンク検索だと手法だけ、結果だけが取れて全体の比較がしづらいです。RAPTOR のような階層表現があれば、「この論文は何を改善したのか」と「どの条件で効いたのか」を一緒に拾いやすくなります。
顧客対応支援や社内ヘルプデスクでも有望です。FAQ だけでなく、マニュアル、障害報告、設定ガイドなど複数粒度の文書が混ざる環境では、細かい手順だけを返すより、最初に全体方針を要約し、その後に該当手順を出す方が回答品質が安定しやすいです。RAPTOR の考え方は、その回答構成自体を支える検索インフラとして使えます。
また、エージェント系のワークフローにも応用できます。エージェントがツール実行前に長いドキュメントを参照するとき、毎回全文を読むのは重いです。まず上位要約で探索方針を決め、必要な部分だけ下位ノードに潜る設計にすれば、レイテンシとコンテキスト使用量の両方を下げられる可能性があります。これは論文の直接の実験対象ではありませんが、技術的にはかなり自然な応用です。
開発や事業へのヒント
この論文から得られる大きなヒントは、RAG の差別化ポイントは「どの埋め込みモデルを使うか」だけではなく、「検索対象をどう設計するか」にあるということです。もし自分で AI アプリを作るなら、まずチャンク戦略を見直すだけでも価値があります。特に長文中心の SaaS なら、単純な固定長チャンクより、話題単位のまとめと中間要約を持つインデックスの方が優位になりやすいです。
既存サービスの改善にも使えます。たとえばナレッジ検索で「答えは合っているが説明が薄い」という問題があるなら、下位ノードだけでなく上位要約ノードを一緒に渡すと、回答の骨格が安定するかもしれません。逆に「それっぽい概要は出るが根拠が弱い」なら、上位要約から下位根拠へ降りる検索フローを明示する設計が有効です。
小規模プロダクトでも、論文そのままのフル実装でなく一部だけ取り入れる価値があります。たとえば、文書ごとに 1 段だけクラスタ要約を作る、章ごとの要約ノードを追加する、検索結果の再ランキングで要約ノードと原文ノードを混ぜる、といった軽量版でも発想は活かせます。重要なのは「RAG の入力文書を、そのまま保存するのではなく、推論しやすい構造に再編成する」という考え方です。
今後注目すべき方向性としては、RAPTOR のような階層インデックスと、クエリ分類、再ランキング、引用付き生成、エージェント制御をどう組み合わせるかです。特にエンタープライズ用途では、単一の検索器より、文書構造と質問タイプに応じて粒度を変える設計が競争力になりやすいです。
限界
RAPTOR の限界としてまずあるのは、前処理コストです。通常の RAG はチャンク化して埋め込みを作れば始められますが、RAPTOR はクラスタリングと要約生成を再帰的に回すため、インデックス構築時の計算コストとトークンコストが増えます。更新頻度の高いナレッジベースでは、この再構築コストが運用上の負担になりえます。
また、要約に依存する以上、要約の品質が悪いと上位ノードの検索品質も落ちます。論文では要約に軽微な hallucination が約 4% 含まれたと報告しています。大きな悪影響は観測されなかったとされていますが、法務、医療、財務のように要約の取りこぼしや言い換えが重要な領域では慎重に扱うべきです。
実装の難しさもあります。GMM、UMAP、BIC によるクラスタ数選定、要約ノード生成、階層検索の設計など、通常のベクトルDB中心の RAG より部品点数が増えます。小規模チームでは、まず軽量な階層要約版から始めた方が現実的かもしれません。
さらに、すべてのタスクで有利とは限りません。短文FAQや、答えが局所的な 1 文に閉じている検索では、要約ツリーの恩恵は小さい可能性があります。RAPTOR は特に、長文で多段の推論や全体理解が必要な場面に向いた手法です。つまり、導入前に自分たちの質問分布を見極める必要があります。
よくある質問
Q. RAPTOR は普通のベクトル検索と何が違うのですか？
A. 普通のベクトル検索は、多くの場合、固定長チャンクを1段で並べて検索します。RAPTOR はそこに中間要約と上位要約を追加し、複数の粒度で検索できるようにします。違いは埋め込みモデルそのものより、検索対象の構造化にあります。
Q. 既存のRAGに後付けしやすい技術ですか？
A. 比較的後付けしやすいです。論文の価値は、生成モデル本体を変えなくても、インデックス構築と検索戦略を変えるだけで改善できる点にあります。ただし、要約生成パイプラインや更新設計は追加で必要です。
Q. どんなデータで特に効きやすいですか？
A. 論文、仕様書、契約書、長いマニュアル、書籍のように、答えに必要な情報が複数箇所へ分散しやすい文書です。逆に、短いFAQ集のようなデータでは恩恵が限定的な可能性があります。
Q. 要約ノードを使うと根拠性が落ちませんか？
A. その懸念はあります。だからこそ RAPTOR は要約だけに寄せず、葉ノードの原文も保持します。実務では、上位要約で文脈を補いながら、回答生成時には下位ノードの原文引用も必ず含める設計が安全です。
Q. 小さなチームでも導入できますか？
A. フル実装はやや重いですが、考え方は導入できます。たとえば章ごと要約ノードを追加する、検索結果に概要ノードを混ぜる、といった簡易版でも長文RAGの品質改善につながる可能性があります。
今日の学び
この論文は、長文RAGで「短いチャンクだけを取っても文書全体を理解しにくい」という課題を扱いました。これに対して、RAPTOR はチャンクを意味的にまとめて再帰的に要約し、詳細から概略までを含む検索ツリーを作ることで解こうとしました。
ここから得られるヒントは明快です。RAG の性能は、検索モデルだけでなく、知識をどんな構造で持たせるかで大きく変わります。長文を扱うプロダクトほど、インデックスを「保存形式」ではなく「推論のための表現」として設計する価値があります。