AWS、教師あり微調整のデータ準備：フォーマットと品質管理の重要性を解説

データ準備は、あらゆる教師あり微調整（SFT）プロジェクトの性能上限を決定します。基盤モデル（FM）の評価が完了し、初期状態でのパフォーマンスが生産環境の要件を満たしていない場合、そこには課題があります。例えば、モデルが出力スキーマに従うのが不安定だったり、ドメイン固有の分類体系に対応できなかったり、アプリケーションに必要なトーンを維持できなかったりするケースです。

重要なのは「カスタマイズすべきか」ではなく、「どのようにカスタマイズするか」です。本稿では、基盤モデルを微調整する方針が既に決まっていることを前提に、その作業のためにデータをどのように準備すべきかを検討します。

ポストトレーニングのカスタマイズには、3 つの異なるレバー（調整要素）があります。それぞれは、現在のモデルの能力と必要な機能との間の異なるギャップを埋めるために設計されています。

継続的事前学習 (CPT) は、大規模な非構造化ドメインテキストを取り込んでモデルの知識基盤を広げる手法です。モデルが特定のドメインの用語や概念、データパターンに不慣れな場合に CPT を使用します。

教師あり微調整 (SFT) は、厳選された入力と出力のペアを用いてモデルの振る舞いを再構築するトレーニング手法です。SFT は、指示に従うこと、スキーマを遵守すること、特定のトーンを採用すること、構造化された出力を生成することをモデルに教えます。これは新しい知識を注入するものではなく、既存の知識を必要な形で適用する方法を教えるものです。この考え方は、「表面的アライメント仮説 (Superficial Alignment Hypothesis)」と呼ばれることもあります。

強化学習微調整 (RFT) は、明示的なデモンストレーションではなく報酬信号を通じて振る舞いを最適化する手法です。出力の品質をプログラムで評価できるが、大規模な推論経路を容易にデモンストレーションできない場合に RFT が有効です。

これらの技術は排他的なものではありません。実際の生産環境では、「CPT → SFT → RFT」という順序が一般的です。まず知識を広げ、次に振る舞いを形作り、最後にフィードバックを通じて最適化します。実務上、CPT はあまり頻繁には使用されず、ベースモデルにタスクに必要な重要なドメイン語彙や知識が欠けている場合にのみ必要となります。Amazon Nova などのファウンデーションモデルはすでに広範なコーパスで事前学習されているため、通常は SFT に続いて RFT を行うだけで十分です。

本シリーズ第1回となるこの記事では、SFT（教師あり微調整）データの準備における基礎として、品質チェック、フォーマット要件、および学習用・評価用のデータ分割について解説します。主要な概念を説明する際には、Amazon Bedrock のドキュメントからコードスニペットを使用しますが、ここで示すガイドラインは選択したモデルに広く適用可能です。

第 2 回では、準備完了の評価、データサブセットの選定とフィルタリング、データ拡張、そしてデータの混合といった高度な戦略について取り上げます。

データ品質チェック

フォーマットを整えたりトレーニングインフラを構築したりする前に、まず生データ（Raw Data）の監査を行いましょう。問題を早期に発見することは、その後の工程における時間と計算コストを大幅に削減します。

正確性と正しさ

データセットに含まれるすべての回答は、本番環境へデプロイしても問題ないレベルの「ゴールドスタンダード」な答えであるべきです。誤った例示は、モデルに修正が難しい悪い癖を学習させてしまうリスクがあります。このリスクは SFT において特に深刻です。SFT ではモデルが新しい事実を学ぶというよりは、真似すべきパターンを学習するからです。間違ったデモはそのまま模倣されてしまいます。

実務的な結論として、データの質は量よりも圧倒的に重要です。LIMA は、1,000 件を手作業で厳選した例だけで、桁違いに多いデータで訓練されたモデルと同等の性能を発揮できることを示しました。また AlpaGasus では、指示セットから最もクリーンな 20% に絞り込むことで、フルセットよりも高速に学習し、より高いスコアを達成できることが実証されています。もし人手による注釈付きデータを利用しているなら、トレーニングセットに組み込む前に多段階のレビュープロセスを導入すべきです。

例の多様性

データセットの多様性は、教師あり微調整（SFT）の成功を予測する最も強力な指標の一つです。supervised fine-tuning scalability に関する研究では、微調整がどの程度汎化するかを支配する 2 つの性質が特定されています。1 つ目はセマンティック・カバレッジ（意味的網羅性）で、これはタスクドメインやプロンプトの表現形式の広さを指します。2 つ目はインフォメーション・デプス（情報の深さ）で、個々の例の豊かさを意味します。生産環境のトラフィックのごく一部しかカバーしていないデータセットでは、その一部の領域では高い性能を発揮するものの、それ以外の場所では著しく劣化するモデルができてしまいます。

