同一场面试落下两个数字——听对率 100%、送达率 33.4%。问题不在哪个数字错了,而在它们量的是不同的东西;而把口径改对之后要付的五笔代价,才是这一集真正的主题。
..._night_2026-10-06_A):听对率 100%(9/9,首次达标),送达率 33.4%。两个数字都真。数字从哪来:每场留下 assistant_ws.jsonl(WS 每帧带时间戳)、timeline.log(每 20s 探针)、room_*.html 快照、archive.json 回执、以及房间麦克风实际录音 room_mic_audit.webm。没有这套材料,就没有后面任何一次拆解。
| 指标 | 量的是 | 分母 | 阈值 |
|---|---|---|---|
| 听对率 | 耳朵 | 面试官实际说的话 | ≥ 0.8(本场 100%) |
| 送达率 | 嘴 | 我们准备的句子 | ≥ 0.6 |
| 首句落地率 | 每段答案第 1 句 | 答案段数 | 未定(C-003) |
送达率算法 = 最长公共子串覆盖率:我这句在对方记录里最长连续重合占原句多大比例,再取算术平均。
为什么用最长公共子串而不是 Dice:平台会把多句合并成整段,Dice 会被长度稀释。这个选择本身是对的,不要改;要改的只有「分母取哪些句」。
辅助口径:发言健康度(均字数 ≥10 字、≤6 字碎片 ≤30%)、回声泄漏(0 条)。三个数字的分母完全不同,本来就不该放在一起比高低。
| 口径 | 分母 | 送达率 |
|---|---|---|
| 全部注入句(诊断书采用) | 98 句 | 0.334 |
| 实际播出句 | 35 句 | 0.566 |
| 从未播出句 | 56 句 | 0.134 |
33.4 是我方截断 + 分母口径叠加出的合成假象:它诚实,但把两种完全不同的失败混在了一起。
旧推理:171 句里零分句只有 1 句 = 0.6% → 「低分是全局性的,不是尾部整段归零」→ 归因平台容量。
断点:覆盖率是连续值——被丢弃的句普遍拿 0.1~0.3 而不是 0,这个统计口径天然看不见「尾部整段归零」的结构事实。
正确做法:先分组看分布(播出 0.566 vs 未播出 0.134)。不需要更复杂的统计,只需要先分组。
用连续值指标证明「不存在分组差异」是无效证明。
apply=57541 至少对应 3 个场次,送达率各不相同:0.289 @ ..._0403_job27、0.256 @ ..._0740_job27、0.334 @ ..._night_2026-10-06_A。job_id 索引会互相覆盖。平台报告里多条候选发言从半句开始:段。首先… / 来说,项目初期… / 免再次出现类似偏差… / 取了以下步骤…。
错位证据:00:50 与 01:20 两段是同一条自我介绍的前后两截,中间被平台插入追问 → 平台按自己的时间窗切段,不认我方答案边界。
真因:平台 VAD 起录滞后。首句落地率实测 50% / 5% / 15%(三个基线场次)。
反直觉钩子:现成的「答案太长就压短」方案在这里是错的,甚至更糟——答案越短,首句占比越大,丢失比例反而更高。压短解决长度,解决不了起录滞后。
诚实不只是不改数字,还包括承认自己最想要的那条证据根本拿不到。
autobot/docs/REQUIREMENTS-DEV.md §0.1 一句话现状(91 段只播 35 段 / 分母 98 vs 35 / 6 段 filler)+ v3 修正;§1.2 C-001 / C-003 / C-007 / C-009 / C-010;§1.2.1 裁决记录(v4);§1.3 指标口径速查与三条使用纪律;README.md §9 数据资产。