构建能预测线上质量的 50 道评测题
做测量的团队往往只测简单题，因为只有这些题有人事先知道答案。而真正会让你赔钱的，是那些没人想到要放进去的题。
发生了什么
一个团队建了 50 道题的评测集，分数很好看，上线，然后看着用户满意度在两个月里慢慢下滑，而所有指标纹丝不动。评测集没写错，只是不具代表性：它抽样的都是构建者事先知道答案的问题，而这些按定义就是系统处理得最好的那批。
为什么落地团队要在意
评测集是一台统计仪器，它唯一的职责是预测系统在没见过的流量上的表现。凭团队想象构建的评测集，会在团队恰好理解的那些维度上高估质量，同时对他们不理解的维度保持沉默——行业黑话、畸形查询、跨文档问题，以及语料根本答不上来的问题。
怎么建
能取到真实数据就取真实的：客服工单、搜索日志、销售被问到的问题。取不到的，让每天干这活的人来写，而不是让构建系统的人来写。然后强制配比：约 40 道可回答，难度分层；5 道必须用现有语料答不出来，用来检验系统是拒绝还是编造；5 道要配一份看起来相关、实际无关的干扰文档。
怎么保持可信
每季度换一批，并且开发过程中绝不让模型看到这份题，否则你就是在对它过拟合。每周抽样记录线上真实查询，检查它们是否还像你的评测集；一旦不像了，这份集就过期了。另外，把上下文召回率下降超过 5 个百分点当作构建失败处理——一个没人执行的指标，在截止日期前一周一定会被忽略。