从客服机器人到AI写作助手，评测集的高分与用户真实体验的割裂成为产品经理的集体困境。本文通过3年实战案例，揭示评测集为何成为'温室成绩'，拆解用户表达、多轮对话、分布漂移等真实场景与评测设计的根本冲突，并给出从日志反构评测集、badcase倒灌等5个实用解法，带你重新思考AI产品效果评估的底层逻辑。
前几天翻硬盘，翻出来一份三年前的评测报告，那会儿在做一个客服机器人，评测集准确率从 78 拉到 92，整整磨了三个月。报告发出来那天，组里几个人去楼下撸串，喝到一点多。第二天灰度上线，反而投诉了剧增。
那段时间我特别拧巴。每天上班第一件事就是打开评测审视数据，多跑几遍结果。跑出来还是 92，可线上日志里全是骂街的。一开始我们怀疑是灰度策略问题，又怀疑是某个版本回滚没干净，折腾了快两周才慢慢想明白，评测集这东西，它本来就不等于真实用户。
不是说它没用。是我们用它的方式有问题。
这篇就把这几年陆陆续续想到的、踩到的，攒一块儿写写。没什么体系，就是一些经验。
我最早做 AI 写作助手那阵，评测集里有一类任务叫”根据主题写开头”。两千条样本，每条都标了参考答案，相关性、流畅度、原创性、长度合规，维度铺得也是满满当当。
跑出来八十几分，比上一版高了七八分，当时挺得意。
结果上线第二天，运营同事甩给我一张截图，用户在小地瓜发的：
“这 AI 写得跟我们公司行政发通知一样，一股班味。”
下面还有评论说”我让它写 50 字它给我 500 字”、”我打错俩字它就完全听不懂了”。
我回去翻那两千条样本，主题清晰、长度明确、表达规范，好多还是直接从公众号优质文章里摘的。模型在这种输入上表现好，太正常了。
可真实用户打字是什么样？错别字、半截句、中英文混着来、夹方言、夹黑话、好几个需求拌在一句话里，甚至他自己都没想清楚要啥。
所以我后来一直觉得，评测集跑得好，更像是模型在温室里能开花。产品做得好不好，得看它能不能在野地里活下来。这俩事不打架，但真不是一回事。
这点说起来挺玄乎，但其实特别直观。
评测集里一条样本，就是个静态切片：输入、输出、打分，完事。它默认用户问一句模型答一句，然后就 game over 了。
但用户用产品哪是这样啊。
举个例子。用户说”帮我写个朋友圈，发产品的”。按评测逻辑，模型生成一段，打个分，结束。
真实场景里呢，用户接下来通常会来这么一串：
太长了。短一点。
别那么硬广。
加点情绪。
再来一版。
……算了第一版好像也行。
帮我配个表情包。
整个过程是反复横跳的。最后用得爽不爽，跟第一轮答得多好没太大关系，关键是这一整段下来顺不顺。
之前做 Agent 项目这个感受最深。Agent 评测里有个指标叫任务完成率，单看一轮的完成率根本看不出问题。很多任务用户是分了三四轮才说清楚自己要啥的。第一轮就一个模糊意图，第二轮补参数，第三轮又改主意。你单轮指标再漂亮，最后用户是不是真把事办成了，是另一回事。
这事说不上谁的错。评测的颗粒度和用户的颗粒度，本来就不一样。
这点我之前忽略了好久。
评测集的样本分布，几乎不可能跟真实用户分布对上。因为评测集是被”设计”出来的，要追求维度覆盖、场景均衡、难度梯度。真实用户分布是自己长出来的，不均衡、有长尾、还会随着时间漂。
我之前做过一个知识问答产品，评测集很认真地铺了八大类，每类两百条，加起来一千六。看着挺均衡。
上线之后拉日志，分布大致是这样：
而且有一大块问题根本不在我们那八大类里。怎么退订、怎么联系人工、什么时候有优惠、能不能开发票。这种问题评测集里一条没有，线上日志里占了快两成。
这就尴尬了。我们花大力气优化的那些维度，真实场景下根本没那么高的权重。用户最爱问的那些，评测集里基本是空白。
所以会出现评测集涨了 10 分、用户感知却没怎么变的情况。不是评测骗人，是我们一开始就没问对问题。
这事我做产品好几年才慢慢接受。
写评测样本的时候，脑子里其实有个隐含假设：用户会”合理、规范、聪明地”用产品。
用户不会的。
我以前看过一个产品的真实日志，本来是给职场人写文档用的工具，结果有人拿它写情书，有人拿它写小作文骂前任，有人让它扮演心理咨询师，还有人让它扮演女朋友哄自己睡觉。
写评测集的时候没人会想到这些。但用户就是会这么用。
而且这种”非预期使用”的占比常常不低。有些产品上线之后，最大的用户群体根本不是当初产品定位的那群人。我一开始觉得很离谱，后来发现这事儿太常见了。
接受了这点之后，做产品反而松弛多了。你不再追求覆盖一切可能性，而是去看用户实际在怎么用，再决定哪些场景值得投。
具体说，有几类东西评测集天然不太容易覆盖。我自己踩过坑的，大概这几样。
一是用户的表达方式有多野。同一个意图能有一百种说法。”帮我订张明天去上海的机票””明天上海机票””我要去上海最便宜的那种””出差去上海订票”。评测集里你撑死覆盖十几种，用户能贡献成百上千种。
二是上下文乱。用户说话从来不是孤立的，上一句聊天气下一句问机票；一段对话里穿插好几个不相关的话题；用代词指前面的东西，但他自己都忘了前面说过啥。评测集里的多轮是预设好的、干净的，真实多轮乱得多。
三是情绪。评测集里的”用户”是没情绪的，不会着急、不会愤怒、不会因为模型慢就不耐烦。真实用户都会。第一轮没拿到想要的答案，他可能直接关窗口走人，可能换一种很冲的问法。这些行为评测集模拟不出来。
四是时间会让一切漂。问题分布是会变的，热点、新品、政策、突发事件，都会让用户问的东西换一茬。评测集做得再全，三个月后也会过时。可很多团队的评测集，两年都没人动一下。
还有个边界问题。评测集能想到的攻击方式有限，真实用户里就是有人专门去试探模型，各种角色扮演、迂回提问、诱导话术。这些手法本身也一直在迭代。
不是说评测集没用。是说它有边界，认清这个边界，反而更知道怎么用它。
要的
评测集最大的好处是快、可控，跑一次结果是稳定的。改了一版东西，想知道有没有变差，跑评测集最快。要做不同模型对比，评测集是相对公平的标尺。要对外汇报，评测集给得出数字。
它的价值在开发阶段。到了产品阶段，它能告诉你”模型本身能不能干这事”，但告诉不了你”用户在真实场景下能不能用起来”。
打个不太精确的比方，评测集像体检报告，真实用户行为像患者主诉。体检报告告诉你哪些指标超标，可患者真正难受在哪儿，得听他自己说。两边都得看。
前面铺垫挺长，这段算是最实用的。我自己实践下来觉得有用的几件事，挑几个说。
第一件，评测集尽量从真实日志里反向构建。很多团队的评测集是产品经理拍脑袋写的，或者从公开数据集改改。这种评测集天然就跟真实用户隔了一层。反过来更靠谱，先收一段时间日志，从里面聚类、抽样，把高频场景提炼出来，再用这些去搭评测集。
第二件，badcase 要倒灌回评测集。线上发现的每一个 badcase，不能止步于”修一下”。得归类、沉淀、加进评测集，下次至少保证发现过的问题不会再回退。这事儿听着简单，能坚持做的团队没几个。
第三件，别只看一个综合分。综合 85 分的模型，可能在核心高频场景只有 70 分，在边缘低频场景反而 95 分。综合分会把这种不均衡抹平。按真实分布加权评一遍，结果才对业务有意义。
第四件，线上要有监控。很多团队对 AI 产品的运营理解还停在”上线，收 badcase，修”这个被动循环里。其实可以主动一点，搭个看板，盯满意度、对话完成率、多轮澄清率、放弃率、追问率、点踩率这些。指标变化往往比 badcase 收集更早反映问题。
第五件，开发评测和真实评测分开做。开发评测用构建好的评测集，目的是迭代快、知道有没有回退。真实评测用线上抽样日志，目的是看真实体验、发现新问题。两套并行，一个保速度，一个保方向。
说到这儿想多说一句不太”方法论”的话。
做 AI 产品越久，我越觉得产品经理最该养的能力，不是设计功能，也不是写 PRD，是慢慢养出一种对真实用户行为的感知！
这种感知没法速成。靠几次用户访谈、几份评测报告，是养不出来。它是每天看日志、看 badcase、看反馈，一点点磨出来的。
很多团队 AI 产品上线之后，产品经理注意力就转到下一个功能去了，模型效果交给算法和评测团队。这事儿说不上对错，但 AI 产品跟传统产品最大的区别就在于，它的效果会随时间漂移。用户在变、需求在变、内容在变、攻击方式也在变。
如果产品经理只看评测集那几个数字，时间一长，产品和真实用户之间的距离会比你想象的拉得更远。
我现在比较相信一件事：那些口碑慢慢起来的 AI 产品，背后多半有一个团队，每天都在很笨地看真实用户在说什么、在做什么、在拿这玩意儿干啥。
这事儿评测集可替不了。
本文由 @溪居即事 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。