語音 AI 代理（Voice Agent）在開發時最困難的不是讓它能說話，而是在複雜的企業情境中保持穩定。許多模型在簡單對話中表現優異，但一旦進入特定領域，例如處理航空公司的訂單編號或人力資源的複雜政策時，就容易崩潰。這種現象是因為不同領域對詞彙、工作流複雜度以及使用者預期的要求截然不同。
為了量化語音 AI 的真實能力，ServiceNow 推出了 EVA-Bench Data 2.0。這是一個專為企業級語音代理設計的評估基準，涵蓋了航空客戶服務（CSM）、企業 IT 服務管理（ITSM）以及醫療人力資源服務（HRSD）三大領域，包含 121 個工具與 213 個測試情境。
設計企業級評估數據的五大原則
對於開發者來說，建立一個高品質的測試集不能僅靠隨機生成，EVA-Bench 遵循了五個核心設計原則，這對想要建立自有評估集的工程師非常有參考價值。
首先是語音優先（Voice-first）。並非所有企業流程都適合語音操作，測試集僅選取現實中會透過電話處理的任務，確保情境符合真實撥電模式。
其次是真實性（Realism）。工具的定義（Schema）是模擬生產環境中的 API，而情境政策則參考實際的企業限制。例如在醫療 HR 領域，會引入美國真實的 NPI 編號（醫療人員識別碼）與 FMLA（家庭與醫療假法案）等規範。
第三是多樣性（Variety）。為了避免模型透過記憶重複模式來刷分，測試集將情境分為三類：單一意圖、多重意圖（單次對話最多四個需求），以及對抗性情境（Adversarial calls）。後者最為關鍵，它模擬使用者嘗試繞過故障排除步驟、誤報緊急程度或試圖獲取未授權紀錄的情況。
第四是身份驗證（Authentication）。經驗顯示，身份驗證是語音 AI 最常失敗的環節。因此，每個領域都內建了驗證流程，並根據任務需求配置 OTP（一次性密碼）等提升權限的機制。
最後是可複現性（Reproducibility）。為了確保評分差異來自模型能力而非隨機性，每個情境被設計為只有唯一正確的解決路徑，且必須提供明確的證據（如確認碼或案件 ID）才算完成。
利用 SyGra 實現聯合生成與驗證
為了避免數據不一致（例如使用者提到一個資料庫中不存在的訂單編號），EVA-Bench 使用了名為 SyGra 的圖形化合成數據管線，並以 GPT-5.4 作為底層模型，採取聯合生成（Joint Generation）策略。
在聯合生成模式下，系統會同時產生三個相互依賴的組件：
一個是結構化的使用者目標。它不是一段模糊的描述，而是一個決策樹（Decision Tree）。它明確定義了使用者在什麼情況下該要求什麼、何時反對、何時接受替代方案，確保模擬器每次運行時行為一致。
二是初始情境資料庫。這定義了 AI 代理在執行任務前，後端資料庫中的初始狀態，確保所有提及的 ID 和憑據真實存在。
三是預期最終狀態（Ground Truth）。系統會先用 LLM 模擬一次正確的執行路徑，將最終更新後的資料庫狀態記錄下來，作為驗證 AI 是否成功完成任務的唯一標準。
為了確保這套數據沒有漏洞，所有生成內容必須通過三層驗證：首先是 Pydantic 結構檢查（確保資料格式正確），接著是 LLM 一致性檢查（確認目標與資料庫匹配），最後是追蹤驗證（確認沒有其他替代路徑可以達成目標，避免非決定性結果）。
從單一語言邁向多語言部署
一個在英文環境表現完美的語音代理，在部署到其他語言時可能會因為語音識別（ASR）精準度下降或文化差異而失效。因此，EVA-Bench 正在擴展多語言支持。
這種擴展不僅是翻譯文字，而是進行本地化適配。例如，將地點名稱、使用者姓名、電子郵件格式以及電話號碼全部替換為目標語言國家的真實格式（如將美國電話格式改為法國格式），讓模擬器能提供原汁原味的本地化體驗。
總結與實務影響
對於工程師而言，EVA-Bench 的重要性在於它提供了一套從數據生成到驗證的完整方法論。它告訴我們，評估 AI 代理不能只看對話是否流暢，而應該關注後端狀態的正確改變、邊際案例的處理能力以及在壓力測試下的穩定性。
該數據集目前已在 Hugging Face 上開源，開發者可以直接透過 datasets 庫載入 airline、itsm 或 medical 數據集，用於測試自己的語音 AI 代理在企業複雜場景下的表現。
來源：huggingface.co (EVA-Bench Data 2.0: 3 Domains, 121 Tools, 213 Scenarios)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。