35. 事前学習・多段階学習・RAG:「LLM の3つの壁」を突破する#
35.1. この資料の位置づけ#
「Transformer で何でも解けるはずなのに、なぜ ChatGPT のような使いやすい AI になるまでに追加の工夫が必要なのか」という問いを起点とします。まず Transformer が有利に機能するための前提条件(コーパスサイズ) を確認したうえで、指示の壁・知識の壁・検索の壁という3つの限界を順番に提示し、それぞれの解決策(転移学習 → SFT → 選好学習 → RAG → 拡張手法)を必然的に導きます。
35.2. 学習目標#
事前学習モデル(GPT/BERT)が Week 13 の Transformer の Decoder / Encoder に対応することを説明できる。
「事前学習だけでは指示に従わない」という壁を、目的関数の観点から説明できる。
事前学習コストの非対称性から「転移学習(事前学習済みモデルから出発するSFT)」が必然的な選択肢であることを説明できる。
Transformer/NMTは大規模コーパスを前提とした技術であり、コーパスが小さい場合に性能が低下するという制約(スケーリング則)を説明できる。
選好データ(Preference Data)を使って LLM を整える方法として、RLHF・PPO・DPO・GRPO の役割の違いを説明できる。
RAG が「ハルシネーション・カットオフ・機密データ」という3つの限界をなぜ緩和できるかを説明できる。
標準 RAG の限界と拡張手法(Parent-Child・ハイブリッド・HyDE・再ランキング・GraphRAG)を対応させて説明できる。
Chinchilla スケーリング則(学習コスト最適化)に対して、MoE によるパラメータ軸の分解・生涯コスト最適化のための過剰学習・推論時計算量という新しい軸がどのように加わったかを説明できる。
35.3. 振り返り:Week 13 の Transformer と今日の問い#
Week 13 では Transformer アーキテクチャを完成させました。
[Week 13 で作ったもの]
入力トークン列
↓ Embedding + Positional Encoding
↓ Multi-Head Self-Attention × N 層
↓ Add & Norm + FFN
↓
出力:各トークンの文脈を反映した d 次元ベクトル列
このアーキテクチャを数十億〜数兆トークンの大量テキストで学習させると何が生まれるか——それが今日のテーマです。
今日の問い:Transformer を大量テキストで学習させると ChatGPT のような AI が直接生まれるか?
答えは No です。今日はなぜ3段階の追加工程が必要なのかを、「3つの壁」として見ていきます。まずは Transformer を大量テキストで次単語予測学習させることの役割を見ていきます。
35.4. 事前学習:Transformer で「言語の仕組み」を習得する#
35.4.1. 目的関数で2種類のモデルが生まれる#
同じ Transformer アーキテクチャでも、学習時の目的関数によって全く性質の異なるモデルが生まれます。
GPT 系(Decoder のみ使用):Causal Language Model
Week 13 の Decoder ブロック(Masked Self-Attention)を縦に積む
「前のトークン列から次のトークンを予測する」を繰り返す
Masked Self-Attention が「未来を見ない」ことを保証 → 推論時も左→右に逐次生成
Tip
Q: CLM 学習でコーパスはどのように使われるか?
コーパスの全文書を EOS トークンでつないで1本のトークン列にし(Packing)、長さ \(L\) の非重複チャンクに分割する。1チャンク \([x_1, \ldots, x_L]\) につき、入力を \([x_1, \ldots, x_{L-1}]\)、目標を \([x_2, \ldots, x_L]\) として全 \(L\) ポジションの損失を1回の forward で同時に計算する。「どの位置 \(t\) を予測するか」を1つずつ選ぶのではなく、Causal Attention マスクにより全ポジションを並列に扱えることが CLM の効率の源泉である。
BERT 系(Encoder のみ使用):Masked Language Model
Week 13 の Encoder ブロック(双方向 Self-Attention)を縦に積む
文中のトークンを 15% の確率でマスク → マスク部分を予測する
双方向参照のため生成には使えないが、文全体の「理解」に優れる
GPT(CLM) |
BERT(MLM) |
|
|---|---|---|
Week 13 の対応部品 |
Decoder(Masked Self-Attention) |
Encoder(双方向 Self-Attention) |
Attention の方向 |
過去のみ |
双方向 |
強み |
テキスト生成 |
文書理解・分類・QA |
35.4.2. 事前学習で「知識が重みに蓄積する」#
大量テキスト(数百億〜数兆トークン)での学習により、重みに暗黙的に蓄積されるもの:
文法:適切な語順・活用・格助詞の使い方
常識:「火は熱い」「東京は日本の首都」
推論パターン:「A なら B、B なら C → A なら C」
世界知識:歴史・科学・文化に関する事実
問い①:これだけの知識が蓄積されているなら、事前学習モデルがそのままで使える AI になるはずでは?
35.4.3. Column:Transformer が有利でないケース——コーパスサイズの壁#
上で「大量テキストで学習させる」と書きましたが、十分な量のテキストが用意できない場合、Transformer は期待通りに機能しません。この「コーパスサイズの壁」を、一連の研究を通じて確認します。
35.4.3.1. NMT はSMTより多くのデータを必要とする(Koehn & Knowles, 2017)#

