# RAGをファインチューニングで置き換えられる？ KB検索の選択肢を調べて考えてみた

> 社内KB検索でRAGをファインチューニングに置き換えられるか。ファインチューニングが実際に学ぶもの、純粋IRやロングコンテキストが勝つ場面、それぞれのコストを整理します。

- Source: https://oharu121.com/ja/blog/rag-vs-finetuning-kb-search/
- Published: 2026-08-11T15:07:58+09:00
- Tags: RAG, LLM, 生成AI, 機械学習

---
## はじめに

ナレッジベース（KB）検索システムを RAG で構築している方は多いと思います。私もその一人なのですが、あるとき素朴な疑問が湧いてきました。

> 「小さいローカルモデルを社内ドキュメントでファインチューニングすれば、RAG と同じことができて、しかもモデルサイズも小さく・安く済むのでは？」

参照するドキュメントに特化してモデルを仕立てれば、検索基盤もベクトル DB も要らなくなって身軽になりそうです。直感的にはそう思えます。しかし実際にはそうなりませんでした。**ファインチューニングが学ぶのは事実ではなく振る舞い**であり、KB 検索が本当に求めているものを供給できないからです。代わりに残ったのは逆の教訓でした。ニーズが狭ければ、フル装備の RAG より単純な構成のほうが勝つことが多い、ということです。この疑問を出発点に、「ファインチューニングは RAG の代わりになるのか」「そもそもファインチューニングとは何をしているのか」「そもそも RAG 以外に選択肢はないのか」を順に調べて考えてみました。

同じ疑問を持っている方の思考の整理に役立てば幸いです。

## 疑問1: ファインチューニングで RAG を置き換えられるのか

最初の疑問から調べてみると、どうやらこの直感はあまりうまくいかなさそうだ、ということが見えてきました。ファインチューニングと RAG は、そもそも解いている問題が違うからです。

**ファインチューニングが学ぶのは「事実」ではなく「振る舞い」**

ファインチューニングは、モデルの重みを調整して、スタイル・出力フォーマット・トーン・タスクの遂行パターンを変える手法です。一方で、「特定の事実を後から確実に引き出せるように埋め込む」ことは得意ではありません。

社内ドキュメントでファインチューニングすると、モデルは「社内ドキュメントっぽい話し方」を学びますが、具体的な質問に対しては、流暢で自信満々な誤答を平気で返すことがあります。RAG は逆に、事実を検索可能なストアに原文のまま保持します。

*Image: 社内ドキュメントを重みに焼き込んだファインチューニングが、経費規程の質問に自信満々の誤答（1食200ドル）を返す一方、RAG は同じ文書を検索インデックスに原文のまま保持し、経費規程 v3.2 を引用して1食150ドルと答える様子を上下に並べた図*

**なぜ RAG が KB 検索に向くのか**

調べていくと、RAG が KB 検索システムに向いている理由は、グラウンディングと引用・更新の安さ・検索コンテキストによるハルシネーション抑制の 3 点に整理できました。KB では、**出典を追えることの価値が大きい**です。

*Figure — WhyRagSuitsKb: 同じ回答でも、根拠を示せるのは一方だけです。*

**「安く・小さく」という直感の落とし穴**

「ドキュメントに特化した小さいモデルなら安くて小さい」という発想は魅力的ですが、いくつか穴があります。

- ファインチューニングをしても、モデルを意味のあるかたちで小型化できるわけではありません。モデルサイズを決めるのは「必要な推論・言語能力」であって、「どれだけドメインの文章を見せたか」ではないからです。小さいモデルは、ドキュメントで仕立てても、やはり合成や指示追従が苦手な小さいモデルのままです。
- ファインチューニングの構築・維持には実コスト（データ準備・計算・評価・ドキュメント更新のたびの再学習）がかかり、RAG はこれを回避できます。
- RAG の推論コスト（検索チャンクでプロンプトが長くなる）は確かに気になりますが、学習パイプラインを保有するコストより安く済むことが多いです。

*Figure — RagVsFinetuning: RAG は事実を外に置き、Fine-tuning は振る舞いを内側に取り込みます。*

