RAG 上下文不准确怎么诊断?

30 秒回答

1. 建立分层诊断流程（检索层→生成层→数据层）
2. 明确三类数据集（开发集、对抗测试集、线上回流数据）
3. 数据质量控制需覆盖采集、清洗、标注、持续监控全链路
4. 区分"检索不准"与"生成幻觉"两类根因

回答与解析

答案要点

• 建立分层诊断流程（检索层→生成层→数据层）
• 明确三类数据集（开发集、对抗测试集、线上回流数据）
• 数据质量控制需覆盖采集、清洗、标注、持续监控全链路
• 区分"检索不准"与"生成幻觉"两类根因
• 给出可落地的迭代闭环机制

诊断流程：三层定位法

第一层：判断问题来源

• 检索问题：召回文档不相关或排序靠后
• 生成问题：检索准确但模型未正确利用（幻觉/忽略上下文）
• 数据问题：知识库本身存在过时、矛盾或错误信息

第二层：快速复现

• 用固定query在开发集复现，确认是系统性问题还是case级问题
• 对比BM25、向量检索、混合检索的结果差异

数据集类型

数据质量控制方法

采集阶段

• 源文档准入：权威来源优先，设定时效性阈值（如知识库只保留2年内文档）
• 格式标准化：统一PDF/网页解析，处理表格、代码块等特殊结构

处理阶段

• 切片策略：按语义边界切分（标题-内容关联），控制chunk长度（通常256-512 tokens）
• 去重与消歧：相似度聚类去重，对同名实体做消歧标注

持续监控

• 检索命中率、答案相关性的人工抽检（每周5%抽样）
• 用户反馈闭环：低分case自动入库，定期review

解决优先级

1. 数据层：清洗脏数据，补充缺失知识（最快见效）
2. 检索层：调优embedding（领域微调）、重排序模型、混合检索权重
3. 生成层：prompt工程约束引用格式、尝试RAG-specific微调

口语版讲法(约4分钟)

• 一句话定位：本质是诊断根因与数据质量闭环
• 分层诊断流程：先分检索、生成、数据三层，举例订单号检索
• 数据集与数据质量：开发集、对抗集、回流数据，质量控制从源文档到监控
• 落地风险与取舍：数据层见效最快，检索层调优要平衡，生成层最难

这道题问的是RAG上下文不准确怎么诊断和解决，其实本质是在问两件事：一是你能不能快速定位问题出在检索、生成还是数据本身，二是你有没有一套数据质量保障的工程闭环。我一般会按三层来诊断。

先看检索层。如果检索出来的文档不相关，或者相关文档排得太靠后，那就是检索的问题。比如在客服场景里，用户问“订单退款为什么还没到”，如果知识库里明明有退款时效文档，但召回的是物流政策，那就是检索不准。这时候我会对比BM25和向量检索的结果，看看是关键词匹配不行，还是语义理解偏了。

再看生成层。如果检索出来的文档是对的，但模型没用好，出现了幻觉或者忽略了关键信息，那就是生成的问题。举个例子，文档里写了“满200减30”，模型却回答“满300减50”，这就是Hallucination。这时候我会看模型的引用行为，是不是没有强制要求它引用原文。

最后看数据层。如果知识库本身就有过时、矛盾或者错误的信息，那检索和生成再努力也没用。比如库存价格文档没更新，用户问价格时模型给了旧价格。

诊断完之后，我会用三类数据集来定位和迭代。先说开发验证集，覆盖高频场景，人工标注黄金答案，用来日常调优。接着说对抗测试集，故意构造一些边界case，比如多跳推理、易混淆的query，用来压测系统的鲁棒性。再补充线上回流数据，也就是用户点踩或者没采纳的case，自动入库定期分析。

数据质量控制我贯穿全链路。采集阶段，源文档要优先权威来源，设时效性阈值，比如只保留两年内的。处理阶段，切片按语义边界切，比如按标题和内容关联来分，chunk长度控制在256到512 tokens。还要做去重和消歧，比如同名实体要标注清楚。持续监控方面，我会每周抽检5%的检索命中率和答案相关性，用户反馈的低分case自动入库review。

这里有个坑：很多人一上来就调embedding或者加重排序，但实际落地时，数据层的问题往往是最快见效的。比如清洗掉脏数据、补充缺失知识，可能一天就提升5个点。检索层调优要平衡效果和延迟，比如Hybrid Search把关键词和向量结合起来，但会增加复杂度。生成层最难，prompt工程能约束引用格式，但真要解决幻觉，可能需要做Self-RAG让模型自己反思，或者做RAG-specific微调，但成本高。

所以我的解决优先级是：先数据层，再检索层，最后生成层。如果数据层做好了，很多问题自然就消失了。

不过这里有个延伸点，就是对抗测试集怎么设计才能有效覆盖真实线上的失败场景。单纯靠人工构造很容易漏掉一些隐含的实体歧义或者时序依赖问题。我一般会结合用户反馈的bad case去迭代对抗测试集，同时用一些自动化的模板来生成多跳推理的case。

总的来说，我更倾向于把RAG上下文不准确看成是一个数据质量驱动的工程问题，而不是一个纯粹的模型问题。先修数据，再调搜索，最后才动模型，这样迭代最快。

关键一句:对抗测试集的设计需要结合线上bad case和自动化模板，才能有效覆盖真实失败场景

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做电商客服RAG，用户问“这款手机支持5G吗”，系统回了一段包含过时参数的上下文，结果答错了。你拿到这个bad case后会怎么一步步查问题？

2. 问法 2 · 层层追问

   RAG系统上线后用户反馈答案不准，你一般怎么排查？……如果确定是上下文信息本身错了呢？……那你手头有哪些数据能帮你定位是知识库脏了、检索没召回到对的、还是模型没用好？

3. 问法 3 · 直球架构

   请你设计一套RAG上下文准确性问题的诊断和修复方案。诊断层面要区分检索和生成两类根因，数据层面要列出你需要的开发集、对抗集、线上回流数据，并说明每类数据的质量怎么控制。