提高检索增强生成(RAG)系统性能的 10 种方法

快速入门指南不够用

“检索增强生成是通过从其他地方检索到的额外信息来补充用户输入的大型语言模型（如 ChatGPT）的过程。然后，该模型可以使用这些信息来增强其生成的响应。” — 科里·祖伊

LLMs 是一项惊人的发明，但容易出现一个关键问题。它们会编造内容。RAG 通过为 LLMs 提供事实背景，使其在回答查询时更加有用。

使用像 LangChain 或 LlamaIndex 这样的框架快速入门指南，任何人都可以用大约五行代码构建一个简单的 RAG 系统，比如一个文档聊天机器人。

但是，用那五行代码构建的机器人不会运行得很好。RAG 很容易原型化，但很难投入生产——即达到用户满意的程度。一个基本的教程可能会让 RAG 达到 80%的效果。但要跨越剩下的 20%通常需要进行一些认真的实验。最佳实践尚未确定，并且可能因使用案例而异。但弄清最佳实践非常值得我们的时间，因为 RAG 可能是使用LLMs的最有效方法。

这篇文章将调查提高 RAG 系统质量的策略。它专为那些希望弥合基本设置与生产级性能之间差距的 RAG 构建者量身定制。就本文而言，提高意味着增加系统能够：1. 找到适当的上下文和 2. 生成适当响应的查询比例。我假设读者已经了解 RAG 的工作原理。如果没有，我建议阅读 Cory Zue 的这篇文章以获得一个良好的介绍。本文还假设读者对构建这些工具所使用的常见框架有一些基本的了解：LangChain 和 LlamaIndex。然而，这里讨论的想法是与框架无关的。

我不会深入探讨如何具体实施我所涵盖的每个策略，而是会尝试说明它们何时以及为何可能有用。鉴于该领域发展迅速，不可能提供详尽或完全最新的最佳实践清单。相反，我的目标是概述一些在尝试改进您的检索增强生成应用程序时可能考虑和尝试的事项。

提高检索增强生成性能的 10 种方法

清理你的数据。

RAG 将 LLM 的能力连接到您的数据。如果您的数据在内容或布局上令人困惑，那么您的系统将会受到影响。如果您使用包含冲突或冗余信息的数据，您的检索将难以找到正确的上下文。而当它找到时，由 LLM 执行的生成步骤可能会不理想。假设您正在为初创公司的帮助文档构建一个聊天机器人，但发现它运行不佳。您首先应该查看的是您输入系统的数据。主题是否逻辑清晰地分开？主题是集中在一个地方还是分散在多个地方？如果您作为人类，无法轻松判断需要查看哪个文档来回答常见问题，那么您的检索系统也无法做到。

这个过程可以像手动合并同一主题的文档一样简单，但你可以更进一步。我见过的一个更有创意的方法是使用LLM创建所有提供作为上下文的文档的摘要。检索步骤可以首先对这些摘要进行搜索，只有在必要时才深入细节。一些框架甚至把这作为内置的抽象功能。

2. 探索不同的索引类型。

索引是 LlamaIndex 和 LangChain 的核心支柱。它是保存检索系统的对象。标准的 RAG 方法涉及嵌入和相似性搜索。将上下文数据分块，嵌入所有内容，当查询到来时，从上下文中找到相似的部分。这种方法非常有效，但并不是每种用例的最佳方法。查询是否与特定项目相关，例如电子商务商店中的产品？您可能想探索基于关键字的搜索。它不必是其中之一，许多应用程序使用混合方法。例如，您可以使用基于关键字的索引来处理与特定产品相关的查询，但依赖嵌入来进行一般的客户支持。

3. 尝试你的分块方法。

将上下文数据分块是构建 RAG 系统的核心部分。框架抽象了分块过程，让你无需考虑它。但你应该考虑它。块大小很重要。你应该探索什么最适合你的应用程序。一般来说，较小的块通常会改善检索，但可能会因为缺乏周围的上下文而导致生成效果不佳。你可以用很多方法来处理分块。唯一行不通的方法是盲目处理。这篇来自 PineCone 的文章列出了一些可以考虑的策略。我有一组测试问题。我通过运行实验来处理这个问题。我用小、中、大三种块大小分别循环遍历每组，发现小块效果最好。

4. 试着调整你的基础提示。

LlamaIndex 中使用的基本提示的一个例子是：

‘上下文信息如下。根据上下文信息而不是先前的知识，回答查询。’

您可以覆盖此内容并尝试其他选项。您甚至可以修改 RAG，使其在上下文中找不到合适答案时依赖自身知识。您还可以调整提示词，以帮助引导其接受的查询类型，例如，指示其以某种方式回答主观问题。至少，覆盖提示词是有帮助的，这样 LLM 就能了解它正在做的工作。例如：

“您是一名客户支持代理。您的设计目的是尽可能提供帮助，同时只提供事实信息。您应该友好，但不要过于健谈。上下文信息如下。根据上下文信息而不是先前的知识回答查询。”

