3 如何建立问题分类和误差归因机制
P2 · rag
🏷 标签：rag, error-analysis, classification, automation
1️⃣ 考察意图
面试官想考察你能否将 RAG 系统的“玄学”错误转化为可量化、可优化的工程问题。这不是背概念，而是系统设计题。刁钻点在于：候选人常只提“分类”不提“归因完整流程”，或只谈理论不谈自动化落地。答好了能展示你具备搭建生产级 RAG 评估体系的能力，包括定义分类体系、设计自动化归因 Pipeline、以及用数据驱动迭代的硬实力。
2️⃣ 标准答
建立问题分类和误差归因机制，核心是三步：定义分类体系 → 自动化归因 Pipeline → 完整流程优化。
第一步：定义多维度问题分类体系不能只按“检索错/生成错”二分。生产级分类至少覆盖三个维度：
- 错误类型：检索遗漏（Recall 不足）、检索噪声（Precision 低）、上下文截断（Chunk 边界问题）、幻觉（事实性错误）、不完整（信息缺失）、格式错误（输出不符合 schema）。
- 严重等级：P0（用户投诉/核心功能失败）、P1（影响体验但可绕过）、P2（偶发或边缘 case）。
- 根因层：数据层（文档缺失/过时）、检索层（Embedding 模型/Chunk 策略/重排序）、生成层（Prompt 设计/LLM 能力/温度参数）。
第二步：设计自动化归因 Pipeline人工逐条分析不可行，必须自动化。推荐用 LLM-as-Judge + 规则引擎 的混合方案：
- 规则引擎：快速过滤明显错误。例如，检查输出是否包含“无法回答”等关键词，或通过 NER 检查实体是否出现在检索到的文档中（实体级 Recall 检查）。
- LLM 分类器：对规则引擎无法判定的 case，用 GPT-4/Claude 等强模型进行多标签分类。Prompt 设计成 Chain-of-Thought 格式，要求模型先输出“检索到的文档片段”，再输出“生成答案”，最后判断错误类型。关键工程取舍：用强模型做分类成本高，但准确率可达 90%+；弱模型（如 7B 级）准确率仅 70% 左右，会导致归因噪音。实际落地时，按 1:10 比例采样（强模型分析 10% 的 case，弱模型分析剩余 90%），用强模型结果校准弱模型。
- 实际落地的坑：LLM 分类器容易“自我合理化”，即即使检索文档不包含答案，LLM 也会强行生成并声称正确。解法：在 Prompt 中强制要求“如果检索文档中无直接证据，标记为‘检索遗漏’”，并加入 Adversarial 示例（如“用户问‘今天天气’，检索文档是菜谱，答案应为‘检索失败’”）。
第三步：建立反馈完整流程归因结果必须驱动优化，否则是废数据。完整流程流程：
- 周报生成：自动统计各错误类型占比、P0 级错误趋势。例如，“本周检索遗漏占比 35%，环比上升 5%”。
- 根因定位：对“检索遗漏”类错误，进一步分析是 Embedding 模型召回不足（用 Recall@K 指标），还是 Chunk 策略导致信息碎片化（用 Chunk 重叠率分析）。
- A/B 实验：针对根因，设计优化方案。例如，将 Chunk 大小从 256 改为 512，或更换 Embedding 模型为 bge-large-en-v1.5，然后对比归因结果中“检索遗漏”占比是否下降。
- 持续迭代：每月更新分类体系，例如新增“多跳推理错误”类别，并重新训练 LLM 分类器的 Few-shot 示例。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从分类体系、自动化归因、完整流程优化三个层面回答。分类体系要覆盖错误类型、严重等级和根因层，不能只二分。自动化归因用 LLM-as-Judge 加规则引擎的混合方案，注意强模型校准弱模型和防自我合理化的坑。完整流程优化通过周报驱动 A/B 实验，让归因结果直接指导检索或生成策略的迭代。总结一句：好的归因机制是 RAG 系统的‘监控仪表盘’，能让玄学问题变成可量化的工程指标。”
4️⃣ 高频追问 & 应对
追问 1：你如何保证 LLM 分类器的准确率？如果它自己分类错了怎么办？
应对策略：首先，用强模型（如 GPT-4）做分类，准确率可达 90%+。其次，建立人工抽检机制：每周随机抽取 100 条分类结果，由标注团队校验，计算准确率。如果准确率低于 85%，则调整 Prompt 或增加 Few-shot 示例。最后，引入置信度阈值：LLM 分类器输出时附带置信度（如“检索遗漏概率 0.9”），低置信度 case 自动进入人工审核队列。这是工程取舍：完全自动化会引入噪音，完全人工成本高，混合方案是平衡点。
追问 2：你的分类体系如何应对长尾错误？比如用户问“今天天气”，系统答了“明天天气”。
应对策略：长尾错误需要动态扩展分类体系。做法是：在归因 Pipeline 中增加“未知错误”类别，所有无法归入现有类别的 case 自动标记为“未知”。每周人工分析“未知”类别的 case，如果某类错误出现频率超过 1%，则新增为正式类别。例如，“时间偏移错误”就是通过这种方式发现的。同时，用 Embedding 聚类对“未知”错误进行自动分组，辅助人工分析。
追问 3：你的归因机制如何与线上系统集成？延迟和成本怎么控制？
应对策略：归因 Pipeline 不能阻塞线上请求，必须异步处理。架构是：线上请求的输入输出写入 Kafka 日志，后台 Consumer 消费日志并执行归因分析。延迟控制在分钟级（非实时），成本通过采样控制：全量日志中只采样 10% 做强模型分析，90% 用弱模型或规则引擎。另外，用缓存机制：相同 Query 的归因结果缓存 24 小时，避免重复计算。整体成本约为线上推理成本的 5-10%。
5️⃣ 避坑 · 常见错误答法
- ❌ 只提“按检索错误和生成错误分类”，没有多维度和严重等级 → ✅ 必须包含错误类型、严重等级、根因层三个维度，且每个维度有具体子类（如检索遗漏、幻觉、格式错误）。
- ❌ 说“用 LLM 自动分类就行”，不提准确率验证和人工抽检 → ✅ 必须说明强模型校准弱模型、置信度阈值、人工抽检机制，体现工程落地思维。
- ❌ 只谈分类不谈完整流程，归因结果没有驱动优化 → ✅ 必须给出完整流程流程：周报 → 根因定位 → A/B 实验 → 迭代优化，让归因结果产生实际价值。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中搭建了自动化归因 Pipeline，每周生成错误报告，指导团队优化 Chunk 策略和 Prompt，使准确率提升 15%”切入，强调具体数字和完整流程效果。
- 如果你只做过传统 NLP：用“传统 NLP 的错误分析（如分类任务的混淆矩阵）类比到 RAG，但 RAG 需要多维度归因（检索+生成），我设计了一个类似混淆矩阵的归因矩阵”切入，展示迁移能力。
- 如果你是校招无项目：聚焦“我复现了 LlamaIndex 的 Evaluation 模块，并在此基础上增加了 LLM 分类器和置信度机制，写了一个 Demo 展示归因流程”切入，展示动手能力和对开源工具的熟悉度。
- 《RAGAS: Automated Evaluation of Retrieval Augmented Generation》
- 《CRUD-RAG: A Comprehensive Chinese Benchmark for Retrieval-Augmented Generation》
- 《Evaluating RAG Systems: A Practical Guide》 (LlamaIndex 官方博客)
- 《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》 (用于 LLM 分类器 Prompt 设计)
- 《HNSW: Hierarchical Navigable Small World》 (用于理解检索层优化)