监督微调数据准备第 1 部分：格式与质量

数据准备决定了任何监督微调（SFT）项目的效果上限。你已经评估了基础模型（FM），而开箱即用的表现无法满足生产要求。也许模型不能稳定遵循你的输出 Schema，难以处理所在领域的分类体系，或无法维持应用所要求的语气。问题不在于是否要进行定制，而在于如何定制。本文假设你已经决定微调一个基础模型，并正在评估如何为这项工作准备数据。

后训练定制提供了三种不同的杠杆，每种方式都针对模型当前能力与你所需能力之间的不同差距。持续预训练（CPT） 会吸收大量非结构化领域文本，以扩展模型的知识库。当模型不熟悉你所在领域的术语、概念或数据模式时，应使用 CPT。监督微调（SFT） 在经过筛选的输入—输出对上训练，以重塑模型行为。SFT 教会模型如何响应：遵循指令、遵守 Schema、采用特定语气或生成结构化输出。它不会注入新知识，而是教会模型以你所需的方式运用其已有知识；这一观点有时被称为表层对齐假说。强化微调（RFT） 通过奖励信号而非显式示范来优化行为。当你能够以编程方式评估输出质量、却难以大规模展示推理路径时，RFT 就很适用。

这些技术并不互斥。一种生产实践模式是 CPT、SFT、RFT 依次进行：先扩展知识，再塑造行为，最后通过反馈进行优化。实践中，CPT 的使用频率较低，且仅在基础模型缺少任务所需的关键领域词汇或知识时才有必要。Amazon Nova 等基础模型已经在广泛的语料库上完成预训练，因此通常先进行 SFT、再进行 RFT 就已足够。

本文是两篇系列文章的第一篇，介绍 SFT 数据准备的基础：质量检查、格式要求以及训练集/评估集划分。我们使用 Amazon Bedrock 文档中的代码片段来说明关键概念，同时确保这些建议适用于你选择的任何模型。第二篇文章将介绍高级策略：就绪度评估、数据子集选择与过滤、数据增强以及数据混合。

数据质量检查

在投入格式化工作或训练基础设施之前，先审查原始数据。及早发现问题能够在后续流程中节省大量时间和计算成本。

准确性与正确性

数据集中的每一条回复都应是你愿意部署到生产环境的黄金标准答案。错误示例可能让模型学会一种难以纠正的持久性坏习惯。这种风险在 SFT 中尤其突出：模型与其说是在学习新事实，不如说是在学习应模仿哪些模式。错误的示范会被模仿。

实际结论是：质量远比数量重要。LIMA 表明，1,000 个精心筛选的示例可以媲美使用数量级更多数据训练的模型。AlpaGasus 表明，将指令集过滤至其中最干净的 20%，相比完整数据集能够训练得更快、得分更高。如果你使用人工标注数据，请在示例进入训练集前实施多轮审核流程。

示例多样性

数据集多样性是预测 SFT 成功与否的最强因素之一。关于监督微调可扩展性的研究指出，有两项属性决定了微调的泛化能力。第一项是语义覆盖度，即所涵盖任务领域和提示词表述方式的广度。第二项是信息深度，即单个示例的丰富程度。如果数据集只覆盖生产流量中的一个狭窄切片，训练出的模型将只在该切片上表现良好，而在其他场景中表现不佳。

首先审查数据集中的提示词变化。示例应涵盖用户表达相同意图的不同方式，因为一个只在“总结这份文档”上训练的模型，无法稳定处理“告诉我关键要点”这样的请求。接着检查领域与主题的广度。如果任务跨越多个领域，应确认每个领域的样本占比与其生产流量频率相称。然后考察难度范围：既要包含直接简单的案例，也要包含复杂的多步骤问题，并按真实流量的复杂度分布进行加权。最后，明确纳入模糊输入、信息不完整和超出范围的请求等边界案例，并配对提供你希望模型在这些情况下生成的回复。

一种实用方法是按嵌入相似度对示例进行聚类，并检查所得聚类是否存在覆盖缺口。稀疏或缺失的聚类意味着模型将缺少相应的训练信号。例如，客户支持数据集可能聚类为密码重置、账单问题和物流更新。如果退款是生产中常见的请求，但没有任何聚类覆盖它，这个空白区域就是你的缺口。模型几乎没有关于退款对话的信号，因此应在训练前收集或编写退款示例。本系列第二篇文章将展示如何使用数据子集选择方法自动化这一思路。

