结论先行：你们扯皮的根因不是"指标选得不对"，而是"决策规则没有前置注册"。 研发和业务方在看完结果之后才争论"算不算好"，这就是典型的 post-hoc rationalization。解法不是再加一个指标，而是在跑评测之前就把"什么算过、什么算不过、看哪个数"写成一页纸的 Decision Rule，双方签字确认，之后只执行不讨论。
下面从指标体系搭建的角度，给三个你们现在缺的环节：
一、先定"最小可感知差异"（MDE），再定样本量
研发说"准确率 90%"，业务方觉得"没变好"——本质是双方对"多大幅度算变好"没有共识。
做法：在评测集构建之前，拉业务方一起回答一个问题：
"如果这个功能从 80% 提升到 ___%，你觉得用户能感知到？低于这个值，上线就没意义。"
这个值就是你的 Minimum Detectable Effect (MDE)。比如业务方说"至少要到 90% 才值得上"，那你的 MDE = 10 个百分点。
有了 MDE，用二项分布的样本量公式反推你至少需要多少条评测样本：
n = (Z_α + Z_β)² × p(1-p) / MDE²
取 α=0.05（单侧），β=0.10（power 90%），p=0.85（预估基线）：
- MDE = 10pp → n ≈ 156 条
- MDE = 5pp → n ≈ 624 条
- MDE = 3pp → n ≈ 1751 条
落到实操：你的黄金集 50~150 条，如果 MDE 定在 10pp 是够的；如果业务方坚持"提升 5% 也要感知到"，那 100 条根本不够，你看到的波动全是噪声。
给业务方看的一句话：「我们 100 条样本能检测到的最小差异是 10 个百分点。如果你需要检测 5 个百分点的差异，评测集至少需要 600 条。你觉得 5% 的差异对用户有意义吗？」——这个问题一抛，大部分"感觉没变好"的争论就消了，因为双方对齐了感知粒度。
二、用置信区间替代点估计，给"90%"加上"有多确定"
研发报"准确率 90%（90/100）"，这个 90% 的 95% 置信区间是 [82.1%, 95.0%]（Clopper-Pearson 精确区间）。也就是说，真实准确率可能只有 82%。
业务方报"我们体感是 75%"，这背后可能是 5 个 case 里 4 个还行，置信区间是 [44%, 94%]——两个区间重叠，统计上根本无法区分。
做法：每次报指标时强制带置信区间。验收规则写成：
"新版在黄金集上的准确率 95% CI 下界 ≥ 85%（即我们 95% 确信真实准确率不低于 85%），且下界高于旧版点估计，才算达标。"
这样研发不能拿"均值 90%"来糊弄（CI 下界可能只有 82%），业务方也不能拿"我试了 3 条有 1 条不好"来否决（n=3 的 CI 宽到没意义）。
三、Decision Rule 模板（贴进验收文档，签字后执行）
【LLM 功能验收 Decision Rule — 版本 ___，日期 ___】
1. 评测集：黄金集 N=___ 条（冻结，不可改）
2. 主指标：___（如"无事实错误率"），二值判定
3. MDE：提升 ≥ ___pp 才算有效（业务方确认：□ 是）
4. 达标条件（全部满足）：
□ 新版主指标 95%CI 下界 ≥ ___%
□ 新版在对抗集上的主指标 ≥ 旧版点估计（不劣化）
□ 灰度 ___% 流量 × ___ 天，出口指标（任务完成率/二次交互率）
的 95%CI 不交叉旧版
5. 不达标处理：
□ 主指标 CI 下界 < 目标 → 打回，附具体失败 case 清单
□ 对抗集劣化 → 打回，附劣化幅度
□ 灰度出口指标 CI 交叉 → 延长灰度至 ___ 天重判
6. 双方签字：研发 ___ 业务 ___ PM ___
关键纪律：Decision Rule 必须在跑评测之前定完。看完结果再改标准 = 作弊。如果第一版标准不合理（比如 MDE 定太严导致永远过不了），可以走变更流程，但必须记录变更原因，不能"静默调参"。
四、踩坑补充（和已有回答不重复的）
- "平均评分 4.2/5"是最大的谎言：10 条里 8 条 5 分、2 条 1 分，均值 4.2，但那 2 条 1 分可能是"严重幻觉导致用户做出错误决策"。永远要看分布（P50/P90/P99），不要只看均值。
- "通过率 95%"可能是幸存者偏差：如果 5% 的失败 case 全是"涉及金额计算"的，那这 5% 的严重度是 95% 里那 5% 的 100 倍。按业务影响加权，不要按条数加权。
- 评测集一旦冻结就不能"补几条"：研发发现某类 case 没过，偷偷在黄金集里加 2 条同类——这等于改了题目再考试。新增 case 必须走"对抗集扩容"流程，且扩容后旧版也要重跑。
一句话总结：不要问"效果好不好"，要问"按我们事先约定的 Decision Rule，数字过没过线"。把"感觉"从验收环节里彻底移除，换成置信区间 + 预设阈值 + 签字确认。
从性能测试的角度看，这篇 Decision Rule 的框架和我做过的事几乎同构——当年我们给一个支付网关定 SLO 时，研发说"P99 从 200ms 降到 180ms，提升了 10%"，业务方说"用户感知不到"。最后我们也是用 MDE + 置信区间把"多少算好"前置锁死，扯皮瞬间消失。
但我想补一个 LLM 场景下特别容易踩的坑：MDE 的"业务可感知阈值"在 LLM 里比传统系统难定 10 倍，因为 LLM 的输出是分布式的、非确定性的。同一个 prompt 跑 5 次可能 3 次对 2 次错，这意味着你的"单次评测"本身就带噪声，样本量公式里的 p 不能按"固定概率"来估，得按"多次采样均值"来算。实操建议：每条黄金集 case 跑 3-5 次取多数投票作为该 case 的"真值"，再代入 MDE 公式。否则你 100 条样本里可能有 20% 的噪声是模型自身的不确定性带来的，你以为是"效果没提升"，其实是"尺子本身在抖"。