必读论文 · 7 FPs When Engineering a RAG System (2024)

Abstract

随着软件工程师在应用程序中不断引入一种名为检索增强生成（Retrieval Augmented Generation, RAG）的策略，以实现语义搜索功能，RAG 系统的应用也日趋广泛。RAG 系统的核心在于寻找与搜索问题在语义上相匹配的文档，并将这些文档交给大语言模型（LLM），如 ChatGPT，依靠 LLM 来抽取准确的答案。RAG 系统旨在：a) 减少大语言模型产生错误回应的风险，b) 为生成的回答关联上来源和参考文献，以及 c) 避免对文档进行元数据标注的必要。但是，RAG 系统也存在局限性，这些局限性源于信息检索系统本身的缺陷以及对大语言模型的依赖性。在本文中，我们通过三个不同领域：研究、教育和生物医学的案例研究，分析了 RAG 系统的失败经验。我们总结了这些案例中的教训，并提出了设计 RAG 系统时应考虑的七个潜在失败点。从我们的工作中得出两个主要的结论是：1) RAG 系统的验证只能在实际运行中才能进行，以及 2) RAG 系统的稳健性是通过不断的迭代优化而形成的，而非在最初设计时就能完全预设的。

Introduction

大语言模型（LLMs）的最新进展，包括 ChatGPT，为软件工程师提供了构建新型人机交互（HCI）解决方案的新工具，能够帮助他们完成复杂的任务，概括文档，解答特定文件中的问题，以及创造新的内容。不过，LLMs 在处理最新知识或企业数据库中的特定领域知识方面还存在不足。目前有两种解决策略：a) 对 LLMs 进行微调（继续用特定领域的资料训练 LLM），这需要管理或提供一个经过微调的 LLM；或 b) 使用基于检索的增强生成（RAG）系统，这种系统依赖 LLMs 利用现有的（可扩展的）知识资料来生成答案。这两种方法在数据隐私与安全、可扩展性、成本、所需技能等方面各有利弊。本文将重点讨论 RAG 系统。

检索增强生成（RAG）系统提出了一个具有吸引力的解决方案来应对这一挑战。它将检索机制与大语言模型（LLMs）的生成功能相结合，能够生成与上下文相关、准确且最新的信息。RAG 系统融合了信息检索和大语言模型的生成才能。其检索部分致力于从数据仓库中寻找与用户问题相关的信息，而生成部分则利用这些检索到的信息作为背景，以产生针对用户问题的答案。RAG 系统的一个重要应用是，它使得所有非结构化的信息都能被索引和查询，这大大缩短了开发周期，无需构建知识图谱，同时也减少了数据整理和清洗的工作量。

软件工程师在构建 RAG 系统时，首先需要对获取的不同格式的领域知识进行预处理，并将其作为工件存放。接着，他们要将这些经过处理的信息储存在适当的数据仓库（例如向量数据库）中，选择或者整合一种合适的查询与工件匹配策略，对找到的工件进行排序，并通过调用大语言模型（LLMs）的 API，结合用户的查询和相关的上下文文档。目前，关于构建 RAG 系统的新技术不断涌现，但要了解这些技术如何适用于特定的应用场景以及它们的实际效果如何，还需要进一步的探索。

在本研究中，我们通过三个案例研究分享了所学到的经验和七个导致失败的关键因素。本文旨在为实践者提供参考，并为 RAG 系统的研究发展指明方向。据我们所知，这是首次就构建鲁棒 RAG 系统面临的挑战提供实证分析。随着大语言模型（LLMs）技术的不断进步，软件工程领域的专家们需要负起责任，分享如何构建基于 LLMs 的鲁棒系统的知识。这项工作对于提升 RAG 系统的鲁棒性来说，是一个重要的进展。

本项研究的主要问题包括：

