这篇稿子拖了两个月。不是懒，是我最近在做一个新的“问数”项目——让AI帮业务同学查数据的那种。结果做的时候，把我之前那套评测集的三分法给干碎了。今天把最新的思考整理出来，算是全网首发，希望能帮你少走弯路。
1. 一个让我重新审视评测集的夜晚
去年我们做智能客服时，我写过一篇评测集的文章，当时用的是三分法：核心场景集（60%）、边缘场景集（20%）、高价值场景集（20%）。那会儿觉得挺完美的，分得清清楚楚，上线后准确率也涨了。
但最近做问数项目，我整个人的自信被按在地上摩擦。
问数项目的场景是这样的：业务同学问“昨天华北区的销售额是多少”，AI要理解“华北区”是哪些省份、“销售额”是含税还是不含税、“昨天”是自然日还是工作日。场景特别多，意图特别细。
我根据之前的learning搭了评测集：核心场景（查销售额、查订单量）、边缘场景（各种奇葩问法）、高价值场景（财务对账相关的）。然后推上去迭代。
结果两周后发现一个诡异的现象：模型在评测集上准确率稳定在87%，但业务同学天天抱怨“这个用不了”。我一查日志，发现模型在“环比增长率”这个低频但高价值的场景上，准确率只有30%。而这个场景，我在“核心场景”里没放（因为出现次数少），在“边缘场景”里也没放（因为不是错别字问题），在“高价值场景”里也没放（因为我分类太糙了）。
补上窟窿后，我思考了很久，发现突然场景不同，做测评的方法也需要“因地制宜”
2. 新框架：四个象限，把场景分清楚
以下就是我踩坑的经验，记录一下：以后可能还会再改，前一篇我晚点也发上来，记录过程。
第一类：核心高频场景（归集）
业务量最大、用户问得最多的那批问题。比如问数场景里的“查销售额”“查订单量”。
怎么干：归集。 把相同意图、不同问法的用例归并到一起，形成一个稳定的“基本盘”。这个盘的准确率必须高（比如98%以上），不然产品没法用。
我的教训： 一开始我没做归集，标注员给“查物流”的20种说法打了20个标签，重复劳动了三天。
第二类：高价值低频场景（先拆后收）
出现次数不多，但一旦出错就是大事故。比如问数里的“环比增长率计算”“同比口径解释”。
怎么干：先拆后收。 一开始把这些场景拆得特别细（比如“环比”拆成“日环比”“周环比”“月环比”），让模型分别学习。等模型能力上来后，再合并成一个泛化的“环比理解”能力。这个过程是动态的，不是一次搞定。
我的教训： 我刚开始没拆，把一个“环比”怼到模型里，结果它只学会了日环比，周环比完全崩了。后来拆开练，两周就好了。
第三类：边缘场景（定向）
用户的各种奇葩问法：错别字、方言、中英混搭、表情包。这些不解决吧，用户老骂；全解决吧，成本太高。
怎么干：定向优化。 挑出频率最高的那几个边缘类型（比如“错别字中的数字写错”），集中解决。其他的先记录，排期后面处理。
我的教训： 我试过一次性把所有边缘场景都塞进评测集，结果模型反而被带偏了，核心场景准确率掉了5个百分点。
第四类：可延后场景（忽略）
出现次数极少，而且就算答错了也不影响核心体验。这个是一开始就做了的，所以暂无案例。
怎么干：忽略，转人工或兜底。 不是所有场景都要硬啃。把资源和精力集中在前三类上。
我的教训： 不要相信业务说的“都很重要”，要有产品的决断力（数据说话也行），舍不得“丢”场景，评测集就会越滚越大，从1000条涨到5000条，跑一次要半小时，迭代效率暴跌。
3举两个例子，看看这套框架怎么用
案例一：退款场景
在原来的智能客服项目里，我们把“退款”当做一个核心场景，放了几十条同义问法。结果模型学了半天，还是分不清“破损退款”和“漏发退款”的区别——因为后端的业务动作完全不同。
用了新框架：
（1）先把“退款”拆成子类：refund_broken、refund_leak、refund_expired、refund_other
（2）分别标注、分别评测
（3）等模型在每个子类上都达到一定准确率（自定，比如90%）后，再尝试合并成一个大的refund意图，通过槽位区分
这个“先拆后收”的过程，我们花了三周，但最终准确率从70%提到了92%。
案例二：问数里的“环比”
业务同学问“昨天销售额环比增长多少”，模型经常算错，因为没理解“环比”要和昨天的昨天比。
我按照新框架：
（1）把“环比”拆成3个子场景：日环比、周环比、月环比
（2）分别标注样本，分别训练
（3）两周后，模型能处理了，我们再合并成一个泛化的“环比理解”能力
现在业务同学再问“环比”，模型不会再傻傻地只算日环比了。
4. 落地时我踩过的三个坑（帮助你们避开）
坑一：拆得太碎，维护成本爆炸
有一次我把“退款”拆成了10个子类，结果标注员每天要处理上千条，成本翻了三倍。
解法： 只有后端业务动作不同的才拆；如果只是用户表达差异，用同义问法覆盖，不要拆。
坑二：忘了“归集”，导致重复劳动
我让标注员给每个同义问法单独写标签，结果“查物流”有20种说法，标注了20次。后来才意识到应该先归集：把query_logistics作为一个评测单元，它的20个问法属于同一个用例。
解法： 归集是第一步，拆是第二步。不要跳过归集直接拆。
坑三：可延后变成了“永不解决”
定了“可延后场景”后，PM每次排期都说“这个先延后”，结果三个月后积累了200多个可延后场景，变成了技术债。
解法： 设硬性门槛：单月出现少于X次才可延后，并且每个版本至少解决10个之前延后的场景。
5. 哪些还可以再优化
新框架比老三分法好，但仍然有搞不定的地方：
（1）什么时候拆，什么时候收？ 根据场景（经验）来的， 没有绝对标准。比如当前我的经验是：当模型在某个大类上准确率卡在70%-80%之间、且后端业务动作有明显分支时，就拆。当子类准确率都超90%后，尝试合并。
（2）归集需要强大的标注规范。同一个意图的不同问法，不仔细看可能漏掉。我用了几个大模型生成同义问法，再让标注员确认，成本降了不少。
（3）边缘场景的优先级判断。错别字、方言、中英混搭，哪个先做？我用了一个公式：优先级 = 出现频次 × 用户情绪负面率。情绪越负面，优先级越高。
6. 结语：评测集是个活的东西
切换新项目以来，我最大的体会是：
我觉得评测集的构建不会是死的，而是一个随着业务切换/演进而不断调整的“tangle”。你不可能一次把它设计完美，但一定要有一套机制，让它能进化。
另外评测集，定期都需要跑一次，看看四类场景的准确率变化：
核心高频：稳定在一定准确率（根据业务实际来定，一般90%）以上才放心
高价值低频：关注“拆”和“收”的时机
边缘场景：挑Top5定向优化
可延后：控制数量，定期清理
同时需要关注，随着业务需求的变化，是不是场景存在跨列别的切换，比如突然从边缘到核心的情况，灵活应对即可。
这套框架我还在摸索中，如果你有更好的想法，欢迎沟通。评论区见。
老三分法考虑下看发不发了，感兴趣的可以去看我的视频。