英語-スペイン語の対訳コーパス(全量約3.9億語)を段階的に削減して NMT と SMT(統計的機械翻訳)を比較した実験です。質の高い対訳コーパスを膨大に準備するのは高コストだが、単言語テキスト(訳なし、それぞれの言語テキスト)はWeb上に大量に存在するため、それらを事前学習しておくことでそれぞれの言語知識を学習しておく事前学習アプローチが有効。
コーパスサイズ |
NMT(BLEU) |
SMT(BLEU) |
|---|---|---|
約38万語(全量の 1/1024) |
1.6 |
16.4 |
約2,410万語(1/16) |
25.7 |
24.7 |
全量 3.86億語 |
31.1 |
28.6 |
コーパスが小さい(約1,500万語未満)段階では NMT が SMT に大きく劣る
約1,500万語を超えたあたりで NMT が SMT を逆転し、以降は NMT の伸びが上回る
なぜ NMT はデータが少ないと弱いのか:SMT はフレーズの断片を組み合わせて部分的に翻訳できるのに対し、NMT は文全体を確率分布として生成するため、パターンを学習し尽くすだけの大量のデータが必要になる。
35.4.3.2. この傾向は Transformer でも変わらない(Kaplan et al., 2020; Ghorbani et al., 2021)#

Kaplan らは Transformer 言語モデルの損失がデータ量・モデルサイズ・計算量の3つに対してべき乗則(power law)に従うことを実証しました:
\(D_c\)を基準点(\(D = D_c\)のとき\(L = 1\))として、Dを何倍にするかで損失がどう変わるか具体的に計算すると次のようになる。
Dの変化 |
\(D_c/D\) |
\(L(D)\) |
損失の変化 |
|---|---|---|---|
\(D = D_c\) (基準) |
1 |
1.00 |
基準 |
Dを1/10に減らす |
10 |
1.24 |
約24%悪化 |
Dを1/100に減らす |
100 |
1.55 |
約55%悪化 |
Dを1/1000に減らす |
1000 |
1.93 |
ほぼ2倍に悪化 |
Dを10倍に増やす |
0.1 |
0.80 |
約20%改善 |
Dを100倍に増やす |
0.01 |
0.65 |
約35%改善 |
ここから読み取れる重要な点は、データを10倍にしても損失は20%程度しか下がらないということである。αD=0.095という指数は小さいため、Lの改善はDの増加に対して非常に緩やかになる。
一方で「データ量 \(D\) が少ないほど損失が大きい(品質が悪い)」ことも意味する。Ghorbani らはさらに Transformer ベースの翻訳モデルで同じ傾向を直接確認した。
結論:アーキテクチャが RNN から Transformer に変わっても、「データが少ないと性能が悪い」という性質は解消されない。
35.4.3.3. 重要なのはモデルとデータのバランス(Chinchilla; Hoffmann et al., 2022)#
当時の大規模モデル(GPT-3: 175B パラメータ・300B トークン、Gopher: 280B・300B トークン)はパラメータ数が桁違いでもデータ量が横並びでした。Chinchilla はパラメータ数を 1/4(70B)にしてデータを 4 倍(1.4T トークン)にしたところ、Gopher・GPT-3 を一貫して上回りました。
教訓:モデルだけを大きくしてデータが伴わなければ、計算資源を浪費して性能を引き出せないまま終わる。
35.4.3.4. 実務的な対処法——転移学習との接続#
これらの実験はすべて「ゼロから学習する(スクラッチ訓練)」という設定です。実務で手元のコーパスが小さい場合の標準的な対処法は、大規模コーパスで事前学習済みの Transformer モデルをファインチューニング(転移学習)することです。
「Transformer はやはり大量のデータを必要とするからこそ、自分では用意できない場合は、他所の大量データで事前学習された重みを借りてくる」——この発想が次節(壁1「指示に従わない」と多段階学習)の多段階学習の出発点になります。
35.4.3.5. さらなる発展(2024〜):スケーリング則の前提が変わり始めた#
Kaplan (2020) は「層数や幅の比率などアーキテクチャの細部は性能にほとんど影響しない」と述べており、Chinchilla (2022) もこの前提のもとで N(パラメータ数)と D(データ量)だけを最適化変数として扱っていました。ところが 2024 年以降、この前提が崩れ始めています。
MoE(Mixture of Experts:専門家の混合)によるパラメータ軸の分解
MoE は、巨大なモデルを「多数の専門家サブネットワーク」に分割し、各トークンを処理するときに一部の専門家だけを選んで動かす仕組みです。
MoE の動作イメージ:
入力トークン「翻訳して」
↓
ルーターが担当専門家を選択(全体の一部のみ)
↓
選ばれた専門家のみが計算を実行 → 出力
例:DeepSeek-V3(2024年)
総パラメータ数 671B(= 知識容量・記憶の大きさ)
1トークンあたりの活性化パラメータ 37B(= 実際に使う計算量)
これにより、Kaplan/Chinchilla が単一変数として扱っていた N(パラメータ数)が「総 N(知識容量)」と「活性化 N(推論コスト)」の2軸に分解されました。モデルを大きくしても、推論にかかる計算量を増やさずに済むようになります。
目的関数の転換:学習コスト → 生涯コスト
Chinchilla が答えたのは「学習にかかる計算量(FLOPs)を最小にするには N と D をどう配分すべきか」という問いでした。しかし実際のサービスでは、ユーザーに使われるたびに発生する推論コストが長期的に支配的になります。
この視点から見ると、小型モデルを Chinchilla 最適比率よりはるかに多いデータで「過剰学習」させる方が、同じ性能をより安い推論コストで提供できる場合があります(例:Alibaba Qwen3-0.6B は 6 億パラメータに対して 36 兆トークンで学習 ≈ Chinchilla 最適比率の 3,000 倍)。
Chinchilla の「法則」が誤りだったのではなく、Chinchilla が最適化した目標(学習コスト)と実務での合理性の目標(生涯コスト)がズレていたということです。
サマリ
コーパスサイズが小さいと性能が出ないという性質(1〜4)は変わりません。変わったのは最適化の次元:パラメータ数N・データサイズD の 2 変数から、「どの N か(総 N vs 活性化 N)」「何に対して最適化するか(学習コスト vs 生涯コスト)」も含めた多次元的な問いになりました。さらに 選好学習:人間の「好み」で LLM を整える で扱う「推論時計算量」という、学習後に生まれたもう一つの軸も加わっています。
35.5. 壁1「指示に従わない」と多段階学習#
35.5.1. なぜ毎回ゼロから学習しないのか——転移学習の必然性と SFT の二重の意味#
壁1を解決するために「追加学習(SFT・選好学習)を行う」わけですが、その前に根本的な問いがあります。
なぜ毎回事前学習からやり直さないのか?
35.5.1.1. 事前学習コストの非対称性#
ステージ |
典型的なデータ規模 |
計算コストの目安 |
|---|---|---|
事前学習 |
数百億〜数兆トークン |
数千〜数万 GPU・日(数億〜数十億円規模) |
SFT |
数千〜数万件の指示-応答ペア |
数〜数十 GPU・日 |
選好学習(RLHF/DPO) |
数千〜数万件の選好比較データ |
数十〜数百 GPU・日 |
事前学習コストは他のステージと比べて数桁異なります。特定のタスクや用途に合わせるたびに事前学習からやり直すのは、現実的に不可能です。
35.5.1.2. 転移学習という選択の必然性#
Fig. 35.1 Transfer Learning(A Gentle Introduction to Transfer Learning for Deep Learningから転載)#
事前学習で獲得した言語・知識・推論パターン(重みに蓄積済み)は、様々な下流タスクに共通して役立つ汎用的な「基盤」です。この重みを出発点として追加学習(ファインチューニング)する——これが転移学習(transfer learning)です。
[転移学習の全体像]
事前学習済みモデル(高コスト・大規模データ・汎用的な知識)
↓ ← 重みをそのまま引き継ぐ
SFT(低コスト・小規模データ・目的特化の振る舞い)
↓
選好学習(さらに人間の「好み」を反映)
狙い1: 計算コストの分散
「巨大モデルの訓練を1回で完結させると GPU 時間・データが膨大になる。最もヘビーな処理(一般知識の獲得)は1回だけ行い、以後は軽量な追加学習で済ませる」という転移学習の延長線上にある。
狙い2: 目的の分離
各目的は損失関数が異なるため、段階を分けたほうが効率的かつ安定しやすい。
基礎能力: 語彙・文法・世界知識・推論パターン
指示追従性: “〜してください”というプロンプトに従う能力
安全性・好み合わせ: 有害発話を抑制し、対話の流暢さを調整
瞬時適応: 追加学習なしでタスクを解く (in-context learning)
35.5.1.3. SFT の二重の意味#
「SFT(Supervised Fine-Tuning)」は1つの手法名ですが、目的によって大きく2つに分かれます:
用途 |
データ |
目的 |
|---|---|---|
A:インストラクションチューニング |
指示 → 良い応答のペア |
「指示に従う」汎用的な能力を付与(壁1への対処) |
B:下流タスク向けファインチューニング |
感情分析・翻訳・分類などのタスクデータ |
特定の業務・タスクに特化したモデルに仕立てる |
ChatGPT のような汎用 AI は主に用途 A、企業の業務特化モデル(法律文書分類・医療記録要約など)は用途 B が主体です。本節以降で扱う「壁1の解決」は用途 A に対応します。
35.5.2. 事前学習モデルの実際の動作#
問い①(事前学習モデルがそのままで使えるAIになるはずでは?)への答え:
事前学習モデルに「日本語で要約して」と入力すると、タスクを解くのではなく、入力に続きそうなテキストを確率的に生成します。このため要約せず、似たようなテキストを生成したりすることもあります。
入力: 「以下の文章を日本語で要約してください。The cat sat on the mat.」
事前学習モデルの出力(例):「以下の英語の文を日本語に翻訳してください。The dog ran on the floor.」
原因:事前学習の目的は「次トークンを予測する」こと。指示に従う・丁寧に答える・有害な発言をしないは一切学習していません。
35.5.3. CLM と SFT:損失範囲の違い#
CLM(事前学習)と SFT はともに「自己回帰的な次トークン予測」を用いますが、損失を課すトークン範囲 と 学習データの形式 が異なります。
CLM 事前学習:全トークンが損失対象
「The cat sat on the mat」
The→cat ✓ cat→sat ✓ sat→on ✓ on→the ✓ the→mat ✓
─── 全トークンで損失を計算 ───
SFT:応答(\(Y\))部分のみが損失対象
ここで \(X\) はユーザーの指示、\(Y\) は Assistant の回答です。
「User: 東京の観光名所は? Assistant: 浅草寺、東京タワーです。」
User 部分(東京の…?) → label = -100:損失なし
Assistant 部分(浅草寺…) → ✓ 損失(ここだけを学習対象にする)
入力トークン(User 部分)はコンテキストとしてモデルに渡され次のトークン予測に使われますが、そのトークン自体は正解ラベルとして扱いません。実装上は入力部分の label を -100 に設定することでクロスエントロピー損失から除外します。
なぜ入力部分を損失から除くのか
SFT の目的は「指示 \(X\) が来たら応答 \(Y\) を返す」という条件付き生成の能力を付与することです。
欲しい能力: P(Y | X) を高くする ← 指示 X に対して応答 Y を返せる
不要な学習: P(X) の予測 ← 指示文 X そのものの続きを予測する
User 部分まで損失を計算すると「指示文の自然な続きを生成する能力」も同時に学習することになり、目的から外れます。
整理:CLM と SFT の比較
CLM 事前学習 |
SFT |
|
|---|---|---|
予測の仕組み |
自己回帰的な次トークン予測 |
自己回帰的な次トークン予測(同じ) |
損失の範囲 |
全トークン(\(t = 1, \ldots, T\)) |
応答部分(\(t \in Y\))のみ |
データ形式 |
大量の一般テキスト |
指示-応答ペア |
主な目的 |
言語・知識・推論パターンの獲得 |
「指示に従う」振る舞いの獲得 |
SFT は「指示-応答形式のデータで、応答部分のみを対象にした CLM」と言えます。損失を課すトークン範囲とデータ形式を変えるだけで、同じ予測メカニズムが全く異なる能力を引き出します。
35.5.4. 多段階学習による壁1の解決#
ステージ2:SFT(Supervised Fine-Tuning、インストラクションチューニングとも呼ばれる)
何を学ぶか:「指示に従って回答する」という行動
データ:人手で書いた 指示 → 良い回答 のペア(数千〜数万件)
目的関数:教師あり学習(回答との交差エントロピー損失)
※ 「インストラクションチューニング」は広義に SFT+選好学習全体を指すこともある
まとめ:2ステージの目的関数
ステージ |
目的関数 |
解決する問題 |
|---|---|---|
事前学習 |
次トークン予測 / マスク穴埋め |
言語・知識・推論の基礎獲得 |
SFT |
指示-応答の一致(教師あり) |
指示に従う能力(または下流タスクへの特化) |
転移学習の位置づけ:ステージ2以降は「事前学習済みモデルの重みから出発する」ことが前提。毎回ゼロから学習するコストは現実的でない(なぜ毎回ゼロから学習しないのか——転移学習の必然性と SFT の二重の意味 参照)。
SFT で「指示に従う」能力は身につきます。しかし——
問題意識:SFT だけでは、有害な回答や不誠実な応答を十分に抑えられない。どうやって「人間にとって好ましい応答」を引き出すか?
35.6. 選好学習:人間の「好み」で LLM を整える#
35.6.1. なぜ SFT だけでは不十分か#
LLM の事前学習では「次にどの単語が現れそうか」を予測する学習を行います。SFT でさらに「指示に従う」能力を付与しても、同じ質問に対して次のような複数の応答が生まれうる状況は解決しません:
正確で分かりやすい回答
正確だが長すぎる回答
不正確な回答
攻撃的な回答
これらを「次に出現しやすい単語」や「指示との一致」という基準だけで区別することは困難です。そこで、
人間がどの回答を好ましいと考えるか
という「選好(preference)」を学習に活かす方法が必要になります。
35.6.2. 選好データ(Preference Data):比較で教える#
同じ質問に対して LLM に複数の回答を生成させ、人間が比較評価します。
質問:「日本の首都はどこですか?」
回答 A:「日本の首都は東京です。」
回答 B:「日本の首都は大阪です。」
→ 人間が「A の方が良い」と判定
このような 「A と B なら、どちらが好ましいか」 という比較によって作られたデータを 選好データ(Preference Data) と呼びます。人間が必ずしも絶対的な点数を付ける必要はなく、比較だけで評価できる点が重要です。
35.6.3. RLHF:選好学習の大きな枠組み#
RLHF(Reinforcement Learning from Human Feedback:人間のフィードバックからの強化学習) は、選好データを使って LLM を改善する大きな枠組みです。典型的な流れは次の通りです:
LLM が複数の回答を生成
人間が回答を比較し、選好データを構築
報酬モデル(Reward Model)を学習
LLM の回答を報酬モデルで自動評価
評価が高くなるよう LLM を強化学習
Note
RLHF は「1つの具体的なアルゴリズム」の名前ではなく、「人間の選好を利用して LLM を改善する枠組み全体」を指します。
35.6.4. 報酬モデル(Reward Model):人間の評価を「自動採点器」にする#
人間が毎回 LLM の回答を評価するのは大変です。そこで選好データを使って、
「人間ならどちらの回答を好みそうか」を予測する採点器
を学習します。これが 報酬モデル(Reward Model) です。
回答 A → 報酬モデル → Reward Score = 0.9(高評価)
回答 B → 報酬モデル → Reward Score = 0.2(低評価)
報酬モデルができれば、人間が毎回採点しなくても LLM が生成した回答を自動評価できます。
35.6.5. PPO・DPO・GRPO:3つの実装方法#
35.6.5.1. PPO(Proximal Policy Optimization)#
報酬モデルができたら、「報酬モデルから高い評価を得られる回答を生成する」ように LLM を強化学習で更新します。この強化学習アルゴリズムが PPO です。
LLM が回答を生成
↓
報酬モデルが評価(「この回答は良い」)
↓
そのような回答を今後もっと生成しやすくする
RLHF の中での位置づけ:
RLHF(枠組み)
└── 報酬モデル(採点器)
└── PPO などを使って LLM を最適化
35.6.5.2. DPO(Direct Preference Optimization)#
PPO は報酬モデルと強化学習という2段階が必要です。DPO はこれを省略し、選好データから LLM を直接最適化 します。
選好データ(chosen / rejected のペア)
↓
DPO
↓
LLM 更新
SFT は「正解を教師として一方向に学ぶ」
PPO(RL)は「行動→評価→更新を試行錯誤で繰り返す」
DPO は「良否ペアを見せて、比較の差分を1ステップで直接反映する」
強いて言えば 「比較学習」 と呼べます。RL のような試行錯誤のループも、SFT のような正解一点提示もなく、「AとBを並べて差を直接学ぶ」という第三の形です。
PPO と比較すると:
RLHF + PPO |
DPO |
|
|---|---|---|
報酬モデル |
必要 |
不要 |
強化学習ステップ |
必要 |
不要 |
安定性 |
不安定になりやすい |
安定 |
DPO は「人間が選んだ良い回答の確率を上げ、悪い回答の確率を下げるように直接学習する方法」と理解できます。LLaMA・Mistral など多くのオープンモデルで採用されています。
35.6.5.3. GRPO(Group Relative Policy Optimization)#
GRPO は DeepSeek(2024)が提案した手法で、同じ問題に対して LLM から複数の回答を生成し、グループ内の相対的な良さ を利用して学習します。
GRPO =
① 1つの問題に対して複数回答を生成する
② 各回答に何らかの方法で報酬を付ける
③ 同じ問題に対する回答グループ内で報酬を相対化する
④ その相対的なAdvantageを使ってモデルを更新する
問題
↓
LLM
↓
┌─────────────────────┐
│ 回答 A:正解(+1) │
│ 回答 B:正解(+1) │
│ 回答 C:不正解(−1) │
│ 回答 D:不正解(−1) │
└─────────────────────┘
↓
グループ内で相対評価
↓
A・B のような回答を生成しやすくし、C・D を生成しにくくする
「この回答は絶対的に何点か」だけでなく、「同じ問題に対する他の回答と比べてどのくらい良いか」を利用する点が特徴です。数学・コードなど正解/不正解を自動判定できるタスクで特に有効で、報酬モデルを別途学習する必要がありません。
DeepSeek-R1 はこの GRPO を活用し、推論時計算量(test-time compute) ——学習後のモデルが回答生成時に多くの「思考ステップ」を踏んで精度を上げる手法——を組み合わせて高い推論能力を実現しました。推論時計算量は さらなる発展(2024〜):スケーリング則の前提が変わり始めた で述べたスケーリング則(N・D・C はすべて学習時の量)が想定していなかった新しい性能向上軸です。
Tip
ケースA: 客観的なVerifierがある(数学・コード・ゲーム・訂正証明など)
GRPO + Verifierだけで強力に機能する
ケースB: Verifierがない(文章の面白さ・Helpful・創造性・自然さなど)
GRPO + Reward Model
「報酬を人間の評価から切り離して、検証可能な推論タスクに適用したこと」がDeepSeek-R1の成功において重要だった。
35.6.6. 4つの用語の整理と全体像#
用語 |
何を指す? |
直感的な説明 |
|---|---|---|
RLHF |
大きな学習枠組み |
人間の好みを LLM の改善に使う |
PPO |
強化学習アルゴリズム |
報酬が高くなるよう LLM を更新する |
DPO |
選好最適化アルゴリズム |
良い回答と悪い回答を直接比較して学習する |
GRPO |
強化学習アルゴリズム |
複数回答をグループ内で比較して学習する |
注意:RLHF と PPO は同じ階層の用語ではありません。RLHF は枠組み、PPO はその実装手法の一つです。DPO は「PPO の別名」ではなく、RLHF の流れを経由しない別のアプローチです。
指示追従学習+選好学習により壁1は大幅に緩和されます。しかし——
問い②:「指示に従い、好ましく安全な応答をする」ことはできるようになった。しかし「知らないことを知ったかぶりして答える」問題は残っている。
35.7. 壁2「知識のカットオフとハルシネーション」と RAG#
35.7.1. 壁2の本質#
多段階学習を経た LLM でも、以下の3つは解決されません:
限界 |
内容 |
なぜ多段階学習で解決しないか |
|---|---|---|
カットオフ |
学習後に生まれた情報を知らない |
訓練データに含まれていない |
ハルシネーション |
知らないことを確率的に補完してでっち上げる |
「次トークン予測」が本質的に「それらしいトークン」を生成する機構 |
機密・社内データ |
学習に含まれないデータは知らない |
外部の非公開文書は訓練できない |
ハルシネーション例
質問: 「○○大学のデータマイニング担当教員は誰ですか?」
LLM: 「田中太郎教授です。主著に『データマイニング入門』(2023年)があります。」 *実在しない人物・書籍を堂々と答える。
LLM は「それらしいトークン」を生成する確率モデルです。知識の有無に関わらず「答えらしいもの」を生成してしまいます。
35.7.2. 壁2の解決:RAG の基本アイデア#
「知識をモデルに焼き込む(学習)」代わりに「毎回外部から検索して注入(RAG; Retrieval-Augmented Generation)」する。
通常のLLM
質問→LLM→回答
LLMは事前学習時や追加学習で得た知識に基づいて回答を生成する。
RAG
外部文書の中から関連部分を 検索
関連文書をプロンプトに 追加
LLMは「学習済みの知識 + 外部知識」に基づいて 回答を生成 する。
35.7.3. RAG の2フェーズ構成#
前処理フェーズ(オフライン・一度だけ実行)
外部文書(PDF・Web・社内マニュアル等)
↓ チャンク分割(200〜500 トークン)
各チャンク ↓ 埋め込みモデル(BERT 系 Encoder)
↓ d 次元の意味ベクトル
↓ FAISS インデックスに格納
クエリフェーズ(オンライン・質問ごとに実行)
質問文
↓ 同じ埋め込みモデルでベクトル化
↓ FAISS で k 近傍探索(意味的に最も近いチャンクを k 件取得)
↓ プロンプト構築:
「以下の情報に基づいて答えてください:
[チャンク1] ... [チャンクk]
質問: {質問}」
↓ LLM で生成
根拠付き回答
RAGにより壁2は大幅に緩和されます。しかし——
問い③:RAG を実装してみると、うまく答えられないケースが残る。なぜか?
35.8. 壁3「標準 RAG の限界」と拡張手法#
35.8.1. 壁3の3つのパターン#
パターン A:文脈が途切れる
文書の元の段落(1000 トークン):
「A社の製品 X は、独自の合金 Y を使用している。Y の特性として...(中略)...
この特性により、摂氏 800 度でも変形しない。」
100 トークンのチャンクに分割すると:
[チャンク3] 「この特性により、摂氏 800 度でも変形しない。」
← 「この特性」が何かわからない文脈ゼロのチャンク
質問: 「製品 X が高温に強い理由は?」 → チャンク3 がヒットするが回答不能
パターン B:意味 vs. キーワードのミスマッチ
質問: 「モデル番号 GT-R35 の最大出力は?」
→ ベクトル検索: 「GT-R35 というモデルは高性能スポーツカーです」がヒット
→ しかし型番の正確な仕様は別ページにあり見つからない
→ キーワード「GT-R35」で検索すれば一発なのに
パターン C:複数の事実をつなぐ推論が必要
質問: 「A 社の CEO が卒業した大学の学長は誰ですか?」
→ 「A 社の CEO は田中さん」(チャンク1)
→ 「田中さんは○○大学卒業」(チャンク2)
→ 「○○大学の学長は××さん」(チャンク3)
→ 3 つのチャンクを組み合わせないと答えられない
→ 個別の k 近傍ではどのチャンクを取得すべきか決まらない
35.8.2. Parent-Child チャンク(パターン A への対応)#
アイデア:検索用には小さいチャンク(精度優先)、LLM への受け渡しには大きいチャンク(文脈優先)を使い分ける。
前処理で文書を2段階のサイズで切り出し、「どの子チャンクがどの親チャンクに含まれるか」をあらかじめ記録しておく。
[元の文書段落]
「A 社の製品 X は、独自の合金 Y を使用している。
Y の特性として高融点・高強度がある。
この特性により、摂氏 800 度でも変形しない。
耐熱性が要求される航空部品に採用されている。」
── 2 段階で切り出す ──────────────────────────────────────
親チャンク(400 トークン ≈ 段落全体):
「A 社の製品 X は〜耐熱性が要求される航空部品に採用されている。」
└─ 子チャンク A(100 トークン):「A 社の製品 X は、独自の合金 Y を使用している。Y の特性として高融点・高強度がある。」
└─ 子チャンク B(100 トークン):「この特性により、摂氏 800 度でも変形しない。耐熱性が要求される航空部品に採用されている。」
FAISS に登録するのは子チャンク A・B のベクトルのみ。
親チャンクはベクトル化せず、「子チャンク A または B がヒットしたら、この親チャンクを返す」という対応を保存。
質問: 「製品 X が高温に強い理由は?」
検索: FAISS → 子チャンク B がヒット
(「摂氏 800 度でも変形しない」がクエリに意味的に近い)
生成: LLM に渡すのは子チャンク B ではなく 親チャンク全体
← 「この特性」=「Y の高融点・高強度」という文脈が含まれ、回答可能になる
小さいチャンクは「どこにヒットするか」を高精度に絞り込む役割、親チャンクは「LLM が答えるために必要な文脈」を担う役割。それぞれに特化させることでパターン A(文脈の途切れ)を解決する。
35.8.3. ハイブリッド検索(パターン B への対応)#
BM25:TF-IDF 改良版のキーワードマッチ。型番・固有名詞・品番コード・ソースコードなどキーワード一致が重要な検索に強い
コサイン類似度:Transformer 埋め込みのベクトル検索。言い換え・抽象的な質問に強い
\(\alpha\) のチューニングでタスクに応じた重み付けが可能
35.8.4. HyDE(Hypothetical Document Embeddings)(パターン B の別アプローチ)#
問題: 「質問」と「文書(回答)」は意味空間が少しズレている
質問形式: 「○○とは何ですか?」
文書形式: 「○○は△△である。□□という特性があり...」
HyDE の手順:
1. 質問 → LLM で仮想回答を生成
「○○は△△です。□□という特性があり...(※根拠なしの生成でよい)」
2. 仮想回答のベクトルで FAISS 検索
→ 文書と同じ「回答形式の意味空間」で検索
3. ヒットした実際の文書を LLM に渡して正式に回答生成
仮想回答自体は正確でなくてよい——「意味空間の橋渡し」としての役割。
35.8.5. クロスエンコーダ再ランキング(検索精度の向上)#
FAISS(Bi-encoder)の弱点:
質問と文書を「独立に」エンコード → 相互の文脈を無視した類似度
クロスエンコーダ:
質問と文書を「同時に」BERT エンコーダへ入力
→ Self-Attention で質問と文書が互いを参照
→ [CLS] トークンで精密な関連度スコアを出力
2 段階検索:
Step 1: FAISS で top-20 を高速取得(粗い)
Step 2: クロスエンコーダで 20 件を精密スコアリング → top-5 のみ LLM へ
35.8.6. GraphRAG(パターン C への対応)#
前処理:
文書 → LLM でエンティティ(人・場所・製品)と関係を抽出
→ ナレッジグラフ: (A社CEO, 卒業した, ○○大学), (○○大学, 学長は, ××さん)
クエリ時:
「A社のCEOが卒業した大学の学長は誰?」
→ グラフを辿る: A社CEO → 卒業した → ○○大学 → 学長は → ××さん
→ 多段推論のチェーン全体を文章化して LLM に渡す
単一の k 近傍では取れない「関係の連鎖」を構造的に取得。データマイニング的には Week 7 で学んだシソーラスやオントロジー・ナレッジグラフと同様に、文書中の知識を概念・実体とその関係として構造化する考え方に基づいている。
シソーラス:語彙間の関係(同義語、上位・下位概念など)を整理する
オントロジー:概念、クラス、属性、関係などを明示的に定義し、知識の意味体系を記述する
ナレッジグラフ:実体(entity)と関係(relation)をグラフ構造として表現する
GraphRAG:文書からLLM等を用いて実体・関係を抽出し、構築したグラフを検索・推論・回答生成に利用する
35.8.7. 壁3への対応まとめ#
壁3のパターン |
対応例 |
|---|---|
A. 文脈が途切れる |
Parent-Child チャンク |
B. キーワードのミスマッチ |
ハイブリッド検索 |
B. 意味空間のズレ |
HyDE |
検索の粗さ |
クロスエンコーダ再ランキング |
C. 複数事実の連鎖推論 |
GraphRAG |
35.9. まとめ#
35.9.1. 3つの壁と解決策#
壁 |
原因 |
解決策 |
|---|---|---|
壁1「指示に従わない」 |
事前学習目的が「次トークン予測」のみ |
SFT(多段階学習)→ 選好学習(RLHF/DPO/GRPO) |
壁2「知らないことをでっち上げる・情報が古い」 |
知識がパラメータに固定・カットオフあり |
RAG(外部知識の動的注入) |
壁3「RAG でも取りこぼす」 |
チャンク分断・意味ズレ・孤立した事実 |
拡張 RAG 5 手法 |
Transformer(アーキテクチャ)
│
├── 大量データで学習する(事前学習=学習方法)
│ └── Scaling Laws
│
├── 事前学習したモデルを段階的に適応(振る舞いの調整)
│ ├── SFT
│ └── Preference Optimization
│
└── モデルの外部に知識を置く(外部知識の利用)
└── RAG
多段階学習の前提:ステージ2以降はいずれも「事前学習済みモデルの重みから出発する(転移学習)」ことが前提。事前学習コストが他のステージと数桁異なるため、毎回ゼロから学習することは非現実的(なぜ毎回ゼロから学習しないのか——転移学習の必然性と SFT の二重の意味 参照)。
Transformer の前提条件:大量コーパス(目安として機械翻訳では1,500万語以上)がなければ、Transformer はゼロから学習しても期待通りに機能しない(Column:Transformer が有利でないケース——コーパスサイズの壁 参照)。実務では事前学習済みモデルの転移学習によってこの制約を回避する。
スケーリング則の多次元化(2024〜):上記の多段階学習を支えているスケーリング則も、単純な「N と D を増やせば良い」から「MoE によるパラメータ軸の分解・推論コスト優先の過剰学習・推論時計算量の活用」へと多次元化しつつある(さらなる発展(2024〜):スケーリング則の前提が変わり始めた・GRPO(Group Relative Policy Optimization) 参照)。
35.9.2. 技術の積み上げ(Week 10〜14)#
word2vec(Week 10): SSL で密ベクトル獲得
↓ 語順・長距離依存の解決
言語モデル(Week 11): 次トークン予測を確率化
↓ 系列全体の文脈捉え
seq2seq + Attention(Week 12): 動的な参照
↓ 逐次依存をなくす
Transformer(Week 13): 並列・深・安定
↓ 大量テキストで学習(大規模コーパスが前提 / スケーリング則)
GPT / BERT(Week 14): 生成 / 理解モデル
↓ 事前学習済み重みを出発点に(転移学習)
多段階学習(Week 14): 指示に従うモデル(SFT)・特定タスクへの特化(downstream FT)
↓ 人間の「好み」を反映
選好学習(Week 14): RLHF / DPO / GRPO・推論時計算量(test-time compute)
↓ 知識の限界を突破
RAG + 拡張手法(Week 14): 外部知識で補完
↓ さらなる展開(2024〜)
スケーリング則の多次元化: MoE(N の分解)・生涯コスト最適化・推論時計算量(test-time compute)
35.10. 演習問題#
Q1:GPT は「Decoder のみ」、BERT は「Encoder のみ」を使います。Week 13 の Decoder と Encoder の構造上の最大の違い(Masked Self-Attention の有無)が、それぞれの「得意なこと」にどう影響しますか?
Q2:SFT(教師あり微調整)の学習データとして「指示-応答ペア」を人手で作成します。このデータが少ない(数百件程度)場合に何が起きるか予想してください。
Q3:LLM は「知らないことを確率的に補完してでっち上げる」という特性があります。この現象(ハルシネーション)が起きる理由を、事前学習の目的関数(次トークン予測)から説明してください。
Q4:選好学習において、RLHF・PPO・DPO・GRPO はそれぞれどのような役割を担いますか?「RLHF と PPO は同じ階層の用語ではない」という点を踏まえて整理してください。
Q5:RAG のクエリフェーズで FAISS を使う理由を、「全文書総当たり検索との比較」の観点から説明してください。
Q6:「チャンクサイズを小さくすると検索精度が上がるが、LLM に渡す文脈が不足する」という Parent-Child チャンクが解決しようとしているジレンマについて、具体例で説明してください。
Q7:HyDE(仮想文書埋め込み)では LLM が生成した「でたらめな回答」を検索に使います。不正確な仮想回答が役に立つ理由を「意味空間」の観点から説明してください。
Q8:GraphRAG が必要になるのはどのようなタイプの質問ですか?具体例を挙げ、標準 RAG(k 近傍のみ)ではなぜ対応できないかを説明してください。
Q9:「壁1〜3」のうち、あなたが最も重要だと思う問題を1つ選び、その理由と解決策の効果・限界を論じてください。
Q10:事前学習には数百億〜数兆トークンのデータと巨大な計算資源が必要です。これに対して SFT(Supervised Fine-Tuning)はなぜ数千〜数万件のデータで済むのか、転移学習の観点から説明してください。
Q11:Koehn & Knowles (2017) の実験では、コーパス約38万語での NMT の翻訳品質(BLEU=1.6)が SMT(BLEU=21.8)に大幅に劣りましたが、約1,500万語を超えると NMT が SMT を逆転しました。(1) この逆転が起きる理由を NMT・SMT それぞれの仕組みから説明してください。(2) 実務で手元のコーパスが小さい場合、どのような対処法が標準的ですか?
Q12:Kaplan et al. (2020) の Scaling Laws は「モデルサイズ N・データ量 D・計算量 C を増やすと性能が上がる」という関係を示しました。2024 年以降の以下の展開が、この枠組みをどのように拡張・修正しているかを説明してください。
(a) MoE(Mixture of Experts)によるパラメータ設計の変化:N という単一変数がどのように分解されたか。
(b) 推論時計算量(test-time compute)という新しい軸:Kaplan/Chinchilla の枠組みのどこにないものか。
また、Chinchilla 最適比率(パラメータ1個あたり約20トークン)を大幅に超えて学習させた小型モデルが実務で合理的になる理由は何ですか?
35.11. 参考文献#
Radford, A. et al. “Language Models are Unsupervised Multitask Learners” (GPT-2, 2019).
Devlin, J. et al. “BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding,” NAACL (2019).
Ouyang, L. et al. “Training language models to follow instructions with human feedback,” NeurIPS (2022). ← RLHF / InstructGPT
Rafailov, R. et al. “Direct Preference Optimization,” NeurIPS (2023). ← DPO
Shao, Z. et al. “DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models,” arXiv (2024). ← GRPO
Lewis, P. et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” NeurIPS (2020). ← RAG 原論文
Gao, L. et al. “Precise Zero-Shot Dense Retrieval without Relevance Labels,” ACL (2023). ← HyDE
Edge, D. et al. “From Local to Global: A Graph RAG Approach,” arXiv (2024). ← GraphRAG
Koehn, P., & Knowles, R. “Six Challenges for Neural Machine Translation,” Workshop on Neural MT (2017). ← NMT vs SMT / コーパスサイズ
Kaplan, J. et al. “Scaling Laws for Neural Language Models,” arXiv (2020). ← スケーリング則
Ghorbani, B., Firat, O. et al. “Scaling Laws for Neural Machine Translation,” arXiv (2021). ← 翻訳モデルでのスケーリング則
Hoffmann, J. et al. “Training Compute-Optimal Large Language Models,” arXiv (2022). ← Chinchilla / モデルとデータのバランス
DeepSeek-AI. “DeepSeek-V3 Technical Report,” arXiv (2024). ← MoE / MLA / FP8
DeepSeek-AI. “DeepSeek-V4 Technical Documentation,” (2026).
Ho, A., Besiroglu, T. et al. “Algorithmic Progress in Language Models,” Epoch AI / arXiv (2024). ← アルゴリズム的効率化