线上 badcase 归档的价值与痛点

在 LLM 生产环境中，badcase 归档常被视为「事后处理」环节，但实际是模型迭代的核心燃料。DeepSeek 团队在处理客服工单场景时发现：未结构化的 badcase 堆积会导致三类问题——

1. 修复滞后性：相同语义的 query 因表述差异被分散记录，工程师需人工聚合分析
2. 典型案例：用户用「付不了款」「支付失败」「无法完成支付」描述同一问题，却被记录为三个独立案例

3. 解决方案：引入语义相似度聚类（如 Sentence-BERT），合并相似度 >0.85 的案例

4. 评测偏差：回归测试集未涵盖高频 badcase 模式，线上改进无法反映在离线指标

5. 根本原因：测试集通常基于历史正向样本构建，缺乏对抗性样本

6. 改进措施：动态将线上 badcase 按比例（建议 15%-20%）注入测试集，保持评估压力

7. 数据泄露风险：用户敏感信息混在日志中，直接导出可能违反合规要求

8. 高危场景：医疗/金融领域对话中包含病历号、银行卡信息等
9. 防护方案：实施字段级脱敏规则，建立数据导出审批流程

DeepSeek 的 badcase 处理流水线

阶段一：自动化捕获与脱敏

• 触发条件（需根据业务调整阈值）：

• 脱敏实施要点：
• 采用正则表达式 + 命名实体识别双重检测
• 对企业定制字段建立映射表（如 JD_12345 → <ORDER_ID>）
• 保留脱敏记录供审计追踪

阶段二：特征提取与分类

除代码示例中的基础特征外，还需补充：
- 上下文分析：检查是否因多轮对话状态丢失导致错误
- 知识库关联：验证 RAG 返回的文档是否相关（可用 BM25 评分辅助判断）
- 时效性检查：对比问题发生时间与知识库更新时间，识别过期信息问题

阶段三：版本化存储与回溯

• 存储设计原则：
• 元数据与对话内容分离存储
• 支持按模型版本号（如 deepseek-v4-0325）快速筛选
• 保留原始请求的 API 参数（特别是容易被忽视的 top_p 和 frequency_penalty）
• 回溯工具链：
• 开发比对功能：并列显示不同版本模型在同一 badcase 的表现
• 支持导出为 CSV 供进一步分析

数据闭环的工程实现

1. 与评测系统联动（详细流程）

• 测试集更新机制：
• 每周自动运行 badcase 去重聚类
• 人工标注团队对新增案例打标（错误类型/严重程度）
• 系统按 3:1 比例采样注入测试集（确保原有正例占比不低于 75%）
• 对抗训练注意事项：
• 控制 badcase 样本在训练数据的占比（通常 5%-8%）
• 对过拟合样本添加降权系数

2. 配置中心集成（实战技巧）

• 实时降级策略：
• 当某类错误 5 分钟内出现 ≥3 次，自动切换至规则引擎
• 降级后记录 fallback 路径，便于后续分析
• 训练数据增强：
• 对高频 badcase 生成同义句扩增（使用 T5 或 GPT 生成变体）
• 在数据流水线中标记增强样本来源

避坑指南（含排障方法）

存储规范

• 错误做法：直接保存含用户 ID 的完整对话日志
• 正确操作：
• 剥离会话标识符转为 UUID
• 对对话内容进行不可逆哈希处理
• 单独加密存储敏感字段

过拟合预防

• 检测手段：
• 监控修复前后在保留测试集上的指标波动
• 特别关注准确率提升但 F1 值下降的情况
• 缓解方案：
• 对修复样本添加对抗权重
• 采用 KL 散度约束输出分布

生命周期管理

• 清理策略：
• 对已修复案例保留 90 天
• 建立白名单机制保护典型教学案例
• 效果验证：
• 每月随机抽样 5% 已关闭案例进行回归测试

扩展应用场景

• 客服质量监控：通过 badcase 分布识别薄弱知识领域
• 产品优化：高频 badcase 可反推界面设计问题（如支付流程卡点）
• 合规审计：统计敏感问题触发频率，优化风控规则

实施该方案后，DeepSeek-V4 在工单场景的改进包括：
- badcase 复发率从 22% 降至 14%
- 平均修复周期缩短 64%（依赖自动化分类效率提升）
- 用户满意度（CSAT）提升 11 个百分点

关键成功因素在于建立「收集-分析-修复-验证」的完整闭环，并通过工程化手段降低人工介入成本。建议每季度回顾 badcase 分类体系，及时调整以适应业务变化。