【2026 最新】Voice Agent Eval 怎麼做？12 段錄音測 Barge-in、數字與 Task Success

電話裡，你說的是「不要取消」，畫面最後的逐字稿也確實顯示「不要取消」；但在文字尚未穩定時，Voice Agent 已經先把「取消」送進工具。這種系統就算字錯率很低，仍然可能做錯事。Voice Agent Eval 真正要驗收的，不只是最後聽見幾個字，而是系統何時拿到可用文字、能不能在你插話時停下來，以及最後有沒有做對動作。

這篇專為已經能串起 ASR、LLM、TTS 與工具，但第一次設計語音回歸測試的讀者寫。你會得到一套可直接改成自己資料的 12 段錄音、四個時間點、事件紀錄格式、Task Success 判分法，以及「Partial Transcript 不得觸發不可逆動作」的安全閘門。它是一份小型個人回歸套件，不是模型排行榜，也不假裝代表所有口音與場景。

如果你的 Agent 還停在文字介面，可先用 AI Agent Harness 建立「模型、工具、狀態、Trace」的共同語言，再回來把 Audio 這一層接上；想自己架 ASR／TTS API，則可搭配 NeMo Speech 本機語音 API 教學。

先說結論：Voice Agent Eval 要同時驗收三件事

一句話記住本文的核心：

可用語音 Agent ＝ 聽得對 × 停得對 × 做得對。

• 聽得對：關鍵數字、日期、人名、否定與修正，有沒有在正確時間成為可用文字。
• 停得對：使用者插話後，Agent 的聲音何時真的停止；自然停頓或「嗯哼」又會不會被誤判成搶話。
• 做得對：最終工具、參數與資料庫狀態是否符合使用者最後確認的要求，而且沒有多做一個動作。

三者是乘法，不是加分題：逐字稿再漂亮，若 Agent 沒停或工具狀態錯了，這次任務仍然失敗。Artificial Analysis 的 Speech-to-Speech 方法論也把 conversational dynamics、正確 final tool call 與最終資料狀態分開看；其 Arena 的 Task Success 會核對正確參數與是否出現非預期動作，而不是只讀最後一句回覆。

為什麼 Voice Agent Eval 不能只看 WER？

WER（Word Error Rate，字詞錯誤率）比較參考稿與辨識稿的刪除、插入、替換比例，適合回答「文字像不像」。但 Voice Agent 還需要回答另外三個問題：正確資訊何時出現、Agent 何時停止說話、工具最後改了什麼。研究者提出 Semantic Distance 的原因之一，正是逐字層面的錯誤與下游意圖、槽位是否仍可用並不總是同步；可參考原始論文 On Semantically Informed ASR Error Metrics。

例如參考句是「訂四位，星期五晚上七點」，系統可能只錯一個字，卻把「四位」變成「十位」；也可能錯了幾個語助詞，四位、日期與時間仍全對。兩者的 WER 差距未必能反映業務後果。更麻煩的是串流 ASR：AWS 的 Partial Results 文件明確顯示，尚未完成的 segment 會隨新語音到來而改寫，開啟穩定化還存在速度與準確度取捨。因此，Partial 只能當「鉛筆稿」，不能直接當成已確認的命令。

2026 年 8 月，一則討論 production voice agent 評測的 Reddit 提問把 first usable text、endpointing、partial rewrite、電話與日期等問題放在一起。社群討論能指出真實痛點，但不能替你決定門檻；下面所有案例與判分都要綁回自己的任務、風險與 Trace。

先定義四個時鐘，否則延遲數字不能比較

最簡單的作法，是讓同一個 orchestrator 以 monotonic clock（只會往前走、不受系統校時跳動影響）替錄音、ASR、Agent runtime 與播放器事件打點；若元件分散在不同主機，就要先做時鐘同步並保存誤差。每個事件都寫下 t_ms，再從同一次 run 相減。本文採以下操作定義；這是方便你落地的測法，不宣稱是全產業唯一標準：

