Alibaba Cloud Model Studio:ファインチューニングデータのアップロードルール

本ドキュメントでは、テキスト生成モデルのファインチューニングデータに関するフォーマット仕様、パッケージング要件、サイズと数量の制限、および API アップロードクォータについて説明します。これにより、ユーザーはトレーニング手法に応じて、コンプライアンスに準拠した SFT/DPO/CPT トレーニングデータを構築し、アップロードすることができます。

概要

本ドキュメントでは、テキスト生成モデルのファインチューニングデータに関するフォーマット仕様、パッケージング要件、サイズと数量の制限、および API アップロードクォータについて説明します。対象範囲は、テキスト生成モデルのファインチューニング (テキスト/画像/動画 → テキスト) であり、プレーンテキストの SFT/DPO/CPT、Qwen VL の画像・動画理解、動画フレーム抽出、関数呼び出し、思考などが含まれます。動画生成モデルのファインチューニング (画像 → 動画) は対象外です。

データセットのタイプ (トレーニングセットまたは評価セット) は、作成後に変更することはできません。各トレーニング手法と要素のサポート状況については、「トレーニング手法と要素のサポートマトリックス」で詳しく説明します。各組み合わせのフォーマット構築ルールについては、以下の対応する章で説明します。

管理操作 (作成パラメーター、バージョン管理、評価セット管理ルール、インポート方法の選択、データクレンジング、セキュリティとコンプライアンス) については、関連ドキュメントで説明しています。詳細については、「トレーニングセットと評価セット」、「モデルファインチューニングの概要」などをご参照ください。インポートの失敗を避けるため、データセット作成ページで対応するシナリオのデータテンプレートをダウンロードし、テンプレートの構造に従ってデータを準備することを推奨します。

データセット構築の推奨事項 (推奨されるデータ規模、多様性とバランス、データ拡張戦略) については、「モデルファインチューニングの概要 - データセット構築のヒント」をご参照ください。

トレーニング手法と要素のサポートマトリックス

トレーニングセットは、SFT、DPO、CPT の 3 つのトレーニング手法をサポートしています。各トレーニング手法と要素のサポート状況を以下のマトリックス表に示します。推奨されるファインチューニングの順序は CPT (任意) → SFT → DPO (任意) です。これら 3 つは段階的な関係にあり、相互排他的ではありません。

リージョン別の可用性：

• SFT、ローカルアップロード、ログリプレイ、API アップロード、およびマルチモーダルデータフォーマットは、すべてのリージョンでサポートされています。
• DPO、CPT、Object Storage Service (OSS) インポート、およびクラウドストレージマウントは、中国 (北京) リージョンでのみサポートされています。

トレーニング手法と要素のサポートマトリックスは以下の通りです：

マトリックス表の各トレーニング手法は、対応する詳細な説明セクションにリンクしています。フィールドの定義については、次のセクションをご参照ください。

トレーニング手法 SFT/DPO/CPT のフィールド定義については、「モデルファインチューニングの概要」をご参照ください。

テキスト生成 - SFT フォーマット

SFT テキスト生成のトレーニングデータは、ChatML の messages マルチターン構造に基づいた jsonl ファイル形式を使用します。

• system、user、assistant の 3 つのロールをサポートします。content フィールドは文字列です (マルチモーダルシナリオの content 配列構造については、対応するマルチモーダルフォーマットの章をご参照ください)。
• 単一ファイルの最大サイズは 200 MB です。
• 1 つのデータセットには、異なるフォーマットの行を混在させることができます。各レコードは独立してフォーマットを選択でき、単一のフォーマットに統一する必要はありません。
• 利用可能なフォーマット：標準 ChatML、思考、関数呼び出し、および関数呼び出しと思考の組み合わせ (以下のサンプルタブページをご参照ください)。

SFT テキスト生成は、以下のサンプルフォーマットをサポートしています。各サンプルの完全な JSON 構造は、対応するタブに表示されます：

