评估即产品能力

一句话定义

在 AI 产品中，评测体系不是 QA 的附属环节，而是与模型、交互并列的核心产品能力——评测驱动开发（Eval-Driven Development）要求任何影响输出的变更（提示词、模型、检索、参数）都必须先过评测集再上线。

为什么重要

AI 产品的迭代速度由评测体系决定：有评测的团队一天能安全试十个提示词版本，没有评测的团队一次改动都要靠「上线看看」赌运气。模型可以买到、交互可以抄，唯一难以速成的是与业务分布匹配的评测体系——它既是质量的度量衡，也是迭代的安全网，还是 kp-009 数据飞轮的枢纽。

前置知识

kp-012 统计性验收标准（评测体系的单次验收形态）。

核心概念

• 评测驱动开发（EDD）的三条纪律：①需求即指标——任何能力需求必须同时给出指标定义与阈值（kp-011 第 6 章）；②变更必回归——提示词、模型版本、检索策略、温度参数，凡影响输出者，发布前必须跑评测集且不回退；③评测集是活文档——随 badcase（kp-023）与真实 query 持续扩充，版本化管理。
• 评测的三类裁判：程序化校验（格式、字段、规则——快而窄）、LLM-as-a-Judge（用强模型按评分标准给开放输出打分——快而需校准）、人工评审（金标准——慢而准，抽样使用）。三者分层组合，人评用于校准另外两者。
• 与传统测试的本质差异：被测对象从「确定性函数」变为「概率函数」，测试结论是统计推断（kp-012），且测试集本身是被测能力定义的一部分——「考纲」即「能力边界」。
• 组织归属：评测集的 owner 应是产品（定义什么是好），算法与工程共同维护管道；「产品写考纲、工程建考场、算法答卷」是健康分工（协作细节见 kp-032）。

原理与机制

EDD 起作用的机制链条：概率性输出使「局部验证」失效（改一句提示词可能影响所有输出的分布），唯有「全量回归」能给出安全信号；回归的前提是评测集稳定且贴近真实分布；于是质量迭代的速度被评测管道的吞吐量决定——这是「评测即能力」的工程含义。LLM-as-a-Judge 可扩展人评的原因是评分标准（rubric）可以被显式化并由强模型稳定复现（MT-Bench 等研究证明了与人类偏好的一致性），但必须定期用人工评审样本校准其偏差（如偏爱长答案），否则裁判自己会漂移。三层裁判的组合本质是把「人工金标准」的成本通过分级复用摊薄。

公式或模型

不适用——方法与组织框架类内容；单指标的公式与置信下限见 kp-012。

图示

实例或案例

同一团队改造前后的对比：改造前，提示词改动全靠资深同事「肉眼扫一轮」，一次措辞调整导致客服回复的拒答率从 2% 飙到 15%，两天后才由客诉暴露；改造后，50 条安全类评测题进入每次发布的前置门禁，同类问题在 CI 阶段即被拦截。评测集的 50 条题目只花了两天建设，却把这类事故的发现时间从「天」压到「分钟」——这就是把评测当能力而非当流程的差别。

常见误区

• 评测是上线前的仪式：只在里程碑评测，日常迭代裸奔；正确形态是评测进 CI，每次变更必跑。
• 只建不养：评测集半年不更新，与真实分布脱节，指标「全绿」而用户流失——评测集必须随 kp-023 的 badcase 持续换血。
• LLM 裁判免检：不做人评校准的 LLM 评审会系统性漂移（如偏爱冗长回答），重要指标必须保留人工抽检锚点。

直观类比

评测体系之于 AI 产品，如同体检体系之于职业运动员：没有体检的球队也能踢球，但无法科学判断谁能上场、训练有没有效果、伤病何时发生；体检项目本身也要随赛季演进——考纲即能力边界的活地图。

自测题

1. 为什么「局部验证」在 AI 产品中失效？

要点：输出是分布且提示词全局生效，局部改动会改变整体输出分布，只能靠覆盖全任务的评测集回归。

1. 三类裁判如何组合与校准？

要点：程序校验管硬约束，LLM 评审管开放质量的规模化，人工评审做金标准；人评定期校准 LLM 裁判偏差。

1. 「评测集是活文档」的操作含义？

要点：版本化、随 badcase 与真实 query 持续扩充、与开发集隔离（kp-012），并进入发布门禁。

与其他知识点的关系

kp-021 给出评测集建设的具体步骤与清单；kp-022 把离线评测延伸到线上灰度；kp-023 是评测集换血的燃料管道；kp-032 定义评测评审会的组织机制。

延伸阅读

• "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena"，Zheng et al.，2023——LLM 评审有效性及其偏差的系统验证。