**ファインチューニングが本当に効く場面**

とはいえ、ファインチューニングが無意味というわけではありません。むしろ RAG と組み合わせると効果的です。

- 一貫した出力フォーマット・トーン・ドメイン用語（専門用語）を教える
- 検索してきたコンテキストの「使い方」を改善する（RAFT: Retrieval-Augmented Fine-Tuning など）、クエリ理解を良くする
- 毎回繰り返す指示を重みに焼き込んでプロンプトを短くする

つまり成熟したパターンは「事実は RAG、振る舞いは（必要なら軽い）ファインチューニング」であって、RAG を「置き換える」ものではない、ということでした。

*Figure — WhatFinetuningAdds: 事実は RAG が供給し、その使い方と伝え方をファインチューニングが変えます。*

## 疑問2: そもそもファインチューニングとは何をしているのか

ここまで「ファインチューニングは振る舞いを変えるもの」と書いてきましたが、正直に言うと、私にはまだ腑に落ちていない部分がありました。

> 「ファインチューニングって、ChatGPT や Claude みたいな製品モデルを自社データでちょっと調整する話でしょ？ それで振る舞いが変わるくらいなら、プロンプトで十分じゃない？」

この疑問は、**ベースモデルの存在を知らなかった**ことから来ていました。

**私たちが使っているモデルは、すでにファインチューニング済み**

調べてみて驚いたのは、ChatGPT や Claude といった製品モデルは、LLM の「完成品」ではなく、すでに大規模なファインチューニングを経た後の姿だということです。その前段階にある**ベースモデル**（プレトレーニング済みモデル）は、私たちが普段触っているものとはまったく別物でした。

*Image: 事前学習済みベースモデルから、教師ありファインチューニング・報酬モデル・RLHF による大規模ファインチューニング、製品利用に向けたアライメントと統合を経て、ChatGPT・Claude・Gemini など日常的に使う製品に至る4段階の図*

**ベースモデルとは何か**

ベースモデルは、インターネット上の膨大なテキスト（Web ページ、書籍、コードなど）を使って「次の単語を予測する」タスクで訓練されたモデルです。この事前学習（プレトレーニング）により、文法・知識・推論パターンなど、言語の基礎能力を獲得します。

ただし、ベースモデルは「テキスト補完エンジン」でしかありません。質問を入力しても、回答を返すのではなく、その質問文の続きを書こうとします。指示に従わず、質問に答えず、有害なリクエストも拒否しません。いわば言語能力は持っているけれど「会話の仕方を知らない」状態です。

*Image: 「フランスの首都は？」という入力に対し、回答ではなく質問文の続きを3通り生成するベースモデルの図。指示に従わない・質問に答えない・有害な要求を拒否しない・会話を続けられない、という4点を併記*

**ファインチューニングがモデルを「使える」ようにする**

ベースモデルを「役に立つアシスタント」に変えるのが、ポストトレーニングと呼ばれるファインチューニングの工程です。

1. **インストラクションチューニング**: 「質問されたら回答する」「指示に従う」といった対話パターンを、大量の（質問, 回答）ペアで学習させます。
2. **RLHF（人間のフィードバックによる強化学習）**: 人間の評価者が「良い回答」「悪い回答」を判定し、その評価に基づいてモデルの出力を調整します。これにより、有用で安全な応答が強化されます。

つまり、**私たちがプロンプトを打ち込んでいる相手そのものが、巨大なファインチューニングの産物**だったのです。「プロンプトで十分」と思っていたのは、ファインチューニングの恩恵の上に立っていたからでした。

**どちらにお金がかかるのか: プレトレーニング vs ファインチューニング**

LLM の構築には大きく 2 つのフェーズがあります。コストの桁がまったく違います。

