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 つのデータセットには、異なるフォーマットの行を混在させることができます。各レコードは独立してフォーマットを選択でき、単一のフォーマットに統一する必要はありません。
• 利用可能なフォーマット：標準対話、ディープシンキング、関数呼び出し、および関数呼び出しと思考の組み合わせ (以下のサンプルタブをご参照ください)。

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

{
  "messages": [
    {"role": "system", "content": "系统输入1"},
    {"role": "user", "content": "用户输入1"},
    {"role": "assistant", "content": "期望的模型输出1"},
    {"role": "user", "content": "用户输入2"},
    {"role": "assistant", "content": "期望的模型输出2"}
  ]
}

{"role": "assistant", "content": "期望的模型输出", "loss_weight": "1.0"}

{
  "messages": [
    {"role": "system", "content": "系统输入1"},
    {"role": "user", "content": "用户输入1"},
    {"role": "assistant", "content": "模型输出1"},
    {"role": "user", "content": "用户输入2"},
    {"role": "assistant", "content": "<think>\n期望的思考内容2\n</think>\n\n期望的输出2"}
  ]
}

思考タグのルール

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

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

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

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

評価セットの仕様：

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

ローカルアップロードのファイル形式は xlsx です (列構造については、コンソールからダウンロードしたテンプレートをご参照ください)。各評価レコードは Prompt/Completion のコンテンツのペアであり、以下に示します：

{"prompt": "谁在文艺复兴时期绘制人体?", "completion": "文艺复兴时期是一个关于艺术、文化和学术的复兴运动,在这个时期,许多艺术家都绘制了人体。"}
{"prompt": "为什么太阳会发光发热?", "completion": "太阳是由氢原子核在高温高压下聚变而产生的巨大能量。这种聚变反应释放出大量的光和热能。"}
{"prompt": "为什么天空是蓝色的?", "completion": "阳光照射到地球大气层中时,波长较短的蓝光会被大气中的气体分子散射开来,形成我们看到的蓝天。"}

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

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

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

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

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

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

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

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

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

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

{
  "messages": [
    {"role": "system", "content": "系统输入"},
    {"role": "user", "content": "用户输入1"},
    {"role": "assistant", "content": "模型输出1"},
    {"role": "user", "content": "用户输入2"},
    {"role": "assistant", "content": "模型输出2"},
    {"role": "user", "content": "用户输入3"}
  ],
  "chosen": {"role": "assistant", "content": "赞同的模型期望输出3"},
  "rejected": {"role": "assistant", "content": "反对的模型期望输出3"}
}

{
  "messages": [
    {"role": "system", "content": "系统输入"},
    {"role": "user", "content": "用户输入1"},
    {"role": "assistant", "content": "模型输出1"},
    {"role": "user", "content": "用户输入2"}
  ],
  "chosen": {"role": "assistant", "content": "<think>\n期望的思考内容\n</think>\n\n期望的模型输出"},
  "rejected": {"role": "assistant", "content": "反对的模型期望输出2"}
}

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

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

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

• 最低 5,000 万トークンが推奨され、単一ファイルのサイズ制限は 300 MB です。

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

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

{
  "text": "文本内容"
}

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

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

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

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入1"}]},
    {"role": "user", "content": [{"text": "用户输入1"}]},
    {"role": "assistant", "content": [{"text": "期望的模型输出1"}]},
    {"role": "user", "content": [{"text": "用户输入2"}]},
    {"role": "assistant", "content": [{"text": "期望的模型输出2"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入1"}]},
    {"role": "user", "content": [{"text": "用户输入1"}]},
    {"role": "assistant", "content": [{"text": "模型输出1"}]},
    {"role": "user", "content": [{"text": "用户输入2"}]},
    {"role": "assistant", "content": [{"text": "<think>\n期望的思考内容2\n</think>\n\n期望的输出2"}]}
  ]
}

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "查询指定城市的实时天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": {"type": "string", "description": "城市名称，例如：北京"}
          },
          "required": ["city"]
        }
      }
    }
  ],
  "messages": [
    {"role": "user", "content": [{"text": "帮我查一下北京的天气"}]},
    {
      "role": "assistant",
      "content": [{"text": "好的，我来帮您查询北京的天气。"}],
      "tool_calls": [
        {
          "id": "call_3a11c1ba883b41b6a4e0cb",
          "type": "function",
          "function": {
            "name": "get_weather",
            "arguments": "{\"city\": \"北京\"}"
          }
        }
      ]
    },
    {"role": "tool", "tool_call_id": "call_3a11c1ba883b41b6a4e0cb", "content": [{"text": "{\"city\": \"北京\", \"weather\": \"晴\", \"temperature\": \"25℃\"}"}]},
    {"role": "assistant", "content": [{"text": "北京今天天气晴朗，气温 25℃，适合出行。"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入"}]},
    {
      "role": "user",
      "content": [
        {"text": "用户输入1"},
        {"image": "图像文件名1.jpg", "resized_width": 200, "resized_height": 200}
      ]
    },
    {"role": "assistant", "content": [{"text": "期望的模型输出1"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入"}]},
    {
      "role": "user",
      "content": [
        {"text": "用户输入1"},
        {"video": "视频文件名1.mp4", "fps": 3.0, "resized_width": 200, "resized_height": 200, "video_start": 0.0, "video_end": 3.0}
      ]
    },
    {"role": "assistant", "content": [{"text": "期望的模型输出1"}]}
  ]
}

{
  "messages": [
    {"role": "system", "content": [{"text": "系统输入"}]},
    {
      "role": "user",
      "content": [
        {"text": "用户输入2"},
        {"video": ["0.jpg", "1.jpg", "2.jpg", "3.jpg"], "sample_fps": 5.0, "resized_width": 200, "resized_height": 200}
      ]
    },
    {"role": "assistant", "content": [{"text": "期望的模型输出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 の最終的な返信です。

Bailian は OpenAI の name および weight パラメーターをサポートしていません。すべての assistant の出力がトレーニングされます。OpenAI/Azure から移行されたトレーニングデータには、name/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% のデータを抽出して検証データセットとして使用するため、実際のトレーニングデータ量が減少します。小規模なデータセットの場合は、独立した検証データセットを推奨します。検証データセットの設定操作については、「コンソールでのモデルのファインチューニング」をご参照ください。

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

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