相似任务内的一致性

虽然整个数据集的多样性至关重要，但处理相同类型情境的示例应在内部保持一致。同一任务类型中的不一致会就何为正确行为发送相互矛盾的信号。例如，如果相似提示词有时生成项目符号答案、有时生成段落式答案，模型将无法学到可靠的默认回复结构。如果你需要简洁的两句话回答，就不要在训练数据中包含段落长度的回复。

目标行为	两个不一致的示例（避免）	两个一致的示例（使用）
从固定集合中返回一个小写标签	Positive This one reads as fairly negative.	positive negative
用两句话总结，不要前言

• Login fails after reset
• iOS 17
• Escalated to Tier 2

Sure! Here’s a quick summary: the customer reports that… | Customer cannot log in after resetting their password on iOS 17. The ticket is escalated to Tier 2. Customer’s card was declined three times at checkout. Billing confirmed the issuer blocked the transaction.
用一个固定句子拒绝超出范围的请求 | I can’t help with that. I’m really sorry, but that falls outside what I’m able to assist with today. However, I’d be happy to… | That request is outside the scope of this assistant. That request is outside the scope of this assistant.

去重

重复或近似重复的示例会导致模型对这些模式过拟合，使其重要性相对于数据集其他部分被不当放大。重复在 SFT 中不如在预训练中那么关键，但当你合并多个标注者的数据、组合来自不同项目的数据集，或使用合成数据生成时，仍可能出现重复。在这些情况下，训练前应同时应用精确匹配去重和语义去重。

毒性与安全筛查

扫描数据集中的有害、带偏见或不适当内容。即使你的用例范围较窄，模型也可能从有问题的示例中内化模式，并在意料之外的场景中呈现出来。使用自动分类器，例如开放的 Llama Guard，标记需要人工审核的内容；同时，为你的领域明确制定何为可接受训练数据的准则。

数据格式

完成质量检查后，就可以为训练组织数据结构。格式化并不仅仅关乎语法。你组织示例的方式会塑造模型学到的行为，因为 SFT 教模型响应特定形态的输入，而不只是响应其中的内容。

示例中的系统提示词

如果你计划在推理期间使用 system prompt，应将其纳入训练示例中。System prompt 用于建立影响模型行为的上下文、角色设定和约束。如果训练数据缺少 system prompt、而推理时包含它，就会产生分布失配，从而可能降低模型行为质量。

对话格式（JSONL）

包括 Amazon Nova 配方在内的大多数现代 SFT 流程，都采用对话式 JSONL 格式，其中每一行都是代表一段对话的独立 JSON 对象。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]"}
      ]
    }
  ]
}

应遵循的关键格式规则：

• 每行一个 JSON 对象，不要跨多行进行美化排版。
• 上传前验证每一行都能解析为有效 JSON。
• 严格保持 user 与 assistant 回合角色交替。
• 如果生产环境使用 system message，训练数据中也应包含它们。

推理轨迹

对于具备推理能力的模型（例如启用 reasoning_enabled: true 的 Amazon Nova 2.0），应在 assistant 回合中使用 reasoningContent 字段包含中间思考步骤。在推理轨迹上训练，能将作为提示技巧而流行的思维链行为转化为模型自身的能力。

{
  "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."}
      ]
    }
  ]
}

使用推理轨迹最困难的部分并非格式，而是获得真正能教会模型东西的轨迹。有效的轨迹应忠实于答案，即推理过程确实能够导向最终回复。轨迹的长度应与难度相称：简单问题使用短轨迹，复杂问题使用长轨迹；难度感知的轨迹压缩明确阐释了这种权衡。轨迹必须完整，不能存在思维跳跃，因为专家撰写的推理说明往往会跳过模型尚未学会的中间步骤。而且，质量比数量更重要：s1 和 LIMO 都表明，不到 1,000 个精心筛选的推理示范，就能在能力较强的基础模型中激发出强大的推理能力。本系列第二篇文章将介绍如何通过蒸馏和自生成，大规模获取这些轨迹。

