智能客服上线后算法与运营团队的矛盾暴露出AI产品迭代的关键问题——缺乏统一的评测标准。本文深度拆解如何构建高质量的AI评测集，从定义业务范围、数据标注规范到搭建自动化流水线，揭秘如何用‘导航系统’解决团队自说自话的困境，实现模型迭代的科学决策。
智能客服上线一个月，算法同学说“准确率又涨了2个点”，运营同学却说“用户投诉更多了”。
——没有统一的测评集，大家都在自说自话。
很多人做AI产品，迭代全凭感觉：今天用户骂得多了，赶紧改一版；明天准确率报表涨了，就上线。这其实也反映了一个事实：
没有评测集，迭代就是拍脑袋。评测集就是你的导航系统。
告诉你当前在哪、该往哪走、走没走对。
一个好的评测集应该做到：
有了这个“导航系统”，算法改完模型不用等上线就知道效果好坏，产品做AB测试也有了基准。
这一步的目标是明确“考什么”以及“答案是什么”。
（1） 划定业务范围
与业务方（客服团队、运营）共同确定必须覆盖的用户意图。
我们当时定义了12个一级意图，比如：
原则：先覆盖高频意图（占80%流量），低频意图后期慢慢补。
（2） 制定标注规范
为每个意图制定清晰、无歧义的标注规范。例如：
关键：规范要写出来、培训到位、定期对齐。我们每周开一次标注对齐会，讨论争议案例。
目标是获取贴近真实用户的数据，并为它们打上正确的标签。
（1）数据来源
最佳来源是脱敏后的真实用户日志。我们拉了过去30天的对话记录，去掉了敏感信息（姓名、电话、地址），然后按意图分层采样。
冷启动期没有足够日志怎么办？可以用以下方式：
（2）数据增强
我们用大模型做了同义句扩展。比如基于“我要退款”这个种子，生成了：
每个意图扩展了 X 条同义问法，评测集从 X 条扩充到 X 条。
（3）标注与质检
我们组建了一个3人标注团队，核心原则：标注和审核角色分离。
这样做的好处：避免“自己标注、自己检查”导致的质量盲区。
我们用了 Label Studio 作为标注工具，免费、开源、支持多人协作。
一个笼统的评测集只能给出一个模糊的总分，而一个分层切片的评测集能告诉你具体哪里好、哪里差。
我们划分了三个子集：
通过这种切片分析，我们可以清晰地发现：“模型在核心场景上表现稳定，但在处理口语化表达时准确率明显下降 ，需要优化。”
有了评测集，我们搭了一套CI/CD流水线：
代码提交 → 烟囱测试（10条核心用例）→ 通过 → 模型训练 → 跑全量评测集 → 指标对比基线 ↓ 不通过 ↓ 下降超过阈值 阻断上线 阻断上线 ↓ 达标 自动部署上线
每次评测结果自动发送到企微群，附带详细报告：
坑一：标注标准不一致
两个标注员，一个认为“退钱”和“退款”是同一个意图，另一个认为应该分开。
解法：先制定《标注规范文档》，所有标注员培训+考试，通过才能上岗。每周开标注对齐会，讨论争议案例。
坑二：测试集过拟合
有一次模型在测试集上准确率涨了3%，但上线后用户反馈没变好。一查发现，算法把测试集中的某个高频样本偷偷加入了训练集。
解法：测试集由产品经理保管，算法团队拿不到原始数据，只能看到评测结果。
坑三：评测集增长太快
半年后测试集涨到了5000条，每次跑评测需要30分钟，影响迭代效率。
解法：定期对测试集做“瘦身”——删除重复的、过时的、低价值的样本，保持核心样本2000条以内。
除了自建，行业内也有一些通用的基准测试集和创新理念，可以作为补充参考：
这些不是必须的，但可以拓宽思路。
做了这么多，我最大的体会是：
评测集是一个活的东西。它需要持续维护、持续更新、持续和业务对齐。有了它，算法、产品、运营才能坐在一张桌子上说话。
我们的最终成果：
本文由 @嘻嘻李 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。