EVA-Bench: A New End-to-end Framework for Evaluating Voice Agents

Paper: arXiv:2605.13841 Code: ServiceNow/eva Code reference: main @ 66ac2d90 (2026-05-19)

1. Motivation (研究动机)

现有 voice agent 评测的核心问题不是“有没有一个分数”，而是两个评测前提同时缺失：第一，评测交互不够像真实电话任务；第二，指标没有覆盖 voice-specific failure modes。许多 benchmark 只评估静态 transcript、单轮问答、或某个组件（STT、LLM、TTS）的局部能力，因此无法回答一个端到端 voice agent 在真实多轮语音任务中是否可靠。

具体瓶颈有三类：

• 仿真层面：真实企业场景里的用户目标、persona、身份认证、工具调用、数据库状态变化、打断/沉默/延迟都影响结果。若只用静态 prompt 或人工录音片段，就无法稳定复现 agent 在 multi-turn task completion 中的行为。
• 测量层面：task completion 只看最终状态，不能发现 agent 在过程中误报政策、误读金额/确认码、过度冗长、抢话、长时间沉默等语音交互错误。论文强调，即使工具调用正确，spoken output 中一个字母/数字错了也可能让用户拿到不可用的 confirmation code。
• 架构比较层面：cascade（STT→LLM→TTS）、hybrid（AudioLLM→TTS）和 S2S（speech-to-speech）暴露的中间信号不同。若指标只依赖 transcript 或某一 pipeline 的内部日志，就会偏向某类架构，不能公平比较 audio-native 与 cascade 系统。

EVA-Bench 的目标是把“仿真”和“评分”连成一个 end-to-end benchmark：用 bot-to-bot audio conversation 自动生成多轮语音任务，再用 validation-gated simulation 排除 user simulator 自身错误，最后用 EVA-A / EVA-X / diagnostic metrics 同时衡量 accuracy、experience 与可诊断失败源。它值得研究，因为 deployment-grade voice agent 需要的不只是偶尔成功，而是在多次真实调用、噪声/口音扰动、不同企业域中稳定完成任务并保持可接受的语音体验。

2. Idea (核心思想)

核心 insight：voice agent benchmark 应该把“用户仿真质量控制”和“跨架构可比的端到端语音指标”合并，而不是只评单个组件或只评 transcript。 EVA-Bench 先让一个带 persona、goal、decision tree 和 TTS voice 的 User Simulator 通过 live audio WebSocket 与待测 agent 对话；对话结束后先过 simulator validation，失败则自动重跑；只有有效 conversation 才进入评分。

关键创新可以压缩成三点：

1. Validated bot-to-bot simulation：每个 scenario 不只是 prompt，而包含 user goal、persona、scenario database、ground truth 和 decision tree；Tool Executor 确定性执行 agent tool calls，使最终数据库状态可以精确比较。
2. 双主指标：EVA-A 衡量 task completion、faithfulness、speech fidelity；EVA-X 衡量 conversation progression、conciseness、turn-taking。它们不是简单平均，而是先对每个 component 设置 pass threshold，再用 pass@1 / pass@k / pass^k 区分平均、峰值和可靠表现。
3. 跨架构和扰动分析：同一套 213 enterprise scenarios 覆盖 Airline CSM、Healthcare HRSD、Enterprise ITSM；再用 French accent、coffee-shop background noise、二者组合等扰动，观察 cascade、hybrid、S2S 的不同失败模式。

与只看工具调用正确率的 TAU-bench-like 评测相比，EVA-Bench 增加了 audio-level speech fidelity、turn timing、spoken conciseness 和 simulator validation；与只测实时语音交互体验的 benchmark 相比，它又把最终 tool/database state 与 policy faithfulness 纳入同一评价框架。因此它更像一个 voice-agent operating envelope test，而不是单点能力测试。

3. Method (方法)

3.1 Overall framework

Figure 1 解读：整个 pipeline 分成 simulation、validation 和 quality measurement。左侧 User Simulator 带着 scenario-specific goal、persona、conversational TTS voice，通过 WebSocket 与待测 Voice Agent 进行真实音频多轮对话；Tool Executor 对 agent 的工具调用做确定性执行并更新 scenario database。中间的 Simulator Validation 用 Conversation Finished、User Behavioral Fidelity、User Speech Fidelity 检查该次仿真是否有效；失败会触发 regeneration，而不是把 simulator 错误算到 agent 头上。右侧 Quality Measurements 输出 EVA-A、EVA-X、pass@1、pass@k、pass^k 和 diagnostic metrics。