{
  "messages": [
    {"role": "system", "content": "System input 1"},
    {"role": "user", "content": "User input 1"},
    {"role": "assistant", "content": "Expected model output 1"},
    {"role": "user", "content": "User input 2"},
    {"role": "assistant", "content": "Expected model output 2"}
  ]
}

{"role": "assistant", "content": "Expected model output", "loss_weight": "1.0"}

{
  "messages": [
    {"role": "system", "content": "System input 1"},
    {"role": "user", "content": "User input 1"},
    {"role": "assistant", "content": "Model output 1"},
    {"role": "user", "content": "User input 2"},
    {"role": "assistant", "content": "<think>\nExpected thinking content 2\n</think>\n\nExpected output 2"}
  ]
}

思考タグのルール

思考コンテンツは <think>\n…\n</think>\n\n タグで囲み、assistant の出力テキスト内に配置します (最終的な返信と同じ最後の assistant の content を共有します)。ルールは以下の通りです：

• 最後の assistant の出力にのみ配置できます。中間の assistant の出力に思考タグを含めてはいけません。
• 思考タグの前後の改行は維持する必要があります。
• トレーニングサンプルでモデルが思考タグを出力しないように設定した場合、トレーニング後にモデルを呼び出す際に思考モードを再度有効にすることは推奨されません。

評価セットのフォーマット

評価セットはテキスト生成シナリオのみに対応し、SFT/DPO/CPT のトレーニング手法とは独立しています。DPO/CPT でトレーニングされたモデルも、評価にはテキスト生成評価セットを使用し、トレーニング手法による区別はありません。

評価セットの仕様：

• ファイル形式は xlsx です。列構造はコンソールからダウンロードしたテンプレートで確認できます。
• 取り込み方法：ローカルアップロードとログリプレイをサポートします。Object Storage Service (OSS) インポートとクラウドストレージマウントはサポートされていません。
• ドラフトバージョンのみがオンライン編集 (Prompt/Completion) をサポートします。公開されたバージョンは編集できません。

ローカルアップロードのフォーマット説明：

{"prompt": "Who painted the human body during the Renaissance?", "completion": "The Renaissance was a revival movement of art, culture, and scholarship, during which many artists painted the human body."}
{"prompt": "Why does the Sun emit light and heat?", "completion": "The Sun generates tremendous energy from the fusion of hydrogen nuclei under high temperature and pressure. This fusion reaction releases large amounts of light and heat."}
{"prompt": "Why is the sky blue?", "completion": "When sunlight reaches the Earth's atmosphere, the shorter-wavelength blue light is scattered by gas molecules in the atmosphere, forming the blue sky we see."}

ログリプレイの取り込み制限：

• サポートされるログの範囲は過去 30 日以内です。
• 1 回のインポートで最大 100,000 レコードです。
• サービスリンクロールを権限付与し、API キーとモデルのフィルター条件を指定する必要があります。
• トレーニングセットは SFT テキスト生成シナリオでのみ利用可能です (テキスト生成評価セットもサポートされています)。

ログリプレイの取り込み方法の詳細については、「ログリプレイ」をご参照ください。

評価セットは、重複しない独立したデータのコレクションであるべきで、モデルの汎化能力を客観的に評価するために使用されます。評価セットの管理ルールについては、「トレーニングセットと評価セット」をご参照ください。

テキスト生成 - DPO フォーマット

DPO テキスト生成のトレーニングデータは jsonl 形式を使用します。ChatML の messages マルチターン構造に基づいており、さらにプリファレンスアライメントトレーニングのために、chosen (選択された) と rejected (拒否された) という 2 つの対照的な assistant の出力を含みます。messages 内のすべての content が入力として使用され、DPO は最後の user 入力に対するモデルの肯定的/否定的なフィードバックをトレーニングするために使用されます。messages マルチターン構造のルールについては、「テキスト生成 - SFT フォーマット」をご参照ください。

ディープシンキングのコンテンツについては、chosen または rejected の assistant 出力を思考タグで囲むことができます。思考タグは最後の assistant の行にのみ配置できます。ルールについては、「テキスト生成 - SFT フォーマット」をご参照ください。