• 在构建 RAG 系统时，我们会遇到哪些失败的环节？(第5节) 为了探究这些潜在的失败环节，我们以 BioASQ 数据集为基础开展了一项实证研究。该实验包含了15,000篇文档和1,000组问题与答案。我们首先对所有文档建立索引，随后利用 GPT-4 运行查询并记录生成的答案。接下来，我们用 OpenAI 的评估工具对所有问题与答案进行了验证。我们对所有出现差异的案例、被标记为错误的案例以及随机选取的标记为正确的案例进行了手动审查，以此来分析并识别出现问题的模式。

• 当我们要构建一个 RAG 系统时，有哪些关键因素需要我们仔细考虑呢？在这里，我们将分享从三个 RAG 系统实施案例中吸取的宝贵经验。这些案例不仅展示了我们在实施过程中遇到的挑战，也揭示了我们从中获取的深刻洞察。

这项研究带来的主要贡献包括：

• 我们罗列了 RAG 系统中可能出现的各种失败点 (FP)。
• 我们分享了三个 RAG 系统实施案例的实践经验，其中两个案例的系统现正于 Deakin 大学运行。
• 我们根据从三个案例研究中吸取的经验，为 RAG 系统的研究指明了一条新的道路。

Related Work

RAG是指在预训练和推理阶段，利用文档来提升大语言模型的性能。但是，要知道，训练这样的模型需要大量的计算资源、数据准备时间，因此，如果能直接使用未经训练或微调的 RAG，无疑是一种极具吸引力的方案。然而，当我们试图使用大语言模型来提取信息时，便会遭遇一些挑战，比如处理长篇文本的性能问题。

最近的一项调查显示，大语言模型在 RAG 流程中被广泛应用，包括检索器、数据生成、重写器和阅读器。我们的研究从软件工程的角度出发，旨在深入探讨工程师在实践中可能遇到的问题，以及为了实现当前最先进的 RAG 系统，需要进行哪些软件工程的研究。

近期有研究对 RAG 系统进行了基准测试，但并未关注在实施过程中可能出现的问题。软件工程研究已经探讨了 RAG 系统在代码相关任务中的应用。然而，RAG 系统的应用范围远超软件工程任务。本文从实践者的角度出发，补充了现有的研究，揭示了在实施 RAG 系统过程中可能遇到的挑战。

RAG 系统中产生的错误和失败与其他信息检索系统有许多相同之处，如 1) 缺乏查询重写的评价标准，2) 文档的重新排名，以及 3) 高效的内容概括。这些问题，我们的研究结果已经证实。而与大语言模型的语义和生成特性相关的部分，如评估事实准确性，便是 RAG 系统所独有的挑战。

Retrieval Augmented Generation

随着 ChatGPT、Claude 和 Bard 等大语言模型服务的广泛应用，人们开始探索将它们作为问答系统的可能性。虽然这些系统的表现令人瞩目，但也存在两个根本性的问题：1) "幻觉"问题 —— 即大语言模型生成的答案看似正确，实则错误；2) "无法控制"问题 —— 除了通过精心设计的提示，我们无法直接指导或修改模型的输出内容。为了解决这些问题，人们设计了 RAG 系统，这是一种信息检索方法，旨在克服直接使用大语言模型所带来的限制。

RAG 的工作方式是，首先将用自然语言表达的查询问题转化为嵌入，以在大量文档中进行语义搜索。在找到相关的文档后，这些文档会被送到一个大语言模型中，由模型生成答案。如 图1 所示，RAG 系统主要包含两个步骤：一是建立索引，二是进行查询。更多的细节可以参考相关的研究调查报告。

Index Process

在 RAG 系统中，我们采用一种称为 “嵌入” 的技术来帮助检索系统工作。“嵌入” 是一种压缩了的文档语义表示方式，可以想象成是一个由数字组成的向量。在建立索引的过程中，我们会把每个文档切分成更小的片段，然后用一个特殊的模型将这些片段转化成 “嵌入”。这些原始的片段和它们对应的 “嵌入” 会被一起存储在数据库中。在这个过程中，软件工程师需要做出一些设计决策，比如如何合理地切分文档，以及每个片段应该有多大。如果切分的片段太小，某些问题可能就无法得到完整的答案；而如果片段太大，那么生成的答案可能会包含一些无关的信息。

