この記事について

📚 RAG入門シリーズ

【基礎編】 RAGって実際どんな仕組み？

【詳細編】 RAGはモデルの"中"で何をしているのか ← いまここ

基礎編では、RAGを 「検索して、プロンプトに連結して、生成する」外側の仕組み として組み立てました。インデックスの作り方、ベクトル検索、プロンプトの組み立て — どれもモデルの外側の話です。

この詳細編では、そこから モデルの内側 に降ります。扱うのは、基礎編では踏み込まなかった次の疑問です。

検索してきた文書は、途中の層や hidden state にも影響するの？
「毎層に同じトークンを渡している」の？
検索したトークンを、そのまま答えにコピーしてるの？
基礎編で「モデルはRAGと手打ちを区別していない」と言っていたが、それは内部から見ても本当？

数式は使わず、比喩とイメージ図でいきます。各項目は公開されている技術文書・論文で裏どりしています（末尾に出典）。

対象読者：基礎編を読んだ方、あるいは「RAGは動かせるが、モデルの中で何が起きているかは曖昧」という方。

💡 実装を先に知りたい方は、基礎編を先に読むことをおすすめします。この記事は基礎編の理解を前提に、その"裏側"を説明するものです。

このページの要点

先に要点を記します。

前編のおさらい（3分）

内部の話に入る前に、基礎編の骨格を1枚で振り返っておきます。ここは既にご存知なら読み飛ばして構いません。

RAG（Retrieval-Augmented Generation）は3つの単語でできています。

単語	意味	やっていること
Retrieval	検索	質問に関連する文書を知識ベースから探す
Augmented	拡張	探した文書を質問と一緒にプロンプトへ連結する
Generation	生成	その合成プロンプトを使ってLLMが答えを作る

流れにするとこうです。

ユーザーの質問
   │
   ▼
[検索] 知識ベース（文書DB / ベクトルストア）から関連文書を取得
   │
   ▼
[拡張] 「質問 + 検索文書」を1つのプロンプトに連結   ← アプリ側の処理
   │
   ▼
[生成] LLM が答えを出力

ポイントは、この過程でモデルの重みは一切変わらないということです。ファインチューニングのように再学習しているわけではなく、追加の学習なしで外部知識を使えるようにするのがRAGの狙いです。IBMやAWSの解説でも、RAGは「再学習なしにLLMを外部の知識ベースにつなぐ仕組み」として説明されています。

この記事の出発点は、まさにここです。 「重みが変わらないなら、モデルの中では一体何が変わっているのか？」を掘り下げていきます。

1. 出発点：モデルはRAGか手打ちかを区別していない

基礎編でも触れた話ですが、内部を見ていくうえでの土台になるので、あらためて確認しておきます。

LLMへの入力は、最終的には「1本のトークン列」でしかありません。

そのトークン列が、

あなたが手でキーボードから打ったものなのか、
検索システムが自動で取ってきた文書を連結したものなのか、

モデルには区別がつきませんし、区別する必要もありません。

「RAG専用の特別な入力ポート」があるわけではないのです。検索文書も、あなたが手で貼り付けたテキストと同じ「プロンプトの一部」として、まったく同じ入り口から入っていきます。

手打ちプロンプト:  [質問 + あなたが貼った資料] ──┐
                                                ├──► 同じトークン列としてモデルへ
RAG:              [質問 + 検索が取ってきた資料] ──┘

つまり 「RAGか、手打ちプロンプトか」はモデル内部の話ではなく、入力トークン列を誰がどう用意したかというパイプライン側の話 なのです。

極端に言えば、あなたが毎回手で「関連しそうな社内文書を検索して、コピペしてから質問する」作業を自動化したのがRAG、という理解で大きく外れていません。

では実用上の違いはどこに出る？

入力さえ同じなら結果も同じ。でも実運用では、以下の点で大きな差が出ます。

スケール：手打ちでは無理な量（何万件のDB）から、質問ごとに関連分だけ動的に選んで入れられる。
鮮度・自動性：人が毎回探さなくても、最新のDBから自動で取ってくる。
検索品質に全依存：RAGの答えの良し悪しは、検索が的確な文書を拾えたかでほぼ決まる。

最後の点は重要です。RAGの失敗の多くは、生成側ではなく 検索側（関連文書を取れていない、ノイズを拾っている）で起きます。モデルにとっては「渡された入力が良かったか悪かったか」でしかないからです。見当違いの資料を渡せば、手打ちで間違った資料を貼るのと同じで、答えも引きずられます。

さて、ここからが本題です。 「入力トークン列が変わるだけ」なら、モデルの中では具体的に何が変わっているのでしょうか。

2. 検索文書は「途中の層」にも影響するのか？ → する（だが理由が重要）

ここから中身に踏み込みます。「入力に足しただけなら、最終出力にしか効かないのでは？」と思うかもしれません。実は全層のhidden stateに影響します。 ただし理由が大事です。