直觉上，EVA-Bench 的设计把 benchmark 中最容易混淆的两个来源分开：先判断“用户模拟是否合格”，再判断“agent 是否做得好”。 这样可以避免把 user simulator 的 premature ending、decision-tree violation、missing information 误判成 agent failure。同时，每个 scenario 有 ground-truth database state，使 task completion 能用 deterministic hash 比较；每个对话又保留 audio/log/timing，使 speech fidelity 和 turn-taking 可以被端到端评估。

3.2 Scenario 与 data design

EVA-Bench 的数据覆盖三个企业语音客服域：

Domain	Scenarios	Workflows	Tools	Avg. tool calls	Min / max tool calls	Auth tiers
Airline CSM	50	7	15	3.14	1 / 6	1
Healthcare HRSD	83	12	47	8.7	1 / 18	2
Enterprise ITSM	80	21	59	8.3	1 / 18	3

每个 scenario 包含四个核心对象：

• user goal：用户想达成的结果和约束，例如改签必须在 10pm 前、票价低于某金额。
• user persona：说话方式、耐心、个性，用来模拟不同 caller 行为。
• scenario database：agent tools 会读取和修改的数据状态。
• ground truth：任务成功后数据库应处于的状态；这也是 deterministic task completion 的比较目标。

User goal 还配有 decision tree，消除“用户到底应该怎么选”的歧义。论文有意选择高接触、适合电话解决的任务，例如 flight rebooking，而不是初次订票这类不一定需要语音 agent 的场景。许多场景要求处理 confirmation code、employee ID、姓名、日期、金额等 spoken key entities，用来触发 STT/TTS/S2S 最常见的语音错误。

3.3 Bot-to-bot multi-turn simulation

EVA-Bench 通过 fully automated bot-to-bot conversation 评估 agent。User Simulator 基于 ElevenLabs ElevenAgents：TTS model family 为 V3 Conversational，English，默认 personality disabled，first message none，interruptible disabled，输入音频为 $\mu$-law telephony 8000 Hz，最大 conversation duration 为 600 s。它接收 user goal、decision tree、persona，与 agent 通过 live audio WebSocket 交互。

待测 agent 可以是三类：

• Cascade：STT → LLM → TTS。它有明确 transcript 和 intended assistant text，因此可以区分 STT 错误、LLM policy 错误、TTS spoken-output 错误。
• Hybrid：AudioLLM 直接听 audio，再用 TTS 输出语音。它在输入侧 audio-native，输出侧仍是 text-to-speech。
• S2S：输入和输出都是 raw audio，可能同时生成 text 用于 tool call。它更少跨模态，通常 latency 更低，但一些中间信号不可见。

Controlled perturbations 包括 accent variations、background noises、connection degradation，也可以建模 personality/speaking style。主实验实际使用三种条件：French-accented user speech、coffee shop background noise、二者组合。每个扰动轴可以单独或组合施加，便于把“口音伤害 accuracy”与“噪声伤害 experience”分开分析。

3.4 Simulator validation：先过滤无效用户仿真

在计算 agent metrics 前，每次 simulated conversation 必须经过 validation：

Validation metric	Type	Scale	Pass threshold	用途
Conversation Finished	Deterministic	$\{0,1\}$	1.0	对话是否正常结束
User Behavioral Fidelity	LLM-as-Judge	$\{0,1\}$	1.0	user simulator 是否按 goal / decision tree 行事
User Speech Fidelity	LALM-as-Judge	$1$–$3$ normalized to $[0,1]$	论文表中未设统一 pass threshold	用户音频是否准确表达 intended content

论文报告，在四个代表系统、所有 domain 上，$12.0\%$ 的 trials 因 user simulator error 需要 regeneration，几乎全部来自 behavioral drift；speech fidelity 占 rerun 的比例低于 $4\%$。在完整 cost analysis 中，四个代表系统平均 $24.1\%$ trials 需要 regeneration，其中约一半是 simulator error，另一半是 infrastructure failures 或 timeouts。因此 EVA-Bench 不是把每次失败都直接打分，而是把无效 conversation 从评分入口前剔除/重跑。

3.5 EVA-A：Accuracy metrics

