ファインチューニング、検索、それともプロンプト改善か：選び方

モデルが必要なとおりに動作していない。選択肢は3つあるが、判断の順序はたいてい逆になっている。誰かが先に手法を選び、後からその正当化を組み立てるのだ。ファインチューニングは最も本格的に聞こえるため、最も頻繁に提案され、最も頻繁に期待を裏切る。

確実なのは、その逆の順序だ。失敗を診断すれば、その失敗自体が使うべき手法を示してくれる。

3つの失敗、3つの道具

モデルの振る舞いに関する不満は、ほぼすべて次の3種類のいずれかに当てはまる。

知識の不足。 モデルが何かを知らない。たとえば、自社の商品カタログ、先週変更された方針、ある顧客の注文履歴などだ。学習データにもプロンプトにも含まれていないため、モデルが知りようのない情報である。

振る舞いの問題。 モデルは十分な知識を持っているが、回答の形が不適切だ。長すぎる、口調が違う、必須のセクションがない、業界で使われない用語を使う、回答を控えるべき場面で回答するといった問題である。

技能の不足。 適切な情報を与え、指示も明確にしているのに、モデルが専門的なタスクをうまくこなせない。境界が微妙な分野別分類、ニッチな形式表記、公開ウェブ上では十分に示されていない慣例に基づく判断などが該当する。

ファインチューニングで知識不足を解消できない理由

これはこの分野で最も重大な誤解であり、正確に説明しておく価値がある。

ファインチューニングは、例のペアを使って重みを調整する。その例に含まれる事実が出力に現れやすくなるのは確かだ。しかし、だからといって知識システムに必要な次の性質が得られるわけではない。

• 何を学習したかを列挙できない。 どの事実が取り込まれたかを返すクエリは存在しない。
• 1つの事実だけを更新できない。 価格を1つ修正するだけでも、新たなデータセットを作って再度学習する必要がある。
• モデルは出典を示せない。 追跡可能な情報源を伴わずに事実を出力するため、規制対象または監査対象となる用途では使えない。
• 権限を適用できない。 全顧客のデータで学習したモデルは、誰に対しても全顧客のデータについて回答してしまう。
• 自信に満ちた誤答が減るどころか増える。 事実でファインチューニングすると、精度が相応に向上しないまま、その分野に関する流暢さと自信だけが増す傾向がある。これは最も役に立たない組み合わせだ。

検索は、すべての項目でこれと正反対の特性を持つ。文書を変更すれば、次の回答から変わる。すべての文章にIDがあり、モデルが何かを見る前に権限をフィルターとして適用できる。

プロンプトが過小評価される理由

チームはしばしば、プロンプトを初心者向けの選択肢と見なし、本格的なシステムはいずれ卒業するものだと考える。実際には、振る舞いの問題の多くはプロンプトで解決できる。出来の悪いプロンプトは、たいてい同じ3つの点で失敗しているからだ。

例がない。 望ましい出力形式を2つか3つ実演する方が、それを数段落かけて説明するよりも効果が高い。指定するのではなく、見本を示す。

構造がない。 散文に埋もれた指示は、遵守の度合いにばらつきが出る。セクション、番号付きの制約、明示的な出力形式の方が、はるかに確実に守られる。

回答を控える許可がない。 答えが不明な場合の対処を示していないプロンプトは、暗黙のうちに回答を要求している。「文書に答えが含まれていない場合は、その旨を述べて終了する」という一文だけで、捏造の一群を丸ごと排除できる。

プロンプトには、ほかの2つにはない特性もある。数秒で元に戻せることだ。要件がまだ変化している間は、どのような効率向上よりもこの性質の方が価値を持つ。

率直に言えば、限界はコストと一貫性にある。2,000トークンのシステムプロンプトはリクエストのたびに課金され、非常に長い指示群は遵守の度合いにもばらつきが出る。振る舞いが固まり、処理量も多くなった段階で、それを重みに移すのは正しい最適化だ。ただし、それは振る舞いが確定した後に行う効率化の判断であり、望ましい振る舞いを発見する方法ではない。

ファインチューニングが本当に適している用途

明確に正当化できるのは、次の3つの場合だ。

大量処理における形式と文体の一貫性。 すべての回答で社内所定の構成に従う必要があり、プロンプトでは95％までしか達成できない場合、数百件の一貫した例で学習すれば、リクエストごとの指示トークンをなくしながら、達成率を大幅に高められる可能性がある。

限定的な技能の習得。 分野特有の微妙な境界を持つ分類、社内表記法、公開ウェブ上に示されていない社内慣例などが該当する。モデルに何をすべきか指示するのではなく、モデルに何ができるかを変えられるのは、3つの手法のうちこれだけだ。

小規模モデルで十分な性能を実現する。 経済面で最も興味深いケースだ。ある限定的なタスクで最先端モデルに匹敵するよう、小規模モデルをファインチューニングできれば、コストと遅延を大幅に削減できる。自社運用を成立させる仕組みとしても、しばしば利用されている。

ネットワーク全体ではなく小規模なアダプターを学習するパラメータ効率の高い手法により、3つの用途はいずれも以前よりはるかに安価になった。費用対効果の判断は変わるが、診断そのものは変わらない。間違った問題に対する安価な解決策は、やはり間違った解決策である。

コスト見積もりで見落とされるもの

データセットの作成。 一貫性があり、正確な例が数百件から数千件必要となり、通常はラベル付け作業が発生する。矛盾した例は、例がないよりも悪い。モデルに不整合を教えてしまうからだ。

評価。 調整前後を比較できるよう、学習に使用しない評価用データセットと比較方法が必要になる。なければ、調整済みモデルが改善したかどうかを判断できない。最も頻繁に省かれる工程であり、改善を検出可能にする工程でもある。

基盤モデル更新の終わりなき追走。 基盤モデルが更新されるたびに、新しい基盤で再学習するのか、古い基盤にとどまって改善を見送るのかという問題が再浮上する。これはいつまでも繰り返される。一方、プロンプトにはこの問題がなく、より優れた基盤モデルが登場すれば、そのまま恩恵を受けられる。

性能劣化のリスク。 ある振る舞いを学習させることで、ほかの能力が低下する場合がある。幅広い評価用データセットがなければ、それを最初に発見するのは利用者になる。

成果につながる順序

1. 失敗を一文で書き出し、知識、振る舞い、技能のいずれかに分類する。
2. 実際に失敗した事例から、先に評価用データセットを作る。これがなければ、3つの手法のどれも評価できない。
3. プロンプトを修正する。 例と構造を加え、回答を控える方法も明示する。そのうえで測定する。
4. 事実に関する失敗であれば、検索を追加する。検索と生成は別々に検証する。
5. 振る舞いが固まっていてプロンプトのコストが高い場合、または手順3と4を経ても本物の技能不足が残る場合に限り、ファインチューニングする。

この順序に従ったチームの多くは、手順3か4で止まる。それは意欲不足ではなく、正しい結果だ。学習パイプラインの構築に何カ月も費やさずに済むことこそ、先に診断を行った成果である。