异常问题发现与 bad case 收集
任何 RAG 系统上线后，都不可能一步到位地完美回答所有问题。真实业务环境中的问题千变万化，知识库内容也可能存在模糊、矛盾或遗漏。要想持续提升系统质量，就必须建立一套机制，主动发现那些“答得不好”的情况，并将它们系统地收集、整理为可分析的 bad case。
1. 什么是 bad case
在 RAG 场景中，bad case 通常指以下几种表现：
- 事实性错误：回答内容与知识库中的正确信息不符，或出现了知识库中不存在的信息。
- 检索不到位：明明知识库中有最合适的文档，却没有被检索出来，导致回答依据的是次优甚至无关的片段。
- 拒绝回答或答非所问：系统错误地认为“未找到相关信息”，或者给出的答案偏离了用户问题的核心意图。
- 出处缺失或错误：回答虽然内容正确，但无法提供来源，或提供的来源指向错误的文档片段。
- 表述混乱：生成的内容语句不通顺、逻辑矛盾，虽然引用了正确材料但表达上让用户难以理解。
任何让用户皱眉、反复追问、或需要人工介入才能解决的情况，都值得被记录为潜在的 bad case。
2. 异常问题的发现途径
依靠用户主动反馈是远远不够的——大多数用户遇到不满意的回答只会默默离开。因此，需要多种渠道并举，主动探测问题。
（1）在线用户反馈通道
在问答界面提供显式的反馈入口，例如：
- “这个回答对你有帮助吗？”（是/否）
- “报告错误答案”按钮，点击后可选择原因（事实错误、引用错误等）
- 自由文本输入框，允许用户补充说明
简便的反馈机制能捕获到真实用户的一手不满。实际运营中，即使只有千分之一的用户反馈，也可能暴露系统性的缺陷。
（2）运营人工抽检
定期（如每日或每周）随机抽取一定数量的线上问答记录，由业务专家或运营人员逐条核查。抽检可以重点关注：
- 高流量的高频问题
- 用户点踩或表示无帮助的会话
- 涉及合规、安全、法律等敏感领域的回答
人工抽检虽然耗时，但能发现那些用户没有主动反馈却存在隐患的 case。
（3）自动化质量监控
可以在系统中预设若干自动化检查规则，对每一轮对话进行初步筛选：
- 检索置信度低：如果 top‑k 片段的相似度得分均低于阈值（如 0.7），标记为“可能缺乏相关知识”。
- 回答重复度过高：若生成回答的文本与检索片段重复率太高（接近原文照抄），可能缺乏有效归纳。
- 来源冲突：当多个检索到的文档片段表述矛盾时，模型可能选择了错误的一方，标记为需要人工判断。
- 关键词过滤：设定敏感词库，自动拦截或标记涉及禁止内容的回答。
这些规则不能替代人工判断，但可以大幅缩小排查范围，让宝贵的人力集中在真正可疑的样本上。
（4）主动模拟测试
定期用一批精心设计的测试问题（覆盖正常、边界、恶意三类）对系统进行“模拟考试”。这些测试题应包含：
- 知识库已有明确答案的简单问题（验证检索）
- 需要整合多段信息才能回答的综合问题（验证归纳能力）
- 知识库确实不包含的内容（验证“拒答”机制）
- 带有干扰信息的模糊问题（验证鲁棒性）
测试结果中的失败项直接成为 bad case，适合在版本更新前后对比回归。
3. bad case 的记录与整理
发现问题只是第一步，关键在于如何记录，使其能够驱动后续改进。每个 bad case 建议至少包含以下字段：
- 时间：问题发生的时间戳，方便追溯当时的系统版本和知识库状态。
- 用户原始输入：保留原始提问，不经过任何改写。
- 系统输出：完整保留系统给出的回答，包括引用的来源片段。
- 期望输出：由业务专家填写理想情况下应该给出的正确答案。
- 问题分类：事实错误 / 检索遗漏 / 知识缺失 / 拒答误执行 / 表达混乱 / 其他。
- 根因标注：初步判断出错的环节——是知识库缺内容？文档切分不合理导致召回失败？还是提示词引导有问题？
- 截图与上下文：如果有前序对话，保留完整上下文，因为不少“答非所问”其实是意图理解偏差。
这些记录可以沉淀在在线表格或 issue 管理工具（如飞书多维表格、Jira、Notion）中，形成团队共享的 bad case 库。
4. 实用建议
- 小步积累，不等“完美”：刚开始可能只有零星的反馈，不必追求立即覆盖所有场景。先建立记录习惯，bad case 库自然会逐渐丰富。
- 分类要贴近优化动作：分类标签最好能直接对应后续的改进方向。例如“检索遗漏”可以导向调整切块大小或混合搜索，“知识缺失”可以导向补充文档。
- 定期复盘：每周或每个迭代周期，对新增的 bad case 进行集中讨论，识别规律性缺陷。很多时候，十几个小的 bad case 背后是同一个根因。
- 善待反馈：无论是用户的一句抱怨，还是抽检中发现的小问题，都是免费的系统质量信号。及时响应和改进，能有效累积用户信任。
通过持续、主动地发现异常并收集 bad case，RAG 系统的优化就脱离了盲人摸象的状态，真正走上了“基于证据的迭代”路径。每一个被认真记录的 bad case，都是下一次版本升级最扎实的依据。