1. First usable text：第一個已包含正確意圖、否定狀態與所有必要槽位，而且到 final 都未再被推翻的 hypothesis 時間 − 最後一個必要詞說完的時間。它必須回頭核對完整 partial 序列，不能在串流當下只看一次就宣布通過。
2. Stable-final delay：ASR final 事件時間 − 使用者實際停聲時間。要同時保存 final 文字，避免只追求快而犧牲關鍵欄位。
3. Barge-in stop latency：Agent 音訊最後一個實際輸出 sample 的時間 − 使用者開始插話時間。不要用「收到 interrupt 事件」冒充真的停聲。
4. Task Success：正確工具、正確參數、正確最終狀態，且沒有額外 final action，才記 1；其餘記 0。

「最後一個必要詞」很重要。若句子是「把週三改成週五」，系統在「週三」後就猜到改期並沒有意義；真正可執行的內容要等「週五」說完。相同道理，Barge-in 要從輸出音訊或 audio sink 找到最後一個送出的 sample，而不是只看控制程式何時把旗標設為 true。另要在 Trace 分清 segment final、整段 speech end、turn close 與 action committed；供應商標記的 final 不自動等於使用者已完成語意或動作已獲授權。

12 段錄音適合逐案看數字並算 median；樣本太小時，不要把 P95 畫成穩定的長尾結論。要判斷 production 尾端延遲，再加入更多獲得同意、完成去識別化的真實樣本與重複 trials。Artificial Analysis 的 AA-WER v2 說明刻意涵蓋多種口音與說話型態，也提醒一份資料集的結果不能自動代表你的使用者。

建立 12 段 Voice Agent Eval 錄音

每段只要完整涵蓋一個測試句，重點是每案只放一個主要失敗機制，並寫出「最後正確要求」與預期工具狀態。先用自己的聲音做 smoke test，再逐步增加不同說話者、口音、裝置與噪音。若使用他人的聲音，先確認你有收集與保存權限並留下紀錄；分享範例前移除姓名、電話、訂單與地址等個資。

A 組：精確欄位（Case 01～04）

1. 電話號碼：混入相近數字與自然分組，例如「零九一二、三四五、六七八」；答案鍵要求每一碼一致。
2. 訂單／會員編號：字母與數字交錯，測試系統能否保留前導零、大小寫規則與分隔。
3. 日期與時間：同一句包含相對日期和明確時段；答案鍵保存解析後的時區與 ISO 值。
4. 人名與地名：選擇產品真的會遇到的專有名詞，不用只對某一家 ASR 有利的單一名字。

B 組：否定與口頭修正（Case 05～07）

5. 否定詞：「不要取消訂單 7318」；若任一 partial 曾短暫只出現「取消」，工具仍必須保持未呼叫。
6. 欄位修正：「三位，不對，四位」；Task Success 只接受最後的四位。
7. 改變心意：「幫我取消……等一下，先不要取消」；測試舊意圖會不會殘留在 planner 或工具佇列。

C 組：Turn-taking 與 Barge-in（Case 08～10）

8. 句中自然停頓：刻意停 600～900ms 再把句子說完，觀察 endpointing 是否過早結束；這個停頓長度是測資設定，不是通用及格線。
9. Backchannel：Agent 說話時只回「嗯哼」或「好」，預期不中斷主要播報，也不建立新工具意圖。
10. 真正 Barge-in：Agent 說出錯誤日期時立刻插話「不是週三，是週五」，記錄插話 onset、實際停聲與修正後參數。

Full-Duplex-Bench v1.5把 user interruption、backchannel、side conversation 與 background speech 分開建模，原因很直觀：有聲音重疊，不等於使用者一定要搶走話輪。你的測組也要把「該停」和「不該停」各自做成答案鍵。

D 組：重疊與環境韌性（Case 11～12）