| 観点 | プレトレーニング（ベースモデル構築） | ファインチューニング（ポストトレーニング） |
| --- | --- | --- |
| 何をするか | 大量テキストで「次の単語予測」を学習 | 対話・指示追従・安全性などを学習 |
| 計算コストの目安 | 数千万〜数億ドル規模 | 数百万ドル規模（RLHF 込み） |
| 必要なインフラ | 数千〜数万 GPU で数ヶ月 | 数十〜数百 GPU で数日〜数週間 |
| 必要なデータ | 数兆トークン規模の汎用テキスト | 数万〜数十万件の高品質な（指示, 回答）ペア + 人間の評価 |
| 参入障壁 | 非常に高い（資金・インフラ・データ・専門人材） | 相対的に低い（オープンなベースモデルを活用可能） |

プレトレーニングは圧倒的にコストが高く、これを自前で行えるのは世界でも数十社程度です。一方で、ファインチューニングはオープンなベースモデル（Llama、Mistral など）を出発点にできるため、新しい企業でも手が届きます。

**新モデルが強くなるのは、どちらのおかげか**

ここまでの話を踏まえると、もうひとつ気になることがあります。「GPT-3 → GPT-4」や「Claude 2 → Claude 3」のように、新モデルが劇的に賢くなるのは、プレトレーニングとファインチューニングのどちらの貢献が大きいのでしょうか。

結論から言うと、**プレトレーニングが能力の「天井」を決め、ファインチューニングがその天井にどれだけ近づけるかを決めます**。

- **世代をまたぐ大きなジャンプ**（GPT-3 → GPT-4、Claude 2 → Claude 3 など）は、ほぼプレトレーニングの進化によるものです。より多くの計算資源、より良いデータ、より大きなモデルサイズ、アーキテクチャの改善。これらがベースモデルの基礎能力（推論の深さ、知識の幅、コード理解力）を引き上げます。ファインチューニングでは、ベースモデルが持っていない能力を後から付け足すことはできません。
- **同世代内の改善**（GPT-4 → GPT-4o、Claude 3 Opus → Claude 3.5 Sonnet など）では、ファインチューニングやポストトレーニングの改善が大きな役割を果たすことがあります。同じ（または近い）ベースモデルでも、より良い RLHF データ、より洗練された学習手法、蒸留の工夫によって、ベンチマークスコアが大幅に向上するケースがあります。

つまりプレトレーニングは「どこまで賢くなれるか」の上限を設定し、ファインチューニングは「その賢さをどれだけ引き出せるか」を決めます。両者は代替ではなく補完の関係です。新モデルが強い理由を一言で言えば、**より良いベースモデルの上に、より良いファインチューニングが乗っている**からです。

**新しい企業が自社モデルを持つ現実的な道筋**

このコスト構造を知ると、「自社モデルを持ちたい」場合の選択肢が見えてきます。

1. **プレトレーニングから**: 数千万ドル〜。フロンティア研究所レベルの資金とインフラが必要。現実的には数十社のみ。
2. **オープンなベースモデル + 自社ファインチューニング**: 数万〜数百万ドル。自社ドメインに特化したモデルを構築可能。多くの AI スタートアップが採るルート。
3. **製品モデルの API + プロンプトエンジニアリング**: 数百〜数千ドル/月。最も手軽だが、モデル自体は自社のものではない。

*Image: LLM を使う3つのルートを、コストと支配権の強さとともに並べた図。ゼロからのプレトレーニングは1,000万〜1億ドル超で完全な支配権、オープンなベースモデル＋自社ファインチューニングは1万〜100万ドル超、製品モデル API ＋プロンプトエンジニアリングは月100〜1万ドル超で支配権は最小*

つまり「ファインチューニングに数百万ドル」は、性格を変えるだけの話ではありませんでした。**テキスト補完しかできないベースモデルを、アシスタントとして成立させる工程**であり、それ自体が製品の核心的な価値を生むプロセスなのです。

**企業がさらにファインチューニングする理由**

製品モデルの上から追加でファインチューニングする場合もあります。これは「性格変更」ではなく、実務上の強い理由があります。

