從客戶對話建立評估資料集

每個為客戶微調模型的機構都面臨同樣的評估問題：你如何知道模型實際上適用於客戶的真實用例？

你可以從零開始建立測試集。你可以生成合成評估示例。兩種方法都有一個根本弱點——它們測試你認為模型應該處理的內容，而不是它在生產中實際遇到的內容。

最好的評估資料集來自真實的客戶對話。支持工單、聊天記錄、銷售通話轉錄、生產故障報告——這些是評估集的原材料，用於衡量真正重要的事情。它們捕捉了合成資料很少能重現的混亂、模糊、特定領域的輸入。

本指南介紹完整流程：收集對話、提取測試案例、標記預期輸出，以及隨時間維護你的評估集。

為什麼真實對話勝過合成測試資料

合成評估集在入門時很有用。但它們有三個盲點，真實對話資料可以彌補：

分佈準確性。 合成資料反映的是你想像的分佈樣子。真實資料反映的是它實際的樣子。如果客戶 40% 的支持工單是計費糾紛，5% 是技術問題，合成測試集通常會倒置這一比例——因為「平衡」看起來更好，就生成相同數量的每個類別。結果：你的評估高估了稀有類別的性能，低估了真正重要類別的性能。

語言真實性。 真實用戶不像提示工程師那樣寫作。他們使用縮寫、打字錯誤、混合語言、引用之前互動的背景，並以改變查詢語氣和隱含意圖的方式表達挫折。合成示例往往是乾淨的、完整的和無背景的。

邊緣案例發現。 你無法合成生成你未曾想到的邊緣案例。真實對話資料包含沒有人預期到的邊緣案例——而這些正是導致生產故障的案例。

一項跨多個行業的生產 ML 系統研究發現，在合成測試集上評估的模型顯示的準確率比在真實生產資料上評估同一模型高 8 到 15 個百分點。這個差距就是令人印象深刻的演示與有效部署之間的差異。

來源 1：支持工單

對於大多數客戶部署，支持工單是評估資料最豐富的單一來源。它們代表真實的用戶問題，以真實的用戶語言表達，通常有已知的解決方案。

要提取什麼：

• 輸入： 客戶的原始消息（工單中的第一條消息，在任何客服互動之前）
• 預期輸出： 根據工單實際解決方式的正確回應、解決方案或分類
• 元資料： 工單類別、優先級、解決時間、客戶滿意度分數

提取流程：

1. 從客戶的服務台（Zendesk、Freshdesk、Intercom 等）匯出過去 90 天的已解決工單
2. 過濾成功解決的工單（客戶確認解決或無重開）
3. 對每個工單，提取客戶初始消息作為輸入
4. 對於分類任務：使用分配的類別/標籤作為預期輸出
5. 對於回應生成：使用解決問題的第一條客服回應作為預期輸出
6. 刪除需要升級或有異常情況的工單——這些是值得單獨測試的邊緣案例，不應在核心評估集中

數量目標： 100 到 200 個工單可以給你一個健壯的評估集。如果客戶數量較少，50 是有意義準確率估計的最低要求。

注意事項： 客服回應通常包含問候語、道歉和客套話，你可能不希望模型重現。剝離這些以隔離實質性回應，或者如果模型預期複製完整的客服體驗，則保留它們。

來源 2：聊天記錄

如果客戶有現有的聊天機器人或即時聊天系統，歷史聊天記錄提供了對話評估資料。

要提取什麼：

• 輸入： 用戶的消息（或如果背景重要，對話中到某個輪次的完整對話）
• 預期輸出： 對話中該點的理想回應
• 背景： 對話中的之前消息，如果可用的用戶元資料

提取流程：

1. 匯出過去 60 到 90 天的聊天記錄
2. 識別達到成功解決的對話（用戶感謝客服、標記問題已解決，或沒有帶同樣問題再次來訪）
3. 選擇對話中的特定輪次作為測試案例——並非每個輪次都同樣有用
4. 優先選擇客服提供實質性資訊的輪次（不是「讓我查一下」或「請稍候」）
5. 對於多輪評估，在輸入中包含對話歷史作為背景

數量目標： 75 到 150 個對話輪次。注重多樣性——你需要來自不同類型對話的輪次，而不是來自 5 個長對話的 50 個輪次。

