EVA-Bench Data 2.0 深度解读：三大领域、121 个工具与 213 个场景的语音智能体评估基准

背景

语音智能体（Voice Agents）在企业级应用中的表现往往呈现出高度的领域特异性。一个在处理航班重新预订交易中的字母数字确认码时表现完美的系统，可能在处理人力资源（HR）系统中的复杂政策时显得捉襟见肘。不同的业务领域测试的是智能体适应不同词汇表、工作流复杂度和用户期望的能力。

为了更全面地评估语音智能体的能力，EVA-Bench 从最初的一个企业领域扩展到了三个核心领域：航空客户服务管理（CSM）、企业 IT 服务管理（ITSM）以及医疗保健人力资源服务交付（HRSD）。这一扩展使得评估场景覆盖了 121 个工具下的 213 个场景，场景覆盖率较初版发布时增加了约 4 倍。

此次发布的所有场景均经过验证，确保其针对三个前沿模型（OpenAI GPT-5.4、Google Gemini 3.1 Pro 和 Anthropic Claude Opus 4.6）具有可解性，从而保证基准测试既具有挑战性又公平合理。所有三个数据集均为开源，可供下载和使用。

核心内容

EVA-Bench 旨在服务于多重受众。对于评估语音智能体的团队，它提供了一套跨越 35 种不同工作流的真实企业场景；对于希望构建自有评估数据集的团队，本文详细描述了端到端的生成和验证流程，可作为实践参考。

数据设计原则

EVA-Bench 数据集的设计遵循五大核心原则，贯穿所有三个领域：

1. 语音优先范围（Voice-first scope）：并非所有企业工作流都适合放入语音基准测试中。设计团队首先识别出每个领域中实际通过电话处理的任务，然后从该子集中选择最常见的流程。这确保了场景植根于真实的呼叫模式。
2. 真实性（Realism）：工具模式（Tool schemas）模拟了生产平台使用的 API 类型，场景政策则源自实际的企业约束。以医疗保健 HRSD 领域为例，场景基于实际的美国医疗政策和行政系统，包括 NPI 号码、FMLA（家庭医疗休假法）和保险覆盖范围，使基准测试反映从业者现实生活中遇到的领域状况。
3. 多样性（Variety）：简单地重复相同任务无法提供足够的评估信号。为此，我们定义了每个领域的特定工作流，并采样了三种场景类型：
   • 单意图呼叫（Single-intent calls）；
   • 多意图呼叫（Multi-intent calls），单次对话中最多包含四个意图；
   • 对抗性呼叫（Adversarial calls），呼叫者试图绕过故障排除步骤、错误分类紧急程度或访问无权查看的记录。
   • 此外，在单意图和多意图场景中，还包含了用户目标无法实现的情况。因为现实中的呼叫量并非全是“顺境”，且经验表明，模型在处理无法实现的目标时往往比在处理成功交互时更加吃力。
4. 身份验证（Authentication）：先前的研究（EVA-Bench 和 τ-Voice）已确定身份验证是语音智能体最一致的失败点之一。EVA-Bench 的每个领域都包含身份验证流程，且具体机制根据任务进行校准。例如，基于 OTP（一次性密码）的权限提升仅在实际生产系统要求的地方出现，而非在所有场景中统一应用。
5. 可复现性（Reproducibility）：如果没有可复现的场景，很难判断分数差异是反映了真正的能力差距，还是场景执行方式的 artifacts。数据集设计确保每个场景都有且仅有一条正确的解决路径。用户目标的构建确保模拟器始终拥有所需的信息和指令以保持一致的行为，场景生成过程显式检查并消除任何可能导致非确定性的多条有效动作序列。

场景生成流程

场景使用 SyGra（一种基于图的合成数据生成管道）生成，以 GPT-5.4 作为骨干模型。每个场景需要三个共同一致的组件，这些组件是联合生成的，以防止独立生产组件时出现的不一致性：