推理内容应使用纯文本，并且与问题求解过程直接相关。当训练时启用推理功能，推理时也应启用它，以保持行为一致。请注意，使用 reasoning_enabled: true 训练一个不含推理的数据集，可能导致模型失去推理能力，因为模型会学会在不运用推理的情况下生成回复。

SFT 支持训练模型使用工具（函数调用）以及进行多模态理解（文档、图像、视频）。对于工具调用，toolUse 块出现在 assistant 回合中，toolResult 块出现在 user 回合中，并且二者都引用唯一的 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":

Data preparation determines the ceiling of any supervised fine-tuning (SFT) project. You’ve evaluated your foundation model (FM), and out-of-the-box performance isn’t meeting your production requirements. Maybe the model doesn’t follow your output schema reliably, struggles with your domain’s classification taxonomy, or can’t maintain the tone your application demands. The question isn’t whether to customize, it’s how. This post assumes you have decided to fine-tune a foundation model and are evaluating how to prepare data for that work.

Post-training customization provides three distinct levers. Each addresses a different gap between what the model can do today and what you need it to do. Continued pre-training (CPT) ingests large volumes of unstructured domain text to expand the model’s knowledge base. Use CPT when the model lacks familiarity with your domain’s terminology, concepts, or data patterns. Supervised fine-tuning (SFT) trains on curated input-output pairs to reshape the model’s behavior. SFT teaches the model how to respond: following instructions, adhering to schemas, adopting a specific tone, or producing structured outputs. It doesn’t inject new knowledge. It teaches the model to apply what it already knows in the way that you need, an idea sometimes called the Superficial Alignment Hypothesis. Reinforcement fine-tuning (RFT) optimizes behavior through reward signals rather than explicit demonstrations. RFT works when you can programmatically evaluate output quality but can’t easily demonstrate the reasoning path at scale.

These techniques aren’t mutually exclusive. A production pattern is CPT, then SFT, then RFT: first expand knowledge, then shape behavior, then optimize through feedback. In practice, CPT is used less often and only required when the base model lacks critical domain vocabulary or knowledge your task requires. Foundation models like Amazon Nova are already pre-trained on a broad corpus, so SFT followed by RFT is usually sufficient.

This post, the first of a two-part series, covers the foundations of SFT data preparation: quality checks, formatting requirements, and train/evaluation splits. We use code snippets from Amazon Bedrock documentation to illustrate key concepts while keeping the guidance applicable to any model you choose. The second post covers advanced strategies: readiness evaluation, data subset selection and filtering, data augmentation, and data mixing.

Data quality checks

Before you invest in formatting or training infrastructure, audit your raw data. Catching problems early saves substantial time and compute cost downstream.

Accuracy and correctness

Every response in your dataset should be a gold-standard answer you would be comfortable deploying to production. Incorrect examples can teach the model a persistent bad habit that’s difficult to unlearn. This risk is especially acute in SFT, where the model isn’t learning new facts so much as learning which patterns to imitate. A wrong demonstration gets imitated.

The practical upshot is that quality beats quantity by a wide margin. LIMA showed that 1,000 carefully curated examples can match models trained on orders of magnitude more data. AlpaGasus showed that filtering an instruction set down to its cleanest 20 percent can train faster and score higher than the full set. If you’re working with human-annotated data, implement a multi-review process before examples enter your training set.

Diversity of examples

Dataset diversity is one of the strongest predictors of SFT success. Research on supervised fine-tuning scalability identifies two properties that govern how well fine-tuning generalizes. The first is semantic coverage, the breadth of task domains and prompt phrasings represented. The second is information depth, the richness of individual examples. A dataset that covers only a narrow slice of your production traffic will produce a model that performs well on that slice and poorly everywhere else.

Audit your dataset for prompt variation first. Your examples should include the different ways users phrase the same intent, because a model trained only on “Summarize this document” won’t reliably handle “Give me the key takeaways.” Check domain and topic breadth next. If your task spans multiple domains, verify that each is represented proportionally to its production frequency. Then look at difficulty range: include straightforward cases alongside complex, multi-step problems, weighted toward the complexity profile of real traffic. Finally, explicitly include edge cases such as ambiguous inputs, incomplete information, and out-of-scope requests, paired with the responses you want the model to produce in those situations.