不同类型的文档在处理和分块策略上有不同的需求。例如，对于视频内容，我们需要一个转录系统来提取音频并在编码前将其转换为文本（详见 Cognitive Reviewer ）。此外，选择何种嵌入方式也至关重要，因为更改嵌入策略需要重新对所有分块进行索引。在选择嵌入方式时，我们应根据其在语义上检索正确答案的能力来决定。这个过程会受到分块大小、预期的问题类型、内容的结构以及应用领域的影响。

Query Process

查询过程是在实时运行中进行的。首先，我们将自然语言形式的问题转化为一般性的查询。为了让这个查询更具普遍性，我们使用了大语言模型，这使得我们可以在新的查询中加入更多的上下文信息，比如之前的聊天历史。然后，我们根据新的查询计算出一个嵌入，用于在数据库中寻找相关的文档。我们会使用如余弦相似度这样的相似性方法来检索最相似的 top k 个文档（向量数据库有一些技术，如倒排索引，可以加速检索过程）。直观来说，与查询在语义上更接近的块更有可能包含我们需要的答案。

检索到的文档将被重新排序，以便让含有答案的文档块尽可能地排在前面。接下来的阶段是“整合器”（Consolidator），它负责处理这些文档块。这个步骤的存在是为了解决大语言模型面临的两个主要限制：1）Token 的数量限制；2）处理速度的限制。像 OpenAI 这样的服务会对输入的文本量设定一个上限。这就限制了我们可以用于提取答案的文档块的数量，因此我们需要一个策略来精简并链接这些文档块，以便从中获取答案。这些在线服务还会限制在一定时间内可以使用的 Token 数量，这就限制了系统的响应速度。因此，软件工程师在设计 RAG 系统时需要考虑这些权衡。

在 RAG 流程的最后阶段，答案会从生成的文本中被提取出来。在这个阶段，我们需要从输入的问题中筛选出有用的信息，同时遵循一些特定的格式要求，比如把答案列成一个选项列表，然后生成最后的输出结果。要实现 RAG 系统，我们需要设计多种不同的问题和答案处理方式。这样做可以确保我们能得到和特定领域相关的问题。通过使用 LLM 从文本中实时提取答案，我们可以开发出一些新的应用领域，比如实时的问题回答系统。不过，RAG 系统的测试是非常困难的，因为我们没有现成的数据可以用来测试。我们只能通过生成一些模拟的数据，或者先行试运行系统来进行实验性的测试。

Case Studies

本研究通过三个案例研究，探讨了在 RAG 系统的实施过程中可能遇到的挑战。表 1 展示了每个案例研究的概述。BioASQ 案例研究的所有脚本、数据，以及每个失败环节的示例，都已在网上公开。由于涉及到保密问题，另外两个案例研究并未包含在内。

Cognitive Reviewer

Cognitive Reviewer 是一款 RAG 系统，旨在帮助研究人员分析科学文档。研究人员可以设定研究问题或目标，并上传一系列相关的研究论文。接着，系统会根据设定的目标对所有文档进行排序，供研究人员进行人工审阅。此外，研究人员还可以直接向系统提出关于所有文档的问题。目前，Deakin University 的博士生们正在使用 Cognitive Reviewer 来支持他们的文献综述工作。Cognitive Reviewer 在运行时进行索引处理，并依赖于一个强大的数据处理流程来处理上传的文档，也就是说，在开发阶段无法进行质量控制。此系统还采用了一种排名算法来对上传的文档进行排序。

AI Tutor

