RAGをファインチューニングで置き換えられる？ KB検索の選択肢を調べて考えてみた
社内KB検索でRAGをファインチューニングに置き換えられるか。ファインチューニングが実際に学ぶもの、純粋IRやロングコンテキストが勝つ場面、それぞれのコストを整理します。
目次
はじめに
ナレッジベース（KB）検索システムを RAG で構築している方は多いと思います。私もその一人なのですが、あるとき素朴な疑問が湧いてきました。
「小さいローカルモデルを社内ドキュメントでファインチューニングすれば、RAG と同じことができて、しかもモデルサイズも小さく・安く済むのでは？」
参照するドキュメントに特化してモデルを仕立てれば、検索基盤もベクトル DB も要らなくなって身軽になりそうです。直感的にはそう思えます。しかし実際にはそうなりませんでした。ファインチューニングが学ぶのは事実ではなく振る舞いであり、KB 検索が本当に求めているものを供給できないからです。代わりに残ったのは逆の教訓でした。ニーズが狭ければ、フル装備の RAG より単純な構成のほうが勝つことが多い、ということです。この疑問を出発点に、「ファインチューニングは RAG の代わりになるのか」「そもそもファインチューニングとは何をしているのか」「そもそも RAG 以外に選択肢はないのか」を順に調べて考えてみました。
同じ疑問を持っている方の思考の整理に役立てば幸いです。
疑問1: ファインチューニングで RAG を置き換えられるのか
最初の疑問から調べてみると、どうやらこの直感はあまりうまくいかなさそうだ、ということが見えてきました。ファインチューニングと RAG は、そもそも解いている問題が違うからです。
ファインチューニングが学ぶのは「事実」ではなく「振る舞い」
ファインチューニングは、モデルの重みを調整して、スタイル・出力フォーマット・トーン・タスクの遂行パターンを変える手法です。一方で、「特定の事実を後から確実に引き出せるように埋め込む」ことは得意ではありません。
社内ドキュメントでファインチューニングすると、モデルは「社内ドキュメントっぽい話し方」を学びますが、具体的な質問に対しては、流暢で自信満々な誤答を平気で返すことがあります。RAG は逆に、事実を検索可能なストアに原文のまま保持します。
なぜ RAG が KB 検索に向くのか
調べていくと、RAG が KB 検索システムに向いている理由は、グラウンディングと引用・更新の安さ・検索コンテキストによるハルシネーション抑制の 3 点に整理できました。KB では、出典を追えることの価値が大きいです。
「安く・小さく」という直感の落とし穴
「ドキュメントに特化した小さいモデルなら安くて小さい」という発想は魅力的ですが、いくつか穴があります。
- ファインチューニングをしても、モデルを意味のあるかたちで小型化できるわけではありません。モデルサイズを決めるのは「必要な推論・言語能力」であって、「どれだけドメインの文章を見せたか」ではないからです。小さいモデルは、ドキュメントで仕立てても、やはり合成や指示追従が苦手な小さいモデルのままです。
- ファインチューニングの構築・維持には実コスト（データ準備・計算・評価・ドキュメント更新のたびの再学習）がかかり、RAG はこれを回避できます。
- RAG の推論コスト（検索チャンクでプロンプトが長くなる）は確かに気になりますが、学習パイプラインを保有するコストより安く済むことが多いです。
ファインチューニングが本当に効く場面
とはいえ、ファインチューニングが無意味というわけではありません。むしろ RAG と組み合わせると効果的です。
- 一貫した出力フォーマット・トーン・ドメイン用語（専門用語）を教える
- 検索してきたコンテキストの「使い方」を改善する（RAFT: Retrieval-Augmented Fine-Tuning など）、クエリ理解を良くする
- 毎回繰り返す指示を重みに焼き込んでプロンプトを短くする
つまり成熟したパターンは「事実は RAG、振る舞いは（必要なら軽い）ファインチューニング」であって、RAG を「置き換える」ものではない、ということでした。
疑問2: そもそもファインチューニングとは何をしているのか
ここまで「ファインチューニングは振る舞いを変えるもの」と書いてきましたが、正直に言うと、私にはまだ腑に落ちていない部分がありました。
「ファインチューニングって、ChatGPT や Claude みたいな製品モデルを自社データでちょっと調整する話でしょ？ それで振る舞いが変わるくらいなら、プロンプトで十分じゃない？」
この疑問は、ベースモデルの存在を知らなかったことから来ていました。
私たちが使っているモデルは、すでにファインチューニング済み
調べてみて驚いたのは、ChatGPT や Claude といった製品モデルは、LLM の「完成品」ではなく、すでに大規模なファインチューニングを経た後の姿だということです。その前段階にあるベースモデル（プレトレーニング済みモデル）は、私たちが普段触っているものとはまったく別物でした。
ベースモデルとは何か
ベースモデルは、インターネット上の膨大なテキスト（Web ページ、書籍、コードなど）を使って「次の単語を予測する」タスクで訓練されたモデルです。この事前学習（プレトレーニング）により、文法・知識・推論パターンなど、言語の基礎能力を獲得します。
ただし、ベースモデルは「テキスト補完エンジン」でしかありません。質問を入力しても、回答を返すのではなく、その質問文の続きを書こうとします。指示に従わず、質問に答えず、有害なリクエストも拒否しません。いわば言語能力は持っているけれど「会話の仕方を知らない」状態です。
ファインチューニングがモデルを「使える」ようにする
ベースモデルを「役に立つアシスタント」に変えるのが、ポストトレーニングと呼ばれるファインチューニングの工程です。
- インストラクションチューニング: 「質問されたら回答する」「指示に従う」といった対話パターンを、大量の（質問, 回答）ペアで学習させます。
- 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 データ、より洗練された学習手法、蒸留の工夫によって、ベンチマークスコアが大幅に向上するケースがあります。
つまりプレトレーニングは「どこまで賢くなれるか」の上限を設定し、ファインチューニングは「その賢さをどれだけ引き出せるか」を決めます。両者は代替ではなく補完の関係です。新モデルが強い理由を一言で言えば、より良いベースモデルの上に、より良いファインチューニングが乗っているからです。
新しい企業が自社モデルを持つ現実的な道筋
このコスト構造を知ると、「自社モデルを持ちたい」場合の選択肢が見えてきます。
- プレトレーニングから: 数千万ドル〜。フロンティア研究所レベルの資金とインフラが必要。現実的には数十社のみ。
- オープンなベースモデル + 自社ファインチューニング: 数万〜数百万ドル。自社ドメインに特化したモデルを構築可能。多くの AI スタートアップが採るルート。
- 製品モデルの API + プロンプトエンジニアリング: 数百〜数千ドル/月。最も手軽だが、モデル自体は自社のものではない。
つまり「ファインチューニングに数百万ドル」は、性格を変えるだけの話ではありませんでした。テキスト補完しかできないベースモデルを、アシスタントとして成立させる工程であり、それ自体が製品の核心的な価値を生むプロセスなのです。
企業がさらにファインチューニングする理由
製品モデルの上から追加でファインチューニングする場合もあります。これは「性格変更」ではなく、実務上の強い理由があります。
- 信頼性: プロンプトは「お願い」、ファインチューニングは「訓練」。数百万コールの本番では 5% の失敗が致命的になり得ます。
- 新しい能力: ツール利用パターン、構造化抽出、ドメイン推論など、プロンプトだけでは確実にはできないことを教えられます。
- コスト削減: 毎回 3,000 トークンの指示をプロンプトに載せる代わりに、重みに焼き込んで 50 トークンで済ませられます。スケールすれば大きな差になります。
- 蒸留（Distillation）: 巨大で高価なモデルの出力で小さく安いモデルをファインチューニングし、能力の大半をわずかなコストで得る手法です。
目安は「まずプロンプト、壁にぶつかったらファインチューニング」。プロンプトでは届かない信頼性、記述しきれない複雑な振る舞い、長いプロンプトが高くつくスケール。そこに達したとき投資し、推論コスト削減で回収する構図です。
| 観点 | プロンプトエンジニアリング | ファインチューニング |
|---|---|---|
| 与えられる例の数 | 数個 | 数万件 |
| 一貫性・信頼性 | 「お願い」ベースでばらつく | 「訓練」ベースで高い |
| 新しい能力の付与 | 限定的 | 可能 |
| プロンプト長・推論コスト | 長くなりがち | 焼き込んで短縮できる |
| モデル間の能力転移 | 不可 | 蒸留で可能 |
疑問3: そもそも RAG 以外に選択肢はないのか
「事実は RAG」と分かったところで、次に「RAG が唯一の正解なのか？」という疑問が出てきました。ここで役立ったのが、「RAG とは何か」を分解して捉え直すことでした。
RAG を 2 段階に分解する
RAG は一枚岩ではなく、2 つのステージを貼り合わせたものです。
- 検索（Retrieval）: 関連するテキストを見つける。これはまさに古典的な ML / 情報検索（IR）です（BM25、埋め込み、リランカー、ベクトル検索）。推論は要りません。
- 生成（Generation）: LLM が検索してきたテキストを読んで回答を合成する。
つまり「ML か RAG か」という分け方は誤った二分法で、ML（機械学習）は RAG の検索半分そのものなのです。本当に考えるべき設計上の問いは「どのステージが本当に必要で、それぞれどこまで高度である必要があるか」でした。
この視点で見ると、ニーズ別の代替が見えてきます。
ケース別の使い分け
- 「探す」だけなら 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 つを先に決めると、アーキテクチャの選択がだいぶ楽になります。