まず、プロンプトの多様性についてデータセットを検証しましょう。同じ意図を表現するユーザーの異なる言い回しを例に含める必要があります。「この文書を要約してください」という指示だけで学習したモデルは、「重要なポイントを教えてください」といった別の表現には対応できない恐れがあるからです。

次に、ドメインやトピックの幅広さを確認します。タスクが複数の領域にまたがる場合は、各領域が生産環境で発生する頻度に応じて適切にサンプルが含まれているか検証してください。さらに、難易度の範囲も考慮しましょう。単純なケースと複雑な多段階の問題を両方含め、実際のトラフィックの複雑さプロファイルに合わせて重み付けを行います。

最後に、曖昧な入力や不完全な情報、対象外のリクエストといったエッジケースを明示的に含める必要があります。これらの状況でモデルがどのように応答すべきか、望ましい回答例も併せて用意しましょう。

実用的なアプローチとして、埋め込み類似度に基づいて例をクラスタリングし、生成されたクラスタに欠落がないか点検する方法があります。クラスタが希薄または存在しない領域は、モデルが学習信号を得られない箇所を示しています。例えば、カスタマーサポートのデータセットでは、「パスワードリセット」「請求に関する質問」「配送状況の確認」などに分類されるでしょう。もし実運用で返金リクエストが多く発生しているにもかかわらず、それをカバーするクラスタが存在しない場合、その空白領域こそが欠落部分です。モデルは返金関連の会話に対して十分な学習信号を持たないため、トレーニング前に返金事例を収集または作成する必要があります。本シリーズの次回記事では、データサブセット選択手法を用いてこのアイデアを自動化する方法について解説します。

類似タスク内での一貫性

データセット全体に多様性を持たせることは重要ですが、同じ種類のタスクを扱う事例については、内部で整合性が保たれている必要があります。同じタスクタイプ内で一貫性がないと、正しい行動について矛盾する信号がモデルに伝わってしまいます。

例えば、類似したプロンプトに対して箇条書き形式の回答と段落形式の回答の両方が出力される場合、モデルは応答構造に対する信頼できるデフォルトを学習できません。簡潔な 2 文以内の回答が必要な場合は、トレーニングデータに段落長の回答を含めないようにしてください。

重複データの除去

重複、あるいは類似したデータ例は、モデルがそのパターンに過学習しやすくなり、結果として他のデータに対する相対的な重要性を不当に高めてしまいます。SFT（教師あり微調整）においては、事前学習ほど深刻な問題とはなりませんが、複数のアノテーターからデータを統合したり、プロジェクト間でデータセットを組み合わせたり、合成データ生成を利用したりする際に、意図せず重複が混入することがあります。そのようなケースでは、トレーニング前に完全一致に基づく除去と意味的な重複除去の両方を適用してください。

有害性と安全性のスクリーニング

データセットには、有害、偏見、あるいは不適切なコンテンツが含まれていないか確認する必要があります。利用ケースが限定的であっても、モデルは問題のある例からパターンを学習し、予期せぬ文脈でそれを表面化させる可能性があります。自動分類器（例えばオープンソースの Llama Guard など）を活用して、人間によるレビューが必要なコンテンツを特定し、ドメイン内で許容されるトレーニングデータの基準を明確に定めておきましょう。

データフォーマット

品質チェックが完了したら、トレーニング用にデータを構造化します。フォーマットの整備は単なる文法の問題ではありません。例の構成方法が、モデルが学習する行動そのものを形作ります。SFT は、モデルに対して単なるコンテンツではなく、特定の形状の入力に対する応答方法を教えるものだからです。

サンプル内のシステムプロンプト

推論時にシステムプロンプトを使用する予定がある場合は、トレーニング例にも必ず含めてください。システムプロンプトは、モデルの動作を形作る文脈、ペルソナ、制約を設定する役割を果たします。もし学習データにシステムプロンプトが含まれていないのに、推論時には使用する場合、分布の不整合が生じてモデルの性能が低下する恐れがあります。

対話形式（JSONL）