5. 尝试元数据过滤。

一种非常有效的改进检索的策略是向你的数据块添加元数据，然后使用它来帮助处理结果。日期是一个常见的元数据标签，因为它允许你按时间顺序过滤。想象一下，你正在构建一个允许用户查询其电子邮件历史记录的应用程序。最近的电子邮件可能会更相关。但从嵌入的角度来看，我们不知道它们是否与用户的查询最相似。这引出了一个在构建 RAG 时需要记住的一般概念：相似 ≠ 相关。你可以将每封电子邮件的日期附加到其元数据中，然后在检索过程中优先考虑最近的上下文。LlamaIndex 有一个内置的节点后处理器类，正好可以帮助实现这一点。

6. 使用查询路由。

通常拥有多个索引是很有用的。然后，当查询进来时，你可以将其路由到适当的索引。例如，你可能有一个索引处理总结性问题，另一个处理尖锐性问题，还有一个适合处理日期敏感性问题。如果你试图优化一个索引以适应所有这些行为，你最终会在所有这些方面都妥协。相反，你可以将查询路由到适当的索引。另一个用例是将一些查询定向到基于关键词的索引，如第 2 节所讨论的。

一旦构建了索引，你只需在文本中定义每个索引的用途。然后在查询时，LLM会选择适当的选项。LlamaIndex 和 LangChain 都有相应的工具。

7. 研究重新排序。

重排序是解决相似性和相关性之间差异问题的一种解决方案。通过重排序，您的检索系统像往常一样获取上下文的顶级节点，然后根据相关性对它们进行重新排序。Cohere Rereanker 通常用于此目的。我经常看到专家推荐这种策略。无论使用案例如何，如果您正在使用 RAG 构建系统，您应该尝试重排序，看看它是否能改进您的系统。LangChain 和 LlamaIndex 都有使其易于设置的抽象。

8. 考虑查询变换。

你已经通过将用户的查询放入你的基本提示中来修改它。进一步修改它也是有意义的。以下是一些例子：

改写：如果您的系统没有找到与查询相关的上下文，您可以让LLM重新表述查询并再次尝试。对人类来说看似相同的两个问题在嵌入空间中并不总是看起来那么相似。

HyDE：HyDE 是一种策略，它接受一个查询，生成一个假设响应，然后使用两者进行嵌入查找。研究发现，这可以显著提高性能。

子查询：LLMs 在分解复杂查询时通常效果更好。您可以将其构建到您的 RAG 系统中，使查询分解为多个问题。

LLamaIndex 有涵盖这些类型查询转换的文档。

9. 微调你的嵌入模型。

基于嵌入的相似性是 RAG 的标准检索机制。您的数据被分割并嵌入到索引中。当查询到来时，它也会被嵌入以与索引中的嵌入进行比较。但是什么在进行嵌入？通常是一个预训练模型，例如 OpenAI 的 text-embedding-ada-002。

问题是，预训练模型对嵌入空间中相似性的概念可能与您上下文中的相似性概念不太一致。想象一下，您正在处理法律文件。您希望嵌入能够更多地基于您的领域特定术语来判断相似性，比如“知识产权”或“违约”，而较少基于像“协议”这样的通用术语。

你可以微调你的嵌入模型来解决这个问题。这样做可以将你的检索指标提高 5-10%。这需要一些额外的努力，但可以对你的检索性能产生显著影响。这个过程比你想象的要简单，因为 LlamaIndex 可以帮助你生成训练集。

10. 开始使用LLM开发工具。

您可能已经在使用 LlamaIndex 或 LangChain 来构建您的系统。这两个框架都有有用的调试工具，可以让您定义回调，查看使用的上下文，检索来自哪个文档等。

如果你发现这些框架内置的工具不足，有一个不断增长的工具生态系统可以帮助你深入了解你的 RAG 系统的内部工作。Arize AI in-notebook tool ，可以让你探索正在检索的上下文以及原因。 Rivet 是一个提供可视化界面的工具，可以帮助你构建复杂的代理。它刚刚由法律技术公司 Ironclad 开源。新工具不断发布，值得尝试看看哪些对你的工作流程有帮助。

结论

使用 RAG 进行构建可能会令人沮丧，因为它很容易开始工作，但很难做到很好。我希望上述策略能为你提供一些灵感，帮助你弥合差距。这些想法没有一个是始终有效的，过程是实验、试验和错误的结合。在这篇文章中，我没有深入探讨评估，即如何衡量系统的性能。评估目前更像是一门艺术而不是科学，但建立某种类型的系统以便你可以持续检查是很重要的。这是判断你所实施的更改是否产生影响的唯一方法。我之前写过关于如何评估 RAG 系统的文章。有关更多信息，你可以探索 LlamaIndex Evals, LangChain Evals以及一个非常有前景的新框架 RAGAS.