RAG “七宗罪”：RAG 系统常见问题总结

一、引言

RAG（检索增强生成）在减少大模型幻觉、引入外部知识方面，确实是一把利器，落地也相当广泛。但现实中的RAG系统，常常踩坑不断——检索不到、回答不完整、格式乱飞……这篇工作通过三个具体案例，系统梳理了RAG工程中的七种典型故障，很值得一看。对应论文是2401.05856。另外，关于RAG的综述之前专门写过，这里就不再展开了。

二、摘要

随着大模型应用的深入，越来越多工程师开始用RAG给应用加上语义搜索能力，效果也确实不错。RAG的核心思路：先用语义检索找到相关文档，然后把文档和用户问题拼到一起交给大模型，让模型从中提取正确答案。这套机制的目标很明确——减少幻觉，同时用外部数据扩充模型的能力。

不过，RAG系统同时受限于信息检索本身的短板，以及对大模型的高度依赖。论文作者用三个案例深入剖析了这些问题，最终归纳出7个故障点（Failure Points），给后续RAG系统的搭建提供了很实用的参考。

三、检索增强生成

3.1 概览

整个RAG流水线可以分成两个阶段：

• 离线阶段（索引构建）
  ：把外部语料切成不同的Chunk，对每个Chunk用Embedding模型提取向量，然后建好向量检索的索引。

• 在线阶段（用户请求）
  ：对用户问题也提取Embedding，用这个Embedding去检索，把命中的文档和问题一起塞给大模型，最后由模型生成答案。

3.2 索引构建

这个阶段有两大关键抉择：

• Embedding模型怎么选
  ：直接关系到检索速度和最终质量。比如OpenAI最新的text-embedding-3-large，提供了256、1024、3072三种维度，256和3072差了整整12倍，索引大小和计算量也跟着差了12倍。

• Chunk怎么切
  ：切太小，正确答案可能被拦腰截断，检索时根本找不到；切太大，噪声太多，检索质量下降。而且不同类型的文档得用不同的切法，没有万能模板。

3.3 请求处理

处理用户请求时，也有几个常见问题：

• Top-k怎么定
  ：通常用余弦相似度取前k个最相似的文档。k太小，召回率低，正确答案漏掉；k太大，输入给大模型的Prompt太长，计算成本飙升，甚至可能超出模型的上下文窗口。

• 大模型怎么选
  ：GPT-4效果最好，但贵。所以很多人退而求其次，挑个开源的小模型。但模型选不对，大模型可能根本不按Prompt的要求生成答案。到底选哪个，还是得做评估实验来决定。

四、案例分析

论文作者做了三个案例分析，从不同角度揭示RAG系统面临的真实挑战。三个案例的总结见下表Table 1（数据已开源，可在线获取）。

4.1 Cognitive Reviewer

这是一个帮研究人员分析科学文档的RAG系统。研究者先定一个研究问题或目标，然后上传一堆相关论文，系统按目标对所有文件排序，供人手动审查。研究人员还能直接针对所有文件提问。这个系统在运行时才建索引，依赖强大的数据处理管道，但缺乏质量控制，排序算法也直接影响最终效果。

4.2 AI Tutor

一个面向学生的RAG系统，学生可以问关于课程单元的问题，答案来自学习内容。学生还能查看答案来源列表来自行验证。它集成到了Deakin大学的学习管理系统中，索引了所有内容——PDF、视频、文本文档。视频先被Whisper转成文字，再分块。这个系统从2023年8月开发到11月，在当年10月30日开始的实验中服务了200名学生，实验中总结了很多经验教训。

值得一提的是，这个RAG管道里有一个专门的Rewriter模块，用于处理通用查询。聊天界面还会把之前的对话历史也作为上下文的一部分，Rewriter会结合上下文重写问题，解决那些模棱两可的请求。

4.3 BioASQ

前两个案例处理的文档数量都不多。为了在更大规模上测试RAG的问题，作者直接用BioASQ数据集搭了个RAG系统。这个数据集包含问题、文档链接和答案，答案形式有“是/否”、文本摘要、事实或列表，全部由生物医学专家准备。作者从中选了4017份文档、1000个问题，全部建索引，然后用OpenAI的OpenEvals技术自动评估答案质量。人工又抽查了40个问题，发现自动评估比人类评估更悲观——因为BioASQ是特定领域数据集，评审人不是专家，而大模型知道的可能比非专家还多。