loss_weight パラメーター (招待制、Qwen3.5+ のみサポート) は chosen モジュールをサポートします。値の範囲は 0.0 から 1.0 で、値が大きいほどトレーニングの重要度が高くなります。詳細については、「テキスト生成 - SFT フォーマット」をご参照ください。

DPO トレーニングデータの単一ファイルサイズ制限は 200 MB で、SFT テキスト生成と同じです。DPO の定義については、「モデルファインチューニングの概要」をご参照ください。ドラフトと公開操作については、「トレーニングセットと評価セット」をご参照ください。

DPO テキスト生成トレーニングデータのサンプルについては、以下のコードブロックをご参照ください：

{
  "messages": [
    {"role": "system", "content": "System input"},
    {"role": "user", "content": "User input 1"},
    {"role": "assistant", "content": "Model output 1"},
    {"role": "user", "content": "User input 2"},
    {"role": "assistant", "content": "Model output 2"},
    {"role": "user", "content": "User input 3"}
  ],
  "chosen": {"role": "assistant", "content": "Preferred expected model output 3"},
  "rejected": {"role": "assistant", "content": "Rejected expected model output 3"}
}

{
  "messages": [
    {"role": "system", "content": "System input"},
    {"role": "user", "content": "User input 1"},
    {"role": "assistant", "content": "Model output 1"},
    {"role": "user", "content": "User input 2"}
  ],
  "chosen": {"role": "assistant", "content": "<think>\nExpected thinking content\n</think>\n\nExpected model output"},
  "rejected": {"role": "assistant", "content": "Rejected expected model output 2"}
}

テキスト生成 - CPT フォーマット

CPT テキスト生成のトレーニングデータは、jsonl プレーンテキスト形式を使用し、1 行に 1 つの jsonl オブジェクトを記述します。構造は {text} で、text フィールドはプレーンテキストのコンテンツです。messages マルチターン構造のルールについては、「テキスト生成 - SFT フォーマット」をご参照ください。

CPT トレーニングデータの制約：

• 最低 5,000 万トークンが推奨され、単一ファイルのサイズ制限は 300 MB です。
• ドラフト状態とデータ継承はサポートされていません。新しいバージョンごとに新しいデータを作成し、すぐに公開する必要があります。

CPT の定義については、「モデルファインチューニングの概要」をご参照ください。バージョン管理とデータ継承操作については、「トレーニングセットと評価セット」をご参照ください。CPT プレーンテキストサンプルの完全な JSON 構造は、以下のコードブロックに示されています。

各トレーニング手法で新しいバージョンを作成する際のデータ継承戦略は以下の通りです (CPT は既存データの継承をサポートしておらず、新しいバージョンごとに新しいデータを作成する必要があります)：

{text} プレーンテキスト形式のサンプル (1 行に 1 つの jsonl プレーンテキストオブジェクト)：

{
  "text": "Text content"
}

視覚理解 - SFT フォーマット

SFT 画像トレーニングデータは、Qwen VL マルチモーダル理解 (コンソール UI オプションは「画像理解」) に使用されます。data.jsonl トレーニングテキストデータファイルと画像ファイルを含む zip パッケージ形式を使用します。data.jsonl はパッケージのルートに配置する必要があります。data.jsonl の各トレーニングレコードの messages は、content 配列構造を採用し、配列アイテムには画像フィールド (image) とテキストフィールド (text) が含まれます。単層のディレクトリ構造を推奨します。パッケージングルールについては、「マルチモーダル zip パッケージのパッケージングルール」をご参照ください。

SFT 画像トレーニングの例を以下のタブに示します：