- **信頼性**: プロンプトは「お願い」、ファインチューニングは「訓練」。数百万コールの本番では 5% の失敗が致命的になり得ます。
- **新しい能力**: ツール利用パターン、構造化抽出、ドメイン推論など、プロンプトだけでは確実にはできないことを教えられます。
- **コスト削減**: 毎回 3,000 トークンの指示をプロンプトに載せる代わりに、重みに焼き込んで 50 トークンで済ませられます。スケールすれば大きな差になります。
- **蒸留（Distillation）**: 巨大で高価なモデルの出力で小さく安いモデルをファインチューニングし、能力の大半をわずかなコストで得る手法です。

*Image: 蒸留の3ステップ図。巨大で高価なティーチャーモデルが高品質な出力を生成し、その（プロンプト, 出力）ペアを学習データとして集め、小さなスチューデントモデルをそれを模倣するようにファインチューニングする。能力はティーチャー100%に対しスチューデント約90%、実行コストは10〜100分の1になる*

目安は「**まずプロンプト、壁にぶつかったらファインチューニング**」。プロンプトでは届かない信頼性、記述しきれない複雑な振る舞い、長いプロンプトが高くつくスケール。そこに達したとき投資し、推論コスト削減で回収する構図です。

| 観点 | プロンプトエンジニアリング | ファインチューニング |
| --- | --- | --- |
| 与えられる例の数 | 数個 | 数万件 |
| 一貫性・信頼性 | 「お願い」ベースでばらつく | 「訓練」ベースで高い |
| 新しい能力の付与 | 限定的 | 可能 |
| プロンプト長・推論コスト | 長くなりがち | 焼き込んで短縮できる |
| モデル間の能力転移 | 不可 | 蒸留で可能 |

## 疑問3: そもそも RAG 以外に選択肢はないのか

「事実は RAG」と分かったところで、次に「RAG が唯一の正解なのか？」という疑問が出てきました。ここで役立ったのが、「RAG とは何か」を分解して捉え直すことでした。

**RAG を 2 段階に分解する**

RAG は一枚岩ではなく、2 つのステージを貼り合わせたものです。

1. **検索（Retrieval）**: 関連するテキストを見つける。これはまさに古典的な ML / 情報検索（IR）です（BM25、埋め込み、リランカー、ベクトル検索）。推論は要りません。
2. **生成（Generation）**: LLM が検索してきたテキストを読んで回答を合成する。

つまり「ML か RAG か」という分け方は誤った二分法で、ML（機械学習）は RAG の検索半分そのものなのです。本当に考えるべき設計上の問いは「どのステージが本当に必要で、それぞれどこまで高度である必要があるか」でした。

この視点で見ると、ニーズ別の代替が見えてきます。

*Figure — ArchitectureDecisionFlow: 合成回答の要否、コーパス規模、マルチホップの 3 つで決まります。*

**ケース別の使い分け**

- **「探す」だけなら LLM を外す**: やりたいことが「正しいドキュメント/箇所を見つける」だけなら、古典的 IR（BM25 + Dense Retriever + リランカー）だけでシステムが完結します。生成なし・ハルシネーションなし・安い・速い・監査可能。多くの「KB 検索」ニーズは実はこれで、LLM を後付けして過剰設計になっているケースもあります。
- **コーパスが小さいなら検索を省いてロングコンテキスト**: 昨今の大きなコンテキストウィンドウを使えば、ナレッジが概ね収まる規模なら、まるごとプロンプトに詰め込むだけで済みます（プロンプトキャッシュで安く）。ベクトル DB もチャンク分割も検索ミスもありません。小さく安定したコーパスでは RAG よりシンプルです。ただし規模が大きくなるとコスト・レイテンシ・"lost in the middle"（長文中央の想起低下）で破綻します。
- **関係性が重要なら GraphRAG / ナレッジグラフ**: 複数ドキュメントにまたがって事実をつなぐ必要がある問い（マルチホップ）では、素の Vector RAG は各チャンクを孤立して取ってくるため苦戦します。ナレッジグラフを構築して問い合わせる、あるいは GraphRAG が向きます。構築・維持コストは高めです。
- **クエリが複雑・多段ならエージェント型検索**: 1 回の retrieve-then-generate ではなく、モデルに反復的に検索・読解・クエリ改善・再検索をさせます。難しい問いに強い一方、1 クエリあたりは遅く高価です。