11. 旁人對話／重疊：目標說話者下指令時，另一人說不相關內容；預期 Agent 不把旁人的數字混進參數。
12. 噪音 × 口音 × 領域詞：讓獲得授權的不同說話者表達同一項任務，再加入咖啡店、車內或風扇噪音與產品特有名稱；保存乾淨版與劣化版，逐 slice 比較才容易歸因。

不要一次把所有困難疊在 Case 12，否則失敗後只知道「很糟」，不知道該修 VAD、ASR、turn detector、prompt 還是 tool policy。先以單一變因建立 baseline，再新增組合壓力測試。若你需要完整 Agent loop 的資料結構，可參考 30 行 AI Agent Harness 實作。

實作 Voice Agent Eval：從 Case Manifest 到四份產物

最小可維護單位不是一個 MP3，而是一個 case 資料夾。它要同時保存 Audio、Transcript、Tool Trace 與 Outcome。先建立這個結構：

voice-eval/
├── cases/01-phone/case.yaml
├── audio/01-phone.wav
├── runs/BUILD_ID/01-phone/transcript.jsonl
├── runs/BUILD_ID/01-phone/tool-trace.jsonl
└── runs/BUILD_ID/01-phone/outcome.json

若原始錄音格式不同，可先轉成單聲道 PCM WAV，避免每個供應商吃到不同編碼。以下命令只做格式正規化，不會自動對齊事件時鐘：

ffmpeg -i raw/01-phone.m4a \
  -ac 1 -ar 16000 -c:a pcm_s16le \
  audio/01-phone.wav

case.yaml 要先寫答案，後跑模型。這能避免看完結果才替喜歡的版本改規則：

id: 06-correction-party-size
audio: audio/06-correction.wav
final_request: { action: reserve, party_size: 4 }
required_slots: [action, party_size]
forbidden_before_confirmation: [reservation.create]
expected_final_tool:
  name: reservation.create
  arguments: { party_size: 4 }
expected_state: { reservation.party_size: 4 }

這裡的 YAML 是語言中立資料格式，不是可直接部署的 production policy。正式 runner 還要處理 schema 驗證、音訊裝置錯誤、timeout、重試、服務速率限制與敏感資料保存週期。測試工具全部指向 sandbox 或 mock；不要讓回歸錄音真的取消訂單、扣款或改會員資料。

事件 Trace：每一步只記一次事實

每行 JSON 記一個事件，至少包含 run_id、case_id、t_ms、event、文字或 payload，以及來源元件。完整 payload 可另外以 hash 指向加密檔案，避免把電話和地址散落在 log：

{"t_ms":0,"event":"user_audio_start"}
{"t_ms":2140,"event":"user_required_slot_end","slot":"party_size"}
{"t_ms":2310,"event":"asr_partial","text":"三位"}
{"t_ms":2780,"event":"asr_partial","text":"三位 不對 四位"}
{"t_ms":3030,"event":"asr_final","text":"三位，不對，四位"}
{"t_ms":3190,"event":"tool_proposed","name":"reservation.create","party_size":4}
{"t_ms":4010,"event":"user_confirmed","party_size":4}
{"t_ms":4080,"event":"tool_executed","party_size":4}
{"t_ms":4250,"event":"state_observed","party_size":4}

把 tool_proposed、tool_authorized、tool_executed 與 state_observed 分開。只看模型生成的 function call，會漏掉下游拒絕、重試重複執行，或 Agent 說「已完成」但資料庫沒變的情況。VAmoS的 assertion grader 會一起讀對話、工具呼叫、參數與回傳結果，用來檢查驗證順序和「說的／做的」是否一致；其論文也明列目前沒有額外查詢 post-call final state，所以本文才把 state_observed 另設一關。

安全閘門：Partial 只能寫草稿，不能做不可逆動作

把串流逐字稿想成櫃檯人員的便利貼：可以先填表、預取資料、判斷使用者是否還在說話，但不能因為半句話就按下退款或取消。本文建議把執行流程鎖成四關：

