RAG 10：索引の工夫（GraphRAG ほか）― 資料の側から歩み寄る

小さく切れば見つかるが、切った文だけでは足りない

チャンクの大きさには、昔からの悩みがあります（第3章）。

図は、就業規則の3つの条を、短い文（チャンク）に切ったところです。「有給は繰り越せる？」と聞かれると、検索は「翌年まで繰り越せる」という短いチャンクをうまく見つけてくれるでしょう。短いチャンクは中身が1つの話題に絞られているので、その意味を表す数字の列（埋め込み）も、質問の数字の列に近くなりやすいのです。

ところが、この1文だけを LLM に渡すと困ります。何が繰り越せるのか、上限は何日か、が書いていません。同じ条の別の文を読まないと、正しく答えられないのです。

逆に、チャンクを大きく（たとえば条ごとに）切ると、文脈は残ります。でも、1つのチャンクにいろいろな話題が混ざるので、埋め込みがぼやけ、質問に近いと判断されにくくなります。

つまり、探すのに向いた大きさと、読ませるのに向いた大きさが違うのです。だったら、両者を分ければいい。これが次のページの考え方です。

親子チャンク：小さく探して、大きく渡す

親子チャンクは、1つの資料を2つの大きさで持っておく方法です。

図では、「翌年まで繰り越せる」という子が当たりました。そこで、その子を含む親、つまり「第12条 年次有給休暇」の全体を LLM に渡します。これなら、10日から始まり最大20日まで、翌年まで繰り越せる、という条文全体を読んで答えられます。

この形は「小さく探して、大きく渡す」という意味で Small-to-Big と呼ばれることもあります。LangChain（RAG などを組み立てる部品を集めた定番のライブラリ）などには、この仕組み（親文書を返す検索）が部品として用意されています。

作り方は単純です。チャンクに切るとき、それぞれの子に「親の ID」（親を見分ける番号）を覚えさせておき、検索で当たった子の親 ID から親の本文を引くだけです。下のコードは、1行目で子を10件探し、2行目で当たった子の親 ID を重複なしで集め、3行目で上位3つの親の本文を読み込んでいます。

const hits = await searchChildren(question, { topK: 10 });
const parentIds = [...new Set(hits.map((h) => h.parentId))]; // 同じ親は1回だけ
const context = await loadParents(parentIds.slice(0, 3));

注意点は、親が長すぎないことです。親を「文書全体」にすると、1回の答えに何万字も読ませることになり、遅く高くなり、読み落としも増えます（第8章）。同じ親の子が複数当たったときに、親を重複して渡さないことも大事です。

文の窓：当たった文の前後だけを足して渡す

親子チャンクは、「条」や「節」のような、はっきりした区切りがある資料に向いています。では、議事録や長いメールのように、区切りがはっきりしない文章ではどうすればよいでしょうか。

そこで使えるのが文の窓（センテンスウィンドウ）です。資料を1文ずつ索引に入れて探し、当たった文の前後の数文を足してから LLM に渡します。窓から外をのぞくように、当たった文の周りだけを見せるイメージです。

図では、「翌年まで繰り越せる」が当たり、その前後2文ずつ、合わせて5文が窓になりました。窓は条の境目を気にしないので、隣の第13条の最初の文まで入っています。

LlamaIndex（RAG 向けのライブラリの1つ）には、この文の窓を作る部品が用意されています。前後に何文を足すかは、資料の書き方によって変わるので、いくつか試して成績を比べる評価（第12章）で決めます。

親子チャンクと文の窓は、どちらも LLM を追加で呼ばないので、索引を作る費用がほとんど増えません。基本の索引の次に試すなら、まずはここからがおすすめです。

文脈を書き足してから索引に入れる

親子チャンクは「渡すとき」に文脈を足す方法でした。でも、そもそも探す時点で当たらないこともあります。

「翌年まで繰り越せる」というチャンクには、「有給」という言葉がありません。そのため、「有給の繰り越し」で探したとき、埋め込みでもキーワードでも、このチャンクが上位に来ないことがあります。報告書の「前期比3%増」のように、何の数字なのかがチャンクの外に書いてあることは、実際の資料ではとてもよくあります。

そこで、チャンクを索引に入れる前に、LLM に文書全体とチャンクを読ませ、「このチャンクはどの資料の、何の話か」を短く書き足させます。図の右がそれです。「就業規則 第12条（年次有給休暇）の一部。有給休暇の繰り越しについて。」という文脈を頭に付けてから、埋め込みを作り、キーワード検索の索引にも入れます。

