Open9
gptのファインチューニング
これを読む
利点
- プロンプトよりも高品質な結果
- プロンプトに収まりきれない多くの例で訓練できる
- プロンプトが短いのでトークン節約
- リクエストが低遅延になる
現状、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に新しい知識を与える
- ファインチューニング
- ジェネラルなモデルに対し、フォーカスを狭めさせる。また、特定の振る舞いパターンを覚えさせる
ログインするとコメントできます