ファインチューニング vs RAG vs プロンプティング：選び方の指針

言語モデルが思いどおりに動かないとき、引けるレバーは大きく分けて3つあります。プロンプトを変える、モデルに読ませる適切な材料を与える、モデルの重みそのものを変える。これがプロンプティング、検索拡張生成（RAG）、ファインチューニングです。これらはしばしば競合する選択肢として語られますが、答えている問いはそれぞれ異なります。そして多くのチームは、もっと軽い手段で済んだはずなのに、最も重く最もコストの高い手段に真っ先に飛びついてしまいます。

このガイドのテーマは、正しい順番で選ぶことです。順番が重要なのは、各レバーがそれぞれ異なるコスト、異なる失敗の仕方、そして実際に解決する問題が異なるからです。診断さえ正しくできれば、選択はたいてい自ずと決まります。

各レバーが実際に変えるもの

何を変更しているのかを正確に捉えると理解が進みます。

• プロンプティングはリクエスト時に送る指示と文脈を変えます。モデルには手を触れません。固定されたシステムを言葉と例で操縦しているのです。
• RAGはリクエスト時にモデルが利用できる知識を変えます。関連する文書を取得し、回答前にモデルの文脈に置きます。モデル自体にはやはり手を触れません。読ませる内容を変えたのです。
• ファインチューニングはモデルそのものを変えます。自前の例で学習を続け、重みを望ましい振る舞いへとずらします。モデルを変えるのはこのレバーだけです。

3つのうち2つはモデルに手を触れない点に注目してください。これが核心的な洞察です。ほとんどの問題はモデルの問題ではありません。何を尋ねたか、何を供給したかの問題なのです。

プロンプティング：妥協ではなく既定の選択肢

プロンプティングには、「本格的な」作業の前に使う安上がりな選択肢という評判があります。この捉え方は逆さまです。プロンプティングは最初に試すべきものです。速く、可逆的で、驚くほど能力が高いからです。明確な指示、1つか2つの具体例、定義された出力フォーマット、迷ったときどうするかの明示——これらで「モデルの挙動がおかしい」という不満の大部分は解決します。

プロンプティングは、モデルが既に能力と知識を持っていて、それを確実に引き出しさえすればよいときに適した道具です。その限界もまた明確です。学習したことのない事実を教えることはできませんし、指示が長く脆ければ、何千もの多様な入力にわたって振る舞いを確実に強制することもできません。プロンプトが膨大なルールブックに膨れ上がってもなおエッジケースが漏れるなら、それは別のレバーが必要かもしれないというサインです。ただしその結論には、プロンプティングを飛ばすのではなく、やり尽くしてから到達すべきです。

RAG：問題が知識のとき

モデルの失敗が何を知っているかに関するものなら——自社の非公開文書を持っていない、最近の情報を見られない、与えられていない具体情報をでっち上げる——問題は知識であり、答えはたいていファインチューニングではなくRAGです。これは現場で最もよくある誤診です。チームはモデルが「うちのドメインを知らない」と感じ、再学習が必要だと思い込みますが、実際には読ませるべき適切なページを手渡すことが必要なのです。

RAGが優れているのは、検索可能な文書に存在する知識が最新で、監査可能で、修正が容易なまま保たれるからです。文書を更新すれば、モデルの回答もそれに合わせて更新されます。どの一節が使われたかを示せば、人間が回答を検証できます。対照的にファインチューニングは知識を重みに焼き込みますが、そこは検査が難しく、更新が難しく、古びてずれていきやすい場所です。原則として、文書が変わったときに答えも変わるべきなら、学習ではなく検索を使うこと。

ファインチューニング：問題が事実ではなく振る舞いのとき

