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

一、引言

二、摘要

在 LLM（Large Language Model）的应用过程中，越来越多工程师尝试使用 RAG 来为应用程序中添加语义搜索功能，获得了不错的结果。RAG 主要是通过语义检索来查询匹配的文档，然后将其添加到 LLM 的提示中，以使 LLM 来提取正确的答案。RAG 系统旨在：

• 减少 LLM 的幻觉。

• 使用外部数据来扩充 LLM，以增强 LLM 的响应。

然而，RAG 系统会受到信息检索系统固有的局限性以及对 LLM 依赖性的影响，本文中，作者通过三个案例来研究 RAG 系统存在的问题，并总结为 7 个故障点（Failure Points），为后续的 RAG 系统提供一定的参考。

三、检索增强生成

3.1 概览

如下图所示，RAG 系统包含两个主要阶段：

• Offline：索引构建阶段，将外部预料划分为不同的 Chunk，针对每个 Chunk 都使用 Embedding 模型提取 Embedding，并构建为向量检索的索引。

• Online：用户请求阶段，基于用户问题提取 Embedding，然后使用该 Embedding 进行检索，将检索到的文档和用户问题一起输入 LLM，通过 LLM 生成输出最终结果。 

3.2 索引构建

在索引构建阶段涉及几个主要的问题：

• Embedding 模型的选择问题，Embedding 模型对于检索速度、质量都有比较大的影响，比如说 Embedding 的维度对索引的大小、检索的速度都有影响，比如 OpenAI 最新发布的 text-embedding-3-large 模型（New embedding models and API updates）包含 256,1024,3072 三个维度，其中 256 和 3072 维度 embedding 差距 12 倍，这也就意味着索引大小、检索计算量相差 12 倍左右。

  

• Chunk 的划分也会有一定影响，比如太小的 Chunk 可能导致正确答案被切分，检索时可能遗漏关键信息；太大的 Chunk 可能引入过多的噪声，从而影响检索质量。此外，不同的文档也可能要用不同的 Chunking 方式。

3.3 请求处理

该阶段也会有几个常见问题：

• Top-k 的选择：通常是使用余弦相似度进行检索 Top-k 个相似文档（也可以使用具有倒排索引等技术加快检索），k 太小可能导致召回率太低，无法检索到正确答案相关信息，k 太大会导致输入 LLM 的 Prompt 太长，计算代价很高，甚至有可能 LLM 无法支持对应长度的输入。

• LLM 的选择：通常来说 GPT-4 作为 LLM 是效果最好的，但是其代价很高，因此往往会选择一些这种的方案，比如现在效果还行但是小得多的开源 LLM，不合适的模型也可能导致 LLM 不按照 Prompt 要求生成答案，因此通常也需要相应的评估实验来决策。

四、案例分析

作者进行了三个案例分析，以探索实施 RAG 系统时面对的挑战。三个案例对应的总结如下图 Table 1 所示，其中 BioASQ 案例相关的所有脚本、数据和每个故障点的示例都可以在线获取（Data for: Seven Failure Points When Engineering a Retrieval Augmented Generation System）：

4.1 Cognitive Reviewer

Cognitive Reviewer 是一个 RAG 系统，旨在支持研究人员分析科学文档。研究人员指定一个研究问题或目标，然后上传一系列相关的检索论文；然后根据既定目标对所有文件排序，供研究人员手动审查。研究人员还可以直接针对所有文件提问。Cognitive Reviewer 在运行时执行索引构建，并依靠强大的数据处理管道来处理上传的文档，无法进行质量控制。此外，该系统还使用排序算法对上传的文档进行排序。

4.2 AI Tutor