注意事項： 聊天記錄通常包含個人資訊（姓名、帳號、電子郵件地址）。在添加到評估集之前進行匿名化處理。用佔位符替換真實姓名，編輯帳號，並將電子郵件域名替換為 example.com。

來源 3：銷售通話轉錄

對於協助銷售賦能、線索資格認定或產品推薦的模型，銷售通話轉錄非常有價值。

要提取什麼：

• 輸入： 通話中客戶提出的問題、異議或需求
• 預期輸出： 銷售員提供的正確產品推薦、異議處理或資訊
• 結果資料： 交易是否成交、交易規模和成交時間——這讓你可以按業務影響對評估示例進行加權

提取流程：

1. 從過去 90 天拉取轉錄（來自 Gong、Chorus 或類似通話錄音工具）
2. 專注於成交的通話——這些展示了成功的互動
3. 識別每次通話的 3 到 5 個關鍵時刻：初始需求評估、技術問題、異議、定價討論和推薦
4. 對每個時刻，提取客戶的陳述作為輸入，銷售代表的回應作為預期輸出
5. 包括 20 到 30% 來自銷售代表回應在事實上仍然正確的失敗交易的示例——模型應該提供準確的資訊，無論交易結果如何

數量目標： 從 15 到 30 次通話中提取 50 到 100 個時刻。

注意事項： 銷售代表有時會做出技術上不準確的承諾或聲明。在將預期輸出添加到評估集之前，驗證其事實內容。建立在不正確預期輸出上的評估集將訓練你接受不正確的模型輸出。

來源 4：生產故障日誌

最有價值的評估示例來自當前系統失敗的案例。如果客戶已在生產中有模型（或基於規則的系統，或一個會出問題的手動流程），故障案例是黃金。

要提取什麼：

• 輸入： 導致故障的確切輸入
• 預期輸出： 應該發生什麼（事後由領域專家確定）
• 故障模式： 系統如何失敗（錯誤分類、幻覺回應、格式錯誤、超時）

提取流程：

1. 收集過去 6 個月的生產故障報告、客戶投訴和升級
2. 重建觸發每個故障的確切輸入
3. 讓領域專家確定每個案例的正確輸出
4. 按類型分類故障：準確性錯誤、格式錯誤、延遲問題、邊緣案例故障、安全違規

數量目標： 你能找到的每個故障案例。即使 10 到 20 個故障案例也具有不成比例的價值，因為它們代表了模型需要改進的確切場景。

為什麼故障最重要： 你的核心評估集告訴你模型處理正常流量的效果如何。你的故障案例告訴你模型是否修復了客戶最關心的具體問題。當客戶說「模型需要更好」時，他們通常意思是「模型需要停止犯這些特定錯誤」——而故障案例捕捉了這些特定錯誤。

提取和標記流程

第 1 步：匿名化

在任何其他操作之前，從所有對話資料中剝離個人可識別資訊。這是不可談判的，既出於隱私合規的原因，也因為評估集中的個人識別資訊可能洩漏到模型輸出中。

替換：

• 姓名替換為角色識別符（客戶、客服、經理）
• 電子郵件地址替換為 user@example.com
• 電話號碼替換為 555-0100 格式
• 帳戶/訂單號替換為通用 ID（ORDER-001、ACCT-A）
• 公司特定識別符替換為通用標籤

對明顯的情況（電子郵件、電話號碼）使用正則表達式模式自動化，並對特定領域識別符進行手動過一遍。

第 2 步：分類

為每個示例標記它代表的任務類型。常見類別：

• 分類： 正確輸出是固定集合中的標籤
• 提取： 正確輸出是從輸入中提取的特定資訊
• 生成： 正確輸出是自然語言回應
• 摘要： 正確輸出是輸入的精簡版本
• 決策： 正確輸出是建議或判斷

這種分類讓你按任務類型分析模型性能，而不是作為單一準確率數字。模型在分類上可能有 95% 的準確率，但在生成上只有 78%——這種區別驅動不同的改進策略。

第 3 步：標記預期輸出

對每個示例，定義什麼樣的輸出是正確的。這是最難也最重要的步驟。

