手元のモデルを自分のデータに合わせる ── その前に試すこと

この回は ファインチューニング を扱いますが、結論から言うと最後の手段です。まず、それ以外で足りないかを確認します。

「自社に合わせたい」という要望は、中身が3種類に分かれます。手段がまったく違うので、まず切り分けます。

1行目が最も多い要望で、最も向かない組み合わせです。追加学習で事実を覚えさせようとすると、更新のたびに学習し直しになりますし、覚えたつもりで間違えるようになります。検索して渡すほうが、正確で更新も容易です。

形式や口調の問題でも、まずプロンプトで試します。多くの場合、ここで足ります。

1. 1求める形式を明示する — 「必ずJSONで、この項目を含めて」
2. 2例を2〜3件見せる — 説明するより例のほうが伝わる
3. 3やってほしくないことも書く — 「前置きを書かない」
4. 4出力を検証して、外れたら再試行する — 形式は機械的に確認できる

2番目が効きます。望む出力の例を数件見せるだけで、形式はかなり揃います。追加学習を検討する前に、例を増やして改善するかを確認してください。

4番目も現実的です。LLM時代のテスト戦略 EP.07 で扱ったとおり、形式は決定的に検証できます。外れたら再試行する仕組みを入れれば、多少のばらつきは吸収できます。

上を試して足りない場合、追加学習の出番です。該当するのは限られた条件です。

• プロンプトが長くなりすぎる — 例を大量に入れないと揃わない
• 毎回同じ指示を繰り返している — 固定化したほうが効率的
• 小さいモデルで動かしたい — 指示への追従が弱いぶんを学習で補う
• 独特の形式が必要 — 一般的でない出力形式

3番目が実務的な動機になりやすい。大きいモデルなら指示だけで揃うが、手元で動かすには重い。小さいモデルに追加学習して、必要な用途だけを揃えるという使い方です。

2番目も効率の観点で正当です。毎回同じ長い指示を送っていると、その分の処理時間と資源を毎回消費します。固定化すれば、指示を短くできます。

手元で回す場合、モデル全体を学習させるのは現実的ではありません。代わりに使うのが LoRA（Low-Rank Adaptation） です。

小さな追加部分だけを学習させる方式で、必要な計算資源とメモリが大幅に減ります。元のモデルは変えないため、切り替えも破棄も容易です。

最下行の切り替えのしやすさは運用で効きます。「要約用」「分類用」と用途ごとに差分を作り、同じモデルに付け替えて使うという形が取れます。

モデル名やオプションは版によって変わります。実行前に、使っている版の説明を確認してください。ここで示したいのは、差分の置き場所を分けておく（`./adapters/summarize`）という運用の形です。

追加学習の成否は、データの質でほぼ決まります。件数より、揃っていることが重要です。

1. 1望む出力の形を揃える — ばらついていると、ばらついた出力を学ぶ
2. 2実際に使う入力に近づける — 想定と違う入力では効かない
3. 3機微な情報を除く — 学習させると取り出せなくなる
4. 4少数から始めて効果を見る — いきなり大量に作らない

1番目が最も効きます。「だいたいこんな感じ」で集めたデータは、だいたいの出力しか生みません。形式を揃えたいなら、学習データの形式が完全に揃っている必要があります。

学習したら、本当に良くなったかを確認します。感覚ではなく、比較で判断してください。

2行目が重要です。「プロンプトを工夫した状態」と比較しないと、追加学習の効果が分かりません。学習前の素の状態と比べると、実際にはプロンプトで得られたはずの改善まで、追加学習の効果に見えてしまいます。

4行目も見落とされます。特定の用途に合わせると、他が劣化することがあります。用途を絞って使うなら問題ありませんが、汎用に使うつもりなら確認が要ります。

そして、効果が小さければやめる。差分を破棄すれば元に戻ります。元のモデルを変えていないという利点が、ここで効きます。