| ニーズ | 推奨アプローチ | 生成（LLM）の要否 |
| --- | --- | --- |
| ドキュメント/箇所を探すだけ | 純粋な IR（BM25 + Dense + リランカー） | 不要 |
| 小さく安定したコーパス | ロングコンテキスト（+ プロンプトキャッシュ） | 要（検索は不要） |
| マルチホップ・関係性 | GraphRAG / ナレッジグラフ | 要 |
| 複雑・多段のクエリ | エージェント型検索 | 要 |
| 大規模・変化するコーパスで合成回答 | RAG | 要 |

**率直なまとめ**

正直なところ、「大規模で変化するコーパスに対して、グラウンディングされた最新の合成回答を返す」という組み合わせについては、RAG を置き換える存在はありません。それこそが RAG の役割だからです。

ただし、ニーズがもっと絞られている場合には、RAG よりシンプルな手段が勝つことが多い、というのが学びでした。間違いは「RAG を選ぶこと」ではなく「もっと安いサブセットで足りる場面でフル装備の RAG に手を伸ばすこと」。だから実務で問うべきは「RAG に勝つものは何か」ではなく「ユーザーはそもそも合成回答を必要としているか、コーパスはどれくらい大きく・安定しているか」です。この 2 つの答えがアーキテクチャを決めます。

**これまでの話との整合**

先ほどの「ファインチューニングは事実の埋め込みが苦手（それは RAG の仕事）」という指摘は、狭く・正しいものでした。一方で疑問 2 で見たように、ファインチューニングの「振る舞いを変える」は、ベースモデルをアシスタントに仕立てるところから、信頼性・新スキル・蒸留によるコスト削減まで、非常に幅広いレンジをカバーします。

## 深掘り: コスト削減が本当の目的なら

最初の動機に戻ると、私の関心は結局「コストを下げたい」でした。その観点では、ファインチューニングより効きやすい打ち手が別にあります。

- RAG の裏側の生成モデルを、より小さく・安いものにする
- 検索品質を上げる（より良いチャンク分割、リランキング、ハイブリッド検索）ことで、送るトークンを減らす
- 埋め込みをキャッシュする
- オープンな小型モデル（例: 7〜8B 規模）を自前ホスティングして RAG の生成器にする

これで、グラウンディングを手放すことなく「ユースケースに合わせた小さいローカルモデル」を手に入れられます。

なお一点注意として、あなたの「KB 検索」が生成というより本当は**検索・ルックアップ**（正しい箇所を見つける）なら、最大の勝ちはほぼ検索側にあり、LLM の選択はほとんど効いてきません。

## まとめ

素朴な「ファインチューニングで RAG を安く置き換えられないか」という疑問から始めて、次のような整理にたどり着きました。

- ファインチューニングは「事実」ではなく「振る舞い」を学ぶ。KB 検索の事実提供は RAG の仕事で、置き換えではなく**併用**が成熟パターン。
- RAG は一枚岩ではなく「検索（古典的 ML/IR）＋生成（LLM）」。ニーズが絞られていれば、純粋 IR・ロングコンテキスト・GraphRAG・エージェント型のほうがシンプルに勝つことも多い。
- 実務で問うべきは「RAG に勝つ手段は？」ではなく「合成回答が要るか」「コーパスはどれくらい大きく・安定しているか」。
- 私たちが使う製品モデル（ChatGPT、Claude）自体が、ベースモデルに対する大規模ファインチューニングの産物。プレトレーニング（数千万〜数億ドル）とファインチューニング（数百万ドル）はコストの桁が違い、オープンモデル活用で参入障壁は下がる。目安は「まずプロンプト、壁にぶつかったらファインチューニング」。
- コスト削減が目的なら、小型生成モデル・検索品質改善・埋め込みキャッシュ・自前ホスティングのほうが効きやすい。

判断の出発点はシンプルで、「ユーザーは答えが欲しいのか、ドキュメントが欲しいのか」「コーパスはどれくらいの規模・更新頻度か」。この 2 つを先に決めると、アーキテクチャの選択がだいぶ楽になります。