gptのファインチューニング

https://platform.openai.com/docs/guides/fine-tuning

これを読む

利点

• プロンプトよりも高品質な結果
• プロンプトに収まりきれない多くの例で訓練できる
• プロンプトが短いのでトークン節約
• リクエストが低遅延になる

現状、gpt3.5まで提供されている

使い所の注意点

• 基本、まずはプロンプトエンジニアリングやfunction callを試すべき。
• 理由
  • それで十分なケースも多い
  • ファインチューニングは時間がかかる。PDCAが回しづらい
  • ファインチューニングが必要な場合でも、プロンプトエンジニアリングは無駄にならない。良いプロンプトをファインチューニングデータに使用すると良い結果になる。

ユースケース

• スタイル、トーンなど定性的なものの学習

• 信頼性の向上

• 複雑なプロンプトに従うための失敗の訂正

• エッジケースへの対処

• プロンプトで明示するのが難しい新しいスキルやタスクの実行

• ファインチューニングでは、「show, not tell」が基本。これがハマるケースは良い。

• また、GPT4を使わなくても良い品質が得られる場合があるため、結果的に遅延やコスト削減になる。

訓練

• chat completionと同じフォーマットで入れる。
• プロダクションでの理想の会話をインプットする。
• ファインチューニング前に、めっちゃ上手くいったプロンプトと指示の全てをトレーニング例に含めることが推奨される。これにより、特にトレーニング例が比較的少ない（e.g., 100以下）場合に良い結果が得られる。
• インプットする例の量は最低10。明確な性能向上が見られるのは50~100以上入れた時。ただタスク依存。
  • 50ぐらいの厳選された例を入れて、それでよくなる兆候があったらもっと入れると良い。
  • 逆にそれで兆候がなかったらもう一度考え直した方がいいかも
• trainデータとtestデータを用意して入れると、それぞれの統計情報が得られる。これによりモデルがどのぐらい良くなってるか把握できる

データクオリティを上げる

ファインチューニングが上手くいかない時のデータの修正

• 上手くいかないところを補完するような例を与える
• 悪い例が混ざってないか確かめる
• 例が偏ってないか確かめる
• 返答に必要な情報が全て例に含まれてるか確かめる
• 例に一貫性があるか確かめる
• 例の返答フォーマットが期待するフォーマットと同じか確かめる

データ量を増やす

• 現在の例の数と、その半分の例の数でそれぞれファインチューニングして、その差を見ると、どれぐらい精度が向上しそうかわかる
• ただ一般に、ゴミデータがいっぱいあるよりも、いいデータが少量ある方が良い

ハイパラチューニング

• epoch数いじれる

上手くいく例

• スタイルとトーン
• 出力を特定のフォーマット(JSONなど)に整形させる

FAQ

• embedding + retrievalとファインチューニングどちらがいいか
  • 目的が違う
  • embedding + retrieval
    • GPTに新しい知識を与える
  • ファインチューニング
    • ジェネラルなモデルに対し、フォーカスを狭めさせる。また、特定の振る舞いパターンを覚えさせる