1. 用户目标（User goal）：

   • 可复现性要求用户模拟器在每次运行场景时行为一致。模糊的意图陈述无法实现这一点，因为模拟器在不同运行中会做出不同的判断，产生不一致的评估信号。
   • 为此，用户目标被结构化为决策树，涵盖模拟器可能遇到的每种情况。
   • 用户目标明确规定用户应请求的内容，以及谈判序列，指定何时坚持己见、何时寻求替代方案、何时接受。
   • 常见的边缘情况（如是否接受候补航班或替代机场）通过显式指令处理，而非留给模拟器解释。
   • 解决条件要求提供已完成动作的证据（如确认号或案例 ID），而非口头承诺，以确保模拟器在动作实际确认前保持在通话中。
   • 结果是一个行为一致、真实的呼叫者，而非即兴发挥的用户。

2. 初始场景数据库（Initial scenario database）：

   • 这是智能体工具在场景执行期间将查询和修改的后端状态。
   • 与用户目标联合生成，以确保用户目标中引用的每个实体（如预订 ID、账户详情和身份验证凭据）在数据库中均存在且一致。

3. 预期最终数据库状态（Ground Truth）：

   • 通过将生成 LLM 应用于智能体指令、用户目标和初始场景数据库来推导预期结果，生成完整的动作轨迹。
   • 随着 LLM 执行写工具调用，数据库会逐步更新， resulting terminal state（最终状态）成为验证器在评估过程中检查的基准真相。

联合生成的必要性：这三个组件深度相互依赖。独立生成会引入静默不一致性（例如，用户目标中引用的案例 ID 在场景数据库中不存在），这将完全破坏评估信号。为了强制执行一致性，我们在每次生成尝试后运行多阶段验证循环，并将任何失败反馈给生成步骤，直到所有检查通过。

验证步骤：

• 结构检查：根据 Pydantic 模式验证场景数据库，捕获类型错误和缺失字段。
• LLM 验证器：更全面地检查场景的一致性：用户目标中的面向用户细节是否与数据库记录匹配，交叉引用是否在内部有效，以及身份验证数据是否正确配置。
• LLM 轨迹验证：检查完整的对话轨迹是否符合政策、动作序列是否正确、所有必需的终端动作是否完成，以及是否存在会引入非确定性的替代写入路径。

进一步验证

在 SyGra 生成之后，所有场景都经过了多轮人工审查。审查者验证了：

1. 政策在领域内的场景中应用一致；
2. 用户目标足够具体，只能容纳一个正确的解决方案；
3. 预期最终状态（Ground Truth）准确反映了智能体在遵循指令和策略时应达到的结果。

关键要点

• 领域扩展：EVA-Bench 从单一领域扩展至航空 CSM、企业 ITSM 和医疗 HRSD 三大领域，覆盖 213 个场景和 121 个工具，场景覆盖率提升约 4 倍。
• 前沿模型验证：所有场景均针对 OpenAI GPT-5.4、Google Gemini 3.1 Pro 和 Anthropic Claude Opus 4.6 进行了可解性验证，确保基准的公平性与挑战性。
• 五大设计原则：
  • 语音优先：聚焦实际电话处理的任务。
  • 真实性：模拟生产级 API 和企业政策约束。
  • 多样性：涵盖单意图、多意图及对抗性场景，包括不可实现的目标。
  • 身份验证：根据任务需求校准身份验证机制。
  • 可复现性：确保每个场景有且仅有一条正确解决路径。
• SyGra 联合生成：使用 SyGra 管道和 GPT-5.4 联合生成用户目标、初始数据库和预期最终状态，通过多阶段验证（结构检查、LLM 一致性检查、LLM 轨迹验证）确保数据一致性。
• 用户目标结构化：将用户目标构建为决策树，明确谈判序列和边缘情况处理，确保模拟器行为一致。