AI 导师是一个 RAG 系统，学生可以向系统提出关于课程的问题，答案则基于学习资料。学生可以通过查看答案来源的列表来核实答案。AI 导师通过整合到 Deakin 大学的学习管理系统，对包括 PDF 文档、视频和文本文件在内的所有内容进行编码和索引。在这个编码和索引的过程中，我们使用深度学习模型 Whisper 对视频进行转录，然后将其分解成可管理的部分。AI 导师是在 2023 年 8 月到 11 月期间开发的，用于一个在 2023 年 10 月 30 日开始的拥有 200 名学生的课程试点项目。我们的目标是分享实施过程中的经验教训，并在试点项目结束时分享后续的发现。这个 RAG 流程包括一种可以简化用户查询的重写功能。我们设计了一个聊天界面，其中用户和 AI 导师之间之前的对话被用作每个问题的上下文。重写功能会考虑这种上下文，重新构造用户的查询，以解决像 “请进一步解释这个概念” 这样的模糊请求。

Biomedical Question and Answer

在之前的案例中，我们主要研究的是内容规模较小的文件。为了进一步探索大规模数据的问题，我们使用了 BioASQ 数据集，构建了一个 RAG 系统。BioASQ 数据集由生物医学专家编制，包含了问题、相关文档链接和答案，答案的形式可能是yes/no、文本摘要、事实或者列表。我们从这个数据集中下载了 4017 篇开放获取的文档，并提出了 1000 个问题。所有的文档都经过了索引处理，并在 RAG 系统中进行了问题提问。接着，我们运用 OpenAI 实现的 OpenEvals 技术对生成的问题进行了评估。在所有生成的问题中，我们手动审查了 40 个问题，以及所有被 OpenEvals 标记为不准确的问题。我们发现，在这个领域，自动评估的结果通常比人类评估者更为保守。但是，需要注意的是，BioASQ 是一个特定领域的数据集，而进行评审的并非专家。也就是说，大语言模型可能在某些方面比非专家更有见解。

Failure Points of RAG Systems

通过我们的案例研究，我们发现了一系列即将在下文中详述的问题。接下来的部分，我们将探讨这样一个研究问题：在构建 RAG 系统过程中，都有哪些可能导致失败的环节？

• Missing Content 首个问题出现在，当我们提出一个无法从现有文档中找到答案的问题时。在最好的情况下，RAG 系统会回应：“对不起，我无法回答这个问题。”然而，对于那些与内容相关，但是并没有明确答案的问题，系统可能会被误导，产生错误的回答。

• Missed the Top Ranked Documents 问题的答案其实在文档中，但由于排名不够高，没有被返回给用户。理论上，系统会对所有文档进行排名，然后在后续步骤中使用。但实际上，系统只会返回排名 top k 的文档，其中 k 是基于性能选择的一个值。

• Not in Context - Consolidation strategy Limitations 虽然包含答案的文档已经从数据库中检出，但却未能被纳入用于生成答案的上下文中。这种情况通常发生在数据库返回大量文档，并进行了整合处理以提取答案的情况下

• Not Extracted 虽然答案确实存在于上下文中，但大语言模型却未能抽取出正确的答案。这种情况通常发生在上下文中存在过多的干扰信息或者信息之间存在矛盾的时候。

• Wrong Format 问题需要以特定的格式（如表格或列表）提取信息，但大语言模型并未按照这个要求执行。

• Incorrect Specificity 虽然用户可以从响应中获取答案，但答案可能过于笼统或者过于详细，无法满足用户的实际需求。这种情况通常出现在 RAG 系统的设计者对某个问题有特定的预期结果，比如教师对学生的期望。在这种情况下，我们需要提供的不仅仅是答案，还应包含具体的教育内容。另外，当用户不清楚如何准确提问，或者提问过于宽泛时，也可能导致返回的答案过于模糊或过于详细。

• Incomplete 虽然不完整的答案并不算是错误，但却可能遗漏了一些原本可以从上下文中获取的信息。比如，如果一个问题是“文档 A、B 和 C 中都涵盖了哪些关键点？”，这种情况下，将问题分开来逐一提问可能会是一个更好的策略。

Lessons and Future Research Directions

我们从三个案例研究中学到的教训已在 表2 中列出。对于研究问题"在构建 RAG 系统时，有哪些关键考虑因素？"，我们的发现如下：根据我们的总结，我们找到了几个与 RAG 有关的潜在研究领域，具体如下：

Chunking and Embeddings

