擴大規模前的語音代理評估檢查清單

將成功定義為經過驗證的業務成果。以預約流程為例，檢查是否記錄了正確的時間、服務和來電者資料，以及口頭確認是否與該紀錄一致。對話流暢或逐字稿不是空的，都不足以證明任務已完成。

將接通、對話品質和任務完成分開看待。電信業者拒絕與聽錯名字是不同的失敗，而這兩者又與預約 API 回傳錯誤不同。記錄失敗類別，讓修正能針對正確的層面。

依照您預期要處理的任務和語言建立測試集。盡可能使用同意參與的測試者和合成的資料。為提示詞和情境說明做版本管理，以便在更換引擎或整合後重複相同的評估。

以下案例可作為初始的檢查清單。它們是建議的測試，並非宣稱每個引擎都能通過。請加入對您應用程式重要的來電者行為和失敗情況。

• 一個預期結果明確的簡單請求。
• 在對話中途更正姓名、電話號碼或預約時間。
• 在代理說話時插話，接著提出不同的請求。
• 背景噪音、靜默、不熟悉的口音，以及每一種支援的目標語言。
• 知識庫以外的問題，以及代理不被允許處理的請求。
• 後端無法使用、重複的事件，以及來電者在完成前掛斷。
• 要求轉接真人，並依照您應用程式實際實作的轉接行為進行測試。

記錄情境、引擎和提示詞版本、通話識別碼、接通結果、任務結果、時長和成本。由審查者檢查背後的業務紀錄，而不是讓同一個代理為自己的答案評分。

關於回應速度，請定義您衡量的區間，例如從來電者說完話到代理開始發出聲音。報告其分布、樣本數和測試條件。不要把一次快速的展示當成普遍的延遲保證。

• 任務完成率 = 經驗證的完成數 / 該任務評估的對話數。
• 接通率 = 接通的通話數 / 嘗試撥打的通話數，另外單獨報告。
• 每項完成的成本 = 所有試行支出 / 經驗證的完成數；完成數為零時報告為未定義。
• 另外記錄嚴重錯誤，以免平均值掩蓋了錯誤的預約或捏造的答案。

讀取通話紀錄的狀態、逐字稿和 cost_micros。通話未接通時，先檢查 failure_code 和 failure_reason，再修改提示詞。將費用與用量事件核對。若通話已完成但您的應用程式沒有更新，請檢查 webhook 的傳送紀錄。

發起通話時使用冪等金鑰，這樣重試請求就不會產生第二次撥號。測試您自己的事件處理程式能否應付重複傳送，並驗證其儲存的結果。在試行擴大之前，就應在整合中加入驗證和 webhook 簽章檢查。

當您預先定義的驗收標準已達成、嚴重失敗都有負責人，且維運流程已經過測試時，再擴大規模。依照您使用情境的風險和價值選擇門檻；沒有任何一個完成率能讓所有語音工作流程都準備就緒。

以受控的幅度逐步增加流量，檢查失敗的通話，並將實際支出與預算比較。為提示詞和模型的變更保留回復路徑。若要發布案例研究，請連同方法和限制一起分享實測結果。

本資源由 Wixzel Voice 發布。產品細節取自以下參考資料；評估建議是一種提議的方法，並非基準測試結果。

• 通話錯誤與失敗代碼
• Webhook 傳送與驗證
• 以冪等性安全重試

發現錯誤嗎？傳送更正。