EVA-A 衡量“任务是否真的正确完成”。它不是单个分数平均，而是每个 component 都必须过阈值： $\text{EVA-A pass}=(\text{Task Completion}=1.0)\wedge (\text{Faithfulness}\ge 0.5)\wedge (\text{Speech Fidelity}\ge 0.95).$ 三个 component 的含义如下：

• Task Completion：deterministic binary metric。比较 scenario database final state 与 ground truth 的 SHA-256 hash；正确工具调用和参数会得到 1，任何 wrong / missing / extra changes 得到 0。
• Faithfulness：LLM-as-Judge。检查 agent actions 是否 grounded in instructions、policies、tool results、user inputs。它补足 task completion：agent 可能最终数据库正确，但过程中误报费用、违反 policy 或误导用户。注意架构适配不同：cascade 相对于 STT delivered text 评估；audio-native 的 mishearing 属于模型自身责任，因此会被计入 faithfulness。
• Speech Fidelity：LALM-as-Judge。检查 spoken audio 是否准确复现 intended text，特别关注 confirmation codes、dates、dollar amounts 等 high-stakes named entities。对 S2S 系统，由于不存在明确 intended text，指标检查 user turns 和 tool responses 中的 key entities 是否被正确说出。

3.6 EVA-X：Experience metrics

EVA-X 衡量“用户是否能顺畅完成语音交互”。pass 条件为： $\text{EVA-X pass}=(\text{Turn-Taking}\ge 0.8)\wedge (\text{Conversation Progression}\ge 0.5)\wedge (\text{Conciseness}\ge 0.5).$ 三个 component 的角色不同：

• Conversation Progression：LLM-as-Judge，检查 agent 是否避免重复、保留上下文、持续推进任务，而不是 stall 或 backtrack。
• Conciseness：LLM-as-Judge，检查 spoken response 是否足够简洁。电话用户不能像阅读文本一样 skim 或回看，过多选项/细节会造成 working-memory overload。
• Turn-Taking：timestamp-based metric。它不只看平均 latency，而是按 turn type 选择 scoring function：agent-interrupted turns 看 overlap duration、barge-in count、post-interrupt recovery latency；user-interruption turns 看 agent yield latency；uninterrupted turns 用 piecewise-linear latency curve；tool-call turns 有更宽松的 latency threshold。若 agent 对用户 turn 完全不响应，也会通过 Conversation Completion 影响此维度。

3.7 pass@1 / pass@k / pass^k：平均、峰值和可靠性

EVA-Bench 对每个 dimension（EVA-A 或 EVA-X）先得到 binary pass/fail，再报告三种 aggregate statistics： $\text{pass@1}=\frac{1}{T}{\sum }_{t=1}^{T}1[{\text{pass}}_t^{(d)}],T=Nk.$ $\text{pass@k}=\frac{1}{N}{\sum }_{i=1}^{N}1\left[{\sum }_{j=1}^{k}1[{\text{pass}}_{i,j}^{(d)}]\ge 1\right].$ ${\text{pass}}^k=\frac{1}{N}{\sum }_{i=1}^N{\hat{p}}_i^k,{\hat{p}}_i=\frac{1}{k}{\sum }_{j=1}^{k}1[{\text{pass}}_{i,j}^{(d)}].$ 直觉上，pass@1 是随机一次调用的平均成功概率；pass@k 是“同一个 scenario 试 $k$ 次至少一次成功”的 ceiling；pass^k 是“同一个 scenario 连续 $k$ 次都成功”的可靠性。论文的关键发现之一就是 pass@k 与 pass^k 差距很大，所以单次或 best-of-k 结果会显著高估 deployment-grade reliability。

3.8 Released code 对应实现与伪代码

代码搜索找到官方实现 ServiceNow/eva。检索面包括 Hugging Face paper page、title + GitHub、arXiv ID + GitHub、ServiceNow + EVA-Bench、GitHub direct probe；有效 repo 含 README、main.py、src/eva/orchestrator/、src/eva/metrics/、configs/ 等实现证据。

