为 Amazon Nova 机型准备数据 - Amazon Bedrock

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

为 Amazon Nova 机型准备数据

当您通过强化微调对 Amazon Nova 模型进行微调时,您可以自带提示或使用现有的 Amazon Bedrock API 调用日志作为训练数据。

训练数据要求和来源

您可以通过以下选项之一提供训练数据:

注意

我们仅支持 OpenAI 聊天完成格式。

收集您的提示并以 .jsonl 文件格式存储它们。您可以上传 JSONL 格式的自定义数据集,也可以从 Amazon S3 中选择现有数据集。JSONL 中的每条记录都必须使用以下结构的 OpenAI 聊天完成格式:

  • messages:在此字段中,包括包含向模型提供的输入提示的用户、系统或助手角色。

  • reference_answer:在此字段中,它应包含您的奖励函数用来对模型的响应进行评分的预期输出或评估标准。它不仅限于结构化输出,还可以包含任何有助于您的奖励功能评估质量的格式。

  • [可选] 您可以添加评分者 Lambda 用于评分的字段。

要求:

  • JSONL 格式,提示符采用 OpenAI 聊天完成格式(每行一个提示)

  • 训练数据集中至少有 100 条记录

  • Amazon Bedrock 会自动验证训练数据集的格式

Example: General question-answering
{ "messages": [ { "role": "system", "content": "You are a helpful assistant" }, { role": "user", "content": "What is machine learning?"} ], "reference_answer": "Machine learning is a subset of artificial intelligence that enables computers to learn and make decisions from data without being explicitly programmed." }
Example: Math problem
{ "id": "sample-001", "messages": [ { "role": "system", "content": "You are a math tutor" }, { "role": "user", "content": "Solve: 2x + 5 = 13" } ], "reference_answer": { "solution": "x = 4", "steps": ["2x = 13 - 5", "2x = 8", "x = 4"] } }

在创建强化微调任务时,您可以让 Amazon Bedrock 使用您的 S3 存储桶中的现有调用日志作为训练数据。对于 Amazon Bedrock,调用日志是模型调用的详细记录。

您可以使用来自 Amazon S3 的客户端存储 Invoke/Converse 的 API 调用日志进行培训。

要求:

  • 必须启用 API 日志才能使用 Amazon Bedrock

  • 日志必须采用支持的格式(Amazon Bedrock Invoke/Converse API)

  • 至少 100 个提示示例

要使用调用日志进行强化微调,请将模型调用日志设置为开启,使用其中一个模型调用操作,并确保已将 Amazon S3 存储桶设置为日志的目标。有关设置调用日志的更多信息,请参阅使用 CloudWatch 日志和 Amazon S3 监控模型调用

在以 S3 存储桶中的调用日志作为输入开始强化微调任务之前,必须提供 Amazon Bedrock 访问来自 S3 存储桶的日志的权限。有关更多信息,请参阅 模型自定义访问权限和安全性

您可以选择使用其中一个模型调用操作向调用日志中的提示-响应对添加请求元数据,稍后再使用该元数据来筛选日志。Amazon Bedrock 可以使用筛选后的日志来微调模型。

在调用日志中的提示和响应中添加请求元数据

通过调用日志,您可以使用附加到调用日志的请求元数据来识别您希望 Amazon Bedrock 用于强化微调的训练数据集提示。

以下是来自调用的调用日志的InvokeModel示例:requestMetadata

{ "schemaType": "ModelInvocationLog", "schemaVersion": "1.0", "timestamp": "2024-09-11T17:16:18Z", "accountId": "XXXXX", "identity": { "arn": "arn:aws:sts::XXXXXXX:assumed-role/Admin/XXXXXX" }, "region": "us-east-1", "requestId": "7ee514f3-9eff-467c-af75-8fd564ce58e5", "operation": "InvokeModel", "modelId": "meta.llama3-1-405b-instruct-v1:0", "input": { "inputContentType": "application/json", "inputBodyJson": { "prompt": "story of two dogs", "max_tokens_to_sample": 300 }, "inputTokenCount": 13 }, "output": { "outputContentType": "application/json", "outputBodyJson": { "type": "completion", "completion": " Here is a story about two dogs:\n\nRex and Charlie were best friends who lived next door to each other. Every morning, their owners would let them out into the backyard to play. Rex was a golden retriever with long, shaggy fur. He loved to run and chase sticks. Charlie was a corgi with short legs and a big smile. He was happy just sniffing the grass and rolling around. \n\nThe two dogs spent every day playing together. Rex would grab a stick and bring it over to Charlie, wagging his tail excitedly. Charlie would take the other end of the stick in his mouth and they'd have a friendly game of tug-of-war. After tiring themselves out, they'd flop down in the warm sunshine for a nap. \n\nAt lunchtime, their owners would call them in for food. Rex would gobble up his kibble hungrily while Charlie ate his at a more leisurely pace. After lunch, it was right back outside for more playtime. The afternoon sunbeams would light up their fur as they chased each other around the yard. \n\nWhen it started getting late, their owners called them in for the night. Rex and Charlie would head inside, tired but happy after another fun day of play. After slurping up fresh water from their bowls, they'd curl up on their beds, Rex's fluffy golden tail tucked over his nose and little", "stop_reason": "max_tokens", "stop": null }, "outputTokenCount": 300 }, "requestMetadata": { "project": "CustomerService", "intent": "ComplaintResolution", "priority": "High" } }

开始钢筋微调作业时,您可以将调用日志指定为输入数据源。您可以通过 Amazon Bedrock 控制台、 AWS CLI API 或 SDK 开始钢筋微调工作。

提供请求元数据的要求

请求元数据必须满足以下要求:

  • 以 JSON key:value 格式提供。

  • 键值对必须是长度不超过 256 个字符的字符串。

  • 最多提供 16 个键值对。

使用请求元数据筛选条件

一旦包含请求元数据的调用日志可用,您就可以根据请求元数据应用过滤器,有选择地选择要包含哪些提示以微调模型。例如,您可能只想包含那些带有"project": "CustomerService""priority": "High"请求元数据的内容。

要使用多个请求元数据筛选日志,请使用单个布尔运算符ANDOR。您不能组合这些运算符。要筛选单个请求的元数据,请使用EqualsNot Equals运算符。

有效训练数据的特征

有效的 RFT 训练数据需要三个关键特征:

  • 清晰度和一致性 — 使用格式一致的清晰、毫不含糊的提示。避免使用相互矛盾的标签、模棱两可的说明或相互矛盾的参考答案,从而误导培训。

  • 多样性 — 包括不同的输入格式、边缘案例和难度级别,以反映不同用户类型和场景的生产使用模式。

  • 高效的奖励函数 — 设计可快速执行(几秒钟,而不是几分钟)、与之并行并行并返回一致分数的函数 AWS Lambda,从而实现经济高效的训练。

其它属性

RFT 数据格式支持超出核心架构要求的自定义字段(messagesreference_answer)。这种灵活性使您可以添加奖励功能所需的任何其他数据,以便进行适当的评估。

注意

您无需在食谱中对此进行配置。数据格式本质上支持其他字段。只需将它们包含在您的训练数据 JSON 中,它们就会传递给您的metadata现场奖励函数。

常见的附加属性

  • task_id— 用于跟踪的唯一标识符

  • difficulty_level— 问题复杂度指标

  • domain— 主题领域或类别

  • expected_reasoning_steps— 解决方案中的步骤数

这些额外字段将在评估期间传递给您的奖励函数,从而实现针对您的特定用例量身定制的复杂评分逻辑。

带有其他属性的示例

Chemistry problem
{ "id": "chem-001", "messages": [ { "role": "system", "content": "You are a helpful chemistry assistant" }, { "role": "user", "content": "Predict hydrogen bond donors and acceptors for this SMILES: CCN(CC)CCC(=O)c1sc(N)nc1C" } ], "reference_answer": { "donor_bond_counts": 2, "acceptor_bond_counts": 4 } }

reference_answer字段包含您的奖励函数用来对模型的响应进行评分的预期输出或评估标准。它不仅限于结构化输出,还可以包含任何有助于您的奖励功能评估质量的格式。

Math problem with metadata
{ "messages": [ { "role": "system", "content": "You are a math tutor" }, { "role": "user", "content": "Solve: 2x + 5 = 13" } ], "reference_answer": { "solution": "x = 4", "steps": ["2x = 13 - 5", "2x = 8", "x = 4"] }, "task_id": "algebra_001", "difficulty_level": "easy", "domain": "algebra", "expected_reasoning_steps": 3 }