簡短回答： AI代理需要數據來代表隨着時間的推移而採取行動,而不是對一對迅速和反應。 培訓和評價單位是一個軌跡——任務說明、可用工具、採取的每一項行動、環境反應和最後結果——說明發生第一次失敗的地點。 旁邊是檢查狀態的核查員 在代理運行前寫好的
核心重點
- 軌跡,不是單一的即時反應對,是動力訓練和評價數據的基本單位.
- 驗證員是確定任務結束狀態的檢查,在代理運行前寫成,將一個看起來似是而非的答案變成可重複的成功信號.
- 步級失敗歸屬——規劃,工具選擇,參數,狀態跟蹤,或覈查——是導致失敗運行有用而不是被丟棄的.
- 任務成功率和有效路徑成功率是兩個不同的數字;它們之間的一個差距意味着代理通過未經批准的路線達到目標.
- 多語言或市場特定代理人需要審查人員在市場上工作,因爲可接受的行動和預期措辭因地方而異。
代理數據與普通LLM數據有何不同?.
常規語言模型的例子包含一個迅速和想要的反應;一個代理人決定、行動、觀察結果、更新計劃,並一直持續到目標達到或放棄。 差異會改變數據必須記錄的內容、由誰來審查以及成功如何定義。
| 普通LLM數據 | 代理數據 | |
|---|---|---|
| 單位 | 一次迅速和一次答覆 | 跨越許多步驟的軌跡 |
| 判斷什麼? | 輸出文本 | 產出 和 道路走進它 |
| 事實 | 參考答案或答案之間的偏好 | 已覈實的結束狀態,加上可接受的路徑限制 |
| 失敗的歸屬 | 答案是錯的 | 規劃、工具選擇、論據、狀態跟蹤、恢復或覈查——每個類別都不同 |
| 環境 | 無 | 工具、 API、 文件、 數據庫或模擬器, 每個都具有自己的狀態 |
| 註釋員技能 | 語言和領域判決 | 同樣的,加上讀取處決追蹤的能力 |
| 成本驅動器 | 長度和主題難度 | 軌跡長度和需要審查的決定點數目 |
驅動其它數據的行是失敗歸屬。 單標籤上寫着任務尚未完成, 無法顯示您可以執行什麼。 團隊對代理數據處理的方式與對任務進行處理的方式相同 。 代理和基因AI系統 通常在評估過程中而不是在收集過程中被構建和評估。選擇合理計劃並稱爲有錯誤參數的工具的代理商需要與發明不存在的工具不同的固定,兩者都不同於完成每個步驟而從未檢查自己的工作。
軌跡到底包含什麼?
每一步都保留生效指令,當時可用的工具,所選擇的動作,其論據,環境反應,結果狀態,以及系統暴露的任何推理.
軌跡是特工運行的完整逐步記錄 ——記錄方式是,它讀作可審計的序列而不是記錄。
| 步驟 | 採取的行動 | 環境反應 | 註釋 |
|---|---|---|---|
| 1 | search_orders(customer_id) |
三個命令還了 | 計劃有效; 工具合適 |
| 2 | get_order(id=…) 順序 |
找到順序; 狀態“ 已發運 ” | 正確的工具, 錯誤的記錄—— 退款請求命名爲更早的命令 |
| 3 | issue_refund(order_id=…, amount=…) |
已創建的退款 | 第一次失敗 以未經覈實的記錄行事;沒有確認步驟 |
| 4 | 向用戶報告成功情況 | — | 報告結果爲完整;在結束狀態時覈查失敗 |
有兩個東西從那個表格中掉出來。最後的輸出看起來是正確的——代理公司確實發行了退款並流利地報告了它——在2步輸入錯誤,然後才明顯出錯。只有階梯級的註釋才找到它。 這也是爲什麼第一個結果的失敗被明確標記:它被污染後的一切,然後將這些後來的步驟分級爲獨立的錯誤,誇大了失敗的計數並隱藏了原因.
軌跡說明是什麼?
軌跡註釋在每一步都檢視一個序列並標記屬性:計劃是否有效,工具調用是否恰當,代理商是否從它造成的錯誤中恢復,以及發生第一個相應的故障的地方.
它對培訓和診斷都很重要,因爲它記錄了結果是如何取得的,而不是僅僅記錄了最終產出是否正確。 只有在故障課事先確定的情況下,標籤才具有可比性:
| 失敗類 | 痕跡裏是什麼樣子 |
|---|---|
| 規劃 | 一致的目標被分解成無法實現的步驟 |
| 工具幻覺 | 調用不存在的工具或參數 |
| 工具選擇 | 用於錯誤目的的真正工具 |
| 參數錯誤 | 調用正確工具的數值有誤或錯 |
| 國家跟蹤 | 以陳舊或記憶不靈的環境狀態行事 |
| 循環 | 同一行動在沒有新資料的情況下重複 |
| 過早完成 | 報告任務完成,標準未達到 |
| 不安全或未經授權的行動 | 超出允許範圍的一個步驟,無論是否成功 |
固定分類學隨着時間推移變得有用,因爲它讓團隊追蹤哪些類在模型版本之間縮小,哪些類是持久性的——後面的學科是相同的. 推理追蹤數據,教一個模型來顯示其工作。一個從未縮小的類通常是數據問題或環境問題,而不是模型問題。
爲什麼代理人需要覈查員和客觀的成功標準?
代理人通常在可以檢查最終狀態的地方運作——文件應該存在,數據庫記錄應該已經改變,測試應該通過,保留應該滿足已聲明的限制——覈查者將這些要求轉換成可重複的評價或獎勵信號.
驗證員是確定狀態的檢查,在代理運行前寫成,因爲之後寫出的標準往往描述代理人做了什麼而不是它應該做什麼.
Task success rate = Trajectories meeting every stated success criterion ÷ Trajectories attempted
與第二個數字一起報告,因爲一個代理可以通過一個不可接受的途徑到達正確的端態:
Valid-path success rate = Successful trajectories with no unsafe or unauthorised step ÷ Trajectories attempted
兩者之間的差距是部署的關鍵。 一個任務成功率高、有效率低得多的代理人已經學會了以你沒有認可的方式實現目標,平均兩者都掩蓋了這一點。 如果評價員只是判斷另一種語言模式的語言模型,隱藏錯誤就會通過——在“E.C.C.”中檢查的循環性。 如何可靠一個 LLM 做法官時將確定性檢查與對主觀或高風險部分的人力審查結合起來;將檢查內容以及如何涵蓋範圍更廣的設計問題結合起來。 設計企業評價基準.
如何將代理失敗轉化爲培訓數據?
保持失敗的軌跡,而不是拋棄它們,因爲它們攜帶的是節目製作的最豐富的資料。
- 標出原因 與固定分類法相對, 也就是失敗進入的一步。
- 問如何是失法之證. 指令不明確、缺少工具文檔、環境不匹配和真正的規劃缺陷,都是失敗運行,需要不同的應對。
- 寫一個更正的演示文稿 ——這是值得信賴的一步步完成這項工作的例子,包括正確的行動和最終狀態。
- 建立目標任務,將薄弱環節隔離開來而不是一般地更多的任務。
- 複試持戒變種. 用於計量的固定裝置,而不是能力。
修正的演示和軌跡之間的偏好數據也是人類餵養背部訓練方法所消耗的——歐陽等人在"訓練語言模型以聽從人類反饋的指示"(arXiv 2203.02155)中描述的方法,應用於動作的序列而不是單答. 決定其中哪些購買方法包含在 RLHF, SFT 和蒸餾:購買什麼.
何時需要專家審查?
每當代理的行動觸及專門系統或影響大的決定時,軟件代理需要能夠讀取其所寫的代碼的審覈員,財務工作流程需要域和遵守專業知識,內部業務代理需要一個非常瞭解組織政策的人,看一個步驟何時超過它們.
審覈員的工作既包括任務完成,也包括流程質量. 通過不安全或未經授權路徑達成正確結果的代理商不應被記錄爲成功——沒有相關專業知識的審覈員會將其記錄爲一體,因爲結尾狀態看起來是正確的.
你該問什麼代理數據供應商?
詢問每個軌道實際交付什麼,故障是如何分類的,誰有資格寫和檢查驗證員——答案將淺審查過程與產生可用診斷數據的審查過程分開.
- 每個軌道究竟交付了什麼——完整的階梯級記錄,還是結果標籤?
- 使用哪一種故障分類法,它能否延伸到我們的環境?
- 如何確定第一個失敗,以及由誰確定?
- 驗者在逃前有寫,誰寫?
- 審查人員之間如何衡量同一軌跡上的一致?
- 審查者對我們領域有何資格,如何覈實?
- 失敗的軌道是否被保留和交付,或過濾出去?
怎麼樣 Lifewood 輔助代理 AI 數據程序?
Lifewood 支持代理方案的數據操作——任務創建、步態軌跡審查、故障標籤和人的評價——使用它一般適用於註釋的相同結構。
結構是工作開始前商定的固定分類法,審查人員有資格獲得所判斷的領域,以及進行雙層人-在行動審查。 95%+ 準確率 SLA如果代理商在一個以上的市場開展業務,則必須進行語言審查,這就是 50+語言 和 40+ 跨省服務中心 30+ 國家 支持。相關服務頁覆蓋 企業 LLM 培訓數據 和 AI 數據驗證.