Code reference: main @ 66ac2d90 (2026-05-19) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
End-to-end benchmark runner	src/eva/run_benchmark.py	run_benchmark(config)
Conversation orchestration + validation/rerun loop	src/eva/orchestrator/runner.py	BenchmarkRunner.run
Per-record validation gate	src/eva/orchestrator/validation_runner.py	ValidationRunner.validate_one, run_validation
Multi-trial setting	src/eva/models/config.py	RunConfig.num_trials, max_rerun_attempts, validation_thresholds
EVA-A / EVA-X composite thresholds	src/eva/metrics/aggregation.py	EVA_COMPOSITES, compute_record_aggregates
pass@k / pass^k implementation	src/eva/utils/pass_at_k.py	compute_pass_at_k, compute_pass_power_k, compute_pass_at_k_for_scores
Deterministic task completion	src/eva/metrics/accuracy/task_completion.py	TaskCompletion
Faithfulness judge	src/eva/metrics/accuracy/faithfulness.py	FaithfulnessJudgeMetric
Audio speech fidelity	src/eva/metrics/accuracy/agent_speech_fidelity.py	AgentSpeechFidelityMetric
Experience metrics	src/eva/metrics/experience/*.py	ConversationProgressionJudgeMetric, ConcisenessJudgeMetric, TurnTakingMetric
Key-entity transcription diagnostic	src/eva/metrics/diagnostic/transcription_accuracy_key_entities.py	transcription key entity metric

代码侧的主循环可以概括为：

async def run_eva_benchmark(config, records):
    runner = BenchmarkRunner(config)
    output_ids = expand_trials(records, num_trials=config.num_trials)
 
    successful_records = []
    for output_id in output_ids:
        for attempt in range(config.max_rerun_attempts):
            result = await ConversationWorker(config).run(output_id)
 
            if not check_conversation_finished(result):
                continue
 
            validation = await ValidationRunner(...).validate_one(output_id)
            if validation.passed:
                successful_records.append(output_id)
                break
 
        # failed attempts are kept for diagnostics but excluded from full metrics
 
    metrics = await MetricsRunner(...).run(successful_records)
    return compute_run_level_aggregates(metrics, num_draws=config.num_trials)

EVA-A / EVA-X composite 的 released code 单一来源在 src/eva/metrics/aggregation.py：

EVA_A_PASS = all([
    task_completion == 1.0,
    faithfulness >= 0.5,
    agent_speech_fidelity >= 0.95,
])
 
EVA_X_PASS = all([
    conversation_progression >= 0.5,
    turn_taking >= 0.8,
    conciseness >= 0.5,
])

src/eva/utils/pass_at_k.py 中，compute_pass_at_k(n, c, k) 用 $1-\left(\genfrac{}{}{0ex}{}{n-c}{k}\right)/\left(\genfrac{}{}{0ex}{}{n}{k}\right)$ 计算至少一次通过的概率；compute_pass_power_k(n,c,k) 用 $\left(\genfrac{}{}{0ex}{}{c}{k}\right)/\left(\genfrac{}{}{0ex}{}{n}{k}\right)$ 计算无放回抽取中全通过的概率。src/eva/metrics/aggregation.py 在 run-level 同时输出 pass_power_k_observed 和 pass_power_k_theoretical=(c/n)^k；论文定义的 pass^k 对应 theoretical 解释。论文公式与 released code 实现差异：核心阈值与 component 组合未发现不一致；但 released code 同时保留 observed/theoretical 两个 pass^k 字段，读取 metrics_summary.json 时要确认使用的是与论文定义一致的 theoretical 口径。

4. Experimental Setup (实验设置)

4.1 Datasets and scale

Clean condition 覆盖全部 213 scenarios，每个 scenario $k=5$ trials。Perturbation condition 覆盖 90 scenarios（每个 domain 30 个），每个 perturbation $k=3$ trials，扰动包括 French-accented user speech、coffee shop background noise、accent + background noise。每个模型总评估样本数为： $213\times 5+90\times 3\times 3=1,875.$ 考虑 validation/rerun，四个代表系统平均 $24.1\%$ trials 需要 regeneration，因此实际 simulation/judge call 约为： $1,875\times 1.241\approx 2,327$ per system。论文还说明平均 conversation 时长约 4–5 分钟，成本来自 user simulator、待测 agent 推理以及 8 个 LLM/LALM-as-Judge metrics。

4.2 Evaluated systems

共评估 12 个系统：7 个 cascade，2 个 hybrid，3 个 S2S。

• Cascade：Cohere-transcribe + Gemma-4-26B + Voxtral-4B-TTS；Scribe-v2.2-Realtime + Gemini-3-Flash + TTS-Conversational-v3-Alpha；Ink-whisper + Haiku-4.5 + Sonic 3；Nova-3 + GPT-5.4 + Sonic 3；Nova-3 + GPT-5.4-mini + Aura-2；Parakeet-1.1 + Gemma-4-31B + Kokoro；Whisper-Large-v3 + Qwen3.5-27B + Voxtral-4B-TTS。
• Hybrid：Gemini-3-Flash + Gemini-3.1-Flash-TTS；Ultravox-Realtime。
• S2S：Gemini-3.1-Flash-Live；GPT-Realtime-1.5；GPT-Realtime-mini。

Self-hosted model configuration 来自 appendix table：Gemma-4-26B / Gemma-4-31B 用 2×H100 BF16 vLLM；Qwen3.5-27B 用 4×H100 + 8×8GB CPU BF16 vLLM；Whisper-Large-v3 用 1×H100 + 4×64GB CPU FP16 vLLM；Cohere-transcribe、Parakeet、Kokoro、Voxtral 分别有 1×H100 配置。API-hosted table 给出 GPT-5.2、GPT-5.4、GPT-5.4-mini、GPT-Realtime-1.5、GPT-Realtime-mini、Gemini-3-Flash、Gemini-3.1-Flash-Live、Gemini-3.1-Flash-TTS、Claude Opus 4.6、Haiku-4.5、Ultravox、Cartesia/Deepgram 等 provider/model IDs。

Released code 的 run config 入口是 RunConfig：domain 取 airline | itsm | medical_hr，num_trials 控制 pass@k 所需重复次数，max_rerun_attempts 默认 3，validation_thresholds 默认 conversation_valid_end=1.0 和 user_behavioral_fidelity=1.0。README 中 required environment variables 包括 OPENAI_API_KEY、EVA_MODEL_LIST、ELEVENLABS_API_KEY、STT/TTS API 参数；全指标运行还需要 Gemini/Vertex audio judge 和 Claude/Bedrock faithfulness judge 相关凭据。

4.3 Metrics and judge validation

主指标与阈值：

Category	Metric	Type	Scale	Pass threshold
EVA-A	Task Completion	Deterministic	$\{0,1\}$	1.0
EVA-A	Faithfulness	LLM-as-Judge	$1$–$3$ normalized to $[0,1]$	0.50
EVA-A	Speech Fidelity	LALM-as-Judge	$[0,1]$	0.95
EVA-X	Conciseness	LLM-as-Judge	$1$–$3$ normalized to $[0,1]$	0.50
EVA-X	Conversation Progression	LLM-as-Judge	$1$–$3$ normalized to $[0,1]$	0.50
EVA-X	Turn-Taking	Deterministic	$[0,1]$	0.80

Diagnostic metrics 包括 Authentication Success、Response Latency、Speakability、STT Word Error Rate、Tool Call Validity、Transcription Key Entities 等，不直接进入 EVA-A/EVA-X，但用于定位失败来源。

Judge validation 方面，primary judge 与 human linguist agreement 的 $\kappa$ 范围为 0.777–0.845：Faithfulness 0.836，Conversation Progression 0.845，Conciseness 0.823，Speech Fidelity 0.777。论文将这作为 judge 至少接近 human annotator consistency 的证据。

5. Experimental Results (实验结果)

5.1 Main accuracy/experience results

Figure 2 解读：左图是 pass@1，右图是 pass^k。pass@1 上 Pareto frontier 有四个系统，来自两个区域：两个 S2S（Gemini-3.1-Flash-Live、GPT-Realtime-1.5）和两个 cascade（Scribe + Gemini + Conversational、Nova + GPT + Sonic）。但到 pass^k 可靠性视角时，frontier 只剩两个 S2S，说明“某次能成功”与“多次都稳定成功”不是同一件事。

Architecture	System	EVA-A pass@1	EVA-A pass^k	EVA-X pass@1	EVA-X pass^k
Cascade	Cohere + Gemma-4-26B + Voxtral	0.207 ±0.041	0.060 ±0.028	0.209 ±0.027	0.015 ±0.011
Cascade	Scribe + Gemini-3-Flash + Conversational v3	0.490 ±0.052	0.269 ±0.055	0.024 ±0.018	0.004 ±0.006
Cascade	Ink-whisper + Haiku-4.5 + Sonic 3	0.234 ±0.041	0.057 ±0.028	0.009 ±0.006	0.000 ±0.000
Cascade	Nova-3 + GPT-5.4 + Sonic 3	0.504 ±0.044	0.217 ±0.048	0.007 ±0.006	0.000 ±0.000
Cascade	Nova-3 + GPT-5.4-mini + Aura-2	0.210 ±0.045	0.062 ±0.032	0.113 ±0.023	0.005 ±0.004
Cascade	Parakeet-1.1 + Gemma-4-31B + Kokoro	0.403 ±0.045	0.169 ±0.046	0.010 ±0.009	0.000 ±0.000
Cascade	Whisper + Qwen3.5-27B + Voxtral	0.205 ±0.033	0.033 ±0.019	0.273 ±0.034	0.051 ±0.021
Hybrid	Gemini-3-Flash + Gemini-3.1-Flash-TTS	0.431 ±0.047	0.158 ±0.043	0.000 ±0.000	0.000 ±0.000
Hybrid	Ultravox-Realtime	0.270 ±0.047	0.108 ±0.037	0.029 ±0.020	0.006 ±0.007
S2S	Gemini-3.1-Flash-Live	0.292 ±0.048	0.132 ±0.043	0.589 ±0.035	0.240 ±0.045
S2S	GPT-Realtime-1.5	0.467 ±0.052	0.283 ±0.056	0.566 ±0.039	0.216 ±0.040
S2S	GPT-Realtime-mini	0.163 ±0.041	0.059 ±0.030	0.406 ±0.036	0.099 ±0.032

最重要的结果是：没有系统在 EVA-A pass@1 和 EVA-X pass@1 上同时超过 0.5；只有 GPT-Realtime-1.5 在两个维度上同时超过 0.4（0.47, 0.57）。EVA-X 的架构差异几乎完全由 Turn-Taking 驱动：cascade mean turn-taking 为 0.28–0.58，S2S 为 0.82–0.83；Conciseness 和 Conversation Progression 没有同样强的架构分层。两个 hybrid 的 EVA-X pass@1（0.000, 0.029）仍落在 cascade 范围内，说明 hybrid 不一定自动继承 fully S2S 的 latency 优势。

5.2 Cascade accuracy–experience trade-off

Figure 3 解读：该图按 pipeline type 汇总四类 facets，显示 S2S 在 turn-taking / conversation completion 上有清晰优势，而 cascade 在某些 accuracy-related 维度上仍有强项。论文指出，accuracy 最好的三个 cascade（Nova + GPT + Sonic、Scribe + Gemini + Conversational、Parakeet + Gemma + Kokoro）在 experience 上表现差，tool-call turn latency 均超过 5 s；experience 较好的两个 cascade（Whisper + Qwen + Voxtral、Cohere + Gemma + Voxtral）tool-call latency 低于 2.7 s，但 accuracy 较低。没有 cascade 在两个维度上同时超过 0.25。

5.3 Consistency: pass@k 高估 reliable capability

Across 12 systems，peak performance（pass@k）显著高于 reliable performance（pass^k）：median gap 为 EVA-A 0.44、EVA-X 0.24。即便 strongest systems，在“同一 scenario 五次全过”的 pass^k 解释下也远低于 peak。这说明用单次 trial 或 best-of-k 评测会系统性高估 voice agent 的部署可靠性。

Figure 4 解读：appendix 的 trial-count analysis 显示，模型级估计的 95% CI width 随 $k$ 约按 $k^{-1/2}$ 下降。subsample stability summary 中，EVA-A pass@1 的 median 95% CI width 从 $k=1$ 的 0.085 降到 $k=4$ 的 0.020，EVA-X pass@1 从 0.052 降到 0.013；$k=3$ subsamples 落在 $k=5$ anchor ±0.02 内的比例分别为 97.6% 和 99.6%。这支持论文选择 clean condition $k=5$ 的稳定性。

5.4 Robustness under accent and noise

Figure 5 解读：Turn-Taking 是最 perturbation-sensitive 的 metric，论文报告跨 perturbations 和 systems 有 81% measurements 出现显著 degradation。图中不同颜色对应 accent、background noise、accent + background noise；负值越大表示扰动相对 clean baseline 伤害越大。

Figure 6a 解读：EVA-A 在 cascade 上更容易被口音/噪声伤害。accented speech 使 cascade task completion 平均下降 10 points，worst system 下降 17 points；S2S 没有显著 accuracy degradation（0/27 model-metric pairs）。combined condition 下 cascade task completion 平均下降 19 points，worst systems 下降 31 points，而 S2S mean 仍在 5 points 内。

Figure 6b 解读：EVA-X 的扰动伤害在 S2S 上更明显，尤其 background noise 导致 S2S experience failure，论文给出 EVA-X 平均 $\bar{\Delta }=-0.16$。这与 EVA-A 的模式相反，说明 audio-native 的低 latency 优势不等于对环境噪声的 experience robustness。

Figure 6c 解读：Conversation Progression 的扰动结果补充了 EVA-X 的原因分解。它显示 background noise 和 combined condition 不只是让 agent 变慢，也可能让对话推进质量下降，例如重复、遗漏上下文或没有顺畅导向任务解决；这与 turn-taking 一起构成 experience degradation。

Figure 6d 解读：Task Completion 直接反映最终工具/数据库状态。表格结果显示 accent + background noise 条件下，Nova-3 + GPT-5.4 + Sonic 3 的 TaskComp 下降 $-0.314^{\ast \ast \ast }$，Nova-3 + GPT-5.4-mini + Aura-2 下降 $-0.313^{\ast \ast \ast }$，Whisper + Qwen + Voxtral 下降 $-0.228^{\ast \ast \ast }$。

Figure 6e 解读：该图只针对 cascade transcription key entities。它说明一些 accuracy drop 不是 LLM reasoning 本身，而是 key entity transcription bottleneck：confirmation code、employee ID、日期或金额一旦听错，后续工具调用即使流程正确也会失败。

5.5 Failure mode analysis

Figure 7 解读：七个 cascade systems 的 key entity transcription accuracy 与 task completion 强相关，Pearson $r=0.93$、$p=0.002$；每个 domain 内也成立，$r=0.88$–$0.93$，all $p<0.01$。低于 70% key-entity transcription accuracy 的 cascade systems task completion rate 比高于该阈值的系统低 39%（0.37 vs 0.60），分 domain drop 为 ITSM -41%、HR -41%、CSM -34%。这说明 WER 以外的 semantic key-entity metric 对 voice agent 评测非常关键。

Figure 8 解读：HR domain 中 employee IDs、names、medical/leave-related entities 更容易暴露 STT 的 domain-specific 错误。该类错误通常不会让 transcript 全局 WER 看起来很差，却足以导致 authentication、eligibility 或 case update 工具调用失败。

Faithfulness 与 task completion 也明显解耦：在 task completion = 1 的 conversations 中，$72.2\%$（$n=12,780$）仍有至少一个 faithfulness deviation（faithfulness < 1.0）；反过来，$50.5\%$ 的 faithfulness deviations 与 task completion = 0 同时出现。这证明“最终数据库状态正确”并不代表 agent 没有违反政策或误导用户。

5.6 Threshold sensitivity and scenario examples

Figure 9 解读：该图分析 EVA-X pass@1 对 turn-taking pass-threshold ${\tau }_{tt}$ 的敏感性。因为 EVA-X 是 component-wise all-pass，turn-taking 阈值越严格，对 S2S/cascade 的相对差距影响越大。论文把 turn-taking threshold 设为 0.80，强调这是 voice experience 的最低可接受门槛，而不是平均 latency 的任意切分。

Figure 10 解读：示例展示一个完整 scenario 的数据结构与评价链路：用户目标、领域数据库、工具调用结果、对话过程和最终 metric 判断被连接在一起。这个示例有助于理解为什么 EVA-Bench 需要 decision tree 和 ground truth：它们让 simulator 的选择可重复，也让 agent 的数据库修改可判定。

5.7 Limitations

论文明确指出几类限制：

• Simulator external validity：EVA-Bench 假设 validated bot-to-bot simulation 可以近似真实人类 caller。如果 simulator 在处理 ambiguity、frustration、misunderstanding recovery 等方面系统性不同于真实用户，分数可能不能完全迁移到生产环境。
• Audio/timing artifacts：PCM-to-$\mu$-law conversion 会带来音频质量下降；bot-to-bot audio interface timing 不一定等同真实部署；不同系统的 VAD events、timestamps 和 log reconciliation 也可能影响 response speed 数值。
• 成本和可复现性：full reproduction 需要商业模型 API；$k=5$ validated trials、213 scenarios、12 systems 加上 judge calls 成本不低。
• 系统范围：EVA-Bench 当前评估 single-agent configurations，agent 直接访问 flat tool list；更复杂的 multi-agent workflow、human handoff、long-term memory 或真实 call-center integration 不在本文主实验范围内。