Amazon Nova のレシピを含む最新の SFT パイプラインの多くは、1 行ごとに会話全体を表す自己完結型の JSON オブジェクトを格納した JSONL 形式を採用しています。Amazon Nova 2.0 モデルでは Converse API のフォーマットを使用します。

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{"text": "You are a helpful coding assistant."}],
  "messages": [
    {
      "role": "user",
      "content": [{"text": "Write a Python function to check if a string is a palindrome."}]
    },
    {
      "role": "assistant",
      "content": [
        {"text": "def is_palindrome(s):\n    cleaned = s.lower().replace(' ', '')\n    return cleaned == cleaned[::-1]"}
      ]
    }
  ]
}

守るべき主要なフォーマットルールは以下の通りです。

• 1 行に 1 つの JSON オブジェクトとし、複数行にまたがるプレティプリント（整形出力）は避けてください。
• アップロード前に、すべての行が有効な JSON パース可能であることを検証してください。
• ユーザーとアシスタントのターン間で、役割を厳密に交互に保ってください。
• 本番環境でシステムメッセージを使用している場合は、必ず含めてください。

推論トレース

推論能力を持つモデル（例：reasoning_enabled: true を設定した Amazon Nova 2.0）では、アシスタントのターン内に reasonContent フィールドを使用して中間的な思考ステップを含める必要があります。推論トレースで学習させることは、プロンプトテクニックとして流行している「チェイン・オブ・ソート（Chain-of-Thought）」の振る舞いを、モデル自体に転移させるための鍵となります。

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{"text": "You are a financial analyst. Provide data-driven answers with supporting calculations."}],
  "messages": [
    {
      "role": "user",
      "content": [{"text": "Calculate YoY revenue growth. 2024: $4.2M, 2025: $5.1M"}]
    },
    {
      "role": "assistant",
      "content": [
        {
          "reasoningContent": {
            "reasoningText": {
              "text": "The user asks for year-over-year revenue growth. I need to calculate the percentage change: (new - old) / old x 100. That gives (5.1 - 4.2) / 4.2 x 100 = 21.43%."
            }
          }
        },
        {"text": "YoY revenue growth is approximately 21.4 percent: ($5.1M - $4.2M) / $4.2M x 100."}
      ]
    }
  ]
}

（原文の技術表記: reasoningContent）

推論トレースを活用する上で最も難しいのは、そのフォーマットではありません。重要なのは、モデルに実際に教訓を与えるようなトレースを入手することです。

有用なトレースは、回答に対して忠実である必要があります。つまり、推論プロセスが最終的な回答へと確実に導くものでなければなりません。また、難易度に応じて長さが比例していることも重要です。簡単な問題には短いトレースを、複雑な問題には長いトレースを与えるというトレードオフは、difficulty-aware trace compression によって明確に定義されています。

さらに、推論の飛躍（思考のスキップ）があってはなりません。熟練者が作成した解説には、モデルがまだ学習していない中間ステップが省略されているケースが多いためです。そして、量よりも質が重要です。s1 と LIMO の研究では、能力の高いベースモデルであっても、1,000 件未満の注意深く選別された推論デモンストレーションを学習させるだけで、強力な推論能力を引き出せることが示されています。このシリーズの次の記事では、これらのトレースをディスタillation（知識蒸留）や自己生成を通じて大規模に収集する方法について解説します。

推論コンテンツにはプレーンテキストを使用し、問題解決プロセスと直接関連する内容に絞り込んでください。トレーニング時に推論機能を有効にする場合は、推論機能も同様に有効化して、一貫した動作を保つようにしてください。また注意が必要なのは、推論機能を無効化したデータセットで reasoning_enabled: true を設定して学習すると、モデルが推論プロセスを経ずに回答を生成するよう学習してしまうため、結果として推論能力を失ってしまう可能性があることです。

ツール呼び出しとマルチモーダル形式

SFT（教師あり微調整）は、ツール使用（関数呼び出し）や多モーダル理解（ドキュメント、画像、動画）に対応したモデルのトレーニングを支援します。ツール呼び出しにおいては、アシスタント側のターンに toolUse ブロックが、ユーザー側のターンに toolResult ブロックが表示され、それぞれ一意の toolUseId を参照します。

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{"text": "You are an expert in composing function calls."}],
  "toolConfig": {
    "tools": [
      {
        "toolSpec": {
          "name": "getItemCost",
          "description": "Retrieve the cost of an item from the catalog",
          "inputSchema": {
            "json": {
              "type": "object",
              "properties": {
                "item_id": {
                  "type": "string",
                  "description": "The ASIN of item to retrieve cost for"
                }
              },
              "required": ["item_id"]
            }
          }
        }
      }
    ]
  },
  "messages": [
    {
      "role": "user",
      "content": [{"text": "How much does item id-456 cost?"}]
    },
    {
      "role": "assistant",
      "content": [
        {
          "toolUse": {
            "toolUseId": "getItemCost_0",
            "name": "getItemCost",
            "input": {"item_id": "id-456"}
          }
        }
      ]
    },
    {
      "role": "user",
      "content": [
        {
          "toolResult": {
            "toolUseId": "getItemCost_0",
            "content": [
              {"text": "{"name": "getItemCost", "results": {"cost": "$29.99"}}"}
            ]
          }
        }
      ]
    },
    {
      "role": "assistant",
      "content": [
        {"text": "Item id-456 costs $29.99."}
      ]
    }
  ]
}