1. Partial／低穩定文字：只更新 UI 草稿、turn detector 與可丟棄的檢索預取；can_mutate_state=false。
2. Final 或符合你的穩定條件：允許建立 action proposal，但先不執行。
3. 讀回關鍵欄位：電話、金額、日期、地址、識別碼與否定狀態，用自然語句重述；修正後舊 proposal 立即失效。
4. 確認＋下游授權：使用者明確確認，工具層再檢查身分、權限、範圍、idempotency key 與目前狀態，才執行。

這不是要求所有低風險查詢都多問一次，而是依動作後果分級。查天氣可以直接回；取消、付款、改地址或傳送訊息則值得多一道確認。OWASP 的 Excessive Agency 指南建議高影響動作保留人工核准、由下游系統做授權並採最小權限。換句話說，LLM 的「我很確定」不等於它有執行權。

在 Eval 裡把下列項目設成 hard gate：Partial 觸發 state-changing tool 次數必須為 0；未確認的關鍵欄位執行次數必須為 0；額外 final action 必須為 0。這些是本教學的安全驗收政策，不是從某個語音排行榜抄來的統一及格線。若產品有更嚴格的法律或產業控制，應再加在 tool layer，而不是塞進 prompt 當唯一防線。也可把攻擊與越權案例接到 Agent Prompt Injection 防禦測試。

完整走一遍：一句修正如何變成 Task Success

以 Case 06「幫我訂三位，不對，四位」為例。使用者說完「三位」時，ASR partial 暫時是完整句，planner 也許已能提出三位的草稿；但 can_mutate_state=false，所以 Tool Trace 不能出現 tool_executed。接著「不對，四位」到來，新的 hypothesis 覆寫 party size，舊 proposal 被撤銷。

ASR final 後，Agent 說「確認預訂四位嗎？」使用者回答「對」，下游才執行 reservation.create(party_size=4)。最後 runner 讀 sandbox state：party size 是 4、沒有三位的殘留預訂、工具只執行一次，Task Success 才是 1。如果對話回答正確、資料庫卻仍是 3，仍判 0；如果先建立 3 再改成 4，也要因額外動作判 0。

這種 end-to-end 判法與 Speech Agent Arena 的工具追蹤概念相通：正確 final call 要匹配使用者最後的修正，不能只靠最後自然語言聽起來合理。要降低 Trace 的儲存與查詢成本，可延伸 LLM API 成本歸因裡的 run／trace／step 分層方法。

怎麼判讀結果：先看 Hard Gate，再看延遲

每個 build 產出一張結果矩陣，但不要用一個平均分掩蓋安全失敗。建議依序看：

1. 安全 Hard Gate：任何 partial mutation、未授權執行或額外 final action，整個 build 阻擋。
2. Task Success：逐 case 核對 tool、arguments、state；保留失敗原因，不只留總成功率。
3. 關鍵槽位：phone、date、name、negation、correction 分欄，才能看出回歸集中在哪裡。
4. 輪替行為：該停的 barge-in 有沒有停，不該停的 pause／backchannel 有沒有繼續。
5. 延遲：最後才比較 first usable、stable-final、barge-in stop；品質未過時，較快沒有交付價值。

case_id,build,task_success,critical_slots_ok,
first_usable_ms,stable_final_ms,barge_in_stop_ms,
partial_mutation_count,extra_final_action_count,
failure_owner,regression_status

failure_owner 可填 audio、vad、asr、turn、planner、tool 或 state。例如 final transcript 已正確但參數仍用舊數字，問題較可能在 planner／state；interrupt event 很快、播放器卻晚停，則先查 audio output。EVA 的 開源評測工具也會按 record 保存 assistant／user／mixed audio、transcript、audit log、events 與 metrics；你不必照搬框架，但產物邊界值得參考。

