前一篇整理了幾種常見的微調方式：
應該很直覺的下一步就是準備資料。
但「選哪種方法」只回答模型要根據什麼訊號學習，還沒有回答資料從哪裡來，以及如何把原始內容整理成可學習的樣本。
如果目標是調整 Agent 的行為，資料準備大致有四種起點：
| 資料來源 | 適合拿來做什麼 | 主要限制 |
|---|---|---|
| 既有公開資料集 | 快速建立基礎能力或作為初始資料 | 任務、工具與企業流程未必相同，也可能有授權或污染問題 |
| 專家示範與人工標註 | 定義理想流程、正確動作與偏好取捨 | 品質較容易控制，但成本高，案例也不容易涵蓋完整 |
| 正式環境執行紀錄（Production Trace） | 找到真實使用情境、常見錯誤與實際工具互動 | 同時混有模型、工具、系統與人工行為，不能直接視為標準答案 |
| 合成資料 | 補足少見案例、邊界條件與新的工具組合 | 生成內容看似合理，仍可能違反真實狀態或工具限制 |
這四條路通常不會單獨使用。團隊可以先用專家示範建立最低標準，再從 Production Trace 找出真實問題，最後用合成資料補足缺少的情境；公開資料則適合提供通用能力或作為比較基準。
不論從哪裡開始，原始資料都還不是可以直接送進訓練流程的教材。公開資料要確認適用性，人工示範要維持一致標準，合成資料要驗證，Production Trace 則要先分清楚每一步是誰做的，以及它是否值得模型模仿。
其中，Production Trace 特別值得深入討論。
Production Trace 它會隨系統運作持續累積，也最接近 Agent 正式面對的任務、工具與使用者；但它記錄的是整個系統如何完成工作，不是替模型整理好的正確示範。資料越真實，裡面混合的責任也可能越複雜。
假設我們從 Production Trace 找到一筆退款工單，最後狀態顯示「處理成功」。完整紀錄卻是這樣：Agent 沒有先查例外條款，便拒絕退款；使用者提出異議後，客服接手查詢，主管完成核准，付款系統才真正退回款項。
從營運報表來看，這是一筆成功案件。但如果把整段紀錄當成標準答案，模型可能同時學到錯誤拒絕、人工才有權限執行的核准，以及最後正確的退款結果。
問題不在紀錄太亂，而是「成功」描述的是整個系統的結果，不是模型每一步的品質。
Production Trace 的任務，是讓我們重建一次執行：
誰說了什麼、呼叫哪個工具、工具回傳什麼、何時有人接手，以及任務最後如何結束。
資訊保留得越完整，越有利於除錯與稽核。
訓練資料的任務不同，它必須從這些事件中，進一步回答四個問題：
因此，一筆工單通常不會直接等於一筆教材。同一段 Trace 可以被整理成不同資料，但要配合前一篇選擇的訓練方法。
| 訓練用途 | 真正需要的資料 | 常見誤用 |
|---|---|---|
| SFT | 當時可見的輸入，加上值得模仿的模型動作 | 把工具回傳、人工操作和整段成功紀錄都當成模型答案 |
| 偏好學習 | 相同決策狀態下，可比較的兩個動作與選擇依據 | 拿背景、工具版本都不同的兩條軌跡直接比較 |
| 強化學習 | 任務、環境狀態、執行軌跡、Reward、終止原因與驗證方式 | 只留下最終分數，卻不知道是哪一步造成成敗 |
同一份原始紀錄可以服務不同方法，但不能不經轉換就共用完全相同的訓練樣本。訓練目標不同，資料要證明的事情也不同。
長軌跡最容易出現的問題，是只有一個最終標籤。
退款成功，不代表中間每個決策都正確；任務失敗，也不代表前面的查詢與檢查都毫無價值。若只依最後結果保留或丟棄整條軌跡，我們會把不同品質的步驟綁在一起。
2026 年的 SWE-Prime 研究檢查成功的程式修補軌跡。在第一階段選出的軌跡內，所有片段仍保留為 Context，卻只有進一步選定的片段參與訓練損失。在該研究的模型與基準中，篩選出的 10% 軌跡子集優於完整成功集合。SWE-Prime
這不代表所有團隊都該刪掉九成資料。
更重要的啟示是：「後面還需不需要看見這段內容」與「模型要不要模仿這段內容」，是兩個不同決策。
例如 Agent 最初的錯誤拒絕，可以保留在 Context 裡，因為後面的道歉、補查與修正需要知道錯誤曾經發生；但這段拒絕不必成為 SFT 的學習目標。實作上可用 loss mask 標明哪些輸出參與訓練，工具回傳與人工操作也不應被誤算成模型要生成的內容。
人工救回的成功案件，仍要分開標記錯誤動作、人工介入與真正值得學的決策。
偏好資料更需要控制比較條件。若一條成功軌跡查到新版政策，另一條失敗軌跡使用舊版政策，兩者的差異不只來自模型動作，直接配成偏好對就很難歸因。
Verified Critical Step Optimization 採取更嚴格的做法：先定位失敗軌跡中的候選關鍵步驟，在相同狀態下換一個動作，再繼續執行。只有替換動作真的把失敗變成成功，才形成偏好資料。Verified Critical Step Optimization
這項研究主要測試深度搜尋任務，不能直接視為所有 Agent 的標準流程；但它提供了一個很實用的判斷方式：與其比較兩段差異很多的完整故事，不如回到同一個決策點，確認究竟是哪個選擇改變了結果。
真實紀錄不夠乾淨時，團隊常會請更強的模型參考最終答案，重寫一份理想示範。這樣做很有效率，也很容易產生事後資訊洩漏。
例如教師模型看過客服的結案備註，知道這筆訂單符合特殊保障，於是寫出：「案件符合例外條款，應進入核准程序。」可是學生模型在這個決策點只看得到訂單編號，還沒查到保障內容。
這句話的結論可能正確，卻不是一個可學習的下一步。它教模型在缺乏證據時直接猜中答案。
整理資料時，我會做一個簡單檢查：先遮住標準答案，只看模型當時真正收到的輸入，是否仍有合理路徑走到目標動作？如果沒有，就應補上正式部署時也能取得的證據，或把目標改成「先查詢保障條款」。
Patches-to-Trajectories 在建立程式修補資料時，也把策展者可見的參考答案，與教師求解時可見的資訊分開，並檢查每個動作能否由先前已見內容支持。Patches-to-Trajectories
參考答案仍然可以用來驗證結果、挑選資料與發現錯誤，只是不能悄悄變成模型當時已知的證據。實務上最好分欄保存「模型可見內容」「策展者參考答案」「評審理由」，人工介入也要標明操作者與權限。這不只是資料格式問題，而是避免模型學會部署時根本做不到的行為。
即使已經排除錯誤步驟與事後洩漏，資料仍不一定教到我們想要的能力。
假設所有示範都使用同一個退款工具、相同欄位順序與固定提示。模型在測試時表現很好，可能不是因為理解「先確認資格，再執行退款」，而是記住特定工具名稱與介面樣式。
2026 年的 PIPE 研究把工具介面改寫，但盡量保持原本語意不變，藉此測試 Agent 到底學會工具含義，還是依賴訓練時的介面。研究發現，軌跡 SFT 可能加深模型對既有介面的依賴。What Do Agents Learn from Trajectory-SFT
這帶來一個容易被忽略的資料檢查：品質不只看每一步對不對，也要看成功是否建立在不該依賴的捷徑上。
因此，工具使用資料除了成功呼叫，還應涵蓋幾種有意義的變化：同義但不同名稱或欄位表達、存在無關工具、缺少必要工具，以及明明有工具卻不該呼叫的情境。這不是為了無限制增加變體，而是要確認模型學到決策條件，而非背下一套介面。
真實紀錄通常不足以涵蓋少見情境，例如工具回傳互相矛盾、必要欄位缺漏，或政策版本剛好跨越生效日。合成資料可以補足這些空缺，但生成一段合理對話，不等於證明它能在真實環境中成立。
Apple 的 Environment-Free Synthetic Agent Trajectories 從 API 規格生成任務，再模擬具狀態的工具回應並篩選軌跡。值得注意的是，在它的實驗設定中，不同篩選器並非都能改善下游表現，其中一種篩選後反而低於未篩選資料。Apple ESAT
這個結果不能推成某個評審一定不好，但它提醒我們：合成降低的是採集成本，不是驗證成本。 如果生成器與評審接受同一個錯誤假設，流程只會很一致地留下錯誤資料。
較完整的做法，是把任務、初始環境、可用工具與驗證器一起設計。2026 年的 SKT 便把任務、環境、Skill 與隱藏驗證條件共同納入資料建構；Kimi K2 的工具使用訓練，也從工具規格產生任務與評分規則，再透過模擬與可執行環境篩選軌跡。SKT、Kimi K2
對企業團隊而言，不必照搬整套研究流程，但至少要分清楚三個層次：格式是否正確、工具語意與狀態是否一致、任務是否真的通過可執行或人工驗收。模型評審可以協助篩選，評審本身也要用抽查與下游實驗驗證。
資料逐筆看起來合理，測試結果仍可能因洩漏而失真。
同一筆退款案件可以有原始對話、客服修正版、教師重寫與十種合成問法。它們字面不同，背後的訂單條件、政策組合與答案卻完全相同。若逐列隨機切分，訓練集與測試集可能同時出現同一案件的不同版本。
因此，順序應該反過來：先以原始案件、政策版本或其他想測試的泛化邊界建立同源群組，再把整個群組分配到訓練、驗證或測試集合。資料增廣只在訓練群組內進行，最後才做跨集合的精確與近似去重，捕捉漏標的關係。
先追蹤同源關係，再分配資料集合；換句話說，不等於遇到新案件。
切分單位沒有固定答案。如果要測未來政策，政策版本與時間就要隔離；若要測新工具介面，工具版本也要納入群組。關鍵不是套用某個比例，而是先說清楚測試集代表哪一種「沒見過」。
資料交付時，我至少會留下以下紀錄：
| 要能追問的問題 | 最少保留的資訊 |
|---|---|
| 資料從哪裡來？ | 原始案件、使用條件、去識別化與轉換版本 |
| 模型當時看到什麼？ | 實際輸入、政策與工具版本、截斷或重建標記 |
| 希望模型學哪一步？ | 目標片段、loss mask、決策者與標註理由 |
| 為什麼判定正確？ | 驗證器或 Reward 版本、執行結果、人工抽查 |
| 是否與其他資料同源？ | 母任務、改寫與合成關係、資料集合分配 |
這些欄位不必一開始就做成龐大的資料平台，但必須能串回同一個版本。當模型開始過度拒絕、誤用工具，或只會某一種介面時，團隊才有辦法回查是哪批資料、哪種標註與哪個驗證器造成的。
回到開頭那筆人工救回的退款案件。它不是一筆該被整段丟棄的壞資料，也不是一筆可以整段照學的成功示範。原始錯誤可以用來教恢復，人工操作要保留來源與權限，真正值得學的決策則必須由模型當時可見的證據支持。
Trace 保存的是一次執行的事實；Dataset 定義的，才是模型下一次應該重複的行為。
當這份行為規格整理完成，下一篇才能進一步討論：SFT 會如何把示範變成模型習慣，以及訓練後如何確認原本的能力沒有一起退步。
工程師：「這批成功案例都拿去訓練！」AI：「那位一直扶著塔的客服，也會一起部署嗎？」
iThome鐵人賽
看影片追技術