對於分類任務： 標籤是明確的。客戶支持 = 「計費」。完成。

對於生成任務： 寫出理想輸出。然後寫 2 到 3 個可接受的變體。你的評分應該接受任何語義上等價的輸出，而不只是完全匹配。

對於複雜任務： 定義關鍵標準而不是確切輸出。例如：「回應必須（1）承認計費錯誤，（2）說明正確金額，（3）描述解決步驟，（4）提供時間表。」根據輸出滿足多少標準進行評分。

提示： 讓兩個人獨立標記 20 個示例的子集。測量他們的一致率。如果他們在超過 15% 的示例上有分歧，你的標記標準太模糊——在標記其餘部分之前收緊指南。

第 4 步：格式化以供使用

以 JSONL 格式存儲你的評估集——每行一個 JSON 對象，每個包含：

{
  "id": "eval-001",
  "input": "客戶消息或查詢",
  "expected_output": "理想的模型回應",
  "category": "classification",
  "source": "support_tickets",
  "difficulty": "standard",
  "key_criteria": ["提到退款政策", "提供時間表"],
  "date_added": "2026-02-15"
}

對這個文件進行版本控制。每次添加或修改示例時，遞增版本號。你需要知道哪個評估集版本產生了哪些結果。

你需要多少示例

簡短答案：50 到 200 個可以建立一個可靠的評估集。

更長的答案取決於你需要衡量什麼：

• 50 個示例： 足以偵測重大問題（超過 10% 的準確率差異）。置信區間很寬。適用於初始完整性檢查。
• 100 個示例： 大多數機構部署的標準。準確率估計在正負 6 到 8 個百分點以內。
• 200 個示例： 高置信度評估。準確率估計在正負 4 到 5 個百分點以內。對高風險部署值得投入。
• 500 個以上示例： 企業級評估。只有對任務關鍵型應用程式或需要跨許多子類別細分性能時才必要。

評估集中的分佈：

• 60% 標準/常見案例（代表大部分生產流量）
• 25% 中等複雜度案例
• 15% 邊緣案例和已知故障模式

不要過度加權邊緣案例。邊緣案例佔 50% 的評估集會給你一個悲觀的準確率數字，不能反映真實的生產性能。邊緣案例很重要，但它們應該與其實際頻率成比例。

隨時間維護你的評估集

評估集不是一次性產物。它需要維護。

每月添加： 每月從近期生產資料中添加 10 到 20 個新示例。專注於模型答錯的案例，或代表現有示例未涵蓋的新模式的案例。

季度審閱： 每 3 個月，審閱完整的評估集以找出過時的示例。刪除不再代表客戶用例的案例（產品停用、政策更改、流程更新）。

版本追蹤： 每次更新都獲得一個新版本號。記錄哪個評估集版本用於每次模型評估。這讓你可以追蹤表面上的性能變化是由於模型改進還是評估集變化。

絕不在評估資料上訓練。 這條規則非常重要，值得重複。評估示例一旦出現在你的訓練集中，該示例就不再衡量泛化，而開始衡量記憶。將評估和訓練資料保存在不同的文件、不同的目錄和不同的版本控制中。

從評估集到改進循環

評估集不只是用來評分的。它驅動改進。

1. 對評估集運行模型並識別故障案例。
2. 分類故障：哪些任務類型失敗？哪些輸入模式？
3. 收集或生成 50 到 100 個針對故障類別的新訓練示例。
4. 用增強的訓練集重新訓練模型。
5. 重新運行評估集。驗證故障案例已修復。
6. 驗證其他類別沒有退步。

這個循環——評估、識別差距、生成有針對性的資料、重新訓練、重新評估——是生產模型改進的核心。評估集使其系統化而非碰運氣。

Ertas Studio 直接支持此工作流程：上傳你的評估集，一鍵運行評估，比較跨模型版本的結果，並準確識別哪些類別需要更多訓練資料。平台追蹤你的評估歷史，使你可以查看隨時間的改進趨勢。

---

延伸閱讀

• Synthetic Data Generation for Fine-Tuning — 當你需要更多數量時，如何用合成示例補充真實對話資料
• How to Evaluate Your Fine-Tuned Model — 使用你在此建立的資料集的評估方法