{
  "messages": [
    {"role": "system", "content": [{"text": "System input 1"}]},
    {"role": "user", "content": [{"text": "User input 1"}]},
    {"role": "assistant", "content": [{"text": "Expected model output 1"}]},
    {"role": "user", "content": [{"text": "User input 2"}]},
    {"role": "assistant", "content": [{"text": "Expected model output 2"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "System input 1"}]},
    {"role": "user", "content": [{"text": "User input 1"}]},
    {"role": "assistant", "content": [{"text": "Model output 1"}]},
    {"role": "user", "content": [{"text": "User input 2"}]},
    {"role": "assistant", "content": [{"text": "<think>\nExpected thinking content 2\n</think>\n\nExpected output 2"}]}
  ]
}

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "Query real-time weather for a specified city",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string", "description": "City name, e.g.: Beijing"}
          },
          "required": ["city"]
        }
      }
    }
  ],
  "messages": [
    {"role": "user", "content": [{"text": "Help me check the weather in Beijing"}]},
    {
      "role": "assistant",
      "content": [{"text": "OK, I will help you query the weather in Beijing."}],
      "tool_calls": [
        {
          "id": "call_3a11c1ba883b41b6a4e0cb",
          "type": "function",
          "function": {
            "name": "get_weather",
            "arguments": "{\"city\": \"Beijing\"}"
          }
        }
      ]
    },
    {"role": "tool", "tool_call_id": "call_3a11c1ba883b41b6a4e0cb", "content": [{"text": "{\"city\": \"Beijing\", \"weather\": \"Sunny\", \"temperature\": \"25℃\"}"}]},
    {"role": "assistant", "content": [{"text": "Beijing is sunny today, with a temperature of 25°C, suitable for going out."}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "System input"}]},
    {
      "role": "user",
      "content": [
        {"text": "User input 1"},
        {"image": "image_file1.jpg", "resized_width": 200, "resized_height": 200}
      ]
    },
    {"role": "assistant", "content": [{"text": "Expected model output 1"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "System input"}]},
    {
      "role": "user",
      "content": [
        {"text": "User input 1"},
        {"video": "video_file1.mp4", "fps": 3.0, "resized_width": 200, "resized_height": 200, "video_start": 0.0, "video_end": 3.0}
      ]
    },
    {"role": "assistant", "content": [{"text": "Expected model output 1"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "System input"}]},
    {
      "role": "user",
      "content": [
        {"text": "User input 2"},
        {"video": ["0.jpg", "1.jpg", "2.jpg", "3.jpg"], "sample_fps": 5.0, "resized_width": 200, "resized_height": 200}
      ]
    },
    {"role": "assistant", "content": [{"text": "Expected model output 2"}]}
  ]
}

マルチモーダル理解の定義については、「モデルファインチューニングの概要」をご参照ください。

ツールフィールドの説明

関数呼び出しモードは、マルチターンメッセージ構造の上に tools 定義と tool_calls/role:tool メカニズムを追加します。フィールドの制約は以下の通りです：

• tools：ツール定義の配列。各アイテムには type:"function" と function{name, description, parameters} が含まれます。parameters は JSON スキーマ (type/properties/required を含む) です。
• messages：マルチターン対話の配列。ロールには user、assistant、tool が含まれます。
• content：マルチモーダルコンテンツの配列。image、text、video などのアイテムを含むことができます (マルチモーダル理解フォーマットと一致)。
• assistant.tool_calls：モデルによって生成されたツール呼び出しの配列。id、type:"function"、function{name, arguments} を含みます。arguments は JSON 文字列です。
• role:"tool"：ツールの戻り値。tool_call_id は対応する tool_calls[].id と一対一で対応する必要があります。content にはツールの戻り結果が含まれます。

マルチターン対話の最後のメッセージは、通常、ツールの戻り値に基づいた assistant の最終的な返信です。ツールモードは SFT シナリオに属します。DPO シナリオでのツールデータのサポートについては、「テキスト生成 - DPO フォーマット」をご参照ください。

loss_weight フィールドの制約：

• 招待制パラメーター。値の範囲は 0.0 から 1.0。値が大きいほど、トレーニング中のこの行の相対的な重要度が高くなります。
• SFT 思考モデルの場合、最後の assistant 行のみが loss_weight をサポートします。