ファインチューニングが本領を発揮するのは、プロンプティングでは確実に届かない形でどう振る舞うかを変える必要があるときです。膨大な量にわたる一貫したトーンやフォーマット、ベースモデルがぎこちなく扱う狭い専門タスク、明確な指示にもかかわらず逸脱し続ける構造化出力など。ファインチューニングのサインは、多くの例で示せるが短い指示には収まらない振る舞いです。

これが最も重いレバーであるのには理由があります。整備された学習データ、学習の実行、評価、そして保守へのコミットメントが必要です。なぜなら、ファインチューニング済みのモデルはあなたが所有することになる存在であり、ニーズが変わるにつれて整合を保ち続けなければならないからです。重要なのは、ファインチューニングが事実を教えるのは苦手だという点です。知識ベースを埋め込むよりも、傾向やスタイルをずらすほうがはるかに確実です。知識のギャップを埋めるためにファインチューニングに手を伸ばすのは、高コストで脆い結果を得る道です。

順番で決める

実践的な順序は、最も安く最も可逆的なものから先に。

1. プロンプティングから始める。 書ける限り明確な指示を書き、いくつか例を加え、出力を定義し、モデルが迷ったときのフォールバックを述べます。実際のケースで測定します。
2. 失敗が知識に関するものなら、RAGを足す。 欠けた事実、古い情報、非公開文書、でっち上げた具体情報——読ませるべき適切な材料を与えます。
3. 失敗が一貫した振る舞いに関するものなら、ファインチューニングを検討する。 指示に圧縮できないが実証可能なパターンが、規模をもって繰り返される場合です。
4. 必要なら組み合わせる。 これらは排他的ではありません。成熟した構成でよくあるのは、ファインチューニング済みモデルとRAGと入念なプロンプトの併用で、それぞれが最も得意な仕事を担います。

ほとんどのチームは、いちばん下に飛びつくのではなく、このリストを上から下へ進むべきです。順番はコストの勾配です。1段上がるごとに、より多くの労力、より多くのデータ、より多くの継続的な保守が要求されます。

自分がどの問題を抱えているか見分ける

最も速い選び方は、失敗を正直に診断することです。悪い回答についてこう問いましょう。適切な文書があればこれは直っただろうか？ イエスなら知識の問題で、RAGがレバーです。こう問います。もっと明確な指示や例があれば直っただろうか？ イエスならプロンプティングの問題です。こう問います。これはモデルが一貫して間違えるパターンで、多くの例で示せるが一文では言えないものか？ イエスならファインチューニングが俎上に乗ります。

複数が当てはまるときは、最も安いものから直して測り直します。多くの場合、安い修正で問題の十分な部分が解決し、高コストな修正が不要になります。苦労するチームはたいてい、失敗が実際に何でできているかではなく、どれが最も深刻に聞こえるかでレバーを選んだチームです。

どれも直さないこと

どのレバーも、モデルを本来とは違う何かに変えることはできません。プロンプティングは、もともと存在しなかった知識を呼び出せません。RAGは供給されたテキストに回答を根拠づけますが、モデルの推論を良くするわけではなく、文書の誤りをそのまま受け継ぎます。ファインチューニングは振る舞いをずらしますが、事実を確実に組み込むわけではなく、基盤となるモデルが根本的にできないタスクを救うことはできません。3つともすべて、引き出し、根拠づけ、傾向のいずれかを改善するものであり——どれも能力を無から作り出しはしません。それぞれの天井を知っておくことが、間違ったレバーに何週間も費やすのを防ぎます。

まとめ

プロンプティング、RAG、ファインチューニングはライバルではありません。3つの異なる問いへの答えです。プロンプティングはどう尋ねたかを直します。RAGはモデルが何を読めるかを直します。ファインチューニングはモデルがどう振る舞うかを直します。失敗を診断し、問題が要求する分だけコストの勾配を登りましょう——プロンプトから始め、ギャップが知識なら検索を足し、ファインチューニングは示せるが言葉にできない振る舞いのために取っておく。問題を解決する最も安いレバーが、正しいレバーです。