五、RAG系统的故障点

基于上面的三个案例，论文总结出了7个典型的故障点，下面逐一说明。

5.1 FP1 Missing Content（内容缺失）

用户问的问题，当前文档库里根本没有相关信息。好的情况是系统老老实实说“不知道”，但很多时候大模型会硬靠自己的知识来编个答案，直接翻车。

5.2 FP2 Missed the Top Ranked Documents（检索到的Topk文档缺失）

答案明明在库里，但检索得分不够高，排不到前k个，用户最终看不到。虽然可以调大k值，但上下文窗口和计算开销摆在那里。当然如果像Gemini-1.5 Pro那样支持数百万Token，那就另当别论了。

5.3 FP3 Not in Context - Consolidation strategy Limitations（未在上下文中——融合策略限制）

文档虽然被检索到了，但系统在合并多个文档时出了问题，答案所在的文档并没有真正被塞进大模型的上下文里。

5.4 FP4 Not Extracted（未提取到）

答案已经在上下文中了，但大模型就是没把它提取出来。这在指令遵循能力差的模型身上很常见，或者上下文中噪声太多，信息相互矛盾。

5.5 FP5 Wrong Format（错误的格式）

要求大模型以表格、列表、JSON等特定格式输出信息，但模型没按规矩来，直接生成了一段散文。

5.6 FP6 Incorrect Specificity（不正确的特异性）

答案是给出了，但要么太笼统要么太啰嗦，不符合用户的实际需求。比如老师问学生的问题，应该给出适合教学的内容而不是一个干巴巴的结论；或者用户自己没问清楚，太模糊，也容易出这种问题。

5.7 FP7 Incomplete（不完整）

答案不能说错，但不完整。明明上下文里有完整的信息，大模型却只说了其中一部分。比如问“文档A、B和C里分别讲了什么要点”，正确的做法是分别列出来，但模型可能只说了A，漏了B和C。

5.8 FP8 Others（其它）

除了上面这些，还有一些常见问题——比如PDF格式五花八门，图、表、脚注一大堆，提取文字信息时容易出错，最后检索出来的文档质量也大打折扣。

六、经验教训

针对上面这些故障点，论文也给出了很实用的建议，整理成一个表格：

FP	经验教训	描述
FP4	更长的上下文窗口，更好的结果	扩大上下文窗口（从4K到32K到128K），能容纳更多知识，效果明显提升。
FP1	语义缓存帮助降低开销和延迟	高频问题缓存起来，能大幅降本降延时（参考GPTCache）。
FP5-7	“越狱”绕过RAG，损害安全训练	微调可能破坏已有的安全训练，导致模型生成有害内容。所有微调模型都需充分测试。
FP2/4	增加Meta信息，提升检索能力	在上下文中加入文件名、Chunk编号等信息，有助于后续信息提取。
FP2/4-7	针对小文本，开源Embedding模型可能更好	在处理短文本场景时，开源Embedding模型有时比闭源的效果更佳。
FP2-7	RAG系统需要持续校正	运行时可能遇到未知输入，需要持续监控和调整。
FP1/2	实现RAG pipeline的可配置化	Chunk大小、Embedding策略、分块方式、上下文大小等都应可调，方便对线上效果做correction。
FP2/4	通过组装定制解决方案创建的RAG pipeline是次优的	端到端训练可以增强RAG系统的领域适应性，效果通常好于手动拼装。
FP2-7	只在运行时测试性能特性	像G-Evals这样的离线评估看起来很好，但必须基于标记好的问答对才能反映真实情况。

七、参考链接

1. https://arxiv.org/abs/2401.05856
2. https://openai.com/blog/new-embedding-models-and-api-updates
3. https://figshare.com/s/fbf7805b5f20d7f7e356
4. https://aclanthology.org/2023.nlposs-1.24/
5. https://arxiv.org/abs/2310.20624
6. https://arxiv.org/abs/2210.02627