本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
在 Amazon Nova 2 上準備 RFT 的資料
Amazon Nova 2 上的 RFT 目前支援以文字為基礎的訓練資料。此頁面說明為 Amazon Nova 2 Understanding 模型準備 RFT 訓練資料的資料格式、支援的功能、限制條件和最佳實務。
提示
若要在開始訓練任務之前驗證資料集格式,請參閱 驗證工具。
資料格式
RFT 訓練資料遵循 OpenAI 強化微調格式
必要. 使用 system、 user和選用assistant角色的對話式轉場陣列。
-
角色 – 必要。常見值:
system(模型的指示) 和user(任務或輸入)。 -
內容 – 必要。訊息的文字內容。對於系統輪換,這是說明;對於使用者輪換,這是任務或輸入。
"messages": [ { "role": "system", "content": "instructions" }, { "role": "user", "content": "prompt" } ]
必要. 您的獎勵函數用來對模型的回應進行評分的預期輸出或評估條件。此欄位不限於結構化輸出 — 它可以包含任何格式,協助您的獎勵函數評估品質。
"reference_answer": { "field": "value" }
選用。在此範例中,模型可用的工具規格陣列。每個項目都會定義工具的界面和中繼資料。如需完整範例,請參閱 工具呼叫。
"tools": [ { "type": "function", "function": { "name": "tool-name", "description": "tool-description", "parameters": {...} } } ]
RFT 資料格式支援 messages和 以外的自訂欄位reference_answer。包含獎勵函數進行適當評估所需的任何其他資料。您不需要在配方中設定這些項目,它們會在執行時間傳遞給 metadata 欄位的獎勵函數。
常見的範例包括:
中繼資料
id– 用於追蹤的唯一識別符task_id– 任務層級識別符difficulty_level– 問題複雜性指標domain– 主題區域或類別expected_reasoning_steps– 解決方案中的步驟數量
評估條件
evaluation_criteria– 特定分級盧布custom_scoring_weights– 不同層面的相對重要性context_data– 問題的背景資訊external_references– 相關文件或資源的連結
驗證您的資料
提交訓練任務之前,請驗證您的資料集,以及早發現格式化問題。如需可用的驗證工具,請參閱 驗證工具。
範例輸入
以下是完整的範例 JSON 物件,示範如何合併不同 RFT 使用案例的欄位。
支援的功能
下表摘要說明 Amazon Nova 2 上 RFT 的功能支援。
一般/文字理解
本節摘要說明在 Amazon Nova 2 訓練資料上準備 RFT 的一般限制條件和最佳實務。
限制條件
| 限制條件 | 詳細資訊 |
|---|---|
| 資料集格式 | JSONL (每行一個 JSON 物件)。 |
| 最低訓練範例 | 100 |
| 最低評估範例 | 100 |
| 支援的模態 | 僅文字 |
最佳實務
我們建議您從最小資料集大小 (100 個訓練和 100 個評估範例) 開始,並在驗證獎勵函數並確認 RFT 適用於您的使用案例後向上擴展。
我們建議採用評估優先的方法。投資大規模 RFT 訓練之前,請評估模型的基準效能:
高效能 (>95% 獎勵) – RFT 可能不必要,因為您的模型已表現良好。
效能非常差 (0% 獎勵) – 首先切換到 SFT 以建立基本功能。
中等效能 – RFT 可能是適當的。
從小型資料集開始,可協助您驗證獎勵函數是否無錯誤、確認 RFT 是正確的方法、及早識別和修正問題,以及在擴展之前測試工作流程。
優先考慮高品質的輸入資料和可靠的獎勵函數,該函數會在模型回應時一致地執行。
範例輸入
{ "id": "math-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"] } }
工具呼叫
RFT 支援工具呼叫模式的訓練模型,讓您的模型了解呼叫外部工具或函數的時間和方式。
限制條件
| 限制條件 | 詳細資訊 |
|---|---|
| 工具定義位置 | 工具會在訓練範例的頂層tools陣列中宣告。 |
| 工具定義格式 | 每個工具都必須在 中包含 type、function.description、 function.name和有效的 JSON 結構描述function.parameters。 |
| 參考答案 | 使用 reference_answer指定預期的工具調用 (例如,tool_called、tool_parameters),讓您的獎勵函數可以評估正確性。 |
最佳實務
確保您的工具定義在所有訓練範例之間保持一致。
此模型會從您提供的示範中學習工具叫用模式。
包含何時使用每個工具以及何時不使用工具的各種範例。
範例輸入
{ "id": "tool-001", "messages": [ { "role": "system", "content": "You are a helpful game master assistant" }, { "role": "user", "content": "Generate a strength stat for a warrior character. Apply a +2 racial bonus modifier." } ], "tools": [ { "type": "function", "function": { "name": "StatRollAPI", "description": "Generates character stats by rolling 4d6, dropping the lowest die result, and applying a modifier.", "parameters": { "type": "object", "properties": { "modifier": { "description": "An integer representing the modifier to apply to the total of the stat roll.", "type": "integer" } }, "required": ["modifier"] } } } ], "reference_answer": { "tool_called": "StatRollAPI", "tool_parameters": { "modifier": 2 }, "expected_behavior": "Call StatRollAPI with modifier=2 and return the calculated stat value" } }
推理
Amazon Nova 2 上的 RFT 支援推理模式,其中模型會在產生最終答案之前產生明確的思維權杖。您可以使用訓練組態欄位控制reasoning_effort訓練期間的推理行為。
限制條件
| 限制條件 | 詳細資訊 |
|---|---|
| 可用模式 | none (省略 reasoning_effort 欄位)low、 和 high。RFT 沒有medium選項。 |
| 預設行為 | 如果 組態中沒有 reasoning_effort 欄位,則會停用推理。 |
| 字符限制 | 啟用推理時,將 max_new_tokens設為 32768 以容納延伸推理輸出。 |
何時使用每個模式
使用推high理:
複雜的分析任務
數學問題解決
多步驟邏輯扣除
step-by-step思考可增加價值的任務
使用 none(省略 reasoning_effort) 或推low理:
簡單事實查詢
直接分類
速度和成本最佳化
直接回答問題
成本和效能權衡
較高的推理模式會增加:
訓練時間和成本
推論延遲和成本
複雜推理任務的模型功能
有效訓練資料的特性
清晰度和一致性
良好的 RFT 範例需要清晰、不明確的輸入資料,以便在不同的模型輸出間實現準確的獎勵計算。避免資料中的雜訊,包括:
不一致的格式
矛盾的標籤或指示
模棱兩可的提示
衝突的參考答案
任何模棱兩可的情況都會誤導訓練程序,並導致模型學習意外的行為。
多樣性
您的資料集應擷取生產使用案例的完整多樣性,以確保強大的實際效能。包括:
不同的輸入格式和邊緣案例
從日誌和使用者分析映射實際的生產使用模式
使用者類型、地理區域和季節性變化的範例
包含從簡單到複雜問題的難度等級
獎勵函數考量事項
設計您的獎勵函數以進行高效訓練:
在幾秒鐘內執行 (非分鐘)
使用 Lambda 有效平行化
傳回一致、可靠的分數
正常處理不同類型的模型輸出
快速、可擴展的獎勵函數可實現快速迭代和經濟實惠的實驗。
使用 LLM 做為判斷的 RFT 訓練
概觀
大型語言模型 LLMs) 在強化微調 (RFT) 工作流程中逐漸被用作判斷,提供引導模型最佳化的自動獎勵訊號。在此方法中,LLM 會根據指定的條件評估模型輸出,無論是評估正確性、品質、風格遵循或語意相等性,並指派推動強化學習程序的獎勵。
這對於傳統獎勵函數難以以程式設計方式定義的任務特別有用,例如判斷不同的表示法 (例如 "1/3"、"0.333" 和 "1/3") 是否在語義上相等,或評估一致性和相關性等細微品質。透過使用以 LLM 為基礎的判斷做為獎勵函數,您可以將 RFT 擴展到複雜的網域,而不需要大量的人工註釋,因此除了傳統對齊問題之外,可在各種使用案例中快速迭代和持續改善模型。
驗證您的 LLM 判斷
在生產環境中部署 LLM-as-a-judge 之前,請驗證判斷模型的評估是否符合人類判斷。這包括:
針對您任務的代表性範例,測量 LLM 判斷者與人工評估者之間的協議率
確保 LLM 與人類的協議符合或超過人際協議費率
識別判斷模型中的潛在偏差
建立獎勵訊號引導模型朝預期方向的可信度
此驗證步驟有助於確保自動化評估程序會產生符合您生產品質標準的模型。
LLM 判斷的 Lambda 組態
使用 LLM 做為判斷,是使用 Lambda 函數進行強化學習與可驗證獎勵 (RLVR) 的延伸。在 Lambda 函數中,您可以呼叫 Amazon Bedrock 中託管的其中一個模型。
重要的組態需求:
| 組態 | 需求 | 詳細資訊 |
|---|---|---|
| Amazon Bedrock 輸送量 | 足夠的配額 | 確保所使用的 Amazon Bedrock 模型的輸送量配額足以滿足您的訓練工作負載 |
| Lambda 逾時 | 延長逾時 | 將 Lambda 函數逾時設定為最長 15 分鐘。預設設定為 3 秒,這不足以回應 Amazon Bedrock 模型 |
| Lambda 並行 | 並行增加 | Lambda 會在訓練期間平行叫用。增加並行以最大化可用輸送量 |
| 配方組態 | 比對 Lambda 設定 | 必須在配方中設定並行限制 |