【ITニュース解説】Fine-Tuning vs RAG vs Prompting: What Each Costs

大規模言語モデル（LLM）をシステムに組み込む際、「自社のデータをモデルに学習させたい」という要望がよく聞かれる。しかし、この解決策としてファインチューニングが常に最適とは限らず、多くの費用と時間を無駄にする原因となることが多い。問題の種類に応じて最適なアプローチを選択することが、成功への鍵となる。モデルが「自社のことを知らない」のか、それとも「望むように回答してくれない」のか、この根本的な問題を正確に診断することが重要である。

LLMをビジネスで活用するための主なアプローチは、「プロンプト調整（Prompting）」、「RAG（Retrieval-Augmented Generation）」、「ファインチューニング（Fine-tuning）」の3つがある。それぞれが異なる種類の問題解決に適しており、誤った選択は、求めている結果を得られないまま何ヶ月もの作業を費やすことにつながる。最もコストを節約できるルールは次のとおりだ。もしモデルが「何かを知らない」ことが問題であれば、RAGを使うべきだ。もしモデルが知識は持っているが「望むスタイル、形式、長さで回答しない」ことが問題であれば、まずプロンプトを改善し、それがうまくいかない場合にのみファインチューニングを検討する。ファインチューニングは「事実」ではなく「振る舞い」を教えるものであり、知識を注入するために使うと、モデルは新しいハウススタイルで自信満々に間違った情報を生成する結果になりかねない。

それぞれの方法が具体的に何をするのか、見ていこう。

プロンプト調整は、モデルへの各リクエストと共に送る指示（プロンプト）を変更することで、モデルの出力のトーン、形式、構造、推論アプローチを調整する。少量の文脈情報もプロンプトに直接含めることができる。この方法は即座に効果が反映され、トークンの費用以外に追加コストはほとんどかからず、本番環境でも数秒で変更可能である。

RAG（Retrieval-Augmented Generation）は、リクエスト時に自社のコンテンツから関連する資料を検索し、モデルが回答する前にその情報をモデルへの入力（コンテキスト）として組み込む。これにより、モデルはトレーニング時に一度も学習していない情報、例えば今朝変更されたばかりの情報にもアクセスできるようになる。モデル自体は変更されないため、モデルに与える情報源を改善していると言える。

ファインチューニングは、モデルの内部の重み（パラメーター）を、望ましい振る舞いの例を使って調整する。これは、一貫した形式、トーン、特定のタスクに特化したパターンなど、言葉で説明するのが難しいが例を示すことで簡単に学習させられる振る舞いを教えるのに非常に効果的である。しかし、事実を教えるのには向いていない。なぜなら、この方法で学習した事実は後から更新、監査、引用することができず、モデルが間違った事実に基づいて回答しても、その根拠をユーザーが確認する手段がないためだ。これら3つの方法すべてが出力を変えるが、モデルが「知っていること」を変えるのはRAGのみであるという点が重要だ。

次に、それぞれのコストを見てみよう。これらの費用は、英国の中規模ビジネスアプリケーションで一般的な目安である。

プロンプト調整は、数日から数週間の作業で、評価セットの構築を含めておよそ1,000ポンドから5,000ポンド程度かかる。実行コストは、トークンの費用のみであり、長いシステムプロンプトを使うと少し増えるが、プロンプトキャッシュによって相殺されることが多い。

RAGシステムの構築は、4週間から12週間かかり、ソースコンテンツの整理具合によって15,000ポンドから60,000ポンド程度が一般的である。構築コストの大部分は、データの取り込み（ドキュメントをシステムから取得し、適切にチャンク化し、ユーザーが閲覧権限のあるものだけを検索できるように権限を処理し、インデックスを常に最新の状態に保つ作業）にかかる。実行コストとしては、ベクトルストレージの費用と、各リクエストで少し大きくなるコンテキストの費用が加わる。

ファインチューニングは、2週間から8週間のエンジニアリング作業に加え、データセットの準備が必要で、20,000ポンドから80,000ポンドが一般的である。トレーニングのための計算資源の費用は通常、全体のコストの最も小さな部分であり、大半の費用は、ドメイン知識を持つ人間が数百から数千もの高品質な学習例を作成する作業にかかる。実行コストも高くなる可能性があり、ファインチューニングされたモデルはしばしばプレミアム料金がかかったり、専用のホスティングが必要になったりする。この費用のアシンメトリー（非対称性）が重要なポイントである。プロンプト調整は非常に安価なので、たとえそれが十分な解決策ではないとある程度確信していても、まず試す価値がある。なぜなら、いずれにせよ評価セットは必要であり、本当の問題点が何であるかを理解できるからだ。

これらのアプローチを試す順序は、最終的に最もコストを抑えることにつながる。たとえ最終的に一番高度なアプローチに行き着くとしても、この順序を守るべきだ。

