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

⚠️ 生产回放集一接进来，最危险的不是总分下滑，而是真实故障被平均数吃掉

很多团队把线上日志抽样成replay set后，第一眼看到的是总分更稳了、波动更小了，于是误以为评测体系更接近生产。⚠️ 真正的问题往往相反：高频、短问、容易答对的样本占比太大，退款、合规、长对话、工具失败这类真正会引发投诉的坏样本，被稀释在平均值里。📉 离线分数看起来仍有86%，线上却可能连续出现“答得像对，其实关键一步错了”的事故。

🔍 随机回放为什么经常抓不到最痛的故障

随机回放默认假设“流量分布等于风险分布”，这在生产里几乎从不成立。🔍 头部请求通常短、模板化、容易命中缓存；尾部请求却更长、更依赖工具、更容易跨知识边界。📌 如果再把投诉工单、人工升级会话和回滚 case 都混在同一池子里，评分器看到的只是大样本稳定，而不是关键缺陷的检出率。某客服模型灰度中，随机回放5万条样本得到89.1%通过率，但和投诉单对齐后，真正覆盖到高风险退款意图的只占6.8%。🧪

🛠️ 更稳的做法，是按投诉强度、流量占比和新鲜度做 Complaint-Weighted Slice

更可用的生产评测，不是继续把回放池做大，而是先把样本切成“头部稳定流量、尾部复杂任务、投诉回灌样本、最新变更样本”四层，再分别设权重。✅ 其中投诉回灌不该只按数量加权，还要看严重级别、重复出现频次和是否已经触发人工接管。这样算出的分数，才更接近真实损失。💡 当某一层样本在最近72小时内集中失真时，即使总体分数没掉，也应该直接拦住发布。

defslice_weight(sample):freshness=1.2ifsample.age_hours<72else1.0severity={"p0":5,"p1":3,"p2":1}[sample.complaint_level]traffic=0.8ifsample.bucket=="head"else1.4returnfreshness*severity*traffic

上线门禁不必追求复杂公式，关键是让“最近刚出过事故的样本”在聚合时拥有更大话语权。🧠 这样做以后，评测从“算平均分”变成“看风险水位”。

📊 发布门禁别只盯总分，还要盯检出率、投诉覆盖率和回放新鲜度

更合理的门禁至少包含defect_detection_rate、complaint_coverage、replay_freshness_lag和rollback_slice_pass_rate四类指标。📊 如果总分达标，但最近一周新增投诉类型没有被回放集吸收，或者最新版本样本仍停留在旧提示词、旧工具链路上，这套评测就不能证明“新版本真的更稳”。🚦 笔者更看重的是：高风险切片是否连续两轮通过、人工复核是否能复现、回滚样本是否在同一批数据里一起通过。

🚀 接下来 3 到 6 个月，生产评测会从静态 Benchmark 走向反馈闭环

接下来3到6个月，真正拉开差距的不会是谁再堆一套更大的静态基准，而是谁先把投诉、升级、回滚和新流量变成持续回灌的评测闭环。🚀 生产评测的价值，不是给模型贴一个更好看的分数，而是更早暴露那些“只错一次就足够贵”的坏样本。🙂 如果你的离线分数一直不低，线上却总在同一类问题上翻车，更该先查的是模型能力，还是回放样本的权重设计？