夜雨聆风
一篇文章讲清楚AI评测是什么,怎么做
做 AI 不评测，等于闭着眼睛开车——开得越快，死得越惨。
一、AI时代下，你如何保障你的产品
在 AI 时代，测试工程师的工作范式正经历一场深刻转变——从确定性测试走向概率性测试。
传统的功能测试和接口测试，曾经是保障产品质量的核心手段。然而，在 AI 产品中，这些确定性方法已经难以完全保证产品的准确性。过去，一个输入对应一个确定的输出（1:1 关系），测试结果是非黑即白的”通过”或”不通过”。而在 AI 时代，输入与输出的关系变成了多对多（N:N），”通过”与”不通过”不再是一个二元判断，而是一个概率值。
面对这种变化，我们该如何转变测试方案，才能有效保障 AI 产品的质量？
要回答这个问题，我们需要先建立一个关键认知：**AI 产品的质量保障，核心在于评测体系的构建。而在动手搭建新体系之前，有必要先认清几个长期存在的认知误区——只有避开这些坑，我们才能真正明白评测应该做什么、怎么做
二、关于 AI 评测的三个常见误区
在讲怎么做之前，先要纠正几个根深蒂固的错误认知。这些误区我见过太多团队踩过坑，希望你看完之后可以完美避开。
误区一：”评测就是跑个分”
这大概是最普遍的误解了。
很多人一提到 AI 评测，脑子里立刻蹦出各种 benchmark：MMLU 多少分、GSM8K 多少分、HumanEval 多少分。分数高就是好模型，分数低就是差模型。
但你想过没有，这些 benchmark 测的是什么？测的是模型在通用题目上的表现。就像高考——它考察的是学生的综合能力，但它不能告诉你这个学生到了你们公司能不能干好具体的活。
一个 MMLU 考 90 分的模型，在你家的客服场景里可能答非所问。一个 HumanEval 满分的模型，写你公司内部的业务代码照样 bug 满天飞。
真正的评测要回答的问题是：AI 在你的具体场景下，能不能解决具体的问题。
跑分只是手段之一，而且往往是最不靠谱的那个。高考状元不代表工作能力强，benchmark 高分也不等于业务场景好用。这是两件相关但完全不同的事。
误区二：”评测是测试同学的事”
不少团队的做法是：AI 产品开发完了，丢给测试团队，说”你们测一下吧”。
这就好比一家餐厅，菜都做完了才让服务员去尝尝好不好吃。问题是，菜好不好吃，取决于食材采购、菜谱设计、厨师手艺，这些环节服务员一个都管不了。
AI 评测也是一样，它不是某一个角色的单方面任务，而是需要多方协作的系统工程。
-
产品团队负责定义”什么是好”——用户要什么，场景是什么，成功的标准是什么 -
算法团队负责提供”怎么测”——用什么指标，设计什么评测集，用什么方法评估 -
业务团队负责验证”有没有用”——上线后效果好不好，用户买不买账
缺了任何一环，评测都是不完整的。产品不介入，评测就没有方向。算法不配合，评测就没有方法。业务不参与，评测就没有结果。
误区三：”上线前测一次就够了”
这个误区的危害最大，也最隐蔽。
很多团队的节奏是：开发 → 测试 → 上线 → 撒花。评测被视为上线前的一个检查点，过了就万事大吉。
但 AI 不是传统软件。传统软件上线后，只要代码不改，行为就不会变。你今天输入 A，输出 B；明年输入 A，还是输出 B。测一次就够了。
AI 不一样。AI 面临着三个持续变化的因素：
-
数据在变：用户的提问方式在变，业务数据在更新，外部世界在演进 -
环境在变：上游系统改了接口，下游依赖换了版本，整个链路都在动态调整 -
模型在变：如果你用的是在线 API，模型本身也在持续更新，今天的”好”不代表明天的”好”
更重要的是，模型会”遗忘”和”退化”。就像学生考上大学后如果不再学习，高中知识也会慢慢忘光。AI 也一样，不持续评测，你根本不知道它什么时候开始变差了。
评测不是一次性的考试，而是定期的体检。 上线不是终点，只是起点。
三、AI 评测考什么：核心指标拆解
纠正完认知误区，接下来进入正题——AI 评测到底要看什么。
在深入具体指标之前，先回答三个基本问题，这三个问题搞清楚了，评测的大方向就不会偏。
第一个问题：为什么测？
答案很朴素：验证 AI 能不能解决业务问题，能不能持续满足需求。不是为了出一份好看的成绩单，而是为了回答一个最实在的问题——这东西到底好不好用。
第二个问题：测什么？
根据你的具体场景来确定。客服场景测回答准确率，搜索场景测结果相关性，代码场景测代码正确率。没有放之四海而皆准的评测对象，一切以你的业务需求为准。
第三个问题：怎么测？
这就涉及到评测集的设计、指标的选择、流程的制定。后面会详细展开。
接下来重头戏来了——四个你必须知道的核心评测指标。别被名字吓到，我会用大白话逐一拆解。
1. 准确率（Accuracy）：答对了多少
这是最直观、也最容易理解的指标。
定义很简单：所有测试题目中，AI 答对的比例。100 道题答对了 85 道，准确率就是 85%。就像考试算总分一样。
类比：期末考试，100 分的卷子你考了 85 分，准确率就是 85%。
听起来完美对吧？但它有一个致命弱点——当样本不均衡的时候，准确率会骗人。
举个例子：假设你要做一个垃圾邮件检测 AI，你的邮箱里 99% 都是正常邮件，只有 1% 是垃圾邮件。这时候如果一个 AI 不管什么邮件都判定为”正常”，它的准确率高达 99%——但它对垃圾邮件的检测能力是零。
所以当各类别样本数量差不多的时候，准确率是个好指标。但面对不均衡的数据，它就不够用了。
2. 精确率（Precision）：AI 说”是”的时候，靠谱吗
精确率回答的是这样一个问题：当 AI 判断某件事”是”的时候，它有多少次真的说对了？
类比：老师说”这道题你肯定能考好”，结果你真的考好了——这就是高精确率。老师说”你能考好”但你考砸了——这就是低精确率，老师在”误报”。
精确率高的 AI，意味着它说”是”的时候你可以比较放心地相信它。
什么场景最需要高精确率？ 误报代价很高的场景。
比如医疗诊断 AI，如果它把没病的人诊断为有病（误报），会导致不必要的恐慌和检查。比如反欺诈 AI，如果把正常交易判定为欺诈（误报），会直接影响用户体验和业务收益。
在这些场景里，我们宁愿漏掉一些，也不愿意冤枉好人。这就是高精确率的价值。
3. 召回率（Recall）：该找的全找出来了吗
召回率回答的是另一个问题：所有应该被找出来的东西，AI 找到了多少？
类比：期末考试，你有 10 道题是复习过应该会的，结果你实际答对了 8 道——召回率就是 80%。漏掉的那 2 道就是”漏报”。
召回率高的 AI，意味着它不太容易漏掉重要的东西。
什么场景最需要高召回率？ 漏报代价很高的场景。
比如癌症筛查 AI，如果漏掉了一个真正的患者（漏报），后果可能非常严重。比如安全告警系统，如果漏掉了一次真正的攻击（漏报），可能造成巨大损失。
在这些场景里，我们宁愿多报几次，也绝对不能漏掉真正的问题。这就是高召回率的价值。
4. F1 分数：不偏科才是真强
看到这儿你可能发现了一个问题：精确率和召回率好像经常是矛盾的。
提高精确率，意味着 AI 说”是”的时候更谨慎——但谨慎的代价就是可能漏掉一些真的”是”，召回率就下降了。
提高召回率，意味着 AI 要尽可能把所有”是”都找出来——但找得太宽，就会把一些不是的也当成”是”，精确率就下降了。
这就像考试里的偏科问题——数学满分但语文不及格，或者反过来。
F1 分数就是精确率和召回率的调和平均数。 它要求两个指标都得好，任何一个拉胯都会把 F1 分数拉下来。
类比：一个学生数学 90 分、语文 90 分，F1 分数很高。另一个学生数学 100 分、语文 60 分，F1 分数就会低很多。F1 告诉你：偏科不行，综合能力强才是真的好。
什么时候用 F1？ 当你既不能容忍太多误报，又不能容忍太多漏报的时候——大多数业务场景都是这种情况。
一张表帮你秒懂
为了让你快速记住这四个指标，我做了一张对比表：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
下次再有人跟你聊评测指标，你直接把这张表甩出来。
四、怎么出题：评测集的设计原则
有了指标，接下来需要一个关键东西——评测集。
评测集就是一组用来测试 AI 的题目集合。就像高考试卷，试卷出得好不好，直接决定了考试成绩有没有参考价值。
一份好的评测集，必须满足三个关键属性。
1. 独立性：不能让 AI “背题”
评测数据不能和训练数据重复。这是一个基本原则，但被很多团队忽视。
想象一下，如果高考题目和高三模拟卷一模一样，那考试还有什么意义？学生不需要理解知识，只需要记住答案就行了。
AI 也是一样。如果你的评测集里的题目，AI 在训练的时候已经见过，那它表现好不是因为能力强，而是因为它”背过答案”。这种评测结果毫无参考价值。
实操要点：
-
训练集和评测集要严格隔离 -
评测集最好从真实用户问题中提取，而不是人工编造 -
定期轮换评测集，防止 AI “记住”了题目
2. 标准性：每道题都要有”判卷标准”
每道评测题目都要有明确的”标准答案”或”评判标准”，否则没法判断 AI 回答得对不对。
你可能会说，AI 的任务很多是开放性的，比如”帮我写封邮件”、”总结一下这篇文章”，哪来的标准答案？
但即使是开放性任务，也要有评分标准。就像高考作文，虽然是开放写作，但评分标准很明确：立意、结构、语言、内容各占多少分。
对于 AI 评测也一样。”帮我写封邮件”这个任务，可以拆解为：格式是否正确、语气是否得当、信息是否完整、有没有错别字。每一项都可以打分。
没有标准，评测就是主观臆断。有了标准，评测才是客观衡量。
3. 大纲对标性：考什么要提前想清楚
评测集要覆盖你关心的所有能力和场景。就像考试大纲——大纲要求考哪些知识点，试卷里就要包含这些知识点的题目。
如果你的 AI 要处理 5 种类型的用户咨询，评测集里每种类型都要有题目，不能只测其中最好测的两种。如果你关心 AI 在中文、英文、代码三个方面的能力，评测集就要覆盖这三种语言。
一个常见的错误是：评测集只覆盖 AI 擅长的领域，测出来分数很好看，但上线后用户问了不擅长的问题就翻车。
实操建议：
-
从业务场景出发，梳理出所有需要覆盖的场景类型 -
每个场景收集足够多样化的真实样本（不要只收集”好测”的） -
定期更新评测集：淘汰过时的题目，补充新的场景
出题是一门技术活，出得好，评测才有意义。
五、AI 评测的难题：从”确定性”到”不确定性”
聊完了指标和评测集，接下来要坦诚地说一说 AI 评测这件事真正的难处。
如果你以前做的是传统软件的测试，转来做 AI 评测，你会明显感觉到一个巨大的变化：从确定性走向了不确定性。
传统软件 vs AI：两种完全不同的评测逻辑
传统软件的评测相对简单直接。输入 A，应该输出 B——这是一个确定的映射关系。
比如一个计算器的加法功能：输入 1 + 1，输出一定是 2。你测一次就知道了，今天测是 2，明年测还是 2。如果某天输出变成了 3，那一定是代码被改坏了，定位起来也很清楚。
但 AI 大模型完全不是这么回事。
同样一个问题”帮我推荐一家附近的餐厅”，你问它三次，可能得到三个完全不同的回答。第一个推荐了火锅，第二个推荐了日料，第三个开始跟你讨论饮食文化。
哪个算对？哪个算错？
这就引出了 AI 评测面临的四大挑战。每一个都是硬骨头。
挑战一：组合爆炸——你永远穷举不完
用户会怎么提问，这件事是完全不可预测的。
同样是问天气，有人会说”今天天气怎么样”，有人会说”外面冷不冷”，有人会说”我需要带伞吗”，有人会说”今天适合晾衣服吗”。
一个 AI 客服每天可能收到几万条用户提问，每一条的表述方式都可能不一样。你不可能把每一种问法都写进评测集里。
这就是组合爆炸——输入的可能情况是天文数字，穷举测试是不可能的。
类比：你教了一个学生”如何回答天气相关的问”，但考试的时候，出题人可以用一万种不同的方式问天气相关的问题。你没法针对每一种问法都做一次练习。
挑战二：任务边界模糊——什么叫”好”？
传统软件的答案通常是非黑即白的。代码跑通了就是跑通了，没跑通就是没跑通。
但 AI 的很多任务没有唯一的正确答案。
“帮我写一封给客户的道歉邮件”——怎样算好？
-
写得简洁算好吗？但有些客户希望看到诚恳的长文 -
写得礼貌算好吗？但过于客套可能显得不真诚 -
包含所有关键信息算好吗？但信息太多可能让人抓不住重点
不同的人对”好”的定义可能完全不同。甚至同一个人在不同心情下，评价标准也可能变化。
任务边界模糊意味着：AI 评测很大程度上是一个主观判断的过程，很难做到像传统软件那样完全客观。
挑战三：难以定位归因——出了问题怪谁？
当 AI 回答错误的时候，最让人头疼的问题来了：到底哪里出了问题？
是基础模型能力不够？是 Prompt 写得不好？是检索到的参考文档有问题？是系统提示词设计不合理？还是知识库里的数据过时了？
类比：一道菜做出来不好吃，原因可能有很多——食材不新鲜、厨师手艺差、菜谱本身有问题、火候没掌握好、甚至锅都不好使。你得一个个排查。
在传统软件里，一个 bug 通常可以追溯到某一行代码。但在 AI 系统里，一个 bad case 可能涉及链路中的任何一个环节。定位问题的成本比修复问题本身还要高。
挑战四：评测成本高昂——测不起也测不完
人工评测费时费力。找一堆标注人员，一道题一道题地看 AI 的输出，然后打分。一套几千条的评测集，一个人可能要测好几天。而且人会疲劳、会走神、会前后标准不一致。
自动化评测倒是快，但准确度又不够。用规则或脚本来判断 AI 的回答好不好，面对开放性任务基本无能为力。
大规模评测要精度就没效率，要效率就没精度。 这是一个两难的选择。
六、应对策略：AI 评测实战指南
说了这么多困难，不是为了劝退，而是为了让你知道：这些坑大家都踩过，而且有办法绕过去。
接下来给出四个实战策略，每一个都是被验证过有效的方法。
策略一：用更强的模型当”裁判”
这是当前最主流、也最有效的策略之一。
核心思路很简单：既然人工评测太慢，规则评测不准，那不如用一个更聪明的大模型来做”裁判”，让它来评估你的 AI 输出质量。
比如你的产品用的是一个 7B 参数的小模型，你可以用 GPT-4 或 Claude 这样的大模型来给小模型的输出打分。你给裁判模型一段评分标准，然后让它判断：这个回答是否准确？是否完整？是否有帮助？
这种做法的优势很明显：
-
效率极高：大模型一秒钟能评几十条，人工一天才能评几百条 -
可规模化：评测集从 100 条扩大到 10 万条，成本增加很小 -
一致性相对好：大模型的评分标准相对稳定，不会像人一样疲劳走神
但它也有局限，需要清醒认识：
-
裁判模型本身也有偏差和盲点，不是绝对公正的 -
对于某些非常专业或非常主观的任务，大模型的判断可能还不如人工 -
所以它不能完全替代人工，只能作为主力手段
最佳实践：用大模型做大规模初评，人工定期抽检校准。两者互为补充。
策略二：在产品设计阶段就设计好评测方案
这条策略听起来简单，但能做到的团队不多。
很多团队的节奏是这样的：先想好要做什么 AI 产品 → 开发 → 快上线了才想起来”我们得评测一下” → 匆忙搞一个评测集 → 跑个分上线。
正确的节奏应该是这样的：在定义产品需求的那一刻，就想清楚怎么评测。
具体来说，在需求阶段就要回答四个问题：
-
这个 AI 要解决什么问题？ —— 明确场景和目标 -
成功的标准是什么？ —— 定义什么样的表现算合格、算优秀 -
用什么指标衡量？ —— 选择准确率、F1、还是其他指标 -
评测数据从哪来？ —— 提前规划数据来源和标注方案
为什么要在这么早的阶段就想这些？因为如果你到了开发阶段才发现评测数据拿不到，或者发现成功标准定义不了，那前面的开发工作很可能都白费了。
类比：建房子之前要先想好怎么验收——墙面平整度怎么量、水电怎么测试。不能等房子盖完了才说”我们来看看这房子好不好”。那时候发现问题，拆了重盖的成本就太高了。
策略三：建立持续评测机制——上线才是开始
再强调一遍：上线不是终点，而是评测的起点。
持续评测机制包含三个关键动作：
第一个动作：定期回归测试。 每周或每月用同一套评测集跑一遍，监控指标的变化趋势。如果某一周 F1 分数突然下降了 5 个百分点，那一定有什么地方出了问题，需要立刻排查。
第二个动作：用户反馈闭环。 把用户标记为”不满意”的回答、用户踩了”没有帮助”的回答，定期收集起来，补充进评测集。这些是真正的”实战题目”，比任何人工设计的题目都值钱。
第三个动作：评测集版本管理。 评测集不是一成不变的。随着业务发展和场景变化，旧的题目可能不再相关，新的场景需要新的题目。给评测集做好版本管理，确保每次评测都基于最新的版本。
一个健康的评测体系应该像一个飞轮：评测发现问题 → 改进 AI → 用户更满意 → 新的用户反馈补充进评测集 → 下一轮评测发现新问题 → 持续改进。飞轮转起来，AI 就越来越强。
策略四：人机结合——效率和精度我都要
最后一条策略，也是最实用的一条。
面对评测成本和精度的两难选择，最聪明的做法不是二选一，而是结合两者的优势。
**自动化评测做”初筛”**：
-
用规则检查格式是否正确、必填信息是否完整 -
用大模型做批量评分，覆盖尽可能多的测试用例 -
快速筛选出明显合格和明显不合格的 case
**人工抽检做”终审”**：
-
对自动化评测的结果进行抽样复核，确保评分标准没有偏移 -
重点审查边界 case 和有争议的 case -
定期校准自动化评测的标准，防止”裁判跑偏”
推荐的配比：80% 的 case 用自动化评测覆盖，20% 的 case 做人工复核。这个比例可以根据你的业务精度要求调整，但原则上一定是自动化为主、人工为辅。
因为纯人工评测的扩展性太差，而纯自动化评测的质量不可控。人机结合才能在效率和精度之间找到最佳平衡点。
七、没有评测的 AI，就像没有仪表盘的飞机
写到这儿，关于 AI 评测的核心内容基本都覆盖了。最后做个简短的总结。
回顾一下今天聊的几个关键点：
-
AI 评测不是跑分，而是验证 AI 在你的具体场景下能不能解决具体问题。benchmark 高分不等于业务好用。 -
AI 评测不是测一次就够，而是需要持续进行的定期体检。模型会退化，环境在变化，评测不能停。 -
AI 评测不是某一个人的事，而是需要产品、算法、业务多方协作的系统工程。 -
核心评测指标——准确率、精确率、召回率、F1，各有适用场景，理解它们的区别才能选对指标。 -
好的评测集需要具备独立性、标准性和大纲对标性，出题水平决定了评测的价值。 -
面对评测的挑战，我们可以用更强的模型当裁判、在 PID 阶段提前设计评测方案、建立持续评测机制、人机结合来提升效率。
有一句在工程和管理领域被广泛引用的话：**”你无法优化你无法衡量的东西。”**
做 AI 也是一样。没有评测的 AI，就像没有仪表盘的飞机——你不知道飞得有多高、还剩多少油、前方有没有山。你觉得自己在前进，但很可能已经偏离了航线。
AI 评测就是那把尺子。有了它，你才知道自己站在哪里，该往哪里走。
互动时间
你的团队是怎么做 AI 评测的？踩过哪些坑？有什么好方法？欢迎在评论区分享你的经验和困惑。
如果觉得这篇文章对你有帮助，欢迎转发给需要的同学。后续我会持续更新 AI 相关的实战内容，欢迎收藏关注。
附录
A. 常见评测工具/平台推荐
如果你准备动手搭建自己的评测体系，以下几个工具可以作为起点：
-
Ragas：专注 RAG（检索增强生成）场景的评测框架，擅长评估回答的忠实度和相关性，开源免费 -
DeepEval：面向大语言模型的单元测试框架，支持多种评测指标的自动化检测，适合工程团队集成到 CI/CD 流程中 -
LangSmith：LangChain 官方评测平台，提供从追踪到评测的一站式工具，适合使用 LangChain 生态的团队 -
Promptfoo：开源的 Prompt 评测工具，适合快速对比不同 Prompt 的效果，轻量好用