评测体系：AI 产品不可见的护城河

过去一年我接手过两个”半成品”AI 项目。它们的共同特征是：能跑，但没人敢改。每次改 prompt 都像在赌运气，改完不知道是好是坏，只能上线等用户反馈。

这两个项目的根本问题不是模型不行，是没有评测体系。没有评测体系意味着你无法度量任何改动的效果，只能靠直觉判断。直觉在简单问题上够用，在复杂系统上是灾难。

评测不是”测试”，是”度量体系”

很多人把评测理解为”跑一批问题看准确率”。这是测试思维，不是度量思维。测试回答的是”有没有bug”，度量回答的是”好不好，好了多少”。

一个合格的评测体系要能回答三个问题：

• 当前系统有多好？——用一个绝对分数描述当前表现。
• 这次改动的效果？——用一个相对分数描述改前改后的差异。
• 哪里好、哪里差？——用分层分数描述不同场景的表现，而不是一个总分。

第三个问题最容易被忽略。一个总分 85 分的系统，可能是”简单题 95 分 + 难题 60 分”，也可能是”简单题 85 分 + 难题 85 分”。这两种系统的改法完全不同。

评测集的三个层次

我维护的每个 AI 项目都有三层评测集，它们的用途、规模、更新频率完全不同。

1. 冒烟集（10–20 条）

每次改代码都跑。它不覆盖边界情况，只验证”核心链路没断”。设计原则是跑得快——1 分钟内出结果，让你敢在每次 commit 前跑。

冒烟集的价值不是发现深层问题，是防止你犯低级错误。比如改了切片逻辑后，最常用的 3 个问题还能答对吗？这个检查 10 条就够，但必须每次都跑。

2. 回归集（100–300 条）

每次合并前跑。它覆盖主要场景 + 已知 bad case。设计原则是覆盖全——每个 intent、每个工具、每种文档类型都要有代表。

回归集里最重要的部分是历史 bad case。每次线上发现的 bad case，修完后要加入回归集。这样下次改动时，你能确认这个 case 没有被改坏。没有这一层，你的系统会反复踩同一个坑。

3. 真实分布集（500+ 条）

每月跑一次。它的数据来自真实用户日志（脱敏后），反映真实的输入分布。设计原则是贴近真实——不追求标注完美，追求分布真实。

这一层评测的价值在于发现”分布漂移”。如果模型在回归集上表现稳定，但在真实分布集上掉了，说明用户的行为变了，你的评测集该更新了。

评测的工程化

评测集建好只是开始。真正让它变成护城河的，是把评测跑成自动化流水线。

我的每个项目的评测流水线长这样：

• 触发：每次 PR 自动跑冒烟集，每次合并到 main 自动跑回归集，每月定时跑真实分布集。
• 报告：跑完后自动生成报告，包含总分、分层分、与上次版本的 diff。diff 比绝对分更重要——它告诉你”这次改动的净效果”。
• 门禁：回归集分数下降超过 2 个百分点的 PR 不能合并。这一条会逼着你在改动时考虑”会不会破坏现有表现”。

门禁这一条最关键，也最难执行。因为很多时候你改 prompt 是为了解决一个具体问题，但这个改动会牺牲其他场景的表现。没有门禁，你会无意识地”拆东墙补西墙”；有门禁，你被迫找到真正更好的解法。

反模式

我见过最多的评测反模式有三种：

反模式一：用 LLM 当裁判。用 GPT-4 给 GPT-3.5 的输出打分。看起来省事，但 LLM 裁判有自己的偏差——它偏好长答案、偏好结构化答案、偏好和自己风格相似的答案。用 LLM 当裁判比没有评测好，但不要把它当成 ground truth。

反模式二：评测集和训练数据混在一起。把评测集放进了微调数据里。这就像考试题泄露到了练习册里——分数虚高，上线后原形毕露。

反模式三：只看总分不看分层。总分从 82 提到 85，看起来是进步。但拆开看可能是”简单题从 90 提到 95，难题从 70 掉到 65”。这种改动上线后，用户感受是”简单问题更快了，但我问的难题它反而不会了”。

评测的真正价值不是给你一个分数，而是给你一个”敢不敢改”的判断依据。没有评测体系的系统，每次改动都是赌博；有评测体系的系统，每次改动都是实验。

结语

评测体系是 AI 产品最被低估的资产。它不可见——用户看不到、老板看不到、demo 时也用不上。但它是唯一能让你持续、可控地改进系统的东西。

模型会换、prompt 会改、数据会变，但只要评测体系在，你就能度量每一次改动、复现每一次结果、避免每一次回归。这才是长期壁垒。