第 3 章：AI 评测的核心悖论与可信原则
第 3 章：AI 评测的核心悖论与可信原则
3.1 评测不是消灭不确定性，而是管理不确定性
客服 Agent 的候选版本在离线评测中提升了 2%。任务完成率从 86% 到 88%，回答满意度略有提升，工具调用正确率基本稳定。团队开始争论：这 2% 是否足以发布？
产品同学认为分数上涨，应该尽快灰度。算法同学认为提升不大，可能只是随机波动。安全同学指出，退款高风险场景样本量太少，平均分不能说明问题。业务同学关心的是：线上投诉率会不会下降。
这个争论没有一个简单答案。
AI 评测面对的不是完全确定的系统。输入空间近乎无限，模型输出具有概率性，业务规则会变化，用户分布会漂移，人工标注也有分歧。评测无法消除这些不确定性，只能通过更好的设计让决策更可信。
可信评测的目标不是给出绝对真理，而是在有限样本、有限预算和有限时间内，给出足够可靠、可解释、可执行的质量判断。
3.2 悖论一：覆盖不完，但必须决策
真实用户的问题无限多。客服 Agent 不可能穷尽所有表达：
- “我退货后券还回来吗？”
- “我只退其中一个，活动满减怎么算？”
- “你们上次说可以补差价，怎么现在不行？”
- “我朋友能退，我为什么不能退？”
每个问题还可能出现在不同上下文、渠道、用户身份和订单状态中。
但业务不能无限等待。系统必须在某个时间点决定是否发布、灰度、回滚或继续优化。
管理策略是分层覆盖：
| 数据层 | 作用 |
|---|---|
| Golden Set | 覆盖核心稳定能力 |
| Regression Set | 防止已知问题复发 |
| Hard Case | 覆盖复杂、长尾和边界问题 |
| Red Team | 探测安全和滥用风险 |
| Online Bad Case | 捕捉真实分布变化 |
| Hidden Set | 防止过拟合和指标迎合 |
评测集永远不可能覆盖全部输入，但可以覆盖最重要的风险面。
3.3 悖论二：指标可量化，但指标会被刷
指标让质量可讨论，也可能让系统被错误优化。
如果只优化回答满意度，模型可能更迎合用户，甚至在不确定时给出自信承诺。如果只优化任务完成率，Agent 可能跳过必要身份验证。如果只优化回答长度，模型可能输出冗长但不更正确的解释。
这就是常说的指标代理问题：当指标成为目标，它就可能不再代表真实目标。
应对方式是多指标制衡。
| 目标 | 不能只看 | 还要看 |
|---|---|---|
| 提高解决率 | 任务完成率 | 投诉率、误导率、转人工合理性 |
| 提升体验 | 满意度 | 正确性、安全、可执行性 |
| 降低成本 | Token 成本 | 质量退化、工具失败、用户重试 |
| 提高拒答安全 | 拒答率 | 误拒率、用户损失、人工接管 |
企业级评测不能追求一个万能总分。总分可以作为入口，但决策必须回到能力、风险和场景维度。
3.4 悖论三：离线可控，在线真实
离线评测可控、便宜、可复现，适合做版本对比和回归验证。但它永远是对真实世界的抽样。
线上数据真实，但噪声大、影响因素多、成本高，不能随意实验。
客服 Agent 离线分数提升 2%，线上投诉率却没有下降，可能有多种原因：
- 离线样本没有覆盖投诉高发场景。
- 线上用户分布发生变化。
- 指标提升发生在低价值场景。
- 线上产品流程影响了用户体验。
- 提升幅度本身只是随机波动。
管理策略是建立离线与在线的闭环：
- 离线评测用于发布前判断。
- 灰度用于验证真实流量。
- 线上 Bad Case 回流到离线数据。
- 离线指标定期用线上结果校准。
离线指标不是目的。它必须持续接受线上信号检验。
3.5 悖论四：人评可靠但慢，机评高效但有偏差
人工评审更能理解业务语境、风险边界和细微体验，但成本高、速度慢、一致性也不天然稳定。
机器评估可以快速覆盖大量样本，但会受 Judge 偏差、提示方式、模型能力和样本分布影响。
企业评测的长期形态是人机协同。
| 评估方式 | 适合场景 | 风险 |
|---|---|---|
| 规则评估 | 格式、字段、敏感词、工具终态 | 覆盖有限 |
| 脚本评估 | 可计算指标、结构化任务 | 难处理开放语义 |
| LLM Judge | 语义质量、风格、复杂回答 | 偏差、漂移、可解释性不足 |
| 人工评审 | 高风险、争议样本、Rubric 校准 | 成本和一致性 |
一个可信体系通常让规则和脚本处理确定性问题，让 Judge 扩展语义评估覆盖，让人工负责高风险样本和评估器校准。
3.6 悖论五：评测集需要透明，但不能完全公开
团队需要知道评测标准，否则无法优化系统。但如果所有评测样本完全公开，系统就可能被针对性优化，导致分数提升但泛化下降。
客服 Agent 的 Golden Set 如果长期暴露给 Prompt 编写者，Prompt 可能逐渐围绕这些样本打补丁。分数上升，不代表线上质量提升。
更好的做法是：
- Rubric 和指标口径公开。
- 场景分布和风险分类公开。
- 具体样本按权限管理。
- 保留 Hidden Set 做独立验收。
- 定期用线上 Bad Case 更新评测集。
透明的是标准，不应完全暴露的是答案和样本细节。
3.7 悖论六：评测要稳定，也要持续更新
评测集太稳定，会逐渐脱离真实业务；更新太频繁，又会让历史分数不可比较。
客服 Agent 的退款政策每月变化。如果评测集不更新，分数会越来越虚；如果每天换一批样本，团队又无法判断版本是否真的进步。
解决方式是数据分层：
| 数据层 | 更新频率 | 作用 |
|---|---|---|
| Core Golden | 低频更新 | 维持核心能力可比性 |
| Regression | 随 Bad Case 增长 | 防复发 |
| Scenario Set | 随业务变化更新 | 覆盖业务场景 |
| Online Sample | 持续流入 | 发现真实分布变化 |
| Hidden Set | 严格控制 | 独立验收 |
稳定性和更新不是二选一。不同数据层承担不同职责。
3.8 可信评测的七个原则
一个评测结论是否可信，可以从七个原则判断。
| 原则 | 含义 |
|---|---|
| 有效性 | 指标确实衡量目标质量 |
| 可靠性 | 相同条件下结果相对稳定 |
| 区分度 | 能区分好版本和差版本 |
| 覆盖度 | 覆盖核心场景和关键风险 |
| 可解释性 | 能说明分数来自哪些样本和原因 |
| 可复现性 | 版本、数据、配置和执行过程可追溯 |
| 可操作性 | 结论能转化为发布或优化动作 |
如果一个评测只给出总分，但不能说明样本、版本、置信度和修复方向，它就很难支撑企业决策。
3.9 统计底线
AI 评测不是只跑一遍脚本。至少要关注基本统计问题。
3.9.1 样本量
样本太少时，分数波动可能大于真实差异。退款高风险场景只有 10 条样本时，提升 1 条就能带来 10% 的表面变化。
3.9.2 置信区间
分数应尽量给出不确定范围。候选版本 88%，基线 86%，如果置信区间高度重叠，就不能草率认为候选版本显著更好。
3.9.3 随机波动
LLM 输出存在波动。关键样本可以多次运行，观察稳定性，而不是只看单次结果。
3.9.4 实际显著性
统计上可见的差异，不一定有业务意义。任务完成率提升 0.5%，但 P95 延迟上升 40%，可能不值得发布。
3.9.5 标注一致性
人工评审需要看一致性。若标注者对同一类回答分歧很大，说明 Rubric 不够清楚，不能直接把分数用于门禁。
3.10 案例：离线提升 2%，线上无感
客服 Agent 候选版本离线分数提升 2%，但灰度后线上投诉率没有下降。
团队按可信评测原则复查：
| 复查点 | 发现 |
|---|---|
| 覆盖度 | 提升主要来自常见物流问题 |
| 风险分层 | 退款和会员权益样本量不足 |
| 置信区间 | 整体提升不稳定 |
| 线上映射 | 投诉主要来自退款政策场景 |
| 可操作性 | 报告没有给出放量和补测建议 |
结论不是“评测没用”，而是这次评测结论不足以支持全量发布。更合适的决策是：
- 常规物流场景可以继续灰度。
- 退款和会员权益场景保持保守策略。
- 补充高风险场景样本。
- 用线上投诉 Bad Case 更新 Regression Set。
- 重新评估候选版本在高风险场景的表现。
可信评测不要求每次都给出“发布 / 不发布”的简单答案。它要给出足够细的决策边界。
3.10.1 不确定性下的决策矩阵
企业评测经常面对“不够确定但必须决策”的状态。此时不应强行把结论压成一个总分，而应把不确定性显式写入决策矩阵。
| 评测证据 | 风险等级 | 业务收益 | 建议决策 | 配套动作 |
|---|---|---|---|---|
| 指标显著提升，高风险样本稳定 | 低 | 高 | 放行或扩大灰度 | 保持线上监控，继续回流 Bad Case |
| 指标小幅提升，高风险样本不足 | 中 | 中 / 高 | 限定场景灰度 | 补充高风险样本，限制高危功能放量 |
| 平均分提升，但 P0 / P1 失败 | 高 | 任意 | 阻断 | 修复红线问题，重新运行门禁 |
| 指标无明显变化，但成本显著下降 | 中 | 中 | 人工审批 | 评估质量风险与成本收益 |
| 指标波动大，结论不稳定 | 中 / 高 | 不确定 | 补测 | 增加样本量、多次运行、复核 Evaluator |
| 线上灰度信号恶化 | 高 | 任意 | 回滚或降级 | 归因线上 Bad Case，进入回归集 |
这张矩阵强调一个原则：评测结论的粒度应服务于决策粒度。全量发布、限定场景灰度、只放低风险意图、保持人工审批、回滚候选版本，本来就是不同决策，不应该被同一个平均分决定。
3.10.2 可信结论的表达格式
可信评测报告应避免只写“候选版本优于基线”。更稳妥的表达方式是把结论拆成事实、范围、风险和动作。
一个可用于发布评审的结论可以采用如下格式：
| 组成部分 | 写法 |
|---|---|
| 结论 | 候选版本在常规物流与订单查询场景可进入 10% 灰度 |
| 证据 | 核心任务完成率提升 2.1%，工具调用正确率持平，P95 延迟上升 4% |
| 适用范围 | 仅覆盖物流、订单查询、常规退款咨询，不覆盖高金额退款操作 |
| 不确定性 | 会员权益与优惠券部分退款样本量不足，Judge 与人工一致性需继续观察 |
| 风险 | 高风险退款承诺场景存在 2 条边界失败，不允许自动化退款放量 |
| 动作 | 补充 100 条会员权益样本；高金额退款保持人工审批；灰度期间监控投诉率和转人工率 |
这种表达比单一分数更长，但更适合企业决策。它告诉读者：评测不是在制造确定性幻觉，而是在有限证据下划定可行动边界。
3.11 交付物一：AI 评测六大悖论与管理策略
| 悖论 | 风险 | 管理策略 |
|---|---|---|
| 覆盖不完，但必须决策 | 样本不足导致误判 | 数据分层、风险优先、灰度验证 |
| 指标可量化，但会被刷 | 分数提升不代表真实质量提升 | 多指标制衡、场景分层、Hidden Set |
| 离线可控，在线真实 | 离线与线上脱节 | 线上回流、离线在线映射 |
| 人评可靠但慢，机评高效但偏 | 成本与偏差难平衡 | 人机协同、Meta-Eval、人工校准 |
| 标准要透明，样本要控权 | 过拟合评测样本 | Rubric 公开、样本分层权限 |
| 评测要稳定，也要更新 | 可比性与时效性冲突 | Core / Regression / Online 分层 |
这张表适合放在评测体系设计评审中，提醒团队不要追求单点完美。
3.12 交付物二：可信评测最低标准清单
| 检查项 | 最低要求 |
|---|---|
| 目标清楚 | 指标能对应业务目标或风险 |
| 样本分层 | 至少区分核心、回归、高风险和线上回流 |
| 版本可追溯 | 模型、Prompt、知识库、工具和评测数据版本可查 |
| 评估器可解释 | 规则、脚本、Judge 或人工依据清楚 |
| 人工校准 | 高风险或争议样本有人评校准 |
| 统计说明 | 样本量、波动和显著性有基本说明 |
| 决策动作 | 结论能对应放行、灰度、阻断、补测或修复 |
| 线上回流 | 线上 Bad Case 能进入后续评测资产 |
低于这条底线，评测结果可以作为参考，但不应直接作为发布依据。
3.13 本章小结
AI 评测的核心挑战，是在不确定性中建立可信决策。
覆盖不完、指标会被刷、离线和线上存在差异、人评与机评各有偏差、评测集既要透明又要防污染、数据既要稳定又要更新，这些矛盾无法完全消除，只能通过体系化设计管理。
可信评测至少要满足有效性、可靠性、区分度、覆盖度、可解释性、可复现性和可操作性。
下一章，我们将把这些可信原则组合成一幅完整的企业级评测闭环全景图，看数据、评估器、平台、门禁、监控和归因如何协同运转。