A practical approach is to cluster your examples by embedding similarity and inspect the resulting clusters for gaps. Sparse or missing clusters indicate areas where the model will lack training signal. For example, a customer-support dataset might cluster into password resets, billing questions, and shipping updates. If refunds are a common request in production but no cluster covers them, that empty region is your gap. The model will have little signal for refund conversations, so collect or write refund examples before training. The second post in this series shows how to automate this idea with data subset selection methods.

Consistency within similar tasks

While diversity across your dataset is critical, examples that handle the same type of situation should be internally consistent. Inconsistency within the same task type sends contradictory signals about correct behavior. For example, if similar prompts produce both bullet-point and paragraph-form answers, the model won’t learn a reliable default for response structure. If you need concise, two-sentence answers, don’t include paragraph-length responses in your training data.

Target behavior	Two inconsistent examples (avoid)	Two consistent examples (use)
Return one lowercase label from a fixed set	Positive This one reads as fairly negative.	positive negative
Summarize in two sentences, no preamble

• Login fails after reset
• iOS 17
• Escalated to Tier 2

Sure! Here’s a quick summary: the customer reports that… | Customer cannot log in after resetting their password on iOS 17. The ticket is escalated to Tier 2. Customer’s card was declined three times at checkout. Billing confirmed the issuer blocked the transaction.
Decline out-of-scope requests with one fixed sentence | I can’t help with that. I’m really sorry, but that falls outside what I’m able to assist with today. However, I’d be happy to… | That request is outside the scope of this assistant. That request is outside the scope of this assistant.

Deduplication

Duplicate or near-duplicate examples cause the model to overfit on those patterns, inflating their importance relative to the rest of your dataset. Duplication is less critical in SFT than in pre-training, but it can creep in when you merge data from multiple annotators, combine datasets across projects, or use synthetic data generation. In those cases, apply both exact-match and semantic deduplication before training.

Toxicity and safety screening

Scan your dataset for harmful, biased, or inappropriate content. Even if your use case is narrow, the model can internalize patterns from problematic examples and surface them in unexpected contexts. Use automated classifiers, such as the open Llama Guard, to flag content for human review, and establish clear guidelines for what constitutes acceptable training data in your domain.

Data formatting

With quality checks complete, you can structure your data for training. Formatting isn’t just about syntax. How you structure examples shapes the model’s learned behavior, because SFT teaches the model to respond to a specific shape of input, not just its content.

System prompt in the sample

Include a system prompt in your training examples when you plan to use one during inference. The system prompt establishes context, persona, and constraints that shape model behavior. If training data lacks system prompts but inference includes them, you create a distribution mismatch that can degrade behavior.

Conversational format (JSONL)

Most modern SFT pipelines, including Amazon Nova recipes, use a conversational JSONL format where each line is a self-contained JSON object representing a conversation. The Amazon Nova 2.0 models use the Converse API format:

{
  "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]"}
      ]
    }
  ]
}

Key formatting rules to follow:

• One JSON object per line, with no pretty-printing across multiple lines.
• Validate every line parses as valid JSON before uploading.
• Maintain strict role alternation between user and assistant turns.
• Include system messages when your production setup uses them.

Reasoning traces

For models with reasoning capabilities (such as Amazon Nova 2.0 with reasoning_enabled: true), include intermediate thinking steps using the reasoningContent field in assistant turns. Training on reasoning traces is what transfers the behavior popularized as chain-of-thought from a prompting trick into the model itself.

{
  "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."}
      ]
    }
  ]
}

The hardest part of using reasoning traces isn’t the format. It’s getting traces that actually teach the model something. Useful traces are faithful to the answer, meaning the reasoning actually leads to the final response. They’re proportional to difficulty: short problems get short traces and long problems get long ones, a trade-off that difficulty-aware trace compression makes explicit. They’re complete, with no thought leaps, because expert-written rationales often skip intermediate steps the model hasn’t yet learned. And quality matters more than quantity: s1 and LIMO both show that under 1,000 carefully curated reasoning demonstrations can elicit strong reasoning in a capable base model. The second post in this series covers how to source these traces at scale through distillation and self-generation.

Use plain text for reasoning content and keep it directly relevant to the problem-solving process. When reasoning is enabled during training, it should also be enabled during inference for consistent behavior. Keep in mind that training on a non-reasoning dataset with reasoning_enabled: true can cause the model to lose its reasoning capabilities, because it learns to generate responses without applying reasoning.