文档分块看似简单，然而分块的质量以多种方式影响检索过程，尤其是通过影响块的嵌入，进而影响块与用户查询的相似性和匹配。有两种分块的方式：一种是基于启发式的分块（通过使用标点符号，段落结束等方式），另一种是语义分块（利用文本中的语义信息来确定块的开始和结束）。进一步的研究应探讨这两种方法之间的权衡，以及它们对关键下游过程，如嵌入和相似性匹配的影响。一个系统性的评估框架，对分块技术在诸如查询相关性和检索准确性等指标上的效果进行比较，将对这个领域有所贡献。

嵌入是另一个热门的研究领域，包括为多媒体和多模态块（如表格、图形、公式等）生成嵌入。通常在系统开发过程中或新文档被索引时，会创建一次块嵌入。查询预处理在很大程度上影响了 RAG 系统的性能，尤其是在处理负面或模糊查询时。我们需要进一步研究架构模式和方法，以应对嵌入的固有限制（匹配质量是领域特定的）。

RAG vs Finetuning

大语言模型（LLMs）因其大量的训练数据和在发布前对模型进行的微调，被视为优秀的全球模型。但是，这些模型是通用的（可能并不了解你特定领域的具体知识），并且知识库并不是最新的（存在知识截止日期）。微调和 RAG 提供了两种可能的定制方式，每种方式都有其独特的权衡。微调需要收集内部数据集来调整和训练大语言模型。然而，你所有的数据都会被集成到模型中，你需要解决安全/隐私问题（谁能访问什么）。此外，随着基础模型本身的改进或者你获得新的数据添加到模型中，你需要再次进行微调。另一方面，RAG 系统似乎提供了一个实用的解决方案，允许你根据需要划分你的数据，并只把相关的数据片段纳入到上下文中，让大语言模型从这些上下文中生成答案。这方便了用新的文档持续更新知识，并且也给了用户对哪些数据片段可访问的控制权。然而，对于数据片段的嵌入、检索和上下文融合的最优策略，仍然是研究的热点。未来的研究应系统地比较微调和 RAG 的各种因素，包括准确性、延迟、运行成本和鲁棒性。

Testing and Monitoring RAG systems

对于 RAG 系统，其软件工程的最佳实践仍在探索阶段。软件测试和测试用例的生成是其中需要进一步优化的领域。RAG 系统需要的问题和答案通常是特定于应用的，在对非结构化文档进行索引时，这些问题和答案往往无法直接获取。目前有一些新的研究尝试使用大语言模型从多个文档中生成问题。然而，如何生成与特定领域相关的、符合实际情况的问题和答案，这仍然是一个未解决的问题。

一旦获得了合适的测试数据，我们还需要质量度量标准来帮助工程师进行质量取舍。使用大语言模型的成本高昂，同时也带来了延迟问题，每次新版本的发布都会改变其性能特性。这种特性在机器学习系统中已经被研究过，但是针对基于大语言模型的系统（如RAGs）所需的适应性策略（如果有的话）尚未实施。另一种思路是将自适应系统的理念融入到 RAG 系统的监控和调整中，其他机器学习应用的初步工作已经开始尝试这种方法。

CONCLUSION

RAG 系统是一种革新性的信息检索技术，它巧妙地运用了大语言模型（LLM）。现在，软件工程师越来越多地通过实施语义搜索或参与新的代码相关任务，来与 RAG 系统进行互动。本文分享了我们在进行三个案例研究的过程中，包括对15000份文档和1000个问题的实证研究，所得到的宝贵经验与发现。这些发现为实践者提供了实施 RAG 系统时可能面临的挑战，为他们指明了方向。我们还对 RAG 系统的未来研究方向进行了探讨，包括：1) 如何进行分块和嵌入，2) RAG 与微调的关系，以及 3) 如何进行测试和监控。随着研究的深入，大语言模型将会拥有更多对工程师和研究人员有价值的新功能。本文是首次从软件工程的角度对 RAG 系统进行深入的探讨。

Source

Seven Failure Points When Engineering a Retrieval Augmented Generation System