私のファインチューニングモデルはOpenAI GPT-4を上回る

 (mlops.systems)
1 ポイント 投稿者 GN⁺ 2024-07-02 | まだコメントはありません。 | WhatsAppで共有
  • ISAFのプレスリリースで構造化データ抽出を行った724件のテストで、複数のファインチューニングモデルがGPT-4系より高い精度を示した
  • 比較対象にはGPT-4o、GPT-4 Turbo、GPT-3.5 Turboと、TinyLlama、Mistral、Llama3、Solar、GPT-3.5ベースのファインチューニングモデルが含まれる
  • OpenAIモデルは常に有効なJSONを出力し、Mistral・Llama3のファインチューニングも安定していたが、TinyLlamaはテンプレートによって欠損値とJSON品質の差が大きかった
  • 最終集計では、OpenPipeでファインチューニングしたMistral-7Bが1位で、Solar LLMとLlama3-7Bが僅差で続いた
  • ファインチューニングはプライバシー、制御性、コスト改善の可能性をもたらす一方、複数環境に分散したモデルの推論・評価・再現性を管理するMLOpsの複雑性も増大する

実験の目的とデータセット

  • 目的は、ISAFのプレスリリースからイベント情報を抽出するタスクにおけるファインチューニングLLMの精度を評価すること
  • データはHugging Face Hubの公開リポジトリにあり、評価はモデルが見ていないtest splitで実施された
    • テストデータは724行で構成される
    • フィールドには name, eventrefnumber, text, StartDate, eventtype, province, targetgroup, minkilled, mincaptured, killq, captureq, killcaptureraid, airstrike, noshotsfired, minleaderskilled, minleaderscaptured などが含まれる
  • 各行は検証と処理を容易にするためPydanticオブジェクトに変換された
  • モデル出力には次のJSON構造を期待する
    • name
    • start_date
    • event_type
    • province
    • target_group
    • min_killed
    • min_captured
    • killq
    • captureq
    • killcaptureraid
    • airstrike
    • noshotsfired
    • min_leaders_killed
    • min_leaders_captured

OpenAI基準モデルの評価方法

  • 基準比較対象としてGPT-4o、GPT-4 Turbo、GPT-3.5 Turboが使われた
  • GPTモデルはファインチューニングモデルと同じプロンプトをそのまま使えず、より長いプロンプトが必要だった
    • 抽出するフィールド一覧を明示
    • イベントタイプ、州、ターゲットグループの許容値を提供
    • 数値注釈ルールを含める
    • 例示用のプレスリリースと期待JSON出力を一緒に入れる
  • 数値注釈ルールでは次の基準を用いた
    • a couple は2と解釈
    • several は最小3と解釈
    • a few, some, a group, a small group, multiple は最小3と解釈
    • numerous, a handful は最小4と解釈
    • a large number は最小5と解釈
    • facilitator は leader ではない
  • 大量予測は非同期で実行され、GPT-3.5 Turboのrate limitのため再試行ロジックが追加された
  • 予測結果は各イベントの predictions フィールドにモデル名ごとに保存された

ファインチューニングモデルの構成

  • OpenAI基準モデルの予測後、以前にファインチューニングしたローカルモデルとワンクリックのファインチューニングサービスベースのモデルの予測を同じデータセットに追加した
  • 含まれたファインチューニングモデルは次の通り
    • tinyllama-templatefree
    • tinyllama-sharegpt
    • mistral-lora-templatefree
    • finetuned-openai-gpt-3.5-turbo-1106
    • finetuned-mistral-7b-optimised-openpipe
    • ft-solar-1-mini-chat-240612-predibase
    • finetuned-llama3-7b-32k-openpipe
  • Mistralのローカルファインチューニングモデルはローカル実行が難しく、ModalのA100環境で推論された
    • その後の評価ではほぼすべての項目で失敗した
    • チャートでは mistral-lora-templatefree と表示される
  • OpenAIのワンクリックファインチューニングサービスで gpt-3.5-turbo-1106 モデルをファインチューニングした
  • OpenPipeでMistral 7B、Mistral 8x7B、Llama3モデルの予測を生成した
  • PredibaseではUpstageのSolar LLMベースモデルを評価した
    • Solar LLMは、構造化データ抽出のようにファインチューニングがよく使われるタスクに強いよう学習されたモデルとして紹介されている
    • ベースモデルはHugging Face Hubの upstage/SOLAR-10.7B-v1.0 と推定される
  • Qwen2のPredibase推論は動作せず、今回の評価から除外された
  • 最終予測データセットはHugging Face Hubの公開データセットに公開された