SFT supports training models for tool use (function calling) and multimodal understanding (documents, images, video). For tool calling, toolUse blocks appear in assistant turns and toolResult blocks in user turns, each referencing a unique 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."}
      ]
    }
  ]
}

Key constraints for tool calling data:

• toolUse must appear only in assistant turns, and toolResult only in user turns.
• Each toolResult must reference a valid toolUseId from a preceding assistant turn, used exactly once per conversation.
• toolResult content should be text or JSON only.
• The inputSchema within toolSpec must be a valid JSON Schema object.

For multimodal training, document and image content blocks appear in user turns alongside text, with sources referencing Amazon Simple Storage Service (Amazon S3) locations:

{
  "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://<your-bucket-name>/report.pdf"}}
          }
        },
        {"text": "Summarize the key findings from this quarterly report."}
      ]
    },
    {
      "role": "assistant",
      "content": [
        {"text": "The quarterly report highlights three key findings..."}
      ]
    }
  ]
}

Staying close to the original model’s chat template

Every foundation model is post-trained with a specific chat template: the exact token sequences that delimit system prompts, user turns, and assistant turns. Your training data should match this template exactly. Deviating from it, even subtly, forces the model to learn a new input format alongside the new behavior, splitting its learning budget across two objectives. In the worst case, template mismatch causes the model to ignore its system prompt or produce malformed outputs at inference time.

Practical guidelines for template alignment:

• Use the model provider’s official formatting utilities. For Amazon Nova, use the Converse API schema. For open source models, use the tokenizer’s apply_chat_template() method from Hugging Face Transformers.
• Never hand-roll delimiters. If you’re converting data from another format such as ShareGPT or Alpaca, run it through the target model’s chat template function rather than manually inserting role marker strings.
• Validate tokenization round-trips. After formatting, tokenize a sample of your data and decode it back to text. Confirm that role boundaries, special tokens, and content are preserved exactly.
• Match inference-time structure during training. If your production pipeline injects a system prompt, tool definitions, or retrieval context at specific positions, your training data should include those elements in the same positions.

Train/evaluation split

Hold out 10–20 percent of your data as an evaluation set. This isn’t optional. Without it, you can’t distinguish genuine learning from overfitting. The evaluation set should be representative of your production distribution, not a random slice that might under-represent rare but important categories.

For small datasets (under 1,000 samples), use stratified splitting so each task category appears in both training and evaluation sets. For larger datasets, random splitting usually suffices, but verify the distribution afterward. Before training, establish baseline performance on your evaluation set using the unmodified model. This gives you a concrete target to beat and helps you quantify the value of supervised fine-tuning.

Conclusion

Data preparation is the most impactful activity in any SFT workflow. The patterns covered here, including systematic quality checks, schema-compliant formatting, and a representative train/evaluation split, apply whether you’re fine-tuning for a narrow classification task or a complex multi-turn dialogue system. Invest the time upfront, and your training jobs will converge faster, generalize better, and avoid the costly cycle of debugging model behavior that traces back to data problems.

In the second post of this series, we cover the advanced side of SFT data preparation: evaluating data readiness with learning curves, selecting high-value subsets, augmenting your data, and mixing data sources to prevent catastrophic forgetting.

To get started, visit the Amazon Bedrock console to explore model customization options. Learn more about Amazon Nova on the service detail page, review the Amazon Nova documentation for customization guides, and explore the Amazon SageMaker HyperPod recipes repository for ready-to-run training configurations. For related reading, see Customize Amazon Nova models with Amazon Bedrock fine-tuning on the AWS Machine Learning Blog.

---

About the authors

Elyse Zhang

Elyse is a Senior GenAI Strategist at the AWS Generative AI Innovation Center (GenAIIC), where she helps enterprise customers with their model customization journey. She focuses on translating business requirements into effective customization strategies across industries.

Krishnateja Killamsetty

Krishnateja is a Senior Applied Scientist at the AWS Generative AI Innovation Center (GenAIIC), specializing in data-efficient machine learning and model customization techniques. His research interests include data subset selection, data mixing, and efficient fine-tuning of large language models. Outside of work, he enjoys reading research papers and spending time with his family.