AI Tutor 是一个 RAG 系统，学生可以在其中提出有关单元的问题，答案来自学习内容。学生也可以查看答案来源列表来验证答案。AI Tutor 的工作原理是集成到 Deakin 的学习管理系统中，索引所有内容，包括 PDF 文档、视频和文本文档。在索引构建过程中，视频在被分块之前也会使用深度学习模型 Whisper 进行转录。AI Tutor 是在 2023 年 8 月至 2023 年 11 月期间开发的，用于 2023 年 10 月 30 日开始的一个有 200 名学生的试点，目的是介绍在实施过程中吸取的经验教训，并在试点结束后提出后续结论。

此 RAG 管道包含一个用于通用查询的 Rewriter，作者也实现了一个聊天界面，其中用户和 AI 导师之间的先前对话也会作为每个问题的上下文的一部分。Rewriter 会考虑上下文并重写 Query，以解决模棱两可的请求。

4.3 BioASQ

之前的案例侧重于文档比较少的场景，为了更大范围探索 RAG 的问题，作者使用 BioASQ 数据集创建了一个 RAG 系统，该数据集由问题、文档链接和答案组成。问题的答案是“是/否”、文本摘要、事实或列表。该数据集由生物医学专家准备，包含特定领域的问答对。作者从 BioASQ 数据集中选择了 4017 份文档，总共 1000 个问题，所有文件加入索引，并针对 RAG 系统提出问题，然后使用 OpenAI 的 OpenEvals 技术评估生成的问题。作者从生成的问题中人工检查了 40 个问题，并检查了所有 OpenEvals 任务不准确的问题。作者发现，针对这个领域，自动评估比人类评估者更悲观，不过 BioASQ 是一个特定领域数据集，审稿人不是专家，LLM 可能比非专家知道的更多。

五、RAG 系统的故障点

如下图 Figure 1 所示，作者通过以上的三个案例，总结了 RAG 系统的 7 个故障点。

5.1 FP1 Missing Content（内容缺失）

第一种情况是：提出了无法从当前可用文档中回答的问题。比较好的情况下，RAG 系统会以类似“对不起，我不知道”之类方式来响应；然而，有些时候 LLM 会依赖自身不准确的知识来回答，可能给出错误的答案。

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

第二种情况是：问题的答案在文档中，但是检索得分不够高，无法返回给用户。考虑 LLM 支持的上下文窗口大小以及计算开销的影响，通常会选择合适的 k 值，当然，如果上下文窗口很大，不计成本，则可以使用尽量大的 k，比如 Gemini-1.5 Pro 支持数百万 Token 的上下文。

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

第三种情况是：文档从数据库中检索到了，但检索到的多个文档可能需要合并，因为融合策略的问题，答案文档并未真正的加入到 LLM 的上下文中。

5.4 FP4 Not Extracted（未提取到）

第四种情况是：问题的答案也存在于上下文中，但 LLM 没有从中正确提取答案。通常，当 LLM 的指令遵循能力比较差，或者上下文中包含太多噪音或相互矛盾的信息时容易出现这种问题。

5.5 FP5 Wrong Format（错误的格式）

第五种情况是：要求 LLM 以某种格式（例如表格、列表、JSON）提取信息，而 LLM 没有很好地遵循该要求。

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

第六种情况是：答案在响应中返回，但不够具体或过于具体，无法满足用户的需求。当 RAG 系统设计人员对给定问题有期望的结果时可能发生这种情况。例如针对教师对学生的场景，应该在答案中包含特定的教育内容，而不仅仅是答案；或者当用户不确定如何提问或者过于笼统时，也会发生这种问题。

5.7 FP7 Incomplete（不完整）

第七种情况是：生成的答案不是不正确，而是不够完整，即使这些信息已经在上下文中，但依然会遗漏一些。例如，“文档 A、B 和 C 中涵盖的要点是什么？”，更好的方式是分别提出这些问题。

5.8 FP8 Others（其它）

除了以上常见问题外，RAG 系统还有一些其它常见问题，比如信息提取可能比较困难，PDF 的格式各种各样，也包含很多图表、图片、脚注等信息，可能不太适合提取，导致影响检索出的文档的质量。

六、经验教训

七、参考链接

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