很多团队改完 Prompt 或换完模型后验证效果的方式是- 跑两三个 case 看看- 自己问几个问题感觉一下- 让业务方试用一下这种验证方式不是评测是赌运气。改之前不知道效果会不会变好改之后不知道有没有变差上线之后不知道哪类问题变差了。等业务方投诉回答质量下降了团队才知道出问题了——但已经在线上跑了一周。这不是个别团队的问题。很多 AI 应用到现在都没有评测体系。不是不想做是不知道怎么做、做到什么程度算够。这篇讲清楚一件事**AI 应用没有评测体系每次变更都在赌运气。技术团队最该先建的是 4 层评测。**---## 一、为什么跑几个 case 看看不等于评测先说清楚跑几个 case为什么不算评测。### 1几个 case 代表不了整体你跑的两三个 case是你自己挑的——通常是你熟悉的、能答对的、效果还行的 case。但真实用户的请求分布和这几个 case 完全不一样。长尾问题、边界问题、多意图问题、跨场景问题这些才是最容易出问题的地方而它们不在你挑的 case 里。### 2跑完没有基线对比跑几个 case你能看到这次回答看起来还行。但还行是和什么比和上一版 Prompt 比和上一个模型比和业务预期比没有基线就没有判断标准。### 3跑完没有指标量化看起来还行是一个主观判断。回答正确率是多少召回覆盖率是多少格式合规率是多少工具调用正确率是多少没有量化就没法做回归对比也没法做发布门禁。### 4跑完没有沉淀这次跑的 case下次改完还会跑吗会不会换一批失败 case 有没有沉淀成测试样本如果没有沉淀每次都在从零开始评测永远做不起来。跑几个 case 看看是评测的起点但不是评测。真正的评测是一套有测试集、有指标、有基线、有门禁、有沉淀的体系。---## 二、评测体系缺位的 3 个典型后果评测体系缺位不只是验证不充分这么简单。它会带来 3 个连锁后果### 后果 1每次变更都在赌运气没有评测体系改 Prompt、换模型、更知识都没有基线对比。团队只能凭感觉判断这次改完好像好了一点。但好像好了一点可能是主场景好了长尾场景变差了平均分涨了关键场景退化了。### 后果 2问题发现总是滞后没有评测体系问题不会在变更时暴露只会在上线后暴露。而上线后暴露意味着用户已经感知到了。团队永远是业务方投诉了才知道出问题永远在被动响应。### 后果 3团队不敢改、又不得不改没有评测体系兜底团队会进入一种矛盾状态不敢改怕改坏了发现不了又不得不改业务一直在提需求。结果是改得小心翼翼、每次都提心吊胆出了问题就回滚回滚完又不知道该不该再改。这 3 个后果叠加团队会进入一种改一次乱一次、不改又不行的失控状态。---## 三、评测集该怎么建黄金样本、边界样本、生产失败样本、高风险切片评测体系的第一块基石是评测集。评测集不是随便找几个问题而是要分层建。至少要有 4 类样本### 1黄金样本Golden Set- 覆盖核心业务场景的标准问答对- 有标准答案或明确预期- 数量不用多但要稳定- 每次变更都跑作为基线对比黄金样本的作用是保证核心场景不退化。### 2边界样本Edge Cases- 模糊表述、多意图、跨场景、超纲问题- 测试系统的边界处理能力- 包括该拒答的、该转人工的、该追问的边界样本的作用是保证长尾场景不翻车。### 3生产失败样本Failure Cases- 从线上投诉、人工接管、用户反馈里沉淀- 每一个确认的生产事故都回灌成测试样本- 这是用真实代价换来的评测资产生产失败样本的作用是保证同一个错不犯第二次。### 4高风险切片High-Risk Slices- 按业务关键性切片高价值客户、付费场景、合规相关- 按用户类型切片新用户、老用户、企业用户、个人用户- 按问题类型切片涉及金额、涉及权限、涉及安全高风险切片的作用是保证关键场景不退化。这 4 类样本建起来评测集才算有了骨架。只有黄金样本覆盖不了长尾只有边界样本保证不了核心只有生产失败样本会一直滞后。4 类缺一不可。---## 四、评测指标不要单一化质量、安全、成本、延迟、工具正确性并列评测集建好之后第二个常见错误是只看一个指标。最常见的单一指标是回答正确率或平均分。但一个指标再好也不能代表整体。### 更像真实现场的过程某次模型切换团队跑评测集平均正确率从 82% 涨到 85%。团队觉得效果变好了直接上线。上线一周后业务方反馈- 某类合规相关问题的拒答率下降了——模型变得更敢答了- 长问题的 P95 延迟从 3 秒涨到 7 秒——模型推理更慢了- 工具调用正确率从 95% 降到 88%——模型选工具变差了- 单次成本涨了 20%——模型输出更长平均分涨了但 4 个关键指标都退化了。团队只盯了一个指标漏掉了 4 个。### 真正该并列看的指标- **质量**正确率、召回覆盖率、忠实度、格式合规率- **安全**拒答率、越界率、提示注入防护率- **成本**单次 Token、单任务累计 Token、后台调用占比- **延迟**P95、P99、长上下文请求延迟- **工具正确性**工具选择正确率、参数构造正确率、副作用正确率这 5 类指标并列看才能判断一次变更是不是真的变好了。只看一个指标就是在赌那个指标没掩盖退化。### 一句判断**总分不能代替决策。质量、安全、成本、延迟、工具正确性要并列考察。**---## 五、把效果回归变成发布门禁离线回归 → 影子流量 → 人工校准评测集和指标有了第三个关键动作是把效果回归变成发布门禁。不是改完跑一下看看而是改完必须过门禁才能上线。### 第 1 层离线回归评测- 每次变更前在评测集上跑完整回归- 和当前生产基线对比- 关键指标不能退化超过阈值- 退化超阈值的变更不能上线这一层是改完先验证。### 第 2 层影子流量评测- 变更先不切真实流量用影子流量跑- 影子流量是真实请求的副本结果不影响用户- 在影子流量上观察指标表现- 表现达标后才进入灰度这一层是上线前再验证。### 第 3 层人工校准- 自动评测指标包括 LLM-as-a-Judge会漂移- 定期用人工标注样本校准自动评测- 记录评测器的模型、Prompt、版本、阈值- 评测器本身也要版本化这一层是保证评测本身可信。这 3 层不是可选的是发布门禁的必要组成。没有这 3 层效果回归就只是一句口号。---## 六、评测器也要校准和版本化这是最容易被忽略的一点。很多团队用 LLM-as-a-Judge 做自动评测——用一个大模型来评判另一个大模型的输出。这能规模化但也有风险### 评测器的风险- 评测器模型本身会变——供应商升级、模型切换、Prompt 调整- 评测器会有偏好——对长回答打高分、对某种风格打高分- 评测器和被评测系统可能同源——用同一个模型评自己分数虚高- 评测器阈值没校准——什么算通过、什么算退化没有明确标准### 真正该做的- 评测器要记录用什么模型、什么 Prompt、什么版本、什么阈值- 评测器要定期用人工标注样本校准- 评测器和被评测系统不要同源- 评测器变更时要重新跑历史评测集确认评分基准没漂移- 评测器本身要纳入版本管理这一步不做评测结果就不可信。团队会陷入指标在涨但效果在掉的错觉。---## 七、一个最小可用的 AI 评测体系骨架如果要把上面这些落地最小可用的骨架是### 骨架| 层次 | 核心问题 | 最小动作 ||---|---|---|| 评测集 | 测什么 | 黄金样本 边界样本 生产失败样本 高风险切片 || 评测指标 | 看什么 | 质量 安全 成本 延迟 工具正确性 || 发布门禁 | 怎么卡 | 离线回归 影子流量 人工校准 || 评测器治理 | 评测本身可信吗 | 评测器版本化 人工校准 不同源 |### 落地顺序1. 先建黄金样本最小集20-50 个核心问答对2. 再定 3-5 个核心指标先从质量和成本开始3. 再做离线回归门禁每次变更必跑4. 再补生产失败样本从线上投诉回灌5. 再加影子流量和人工校准6. 最后做评测器治理这个顺序不是一步到位而是逐步长出来。但每一步都要做不能跳。---## 八、结语AI 应用没有评测体系每次改 Prompt、换模型、更知识都是在赌运气。跑几个 case 看看不是评测。真正的评测是一套有测试集、有指标、有基线、有门禁、有沉淀的体系。技术团队最该先建的 4 层评测- **评测集**黄金样本 边界样本 生产失败样本 高风险切片- **评测指标**质量 安全 成本 延迟 工具正确性并列- **发布门禁**离线回归 影子流量 人工校准- **评测器治理**版本化 人工校准 不同源这 4 层建起来团队才能从改一次赌一次变成改一次验一次。变更才敢做回滚才敢回效果才说得清。对技术负责人来说评测体系不是以后再说的能力而是 AI 应用能不能长期跑的前提。没有评测体系首发再顺的系统也会在几次变更后慢慢失控——因为没人知道每次变更到底改了什么。