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

这道题问的是[[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。