人工抽听，贵且慢
抽听成本随话务规模线性上升，全量覆盖几乎不可能；问题发现滞后，难以支撑快速迭代。
美团 AI Hackathon 2026 · 命题二决赛作品 · 团队「降临派」
让外呼模型敢上线，
让每次迭代有证据。
EvalCall 自动测试并评估外呼模型在特定任务指令下的指令遵循效果，输出可审计的模型上线报告——门禁结论、履约率、P0 红线、覆盖率与逐条对话证据。
- 被评对象外呼模型
- SOP评分依据
- 用户模拟器测试工具
- 对话日志过程数据
0%
裁判校准准确率
32 例 / 165 已知真值全量校准
32 例 / 165 已知真值全量校准
0处
官方指令缺陷自主检出
含字数上限与参考话术的物理冲突
含字数上限与参考话术的物理冲突
0/10 → 0/10
P0 触发 · 同尺回归
门禁「打回」→「可上线」
门禁「打回」→「可上线」
0+
自动化测试全绿
编译 / 判定 / 报告 / 归因 / 工作台
编译 / 判定 / 报告 / 归因 / 工作台
01 / 为什么需要 EvalCall
「会说话」不等于「能完成任务」。
低分背后的责任，必须分清。
履约数字人每天产生海量外呼。任务指令包含复杂流程分支与多重合规约束——漏掉一句必要告知、错误承诺一次结果，模型就无法上线。而传统质检手段各有死角：
标准因人而异
评分依赖个人经验，同一通电话两个质检员两个结论；历史日志覆盖有限，拒绝、打断、质疑等高风险场景难以主动触达。
平均分会撒谎
隐私泄露、违规承诺是低频高危的 P0 红线，平均分完全掩盖；只输出总分无法支撑上线决策。
低分 ≠ 模型差
分数低可能是模型没守指令、SOP 自相矛盾、裁判误判、测试数据未覆盖——四类混杂。错误归因会让人修改错误的对象。
EvalCall 的回答：一套能主动测试、统一判断、准确归因、同尺回归的自动评测流程。
02 / 产品主流程
六步，从「怎么测」
到「能不能上线、该改什么」。
前三步解决「怎么测」，第四步回答「能不能上线」（核心交付终点），后两步回答「为什么失败、下一步改什么」。全程留痕：SOP、对话、Checklist、模型与结果均落盘版本与哈希。
-
配置测试任务
统一封装被测模型、SOP、Persona 与测试批次，生成版本哈希——不同版本公平可比、可复现。
输入 SOP · 被测模型 / 已有对话 -
建立评分标准
自然语言 SOP 编译为可执行的 L0 安全红线 + L1 业务检查点，每项保留类型、严重度与原文出处。
输出 21 项可溯源 Checklist -
测试外呼模型
用户模拟器按 Persona 生成拒绝、打断、质疑、追问等对话，追踪检查点覆盖率；或直接评估已有日志。
输出 transcripts · 覆盖信号 -
输出模型评测报告
逐项判定引用对话证据，程序汇总门禁、履约率、P0、关键失败与覆盖率——从「不能上线」一路下钻到「哪一通、哪条规则、哪句话」。
输出 门禁结论 + 证据化报告 -
分析失败原因
综合模型表现、SOP 体检、裁判 NA/分歧与测试分布，归因到模型 / SOP / 裁判 / 测试数据四类根因。
输出 根因候选 + 置信度 -
优化与同尺回归
只修改首要责任对象，其余哈希锁定，返回对应步骤复测——提升必须可归因，不能靠偷偷换尺子。
输出 回归计划 + 版本对比
模拟测试模式
用户模拟器主动生成多轮测试对话，上线前系统性补齐边界场景。
已有日志质检模式
导入 JSONL / JSON / CSV / TXT / Markdown 对话，同一套评分标准直接质检历史与生产日志。
03 / 凭什么信它
别人交打分器，
EvalCall 交一套能证明自己可信的评测基础设施。
做一个自动评测器不是难点——难的是凭什么信它：裁判自己会误判，谁来评评测系统？模型分低，是指令写得自相矛盾还是模型真差？答案是三层质量闭环，每层都在官方脱敏数据上实测落地。
评模型
模型守不守指令？
- 指令编译SOP → 结构化检查点，每条可溯源
- 对抗模拟6 类 Persona × 多策略，定向诱导违规
- 双轨判定规则轨产线索 + LLM 轨证据判定，3 票多数决
- 量化报告四维画像 / 热力图 / 逐检查点证据引用
审指令
分低是模型差，还是指令有病？
- 指令体检器自动检测自相矛盾 / 不可行 / 歧义 / 缺失分支
- 修订建议每个缺陷附可直接照改的修改方向
- 可行性分确定性公式计算，可复现
校裁判
裁判自己判得准不准？
- 已知答案注入人工构造真值对话，跑完整裁判流程
- 误差棒上报告查准率 / 查全率 / 混淆矩阵印在评测报告上
- 盲标 held-out标注链与调优链隔离，独立验证泛化
04 / 实证战绩
每个数字，
都能在仓库 runs/ 下逐一复核。
主演示「配送时间改约」：同一 SOP、同一 21 项 Checklist、同一批 10 通用户输入、同一 Judge 下，只替换被测模型策略——这就是同尺回归。
主演示 · 同尺回归：v1 → v2
| 指标 | baseline-v1 | guarded-v2 | 变化 |
|---|---|---|---|
| 上线门禁 | 打回 | 可上线 | ▲ 门禁翻绿 |
| P0 触发 | 3 / 10 通 | 0 / 10 通 | ▲ 红线清零 |
| 平均分 | 62.5 | 91.4 | ▲ +28.9 |
| 履约率 | 40.0% | 40.0% | — 持平（如实展示） |
| 通话打回 | 3 / 10 | 0 / 10 | ▲ 全部放行 |
原生 diff 同时显示 6 项改善与 1 项 style 退化（标记待复测）——成熟评测不只展示好消息。履约率持平说明：安全性改善不等于业务能力完全优化，仍需继续迭代。产物：runs/t02_delivery_fixedusers_regression_20260714/comparison.json
低延迟直播升级：系统不会什么都怪模型
10 通中 9 通打回、履约率仅 10%。但指令体检发现 SOP 可行性 0/100、4 项高严重度问题——首要根因判定为 instruction（高置信），模型归因降级。
→ 动作：先由业务方修 SOP，回到第 2 步重建评分尺；新旧尺不直接比较模型能力。
能力榜单 ≠ 指令遵循
同任务同尺下，小模型约束遵循 100% 反超大模型 66.7%——强字数约束的外呼场景里，大模型信息越丰富越易超限。
→ 外呼模型选型必须用任务指令实测，不能按通用能力榜单挑最大的。
92.73%整体准确率（165 真值）
calibration_32case_gpt56sol_xhigh_v1.json
11/11P0 fail 全检出
质检底线守住
质检底线守住
94.7%盲标 held-out 独立集
20 个违规零漏判
20 个违规零漏判
70%style 类准确率
短板原样披露
短板原样披露
05 / 产品界面
可操作的工作台，
不是录屏。
六步流程每个节点可点击展开：上游 / 下游、承担任务、底层执行逻辑与本次运行痕迹。以下均为真实运行截图。
06 / 诚实边界
可信的另一半，
是如实说出做不到什么。
缓存与实时，明确分标
内置样例复用已验收的正式产物，页面标注「已验证结果」；自定义材料走实时后端——不把回放伪装成重新推理。
同源考题上界
裁判校准的真值由作者标注、判定准则与考题同源迭代，92.73% 应理解为同源上界；盲标 held-out 仅是初步缓解，生产前需人类标注一致率与异构裁判。
归因不是因果证明
根因归因是确定性信号归纳，低中置信结论必须人工复核后才修改生产配置。
样例规模声明
10 通 / 165 真值是验证方法与产品闭环的规模，不代表生产话务分布；上线需扩样、报告置信区间与覆盖盲区。
亲自验证，而不是听介绍
打开工作台，
六步走一遍。
本地运行
python3 -m evalcall demo # → http://127.0.0.1:8765/