从合成数据到线上崩盘：评测集陷阱全复盘

去年Q4我们上线了一个基于DeepSeek-V3的工单分类系统，离线测试准确率高达92%，但上线后实际工单处理准确率暴跌至68%。这场事故暴露了评测集构造中的致命盲区。

阶段1：构造评测集的三个错误

1. 合成数据占比失控：为了快速扩充测试集，用模板生成75%的工单样本。这些样本遵循完美语法且问题边界清晰，与真实用户潦草的工单描述差距巨大
2. 难度分层缺失：未区分简单查询（"网络连不上"）和复杂场景（"VPN连接后OA系统HTTP 500"），导致模型在简单样本上刷分
3. 负样本过乖：竞品错误案例仅采集明显错误（如完全无关的分类），忽略了真实场景中的灰色地带

阶段2：离线评测的虚假繁荣

• 采用标准准确率指标时未做切片分析
• 测试集推理速度是真实流量的3倍（合成文本平均长度仅真实工单的60%）
• 关键发现：当强制使用真实工单的token长度分布重新评测，准确率立即下降11个百分点

阶段3：线上shadow测试的救命稻草

部署时采用双路推理： 1. 生产流量实时走现有系统 2. 并行发送到新模型但结果仅记录不返回

三周数据揭示出： - 对<30字短工单准确率保持89% - 对含多个故障现象的复合工单准确率仅41% - 当用户使用方言词汇（如"光猫"代替"调制解调器"）时错误率激增

修正方案与检查清单

1. 真实数据占比强制要求：
2. 核心场景必须≥60%真实用户数据
3. 合成数据需通过「脏数据模拟器」（随机插入错别字、删除标点等）
4. 难度标定体系：

   # 工单复杂度计算公式（示例）
   def complexity_score(text):
       term_count = len(jieba.cut(text))
       tech_term_ratio = count_technical_terms(text)/term_count
       return 0.4*term_count + 0.6*tech_term_ratio

5. 动态评测集机制：
6. 每月收集top 100模型错误案例
7. 当新错误类型占比>15%时触发评测集更新

评测集构建的工程细节

• 数据收集管道：
• 从生产环境抽样时需保留完整上下文（如用户后续追问记录）
• 使用DeepSeek-V4的embedding聚类功能自动发现语义相似的问题簇
• 标注质量控制：
• 对模糊case采用三方标注+仲裁机制
• 建立标注员-模型争议案例库（占比约8%的边界样本最值得关注）
• 压力测试设计：
• 模拟高峰时段3倍流量冲击
• 注入5%的对抗样本（如故意打乱语序的工单）

模型迭代中的评测策略

1. 版本对比测试：
2. 新旧模型在相同流量下AB测试
3. 关键指标：首次解决率（避免连环追问）
4. 错误模式分析：
5. 使用DeepSeek-V4的attention可视化定位高频错误路径
6. 对「模型自信但错误」的案例重点优化
7. 冷启动方案：
8. 新业务上线前采集种子数据时，同步构建mini评测集（200-300样本）
9. 允许前两周的评测指标波动范围±15%

成本与效率平衡

• 自动化回归测试：
• 核心场景用例100%自动化（占每日测试量的30%）
• 边缘场景采用抽样测试
• 资源分配原则：
• 80%测试资源用于top20%高频场景
• 长尾问题每月集中测试一次

关键教训

评测集不是一次性的静态资产。采用DeepSeek-V4后，我们建立了「线上错误→评测集更新→模型迭代」的闭环，使生产环境准确率稳定在87%以上。记住：离线分数只是入场券，真实场景才是终极考场。

延伸思考

• 当业务指标和模型指标冲突时（如准确率下降但首次解决率上升），该如何决策？
• 如何设计跨语言评测集（如中英文混合工单）？
• 模型迭代频率与评测集更新周期的最佳实践是多少？