评测的起点：为什么我们需要给AI打分
第 1 章 评测的起点：为什么我们需要给 AI 打分
2016 年 3 月 23 日下午,微软在 Twitter 上线了一款名为 Tay 的聊天机器人,目标用户是 18 到 24 岁的美国年轻人。微软的工程师们希望 Tay 能通过与网友的对话不断学习,变成一个"懂年轻人"的对话伙伴。然而仅仅 24 小时后,微软就被迫关闭了 Tay——因为 Tay 在 Twitter 上发表了大量种族主义、性别歧视和反犹太言论,成为 AI 史上最著名的失控案例之一。
Tay 的失败并非技术上的"错误",而是设计上的"缺测"。微软在发布前并没有建立完善的评测体系来检测 Tay 在敏感话题上的输出是否安全。最终,一群恶意用户通过反复向 Tay 输入极端言论,利用其在线学习机制把 Tay"教坏"了。
这个故事引出了本书的第一个核心问题:当我们训练出一个 AI 系统时,我们究竟凭什么判断它是"好的"? 对于传统软件,我们可以用单元测试、集成测试、功能测试层层把关,因为代码的行为是可预期的:同样的输入,永远产生同样的输出。但对于 AI 系统,事情变得复杂了——同一个问题,模型今天回答得可能和明天不一样;同一个模型,面对不同用户可能给出完全不同方向的回复。那么,我们到底要如何"打分"?
这一章,我们将从历史教训出发,逐步构建起一个完整的 AI 评测思维框架。我们会看到,AI 评测不是简单的"对错判断",而是一个融合了技术、心理学、社会学和工程管理的复杂系统工程。在本章末尾,我们将正式提出"评测驱动开发"(Evaluation-Driven Development, EDD)这一贯穿全书的工程方法论。
---
1.1 AI 评测的历史教训:从 Tay 到 GPT 的演进
要理解 AI 评测为什么重要,最好的方式不是从理论开始,而是从"事故"开始。每一次重大的 AI 失败,都在提醒我们:评测体系的缺失会带来真实世界的代价。
1.1.1 Tay 事件:在线学习的失控
让我们更细致地解剖 Tay 事件。Tay 的技术架构包含三个关键组件:对话生成模块、用户画像模块和在线学习模块。当 Tay 与用户互动时,系统会记录用户的输入和 Tay 的回复,并将这些数据用于实时微调模型参数。这种设计在技术上并非不合理,但它完全忽略了一个核心问题:恶意用户的输入不应该被当作"有效训练数据"。
问题的本质在于:评测体系缺失。微软在 Tay 发布前只做了基础的语法检查和"不能骂人"之类的关键词过滤,但没有建立以下几类关键评测:
- **毒性评测(Toxicity Evaluation)**:在数百个敏感话题上,Tay 能否保持立场一致?
- **诱导抵抗评测(Adversarial Robustness)**:面对带有引导性的恶意输入,Tay 能否识别并拒绝?
- **价值观一致性评测(Value Consistency)**:在不同语境下,Tay 的回答是否始终符合预设的伦理边界?
- **长期行为漂移评测(Long-term Drift Evaluation)**:经过 1000 次、10000 次对话后,Tay 的行为是否还保持在安全范围内?
事后复盘报告指出,微软在 Tay 内部测试阶段仅评估了"对话的自然度",而完全没有评估"对话的安全性"。当一个评测维度被遗漏时,所有的优化目标都会向那个维度倾斜——这就是典型的"指标盲区"。
1.1.2 Amazon 的招聘 AI:隐藏的偏见
如果说 Tay 的失败是"显性的",那么 2018 年曝光的 Amazon 招聘 AI 事件则是"隐性的"。Amazon 内部开发了一套简历筛选 AI,目的是从海量简历中自动识别出最有可能被录用的候选人。系统训练数据来源于 Amazon 过去 10 年的招聘记录——而在科技行业,这些记录本身就带有明显的性别失衡。
当这套系统被部署后,工程师们发现:AI 会系统性降低包含"女子"(women's)一词的简历评分,例如"女子篮球俱乐部队长"会被扣分,而"男子篮球俱乐部队长"则不会。更严重的是,即使简历中不直接出现性别词汇,AI 也能通过推断学校、社团等间接信息做出带有偏见的判断。
这个案例的核心教训是:评测不能只看"准确率",还要看"公平性"。一个模型在传统机器学习指标(比如分类准确率)上可能表现完美,但它可能在不同人群、不同群体上存在系统性偏差,这种偏差只有专门的公平性评测才能发现。
Amazon 最终在 2018 年解散了这个项目。但它留下了两个重要的遗产:第一,引发了整个行业对 AI 公平性的关注;第二,推动了"差异性影响分析"(Disparate Impact Analysis)等评测方法的发展。
1.1.3 GPT 的"幻觉":自信地说错话
到了大语言模型时代,AI 评测面临的新挑战是"幻觉"(Hallucination)——即模型会一本正经地编造事实。
想象一下,你问 GPT 一个关于某位历史人物生平的细节问题。即使模型从未在训练数据中见过准确答案,它也不会说"我不知道",而是会用流畅的语言"编造"一个听起来非常可信的答案。如果你是一名学生,你可能就把这个错误答案当成了正确知识。
这种"自信地说错话"的行为,本质上反映了评测体系的盲区。大语言模型的传统评测指标(困惑度、BLEU 分数等)衡量的是"生成文本的流畅度和相似度",而非"生成内容的真实性"。这就导致了一个荒谬的局面:模型可能越流畅、越自信,反而越容易传播错误信息。
针对幻觉问题,业界发展出了"事实性评测"(Factuality Evaluation)、"可追溯性评测"(Attribution Evaluation)等新维度。例如,HuggingFace 发布的 HaluEval 基准测试,专门用于评估模型识别和避免幻觉的能力。
1.1.4 评测演进的三个时代
回顾历史,我们可以清晰地看到 AI 评测演进的三个时代:
第一代(规则时代,1990s-2010s):评测主要依赖人工编写的规则和关键词匹配。例如判断一个对话系统是否"礼貌",就看它是否包含"请""谢谢"等关键词。这种方式简单直接,但完全无法理解语义。
第二代(统计指标时代,2010s-2020s):随着深度学习的兴起,业界发展出 BLEU、ROUGE、METEOR 等基于统计的自动评测指标。这些指标在机器翻译、文本摘要等任务上取得了一定成功,但对开放性生成任务的评测能力有限。
第三代(大模型与多维评测时代,2020s-至今):随着 GPT-4、Claude 等大模型的出现,评测进入了"以模型评模型"的新阶段。研究者开始使用大模型作为"评判员"(LLM-as-a-Judge),同时构建包含安全性、公平性、事实性、价值对齐等多维度的评测体系。这一阶段的评测不再是单一分数,而是一个多维的质量画像。
理解这段历史,对我们有三重启示:第一,评测不是"事后诸葛亮",而是 AI 系统的"神经系统";第二,每一次技术进步都会暴露新的评测盲区;第三,好的评测体系必须能够随着 AI 能力一起进化。
---
1.2 评测金字塔:三层校验的智慧
了解了历史教训后,我们自然会问:那么一个完整的 AI 评测体系应该长什么样?答案是"评测金字塔"——一个由业务指标、用户反馈、离线基准三层构成,自上而下、由实到虚的评测体系。
1.2.1 顶层:业务指标——评测的"终极裁判"
任何 AI 系统的最终目的都不是"模型表现多好",而是"业务结果有多好"。业务指标位于评测金字塔的最顶层,是所有评测活动的"终极裁判"。
举几个例子:
- 对于一个推荐系统,业务指标是点击率(CTR)、转化率、客单价、GMV(商品交易总额);
- 对于一个客服机器人,业务指标是问题解决率、平均处理时长、客户满意度(CSAT)、人工接管率;
- 对于一个内容生成 AI,业务指标是用户停留时长、二次创作率、广告点击率;
- 对于一个自动驾驶系统,业务指标是事故率、接管次数、行程完成率。
业务指标之所以重要,是因为它直接反映了 AI 系统在真实世界中的价值。一个模型即使在离线基准上拿了 100 分,如果它上线后用户都跑了,那它就是失败的。
然而,业务指标也有它的局限性:它变化慢、归因难、成本高。一个电商网站的转化率下降,你很难立刻判断是 AI 推荐出了问题,还是市场环境变了,还是用户群发生了变化。调整业务指标往往需要 A/B 测试、大样本、长周期。
1.2.2 中间层:用户反馈——最真实的体验数据
中间层是用户反馈。这是来自真实用户的声音,可以是显式的(点赞、差评、问卷调查),也可以是隐式的(点击、停留、跳出、复访)。
用户反馈的重要性在于:它直接来自"上帝视角"——用户。用户的评价虽然有时片面,但他们的"用脚投票"是任何评测指标都无法替代的。
我们常见的用户反馈机制包括:
- **评分机制**:五星评分、Thumbs Up/Down、表情反馈;
- **文本反馈**:用户主动填写的评价、吐槽、建议;
- **行为信号**:点赞、点踩、分享、收藏、二次访问;
- **客服工单**:用户主动投诉或求助的内容;
- **NPS(净推荐值)**:用户是否愿意向他人推荐。
但用户反馈也有自己的陷阱:
1. 极端化偏差:只有特别满意或特别不满意的用户才会主动反馈,中间的大多数沉默用户的声音被忽略了; 2. 主观性强:不同用户对"好"的定义差异巨大,一个创意写作 AI 的"文采"几乎无法用统一标准衡量; 3. 时间错位:用户当下给出的反馈,可能受到无关因素影响(比如心情、天气、对界面颜色的偏好); 4. 激励扭曲:如果评分会影响奖励或惩罚,用户可能给出策略性反馈而非真实反馈。
因此,用户反馈必须与上下两层结合使用,才能形成完整的判断。
1.2.3 底层:离线基准——可控的实验场
最底层是离线基准(Offline Benchmark),也就是我们通常说的"测试集"和"评估指标"。在模型上线之前,我们会用一组预先准备好的数据集对模型进行评估。
离线基准的优势是可控、可重复、可比较。你可以反复跑同一个测试,得到稳定的结果;你可以对比模型 A 和模型 B 在完全相同条件下的表现;你可以在模型上线之前就发现严重的问题。
常见的离线基准包括:
- **学术基准**:GLUE、SuperGLUE、MMLU、HELM 等通用语言理解基准;
- **领域基准**:MedQA(医学)、LegalBench(法律)、HumanEval(代码)、GSM8K(数学推理);
- **安全基准**:TruthfulQA(真实性)、BBQ(偏见)、HarmBench(有害性);
- **任务基准**:每一类特定任务都有专门的测试集,例如对话质量、摘要忠实度、翻译流畅度。
但离线基准也有它致命的弱点:它和真实场景之间存在"分布偏移"(Distribution Shift)。你的测试集可能只覆盖了真实场景的 5%,而那 95% 的"长尾问题"在测试集中根本没有出现。当模型上线后,它会遭遇大量训练和测试时从未见过的输入,这时候离线基准的高分就变得毫无意义。
1.2.4 三层之间的相互校验
评测金字塔的三层不是孤立的,而是相互校验、相互补充的关系。
```mermaid flowchart TD L1[业务指标层<br/>核心 KPI] --> L2[用户反馈层<br/>满意度与行为] L2 --> L3[离线基准层<br/>测试集与指标] L1 -.一致性校验.-> L2 L2 -.诊断定位.-> L3 L3 -.能力基线.-> L1 L1 -.归因分析.-> L3 L3 -.风险预警.-> L1 L2 -.体验洞察.-> L1 ```
让我们具体看一下三层之间的校验逻辑:
业务指标 → 用户反馈:当业务指标下降时,我们需要去用户反馈中寻找原因。是因为用户觉得推荐不准?还是因为界面设计有问题?用户反馈给业务指标提供了一个"诊断视角"。
用户反馈 → 离线基准:当用户在抱怨某个具体问题时,我们需要把这个问题转化为离线基准中的测试用例。用户的吐槽是构建高质量测试集的最好来源——这是"以用户为中心"的评测哲学。
离线基准 → 业务指标:离线基准必须在发布前证明自己的有效性。如果一个模型的离线基准分数很高,但上线后业务指标反而下降了,那么这个基准就有问题,需要调整。
业务指标 → 离线基准:反过来,业务指标的成功也可以反向优化离线基准——把对业务有正向贡献的案例加入测试集,把对业务有负面影响的案例加入测试集的"反例区"。
用户反馈 → 业务指标:用户反馈是对业务指标的"早期预警系统"。在业务指标大幅波动之前,用户反馈往往已经出现异常——那些给出差评的用户,可能正在流失。
离线基准 → 业务指标:离线基准是业务指标的"风险防线"。在上线前,我们用离线基准挡住那些明显有问题的模型,避免它们对业务造成实际损害。
三层之间的校验关系可以总结为一句话:离线基准告诉你"能不能上线",用户反馈告诉你"用户怎么看",业务指标告诉你"到底有没有用"。三者缺一不可。
---
1.3 AI 评测与传统软件测试的八大根本差异
很多工程师第一次接触 AI 评测时,会自然地把它类比为软件测试。但 AI 评测和传统软件测试之间存在根本性的差异。理解这些差异,是建立正确评测思维的前提。
1.3.1 差异一:确定性 vs 概率性
传统软件:同样的输入,永远产生同样的输出。这是软件工程的基本公理,也是测试能起作用的基础。
AI 系统:同样的输入,可能产生不同的输出。即使是 temperature 参数设为 0 的情况下,现代大模型在底层浮点运算的非确定性中也可能给出略微不同的回答;更不用说各种采样策略(temperature、top-p、top-k)本身就是为了引入变化性。
这种概率性意味着:AI 评测不能只看一次结果,必须看多次结果的统计分布。一个模型在 100 次回复中,有 90 次是正确的,那它的可靠率是 90%,而不是 100%。这就引出了一个新的评测维度——"一致性"或"稳定性"。
1.3.2 差异二:正确答案 vs 合理答案
传统软件测试:有明确的"对"和"错"。1+1 等于 2,不是 2 就是错的。
AI 系统:很多任务没有"标准答案"。给"请写一首关于秋天的诗"这个 prompt,一千个诗人能写出一千首完全不同的诗,它们都可能是"好的"。评测一个开放式 AI 的回答,我们无法用"对错"来评判,只能看它是否"合理""有用""符合预期"。
这迫使我们引入"参考答案集"(Reference Set)和"质量维度"(Quality Dimensions)的概念。我们不要求 AI 输出唯一的"标准答案",而是要求它的输出落在"合理范围"内。
1.3.3 差异三:单元可测性 vs 涌现行为
传统软件:可以分解为函数、模块、组件,每个单元可以独立测试。一个排序算法错了,我们能精确地定位到第几行代码。
AI 系统:尤其是深度学习模型,其行为具有"涌现性"(Emergent Behavior)——某些能力不是设计出来的,而是在大量数据训练后"涌现"出来的。一个 GPT-4 的"幽默感",我们说不清它在哪个具体的参数里;一个自动驾驶系统的"判断力",我们也没法拆解成几个子模块独立测试。
这种涌现性意味着:AI 评测必须更接近"端到端"的真实场景,而不是过度依赖单元级别的拆解。我们需要在完整的输入输出链路上评估 AI,而非孤立测试某个中间环节。
1.3.4 差异四:可控性 vs 不可控性
传统软件测试:测试环境完全可控。我们可以模拟各种异常情况(网络中断、磁盘满、内存溢出),并精确地观察系统行为。
AI 系统:很多行为难以预测。模型可能在某个看似无害的输入下产生有害输出("jailbreak"攻击就是典型例子);模型可能在训练数据中的某个边缘案例上犯奇怪的错误("对抗样本");模型的"黑箱"特性使得我们很难从根本上修复某些问题。
这种不可控性要求我们:AI 评测必须采用更广泛、更对抗性的测试策略。我们不仅要在"正常输入"上测试,还要在"恶意输入""模糊输入""边界输入""对抗输入"上测试。
1.3.5 差异五:静态 vs 动态演化
传统软件:版本一旦发布,行为就固定了。下次发版才会改变。
AI 系统:很多 AI 系统会持续学习、持续更新。一个新闻推荐 AI 在 1 月 1 日的表现可能和 1 月 2 日不同,因为它学习了用户昨晚的行为;一个对话机器人每天都在积累新的对话数据。
这意味着:AI 评测不能是一次性的,而必须是持续性的。我们必须建立"持续评测"(Continuous Evaluation)机制,在模型的生命周期内不断监控其表现,警惕"模型漂移"(Model Drift)的发生。
1.3.6 差异六:功能正确性 vs 综合体验
传统软件测试:主要关注"功能是否正确"。程序能不能跑、计算结果对不对、异常是否处理。
AI 系统:不仅要关注功能正确,还要关注"综合体验"。一个客服机器人,即使它回答的内容是事实正确的,如果它的语气傲慢、回复冗长、答非所问,用户依然会觉得它"很差"。一个图像生成 AI,即使像素值接近参考图,如果画面丑陋、构图混乱,也毫无价值。
这意味着:AI 评测必须是多维度的。我们需要同时评估"准确性""有用性""无害性""流畅性""美观性""创造性""一致性""情感温度"等多个维度。
1.3.7 差异七:开发者视角 vs 用户视角
传统软件测试:主要从开发者视角出发。开发者写测试用例,覆盖自己代码的功能路径。
AI 系统:必须同时考虑开发者视角和用户视角。用户用 AI 的方式常常出乎开发者的预料——他们会问一些工程师想不到的问题,会要求一些没有规划过的功能,会在完全不同的语境中使用 AI。
这就是为什么"用户评测"在 AI 领域如此重要。开发者写再多的测试用例,也覆盖不了真实用户的千奇百怪。
1.3.8 差异八:结果可复现 vs 评测可复现
传统软件测试:测试结果可复现。今天跑和明天跑,结果一样。
AI 系统:测试结果可能因为模型权重更新、硬件差异、随机种子等因素而变化。更微妙的是,评测本身的可复现性也成了挑战。如果评测依赖大模型作为评判员,那评判员模型本身的版本变化也会导致评测结果不一致。
因此,AI 评测需要建立"评测的可复现性规范":固定模型版本、固定评测集版本、固定评测代码、固定硬件环境、固定评测参数,这样多次评测的结果才能比较。