ファインチューニング vs RAG：本当にファインチューニングが必要なのはいつか

モデルがあなたのために何をするかを変える方法は三つしかなく、それらは互換ではありません。間違ったものを選ぶと、数か月後になってはじめて表れる形で高くつきます。

ファインチューニングとは実際には何か

ベースモデルを取り、望む振る舞いの例——入力と、あなたの分野の優れた実務家が返したであろう答えの対——でその学習を継続します。モデルのデフォルトが変化します——どの言葉に手を伸ばすか、答えがどんな形を取るか、答える前に何を尋ねるか。

これはデータベースではありません。 何も保存されず、検索されません。例はモデルの傾向を動かすのであって、暗唱できる事実になるのではありません。

実際には新しいモデルではなくアダプター

すべての重みを再学習するのは高価で、めったに必要ありません。通常の手法——LoRA、つまり低ランク適応——は、凍結したベースモデルの上に乗る少数の追加パラメータを学習します。結果は数十ギガバイトではなく数十メガバイトのファイルです。

これには知っておく価値のある帰結があります。一つのベースモデルが多数のアダプターを提供できるのです。一台のマシンが、法律事務所、診療所、物流業者に同じベース重みを走らせ、テナントごとに小さなアダプターを差し替えられます。業種ごとのファインチューニングは、業種ごとに丸ごとのモデルを意味しません。

本当に必要になるのはいつか

言葉づかいが重要で、プロンプトではそれを保持できないとき。 日本語のビジネス敬語、臨床的な言い回し、引受担当者の言葉の濁し方。言葉づかいはプロンプトで説明できますが、長い会話の下でモデルはデフォルトへ戻っていきます。ファインチューニングはデフォルトを動かします。

大量の場面でのフォーマット遵守。 すべての出力が特定の構造でなければならず、「たいてい正しい」では不十分なら、指示よりも例のほうが確実に教え込めます。

指示が答えより長くなってしまったとき。 システムプロンプトが生成物より長いなら、あなたは毎回のリクエストでそのトークン分を支払っています。ファインチューニングは、そのコストをリクエストごとの経路から外す方法です。

狭い領域における小さなモデル。 よく調整された小さなモデルは、一つの専門内では、はるかに大きな汎用モデルにしばしば勝ります——これは品質の問題であると同時にコストの決定でもあります。自前のモデルを持ち込むを参照。

ベースモデルがあなたの言語や分野で弱いとき。 一部の言語や専門分野は、公開学習データに乏しいものです。それを直す手立てが例です。

必要ないのはいつか

• まだより良いプロンプトを試していない。 「カスタムモデルが必要だ」という問題のほとんどはプロンプトの問題です。ファインチューニングは高価な答えです。まずそれに値することを示しましょう。
• 例が一握りしかない。 数十件ではモデルは動きません。数百件の良いものなら動くかもしれません。品質が量に勝り、悪い例は悪い癖を忠実に教え込みます。
• 望むものが頻繁に変わる。 毎週編集したくなるようなものは、焼き込むべきではありません。

きちんとやるのに必要なもの

例。 数百から低い数千件、実務から引き出し、その分野を知る誰かによって確認されたもの。ここが顧客の見積もりが甘くなる部分です——データ収集は通常、学習そのものより長くかかります。

保留した評価セット。 モデルが一度も見ていない例で、前後で採点します。これがなければ、ファインチューニングが役立ったのか、害になったのか、何もしなかったのか、判断できません——そして「良くなった気がする」は測定ではありません。これは最も飛ばされがちなステップであり、そのプロジェクトに取り組む価値があったかを決めるステップです。

ベースモデルが変わることへの備え。 アダプターは、学習に使ったベースに紐づいています。新しいベースモデルに移るとき、調整はやり直しになります。一度きりの作業ではなく、保守として予算を組んでください。

設計で防ぐべき失敗

一つの狭いスタイルに調整しすぎたモデルは、それ以外のすべてが下手になります——別の言葉づかいが必要な質問にもあなたの社内トーンで答え、教わったことのないものについて自信たっぷりに流暢になります。これが評価セットが重要な理由であり、賢明な目標が通常、一つのことしかできないモデルではなく、デフォルトのささやかな移動である理由です。