まず、評価セットを作成する。これは、30個から100個の実際の入力と、それに対応する正しい出力のセットである。これがないと、どんな変更が効果があったのか判断できず、その後のすべての決定は当てずっぽうになってしまう。

次に、プロンプトを改善する。形式を具体的に指定し、良い出力例をプロンプト内にいくつか含め、答えが不明な場合にどうすべきかを指示する。驚くほど多くの「モデルの性能が十分でない」という不満が、この段階で解決する。特に、冗長性や出力構造に関する問題は解決されやすい。

その後、より大規模なモデルや異なるモデルを試す。多くの場合、これはどんなカスタマイズ作業よりも安価であり、評価には半日もかからない。

もし問題が「知識不足」にあるなら、RAGを追加する。モデルが自社の製品、ポリシー、ドキュメントに関する質問に間違って答えたり、回答を拒否したりする場合、このステップがそれを解決する。

最後に、もし問題が「振る舞い」にあるなら、ファインチューニングを検討する。この段階では、すでに評価セットがあり、調整されたプロンプトがあり、必要であればRAGパイプラインも構築されているはずだ。それでも出力のスタイルや構造が求めるものと一致せず、その望ましい振る舞いを言葉で説明するよりも数百もの例で示す方が簡単であれば、ファインチューニングが適切なツールとなる。ほとんどのプロジェクトはステップ3または4で解決するため、これがコスト削減につながる。

もちろん、ファインチューニングが本当に有効なケースも存在する。それを完全に無視するのは、最初からそれを選ぶのと同じくらい間違いだ。

大規模かつ一貫した構造化出力が必要な場合、例えば、すべての応答がプロンプトで指定するには面倒な厳密な形式に従う必要がある場合、ファインチューニングされたモデルはより信頼性が高く、入力トークンもはるかに少なく済むため、大量の処理においてコストを回収できる。 法律文書の作成、臨床記録、規制対象の金融通信など、専門的なトーンやドメイン固有の表現が必要な場合、業界の専門家がすぐに認識できるような強い慣習を持つスタイルは、指示で捉えるのが難しいがファインチューニングで実現できる。 微妙で言葉では説明しにくい境界線を持つ分類タスクでは、チームが例を consistent に分類できるが、そのルールを説明できない場合に、まさに例を用いたトレーニングが役立つ。 高ボリュームでのコスト削減も、有効なケースの一つだ。特定の狭いタスクにおいて、より大きな汎用モデルと同等の性能を発揮する小さなファインチューニングモデルは、リクエストあたりのコストを大幅に削減できる。これは、節約額が構築と維持のコストを上回るボリュームの場合にのみ意味がある。 これら共通の糸は「知識」ではなく「振る舞い」である。もし何を求めているかを数行の文章で説明できるならプロンプトを調整し、もしそれを示すことしかできないならトレーニング（ファインチューニング）を検討するべきだ。

ファインチューニングのビジネスケースでしばしば見落とされがちな、継続的な負担が三つある。

一つ目は、データセットの陳腐化だ。ファインチューニングされたモデルは、学習時に見た例を反映する。製品、ポリシー、またはハウススタイルが変更されると、学習例は古くなり、モデルは古い振る舞いを自信満々に生成し続ける。このため、定期的な再トレーニングを継続的なコストとして予算に組み込む必要があり、一度きりの投資ではない。

二つ目は、特定のベースモデルへの依存だ。ファインチューニングは特定のバージョンのベースモデルに結びつく。そのベースモデルが非推奨になったり、より優れたモデルが登場したりした場合、移行のためには再トレーニングが必要となり、これはプロンプト調整では発生しない実際の切り替えコストとなる。

三つ目は、評価が選択肢ではなく必須となることだ。プロンプト調整では、出力の品質低下を視覚的に確認できる場合がある。しかし、ファインチューニングされたモデルでは、なぜ振る舞いが変化したのか内部を検査できないため、評価ハーネスが唯一の測定手段となる。 RAGにも同様に、インデックスを常に最新の状態に保つ必要があり、人々が役割を変更するにつれて権限が正確に維持されている必要があり、データの取り込みが静かに停止していないか誰かが気づく必要がある、という継続的な負担がある。これらは再トレーニングよりも安価だが、決して無料ではない。

プロジェクトを開始する前に、まず問題の「診断」を行うことが極めて重要である。モデルが「何を知らない」のか、それとも「どのように回答すべきか知らない」のかを、ユーザーが使う言葉で具体的に把握することで、上記の3つのアプローチのどれが最も適切かを判断できる。この診断によって、当初計画していたプロジェクトよりもはるかに少ないコストで問題を解決できることが多い。もしファインチューニングが本当に正しい解決策であると診断された場合は、データセットの準備にかかる作業を正直に見積もり、プロジェクトの成功を確実にする必要がある。