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 的格式各种各样，也包含很多图表、图片、脚注等信息，可能不太适合提取，导致影响检索出的文档的质量。
六、经验教训
七、参考链接
https://arxiv.org/abs/2401.05856
https://openai.com/blog/new-embedding-models-and-api-updates
https://figshare.com/s/fbf7805b5f20d7f7e356
https://aclanthology.org/2023.nlposs-1.24/
https://arxiv.org/abs/2310.20624
https://arxiv.org/abs/2210.02627