JSONの妥当性と欠損値

  • 最初の評価は、各モデル出力が有効なJSONかどうかを確認する方法で行われた
  • OpenAIモデルは毎回有効なJSONを生成した
  • ファインチューニングしたMistralとLlama3モデルも安定して有効なJSONを出力した
  • TinyLlamaはテンプレート選択によって結果が大きく分かれた
    • tinyllama-sharegpt には38件の欠損値があった
    • 欠損値がなければ、724件の予測と有効JSONをすべて備えていたと考えられる
  • 欠損値の集計は次の通り
    • gpt-4o: 0
    • gpt-4-turbo: 0
    • gpt-3.5-turbo: 0
    • tinyllama-templatefree: 0
    • tinyllama-sharegpt: 38
    • finetuned-openai-gpt-3.5-turbo-1106: 0
    • finetuned-llama3-7b-32k-openpipe: 0
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 0
    • ft-solar-1-mini-chat-240612-predibase: 0

フィールド別精度

  • 精度評価は合計13個の属性を基準に行われた
    • start_date
    • province
    • target_group
    • event_type
    • min_killed
    • min_captured
    • killq
    • captureq
    • killcaptureraid
    • airstrike
    • noshotsfired
    • min_leaders_killed
    • min_leaders_captured
  • すべてのチャートの総タスク数は724件

  • start_date

    • start_date の精度ではSolarとファインチューニングしたGPT-3.5モデルが最も良い性能を示した
    • スコアは次の通り
      • gpt-4o: 527
      • gpt-4-turbo: 522
      • gpt-3.5-turbo: 492
      • tinyllama-templatefree: 231
      • tinyllama-sharegpt: 479
      • finetuned-openai-gpt-3.5-turbo-1106: 646
      • finetuned-llama3-7b-32k-openpipe: 585
      • mistral-lora-templatefree: 0
      • finetuned-mistral-7b-optimised-openpipe: 636
      • ft-solar-1-mini-chat-240612-predibase: 649
    • 最上位モデルでも日付を75件誤っており、日付抽出にはまだ改善の余地がある

  • province

    • 州（province）の予測では、ファインチューニングモデルがOpenAIモデルを上回った
    • スコアは次の通り
      • gpt-4o: 649
      • gpt-4-turbo: 645
      • gpt-3.5-turbo: 595
      • tinyllama-templatefree: 335
      • tinyllama-sharegpt: 660
      • finetuned-openai-gpt-3.5-turbo-1106: 704
      • finetuned-llama3-7b-32k-openpipe: 707
      • mistral-lora-templatefree: 0
      • finetuned-mistral-7b-optimised-openpipe: 711
      • ft-solar-1-mini-chat-240612-predibase: 704

  • target_group と event_type

    • target_group は複数グループがあり得るため、正解グループのうちモデルが当てた割合でスコアを計算した
    • ファインチューニングモデルはターゲットグループの識別でOpenAIモデルより有意に良い性能を示した
    • ただし、学習データになかった新しいグループが追加されると性能が低下する可能性がある
    • event_type は意味的に重なるカテゴリがあり、人間のアノテータにとっても難しい項目とされた
    • この難しい項目でもファインチューニングモデルは良い性能を示した

  • 数値とブール値のフィールド

    • min_killed のような数値推定では、ファインチューニングモデルとOpenAIモデルの差は小さくなった
    • Mistralが最も高かったが差は大きくなく、OpenAIモデルもこの項目では良い性能を示した
    • 長いプロンプトに含まれた数値注釈ルールが役立った可能性がある
    • killq のようなブール属性は、ほとんどのモデルが高い精度を記録した
    • ファインチューニングしたMistralは、この項目でもGPT-4oの最高スコアを上回った
    • killcaptureraid はOpenAIモデルに不利な項目として現れた
      • kill-capture raid はラベリングで特定の意味で使われる専門用語だった
      • OpenAIモデルはそのラベリング判断基準を知らなかった
    • noshotsfired は、特定期間のプレスリリースが「発砲がなかった」ことを強調していたことから生まれたフィールド
    • OpenAIモデルは期待とは逆の順序で性能を示し、原因の理解には追加調査が必要
    • min_leaders_killed と min_leaders_captured では全体的に高いスコアが出た
    • LLMは数値に弱いという一般的な認識とは異なり、このタスクでは高い性能を示したが、それでもファインチューニングモデルが最良の結果を出した

