很多团队做 AI 产品时，前半段速度都很快。接模型、写 Prompt、配工作流、做出 Demo，往往几天内就能完成。但到了真正准备上线的时候，问题才会集中爆发。有人觉得回答变差了，有人发现同样的问题今天能答对、明天答错，还有人发现模型切换之后，某些核心场景直接退化。
这时候团队才意识到，自己缺的不是更多模型，而是一套可以持续复用的评测体系。
AI 评测最常见的误区，是把它理解成一次性验收。好像只要在上线前抽几条样例看看效果，就算完成了质量控制。但真实情况刚好相反。AI 系统的变化频率远高于传统功能：模型版本会变，Prompt 会变，工具链会变，知识库会变，甚至同样的请求在不同 provider 上也会有不同结果。如果评测不能跟着这些变化持续运行，所谓的质量就只是一种短暂错觉。
先定义“好”到底是什么
评测体系搭建失败，通常不是因为工具不够，而是因为一开始就没有把“什么算好结果”说清楚。很多团队的描述停留在“更像人”“更稳定”“更准一点”，这些说法在讨论会上没问题，但无法变成可执行标准。
我们通常会先把质量拆成更具体的几类目标：
- 正确性：答案是否事实正确，推理是否站得住。
- 完整性：是否覆盖了用户真正关心的关键点。
- 可执行性：输出是否能直接进入下一步流程。
- 稳定性：相似输入下，结果是否保持在可接受范围内。
- 安全性：是否出现越权、幻觉、泄露或不合规表达。
只有这些目标被写清楚，评测才能从“感觉”变成“标准”。
样本集不是越多越好，而是越贴近业务越好
很多团队一做评测，就先想着收集几千条样本。但如果样本集没有代表真实业务结构，再大的规模也只是噪音。真正重要的是覆盖面是否合理。
一套能工作的样本集，至少要包含四类内容：
- 高频主路径，也就是用户最常问、最影响体验的场景。
- 高风险路径，例如涉及金额、合规、流程执行的任务。
- 边界样本，包括模糊表达、脏数据、超长输入和异常格式。
- 对抗样本，用来验证系统在诱导、越权和误导输入下的表现。
我们更倾向于先做一套小而硬的样本集，保证它真的能代表业务，再逐步扩充，而不是一开始追求数量。
评分口径必须可复现
评测体系另一个大坑，是评分过于依赖人工直觉。今天 A 觉得这条回答“差不多可以”，明天 B 觉得“风险太高”，最后团队并没有形成统一口径。
一个更稳妥的做法，是把评分标准拆得足够细。比如某个客服场景，可以明确要求：
- 是否识别出用户意图。
- 是否引用了正确政策。
- 是否给出明确下一步动作。
- 是否包含不应承诺的内容。
这样即使最终仍需要人工复核，判断标准也会稳定得多。对一些结构化任务，还可以直接引入程序化检查，例如 JSON 格式是否正确、字段是否缺失、工具调用是否成功、返回值是否落在允许范围内。
回归评测必须进入发布流程
评测最有价值的地方，不是帮你知道“当前怎么样”，而是帮你知道“这次改动有没有把原本好的东西搞坏”。所以评测一定要进入发布流程，而不是变成一个独立仪式。
一个实用的发布链路通常包括：
- 修改 Prompt、模型、路由或工具配置后自动触发评测。
- 在核心任务集上跑回归，生成与上个版本的差异报告。
- 对高风险场景设置硬门槛，不达标就不允许发布。
- 灰度上线后继续收集线上样本，补回评测集。
这样做的好处是，团队不用每次都重新争论“要不要上线”，而是回到一套事先 agreed 的质量门槛上。
不要只评模型，要评整条链路
很多质量问题看起来像模型问题，实际上出在模型之外。检索召回不对，工具参数传错，上游接口超时，Prompt 拼接丢字段，最后都会表现成“模型回答差”。如果评测只盯着最终文本，就很难定位问题到底出在哪一层。
所以在平台实践里，我们更建议把评测对象从单个模型扩展到完整链路：输入预处理、检索结果、模型输出、工具调用、最终响应，每一步都应该能被抽样和回看。只有这样，评测结果才能真正指导优化，而不是只制造焦虑。
好的评测体系，最终会改变团队协作方式
评测做起来之后，最大的变化往往不是分数提高，而是团队讨论方式变了。产品、算法、工程、运营不再围绕抽象感受争论，而是围绕具体样本、具体指标和具体回归结果协作。每次改动的收益和风险都会更清楚，发布节奏也会更稳。
结语
AI 产品上线前，最该补的不是更多功能，而是更可靠的评测。它决定的不是“能不能做出一个 Demo”，而是“能不能把一个 Demo 变成可持续运营的产品”。当评测真正进入日常流程之后，质量才不再是上线前的一次冲刺，而会变成系统的默认能力。