Transformerは各層の self-attention で「系列内のすべてのトークン同士」を混ぜ合わせながら処理します。検索文書を先頭に入れると、それがトークンとして系列に加わり、質問側・回答側のトークンは各層のattentionを通じてその検索文書を参照します。

[検索文書トークン]   [質問トークン]   [回答トークン]
       │                 │               │
       └──── attention で参照される ──────┘   ← これが全層で起きる

結果として、質問・回答位置のhidden stateはすべての層で検索内容の影響を受けます。

ただし勘違いしてはいけないのは、これは重みが変わったからではないということ。「入力が変わったことが、attention経由で全層に自然に波及している」という間接的な経路にすぎません。

🔑 ここが「重みは変わらないのに、中身は全部変わる」の正体です。
基礎編の「RAGはモデルを再学習しない」と、この章の「全層に影響する」は、矛盾しません。

3. 「毎層おなじトークンを渡している」わけではない

「全層に影響する」と聞くと、「トークンを各層に配っているのか？」と思いがちですが、違います。ここはTransformerの基本として押さえたいポイントです。

トークン（＝離散的なID）が使われるのは、いちばん下の埋め込み層で1回だけです。

トークンID列を埋め込みベクトル列に変換したあと、層をまたいで流れていくのは hidden state（連続値のベクトル） であって、トークンそのものではありません。

トークンID列 ──(埋め込み・1回だけ)──► h⁰
h⁰ ──[層1]──► h¹
h¹ ──[層2]──► h²
 ...

同じもの：系列の長さ（＝位置の数）。10トークン入れれば全層で「位置10個」という構造は保たれる。
違うもの：各ベクトルの中身。層を上がるにつれて表現は変化していく。層2が受け取るのは「元のトークン」でも「h⁰」でもなく、層1が出力した「h¹」です。

検索文書もこの系列の中の「位置」を占めるだけです。そして各層は、その層の文書位置のhidden stateから その層独自のKey/Value を計算します。「文書のK/Vを1回作って全層で使い回す」のではなく、層ごとに別々に持っている（KVキャッシュも層ごと）。だからこそ、検索内容の影響が「全層で」効くわけです。

💡 基礎編で Embedding Model の内部図を見た方へ：
あそこで [Self-Attention → FFN] × N層 と書いた繰り返し部分が、まさにこの話です。
埋め込みモデルでも生成用LLMでも、層を流れるものが hidden state である点は同じです。

4. 検索したトークンを「コピー」しているわけではない

もう一つの典型的な誤解です。

「RAGは検索したトークンを出力に使っている」と言うと、検索文書のトークンをそのまま答えに持ってきているというイメージになりがちです。でも通常のRAGはそうではありません。

方式	やっていること
(a) 通常のRAG	検索文書を「情報源」として読み、その意味・事実を根拠にして、モデルが新しくトークンを生成
(b) コピー機構	ポインタネットワーク／抽出型QAなど。文書中のスパンをそのまま抜き出す（通常のRAGとは別設計）

通常のRAG (a) では、出力トークンは語彙全体からその都度サンプリングされます。答えの中身（事実）は文書由来でも、出力トークン列そのものはモデルが組み立てているのです。固有名詞や数値が文書と一致することはよくありますが、それは「コピーした」のではなく「読んで、それに基づいて自分で書いた」結果です。

比喩で言うと：

通常のRAG (a) … 資料を読んで自分の言葉で答えを書く人

コピー機構 (b) … 資料の該当箇所をそのまま書き写す人

一般に「RAG」と言えば (a) を指します。

ちなみに、出力の大半が検索文書とそっくり（＝ほぼ書き写し）になるのは、要約や統合が求められる場面ではむしろ望ましくない挙動とされることが多いです。

5. 【発展】検索を「途中の層」に直接注入するアーキテクチャ

ここまでは「埋め込み層で1回入れて、あとは自然に上へ伝播」という標準RAGの話でした。実は、検索結果を明示的に中間層へ食わせる設計も存在します。「RAGは中間層に影響するのか」という問いに対して、より構造的に介入している例です。

基礎編の最後で名前だけ挙げた3つを、ここで少しだけ詳しく見ます。

手法	どこで検索を統合するか
RETRO（DeepMind）	特定の中間層に chunked cross-attention を挿入し、検索チャンクをそこで直接参照させる
kNN-LM	出力分布のレベルで、最近傍の検索結果と補間する
FiD（Fusion-in-Decoder）	パッセージを個別にエンコードし、デコーダで融合する

たとえばRETROは、事前学習済みのモデルの重みを凍結したまま、cross-attention層を（論文では6層目から3層ごとに）追加する形で検索を組み込みます。この仕組みで、GPT-3級の性能を約25分の1のパラメータ数で達成した、というのが当時話題になった成果です。

