GPT-4.1シリーズがAzureでFT対応したので検証してみた
Azure OpenAI Service で GPT4.1 と GPT-4.1 で Fine-Tuning ができるようになったとのことなので、早速試してみました。
Fine-Tuing とは
-
より高品質な応答
単なるプロンプトエンジニアリングでは対応が難しい高度なタスクや、固有のドメイン知識への対応度を高めることができます。 -
文脈長制限を超える学習が可能
通常のプロンプトに入るサンプル数よりもはるかに多くの学習データを利用できるため、モデルが学習できる情報量が増えます。 -
トークン削減やレイテンシ改善
ファインチューニングによって「指示例や余計な手がかり」をプロンプトに詰め込む必要が減るため、トークン数を削減してコストを下げられます。さらに、より小さいモデルでも応答精度を補えるため、レイテンシを抑えることが可能です。
なお、Azure OpenAI Service では LoRA (Low-Rank Adaptation) という手法で効率的に Fine-Tuning を行っているそうです。
Azure OpenAI における Fine-Tuning の流れ
Azure OpenAI の Fine-Tuning は、以下のステップで進めます。
-
学習データ（トレーニング、バリデーション）を準備
JSON Lines（JSONL）形式で、Chat Completion と同じ形式のroleとcontentを含むデータを作成します。 -
データのアップロード
トレーニングデータとバリデーションデータを Azure OpenAI へアップロードします。 -
Fine-Tuning ジョブの作成
アップロードしたファイル ID とベースモデルを指定し、Fine-Tuning を開始します。 -
学習ステータスの確認
ジョブの進行状況やイベントログ、チェックポイントの状態などを確認します。 -
モデルの分析（結果ファイルの確認）
Fine-Tuning 完了後に生成されるresults.csvを確認し、学習中の損失（loss）や正解率（accuracy）を分析します。 -
デプロイ
Fine-Tuning 後のモデルをエンドポイントとしてデプロイすると、実際の推論処理に使用できます。
実際のFine-Tuningしてみる
データセットの準備
今回は以下のデータセットを使用しました。文末に「~ござる + Emoji🤗」がつくように加工されたデータセットです。 Fine-Tuning に使う JSONL ファイルは、1行に1つの会話ログを記述します。
{"messages": [{"role": "system", "content": "システムプロンプト"}, {"role": "user", "content": "インプット内容"}, {"role": "assistant", "content": "アウト内容"}]}
以下コードでダウンロードします。
from datasets import load_dataset
import json
import random
# Load the dataset (adjust the name if needed)
dataset = load_dataset("bbz662bbz/databricks-dolly-15k-ja-gozaru")
# Emoji list for appending to assistant messages
emojis = ["🙂", "😉", "😄", "🤖", "✨", "🎉", "🚀"]
output_file = "dolly_15k_gozaru_ft_ready.jsonl"
with open(output_file, "w", encoding="utf-8") as f:
for item in dataset["train"]:
record = {
"messages": [
{
"role": "system",
"content": "Clippy is a factual chatbot that is also sarcastic."
},
{
"role": "user",
"content": item["instruction"] # User prompt
},
{
"role": "assistant",
"content": item["output"] + " " + random.choice(emojis) # Assistant reply + emoji
}
]
}
# Write JSONL line without escaping Japanese
f.write(json.dumps(record, ensure_ascii=False) + "\n")
print(f"完了！Azure OpenAI用JSONLファイルを生成しました: {output_file}")
Azure Portal での初期設定
Azure Portal を使うのが簡単そうだったので、まずはそちらで試しました。
私自身は AI Foundry が好きなので、今後のためにAOAIをConnection しておきました。
なお、リージョンはいつも使っている East US2 が対応していなかったため、Sweden Central を選択しています。
現在対応しているFine-tuing Model
| モデルID | ファインチューニング可能リージョン | 最大リクエスト（トークン） | 学習データ取得時期 | モダリティ |
|---|---|---|---|---|
| gpt-35-turbo (1106) | East US2、North Central US、Sweden Central、Switzerland West | 入力: 16,385 / 出力: 4,096 | 2021年9月 | テキスト→テキスト |
| gpt-35-turbo (0125) | East US2、North Central US、Sweden Central、Switzerland West | 入力: 16,385 | 2021年9月 | テキスト→テキスト |
| gpt-4o-mini (2024-07-18) | North Central US、Sweden Central | 入力: 128,000 / 出力: 16,384（学習例コンテキスト長: 65,536） | 2023年10月 | テキスト→テキスト |
| gpt-4o (2024-08-06) | East US2、North Central US、Sweden Central | 入力: 128,000 / 出力: 16,384（学習例コンテキスト長: 65,536） | 2023年10月 | テキスト＆ビジョン→テキスト |
| gpt-4.1 (2025-04-14) | North Central US、Sweden Central | 入力: 128,000 / 出力: 16,384（学習例コンテキスト長: 65,536） | 2024年5月 | テキスト→テキスト |
| gpt-4.1-mini (2025-04-14) | North Central US、Sweden Central | 入力: 128,000 / 出力: 16,384（学習例コンテキスト長: 65,536） | 2024年5月 | テキスト→テキスト |
AI Foundry から Fine-Tuning モデルを選択します。
※ 現在 GPT-4.1 と GPT-4.1-mini は...
各種パラメーターの設定について
以下のように各種設定を行います。
| 区分 | 項目名 | 説明 |
|---|---|---|
| 基本項目 | Method（学習方法） | Supervisedを選択すると、与えられた入力と正解データに基づいてモデルを微調整します。モデルによっては、DPOやRFTも選択可能です。 |
| 基本項目 | Base model | ファインチューニングの元となるモデルを選びます。例：gpt-4.1-mini-2025-04-14 など。 |
| 基本項目 | Training data |
.jsonl形式の学習用データ。必須項目です。 |
| 基本項目 | Validation data | モデルの汎化性能を評価するためのデータ。 指定しない場合はトレーニングデータの一部が検証に使用される可能性があります。 |
| オプション設定 | Suffix | 出力されるファインチューニング済みモデルの名前に付加される任意の文字列。例：custom-gpt-model-v1 など。 |
| オプション設定 | Seed | 同じ条件で再現性を持たせるための乱数初期値。 未指定の場合は自動で生成されます。 |
| ハイパーパラメータ | Batch Size | 1ステップで処理されるデータ数。Defaultではトレーニングデータの0.2%（最大32）が自動設定されます。 |
| ハイパーパラメータ | Learning rate multiplier（学習率倍率） | 元の学習率に掛ける倍率。 通常 0.5〜2.0 程度で調整します。大きなバッチサイズでは大きめに設定しても安定しやすいです。 範囲：0.0〜10.0 |
| ハイパーパラメータ | Number of epochs（エポック数） | データセット全体を何周するか。1エポック = 全データ1周分の学習。Defaultでは自動設定されます。必要ならチェックボックスをオンにして明示指定可能。 |
Fine-tuning 各設定をいじるとどうなるか？（参考までに）
Suffix
モデル名に追加されるだけで学習・性能には影響しません。バージョン管理や識別用に使えます（例: -v1、-test）。
Seed
同じ Seed を使うと再現性が高まります。異なる Seed だと結果が微妙に変化する可能性があります。
Batch Size（バッチサイズ）
1 ステップで処理するデータ数です。大きいほど学習が速い一方、メモリ消費や過学習リスクが増します。小さいほど学習が安定しますが、時間がかかります。
Learning rate multiplier（学習率倍率）
パラメータ更新の速さを調整します。高いほど学習が速く進みますが不安定になりやすく、低いほど安定しますが学習速度が落ちます。
Number of epochs（エポック数）
データを何周させるかを決めます。増やすと精度向上が期待できますが、過学習リスクも高まります。
| 目標 | 調整ポイント |
|---|---|
| 早く学習したい | Batch sizeを大きく、Learning rateもやや上げる |
| 精度を高めたい | エポック数を増やし、Learning rateは低めに |
| 過学習を防ぎたい | エポック数を減らし、Validationデータを使う |
| 再現性が欲しい | Seedを固定する |
Fine-tuning 失敗しないためのポイント（参考までに）
学習率（Learning Rate）を上げすぎない
- 最初は 0.5〜1.0 程度からスタート
- 大きすぎると学習が発散するリスク
- 大きめの Batch size なら少し高めに設定してみるのも手
エポック数（Epochs）を増やしすぎない
- 最初は 1~3エポック程度からスタート
- 必要なら 3~5エポック程度まで増やす
- 必要以上にあげると過学習リスクが高まる
Validationデータを必ず分ける
- トレーニングデータのみだと汎化性能を正しく評価できない。
- データセットの**約20%**はバリデーション用に確保し、別ファイルで指定する
小さいデータセットでは慎重に設定する
- トレーニングデータの
0.2%（最大256）がデフォルト値 - 小規模データセット（例：数百件）では、Batch Sizeは小さめに設定
- 大規模データセットに対しては大きなBatch Sizeが適してる場合がある
- 適正範囲を超えると学習不安定のリスク
データのアップロードについて
Traning Data のアップロードには複数の方法があり、アップロード後は上位 3 行のプレビューが確認できます。
設定が完了したらトレーニングを開始します。
私の場合、データセットの文字数が多すぎてエラーになりました。
prompt と completion を合わせたトークン数が gpt-4.1-mini モデルでは 8192 トークンを超えてはいけないため、超過するデータ行を削除しました。
その他にもいくつか制限事項があります。
-
ファイルサイズ制限
- 1ファイルあたり 100MB未満。
-
1例（1行）あたりの最大トークン数
-
prompt+completion合計でモデルごとに制限あり。- 例：gpt-4.1-mini → 8192トークン以下
-
-
ファイル形式
- 必ず JSONL形式
-
ファイル数
- 複数ファイルのアップロード可能。ただし、ファインチューニングジョブ作成時は Training用・Validation用 それぞれ1ファイルずつ指定。
-
データ内容
- 画像・バイナリファイルは使用不可。テキストのみ対応。
- 画像データを使いたい場合はテキスト化して使用する。
-
エンコーディング
- ファイルは必ず UTF-8（BOMなし） で保存する。
-
その他
- 不正なJSON形式やトークンオーバーすると 400エラー が発生。
トレーニングと学習ステータスの確認
Azure OpenAI の Fine-Tuning ジョブ進行状況を把握することは、モデル品質向上やトラブルシューティングにおいて重要です。
ジョブステータスの確認
Fine-Tuning ジョブのステータスは、Azure AI Foundry ポータルの「Fine-tuning」ページで確認できます。
-
ステータスの種類
queued、running、succeeded、failedなどがあります。 -
注意点
ジョブがrunningのまま長時間変化しない場合でも、これは共有リソースの状況や内部処理によるものであり、必ずしもエラーを意味するわけではありません。
実際のトレーニング中の画面: Detail
実際のトレーニング中の画面: Detail
チェックポイントの活用
Fine-Tuning ジョブでは各エポック終了時にチェックポイントが生成されます。
-
特徴
最終結果のモデルに加えて、直近 2 回分のチェックポイントが保存され、いずれもデプロイ可能です。 -
活用方法
過学習を避けるために、最終エポックより手前のチェックポイントをデプロイする選択肢もあります。
また、既存のチェックポイントを基に継続的に Fine-Tuning を行うことも可能です。
実際のトレーニング中の画面: CheckPoint
結果ファイル（results.csv）の分析
Fine-Tuning ジョブが完了すると、results.csv ファイルが生成され、学習の詳細なログが記録されています。
-
主なカラム
-
step: トレーニングステップの番号 -
train_loss: トレーニングデータに対する損失値 -
train_mean_token_accuracy: トレーニングデータのトークン精度 -
valid_loss: バリデーションデータに対する損失値 -
validation_mean_token_accuracy: バリデーションデータのトークン精度
-
-
分析のポイント
train_lossとvalid_lossの差が大きくなる場合は過学習の兆候です。
また、validation_mean_token_accuracyが停滞または低下する場合は、学習率やエポック数を調整することを検討します。 -
理想的な学習パターン
training_lossとvalidation_lossが徐々に減少する
accuracyが徐々に増加する
validation_lossが途中から上がり続けたら過学習の兆候
実際のトレーニング結果: Metrics
シンプルなデータセットのため、20～30ステップで損失が急激に低下し早期に収束したしました。
同時にトークン精度が0.6→0.9以上まで短時間で向上し、その後はほぼ横ばいとなりました。
デプロイ
Fine-Tuning 後に作成されたカスタムモデルは、エンドポイントとしてデプロイすることで推論 API として利用できます。
デプロイできましたので早速チャットしてみましたが、学習後すぐには利用ができないようです。
5分ぐらいしたら、返答が返ってきました。システムプロンプトに何も指示していませんが、しっかりと「ござる+Emoji🤗」になってます。
Evaluation API の導入: コードファーストで大規模に評価
Stored Completions API のリリースに続いて、Evaluation API を新たに提供開始されたとのこと。こちらはモデル出力の品質を自動かつ精密に評価するための強力なツールで、
デベロッパーは標準搭載のグレーダー (文字列マッチやオブジェクト比較など) を使用するか、ユースケースに合わせたカスタム グレーダーを定義して補完結果をスコアリングできます。A/B テストやリグレッション検証、モデルの反復的改善を大規模かつプログラム的に実行可能にします。
Stored Completions と組み合わせることで、コードのみで生成、保存、評価、ファインチューニングまでを完結できるため、人的な作業負荷を減らし、蒸留サイクルを加速させることが可能です。
また機会があれば触ってみたいと思います。
最後に
Azure OpenAI Service の中で Fine-Tuning によるパラメーター調整がある程度可能だというのは大きな発見でした。短時間で学習を開始できる点や継続的に学習＆評価できる点も便利だと思います。これからも用途に合わせてモデルをチューニングしていきたいです。
引用
Discussion