ツール呼び出しデータの重要な制約事項は以下の通りです。

• toolUse はアシスタントの応答にのみ、toolResult はユーザーの応答にのみ出現させる必要があります。

• 各 toolResult は、直前のアシスタントの応答から参照される有効な toolUseId を指す必要があります。これは会話内で一度だけ使用されます。

• toolResult のコンテンツは、テキストまたは JSON のいずれかである必要があります。

• toolSpec 内の inputSchema は、有効な JSON スキーマオブジェクトでなければなりません。

マルチモーダル学習では、ドキュメントや画像のコンテンツブロックがテキストと共にユーザー側のターンに現れ、ソースはAmazon Simple Storage Service（Amazon S3）の場所を参照します。

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{"text": "You are a document analysis assistant."}],
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "document": {
            "format": "pdf",
            "name": "quarterly_report",
            "source": {"s3Location": {"uri": "s3:///report.pdf"}}
          }
        },
        {"text": "Summarize the key findings from this quarterly report."}
      ]
    },
    {
      "role": "assistant",
      "content": [
        {"text": "The quarterly report highlights three key findings..."}
      ]
    }
  ]
}

元のモデルのチャットテンプレートに忠実に

すべての基盤モデルは、特定のチャットテンプレートを用いてポストトレーニングされます。これはシステムプロンプト、ユーザー側のターン、アシスタント側のターンの境界を示す正確なトークンシーケンスのことです。学習データはこのテンプレートと完全に一致させる必要があります。たとえ微妙な違いであってもテンプレートから逸脱すると、モデルは新しい振る舞いに加えて入力形式も新たに学習する必要が生じ、学習リソースが2つの目的に分散されてしまいます。最悪の場合、テンプレートの不一致により、推論時にシステムプロンプトを無視したり、 malformed な出力を生成したりする原因となります。

テンプレート整合のための実践的ガイドライン：

モデルプロバイダが公式に提供するフォーマットユーティリティを使用してください。Amazon Nova の場合は Converse API スキーマを、オープンソースモデルの場合は Hugging Face Transformers 内のトークナイザーの apply_chat_template() メソッドを利用します。

手動で区切り文字を作成してはいけません。ShareGPT や Alpaca など他の形式からデータを転換する際も、役割を示す文字列を手動で挿入するのではなく、対象モデルのチャットテンプレート関数に通してください。

トークン化のラウンドトリップを検証します。フォーマット完了後、データのサンプルをトークン化し、再度テキストにデコードして確認します。役割の境界、特殊トークン、そしてコンテンツが正確に保持されていることを確認しましょう。

トレーニング時は推論時の構造と一致させます。本番環境のパイプラインでシステムプロンプトやツール定義、検索コンテキストを特定の位置に注入する場合、トレーニングデータにも同じ要素を同様の位置に含める必要があります。

学習用/評価用データの分割

データの 10〜20% を評価セットとして確保してください。これは必須事項です。これを行わないと、真の学習成果が過学習によるものかを見分けることができません。評価セットは本番環境のデータ分布を代表するものでなければならず、稀だが重要なカテゴリが不足してしまうようなランダムな断片であってはなりません。

小規模なデータセット（1,000 サンプル未満）の場合は、各タスクカテゴリがトレーニングセットと評価セットの両方に含まれるように層化分割（stratified splitting）を行いましょう。大規模なデータセットではランダム分割で十分ですが、事後に分布を確認することが重要です。トレーニング開始前には、未修正モデルを用いて評価セットでのベースライン性能を測定してください。これにより、達成すべき具体的な目標が明確になり、教師あり微調整（SFT）の効果を定量化できるようになります。

結論

データ準備は、あらゆる SFT ワークフローの中で最も影響力のある活動です。ここで紹介したパターン——体系的な品質チェック、スキーマ準拠のフォーマット、代表的なトレーニング/評価セットへの分割——は、狭い分類タスク向けに微調整する場合でも、複雑な多ターン対話システムを対象とする場合でも通用します。事前投資として時間をかけることで、その後のトレーニングジョブはより速く収束します。