この方法は、2024年に Anthropic が Contextual Retrieval（文脈つき検索）として紹介しました。紹介記事では、文脈を足した埋め込みと、キーワードの一致で探す検索（BM25、第6章）を組み合わせることで、上位20件に正しいチャンクが入らない失敗が約半分に減ったと報告されています（同社の評価データでの結果です）。

代償は、チャンクの数だけ LLM を呼ぶことです。1つの文書の多数のチャンクで、毎回同じ文書全体を読ませることになるので、プロンプトキャッシュ（第8章。毎回同じ前半部分を読ませるとき、その処理結果を使い回して安くする仕組み）で文書の部分を使い回すと、費用を大きく抑えられます。

要約の木：まとめ文も一緒に索引に入れる

「休暇の制度をざっくり教えて」と聞かれたらどうでしょう。答えは、どれか1つのチャンクにあるのではなく、たくさんのチャンクをまとめた内容です。細かいチャンクをいくつ拾っても、全体像にはなりません。

そこで、要約も索引に入れておくという考え方があります。図のように、

という木を作り、すべての段を索引に入れます。細かい質問には葉が、ざっくりした質問には中や根の要約が当たります。

この考え方を代表する手法が、2024年の国際会議 ICLR で発表された RAPTOR です。チャンクを埋め込みで似たものどうしにまとめ（クラスタリング）、それぞれを LLM で要約し、その要約をまたまとめて要約する、ということを繰り返して木を作ります。論文では、長い文書全体の理解が必要な質問で、大きく成績が上がったと報告されています。

代償は、要約を作るために LLM を何度も呼ぶことと、資料が変わったときに上の段も作り直す必要があることです。葉を1つ直したら、その上の要約も、根の要約も古くなります。

「全体では？」と聞かれると、上位数件では答えられない

さらに難しい質問があります。「社員アンケート全体で、多い不満は何？」のような、資料全体の傾向を聞く質問です。

図の24個の箱は、アンケートの回答（チャンク）です。中の丸の色が、そこに書かれた不満の種類だとします。赤は「残業」、橙は「評価」、紫は「設備」の不満です。

普通の RAG は、質問に近いチャンクを上位数件だけ拾います（赤枠）。でも、この質問の答えは、特定の数件ではなく、24件すべてを見て数えないと分かりません。上位5件だけ見て「多い不満は残業です」と答えても、たまたま拾った5件の傾向にすぎません。

前のページの要約の木は、この問題を少し和らげます。でも、「どんな人や組織が、どうつながっているか」という関係まで扱いたい場合に考えられたのが、次のページからの知識グラフと GraphRAG です。

知識グラフ：「誰が・何と・どうつながるか」を先に取り出す

知識グラフは、情報を「点」と「線」で表したものです。点は人・組織・製品などのもの（エンティティ）、線はそれらの関係です。

図では、「田中は営業部に所属」「営業部は A社と B社を担当」「A社と B社は製品Xを購入」「佐藤は開発部に所属」「開発部が製品Xを開発」という関係を、点と線で表しています。

これを作るには、LLM に文書を1つずつ読ませ、出てくるものと関係を取り出させます。「この文章に出てくる人・組織・製品と、それらの関係を JSON（プログラムが読みやすい決まった書式）で書き出して」と頼むわけです。取り出した結果をつなぎ合わせると、文書の山全体が1つの大きなグラフになります。

グラフがあると、文章の検索では難しい質問に答えやすくなります。

1つ目のように、答えまで何段もたどる質問（第9章の多段の質問）は、それぞれの事実が別々の文書に書かれていることが多く、普通の検索では集めきれません。グラフなら、線をたどるだけで集められます。

一方で、LLM による取り出しは完璧ではありません。同じ会社が「A社」「株式会社A」と別の点になったり、関係を取り違えたりします。取り出した結果を整える手間も見込んでおきます。

GraphRAG：つながりの濃いまとまりごとに要約を作る

GraphRAG は、2024年に Microsoft Research が発表した手法です（論文の題は「From Local to Global」）。知識グラフに、もう一段の工夫を加えています。

グラフの点を、つながりの濃いまとまりに分けるのです。これをコミュニティと呼びます。図では、営業部と、そこにつながる田中・A社・B社が1つ、開発部と佐藤・製品Xがもう1つのコミュニティになりました（分け方には Leiden 法というグラフの分割の方法が使われています）。

そして、コミュニティごとに、LLM で要約を書いておきます。「営業部は A社・B社を担当し、…」のように。コミュニティは大きな単位から小さな単位まで階層に分けられ、それぞれの階層で要約が作られます。

