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

はじめに

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

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

参照するドキュメントに特化してモデルを仕立てれば、検索基盤もベクトル DB も要らなくなって身軽になりそう——直感的にはそう思えます。この疑問を出発点に、「ファインチューニングは RAG の代わりになるのか」「そもそも RAG 以外に選択肢はないのか」「ファインチューニングにはどんな価値があるのか」を順に調べて考えてみました。

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

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

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

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

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

社内ドキュメントでファインチューニングすると、モデルは「社内ドキュメントっぽい話し方」を学びますが、具体的な質問に対しては、流暢で自信満々な誤答を平気で返すことがあります。事実が重みの中に非可逆的に「にじんで」保存されるため、補間はできても正確な参照はできないからです。RAG は逆に、事実を検索可能なストアに原文のまま保持します。

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

調べていくと、RAG が KB 検索システムに向いている理由が整理できました。

• グラウンディングと引用: RAG は回答の根拠となった原文の箇所を指し示せます。ファインチューニングでは根拠の提示ができず、監査可能性が失われます。KB では出典を追えることの価値が大きいです。
• 更新が安い: ドキュメントが変わったら再インデックスするだけ（数分）。ファインチューニングだとドキュメント更新のたびに再学習が必要になります。
• ハルシネーションの抑制: 検索してきたコンテキストがモデルの回答を制約します。ファインチューニングのみのモデルには、拠りどころとなる文脈がありません。

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

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

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

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

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

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

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

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

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

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

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

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

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

ベースモデルとは何か

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

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

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

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

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

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

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

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

プレトレーニングは圧倒的にコストが高く、これを自前で行えるのは世界でも数十社程度です。一方で、ファインチューニングはオープンなベースモデル（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 + プロンプトエンジニアリング: 数百〜数千ドル/月。最も手軽だが、モデル自体は自社のものではない。

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

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

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

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

蒸留 の仕組み

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

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

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

RAG を 2 段階に分解する

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

1. 検索（Retrieval）: 関連するテキストを見つける。これはまさに古典的な ML / 情報検索（IR）です（BM25、埋め込み、リランカー、ベクトル検索）。推論は要りません。
2. 生成（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 クエリあたりは遅く高価です。

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

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

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

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

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

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

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

まとめ

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

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

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