Bailian は OpenAI の name および weight パラメーターをサポートしていません。OpenAI/Azure から移行されたトレーニングデータには、name/weight フィールドを含めないでください。

データの多様性とバランスに関する推奨事項：各シナリオのデータ量は比較的バランスが取れているべきであり、データ比率は実際のシナリオ比率と一致させる必要があります。あるタイプのデータが多すぎると、モデルがそのタイプの特徴を学習する傾向が強まり、汎化能力に影響を与えるため、避けるべきです。

ChatML と loss_weight フィールドの定義については、「モデルファインチューニングの概要」をご参照ください。

思考タグのルール

思考コンテンツは <think>\n…\n</think>\n\n タグで囲み、assistant の出力テキスト内に配置します (最終的な返信と同じ最後の assistant の content に属します)。ルールは以下の通りです：

• 最後の assistant の出力にのみ配置する必要があります。中間の assistant の出力に思考タグを追加してはいけません。
• 思考タグの前後の改行は維持する必要があります。
• トレーニングサンプルでモデルが思考タグを出力しないように設定した場合、トレーニング完了後に呼び出しの際に思考モードを有効にすることは推奨されません。

マルチモーダル zip パッケージのパッケージングルール

マルチモーダル理解トレーニングデータは、データセットの追加 ページから zip パッケージとしてアップロードされます。パッケージングは以下の制約を満たす必要があります：

• zip パッケージは最大 2 GB までサポートされます。
• パッケージ内のフォルダ名とファイル名に使用できる文字セットは、ASCII 文字 (a-z, A-Z)、数字 (0-9)、アンダースコア (_)、ハイフン (-) です。
• トレーニングテキストデータファイルは data.jsonl に固定され、zip パッケージのルートディレクトリに配置する必要があります。展開後、zip ファイルを直接開くと data.jsonl が表示されるようにし、余分な外側のフォルダでラップされていないことを確認してください。

画像または動画のファイル名は、異なるフォルダに分散している場合でも、zip パッケージ内でグローバルに一意でなければなりません。data.jsonl 内では、ファイルパスではなくファイル名のみを宣言する必要があります。正しい例：image1.jpg、誤った例：jpg_folder/image1.jpg。

クラウドストレージマウントは zip パッケージをサポートしていません。クラウドストレージマウントを介してデータセットをロードする場合、非圧縮のデータセットフォルダ全体を OSS バケットにアップロードし、MountStorage の file_path を介して data.jsonl ファイルパスを指定する必要があります。複数のファイルが含まれる場合、data.jsonl のパスを指定するだけで、同じディレクトリ内の他のファイルは自動的にマウントされます。クラウドストレージマウントの詳細については、「API または CLI を使用したファインチューニング」をご参照ください。

命名例とディレクトリ構造を以下のコードブロックに示します。クラウドストレージマウントの権限付与操作については、「コンソールでのモデルのファインチューニング」をご参照ください。OSS バケットインポートのタグ付け操作については、「トレーニングセットと評価セット」をご参照ください。

# 単層ディレクトリ (推奨)
Trainingdata_vl.zip
  |--- data.jsonl        # ルートディレクトリに配置する必要があり、外側のフォルダでラップしない
  |--- image1.png
  |--- video1.mp4

# data.jsonl 内でファイル名を宣言 (パスではない)
# 正しい: image1.jpg
# 誤り: jpg_folder/image1.jpg

コンソールの [データセットの作成] ページに移動して、マルチモーダル zip パッケージをアップロードし、パッケージングの検証を完了します。

ファイルサイズと数量の制限

ローカルアップロードのファイルサイズと数量の上限は、トレーニング手法とシナリオによって設定されており、詳細は以下のシナリオ別テーブルに記載されています。画像の受け入れ制限については、「視覚理解 - SFT フォーマット」をご参照ください。評価セットのフォーマット制限については、「評価セットのフォーマット」をご参照ください。ログリプレイの取り込み制限については、「評価セットのフォーマット」をご参照ください。