要約を先に書いておくのは、少し前に見た「全体では？」という質問に答えるためです。質問が来てから全部の資料を読むのは大変ですが、コミュニティの要約なら数が限られているので、それらを集めれば全体像を作れます。GraphRAG はオープンソース（誰でも中身を見て使えるソフト）として公開されていて、自分の資料で試すことができます。

個別の質問はグラフをたどり、全体の質問は要約を集める

GraphRAG には、質問の種類に合わせた2つの探し方があります。

図の赤い部分がローカル検索です。「田中」から「営業部」、そこから「A社」「B社」と線をたどり、その周りの情報を集めます。人に聞いて回り、知り合いの知り合いまでたどるイメージです。

グローバル検索は、各コミュニティの要約に「この質問に関係することは？」と聞いて部分的な答えを作り、それらを最後に1つにまとめる、という二段構えです。各支店に同じ質問をして報告を集め、本社で1つの報告書にまとめるのに似ています。たくさんの部分を並行して処理し（map＝割り振って処理する）、最後にまとめる（reduce＝1つに畳む）ので、map-reduce の形と説明されます。

GraphRAG の弱点は、作るのが高いことです。すべての文書を LLM に読ませて点と線を取り出し、さらにコミュニティごとに要約を書くので、普通の索引よりずっと多くの LLM 呼び出しが要ります。資料が増えたり変わったりしたときの作り直しも重くなります。

そのため、「全体の傾向」や「関係のつながり」を聞かれることが多い場面に絞って使うのが現実的です。普通の質問が中心なら、普通の RAG のほうが安く速く、十分に答えられます。

表・図・PDF のページをどう索引に入れるか

社内の資料は、きれいな文章ばかりではありません。表の多い仕様書、グラフの入った報告書、スキャンした紙の書類、スライドの PDF…。これらから文字だけを抜き出すと、困ったことが起きます。

表は、行と列の関係が消え、数字がばらばらに並ぶだけになります。グラフや図は、そもそも文字が無いので、何も残りません。スキャンした PDF は、文字認識（OCR）をしないと、文字すら取れません。

画像も文字も扱えることをマルチモーダル（複数の種類の情報を扱える）と呼びます。画像を読める LLM が増えたことで、対策の幅が広がりました。主な対策は3つです。

3つ目の代表が、2024年に発表された ColPali です。画像を読めるモデルでページの画像そのものから埋め込みを作り、文字の抜き出しという壊れやすい手順を飛ばします。見つかったページは、画像のまま、画像を読める LLM に渡して答えさせます。

どの方法でも、元のページへの参照（ファイル名とページ番号）を残しておくことが大事です。答えの根拠として、そのページを利用者に見せられるからです（第8章）。

限界とトレードオフ：索引を作る費用

この章の工夫は、どれも「質問が来る前に、資料の側で手間をかけておく」ものです。その手間には費用がかかります。

見落としやすいのは、右の列です。作る費用は一度きりではありません。社内の資料は毎日のように増え、変わります。そのたびに作り直しが発生します。「最初に1回作ってみたら良かった」だけで判断すると、運用が始まってから費用に驚くことになります。

もう1つの費用は、仕組みの複雑さです。索引の作り方が増えるほど、壊れたときの原因を探すのが大変になり、担当者の学ぶことも増えます。

索引の費用と、答えの良くなり方を比べるには、同じ質問の組で、索引を変える前と後の成績を測るしかありません（第12章）。

どれを使うか：困っている失敗から選ぶ

この章の工夫は、どれも「効く場面」がはっきりしています。流行っている手法から入れるのではなく、実際に困っている失敗から選びます。

おすすめの順番は、費用の安いものからです。まず基本の索引（第2〜5章）とハイブリッド検索（第6章）、リランキング（第7章）を整え、それでも残る失敗を見て、親子チャンクや文の窓を足します。文脈の書き足しは、その次の候補です。要約の木や GraphRAG は、全体を問う質問が多いと分かってから検討します。

どの失敗が多いのかを知るには、利用者の実際の質問と、うまく答えられなかった例を集めて分類するのが近道です。その方法は第12章で見ます。

よくある落とし穴

索引の工夫で、よくある失敗をまとめます。

3つ目の「作り直しを忘れる」は、特に要約の木と GraphRAG で起きやすい失敗です。元の資料からは古い内容が消えたのに、要約の中にだけ古い内容が残っていると、その要約が検索に当たり、古い答えが出てきます。しかも、元の資料を見ても見つからないので、原因を探しにくいのです。

要約やグラフのような「資料から作ったもの」には、どの資料のどの版から作ったかを記録しておき、元が変わったら作り直せるようにしておきます（第13章）。