第 15 章：可信评测：统计、Meta-Eval 与体系质量
第 15 章：可信评测：统计、Meta-Eval 与体系质量
15.1 分数提升 1.5，能上线吗
客服 Agent 的候选版本在离线评测中平均分提升了 1.5。看起来这是一个好消息。
但进一步拆开结果后，团队发现：
- Easy 样本提升明显，Hard Case 下降。
- 总分提升主要来自回答更长、更礼貌。
- 高风险退款场景有 2 条工具参数错误。
- Judge 与人工在投诉升级样本上的一致率只有 62%。
- 小流量灰度中，转人工率没有下降。
这个版本到底是变好了，还是只是分数变好看了？
可信评测要回答的不是“分数是多少”，而是“这个分数能不能支撑决策”。评测结论如果不可信，比没有评测更危险，因为它会给团队虚假的安全感。
15.2 可信评测的七个标准
一套评测体系至少要满足七个标准。
| 标准 | 问题 |
|---|---|
| 有效性 | 是否真的评到了想评的能力 |
| 可靠性 | 多次评测结果是否稳定 |
| 区分度 | 能否区分不同质量的版本 |
| 覆盖度 | 是否覆盖主路径、长尾、异常和安全 |
| 可解释性 | 分数变化能否解释原因 |
| 可复现性 | 其他人能否复现同一结果 |
| 可操作性 | 结果能否转化为优化或发布决策 |
如果一套评测只给出总分，却无法解释分数代表什么、为什么变化、该不该发布、该改哪里，它就不满足可信评测的要求。
15.3 样本量与不确定性
AI 评测面对的是有限样本和概率性输出。一次跑分不是绝对真相，而是一次测量。
如果只用 30 条样本评估一个客服 Agent，然后得出“候选版本比当前版本高 3 分”，这个结论很可能不稳定。换一批样本，换一次采样，分数可能就变了。
评测报告中应尽量包含：
- 样本数量。
- 样本分布。
- 均值和分维度分数。
- 置信区间。
- 方差或波动范围。
- 多次运行稳定性。
对高风险场景，不能只看总样本量。全量 1000 条样本里只有 5 条隐私越权样本，即使总体样本量很大，也无法证明安全评测充分。
15.3.1 用业务语言解释不确定性
评测报告不一定要写复杂公式，但要把不确定性讲清楚。
| 表达 | 含义 |
|---|---|
| 样本量不足 | 当前样本无法支撑稳定结论 |
| 波动范围较大 | 多次运行结果不稳定 |
| 高风险样本覆盖不足 | 安全结论证据不足 |
| 置信区间重叠 | 两个版本差异可能不明显 |
| 需要灰度验证 | 离线证据不足以支持全量 |
这比只写“候选版本高 1.5 分”更有决策价值。管理层不需要看到完整统计推导，但必须知道结论的把握程度。
15.3.2 实操工具箱：三个常用统计计算
评测工程师不需要成为统计学家，但以下三个计算方法是日常工作中反复用到的。掌握它们，你就能把“看起来提升了”变成“在 95% 置信度下提升了”。
方法一：比例的置信区间（用于通过率、正确率等）
当你的指标是“正确数 / 总数”这类比例时（例如退款政策正确率、工具参数准确率），最常用的是 Wilson 置信区间。它比简单的正态近似在小样本下更可靠。
import math
def wilson_confidence_interval(successes, total, confidence=0.95):
if total == 0:
return (0.0, 0.0)
z = {0.90: 1.645, 0.95: 1.96, 0.99: 2.576}[confidence]
p = successes / total
denominator = 1 + z**2 / total
center = (p + z**2 / (2 * total)) / denominator
margin = z * math.sqrt((p * (1 - p) + z**2 / (4 * total)) / total) / denominator
return (center - margin, center + margin)
lower_a, upper_a = wilson_confidence_interval(180, 200)
lower_b, upper_b = wilson_confidence_interval(190, 200)
print(f"当前版本: {180/200:.1%}, 95%CI: [{lower_a:.1%}, {upper_a:.1%}]")
print(f"候选版本: {190/200:.1%}, 95%CI: [{lower_b:.1%}, {upper_b:.1%}]")
怎么用：报告中不只写“正确率从 90% 提升到 95%”，而要写“95% 置信区间为 [85.1%, 93.5%] → [91.1%, 97.4%]，区间有重叠，需补测或灰度验证”。如果当前版本 CI 上限低于候选版本 CI 下限，可以更有信心地说有显著提升。
样本量快速估算：如果你希望正确率的置信区间宽度不超过 ±5%，在 p≈0.9 的场景下大约需要 150-200 条样本。如果只测了 30 条，margin 大约是 ±15%，根本无法支撑版本对比结论。
方法二：配对 Bootstrap（用于分数对比）
当你对比两个版本在同一批 Case 上的分数时，配对 Bootstrap 比独立 t 检验更实用，因为它不假设分数服从正态分布。
import random
def paired_bootstrap(scores_a, scores_b, n_bootstrap=10000, confidence=0.95):
n = len(scores_a)
diffs = [b - a for a, b in zip(scores_a, scores_b)]
boot_diffs = []
for _ in range(n_bootstrap):
sampled = [diffs[random.randint(0, n-1)] for _ in range(n)]
boot_diffs.append(sum(sampled) / n)
boot_diffs.sort()
alpha = (1 - confidence) / 2
mean_diff = sum(diffs) / n
wins = sum(1 for d in boot_diffs if d > 0) / n_bootstrap
return (mean_diff, boot_diffs[int(alpha*n_bootstrap)],
boot_diffs[int((1-alpha)*n_bootstrap)], wins)
判断规则：CI 下界 > 0 → B 显著优于 A；CI 包含 0 但大部分 > 0 → B 可能更好，建议灰度；CI 包含 0 且对称 → 无显著差异；CI 上界 < 0 → B 显著差于 A（阻断）。
方法三：最小样本量快速查表
| 你想检测的最小差异 | 所需样本量（每条分支） | 说明 |
|---|---|---|
| ±10%（粗糙对比） | 50-100 | 适合早期快速验证 |
| ±5%（常规发布） | 200-400 | 适合核心场景发布门禁 |
| ±3%（精细对比） | 500-1000 | 适合关键版本和模型升级 |
| ±1%（精确度量） | 2000+ | 通常不需要，线上 A/B 更合适 |
核心原则：高风险场景（P0/P1）的样本量要比体验类场景大。如果越权查询只有 5 条样本，即使这 5 条全过，也不能得出“越权风险已控制”的结论——你只是还没测到失败的样本。
15.4 配对实验比独立比较更可靠
模型或 Agent 版本对比时，最好使用配对实验：同一批 Case，同时评估当前版本和候选版本。
配对实验的优势是控制样本差异。否则，当前版本跑的是一批样本，候选版本跑的是另一批样本，分数差异可能来自样本难度，而不是系统能力。
版本对比时要锁定：
- 数据集版本。
- Case 版本。
- Prompt 版本。
- 知识库版本。
- 工具 Schema。
- Evaluator 版本。
- 运行环境。
- 采样参数。
只有目标变量发生变化，版本对比才有解释力。
15.4.1 退化分析比平均提升更重要
版本对比中，平均提升不应掩盖局部退化。
报告应单独展示：
- 哪些场景提升。
- 哪些场景退化。
- 退化是否发生在 P0 / P1 场景。
- 退化是否与某类能力相关。
- 退化是否超过业务容忍度。
客服 Agent 候选版本如果普通物流问答提升 5%，但退款工具参数准确率下降 2%，不能用平均提升放行。版本对比报告要把退化场景列为决策重点。
15.4.2 配对二分类指标的比较
很多企业评测指标不是连续分数，而是通过 / 失败、是否越权、是否正确调用工具这类二分类结果。比较这类指标时，最重要的不是“两个版本各自通过率是多少”，而是同一批 Case 上哪些样本从失败变成功、哪些从成功变失败。
| 当前版本 | 候选版本 | 含义 |
|---|---|---|
| 失败 | 通过 | 候选版本修复的样本 |
| 通过 | 失败 | 候选版本引入的退化 |
| 通过 | 通过 | 两个版本都能处理 |
| 失败 | 失败 | 两个版本都未解决 |
如果只是看通过率，两个版本可能都在 95% 左右；但如果候选版本修复了大量低风险样本，同时引入少量 P0 退化，发布决策应优先关注退化样本。配对二分类检验（例如 McNemar 检验）适合判断“修复数”和“退化数”的差异是否足够稳定。
企业报告不一定要展示公式，但至少要展示三件事：
- 修复样本数和退化样本数。
- 退化样本是否集中在 P0 / P1 场景。
- 退化是否超过业务容忍度或门禁阈值。
对客服 Agent 来说，如果候选版本让普通问答多通过 30 条，却让 3 条退款工具样本从通过变失败，这 3 条退化可能比 30 条修复更重要。
15.5 统计显著性与实际显著性
统计显著不等于业务有意义。
一个候选版本在 5000 条样本上平均分提升 0.1，可能统计显著，但用户完全感知不到。反过来，一个版本在总分上只提升 0.5，但高风险退款错误下降 80%，业务价值可能很大。
因此，评测报告应同时回答：
- 变化是否超过随机波动。
- 变化是否足以影响业务。
- 提升发生在哪些场景。
- 退化发生在哪些场景。
- 是否触及门禁或红线。
企业级评测不能只报告 p 值或平均分，而要把统计变化翻译成业务决策。
15.5.1 把分数结论翻译成决策置信等级
发布评审最需要的不是“候选版本高了多少分”，而是“这个结论有多可靠，适合做什么决策”。因此，评测报告可以把结论分成不同置信等级。
| 置信等级 | 判断条件 | 适合动作 |
|---|---|---|
| 高置信放行 | 核心指标稳定提升，高风险样本通过，退化可解释，线上映射明确 | 放行或扩大灰度 |
| 中置信灰度 | 主要指标可接受，但部分场景样本不足或波动较大 | 限定场景灰度，补充监控 |
| 低置信补测 | 样本量不足、置信区间重叠、Judge 与人工分歧较大 | 补测、复核、延后决策 |
| 高风险阻断 | P0 / P1 样本失败，或关键门禁退化 | 阻断发布，修复后重跑 |
| 业务权衡审批 | 质量变化不明显，但成本、延迟或业务收益有明显变化 | 负责人审批并记录风险接受 |
这个分级有两个作用。第一，它避免团队把所有结果都写成“通过 / 不通过”。第二，它让不确定性进入决策过程，而不是被平均分隐藏。
客服 Agent 候选版本如果在常规物流场景提升明显，但退款高风险样本只有少量覆盖，更合适的结论不是“整体提升 1.5 分”，而是“低风险场景可灰度，高风险退款场景证据不足，需要补测并保持人工审批”。
15.6 多指标比较的误报
当团队同时看 30 个指标时，总会有几个指标“显著变化”。这可能是真变化，也可能是偶然波动。
多指标评测中应注意：
- 先区分门禁指标、诊断指标、观察指标。
- 不要因为观察指标波动就直接阻断发布。
- 对多个维度的显著变化做分组解释。
- 关注一致性模式，而不是孤立异常。
- 对关键指标做人工复核或二次实验。
- 对大量观察指标，可使用 FDR 或 Bonferroni 一类方法控制误报，但不要机械套用到所有业务指标。
例如，候选版本在“回答长度”“礼貌程度”“用户安抚”上提升，但“政策正确性”“工具参数准确率”“高风险拒绝”没有提升，甚至退化，就不能简单判断版本更好。
多指标控制的业务化做法是：门禁指标先按业务红线独立判断，不能被平均分或多指标校正稀释；诊断指标用于解释问题，不直接决定放行；观察指标用于趋势监控，出现异常时触发复核而不是自动阻断。统计方法帮助团队降低误报，但发布决策仍要回到风险等级、样本证据和业务后果。
15.7 标注一致性
人工评测不是天然可靠。人工也需要校准。
如果两个标注者对同一批客服回答的好坏判断差异很大，说明 Rubric 不够清晰，或样本本身存在歧义。
常见一致性指标包括：
| 指标 | 适用场景 |
|---|---|
| Cohen's Kappa | 两个标注者的分类一致性 |
| Fleiss' Kappa | 多个标注者的分类一致性 |
| Krippendorff's Alpha | 多标注者、多类型标签 |
| Spearman 相关 | 排序或打分一致性 |
评测团队不需要把统计学写成论文，但至少要知道：如果人工标签本身不一致，自动 Evaluator 就没有稳定的校准目标。
15.8 Judge 的 Meta-Evaluation
LLM-as-Judge 必须被评测。否则它只是另一个未经校准的模型。
Meta-Evaluation 至少包括：
| 维度 | 检查问题 |
|---|---|
| 人工一致率 | Judge 与人工判断是否一致 |
| 排序相关性 | Judge 是否能正确比较两个版本 |
| 长度偏置 | 是否偏好更长回答 |
| 位置偏置 | Pairwise 中 A/B 顺序是否影响判断 |
| 风格偏置 | 是否偏好礼貌但不准确的回答 |
| 自我偏好 | 是否偏好同类模型输出 |
| 领域盲区 | 是否误判专业或业务规则 |
| 版本稳定性 | Judge 更新后结果是否可比 |
客服 Agent 中，Judge 很容易被“语气好、解释多”的回答影响。但企业评测必须优先保证政策正确、证据忠实和安全边界。Meta-Evaluation 要专门检查这些偏差。
15.8.1 Judge 校准集
Judge 需要一套稳定校准集。校准集不是普通评测集，它用于长期观察 Judge 是否可靠。
校准集应包含：
| 样本类型 | 目的 |
|---|---|
| 明显正确样本 | 检查 Judge 是否过度苛刻 |
| 明显错误样本 | 检查 Judge 是否误放 |
| 边界样本 | 检查 Judge 是否理解 Rubric |
| 长答案和短答案配对 | 检查长度偏置 |
| 安全高风险样本 | 检查红线判断 |
| 领域专家样本 | 检查业务规则理解 |
Judge Prompt、Judge 模型或 Rubric 变化后，都应先跑校准集。只有校准集表现稳定，Judge 才适合进入大规模评测。
15.8.2 Judge 的适用边界
Judge 的优势是规模化语义评估，但它不适合承担所有判断。终稿级评测体系必须明确 Judge 的使用边界。
| 场景 | Judge 适用性 | 推荐处理 |
|---|---|---|
| 语气、清晰度、结构完整性 | 较适合 | Judge 批量评估，人工抽检 |
| 证据忠实度 | 条件适用 | 给 Judge 明确证据和 Rubric，并用人工校准 |
| 业务政策正确性 | 谨慎使用 | 规则、脚本、专家样本和 Judge 组合 |
| 金额计算、字段格式、工具参数 | 不应作为主评估器 | 脚本、Schema、业务规则引擎 |
| P0 / P1 安全风险 | 不应单独裁决 | 规则、Trace、人工复核和硬门禁 |
| 发布最终决策 | 不应直接替代负责人 | Judge 只提供证据，决策进入门禁和审批流程 |
一个实用原则是：凡是可以用确定性规则、工具终态或业务系统校验的内容，不应优先交给 Judge。Judge 应用于开放语义和复杂表达，但它的输出必须经过校准、抽检和版本管理。
客服 Agent 的“回答是否礼貌”可以交给 Judge 大规模评估；“退款金额是否正确”应由业务规则计算；“是否泄露他人订单信息”应由规则、Trace 和人工共同检查。把这些问题都交给 Judge，会让评测体系看似自动化，实际风险更高。
15.9 离线指标与线上指标的相关性
离线评测的最终价值，要靠线上表现校准。
如果离线“政策正确率”提升，线上退款投诉率下降，说明这个指标可能有效。如果离线总分持续提升，线上转人工率、投诉率、用户追问率没有变化，说明离线指标可能没有抓住真实问题。
离线和线上可以建立映射：
| 离线指标 | 对应线上信号 |
|---|---|
| 任务完成率 | 自助解决率、转人工率 |
| 政策正确率 | 政策类投诉率、人工纠错率 |
| 工具参数准确率 | 工具失败率、业务异常单 |
| 高危拒绝正确率 | 安全事件、隐私投诉 |
| 回答清晰度 | 用户追问率、满意度 |
| 成本和延迟 | P95 响应时间、单会话成本 |
这种映射不是一次建立后永久有效。业务变化、用户变化、系统能力变化后，相关性也会变化。
15.9.1 如何建立离线在线校准机制
离线在线相关性不能只靠直觉判断。团队可以按固定节奏建立校准机制。
第一步，选择少量关键映射。不要试图把所有离线指标都映射到线上指标。优先选择能影响发布决策的指标，例如政策正确率、工具参数准确率、高危拒绝正确率和转人工合理性。
第二步，按版本记录离线结果和线上结果。每次发布后，保留对应版本的离线 Run、灰度范围、线上观察窗口、流量比例和异常事件。没有版本对齐，就无法判断相关性。
第三步，分析指标是否同向变化。如果离线政策正确率提升后，政策类投诉率持续下降，说明指标可能有效；如果离线总分提升但线上投诉不变，就要检查离线样本是否偏离真实分布。
第四步，处理不一致。离线好、线上差，通常指向样本覆盖、产品流程、用户分布或线上依赖问题；离线差、线上好，可能说明离线样本过难、权重不合理或指标与业务目标错位。
| 不一致类型 | 可能原因 | 调整动作 |
|---|---|---|
| 离线好，线上差 | 线上场景未覆盖、用户表达漂移、产品流程影响 | 回流线上 Bad Case，调整样本分布 |
| 离线差，线上好 | 离线 Hard Case 权重过高、指标过严 | 重审权重和门禁阈值 |
| 离线波动，线上稳定 | 样本量不足、Judge 漂移、运行随机性 | 增加样本、重跑校准集 |
| 离线稳定，线上波动 | 线上流量、活动、渠道或外部系统变化 | 分渠道分析，记录外部变量 |
校准机制的目标不是让离线指标完美预测线上结果，而是让离线评测持续接近真实决策需求。离线指标一旦长期无法解释线上质量，就应调整或降级。
15.10 评测体系本身会退化
评测体系不是建成后就稳定有效。它也会退化。
常见退化包括：
- 评测集被污染。
- 样本被反复针对优化。
- 业务规则变化导致答案过期。
- Judge 版本变化导致分数不可比。
- 指标被团队刷高，但用户体验无改善。
- Hard Case 不再有区分度。
- 线上新问题没有回流。
因此，评测体系也需要定期体检。
15.10.1 评测体系体检节奏
评测体系体检可以按节奏运行：
| 节奏 | 检查内容 |
|---|---|
| 每次发布前 | 门禁指标、Regression Set、Red Team Set |
| 每周 | 线上 Bad Case 回流、异常指标、Judge 低置信样本 |
| 每月 | 数据集覆盖、样本老化、标注一致性、Evaluator 漂移 |
| 每季度 | 指标树有效性、离线在线相关性、隐藏集区分度 |
体检结果应进入质量治理，而不是只停留在评测团队内部。若发现离线分数和线上投诉长期无关，就应调整指标、样本或评估器。
15.10.2 可信评测的停用条件
某些指标或评估器不应无限期使用。当它们不再可信时，要停用或降级。
停用信号包括：
- 与人工一致性长期偏低。
- 对线上指标没有解释力。
- 被团队稳定刷高但业务无改善。
- 样本严重污染。
- 对强弱版本没有区分度。
- 业务规则变化后无人维护。
停用不是失败，而是评测体系维护的一部分。保留失效指标，比没有指标更危险。
15.11 交付物一：评测体系质量回检表
可以按七个标准回检评测体系。
| 标准 | 回检问题 |
|---|---|
| 有效性 | 指标是否对应真实业务目标 |
| 可靠性 | 重复运行是否稳定 |
| 区分度 | 能否区分强弱版本 |
| 覆盖度 | 是否覆盖高频、高危、长尾和安全 |
| 可解释性 | 分数变化是否能归因 |
| 可复现性 | 是否记录数据、模型、Prompt、工具、Evaluator 版本 |
| 可操作性 | 结果是否触发门禁、修复或回流 |
如果一套评测体系只能回答“分数是多少”，不能回答“为什么、怎么办、能不能上线”，它还没有达到企业级要求。
15.12 交付物二：版本对比实验设计模板
| 字段 | 内容 |
|---|---|
| 实验目标 | 比较候选版本是否优于当前线上版本 |
| 对比对象 | 当前版本、候选版本 |
| 控制变量 | 数据集、知识库、工具、Evaluator、采样参数 |
| 样本范围 | Golden、Regression、Hard Case、Red Team |
| 主要指标 | 门禁指标和核心业务指标 |
| 次要指标 | 诊断指标、观察指标 |
| 显著性判断 | 置信区间、配对差异、人工复核 |
| 退化处理 | 识别退化场景，决定阻断、灰度或修复 |
| 发布建议 | 全量、灰度、阻断、人工审批 |
15.13 交付物三：离线-在线相关性分析模板
| 字段 | 内容 |
|---|---|
| 离线指标 | 任务完成率、政策正确率等 |
| 线上指标 | 转人工率、投诉率、用户追问率等 |
| 观察周期 | 例如 7 天或 14 天 |
| 版本范围 | 涉及哪些版本 |
| 相关性判断 | 同向、反向、无明显相关 |
| 异常解释 | 样本分布、用户变化、业务策略变化 |
| 调整动作 | 更新评测集、调整指标、补充线上回流 |
15.14 本章小结
可信评测不是追求复杂统计，而是避免用不可靠分数做高风险决策。
一套评测结论要能支撑企业决策，至少要说明：
- 样本是否足够，分布是否合理。
- 版本对比是否控制变量。
- 分数变化是否超过随机波动。
- 提升是否具有业务意义。
- Evaluator 是否经过人工校准。
- 离线指标是否能解释线上表现。
- 评测体系本身是否仍然有效。
至此，评测方案设计的核心链条已经形成：指标树决定评什么，数据资产决定用什么评，Case Schema 决定如何执行，Evaluator 决定如何判定，Trace 决定如何看过程，可信评测决定结论能否用于发布和优化。下一章，我们将引入评测中常被忽略的第三个维度——成本和延迟，看看如何在质量、成本和速度之间做出工程化权衡。