第一版門檻從「不比目前 production 壞」開始：固定相同 12 段與 runner，保存 baseline，任何 hard gate 失敗直接擋；其餘指標以逐案 delta 看回歸。若要設定絕對毫秒門檻，先從真實使用流程和使用者研究取得依據，不要把別人的硬體、網路與語言結果直接搬過來。跨模型比較時也固定地區、音訊格式、並行數、prompt、工具 schema 與 warm／cold 條件。

最常見的 5 個 Voice Agent Eval 坑

1. 只存 final transcript：你會看不到 partial 曾經改寫什麼，也無法證明工具是否過早啟動。保存每個 hypothesis 與時間。
2. 用 interrupt event 當停聲：控制訊號快，不代表聲卡 buffer 已清掉。以使用者聽得到的實際音訊為準。
3. Task Success 只看回覆文字：Agent 說「已取消」不代表 state 已改；也可能 state 正確但同時洩露不該說的資料。分開驗工具、狀態與輸出。
4. 同時更換五個元件：ASR、VAD、LLM、TTS、prompt 一起改，失敗就無法歸因。每次 build 只改一個主要變因。
5. 12 段就宣布冠軍：這套測組只能驗收你的已知任務。要做一般化結論，需要更廣的說話者、語言、場景、重複 trials 與統計設計。

每次 production incident 都回填成新 case：保存最小可重現音訊、去識別化答案鍵、修正 commit，以及「修正前 fail／修正後 pass／舊案例仍 pass」三段證據。這樣 Voice Agent Eval 才會從一次性 demo 變成真正的工程護欄。

常見問題 FAQ

Q1：有 WER，還需要 Task Success 嗎？

需要。WER 描述逐字差異，Task Success 檢查工具、參數與狀態是否真的符合最後要求；兩者回答的問題不同。

Q2：First usable text 是業界統一指標嗎？

不是統一定義。本文把它明確定義為「最後必要詞說完後，第一個包含正確意圖、否定與必要槽位的 hypothesis」，方便在同一套 runner 裡比較 build。

Q3：Partial transcript 完全不能用嗎？

可以用，但要限制權限。它適合 UI 草稿、預取與 turn detection；會改變外部狀態的工具，則等穩定文字、確認與下游授權。

Q4：所有數字都要讀回嗎？

不一定。依後果分級；金額、日期、地址、識別碼及不可逆動作優先確認，低風險查詢可採較輕流程。

Q5：Barge-in latency 從哪一刻開始算？

從使用者真正開始插話算。終點是 Agent 音訊實際停止，不是 runtime 收到 interrupt flag 的時間。

Q6：12 段錄音夠上線嗎？

不夠單獨決定上線。它是快速、可重跑的最低起點；上線前仍要加入目標使用者、裝置、口音、網路與高風險流程。

Q7：可以用真實客服錄音嗎？

先確認權利與同意。依適用政策處理錄音告知、存取、保存與刪除，公開或交給第三方前完成去識別化；初版可先用合成案例與自錄音訊。

Q8：怎麼比較兩家 Voice API 才公平？

固定輸入與下游。使用相同音訊、地區、網路條件、工具 schema、prompt、並行數和重試規則，保留各自原生設定，再同時看逐案成功與時間 Trace。

給新手的 6 個執行順序

1. 今天先錄 Case 05「不要取消」與 Case 06「三位，不對，四位」。
2. 讓 ASR 每個 partial／final 都帶同一個 monotonic 時鐘。
3. 把 Tool Trace 拆成 proposed、authorized、executed、state observed。
4. 先鎖三個安全 Hard Gate，再計算延遲。
5. 跑目前 production build 建 baseline，再只改一個主要元件。
6. 把每個新失敗加入 case manifest，形成可重跑的回歸證據。

若你希望把這套方法接進更完整的 Agent 工程流程，可從 AlphaLab AI 專區延伸到模型、Harness、記憶與安全測試；想用系統化課程建立完整能力，也可查看 AlphaLab 線上課程。