ここまでの話と対比すると、違いがはっきりします。

標準RAG:   埋め込み層で1回だけ入力 → あとは attention で自然に上へ波及（間接的）
RETRO系:   特定の中間層に、検索結果を外から直接差し込む（構造的・意図的）

初学者のうちは「こういう別系統もあるんだな」くらいの理解で十分です。まずは標準RAG（＝プロンプトに連結するだけ）をしっかり押さえましょう。

6. 大事な注意：入力に入れても「必ず従う」とは限らない

最後に、実務で効いてくる落とし穴を一つ。基礎編でも触れましたが、内部の話を通った今のほうが腑に落ちるはずです。

「検索文書を入力に入れれば、モデルは必ずそれに従う」とは限りません。モデルが検索文書を無視して、重み側の知識（＝もともと覚えている知識）で答えてしまうケースは実際にあります。これは 知識衝突（knowledge conflict）／context-unfaithfulness として研究されている課題です。

サーベイ論文でも、「文脈と重みのどちらを優先するかに決定的なルールは存在しない」とされており、モデルはしばしば、意味的に整合していて説得力のある情報の方を選ぶ傾向がある、と報告されています。強いモデルほど、正しい外部証拠があっても自分の内部記憶に固執する場合がある、という指摘もあります。

なぜこうなるのかは、ここまでの話から見えてきます。 検索文書は「特別扱いされた真実」として入るのではなく、ただの入力トークン列として、重みが持つ知識と同じ土俵で処理されるからです。優先されるという保証は、アーキテクチャのどこにもありません。

つまり 「RAGは入力だから確実に反映される」と過信するのも正確ではない、ということです。ここを理解しておくと、「ちゃんと検索文書を渡したのに、なぜか古い答えが返る」といった現象に出くわしたとき、原因の当たりをつけやすくなります。

まとめ

詳細編の内容を一枚にまとめます。

検索文書は attention 経由で 全層のhidden stateに影響する。ただし重みが変わったからではなく、入力が変わったことの波及。
層を流れるのはトークンではなく hidden state（ベクトル）。K/Vは層ごとに独立。
出力は検索文書の コピーではなく、読んで新しく生成したもの。
RETRO / kNN-LM / FiD のように、検索を中間層へ直接注入する別系統も存在する。
入力に入れても必ず従うとは限らない（知識衝突）。検索文書に特権はない。

ひとことで言えば、RAGとは —

内部パラメータという「生成エンジン」に、検索文書という「事実の素材」を与えて動かす仕組み。

素材は外から来ていて、文章力や論理はモデル由来。そう捉えると、ここまでの話がすべてつながります。

シリーズを通して

基礎編では、RAGを外側の仕組みとして組み立てました（インデックス構築 → 検索 → プロンプト組み立て → 生成）。
詳細編（この記事）では、その入力がモデルの内側でどう扱われるかを見ました。

両方をつなぐと、こうなります。

[基礎編の領域：あなたが作る]           [詳細編の領域：モデルがやる]
文書 → チャンク → ベクトル化 → 検索  →  トークン列 → 全層に波及 → 生成
                                    ↑
                              ここが境界線
                        （＝アプリとモデルの境目）

この境界線がどこにあるかを掴むことが、RAGを理解する上でいちばんの近道だと思います。境界の左側は自分でコントロールできる。右側はできない。だから精度改善は左側（＝検索）から手をつける、という判断ができるようになります。

参考・出典

本記事の技術的主張は以下で確認しました（2026年7月時点）。基礎編と共通の出典も含みます。

IBM「What is Retrieval-Augmented Generation (RAG)?」― RAGの定義・再学習不要の点
AWS「What is RAG?」― retrieval / augment / generation の流れ
NVIDIA Blog「What Is Retrieval-Augmented Generation aka RAG」― 命名の由来、parameterized knowledge の説明
Pinecone「Retrieval-Augmented Generation (RAG)」― 拡張プロンプトの具体例
Borgeaud et al. (2022) "Improving language models by retrieving from trillions of tokens"（RETRO論文, PMLR）― chunked cross-attention、6層目から3層ごとに追加、25×少ないパラメータでGPT-3級
Khandelwal et al. (2020) "Generalization through Memorization: Nearest Neighbor Language Models"（kNN-LM）― 出力分布の補間
Izacard & Grave (2021) FiD ― Fusion-in-Decoder
"Knowledge Conflicts for LLMs: A Survey"（arXiv:2403.08319）― 文脈と重みの優先順位に決定的ルールはない
"FaithfulRAG"（arXiv:2506.08938）ほか ― context-unfaithfulness / 知識衝突

※ 本記事は入門者向けに図・比喩を優先しており、細部（KVキャッシュ、causal attentionの厳密な依存関係など）は簡略化しています。正確な実装や最新の研究動向は、上記の一次資料をあたってください。

← 基礎編：RAGって実際どんな仕組み？