簡短回答。 AI代理需要的數據是代表 時間維度上的行為，而非簡單的提示-響應對。訓練與評估的基本單元是 軌跡 —— 一個任務說明、可用工具、每一步操作及其參數、環境對操作的響應、中間狀態以及最終結果 —— 並標註出首次產生實質性失敗的位置。與此同時，還配備一個 驗證器：在代理運行前預先編寫的一條確定性檢查，用於判斷最終狀態是否成功，從而將‘答案看起來正確’轉化為可重複的成功信號。沒有軌跡，就無法判斷代理在規劃、工具選擇、執行、狀態跟蹤或驗證環節是否失敗；沒有驗證器，就無法判斷其是否真正成功。
一個傳統的語言模型示例包含一個提示和期望的響應。一個代理會決定行動、執行、觀察結果、更新其計劃，並持續進行，直到達成目標或放棄目標。這種差異改變了數據需要記錄的內容、誰需要審查它以及如何定義成功——那些將代理數據當作普通指令數據來購買的團隊，通常在評估階段才發現這種不匹配，而不是在數據收集階段。
本指南闡明瞭軌跡包含的內容、軌跡如何進行標註、為何驗證器必須在運行前編寫、失敗運行如何轉化為訓練數據，以及為何合格的審查員並非可有可無。
代理數據與普通LLM數據有何不同？
| 普通LLM數據 | 代理數據 | |
|---|---|---|
| 單元 | 一個提示和一個響應 | 一條跨越多個步驟的軌跡 |
| 評判的內容 | 輸出文本 | 輸出 和 通往該輸出的路徑 |
| 真實基準 | 一個參考答案或多個答案之間的偏好 | 一個經驗證的最終狀態，加上一個可接受路徑的約束 |
| 故障歸因 | 答案是錯誤的 | 規劃、工具選擇、論據、狀態跟蹤、恢復或驗證——每一項都是一個獨立類別 |
| 環境 | 無 | 工具、API、文件、數據庫或模擬器，每個都有其自身狀態 |
| 標註員技能 | 語言和領域判斷 | 相同的內容，再加上能夠閱讀執行軌跡的能力 |
| 成本驅動因素 | 長度和主題難度 | 軌跡長度以及需要審查的決策點數量 |
驅動其餘行的是失敗歸因。一個簡單的標籤說明任務未完成，並不能為你提供任何可操作的信息。一個選擇了合理計劃並調用參數錯誤工具的代理，需要與一個發明了不存在工具的代理採取不同的修復方式，而這兩者又與一個每一步都正確完成且從未檢查自身工作的代理完全不同。
軌跡實際上包含什麼？
每一步都應保留當前指令、該時刻可用的工具、所選動作、其參數、環境的響應、最終狀態以及系統暴露的任何推理。以這種方式記錄，軌跡讀作可審計的序列，而非簡單的轉錄。
一個簡短的示例——一個代理被要求將客戶退款與訂單記錄進行核對：
| 步驟 | 採取的動作 | 環境響應 | 標註 |
|---|---|---|---|
| 1 | search_orders(customer_id) |
返回三個訂單 | 計劃有效；工具選擇恰當 |
| 2 | get_order(id=…) 在最近一個訂單上 |
訂單找到；狀態為"已發貨" | 工具正確，記錄錯誤——退款請求指定了一個更早的訂單 |
| 3 | issue_refund(order_id=…, amount=…) |
退款已創建 | 首次後果性故障。 基於未經驗證的記錄操作；未設置確認步驟 |
| 4 | 向用戶報告成功 | — | 結果被報告為已完成；驗證者在最終狀態上失敗 |
從該表格中可以得出兩點。最終輸出看起來是正確的——代理確實發起了退款，並且流暢地報告了該結果——而錯誤出現在第2步，距離任何明顯問題出現前兩步。只有在步驟級別的標註才能定位到這一點。這也是為什麼首次實質性失敗被明確標記：其之後的所有內容都已受到汙染，若將後續步驟單獨視為錯誤，則會誇大失敗數量並掩蓋根本原因。
軌跡標註是什麼？
軌跡標註審查整個序列，並在每一步標記若干屬性：計劃是否有效、工具調用是否恰當、參數是否正確、代理是否從自身引發的錯誤中恢復，以及首次實質性失敗發生的位置。它對訓練和診斷都具有價值，因為它記錄了結果是如何達成的，而不僅僅是最終輸出是否看起來正確。
標註只有在失敗類別提前固定的情況下才具有可比性。一個可行的初始分類體系：
| 失敗類別 | 在軌跡中看起來是什麼樣子 |
|---|---|
| 規劃 | 一個連貫的目標被分解為步驟，但這些步驟無法實現目標 |
| 工具幻覺 | 調用一個不存在的工具或參數 |
| 工具選擇 | 使用了真實的工具，但用於錯誤的目的 |
| 參數錯誤 | 調用了正確的工具，但參數值格式錯誤或不正確 |
| 狀態跟蹤 | 基於過時或記錯的環境狀態採取行動 |
| 循環 | 重複執行相同操作而沒有獲得新信息 |
| 過早完成 | 任務報告已完成，但未滿足標準條件 |
| 不安全或未經授權的操作 | 超出允許範圍的步驟，無論是否成功 |
隨著團隊使用時間的推移，該分類體系會變得更有用，因為它能幫助團隊追蹤不同模型版本間各類別的縮小情況和持久情況。一個從未縮小的類別通常是由數據問題或環境問題引起的，而不是模型問題。
為什麼代理需要驗證器和客觀成功標準？
代理通常在最終狀態可以被檢查的環境中運行。文件應存在。數據庫記錄應發生變更。測試應通過。預訂應滿足明確的約束條件。驗證器將這些要求轉化為可重複的評估或獎勵信號，且必須在代理運行之前編寫——在代理運行之後才寫下的標準通常描述的是代理實際執行的內容。
任務成功率 = 滿足全部既定成功標準的軌跡數 ÷ 嘗試的軌跡總數
應與第二個圖表並列報告，因為代理可以通過不可接受的路徑達到正確的最終狀態：
有效路徑成功率 = 不含不安全或未經授權步驟的成功軌跡數 ÷ 嘗試的軌跡總數
兩個數值之間的差距是部署中真正需要關注的部分。一個任務成功率達到較高水平，但有效路徑率遠低於該水平的代理，已經學會了以你未授權的方式達成目標，而將兩者平均會完全掩蓋這一點。
當評估者僅是判斷另一個語言模型的語言模型時，隱藏錯誤會通過——這與任何系統對其自身假設進行評分時出現的循環性問題相同。對於主觀性或高風險部分，應結合確定性檢查與人工審核。更廣泛的評估設計在系統上線前的內容將在 部署前評估AI 中單獨介紹。
如何將代理失敗轉化為訓練數據？
保留失敗軌跡。大多數程序會丟棄這些軌跡，從而浪費了它們產生的最有信息量的內容。
- 根據固定分類法標註失敗原因，在失敗進入的步驟處進行標註。
- 詢問失敗揭示了什麼問題。 模糊的指令、缺失的工具文檔、環境不匹配以及真正的規劃缺陷都會表現為一次失敗運行，需要不同的應對方式。
- 為相同任務編寫修正後的示範——一個可信的、分步驟的示例，說明應該如何完成該任務，包括正確的操作步驟和最終狀態。
- 設計針對性任務以隔離弱點，而不是增加更多一般性的任務。
- 在保留的變體上重新測試。 一個在特定任務上驗證過的修復措施，只能衡量記憶能力，而非實際能力。
修正後的示範以及不同軌跡之間的偏好數據，正是人類反饋訓練方法所消耗的內容——Ouyang 等人在《使用人類反饋訓練語言模型遵循指令》（arXiv 2203.02155）中描述的方法，但應用於一系列操作而非單個答案。
何時需要專家審核？
每當代理的行為涉及專業系統或高影響決策時。軟件代理需要能夠閱讀其編寫代碼的審核人員。金融流程需要具備領域和合規專業知識。內部運營代理需要了解組織政策和數據權限的人，以便識別某一步驟是否超出了權限範圍。
審核人員的工作涵蓋任務完成和流程質量兩個方面。如果代理通過不安全或未經授權的路徑達到了正確結果，不應將其記錄為成功——而缺乏相關專業知識的審核人員會將其記錄為成功，因為最終狀態看起來是正確的。
向代理數據供應商提問的內容
- 每條軌跡具體交付什麼內容——是完整的分步驟記錄，還是僅一個結果標籤？
- 使用的是哪種失敗分類法，是否可以擴展到我們的環境？
- 如何識別並由誰識別首次產生後果的失敗？
- 驗證器是否在運行前編寫，由誰編寫？
- 在相同軌跡上，審核人員之間的一致性如何衡量？
- 審核人員在我們領域的資質是什麼，如何驗證？
- 失敗軌跡是否被保留並交付，還是被過濾掉？
Lifewood的應對方式
Lifewood 支持圍繞代理程序的數據操作——任務創建、分步驟軌跡審核、失敗標註和人工評估——採用與一般標註相同的結構：在工作開始前就確定一個固定的分類法，審核人員具備被評估領域的專業知識，並通過 95%以上準確率 的雙重人工參與閉環進行審核。當代理在多個市場運營時，審核必須以本地語言進行，這正是 50多種語言 和 30多個國家的40多個交付中心 所支持的。AI數據遺產可追溯至2004年，當前公司成立於2018年。
參見 企業級LLM訓練數據，AI數據驗證 和 購買建議：RLHF、SFT或蒸餾。
資料與進一步閱讀
- Ouyang 等人，《使用人類反饋訓練語言模型遵循指令》，arXiv 2203.02155——通過修正示範和偏好數據輸入的人類反饋訓練方法。
- NIST，人工智能風險管理框架（AI RMF 1.0），2023年1月——關於採取行動的系統在文檔和可追溯性方面的期望要求。