RAG を設計するとき、最初に決めたくなるのは、文書をどの大きさで区切るかである。200 token なのか、500 token なのか、あるいは段落や節を単位にするのか。文書を短く切れば、一つの断片に含まれる話題が限定されるため、質問と関係する箇所を検索結果の上位へ出しやすくなる。一方で、短く切るほど、その断片だけでは主語、条件、例外、照応先が分からなくなる可能性が高くなる。
逆に、文書を長く残せば前後関係を保持できる。契約書の一つの条文だけでなく、その条文が適用される契約種別、直前に定義された用語、後続する例外規定まで同じ断片に含められる。しかし、一つの断片に複数の話題が入れば、その全体を一つの埋め込み表現へ圧縮することになる。質問がその中の一部分だけを対象としていても、検索時には断片全体の表現との近さで順位を決めることになる。
このため、チャンクサイズには単純な大小の交換関係があるように見える。短くすれば検索時の対象は限定されるが、生成時に必要な文脈を失いやすい。長くすれば文脈は残るが、検索対象として含まれる意味の範囲が広がる。そこで「検索精度と文脈保持の両方が高くなる中間のサイズ」を探すという発想が生まれる。
しかし、この発想には、検索するときに使う情報単位と、回答を作るときに LLM へ渡す情報単位を同じにするという前提が含まれている。検索では、多数の候補から質問に関係する箇所を識別して順位付けする必要がある。回答生成では、取得した箇所がどの条件で成立し、何を例外とし、他の記述とどう関係しているかまで復元する必要がある。二つの工程では、情報に要求される性質が異なる。
たとえば、利用規約から「途中解約した場合に返金されるか」を検索するとする。検索段階では、「解約」「払い戻し」「未利用期間」といった内容を含む一節を見つけられればよい。しかし、その一節に「未利用期間の料金は返金しない」とだけ書かれていて、前の節で「年間契約の場合」と対象が限定されているなら、その一節だけを LLM に渡すと適用範囲を誤る。検索自体は成功していても、生成に必要な文脈の復元に失敗している。
ここでは二つの異なる損失が起き得る。検索単位を大きくしすぎれば、質問に対応する局所的な特徴が広い文章の中へ埋もれ、必要な断片を取得できない可能性が生じる。検索単位を小さくしすぎれば、必要な断片は取得できても、その断片を正しく解釈するための周辺情報が検索結果から外れる。前者は候補選択の失敗であり、後者は意味復元の失敗である。同じ「回答が間違った」という結果に見えても、原因は別の段階にある。
RAG の原論文は、モデル内部に保持された知識だけに依存せず、外部の非パラメトリックな記憶から文書を取得し、その情報を生成へ利用する構成を示した[1]。Dense Passage Retrieval は、質問と文書断片をそれぞれ密なベクトル表現へ変換し、その類似度によって文書を検索する構成を具体化した[2]。この時点ですでに、検索時に比較されているのは文字列そのものではなく、検索のために作られた数値表現である。
既稿では、この基本構造をローカル環境へ実装し、文書を分割し、埋め込み表現を作り、質問に近い断片を取得し、その断片を LLM へ渡すまでを処理単位ごとに確認した[3]。この構成では、一つのチャンクが検索対象であると同時に、回答生成時の文脈でもある。そのため、チャンクサイズを変更すると検索性能と生成時の情報量が同時に変化する。
その後の研究を並べると、この結合を解く方向が複数の場所で現れている。質問をそのまま検索せず別の文章表現へ変換する方法がある。文書本文とは別に「この文書が答えられる質問」を検索用表現として持つ方法もある。短い単位で候補を見つけてから広い親文脈へ戻す方法、原文と要約を異なる抽象度で同時に保持する方法、回答生成の途中で新しい検索を行う方法、局所的な事実検索と資料集合全体の把握を異なる検索問題として扱う方法も提案されている。
これらは一つの手法が順番に改良されてできたものではない。それぞれが異なる失敗条件へ介入している。しかし、共通しているのは、RAG の各工程で同じ情報表現を使い続ける必然性を取り除いていることである。検索に使う表現、検索する粒度、検索後に復元する文脈、最終的に LLM へ渡す情報を分けて設計できるなら、「最適なチャンクサイズを一つ選ぶ」という問い自体を分解できる。
1. 検索する単位と、LLM に読ませる単位を同じにする必要はない
検索と生成の違いを具体的に見るため、製品マニュアルから保証条件を回答する場面を考える。文書には、保証期間、保証対象となる故障、消耗品の扱い、購入証明の要否、地域ごとの例外が別々の段落に書かれているとする。「保証期間は何年か」という質問に対して検索システムが最初に行う仕事は、これらすべてを理解することではない。多数の文書断片の中から、保証期間について書かれた候補を上位へ出すことである。
この段階では、対象を狭くできることが有利に働く。「本製品の保証期間は購入日から 1 年間です」という一文を含む短い断片なら、その断片の内容は保証期間へ集中している。これに対して、保証規定全体を一つの長い断片にすると、自然故障、消耗品、輸送費、国外利用など複数の内容が同じ検索表現へ含まれる。質問が保証期間だけを尋ねていても、検索時にはそれらをまとめた表現との類似度で順位を決めることになる。
生成段階では逆の要求が生じる。検索によって「保証期間は購入日から 1 年間」という箇所を正しく見つけても、直前に「通常の個人利用の場合」、直後に「業務利用では 90 日間」と書かれていれば、一文だけから「保証期間は 1 年」と回答するのは不十分である。取得対象としては正しかった断片が、回答根拠としては狭すぎる。
この違いを処理の流れに沿って見ると、失敗箇所を切り分けられる。第一段階では、質問と対応する候補を検索できるかが決まる。ここで候補に入らなければ、その後の LLM がどれほど高性能でも、外部文書にある根拠を使えない。第二段階では、取得した候補から回答に必要な文脈を構成できるかが決まる。検索に成功していても、適用条件や例外を含む周囲の文章を復元しなければ、生成モデルへ不完全な根拠を渡すことになる。
RAG の基本構造では、この二段階が連続している。検索によって外部文書を取得し、その取得内容を生成へ利用する[1]。DPR では、質問と文書断片をそれぞれエンコーダーでベクトルへ変換し、検索に適した類似度空間上で候補を選ぶ[2]。検索時に扱うベクトルは、文書をそのまま保存したものではない。文書の内容を、候補選択に利用できる固定長の表現へ変換したものである。
この点を一段進めると、検索表現と生成文脈を同一にする理由もなくなる。検索には、候補どうしを区別できる表現が必要である。生成には、取得した候補が成立する条件まで含めて解釈できる文脈が必要である。検索対象を狭くすることで候補選択が改善するなら、その狭い単位で検索した後に元の文書へ戻り、親となる節や隣接段落を追加してから生成モデルへ渡すことができる。
反対に、長い文脈を生成へ渡したいからといって、その長い文章全体を一件の検索対象にする必要もない。検索では短い単位を使い、取得後に広げる構成なら、検索時の識別粒度と生成時の文脈範囲を個別に調整できる。チャンクサイズを変更したときに検索精度と生成文脈が同時に動いてしまう構成から、二つを別々の設計変数として扱う構成へ移れる。
既稿のローカル RAG では、文書分割、埋め込み生成、検索、回答生成を順番に実行することで、どの断片が検索され、それがどのように回答へ利用されるかを観測できる形にした[3]。この最小構成を基準にすると、検索単位と生成文脈を分離する意味も明確になる。処理を複雑にすること自体が目的なのではなく、一つのチャンクへ課していた二つの責務を分けることで、それぞれの失敗を個別に調整できるようになる。
| 工程 | 求められる性質 | 直接的な失敗 | 回答への帰結 |
|---|---|---|---|
| 検索 | 質問に対応する候補を、多数の無関係な候補より上位へ順位付けできること。 | 必要な文書断片が検索結果へ入らない。 | 生成モデルへ根拠そのものが渡らず、外部文書に基づく回答を作れない。 |
| 文脈復元 | 取得した断片が成立する条件、例外、照応先、関連する周辺記述を補えること。 | 局所的な事実は取得できても、その適用範囲が欠ける。 | 事実そのものは正しくても、対象範囲を広げすぎた回答や条件を落とした回答になる。 |
| 生成 | 与えられた根拠の関係を読み取り、質問に対応する形へ組み立てること。 | 十分な根拠が入力されていても、内容を誤読したり根拠外の情報を加えたりする。 | 検索と文脈復元が成功していても、最終回答が根拠と一致しなくなる。 |
この分解によって、チャンクサイズの意味も変わる。チャンクは「検索から生成まで一貫して使う文章の大きさ」ではなく、検索、表現生成、文脈復元のどこで使う単位なのかを指定して初めて意味を持つ。200 token の断片を検索し、取得後に 1000 token 相当の親文脈へ戻す構成と、最初から 1000 token を一件として検索する構成は、生成時に同程度の文章量を渡していても検索過程は同じではない。
検索に適した表現と、回答生成に必要な文脈は同じでなくてよい。この命題から次に生じる問いは、「では検索用のチャンクだけについて最適な大きさを決めればよいのか」である。しかし、検索単位の大きさと、その単位の意味を作るために参照する文脈の大きさも分離できる。チャンクサイズを一つの数値で決める問題は、さらに分解できる。
2. 「最適なチャンクサイズ」を一つ決めても問題は終わらない
検索単位と生成時の文脈を分けて考えると、「何 token で区切るべきか」という問いも一つの数値には収まらなくなる。長くすれば文脈を保持できるが、検索対象としては複数の話題を含みやすい。短くすれば検索対象を限定できるが、その断片を正しく解釈するための情報が外へ出る。さらに、検索単位を短くしたまま、埋め込み表現だけには広い文脈を反映する方法もある。
つまり、チャンクサイズを決める前に、少なくとも三つの大きさを区別する必要がある。検索候補として何を一件とみなすか。その候補の意味表現を作るとき、どこまで周囲を見るか。検索後、回答生成のためにどこまで文脈を復元するか。この三つを同じ長さに固定したときに初めて、「短いか長いか」という一軸の交換関係が生じる。
2.1 長く入力できることと、長い文脈を使えることは違う
文脈を失うことだけが問題なら、文書を細かく切らず、利用可能なコンテキストウィンドウへできるだけ多く入れる方法が考えられる。長い入力を受け取れる LLM なら、検索によって情報を絞らなくても、関連箇所を入力内部から見つけて回答できるようにも見える。
しかし、この構成では「入力できること」と「必要な情報を利用できること」が同じ能力であると仮定することになる。たとえば 100 ページ分の資料が入力可能であっても、その中にある一つの契約条件を、周囲の無関係な記述に影響されず取り出せるとは限らない。コンテキストウィンドウの大きさは、モデルへ渡せる情報量の上限を決める。一方、回答に必要なのは、その大量の情報から質問に関係する部分を識別し、他の記述との関係を保ったまま利用する能力である。
Lost in the Middle は、この差を情報の配置という条件から調べた。評価対象となった長文コンテキストモデルでは、関連情報が入力の先頭や末尾にある場合と比べ、中央付近に配置された場合に性能が低下する傾向が確認された[4]。入力内容そのものを変えず、必要情報の位置を変えるだけで結果が変わるなら、コンテキストへ情報を格納できたことだけでは、その情報を同程度に利用できるとは言えない。
この結果から直ちに「長いコンテキストは使えない」と結論することもできない。調査対象となったモデル、課題、入力長に依存する結果であり、モデルの改良によって位置依存性が変化する可能性もある。直接確認できるのは、コンテキスト容量だけを見て情報利用性能を推定することはできない、という範囲である。
Retrieval meets Long Context Large Language Models は、検索と長文コンテキストを単純な代替技術として置かず、検索による情報選択と長い入力を組み合わせる条件も比較した[5]。この比較が示す論点は、検索と長文入力が別の場所へ作用していることである。長いコンテキストは、一度に保持できる情報量を増やす。検索は、その中でも質問に関係する情報を選ぶ。前者を改善しても、後者の役割が自動的に消えるわけではない。
| 能力 | 決まること | それだけでは決まらないこと |
|---|---|---|
| コンテキスト容量 | 一回の推論でモデルへ渡せる情報量の上限が決まる。 | 入力された情報のうち、質問に必要な部分を安定して選択できるかは決まらない。 |
| 検索 | 大きな情報集合から、質問に関係する候補を事前に絞り込める。 | 取得した断片だけで回答に必要な条件や前後関係が揃うとは限らない。 |
| 文脈復元 | 検索された候補から、回答に必要な周辺情報を追加できる。 | 増やした情報を生成モデルが必ず正しく利用するとは限らない。 |
長文入力、検索、文脈復元は、同じ問題に対する三つの名前ではない。容量、選択、意味の復元という異なる段階へ作用する。長いコンテキストウィンドウが利用可能になっても、どの情報を選んで渡すかという設計問題は残る。
2.2 短く切るほど検索が良くなるわけでもない
長い入力だけでは情報選択の問題が残るなら、検索対象をできるだけ細かくすればよいように見える。一つの断片に含まれる話題が少なければ、その断片が何について書かれているのかを埋め込み表現へ反映しやすい。質問との対応も局所化できる。
Dense X Retrieval は、この検索単位そのものを実験対象にした。一般的な文書断片より細かい命題（proposition）を検索単位として扱い、どの粒度で情報を索引するかが検索性能へ影響することを検証している[6]。文書分割は、モデルへ入力できる長さに合わせるだけの機械的な前処理ではなく、検索器が何を一件の候補として比較するかを決める処理になる。
ただし、細粒度化には別の失敗条件がある。たとえば「解約日から 30 日以内に返送すること」という一文が検索されたとしても、その直前に「貸与機器がある場合」と書かれていれば、前の一文を失った時点で条件が変わる。検索器から見れば「30 日以内」という必要箇所を正しく取得できている。それでも回答生成では、「すべての利用者が 30 日以内に返送する必要がある」という過剰な一般化につながり得る。
この失敗は、検索精度だけを高めても解消しない。断片を細かくすると、検索対象としての意味は狭くできる。その一方で、意味の成立条件が断片境界の外へ出る確率も高くなる。検索時に有利な分割と、解釈時に必要な範囲が一致しなくなるためである。
そこで、検索単位を細かく保ちながら、検索表現を作る段階では広い文脈を見るという設計が現れる。Late Chunking は、文書を最初から独立した小断片として埋め込むのではなく、まず長い文書をエンコーダーへ入力し、その出力から後でチャンク単位の表現を作る[7]。検索結果として扱う単位は短くても、その表現は周囲から完全に切り離されていない。
たとえば同じ「30 日以内」という語句でも、「契約解除後 30 日以内」と「貸与機器を 30 日以内に返却」のどちらなのかは周囲の文章によって決まる。断片だけを独立に埋め込む場合、この違いを短い文字列だけから表現しなければならない。広い文脈を読んだ後で断片表現を作れば、その断片が文書中で担っている意味をベクトルへ反映できる余地が増える。
Context is Gold to find the Gold Passage も、対象文書断片を周辺から独立して表現する場合と、文書レベルの文脈を考慮して表現する場合を比較し、文脈依存の検索課題で文脈化された文書埋め込みを検証している[8]。この研究系列が分離しているのは、検索結果として返す単位と、その単位の意味を計算するときに参照する範囲である。
この区別を入れると、「短いチャンクは文脈を失う」という説明も精密になる。失われる可能性があるのは二種類ある。検索表現を作る時点で周囲を切り捨てれば、その断片が何を意味しているかという情報が表現から失われる。さらに検索後もその断片だけを LLM へ渡せば、回答を組み立てるための条件や例外が生成文脈から失われる。前者は検索表現の問題であり、後者は文脈復元の問題である。
2.3 長い検索単位が有効になる条件もある
検索表現へ広い文脈を反映できるとしても、すべての検索を細粒度化すべきだという結論にはならない。質問自体が複数の記述にまたがる場合には、一件の検索単位を長くする方が合理的なこともある。
LongRAG は、細かな断片を大量に検索する構成とは逆に、より長い検索単位を使う方法を提案している[9]。短いチャンクへ分割すると、一つの回答に必要な情報が複数候補へ散らばり、それらを後段で再結合しなければならない。検索単位を長くすれば、関連情報を一つの候補内に保持できる可能性が高くなる。
たとえば「この契約で途中解約した場合、返金と機器返却はそれぞれどうなるか」という質問では、返金規定と返却規定が隣接する複数段落に書かれているなら、それらを含む長い単位を一度に取得する方が後段の統合は単純になる。細かく分割した場合には、返金規定だけ取得して返却規定を落とす、あるいは二つを別々に取得したものの関係を生成段階で誤る、といった失敗経路が増える。
一方、長い検索単位には、無関係な記述まで同じ候補へ含めるという代償がある。局所的な事実だけを探す質問では、細かい単位の方が候補を識別しやすい場合がある。LongRAG が示すのは「長い方が正しい」という一般則ではなく、細かいチャンクへ分割することにも再結合コストと情報分散という負担があることである。
この点まで含めると、チャンクサイズは一つの数値として最適化する対象ではなくなる。同じ文書集合でも、局所的な事実を探す質問と、複数箇所をまとめる質問では有利な検索単位が異なり得る。さらに、その検索単位と埋め込み表現に利用する文脈、生成時に復元する文脈も別々に設定できる。
| 設計対象 | 決めること | 小さくした場合の利点と失敗 | 大きくした場合の利点と失敗 |
|---|---|---|---|
| 検索単位 | 何を一件の検索候補として順位付けするか。 | 局所的な意味を識別しやすいが、一つの回答に必要な情報が複数候補へ分散しやすい。 | 関連情報を一件に保持しやすいが、複数の話題や無関係な記述が同じ候補へ混入しやすい。 |
| 表現に使う文脈 | 検索候補の意味を計算するとき、どこまで周囲を参照するか。 | 候補単体の特徴へ集中できるが、照応先や適用条件を表現から失いやすい。 | 周囲との関係を表現へ反映できるが、より長い入力を扱えるエンコーダーと計算量が必要になる。 |
| 生成へ渡す文脈 | 検索後、回答生成のためにどこまで情報を復元するか。 | 入力ノイズを抑えられるが、条件や例外が欠落すると回答の適用範囲を誤る。 | 意味関係を保持しやすいが、無関係な情報が増えれば生成側で必要箇所を選ぶ負荷が増える。 |
この三つを区別すると、「小さいチャンク」と「広い文脈」は両立できる。短い単位を検索候補にしながら、検索表現には文書全体の情報を反映し、取得後には親節や隣接段落まで戻して LLM へ渡すことができる。逆に、質問の性質によっては最初から長い検索単位を使う選択もできる。
ここまでで、チャンクサイズという一つの数値にまとめられていた問題は、検索単位、表現を作る文脈、生成へ返す文脈という三つの設計変数へ分かれた。この分離をさらに進めると、次の前提も不要になる。検索に使う表現そのものを、原文と同じ文章にしておく必要はない。
3. 質問と文書は、同じ意味でも同じ文章ではない
検索単位と生成文脈を分けても、検索そのものには別の難しさが残る。質問と、その答えを含む文書は、意味的に対応していても同じ語彙や文型で書かれているとは限らないからである。「途中解約した場合に返金されるか」という質問に対し、規約には「契約期間中に利用を終了した場合であっても、未利用期間に相当する料金の払い戻しは行わない」と記載されているかもしれない。質問には「解約」「返金」という語があり、文書には「利用を終了」「払い戻し」という語がある。人間なら対応関係を読めるが、検索器はその対応を数値表現の近さとして扱わなければならない。
このずれは、単なる同義語の問題だけではない。質問は通常、「何を知りたいか」を短く表す。これに対して文書は、説明、規則、報告、定義などの形式で「何が成り立つか」を記述する。同じ事実を指していても、質問側と文書側では文の役割が違う。そのため、質問と文書をそのまま同じ埋め込み空間へ置くだけでは、意味的な対応が十分に近くならない場合がある。
この表現差へ介入する方法の一つが、検索前に質問側を変換することである。Generation-Augmented Retrieval は、入力された質問から回答、文、タイトルなどの生成表現を作り、それらを検索へ利用した[10]。質問そのものだけで検索するのではなく、「その質問に対応する文書には、どのような内容が書かれていそうか」を生成によって補う構成である。
この方法が変えているのは、検索対象となる文書ではない。質問と文書を比較する前に、質問側の表現を検索向けに広げている。元の質問が短く、文書側の表現形式と離れていても、生成された補助表現に文書側と共通する語彙や説明形式が含まれれば、検索器が対応関係を捉えやすくなる可能性がある。
3.1 質問を、文書に近い表現へ変換する
HyDE は、この考え方をさらに明確な形にした。入力された質問から LLM に仮想文書を生成させ、その仮想文書を埋め込み表現へ変換し、実在する文書を検索する[11]。処理の流れは、質問と実文書を直接比較するのではなく、質問をいったん文書形式へ写してから比較する構成になる。
たとえば「途中解約した場合に返金されるか」という質問に対し、仮想文書として「契約期間中に解約した場合、未利用期間に相当する料金は返金されない」といった文章が生成されたとする。この文章が正しい事実である必要はない。検索段階で必要なのは、実際の規約に現れそうな語彙、文型、説明形式を持つ表現を作り、それを使って関連文書を探すことである。
この構造では、生成された内容と回答根拠の役割が明確に分かれる。仮想文書は検索器を実文書へ誘導するための中間表現であり、最終回答の証拠ではない。仮想文書の内容が一部誤っていても、それによって適切な実文書へ到達できれば、回答生成時には実文書を根拠として利用できる。
逆に、仮想文書をそのまま回答根拠として扱えば、この利点は失われる。生成内容には事実誤認が混ざる可能性があるため、検索補助として使う情報と、回答を正当化する証拠を混同すると、検索用に導入した生成結果が新しい誤りの原因になる。HyDE の構造上の意味は、LLM が作った文章を信頼することではなく、検索表現として利用した後に実文書へ戻るところにある。
| 段階 | 入力 | 出力 | 役割 |
|---|---|---|---|
| 質問入力 | 利用者が知りたい内容を短い質問として与える。 | 自然言語の質問が得られる。 | 情報要求そのものを表す。 |
| 仮想文書生成 | 元の質問を LLM へ与える。 | 答えを含みそうな文書形式の文章が得られる。 | 質問と実文書の表現差を縮める検索用の中間表現になる。 |
| 実文書検索 | 仮想文書の埋め込み表現を使う。 | 実在する文書候補が取得される。 | 回答に利用できる根拠へ到達する。 |
| 回答生成 | 取得した実文書を利用する。 | 質問への回答を生成する。 | 検索用の仮想文書ではなく、取得した根拠に基づいて結論を作る。 |
この分離によって、「質問をそのまま検索しなければならない」という制約が外れる。検索器へ渡す質問は、利用者が入力した文字列そのものでなくてもよい。実文書へ到達しやすい表現へ変換した上で検索し、根拠だけは元の文書から取得することができる。
3.2 逆に、文書を質問の形へ変換する
質問と文書の表現差を埋めるなら、変換方向は逆でもよい。質問を文書へ近づける代わりに、文書側へ「この内容なら、どのような質問に答えられるか」という別表現を持たせる方法である。
HyQE は、取得された候補文脈から仮想質問を生成し、実際の質問とその仮想質問との類似度を使って候補文脈を再順位付けする[12]。たとえば規約に「未利用期間に相当する料金の払い戻しは行わない」と書かれていれば、「途中解約時に返金はあるか」「契約期間を残して解約した場合の料金はどうなるか」といった質問表現を生成できる。実際の利用者の質問は、規約本文よりも、こうした仮想質問の方に文章形式として近い。
HyDE と HyQE は、どちらも質問と文書の表現差へ介入するが、処理の方向は反対である。HyDE は実際の質問を文書に近い形式へ変換する。HyQE は取得済みの候補文脈から質問に近い形式を生成し、その類似度で候補を再順位付けする。どちらも「意味が同じなら生の質問と生の文書を直接比較すれば十分だ」という前提を外している。
HyPE は、この文書側の変換を索引作成時に行う[13]。各文書断片から複数の仮想プロンプトを事前生成し、それらを検索用表現として保持する。実際の質問が来るたびに文書側の表現を作り直すのではなく、文書登録時に「この断片が答えられる質問の候補」を作っておく構成である。
この違いは、運用時の計算位置にも影響する。質問ごとに仮想文書を生成する HyDE では、検索要求が発生するたびに生成処理が必要になる。文書側の仮想質問を事前生成する方式では、索引作成時の計算量と保存量は増えるが、検索時には既存の質問表現と実際の質問を比較できる。表現変換の方向を変えることは、検索精度だけでなく、計算をいつ実行するかというシステム設計にもつながる。
| 方式 | 変換方向 | 主な変換時点 | 検索時の対応関係 | 構造上の特徴 |
|---|---|---|---|---|
| Generation-Augmented Retrieval | 質問から回答候補、文、タイトルなどの補助表現を生成する。 | 検索要求を受けた後に行う。 | 元の質問と生成表現を利用して実文書を検索する。 | 短い質問を生成情報で拡張し、文書側との表現差を小さくする。 |
| HyDE | 質問から仮想文書を生成する。 | 検索要求を受けた後に行う。 | 仮想文書の埋め込み表現と実文書を比較する。 | 質問を文書に近い形式へ写し、最終的な根拠は実文書から取得する。 |
| HyQE | 取得された候補文脈から仮想質問を生成する。 | 取得候補を再順位付けする段階で行う。 | 実際の質問と、候補文脈から生成した仮想質問を比較する。 | 候補文脈を質問に近い形式へ写し、類似度で再順位付けする。 |
| HyPE | 文書断片から複数の仮想質問を生成する。 | 索引作成時に行う。 | 実際の質問と事前生成済みの複数の質問表現を比較する。 | 検索時の生成負荷を事前処理へ移し、一つの文書断片へ複数の検索入口を持たせる。 |
この四つを一括して「仮想質問を使う RAG」と捉えると、設計上の違いを見失う。変換されるのが質問なのか文書なのか、変換を検索時に行うのか索引作成時に行うのか、生成された文章を何と比較するのかによって、計算量、保存量、更新方法、誤りの入り方が変わる。
たとえば文書が頻繁に更新される環境では、文書ごとに複数の仮想質問を事前生成する方式は、更新のたびに再生成と再索引が必要になる。一方、HyDE のように質問ごとに生成する方式では文書更新の影響は比較的小さいが、検索要求ごとに LLM 推論が発生する。検索表現の設計は、精度だけでなく、どの処理をオンラインで実行し、どの処理を事前計算するかという運用条件まで含んでいる。
もう一つの制約は、生成された代理表現の品質である。文書から作った仮想質問が、その文書で実際に答えられる範囲を越えていれば、関係の薄い質問を引き寄せる可能性がある。質問から作った仮想文書も、質問の意図を誤れば別の領域の文書へ検索を誘導する。代理表現を追加すると検索経路は増えるが、その生成誤差も検索結果へ伝播する。
それでも、この研究系列から得られる構造は明確である。検索用の表現は、原文や利用者の質問そのものである必要がない。検索に有利な中間表現を作り、そこから実際の根拠へ戻れるなら、質問と文書の間に複数の表現層を置くことができる。
第 2 章では、検索単位、表現を作る文脈、生成へ返す文脈を分離した。ここではさらに、検索時に比較する文章そのものも分離できることが分かった。RAG の検索処理は、原文を一度ベクトル化して終わる固定的な処理ではなく、質問と文書の間にどの表現を置くかを設計する処理になる。
次に残るのは時間方向の制約である。検索表現を変えられるなら、その検索を回答の最初に一度だけ行う必要があるのか。複雑な質問では、途中まで得られた情報によって次に必要な検索対象が初めて決まることがある。検索時点そのものも、固定された前処理から分離できる。
4. 検索は回答の最初に一度だけ行う必要もない
ここまで、検索単位、検索表現、生成へ返す文脈を別々の設計対象として見てきた。もう一つ固定されやすいものがある。検索を実行する時点である。単純な RAG では、利用者の質問を受け取ると最初に検索し、取得した文書を LLM へまとめて渡し、その後は追加検索をせず回答を生成する。この構成では、最初の質問だけから「回答に必要な情報をすべて特定できる」ことが暗黙の前提になる。
一つの事実を尋ねる質問なら、この前提でも処理できる。「企業 A の 2025 年度売上はいくらか」であれば、売上高を含む文書を最初の検索で取得できればよい。しかし、「制度変更によって企業 A の収益構造がどう変わったか」のような質問では、最初から必要な検索語を列挙できるとは限らない。制度の変更内容を読まなければ、影響を受ける商品、地域、契約形態が分からず、企業側のどの情報を次に調べるべきかも確定しないからである。
たとえば、制度変更の資料を検索した結果、「特定地域で提供される従量課金サービスだけが新しい規制の対象になる」と分かったとする。その時点で初めて、企業 A について調べるべき情報を「全社売上」から「対象地域の従量課金サービスの売上比率」へ狭められる。さらに、その比率を調べた結果、企業 A が長期契約によって価格変動を一部吸収していると分かれば、次には契約更新時期を調べる必要が生じる。最初の検索結果が、次の検索条件を決めている。
この場合、失敗は二段階で起こり得る。第一に、最初の質問だけで関連しそうな文書を大量に集めようとすると、まだ必要性が判明していない情報まで検索対象に含めるため、取得結果のノイズが増える。第二に、最初の検索結果だけで回答を完結させようとすると、制度変更を読んだ後に初めて判明した追加の情報要求を処理できない。前者は検索範囲を早すぎる段階で広げる失敗であり、後者は情報要求の更新を認めない失敗である。
4.1 生成途中の状態から、次の検索を決める
FLARE は、この時間方向の固定を外す能動検索を提案した[14]。回答生成の前に一度だけ検索を済ませるのではなく、生成を進めながら、これから述べる内容に追加情報が必要になった時点で検索を実行する。検索の判断材料になるのは、利用者が最初に入力した質問だけではなく、そこまでに生成されている内容と、次に生成しようとしている内容である。
この構成では、検索質問も固定されない。最初の質問が「制度変更は企業 A にどう影響したか」だったとしても、生成途中で「対象となるのは従量課金サービスである」と判明すれば、次の検索は「企業 A の従量課金サービス比率」のような、より具体的な情報要求へ変わる。最初の質問をそのまま繰り返して検索するのではなく、途中まで得た知識によって質問の意味を更新できる。
FLARE の設計上の特徴は、検索回数を増やすこと自体にはない。検索を必要とする箇所を生成過程の中で判断する点にある。あらゆる文を生成するたびに検索すれば、計算量と待ち時間が増え、大量の無関係な文書が文脈へ流入する。逆に、最初の一回だけに固定すれば、生成途中で判明した情報不足を補えない。検索する時点を制御対象にすることで、この二つの間を調整できる。
4.2 検索結果を使った生成が、次の検索を変える
Iter-RetGen は、検索と生成を反復させる別の構成を示している[15]。ある検索結果から生成した内容を次の検索に利用し、そこで得た情報を使って再び生成する。処理は一方向の「検索してから生成する」ではなく、検索と生成が互いの入力を更新する循環になる。
この構造が効くのは、情報要求を一回の質問に展開しきれない場合である。複数の文書にまたがる問いでは、最初の検索によって一つの中間事実を得、その事実を使わなければ次の根拠を特定できないことがある。制度の対象範囲を調べ、その結果から企業の対象事業を特定し、その事業について契約条件を調べるという流れがその例になる。
ここでは生成が最終回答を作る処理だけではなく、次の検索を具体化する処理にもなる。検索によって外部情報を取得し、その情報を生成過程で整理する。その生成結果によって次の情報不足が明確になり、新しい検索を実行する。この循環によって、最初には明示されていなかった検索経路を段階的に形成できる。
| 構成 | 検索質問の決まり方 | 検索時点 | 失敗しやすい条件 |
|---|---|---|---|
| 一回検索型 RAG | 最初に与えられた質問を中心に決まる。 | 回答生成を始める前に実行する。 | 最初の質問だけでは後続する情報要求を特定できない場合、必要な根拠を取得し損なう。 |
| FLARE | 生成途中でこれから必要になる内容を利用して検索要求を作る。 | 生成過程で追加情報が必要になった箇所に応じて実行する。 | 検索判断が過剰なら待ち時間と取得ノイズが増え、不足すれば根拠のない生成区間が残る。 |
| Iter-RetGen | 前段の検索結果と、それを使って生成した内容から次の検索を更新する。 | 検索と生成を複数回反復する。 | 途中の生成が誤れば、その誤った中間結果が次の検索方向にも影響する。 |
4.3 検索を繰り返せばよいわけでもない
検索時点を可変にすると、最初の質問だけでは解けない質問を段階的に扱える一方、新しい失敗経路も生じる。一つは計算量である。一回検索型なら検索と LLM 推論の回数を事前に見積もりやすいが、反復型では質問によって検索回数が変わる。外部 API を利用する構成では、検索と生成を追加するたびに待ち時間と利用コストも増える。
もう一つは、途中の誤りが次の検索へ伝播することである。最初の検索結果を LLM が誤って解釈し、「企業 A の主要事業は対象地域に集中している」と誤った中間結果を作れば、その内容を使った次の検索も誤った方向へ進む可能性がある。一回検索型では生成誤りが最終回答に現れるだけで済む場合でも、反復型では生成誤りが次の証拠収集まで変える。
このため、反復検索では「検索を増やせること」と同時に「いつ反復を止めるか」「どの中間結果を次の質問に使うか」「取得した根拠と生成された推測をどう区別するか」が必要になる。検索時点を設計変数に加えると、RAG は単なる情報取得処理から、状態を更新しながら次の情報取得を決める制御系へ近づく。
ただし、検索回数を増やしても、一つの情報をどの抽象度で保持するかという問題は残る。個別の事実を大量に取得しても、「これらの記述に共通する主題は何か」という問いには、そのままでは答えにくい。次に、原文の細部と、それらをまとめた上位の要約を同じ検索構造の中に持つ方法を見る。
5. 情報には一つの正しい粒度ではなく、複数の抽象度がある
検索単位を細かくしたり、検索後に広い親文脈へ戻したりすれば、局所的な情報と前後関係を両立できる。しかし、文書に含まれる情報の違いは「短いか長いか」だけではない。同じ資料について、原文に近い具体的な事実と、それらをまとめて初めて得られる上位の説明が存在する。
たとえば契約書には、「第 12 条では利用開始後の任意解約を認めない」「第 13 条では一定の例外条件を定める」「第 14 条では違約金を規定する」といった個別の記述がある。これらはそれぞれ検索可能な事実である。一方、「この契約は利用者都合による中途解約を強く制限している」という説明は、どれか一文をそのまま抜き出したものではない。複数の条項をまとめ、それらの共通する方向を抽象化した結果として得られる。
この違いは、単純なチャンクサイズの違いとは異なる。1000 token の原文を保持したからといって、その中に含まれる複数の規定の関係が自動的に「中途解約を強く制限する契約」という表現へ変わるわけではない。長い原文は情報量を増やすが、上位概念を明示的に作る処理とは別である。ここで必要になるのは、粒度だけでなく抽象度という軸である。
5.1 RAPTOR は原文と要約を階層として同時に保持する
RAPTOR は、この抽象度の違いを検索構造そのものへ組み込む[16]。最下層には原文に近いテキスト断片を置き、それぞれを埋め込み表現へ変換する。次に、意味的に近い断片をクラスタリングし、同じクラスタに属する複数の断片を LLM で要約する。その要約を新しいノードとして扱い、さらに上位でも同様のクラスタリングと要約を繰り返す。
この処理によって、一つの文書集合から複数の情報表現が作られる。下位層には「誰が、いつ、何をしたか」といった具体的な記述が残り、その上には複数の記述をまとめた説明が置かれ、さらに上位には複数の説明に共通する主題が置かれる。同じ資料について、原文に近い詳細と、段階的に抽象化された要約を同時に検索対象へできる。
たとえば、企業の複数年の決算資料を考える。「2025 年度の海外売上比率は何 % か」という質問なら、その数値を含む下位ノードを取得する方が直接的である。これに対して「この企業は数年間でどの市場への依存を強めてきたか」という質問では、複数年度の記述をまとめた上位ノードの方が問いの粒度に近い場合がある。一つの検索単位の大きさを変更するだけでは、この二種類の情報要求を同時には表現しにくい。
RAPTOR の意味は、原文を要約へ置き換えることにはない。要約だけを保存すれば、具体的な数値、固有名詞、条件などが圧縮の過程で失われる可能性がある。逆に原文だけを保存すれば、複数箇所に分散した記述の共通性を検索時に捉えるには、取得後の統合へ大きく依存する。原文と要約を異なる層として残すことで、詳細を失わずに上位概念への検索経路も持たせる。
| 情報層 | 保持する内容 | 適合しやすい質問 | 単独で使った場合の弱点 |
|---|---|---|---|
| 原文に近い下位ノード | 具体的な数値、条件、固有名詞、個別の出来事を細かく保持する。 | 特定の値、条項、日時、人物などを尋ねる局所的な質問に対応しやすい。 | 複数箇所にまたがる傾向や共通テーマを、一件の検索結果として表現しにくい。 |
| 中間的な要約ノード | 複数の関連断片をまとめ、一つの話題や関係として表現する。 | 一つの節や複数の関連事実について概要を尋ねる質問に対応しやすい。 | 要約過程で細かな条件や例外が省略される可能性がある。 |
| 上位の要約ノード | 複数の話題に共通する主題や大きな構造を圧縮して保持する。 | 長い資料全体の傾向、主要テーマ、複数部分の共通性を尋ねる質問に対応しやすい。 | 具体的な根拠へ戻らなければ、細部の検証や条件付きの回答には情報が不足する。 |
この階層化によって、「検索する文章と LLM に読ませる文章は同じでなくてよい」という命題が、別の方向から具体化される。上位要約を使って関連する領域を見つけても、最終回答で細かな事実が必要なら、その下位にある原文を参照できる。反対に、複数の原文断片だけでは問いの範囲が広すぎる場合には、それらをまとめた上位表現を検索へ利用できる。
5.2 「長いチャンク」と「高い抽象度」は同じではない
ここで、前章まで扱ってきた粒度と抽象度を区別する必要がある。長いチャンクは、単に多くの原文を一つの検索単位へ入れたものである。上位要約は、その原文に含まれる情報を選択し、共通する意味関係を別の文章として再構成したものである。文字数が同程度でも、二つは情報の作られ方が違う。
たとえば、5 つの製品レビューをそのまま連結した 2000 token の文章と、「5 件に共通して性能は高く評価される一方、重量が欠点として繰り返し指摘された」という 100 token の要約を比較すると分かりやすい。前者には個別の詳細が多く残る。後者には情報量は少ないが、複数のレビューにまたがる共通性が明示されている。「レビュー 3 で指摘された不具合は何か」という質問には前者が必要であり、「全体として何が長所と短所か」という質問には後者の方が直接的である。
このため、検索設計で考えるべきなのは「短いか長いか」だけではない。ある情報が原文なのか、複数の原文をまとめた要約なのか、さらに複数の要約を統合した上位概念なのかによって、同じ質問との意味的な距離が変わる。検索対象の文字数と、そこに含まれる抽象化の程度を別々に考える必要がある。
5.3 検索で見つけた単位から、回答に必要な単位へ戻す
階層を利用する方法は、RAPTOR のように要約ノードを新しく作る場合だけではない。既存の文書構造を利用し、細かい単位で検索してから、その親となる広い文脈へ戻す方法もある。
LlamaIndex の AutoMergingRetriever は、この構造を実装した例である[17]。文書を親子関係を持つノードとして保持し、最初は細かい子ノードを検索する。取得された子ノードが同じ親の下へ一定以上集中した場合には、それらを個別に返し続ける代わりに親ノードへまとめる。
たとえば、一つの「解約」節が 5 個の子チャンクへ分割されているとする。質問に対してそのうち 4 個が検索結果へ入ったなら、4 個を別々の断片として LLM へ渡すより、それらを含む「解約」節全体へ戻した方が、重複を減らしながら前後関係も保持できる。検索では細粒度の識別能力を利用し、生成時には元の文章構造を利用して意味を復元する。
ここには二段階の選択がある。最初の検索では、どの局所的な断片が質問と関係するかを判断する。その結果を見て、複数の関連断片が同じ親文脈に集中しているなら、回答時にはより広い親を利用する。検索前に「この質問には親節が必要だ」と決めるのではなく、検索結果から必要な文脈範囲を後から調整する。
ただし、親へ戻せば常に良くなるわけではない。親ノードが非常に大きければ、検索には不要だった別の話題まで生成文脈へ入る。反対に、閾値を高くしすぎれば、複数の子ノードが関連しているにもかかわらず親へ統合されず、断片的な文脈のまま残る。AutoMergingRetriever の閾値は、この交換関係を調整する実装上の設定であり、あらゆる文書と質問に通用する普遍的な定数ではない。
| 構成 | 検索時に使うもの | 検索後に行うこと | 主な利点 | 主な失敗条件 |
|---|---|---|---|---|
| 単一粒度の検索 | 固定サイズのチャンクを使う。 | 取得したチャンクをそのまま利用する。 | 構成が単純で、検索結果と生成入力の対応を追いやすい。 | 検索に適した粒度と回答に必要な文脈が異なる場合、どちらかを犠牲にしやすい。 |
| 親子型の文脈復元 | 細かい子ノードを使う。 | 取得状況に応じて親ノードへ戻す。 | 局所的に検索しながら、生成時には広い原文文脈を利用できる。 | 親が大きすぎれば無関係な情報が増え、統合条件が不適切なら必要な文脈へ戻れない。 |
| RAPTOR 型の階層表現 | 原文に近いノードと、複数段階の要約ノードを使う。 | 質問の範囲に応じて異なる抽象度から情報を取得する。 | 局所的な事実と、複数断片にまたがる上位概念の双方へ検索経路を持てる。 | 要約が重要な条件を落とせば上位ノードの表現自体が不完全になり、索引作成にも追加の計算が必要になる。 |
5.4 階層を作ると、要約の誤差も索引へ入る
複数の抽象度を持つと検索経路は増えるが、上位表現には原文にはなかった新しい誤差経路も生じる。要約は情報を圧縮する処理なので、何を残し、何を省略するかという判断が必ず入る。原文では例外条件が明記されていても、上位要約が「原則として解約不可」とだけまとめれば、例外を尋ねる質問に対して上位ノードが不十分な表現になる可能性がある。
さらに、その要約を使って次の階層を作れば、下位で失われた情報は上位へも引き継がれる。一段目の要約で条件を落とし、二段目で複数の要約をさらに統合すれば、最上位のノードは原文からかなり離れた表現になる。階層化は抽象的な質問を検索しやすくする一方、要約誤差を複数段階へ伝播させる可能性を持つ。
この制約があるため、上位表現と原文を役割分担させる意味がある。上位ノードは「どの領域を見るべきか」を探すために有効でも、具体的な数値や条件を確定するときには下位ノードや原文へ戻る必要がある。検索用の代理表現と最終的な根拠を分離する考え方は、HyDE や HyQE だけでなく、階層型の検索にも現れる。
ここまでなら、質問に適した粒度や抽象度を選べばよいように見える。しかし、次には別の違いが現れる。「第 12 条の条件は何か」という質問と、「この契約全体では利用者にどのような制約が課されているか」という質問では、必要な情報量が違うだけではない。後者では、資料の複数部分を横断して全体構造を組み立てなければならない。検索する情報の範囲そのものが変わる。
6. 一か所を探す質問と、全体を理解する質問は同じ検索問題ではない
ここまで、検索する単位、検索表現、検索時点、抽象度を分けてきた。しかし、もう一つ大きな違いがある。質問そのものが、どの範囲の情報を要求しているかである。「企業 A の 2025 年度売上はいくらか」という質問と、「企業 A は数年間でどの事業へ重点を移してきたか」という質問では、必要な情報量が違うだけではない。前者は一つの根拠箇所へ到達できれば答えられる可能性が高いが、後者では複数年度、複数事業、複数の経営判断を横断し、その関係をまとめなければならない。
局所的な質問では、検索器の主な仕事は「答えが書かれている場所を見つけること」である。決算資料に「売上高 1,250 億円」と書かれているなら、その箇所を取得し、年度や連結・単体といった周辺条件を確認すれば回答できる。検索対象と質問の対応関係が比較的直接的であり、最類似候補の上位に正しい証拠を入れられるかどうかが重要になる。
これに対し、「主要な経営テーマは何か」という質問では、答えに相当する一文が存在しないことがある。2023 年の資料には海外展開、2024 年には高採算事業への集中、2025 年には不採算事業の撤退が書かれているかもしれない。個々の記述は別の文書、別のページ、別の表現で現れる。それらを「収益性を優先した事業ポートフォリオの再編」という上位の説明へまとめるには、複数の証拠を横断して共通構造を抽出する必要がある。
ここで単純な top-k 検索には構造上の限界が現れる。ベクトル検索は通常、質問と各候補の類似度を個別に計算し、近いものから順位を付ける。そのため「この企業の主要テーマ」という広い質問に対して、個々の文書断片が部分的にしか対応しない場合、関連する断片が広く分散する。上位 5 件を取っても一つの時期や一つの事業へ偏り、全体像を構成するのに必要な別の領域が落ちる可能性がある。
この失敗は、top-k の値を増やすだけでも解消しない。取得件数を 5 件から 50 件へ増やせば、必要な証拠が入る可能性は高くなるが、同時に無関係な断片や重複も増える。生成モデルは、その大量の入力から主要テーマを再構成しなければならない。検索段階で構造化されていなかった「どの記述どうしが同じ話題に属するか」という関係を、回答生成時に初めて推定することになる。
6.1 GraphRAG は「最も近い断片」ではなく、資料全体の構造を事前に作る
Microsoft Research の GraphRAG は、このような資料集合全体の構造把握を従来型 RAG が苦手とする問題として扱った[18]。文書からエンティティと関係を抽出してグラフを構築し、グラフ上で関連の強い部分をコミュニティとしてまとめ、それぞれのコミュニティについて要約を生成する。検索時に初めて全資料を横断するのではなく、索引作成の段階で資料集合の構造を別の表現として持たせる。
たとえば数年分の企業資料から、「海外事業」「クラウドサービス」「不採算店舗」「設備投資」「人員再配置」といったエンティティや関係が抽出されたとする。グラフ上で海外事業とクラウドサービスが一つのコミュニティに集まり、不採算店舗と人員再配置が別のコミュニティに集まるなら、資料全体には複数のまとまりがあることが検索前から表現される。Global Search では、これらのコミュニティ要約を使って、個別断片を一件ずつ並べるより上位の問いへ回答する。
この構成が変えているのは検索アルゴリズムだけではない。索引そのものが、原文チャンクの集合から「エンティティ、関係、コミュニティ、コミュニティ要約を持つ構造」へ変わっている。局所的な質問に対しては一つの根拠を探す検索で足りても、全体的な質問では「どの情報群が互いに関係し、それぞれ何を表しているか」を事前に持っていることが有利になる。
因果関係を分けて見ると分かりやすい。第一に、全体質問は複数箇所へ分散した証拠を必要とするため、単一候補との類似度だけでは情報要求全体を表現しにくい。第二に、候補を大量取得して後から LLM にまとめさせると、検索側で表現できなかった構造を生成側だけで復元する負担が増える。GraphRAG は、その構造化の一部を索引作成時へ移している。
6.2 Local Search と Global Search では「何が関連情報か」の定義が違う
局所検索と全体検索の違いは、検索範囲の大小だけではない。何を関連情報とみなすかが違う。Local Search では、特定の人物、企業、製品、出来事などを起点に、そのエンティティと直接関係する記述を集める。質問が「企業 A は企業 B をいつ買収したか」であれば、企業 A、企業 B、買収イベント、その日時に近い情報が重要になる。
Global Search では、個々のエンティティとの近さだけでは十分ではない。「この資料群で繰り返し現れる論点は何か」という質問なら、特定エンティティが一件だけ強く関連することより、複数のコミュニティで何が繰り返され、どのテーマが資料全体を占めているかが重要になる。局所的な関連性と、資料全体での代表性は別の尺度である。
現行の Microsoft GraphRAG 公式ドキュメントでも、検索モードは一つへ統一されていない。Global Search はコミュニティ要約を用いて資料集合全体についての問いを扱い、Local Search はエンティティを中心に構造化データとテキスト単位を組み合わせる。さらに DRIFT Search はコミュニティ単位の情報から出発しながら局所情報へ掘り下げる構成を持つ[19]。
この区別は、「GraphRAG なら高度で、通常の検索なら単純」という序列を意味しない。局所的な事実を知りたいだけなら、該当する原文を直接検索する方が処理も検証も単純である。資料全体のテーマを知りたい場合には、単一断片検索だけでは問いの範囲と検索単位が合わない。質問の種類が違えば、適した検索構造も変わる。
| 質問の範囲 | 典型的な問い | 主な証拠の形 | 検索上の課題 | 適した処理 |
|---|---|---|---|---|
| 局所 | 特定の値、条項、人物、出来事、日時を知りたい。 | 答えを直接含む一つまたは少数の原文断片が中心になる。 | 該当箇所を高い順位で取得し、条件や周辺文脈を落とさないことが必要になる。 | 細粒度の検索と、その後の親文脈や隣接情報の復元が適する。 |
| 複数箇所 | 複数の条件、時点、文書を組み合わせて答えたい。 | 答えの構成要素が複数の文書断片へ分散している。 | 一回の検索で必要証拠をすべて取得できず、途中の情報から次の検索要求が生じる。 | 反復検索や、複数の根拠を統合する処理が必要になる。 |
| 全体 | 資料集合の主要テーマ、共通構造、長期的な傾向を知りたい。 | 答えが一文として存在せず、複数領域の関係から上位概念を構成する必要がある。 | 最類似チャンクの順位だけでは資料全体の代表性や構造を表しにくい。 | コミュニティ、階層要約、グラフなど、資料全体の構造を事前に表現した索引が有効になり得る。 |
6.3 Global Search では、索引作成時の解釈が回答へ影響する
資料全体の構造を事前に作る方法には、局所検索とは異なる誤差も生じる。GraphRAG では、原文からエンティティと関係を抽出し、それをグラフへ変換し、コミュニティを検出し、さらに要約を生成する。原文から回答までの間に複数の変換段階が入る。
たとえば同じ企業名が別表記で抽出され、別エンティティとして扱われれば、本来一つにまとまるべき関係がグラフ上で分散する可能性がある。関係の抽出を誤れば、本来関係しない出来事が同じコミュニティに入ることもある。コミュニティ要約が重要な例外を省略すれば、Global Search はその省略された表現をもとに資料全体を要約することになる。
つまり、全体質問を扱いやすくする代わりに、索引作成時の抽出・分類・要約という新しい判断段階が増える。局所検索では「正しい原文を取れたか」を中心に検証できるが、グラフを利用する場合には「エンティティ抽出は正しいか」「関係は正しいか」「コミュニティのまとまりは妥当か」「要約は原文を忠実に要約しているか」も確認対象になる。
これは GraphRAG に特有の欠点というより、検索用の代理表現を増やすときに共通して生じる交換関係である。HyDE では仮想文書の生成誤差、RAPTOR では要約誤差、GraphRAG ではグラフ構築とコミュニティ要約の誤差が新たに入る。検索用表現を高度化すると、検索できる問いの範囲は広がる一方、その表現が元情報をどこまで正しく写しているかを評価する必要も増える。
6.4 質問スコープは検索後ではなく、検索方式を選ぶ前に効いてくる
局所質問と全体質問の違いを後段の生成だけで吸収しようとすると、検索器はすべての質問に同じ候補集合を返し、LLM がそこから必要な処理を判断することになる。しかし、質問スコープが異なるなら、検索前の段階で使う索引や取得戦略を変える方が合理的な場合がある。
「2025 年度の売上高」のような質問に対して、コミュニティ要約を多数取得して全体テーマを経由する必要はない。反対に、「数年間の主要な経営テーマ」を問う質問に、最類似チャンクを 5 件だけ返しても、特定年度の一部記述に偏る可能性がある。質問の範囲を先に判定できれば、局所検索、反復検索、全体検索のどれを使うかを分けられる。
このとき質問の振り分けも RAG の設計対象になる。検索前に「この問いは一点の事実を尋ねているのか」「複数証拠の統合が必要なのか」「資料全体の構造を尋ねているのか」を判定し、その結果に応じて検索経路を変える。検索表現やチャンクサイズだけでなく、どの検索器を使うかまで質問の性質に依存する。
この分解を行うと、「RAG の性能」を一つの最終回答精度だけで測ることにも無理が出てくる。局所検索が失敗したのか、グラフのエンティティ抽出が誤ったのか、コミュニティ要約が情報を落としたのか、十分な根拠を取得した後で LLM が誤ったのかでは、直す場所が違う。次に必要になるのは、検索と生成を分けた設計に対応して、評価も処理段階ごとに分けることである。
7. 最終回答だけ見ても、どこが悪かったのかは分からない
RAG を複数の処理段階へ分けて設計すると、評価も同じ境界で分けなければ原因を特定できない。最終回答が誤っていたとしても、その誤りが検索から生じたのか、検索後の文脈復元で生じたのか、生成段階で生じたのかは、回答文だけを見ても分からない。「LLM が間違えた」という説明では、修正すべき処理を決められない。
たとえば、「年間契約を途中解約した場合、未利用期間分は返金されるか」という質問に対し、「返金される」と誤答した場合を考える。この一件の誤答だけでも、少なくとも複数の失敗経路がある。返金規定そのものを検索できなかった可能性がある。返金規定は取得できたが、「年間契約には返金しない」という適用条件を含む直前の段落を落とした可能性もある。必要な規定がすべて LLM へ渡っていたのに、「返金しない」を読み違えた可能性もある。さらに、文書にはない例外をモデルが補ってしまった可能性もある。
最終的な出力はどの場合も「誤答」である。しかし、原因が違えば対策も異なる。検索できなかったのであれば、埋め込み表現、質問変換、検索単位、順位付けを調べる必要がある。条件を落としていたのであれば、検索精度を上げても直らず、親文脈や隣接段落をどこまで復元するかを見直す必要がある。十分な根拠が入力されていたなら、検索系を変更しても意味はなく、生成モデルの根拠利用や回答制約を調べるべきである。
7.1 最終正答率だけでは、異なる失敗が一つに潰れる
正答率はシステム全体の結果を比較するには使える。しかし、内部のどこを修正すべきかを示す指標ではない。100 問中 70 問正解した二つの RAG があったとしても、一方は 30 問すべてで必要文書を検索できておらず、もう一方は 30 問すべてで正しい文書を取得した後に生成を誤っているかもしれない。最終スコアは同じでも、システムとしての弱点は正反対である。
さらに、前章まで扱った構成では検索処理そのものが一段ではない。HyDE のような代理表現を使えば質問変換が入る。親子型の検索なら検索後の文脈復元が入る。RAPTOR では要約ノードが索引に入り、GraphRAG ではエンティティ抽出、関係抽出、コミュニティ構築、コミュニティ要約生成までが検索前処理に含まれる。最終回答だけを評価すると、これらのどこで情報が変質したかが見えなくなる。
このため、RAG を評価するときには「最終的に正しかったか」と「必要な情報が各段階を正しく通過したか」を分ける必要がある。前者は利用者から見た結果を測る。後者は開発者が原因を診断するための観測である。両方がなければ、性能が下がったときに、どの部品を変更すべきか判断できない。
7.2 RAGAS は検索と生成を別々の評価対象にする
RAGAS は、RAG を一つのブラックボックスとして採点するのではなく、取得文脈と生成回答を複数の観点から評価する枠組みを提示した[20]。代表的には、取得した文脈が質問にどれだけ関係しているか、生成された回答が与えられた文脈にどれだけ忠実か、回答自体が質問にどれだけ適合しているか、といった観点を分離する。
この分離によって、同じ誤答でも診断結果が変わる。質問に必要な情報が文脈に含まれていなければ、生成モデル以前に検索側の問題が疑われる。必要な根拠が文脈に含まれているのに回答がそれと矛盾していれば、生成側の問題である。最終回答の品質だけを見る場合には、この違いは一つの低スコアにまとめられてしまう。
ここで評価指標を増やす目的は、数字を細かくすることではない。処理境界と評価境界を一致させることにある。検索、文脈復元、生成を別々に改善できる構成なら、それぞれが必要な情報を次段へ正しく渡せたかを観測できなければならない。
7.3 RAGChecker は「何を取れなかったか」と「何を使えなかったか」をさらに分ける
RAGChecker は、検索と生成の失敗をさらに細かく診断する枠組みを提案している[21]。単に「正しい文脈を取れたか」だけでなく、必要な主張を検索器がどこまで取得できたか、取得された主張を生成モデルがどこまで利用できたか、取得されていない内容を回答へ加えていないか、といった形で原因を分解する。
この細分化が必要になる理由は、RAG の回答が複数の根拠から構成されるためである。たとえば「解約時の返金」と「機器返却期限」を同時に尋ねる質問では、返金規定だけ取得し、返却規定を落としても、一部は正しい回答になる。検索が完全に失敗したわけではない。必要な根拠のうち一部だけを取得したという失敗である。
逆に、返金規定と返却規定の両方を取得していても、生成モデルが返却期限だけを回答し、返金条件を使わなければ、検索再現率を改善しても結果は変わらない。必要な根拠はすでに存在しているため、問題は生成モデルが取得情報を使い切れていないことにある。
さらに、取得された文書に「違約金は発生しない」と書かれていないのに、回答へ「違約金もありません」と追加したなら、これは検索の不足とは別の失敗である。検索対象を増やすより、回答を取得根拠へ拘束する方法を調整する必要がある。
| 失敗段階 | 観測される現象 | 直接原因 | 背後で疑う設計 | 修正方向 |
|---|---|---|---|---|
| 検索表現 | 必要な文書が検索候補へ入らない。 | 質問と文書の表現差を検索器が吸収できていない。 | 質問変換、埋め込み表現、代理表現の品質が質問形式と合っていない可能性がある。 | 質問変換、HyDE 型表現、文書側の検索表現、埋め込みモデルを見直す。 |
| 検索粒度 | 関連する話題は取得できるが、必要な事実が候補から漏れる。 | 検索単位が質問に対して大きすぎる、または小さすぎる。 | 一つの検索単位に複数話題が混在しているか、必要情報が複数の検索単位へ分散している。 | チャンク境界、検索単位、階層検索を調整する。 |
| 文脈復元 | 主要事実は取得できるが、条件、例外、照応先が欠ける。 | 検索した断片を狭い範囲のまま生成へ渡している。 | 検索単位と生成文脈を同一に扱っている。 | 親ノード、隣接段落、原文への復元範囲を見直す。 |
| 複数根拠の取得 | 回答に必要な事実の一部だけが文脈に含まれる。 | 一回の検索で必要証拠をすべて取得できていない。 | 質問が複数段階なのに、一回検索型の構成へ固定している可能性がある。 | 反復検索、質問分解、追加検索を検討する。 |
| 生成時の根拠利用 | 必要な根拠は入力されているが、回答で一部しか使われない。 | 生成モデルが文脈内の必要情報を選択・統合できていない。 | 入力過多、指示不足、モデル能力、文脈配置の影響が考えられる。 | 生成入力の構成、指示、モデル、文脈の並べ方を見直す。 |
| 生成時の逸脱 | 取得文書に存在しない断定が回答へ加わる。 | 生成モデルが根拠外の情報を補っている。 | 回答を根拠へ拘束する仕組みが弱い。 | 引用要求、根拠照合、根拠忠実性評価、回答制約を強化する。 |
7.4 高度な検索表現を増やすほど、観測すべき場所も増える
第 3 章から第 6 章で扱った手法は、RAG が答えられる質問の範囲を広げる一方、情報が通過する変換段階も増やす。HyDE なら、元質問から生成した仮想文書が適切だったかを確認する必要がある。RAPTOR なら、上位要約が原文の条件を落としていないかを見る必要がある。GraphRAG なら、エンティティと関係の抽出、コミュニティの形成、コミュニティ要約の要約がそれぞれ誤差源になる。
たとえば GraphRAG で全体質問への回答が不正確だった場合、Local Search の検索適合率を上げても改善しない可能性がある。エンティティが二重登録されてコミュニティが分断されているならグラフ構築を直す必要がある。コミュニティ自体は妥当でも要約が重要な出来事を落としているなら要約を直す必要がある。要約まで正しいのに最終回答が偏っているなら生成の統合処理を疑うべきである。
代理表現や階層を増やすほど、元情報から最終回答までの経路は長くなる。その分だけ検索できる問いは増えるが、どの変換で意味が変わったかを追跡できなければ、誤答の原因も見つけにくくなる。高度な検索アーキテクチャほど、評価を最終出力だけへ集約する設計とは相性が悪い。
7.5 評価指標は、改善の判断主体を分けるために使う
実運用では、すべての失敗に対して同じ担当者や同じ修正を当てるわけではない。検索再現率が低いなら索引作成や検索器の設計を変更する。取得文脈が広すぎるなら文脈構成を調整する。根拠は十分なのに回答が不安定なら生成モデルや生成指示を変更する。評価指標を処理段階に対応させることで、「何を改善すべきか」という判断主体を切り分けられる。
この違いは A/B テストにも影響する。埋め込みモデルを変更した実験で最終回答精度だけが上がったとしても、その理由が検索再現率の改善なのか、取得文書の順序が変わって LLM の生成が偶然改善したのかは分からない。検索指標と生成指標を同時に見れば、変更がどの境界へ効いたのかを確認できる。
反対に、最終回答精度が変わらなくても内部指標が改善することがある。検索器が必要根拠をより確実に取得できるようになった一方、生成モデルがその改善を使い切れていなければ、全体スコアにはまだ現れない。この場合、「検索変更は効果がない」と戻すのではなく、次に生成側のボトルネックを解消すべきだと判断できる。
| 観測対象 | 答えたい問い | 改善判断 |
|---|---|---|
| 検索結果 | 回答に必要な根拠を取得できたか。 | 検索器、検索表現、粒度、索引を変更すべきか判断する。 |
| 復元後の文脈 | 取得した根拠に必要な条件、例外、関連情報が揃ったか。 | 親文脈、隣接情報、階層復元、文脈構成を変更すべきか判断する。 |
| 生成回答と文脈の対応 | 生成内容が与えた根拠から導けるか。 | 生成モデル、生成指示、根拠拘束を変更すべきか判断する。 |
| 最終回答 | 利用者の質問へ正しく十分に答えられたか。 | システム全体として改善したかを判断する。 |
RAG の処理境界を分離するなら、評価も同じ境界へ置く必要がある。検索表現を変え、粒度を変え、検索時点を変え、階層を追加しても、最終回答だけを見ていれば、それぞれの変更がどこへ作用したのか確認できない。設計の自由度が増えるほど、観測点も増やさなければならない。
この章までで、RAG は一つの検索と一つの生成からなる単純な直列処理ではなくなった。検索前には表現変換や階層構築があり、検索中には質問の振り分けや反復処理があり、検索後には文脈復元があり、その後に生成がある。次に必要なのは、これらを個別技術の一覧としてではなく、一つの設計モデルとして整理することである。
8. RAG は「検索エンジンを LLM につなぐ技術」より広くなっている
ここまで見てきた研究を手法名ではなく、「RAG のどの部分を変更したのか」で並べると、個々の研究の関係が整理しやすくなる。HyDE は利用者が入力した質問をそのまま検索せず、文書に近い仮想文書へ変換した。HyQE と HyPE は逆に、文書側へ質問に近い代理表現を持たせた。Dense X Retrieval と LongRAG は、一件の検索候補をどの大きさにするかを変更した。Late Chunking は、検索単位の大きさと、その単位の意味表現を作るために読む文脈の大きさを分離した。FLARE と Iter-RetGen は、検索を回答生成前の一回に固定せず、生成途中でも実行できるようにした。RAPTOR は原文と要約を複数の抽象度で保持し、GraphRAG は局所的な事実検索と資料集合全体への問いで異なる索引構造を利用する。
これらは同じ問題を別の方法で解いているわけではない。HyDE が扱うのは質問と文書の表現差であり、Dense X Retrieval が扱うのは検索粒度である。FLARE が扱うのは検索時点であり、RAPTOR が扱うのは情報の抽象度である。GraphRAG が対象にする資料全体の構造把握では、そもそも「最も近い断片を探す」という問題設定だけでは質問の範囲を表現しにくい。個々の研究は、RAG の異なる境界へ介入している。
この違いをまとめると、RAG の設計は少なくとも五つの軸へ分解できる。これは既存研究で定義された標準分類ではなく、ここまでの研究結果を同じ処理モデルの上へ置いたときに得られる整理である。
| 設計軸 | 決めること | 変更すると影響する箇所 | 研究例 |
|---|---|---|---|
| 表現 | 利用者の質問や元文書を、検索時に何として比較するかを決める。 | 質問と文書の語彙や文章形式が離れている場合の検索到達率が変わる。 | HyDE は質問を仮想文書へ変換し、HyQE と HyPE は文書側へ質問に近い表現を作る。 |
| 粒度 | 何を一件の検索候補として順位付けするかを決める。 | 局所的な意味を識別する能力と、複数情報を一件に保持する能力の配分が変わる。 | Dense X Retrieval、LongRAG、Late Chunking は検索単位と周辺文脈の関係へ介入する。 |
| 検索時点 | 検索をいつ実行し、途中の状態から追加検索を行うかを決める。 | 最初の質問だけでは確定しない情報要求を後から処理できる一方、反復コストと誤差伝播が増える。 | FLARE と Iter-RetGen は検索と生成の間に反復経路を作る。 |
| 範囲と抽象度 | 局所的な原文、複数断片の要約、資料集合全体のどの層を検索対象にするかを決める。 | 一件の事実を探す質問と、複数箇所から上位概念を作る質問への適合性が変わる。 | RAPTOR は複数抽象度を階層化し、GraphRAG は局所と全体で異なる情報構造を利用する。 |
| 文脈復元 | 検索によって候補を特定した後、どの情報を生成モデルへ渡すかを決める。 | 条件や例外を保持できるか、反対に無関係な情報をどこまで抑えられるかが変わる。 | 親文脈、隣接段落、下位原文、要約、コミュニティ要約などを質問に応じて組み合わせられる。 |
8.1 一つのチャンクに五つの役割を負わせると、変更の影響を分離できない
単純な RAG では、この五つの軸が一つのチャンクへまとめられやすい。文書を 500 token ごとに切り、その 500 token から埋め込み表現を作り、それを一件として検索し、取得した 500 token をそのまま LLM へ渡す構成を考える。この場合、同じチャンクが「検索表現を作る元」「検索単位」「回答時の文脈」という三つ以上の役割を同時に持つ。
この構成でチャンクサイズを 500 token から 200 token へ変更すると、複数の条件が一度に変わる。一件の検索候補が細かくなる。埋め込み表現を作るときに参照する文章も短くなる。検索結果として LLM へ渡る一件あたりの文脈も短くなる。性能が改善しても、それが検索粒度の改善によるものなのか、無関係な文脈が減ったためなのかは分からない。性能が悪化した場合も、検索に失敗したのか、検索後に条件を失ったのかを切り分けにくい。
五つの軸を分離すると、この結合を解ける。200 token の単位で検索しながら、埋め込み表現はより広い文脈から作ることができる。検索後には 1000 token 相当の親節へ戻せる。質問が広ければ上位要約を使い、複数段階なら追加検索を実行できる。変更する変数を限定できるため、前章で扱った評価も、どの設計変更がどの段階へ作用したかを追いやすくなる。
つまり、RAG の複雑化には二種類ある。機能を無秩序に追加して処理経路を増やす複雑化と、もともと一つのチャンクへ暗黙に結合されていた責務を分離する複雑化である。後者では部品数は増えても、それぞれが何を決めるのかはむしろ明確になる。
8.2 検索用の情報と、根拠として使う情報を分ける
この五軸の中でも、記事全体を通して繰り返し現れたのが、検索用表現と回答根拠の分離である。HyDE の仮想文書は、関連する実文書を見つけるために生成される。HyQE や HyPE の仮想質問も、文書断片へ到達するための検索入口である。これらの生成物を最終的な事実として信頼する必要はなく、検索後に元文書へ戻れる。
RAPTOR でも同じ区別が成立する。上位要約は、複数の原文に共通する主題を検索しやすくする一方、具体的な数値や例外条件を確認するときには下位の原文が必要になる。GraphRAG のコミュニティ要約も、資料全体の構造へ到達するためには有用だが、特定の主張を確定する場合には、その要約がどのエンティティ、関係、テキスト単位から構成されたかを辿れる方が検証しやすい。
この構造では、検索用表現に要求される性質と、証拠に要求される性質が違う。検索用表現には、質問から関連領域へ到達できることが求められる。多少の圧縮や言い換えを含んでいても、適切な根拠へ案内できれば役割を果たせる。これに対して回答根拠には、元情報との対応、条件の保持、検証可能性が必要になる。
| 情報の役割 | 主な要求 | 許容できる変換 | 誤った扱いをした場合 |
|---|---|---|---|
| 検索用表現 | 質問から関連する元情報へ到達できること。 | 要約、仮想質問、仮想文書、階層化など、検索性能を目的とした変換を利用できる。 | 代理表現の生成誤差によって、本来とは異なる文書へ検索を誘導する可能性がある。 |
| 回答根拠 | 回答中の主張を検証でき、条件や例外を確認できること。 | 必要な範囲の抽出や整形はできるが、元情報との対応を失わないことが必要になる。 | 代理表現を事実そのものとして扱うと、生成された誤情報や要約時の省略を根拠として採用してしまう。 |
検索用表現を自由に変えられるのは、最後に根拠へ戻れるからである。代理表現そのものを正解として扱う構成では、この分離は成立しない。検索を高速化・高精度化する表現と、回答を正当化する情報を別に保持することが、表現変換を安全に利用する条件になる。
8.3 既稿で分けた情報経路を、RAG の内部でも分ける
既稿「Ollama、RAG、MCP を開発環境へ統合する」では、長期的な文書、作業中のコード、GitHub 上の現在状態を、一つの巨大な入力へ集約しなかった[22]。長期文書は RAG から取得し、作業対象のコードはローカル環境から参照し、GitHub の issue や pull request の現在状態は MCP を経由して取得する。情報の更新頻度と所在が違うため、取得経路も分ける構成である。
この設計で、GitHub の現在状態をあらかじめ RAG の索引へコピーしていた場合、索引更新から実際のリポジトリの状態までに時間差が生じる。逆に、長期的な技術資料を毎回外部 API から検索すれば、取得コストと応答時間が増える。同じ「LLM に情報を渡す」という目的でも、情報の性質が違えば適した取得経路が違う。
「MacBook Pro でローカル LLM を実用化する条件」では、計算資源が限られるローカル環境ほど、処理対象を必要な範囲へ絞ることが実用性へ直結することを整理した[23]。巨大なモデルや巨大なコンテキストですべてを吸収するのではなく、処理対象を選び、必要な情報だけをモデルへ渡すことで計算量を管理する考え方である。
ここまでの研究は、この分離を RAG の内部へさらに進めたものとして読める。文書が一種類だからといって、一種類の表現だけを作る必要はない。同じ文書から原文チャンク、文脈化された埋め込み、仮想質問、要約ノードを作り、目的に応じて異なる経路から同じ根拠へ到達できる。情報源を分けるだけでなく、一つの情報源の内部にも複数の検索経路を持てる。
ここでソフトウェア設計上の責務分離との対応が具体的になる。一つのコンポーネントに検索、文脈保持、抽象化、回答生成をまとめると、一つの変更が複数の性能特性へ影響する。役割を分ければ、「検索しやすい表現を変更する」「生成へ戻す文脈を広げる」「全体質問だけ別の索引へ送る」といった局所的な変更が可能になる。
8.4 RAG の処理を「検索前」「検索」「検索後」「生成」に分け直す
この構造を処理順に並べると、RAG は単純な「文書を検索して LLM へ渡す」という二段階より細かく表現できる。
| 段階 | 処理 | ここで決めること | 失敗した場合の帰結 |
|---|---|---|---|
| 元情報の保持 | 最終的な根拠となる文書、記録、データを保持する。 | どの情報を原典として残し、更新や出典をどう追跡するかを決める。 | 元情報自体が古い、不完全、重複していれば、その後の検索を改善しても正しい根拠へ到達できない。 |
| 検索用表現の生成 | 原文チャンク、文脈化された埋め込み、仮想質問、仮想文書、要約、グラフなどを作る。 | どの質問から元情報へ到達するために、どの代理表現を用意するかを決める。 | 表現が元情報の意味を十分に保持できなければ、適切な文書が検索候補から外れる。 |
| 検索経路の選択 | 質問の範囲に応じて検索方法を選び、候補を順位付けする。 | 局所検索、反復検索、階層検索、全体検索のどれを使うかを決める。 | 質問スコープと検索方式が合わなければ、局所情報への偏りや必要証拠の欠落が起きる。 |
| 文脈復元 | 取得結果から親文脈、隣接情報、下位原文、関連ノードを組み立てる。 | 検索で見つけた単位から、回答に必要な証拠範囲へどこまで広げるかを決める。 | 狭すぎれば条件や例外を落とし、広すぎれば生成時のノイズを増やす。 |
| 生成 | 復元された根拠から質問への回答を構成する。 | どの根拠を使い、どの範囲まで断定し、出典との対応をどう維持するかを決める。 | 十分な根拠があっても誤読や根拠外生成が起きれば、最終回答は不正確になる。 |
この処理モデルでは、検索は中央の一工程にすぎない。検索前には、元情報からどの代理表現を作るかという設計がある。検索時には、質問の種類に応じてどの索引と経路を使うかを選ぶ。検索後には、取得した単位をどの範囲の根拠へ戻すかを決める。その後で初めて、LLM が回答を生成する。
この分解によって、前章の評価とも対応が取れる。検索結果に必要な根拠がなければ、検索用表現か検索経路を疑う。根拠は見つかっているのに条件が欠けていれば、文脈復元を疑う。十分な根拠が渡っているのに回答が誤れば、生成を疑う。GraphRAG のコミュニティ要約が誤っていれば、その前段のグラフ構築や要約を調べる。設計境界と観測境界が一致する。
この構造から得られる帰結は、「RAG には高度な手法を多く組み込むほどよい」というものではない。質問が局所的な事実検索だけなら、単純なベクトル検索と適切な文脈復元で十分な場合がある。文書と質問の表現差が小さければ、HyDE や HyPE を追加する理由も弱い。全体質問を扱わないシステムに GraphRAG の索引生成コストを負わせる必要もない。
分離の目的は機能を増やすことではなく、必要になった場所だけを変更できるようにすることである。局所検索で困っていないならそこは固定し、文脈欠落が問題なら検索後の復元だけを変える。複数段階の質問で根拠が足りなければ検索時点を変える。資料全体への問いが必要になったときに初めて全体検索用の構造を加える。どの失敗条件に対して、どの軸を変更するのかを対応させる。
ここまで来ると、最初に置いた「検索する文章と、LLM に読ませる文章は同じでなくてよい」という命題の射程も明確になる。異なるのは文章の長さだけではない。検索用の代理表現、検索単位、検索時点、抽象度、質問スコープ、生成へ戻す根拠範囲まで、それぞれ別の設計変数として扱える。
残るのは、この分離から何を一般化できるかである。個々の研究は、それぞれ異なるデータセットと評価条件で特定の介入を検証したものであり、五つの軸をすべて分離すれば性能が上がると証明したものではない。最後に、各研究から直接言える範囲と、それらを横断して本稿が導く設計上の帰結を分けて整理する。
9. 問うべきなのは「何文字で切るか」ではなく、各段階で何を表現するかである
RAG の設計を「最適なチャンクサイズを探す問題」として始めると、複数の異なる問題を一つの数値へ押し込めることになる。200 token にすれば検索候補は細かくなるが、同時に埋め込み表現を作るときの文脈も短くなり、取得後にその断片をそのまま LLM へ渡す構成なら生成文脈まで狭くなる。500 token に変更すれば、この三つがまとめて広がる。結果が改善しても悪化しても、どの変更が効いたのかを切り分けにくい。
ここまで見てきた研究は、この結合を異なる場所から解いている。検索候補の大きさ、意味表現を作るために参照する文脈、検索に使う代理表現、検索を実行する時点、情報の抽象度、質問の範囲、検索後に復元する文脈は、それぞれ別の設計変数として扱える。たとえば 200 token の単位で候補を検索しながら、より広い節の文脈を埋め込み表現へ反映し、取得後には 1000 token 相当の親節へ戻す構成を取れる。仮想文書や仮想質問を検索用の入口にしても、最終回答では実文書へ戻って根拠を確認できる。
質問の範囲によって検索経路も変わる。一つの値や条項を尋ねる局所質問なら原文を直接検索する方が単純であり、複数の根拠を順に集める必要がある質問なら反復検索が候補になる。資料集合全体の傾向を尋ねる場合には、階層要約や GraphRAG の Global Search のように、個々の最類似断片とは別の索引構造が必要になり得る。どの構成を選ぶかは手法の新しさではなく、観測された失敗条件と質問スコープの対応で決める必要がある。
9.1 分離できるからといって、すべて分離すればよいわけではない
ここまでの議論から、「HyDE、Late Chunking、RAPTOR、GraphRAG、反復検索をすべて組み合わせれば高度な RAG になる」という結論は出ない。処理を一段追加するたびに、新しい計算量と誤差源も加わるからである。
HyDE を使えば検索時に LLM 推論が必要になる。文書側へ複数の仮想質問を持たせれば、索引作成時の生成量と保存量が増え、文書更新時には再生成が必要になる。RAPTOR では階層要約の生成コストと要約誤差が入り、GraphRAG ではエンティティと関係の抽出、コミュニティ構築、コミュニティ要約生成まで検証対象が増える。反復検索では応答時間が伸び、中間生成の誤りが次の質問へ伝播する可能性がある。
このため、設計軸を分ける目的は機能を増やすことではない。実際に観測された失敗条件に対して、必要な軸だけを変更できるようにすることである。局所的な検索精度に問題がなければ検索方式を変える必要はない。正しい断片を取得できているのに条件を落とすなら、文脈復元だけを変更すればよい。質問と文書の表現差で検索に失敗しているなら、代理表現を検討する。全体質問が必要になって初めて、資料全体の構造を持つ索引を検討すればよい。
| 観測された失敗 | 先に疑う設計軸 | 考えられる変更 | 変更時に増える制約 |
|---|---|---|---|
| 関連文書そのものを検索できない | 検索表現 | 質問変換、仮想文書、仮想質問、埋め込み表現を見直す。 | 生成処理、索引量、代理表現の誤差が増える可能性がある。 |
| 関連箇所は取れるが条件や例外を落とす | 文脈復元 | 親節、隣接段落、元文書への復元範囲を広げる。 | LLM へ渡す入力量と無関係情報が増える可能性がある。 |
| 一回の検索では必要な根拠が揃わない | 検索時点 | 追加検索、反復検索、質問の段階的更新を導入する。 | 応答時間、検索回数、中間誤差の伝播が増える。 |
| 局所的な断片は取れるが全体傾向を答えられない | 範囲と抽象度 | 階層要約、コミュニティ、全体検索を利用する。 | 索引作成コストと要約・構造化の誤差が増える。 |
| 十分な根拠があるのに回答が誤る | 生成 | 生成指示、文脈構成、モデル、根拠拘束を見直す。 | 検索を変更しても改善しないため、検索側との切り分けが必要になる。 |
9.2 RAG の設計対象は、文章の切れ目から情報の変換経路へ移る
以上をまとめると、RAG で先に問うべき事項は「チャンクは何 token か」だけではない。元文書からどの検索用表現を作るのか。その表現を作るときにどこまで文脈を見るのか。何を一件の検索単位にするのか。質問に応じてどの検索経路を使うのか。途中で追加検索するのか。取得後にどこまで原文へ戻すのか。どの段階の結果を根拠として回答へ使うのか。これらを分けて初めて、チャンクサイズという個別設定の意味も決まる。
各研究が直接示した範囲には限界がある。Lost in the Middle で観測された位置依存性を、長い文脈を扱う将来のすべてのモデルへ一般化することはできない[4]。HyDE の有効性が確認された条件から、すべての質問を仮想文書へ変換すべきだとは言えない[11]。RAPTOR の評価結果から、通常のベクトル検索を一律に置き換えるべきだとも言えない[16]。GraphRAG が資料全体の構造把握で改善を示しても、局所的な事実検索までグラフ化する必要はない[18]。
それでも、異なる条件で行われた研究を横断すると、一つの設計上の帰結は残る。検索に使う表現、検索する粒度、回答生成に必要な文脈、情報の抽象度、検索を行う時点を、同じ文章単位へ固定する必然性はない。各工程が異なる目的を持つなら、それぞれに適した表現を使い、最後に検証可能な元情報へ再接続できる。
「検索する文章と、LLM に読ませる文章は同じでなくてよい」という命題は、単にチャンクを二種類用意するという話ではない。検索のためには仮想質問や要約を使い、候補の識別には細かい単位を使い、回答時には親文脈へ戻し、広い質問では上位表現を使い、必要なら生成途中でも再検索する。RAG の各段階で、同じ情報を異なる表現として扱えるという意味である。
この見方へ移ると、RAG は「検索エンジンから何件取って LLM へ渡すか」という構成から、元情報をどのような検索表現へ変換し、質問に応じてどの経路から見つけ、どこまで原文へ戻して回答させるかを設計する構成へ変わる。最初に決めるべきものはチャンクの文字数ではない。各段階で何を表現し、その表現を次の段階へどう受け渡すかである。
10. 参考文献
- Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020. https://proceedings.neurips.cc/paper/2020/hash/6b493230205f780e1bc26945df7481e5-Abstract.html
- Vladimir Karpukhin et al., Dense Passage Retrieval for Open-Domain Question Answering, EMNLP 2020. https://aclanthology.org/2020.emnlp-main.550/
- id774, MacBook Pro にローカル RAG を構築する（2026-07-18）. https://blog.id774.net/entry/2026/07/18/5104/
- Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2024. https://aclanthology.org/2024.tacl-1.9/
- Peng Xu et al., Retrieval meets Long Context Large Language Models, ICLR 2024. https://openreview.net/forum?id=xw5nxFWMlo
- Tong Chen et al., Dense X Retrieval: What Retrieval Granularity Should We Use?, EMNLP 2024. https://aclanthology.org/2024.emnlp-main.845/
- Michael Günther et al., Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models, arXiv:2409.04701, 2024. https://arxiv.org/abs/2409.04701
- Max Conti et al., Context is Gold to find the Gold Passage: Evaluating and Training Contextual Document Embeddings, EMNLP 2025. https://aclanthology.org/2025.emnlp-main.1150/
- Ziyan Jiang, Xueguang Ma, Wenhu Chen, LongRAG: Enhancing Retrieval-Augmented Generation with Long-context LLMs, arXiv:2406.15319, 2024. https://arxiv.org/abs/2406.15319
- Yuning Mao et al., Generation-Augmented Retrieval for Open-Domain Question Answering, ACL-IJCNLP 2021. https://aclanthology.org/2021.acl-long.316/
- Luyu Gao et al., Precise Zero-Shot Dense Retrieval without Relevance Labels, ACL 2023. https://aclanthology.org/2023.acl-long.99/
- Weichao Zhou et al., HyQE: Ranking Contexts with Hypothetical Query Embeddings, Findings of EMNLP 2024. https://aclanthology.org/2024.findings-emnlp.761/
- Domen Vake, Jernej Vičič, Aleksandar Tošić, Bridging the Question–Answer Gap in Retrieval-Augmented Generation: Hypothetical Prompt Embeddings, IEEE Access 2025. https://ieeexplore.ieee.org/document/11080443/
- Zhengbao Jiang et al., Active Retrieval Augmented Generation, EMNLP 2023. https://aclanthology.org/2023.emnlp-main.495/
- Zhihong Shao et al., Enhancing Retrieval-Augmented Large Language Models with Iterative Retrieval-Generation Synergy, Findings of EMNLP 2023. https://aclanthology.org/2023.findings-emnlp.620/
- Parth Sarthi et al., RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval, ICLR 2024. https://openreview.net/forum?id=GN921JHCRw
- LlamaIndex, AutoMergingRetriever, official source code. https://github.com/run-llama/llama_index/blob/main/llama-index-core/llama_index/core/retrievers/auto_merging_retriever.py
- Darren Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization, Microsoft Research, 2024. https://www.microsoft.com/en-us/research/publication/from-local-to-global-a-graph-rag-approach-to-query-focused-summarization/
- Microsoft, GraphRAG Query Overview, official documentation. https://microsoft.github.io/graphrag/query/overview/
- Shahul Es et al., RAGAs: Automated Evaluation of Retrieval Augmented Generation, EACL 2024. https://aclanthology.org/2024.eacl-demo.16/
- Dongyu Ru et al., RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation, NeurIPS 2024. https://proceedings.neurips.cc/paper_files/paper/2024/hash/27245589131d17368cccdfa990cbf16e-Abstract-Datasets_and_Benchmarks_Track.html
- id774, Ollama、RAG、MCP を開発環境へ統合する（2026-07-19）. https://blog.id774.net/entry/2026/07/19/5106/
- id774, MacBook Pro でローカル LLM を実用化する条件（2026-07-17）. https://blog.id774.net/entry/2026/07/17/5102/