AI 客服回覆如何評估？建立模型比較與品質驗收流程

比較 AI 客服回覆品質，不能只問「哪一個模型比較像真人」或拿一次示範對話下結論。客服回覆的好壞牽涉到事實是否正確、是否符合公司政策、能否推進問題、何時應交由真人，以及是否妥善處理個人資料。GPT-4、Gemini 或其他模型名稱都只是候選方案；真正該比較的是固定版本、固定提示與固定流程在你的案例集上的表現。

先定義「好客服回覆」的可驗收標準

開始 A/B 比較前，先把模糊的「品質好」拆成可檢查的項目。每個項目都應有明確的通過、失敗與需要人工覆核條件，避免評審只憑喜好打分。

• 事實與政策正確：回覆只能使用已核對的知識庫、訂單或帳號資料；資料不足時要承認不確定，而不是補造答案。
• 任務完成度：回覆是否真正回答問題、給出下一步，或在無法處理時正確轉交。
• 安全與隱私：不得要求不必要的敏感資料，不得繞過身分驗證，也不得對高風險情境作出未授權承諾。
• 語氣與可讀性：要符合品牌語氣、清楚且尊重使用者，但禮貌不能掩蓋錯誤內容。
• 營運指標：量測延遲、失敗率、人工接手率與每個已成功解決案件的成本，而非只看單次回覆成本。

建立能代表真實情況的測試集

評估資料應來自經適當去識別化、可合法使用的客服情境，而不是只挑簡單 FAQ。可依意圖、語言、渠道、複雜度與風險分層，並為每一類保留預期事實、允許的處理方式與必須升級的條件。

• 常見問題與知識庫問答。
• 資訊不足、上下文矛盾或需要澄清的對話。
• 退款、帳務、帳號存取或其他需要真人授權的案件。
• 情緒激動、辱罵、詐騙訊號與安全敏感情境。
• 繁體中文、混合語言、口語拼寫與多輪對話。

OpenAI 的 evals 指引以客服工單分類示範：測試資料需要代表預期輸入，並以人工標註的正確答案或規則做為驗收依據。這個概念同樣適用於生成式客服回覆：只要把「正確答案」擴充成事實、政策、升級與語氣等可檢核條件即可。

如何公平比較兩個模型或提示版本？

1. 固定版本與設定：記錄供應商、模型版本、系統提示、工具、知識庫快照、溫度與輸出長度限制。模型名稱相同不代表行為永久不變。
2. 採用盲測：讓評審不知道回覆來自哪個候選方案，並隨機呈現順序，降低品牌偏好造成的偏差。
3. 分項評分：把事實正確、政策遵循、問題解決、升級判斷、語氣與安全分開記錄；不要用一個總分掩蓋關鍵失敗。
4. 人工校準自動評分：規則檢查或模型評審可加快篩選，但應以人工抽樣與一致性檢查校準；高風險案例不可只交給自動評分。
5. 看錯誤切片：除了平均分數，也要看哪一種意圖、語言或風險案件失敗，才能知道是否真的可上線。

把人工接手設計成系統能力

客服 AI 不應假裝能處理所有事情。當找不到可靠依據、牽涉退款／法律／醫療等高影響問題、使用者要求人工協助，或偵測到安全風險時，系統應保留對話脈絡並交給合適的人員。這不是模型能力不足的掩飾，而是降低錯誤成本的產品設計。

NIST 的生成式 AI 風險管理資料指出，生成式系統可能需要額外的人類覆核、追蹤、紀錄與管理監督；其後續監測研究也把功能、營運、人因、安全與合規列為不同的監測面向。客服系統上線後，應持續抽樣覆核、記錄拒答與轉交原因、觀察知識庫更新後的漂移，而不是把上線前的一次比較當成永久結論。

常見問題

可以直接比較 GPT-4 與 Gemini 嗎？

可以把它們當作候選方案，但比較報告必須標示實際使用的模型版本、日期、提示、工具與知識來源。沒有這些條件的「誰更好」結論通常無法重現，也很快失效。

模型評審可以完全取代人工品管嗎？

不可以。自動評分適合擴大覆蓋率與找出疑似問題；人工評審仍需校準評分規則、處理爭議案例，並負責高風險決策。

上線後還需要再評估嗎？

需要。模型、提示、知識庫、客服政策與使用者問題都可能改變。每次重大變更前後都應執行回歸測試，並定期檢視實際對話的錯誤與人工接手情況。

結論：比較的是可被驗收的客服流程

好的 AI 客服評估不會產生「某模型永遠勝出」的口號，而是留下可重複的案例集、評分規則、版本紀錄、人工升級機制與監測節奏。先把這些基礎建立好，模型更替時才能安全地重新比較，也能把使用者體驗放在模型名稱之前。

參考資料與延伸閱讀

• OpenAI：Evals 指引
• Google：Responsible Generative AI Toolkit
• NIST：Generative AI Profile
• NIST：已部署 AI 系統的監測挑戰
• 站內延伸閱讀：AI 與 LLM 分類文章