RAGかファインチューニングか — プロダクト機能での選び方

質問の裏にある本当の問い

チームが「ファインチューニングすべきか」と尋ねるとき、実際に言いたいのは「モデルが自社データを知らない」であることがほとんどです。これは別の問題であり、対処法も異なります。

ファインチューニングはモデルの振る舞いを変えます。検索（RAG）は回答時点でモデルが知っている内容を変えます。この二つの混同が、初期のAI機能で最も多く、最も高くつく誤りです。

答えが自社データの中にあるなら検索を

正しい答えが文書、商品カタログ、サポート履歴、データベースの行のどこかに存在するなら、ほぼ常に検索が正解です。

• 内容は変わります。ファインチューニング済みモデルは学習時点で知識が固定されますが、検索インデックスは新しい行を書いた瞬間に更新されます。
• 出典を示す必要があります。検索なら該当箇所を指し示せます。ファインチューニング済みモデルは、その答えがどこから来たかを説明できません。
• 誤答を今日中に直す必要があります。検索なら文書を直すだけ。ファインチューニングなら再学習です。

形式の問題ならファインチューニングを

プロンプトでは安定しない一貫した振る舞いが必要なとき、ファインチューニングはコストに見合います。

• モデルがずれてしまう厳格な出力フォーマット。
• 何千回の生成にわたる統一されたトーン。
• 小さく安価なモデルが大きなモデルを置き換えられる、狭い分類タスク。

最後の点が見落とされがちです。狭いタスク一つで小型モデルを大型モデルに追いつかせるのは、品質ではなくコストの判断であることが多いのです。

推奨する順序

1. まずプロンプトを丁寧に書く。「ファインチューニングが必要」の相当な割合が、実は指示の曖昧さでした。
2. 検索を足す。失敗が本当に知識の欠如だったかを測る。
3. その後で初めてファインチューニングを検討する。検索では直せない振る舞いに限って。

痛い目を見るパターン

最も高くつく失敗は、週単位で変わるデータのスナップショットで学習させることです。六週間後、モデルは前四半期の価格を自信たっぷりに答え、どの学習例が原因かは誰にも特定できません。検索なら、データベースを一行直すだけで済みました。

開発中のプロダクトでこれを検討中なら、コードを書く前に一時間話す価値があります。受託開発サービスはまさにそこから始まります。