当评测集与真实流量分布脱节时，那些漂亮的离线分数可能正在掩盖致命的线上风险。我们拆解过多个 DeepSeek 模型迭代案例，发现评测集过时导致的误判率可达实际生产环境的 3 倍。

合成数据的双重陷阱

1. 多样性幻觉：通过模板生成的问答对往往过度拟合已知模式。某金融知识库项目用合成数据测试时 F1 达 92%，上线后面对用户自然表述骤降至 67%。关键问题在于构造者潜意识规避了真实场景中的模糊指代和跨领域追问。
2. 难度塌陷：人工构造的「困难样本」常陷入两类极端——要么明显脱离业务场景（如故意拼错所有专业术语），要么因构造者思维定式变得可预测（如总在第三句插入干扰信息）。DeepSeek 在代码补全评测中曾发现，人工设计的「陷阱代码」有 78% 符合特定模式。

分布漂移的四种典型症状

• 指标倒挂：离线评测准确率提升 5%，线上 A/B 测试下降 2%
• bad case 突变：未在评测集中出现的长尾问题集中爆发（如客服场景中的方言处理）
• token 分布异常：log 分析显示高频 token 与评测集差异超过 30%
• 模型「作弊」：通过分析 attention 权重发现模型依赖评测集特有特征（如合成数据中的模板标记）

DeepSeek 的冻结策略实践

• 版本快照：每个大版本训练前冻结评测集，包括：
• 500 组真实用户 query（脱敏后，覆盖 90% 高频意图）
• 200 组对抗性改写（同义替换+干扰项注入，由不同团队独立构造）
• 100 组跨领域 OOD 样本（从相似业务场景采集）
• 50 组「陷阱样本」（已验证会引发错误但暂不修复的案例）
• 影子流量分流：线上请求 5% 流量同时发给新旧模型，对比时需排除：
• 接口超时（>500ms 的请求不计入）
• 非文本类错误（如 JSON 解析失败）
• 同一用户短时间内重复提问

可操作的漂移检测清单

1. 指标解耦监控（每周）：
2. 新旧评测集得分差异 >15% 触发审查
3. 合成数据正确率比真实样本高 20% 即预警
4. 不同难度层级样本的指标波动标准差超过 0.1 需排查
5. 数据层校验：
6. 检查高频 token 分布变化（使用 DeepSeek tokenizer 统计前 100 个 token 的 Jaccard 相似度）
7. 对未登录词比例设置阈值告警（建议阈值：评测集 ≤5%，线上 ≤15%）
8. 分析 bad case 中 N-gram 重叠率（与评测集重叠率 <30% 需警惕）

评测集更新的决策框架

graph TD
  A[发现指标异常] --> B{是否业务变化导致?}
  B -->|是| C[扩展现有评测集]
  B -->|否| D{是否模型缺陷?}
  D -->|是| E[修复模型并保留原评测集]
  D -->|否| F[重建 golden set]

何时必须重建评测集？

• 业务场景发生范式级变更（如新增产品线或交互模式）
• 核心指标连续 3 次迭代无显著差异（可能遇到天花板）
• 线上 bad case 分析发现高频模式未覆盖（占比 >10%）
• tokenizer 更新导致词汇表变化超过 20%

成本控制实践

• 冷热数据分层：将评测集分为三部分：
• 核心 golden set（100-200 样本，长期不变）
• 动态验证集（每月更新 30%）
• 压力测试集（极端 case，不参与常规评测）
• 自动化校验流水线：
• 使用 DeepSeek-API 的批量推理功能并行跑分
• 对每批新样本先做小规模（10%）人工审核
• 通过 SLO 看板监控评测耗时（建议 P99 <15 分钟）

最后记住：评测集不是越大约好，关键在分布代表性。我们建议保持 20%~30% 的样本定期轮换，但核心 golden set 必须长期保留作为基线。同时要警惕「评测集优化」陷阱——当发现模型在某类样本表现不佳时，优先考虑模型改进而非删除「难题」样本。