模型评测为什么一接生产回放集就开始高分低检出：从 Replay Sampling 到 Complaint-Weighted Slice 的工程实战

⚠️ 生产回放集一接进来最危险的不是总分下滑而是真实故障被平均数吃掉很多团队把线上日志抽样成replay set后第一眼看到的是总分更稳了、波动更小了于是误以为评测体系更接近生产。⚠️ 真正的问题往往相反高频、短问、容易答对的样本占比太大退款、合规、长对话、工具失败这类真正会引发投诉的坏样本被稀释在平均值里。 离线分数看起来仍有86%线上却可能连续出现“答得像对其实关键一步错了”的事故。图 1生产回放一旦被头部简单流量主导真正昂贵的坏样本就会被平均分掩盖 随机回放为什么经常抓不到最痛的故障随机回放默认假设“流量分布等于风险分布”这在生产里几乎从不成立。 头部请求通常短、模板化、容易命中缓存尾部请求却更长、更依赖工具、更容易跨知识边界。 如果再把投诉工单、人工升级会话和回滚 case 都混在同一池子里评分器看到的只是大样本稳定而不是关键缺陷的检出率。某客服模型灰度中随机回放5万条样本得到89.1%通过率但和投诉单对齐后真正覆盖到高风险退款意图的只占6.8%。图 2头部简单流量、尾部复杂任务和投诉样本的风险密度并不相同方案总体通过率高风险投诉覆盖率上线后 7 天投诉检出率随机回放89.1%6.8%41.3%分层回放87.9%18.4%63.7%Complaint-Weighted Slice86.8%31.6%79.4%️ 更稳的做法是按投诉强度、流量占比和新鲜度做 Complaint-Weighted Slice更可用的生产评测不是继续把回放池做大而是先把样本切成“头部稳定流量、尾部复杂任务、投诉回灌样本、最新变更样本”四层再分别设权重。✅ 其中投诉回灌不该只按数量加权还要看严重级别、重复出现频次和是否已经触发人工接管。这样算出的分数才更接近真实损失。 当某一层样本在最近72小时内集中失真时即使总体分数没掉也应该直接拦住发布。defslice_weight(sample):freshness1.2ifsample.age_hours72else1.0severity{p0:5,p1:3,p2:1}[sample.complaint_level]traffic0.8ifsample.bucketheadelse1.4returnfreshness*severity*traffic上线门禁不必追求复杂公式关键是让“最近刚出过事故的样本”在聚合时拥有更大话语权。 这样做以后评测从“算平均分”变成“看风险水位”。图 3先切层、再加权、最后聚合门禁才能把线上事故经验拉回离线评测 发布门禁别只盯总分还要盯检出率、投诉覆盖率和回放新鲜度更合理的门禁至少包含defect_detection_rate、complaint_coverage、replay_freshness_lag和rollback_slice_pass_rate四类指标。 如果总分达标但最近一周新增投诉类型没有被回放集吸收或者最新版本样本仍停留在旧提示词、旧工具链路上这套评测就不能证明“新版本真的更稳”。 笔者更看重的是高风险切片是否连续两轮通过、人工复核是否能复现、回滚样本是否在同一批数据里一起通过。图 4总分只是结果面真正能挡事故的是高风险检出率、投诉覆盖率和样本新鲜度 接下来 3 到 6 个月生产评测会从静态 Benchmark 走向反馈闭环接下来3到6个月真正拉开差距的不会是谁再堆一套更大的静态基准而是谁先把投诉、升级、回滚和新流量变成持续回灌的评测闭环。 生产评测的价值不是给模型贴一个更好看的分数而是更早暴露那些“只错一次就足够贵”的坏样本。 如果你的离线分数一直不低线上却总在同一类问题上翻车更该先查的是模型能力还是回放样本的权重设计