max_length は、500 から 131072 の範囲の値を取るトレーニングシーケンス長の構成パラメーターであり、アップロードの受け入れ上限ではありません。単一のトレーニングデータレコードの受け入れサイズの上限は、ソースドキュメントに数値で示されていません。コンソールページに表示される値を参照してください。

ローカルアップロードのファイルサイズと数量の上限は、トレーニング手法とシナリオによって設定されています。推奨データ量は、最小限の推奨値です：

API アップロードクォータ

DashScope API を介してファインチューニングファイルをアップロードする (purpose がモデルファインチューニングとしてタグ付けされている) 場合のクォータを以下のクォータ表に示します。コンソールでデータセットを作成する際、ファイル API リストは最大 10 ファイルのマージと登録をサポートします。API を介してアップロードされたファインチューニングファイルは、コンソールのモデルファインチューニングページと API 呼び出しの両方で表示および使用可能です。

クラウドストレージマウントを介してデータセットをロードする際の制約：

• MountStorage の file_path を介して data.jsonl のルートディレクトリマニフェストパスを指定します。zip アーカイブはサポートされていません。
• ストレージ場所としてクラウドストレージマウントを選択すると、即時公開が強制されます。ドラフト状態はサポートされていません。
• マウントする前に、Bailian サービスに OSS データへのアクセスを権限付与する必要があります。

オーバーフロー処理と暗号化：

• 単一ファイルが 300 MB を超える場合：クラウドストレージマウントまたはマルチモーダル ZIP 2 GB チャンネルを介してアップロードします。
• 合計クォータを超えた場合：履歴ファイルを削除してスペースを解放します。
• インポートされたデータは、自動的に OSS サーバーサイド暗号化 (SSE-OSS, AES256) を有効にします。

API 呼び出し、認証、SDK、エラーコード、および MountStorage フィールドの詳細については、「API または CLI を使用したファインチューニング」をご参照ください。

API を介してファインチューニングファイルをアップロードする場合のクォータは以下の通りです：

OSS インポートとクラウドストレージマウントの違いは以下の通りです：

アップロードの検証とよくあるエラー

データセットの追加 ページでファイルをローカルにアップロードする際、フロントエンドの検証は受け入れルールを満たさないファイルを拒否し、プロンプトを表示します。一般的な検証拒否とアップロードエラーのシナリオを以下の折りたたみ項目に示します：

元に戻せない操作のリスク通知：

• 公開と削除の操作はどちらも元に戻せません。公開されたバージョンは再編集できず、ドラフトバージョンのみが削除またはオンライン編集可能です。
• データセットのタイプ (トレーニングセット/評価セット) は作成後に変更または交換できません。間違って選択した場合は、新しいデータセットを作成し、すべてのデータを再インポートする必要があります。
• データセットのタイプ、トレーニングシナリオ、またはトレーニング手法を切り替えると、アップロードされたファイルがクリアされ、ストレージ場所とインポート方法がリセットされます。

検証データセットの自動分割は、トレーニングセットからランダムに 10% のデータを抽出し、検証データセットとして使用するため、実際のトレーニングデータ量が減少します。小規模なデータセットの場合は、独立した検証データセットを推奨します。検証データセットの設定操作については、「コンソールでのモデルのファインチューニング」をご参照ください。

まず、対応するシナリオのデータテンプレートをダウンロードすることを推奨します。テンプレートの構造に従ってデータを準備することで、インポートの失敗を避けることができます。データテンプレートのダウンロードに関する推奨事項については、「概要」をご参照ください。一般的な問題のトラブルシューティングについては、以下の折りたたみ項目で詳しく説明しています。ドラフトデータのクレンジングと拡張操作については、「」をご参照ください。セキュリティとコンプライアンスのデータドメインについては、「」をご参照ください。

アップロードの検証に失敗した場合は、コンソールの [新規データセット] ページに移動して、ファイルフォーマットと受け入れルールを確認してください。