引言：
在大语言模型（LLM）加速落地的今天，性能指标的提升固然令人振奋，但真正决定用户体验与产品可信度的，往往是那些“答错了”“说不清”或“不该说”的瞬间——即我们常说的 bad case。这些看似零散的失败案例，实则是模型能力边界与系统脆弱性的直接体现。
一、什么是 bad case？
Bad case 指的是模型在实际应用中表现不佳的输出，例如：
- 回答错误或事实性错误（如编造信息、答非所问）
- 逻辑混乱、自相矛盾
- 输出不完整或截断
- 生成有害、偏见、不安全内容
- 语言不通顺、语法错误
- 无法理解用户意图或上下文
- 响应延迟过长或无响应
二、如何判断 bad case？
-
人工评估（Human Evaluation）
- 抽样检查：定期从线上日志中随机抽样用户对话，由专业标注人员评估回答质量。
- 评分体系：建立多维度评分标准，如相关性、准确性、流畅性、安全性等，采用 Likert 量表（如1-5分）打分。
- A/B 测试对比：对比新旧模型在同一 query 下的输出，判断改进是否有效。
-
自动化检测（Automated Detection）
- 关键词/正则匹配：识别敏感词、错误模式（如“我不知道”、“抱歉”高频出现）。
- 毒性检测模型：使用专门的分类器检测生成内容是否包含仇恨、歧视、暴力等。
- 一致性检测：通过多次生成或反向提问，检测回答是否自洽。
- 事实性校验：对接知识库或搜索引擎，验证回答中的关键事实是否准确。
- 响应长度/时间监控：异常短或过长的回答、响应时间超时可能为 bad case。
-
用户反馈信号
-
显式反馈：用户点击“不满意”、“举报”、“踩”等按钮。
-
隐式反馈：
- 用户重复提问同一问题
- 用户中断对话或跳出率高
- 用户修改提问方式（改写、澄清）
- 低停留时间或无后续交互
-
三、如何系统性收集 bad case？
-
建立日志记录系统
- 记录完整的输入（query）、输出（response）、上下文、时间戳、用户ID（匿名化）、模型版本等元数据。
- 标记用户反馈、系统异常、调用链路等辅助信息。
-
构建 bad case 管理平台
- 设立专门的数据库或看板，分类存储 bad case。
- 支持标签化（如“事实错误”、“逻辑混乱”、“安全风险”）、优先级标注、责任人分配。
- 支持搜索、去重、状态跟踪（待处理、已修复、验证通过）。
-
设置触发机制
- 自动化规则触发：如检测到“我无法回答”连续出现3次，自动上报。
- 用户反馈自动入库：用户点击“不满意”即进入审核队列。
- 模型置信度低时标记：若模型内部评分低于阈值，标记为潜在 bad case。
-
定期分析与复盘
- 按周/月统计 bad case 类型分布、高频问题、影响范围。
- 归因分析：是训练数据问题、推理逻辑缺陷，还是 prompt 设计不当？
- 推动模型优化：将典型 bad case 加入训练集（作为负样本或修正样本），或用于强化学习微调。
四、注意事项
- 数据隐私与合规：收集用户对话时需脱敏处理，遵守 GDPR 等隐私法规。
- 避免偏见放大：人工评估需多角色参与，防止主观偏见影响判断。
- 持续迭代：bad case 收集不是一次性任务，应融入模型生命周期管理。
总结：
判断和收集 bad case 需要“人工 + 自动化 + 用户反馈”三位一体的机制。通过系统化记录、分类、分析和闭环处理，才能持续提升大模型的鲁棒性与可靠性。