最終集計結果

  • 13個の個別精度スコアを合算し、その平均から0〜100スケールの最終集計精度を計算した
  • 最終結果ではファインチューニングモデルがOpenAI GPT系モデルを上回った
  • TinyLlamaもGPT-3.5 Turboより高い集計精度を示した
  • 最高性能モデルはOpenPipeでファインチューニングしたMistral-7Bだった
  • Solar LLMとLlama3-7BがMistral-7Bにごく僅差で続いた
  • 構造化データ抽出のファインチューニングでは、Mistral-7B、Solar 7B、Llama3-7Bから始めて、どのモデルが最も適しているか比較するアプローチが有効に見える
  • 精度だけを見ると、3モデルはほぼ同等かもしれない
  • モデルサービング、効率、レイテンシには別のトレードオフがあり得る

ファインチューニングの利点とコスト

  • OpenAIモデルもプロンプトにより多くの例やルールを入れれば性能を高められる
  • ただし、プロンプトが長くなるとリクエストあたりのコストが増える
  • 自前のファインチューニングモデルは次の利点を提供する
    • 機密情報をOpenAIに送らずに済むデータプライバシー
    • より小さなモデルによる潜在的な性能向上
    • より大きな制御権
    • コスト改善の可能性
  • コスト比較は現時点では明確に断定しにくい
    • 大手クラウドプロバイダは規模の経済を活用できる
    • 長期的に反復推論する実運用のユースケースでは、自前モデルのコスト論理がより説得力を持つ可能性がある
    • OpenAI呼び出しを改善するには多くの例と説明を入れる必要があり、クエリごとのコストが増える可能性がある

評価運用とMLOpsの複雑性

  • ファインチューニングは比較的少ない調整でGPT-4より良い性能を示した
    • 使用したモデルは、取り込んだデータで作成した最初のファインチューニングモデル群だった
    • ほとんどはデフォルト設定を使用した
  • 今後はSolar、Llama3、Mistral 7Bモデルに注力する予定
  • 評価はJupyter notebook中心で実装され、運用は煩雑だった
    • 一部のモデルはローカルで動作した
    • 一部のモデルは異なるサービスや環境にデプロイされていた
    • 724行を順に処理する方式は遅かった
  • 次の反復では、評価をローカルで実行できるようにし、データの一部スライスだけを先に評価してから全体データへ拡張する方法が必要
  • 同じプロジェクトで複数モデルを扱う場合は標準化された推論インターフェースが必要
  • モデルが複数箇所に分散し、ファインチューニングや更新が繰り返され、データも継続的に変わるなら、それを管理する仕組みが必要になる
  • ファインチューニングLLMの主なトレードオフは、安定的で再現可能な運用のために多くの構成要素を管理しなければならない点にある

評価がもたらした価値と次のステップ

  • 評価実装は煩雑だったが、学習データやモデル改善が実際の進展につながっているか確認するためのタスク特化ベンチマークを提供した
  • 評価がなければ改善の有無を判断しにくい
  • 複数の超特化モデルを個別に作るというアイデアは、現時点で明確な次の一手ではない
    • 例: 捕捉人数推定だけが得意な別モデル
    • 現在のモデル性能を見る限り、このアプローチで精度が大きく向上するかは不明
  • 優先度の高い次のステップは、精度以外の評価を実施すること
    • 前回の記事で言及したout-of-domainデータ評価がその例
    • まったく異なるトピックのダミーデータに対する挙動を確認したいとしている
  • もう1つの次のステップは、上位3モデルのLLMサービングをより深く調べること
    • LLMサービングには、非LLMモデルのサービングとは異なるツール、トレードオフ、手法がある
  • さらに深く問題を掘り下げるなら、誤答事例をLilacやArgillaのようなWebインターフェースに載せて失敗パターンを分析するアプローチが有用
  • 失敗シナリオの理解は、ファインチューニングパラメータの調整よりも精度改善に役立つ可能性がある

関連記事

まだコメントはありません。

まだコメントはありません。