检索增强生成 (RAG) 已成为扩展大型语言模型 (LLM) 功能的常见模式。

RAG 理论上很简单（只需将数据添加到上下文窗口！），但实践中很复杂。隐藏在框图之外的是高级分块策略、重新排序、多查询检索器、从小到大检索、假设文档嵌入、预嵌入数据丰富、动态路由、自定义嵌入模型……等等。

虽然建立初始 Pipeline 可能既快速又简单，但达到生产水平的质量却要复杂得多。如果不仔细考虑，RAG 系统可能会返回不正确、不相关或不一致的信息；他们可能会因性能不佳而苦苦挣扎，低效地消耗昂贵的资源，或者在扩展到生产规模的源数据时陷入困境。

了解如何有效且高效地评估 RAG 系统的质量需要了解所有各个部分如何协同工作以创建完整的 RAG Pipeline 。每个部分的设计决策都会影响质量，每个尝试部署 RAG 应用程序的人都应该理解这一点。

下面从测试和质量的角度介绍 RAG 概念和模式。我们将首先介绍为什么 RAG 有价值，然后讨论构建生产质量 RAG 所固有的许多设计决策如何寻求改进它。在我们讨论具体的评估方法和技术之前，本介绍将为我们提供必要的基础。RAG 系统。

LLM 的局限性

为了理解 RAG 流程，我们首先应该退后一步，了解 RAG 试图解决的 LLM 的局限性。

LLM 的核心很简单：您向他们发送提示，然后得到回复。

要返回响应，LLM 必须针对模型运行推理计算。该计算涉及将输入与定义模型的数百万甚至数千亿个*参数相结合。*这是一个昂贵的计算。

与申请 LLM 的费用一样，培训 LLM 的难度要大几个数量级。训练是确定模型内参数最佳值的过程。有不同的算法用于计算最佳权重，但都涉及在给定输入上运行模型、计算误差、然后反向传播校正调整的迭代过程，以使答案会稍微好一些。这是针对很多很多输入进行很多很多次，最终你得到一个经过训练的模型。虽然模型推理可能需要几秒钟，但模型训练可能需要*数周时间，*即使在大规模 GPU 集群上也是如此。

巨大的培训成本为将新的或更新的信息纳入 LLM 造成了瓶颈。大多数公司没有资源来训练模型，也不能简单地通过使用私人数据进行训练来向 LLM “添加新信息”。相反，资金雄厚的大型科技公司在大型公共数据集上训练通用基础模型，并且这些模型通过 RAG 等二级流程增强了新的能力和信息。

具体来说，RAG 旨在让 LLM 获得大量额外知识，从而避免训练新模型的昂贵过程。

RAG 基础知识

让我们了解一下 RAG 的实际工作原理。

发送给 LLM 的提示的长度有限，称为*上下文窗口。*上下文窗口以标记来衡量（对于我们的目的来说，大约相当于单词）。上下文窗口的大小通常为 1K、4K 或更多令牌，尽管更大的上下文窗口正在变得可用（例如：具有 128K的 Gemini 1.5 Pro）。

许多人直观地认为上下文窗口只是您可以提出的最长的问题，但这是考虑上下文窗口的一种限制方式。由于 LLM 的工作方式，LLM 在生成响应时可以使用上下文窗口中提供的信息*。因此，它可用于提供附加信息。这通常称为情境学习。*

因此，我们可以使用上下文窗口来提供 LLM 回答问题所需的新知识。例如，我们可以创建一个提示，询问公司关于丧亲之痛的政策，然后将整个公司手册填充到提示中（包括有关丧亲之痛的部分），只要它适合上下文窗口即可。这种方法将允许 LLM 使用提供的新信息做出回应。

当我们已经拥有相关信息并且该信息可以适合上下文窗口时，此解决方案很简单。不幸的是，情况并非总是如此。因此，我们需要某种机制来检索和向下选择与我们的提示相关的信息。

一种简单的方法是在整个可能相关的数据中对提示中的术语进行关键字搜索，复制命中周围的文本，然后将此文本添加到提示中。

这种简单形式的关键字搜索RAG 可以提高 LLM 响应，并且在某些情况下可能有用，但也可能会出现误报（在不同情况下使用关键字）。幸运的是，我们可以通过利用语义搜索做得更好，我们匹配文本的含义，而不是原始单词。

具体来说，我们可以利用嵌入模型从可能相关的数据块创建嵌入，然后在这些嵌入中执行搜索以查找与我们的提示相关的数据。这种方法高度简化，但它开始看起来像真正的 RAG。

RAG 和嵌入

要了解 RAG 相对于简单关键字搜索的优势，需要了解嵌入模型的目的和性质。这本身是一个很深的话题，但对于理解 RAG 至关重要。

嵌入模型与我们最初的 LLM 类似，但它们不是生成新内容，而是减少向量的输入（只是一个数字列表）。对于嵌入模型来说，它们是非常大的数字列表。嵌入模型创建的向量通常是 768 或 1536 个数字（*维度），*但也存在其他大小的向量。

嵌入模型创建的向量不仅仅是一组随机数字；而是一组随机数字。它是根据模型对输入数据的含义进行的升华。该向量对其他模型没有意义，但“相似”文本会在同一模型中创建相似的向量。相似不仅仅是“具有相同的关键字”——嵌入模型经过专门训练，可以从非结构化数据中提取更深层次的语义含义。例如，“Guy horses do not Fly”和“A Fly Guy horsing around”尽管有相似的单词，但不会是接近的向量。

向量的伟大之处在于你可以对它们进行数学运算。快速数学。可以在相当短的时间内搜索数百万个向量以找到相似的向量。 

现在我们已经有了 RAG Pipeline 的各个部分，所以让我们逐步完成这些步骤。

前四个步骤只需完成一次，或者一次并随着源数据的更改而更新。对每个推理请求执行第五步到第八步：

1. 我们收集所有可能相关的数据——数据太多，以至于我们不可能将其放入提示的上下文窗口中。

2. 我们将这些数据分成更小的部分（稍后会详细介绍）。

3. 然后，我们通过嵌入模型运行每个块，以创建一个封装该块含义的向量。

4. 我们将向量保存到向量数据库中。

5. 对于每个推理请求：当我们收到提示时，我们通过与分块源数据相同的嵌入模型运行该提示，以生成另一个向量（称为提示向量或查询向量）。

6. 我们在向量数据库中搜索与提示向量相似的向量。返回的向量将比我们仅通过关键字搜索原始数据更好的匹配。

7. 我们（可选）对识别出的相关向量进行重新排序，然后返回每个顶级向量的原始数据。

8. 原始数据与初始提示相结合并发送给 LLM 。

我们的 LLM 现在的表现就好像它是根据我们输入矢量搜索的所有新的专有数据进行训练的，而无需对基础模型进行昂贵的训练。

至少，理论上应该是这样的。实际上，这种过于简单的 Pipeline 可能无法满足您的生产需求，您需要调整、改进、交换或扩展不同的部件，以满足您的特定应用程序的需求，然后才能获得高质量、可用于生产的 RAG Pipeline 。

RAG 设计和质量

上面介绍了 RAG，但正如我们之前所说，实践中的 RAG 可能要复杂得多，而这些现实世界的复杂性会影响应用程序质量。让我们逐步完成每个步骤，以了解 RAG Pipeline 中的一些实施挑战、质量风险和可能的替代方案。

1 、 采购相关数据、摄取和丰富

从头开始，我们必须找到所有“可能相关的数据”。

上面 RAG 图中的单个图标 (#1) 更有可能是从多个源获取数据的整个数据 Pipeline （或一组 Pipeline ！）；上演它；策划它；可能对其进行转换、匿名化和标记化；并执行数据 Pipeline 中常见的其他处理操作。

其中一些 Pipeline 可能会变得非常复杂，特别是当原始数据采用文本以外的格式时。例如，一些 Pipeline 广泛使用 OCR 技术来摄取大量扫描的物理文档。

如果源数据甚至没有进入矢量数据库，那么实施得最好的 RAG Pipeline 也会严重失败，并且根据该数据的种类、速度和数量，RAG 的这个摄取阶段可能会很复杂，而且源数据可能会很复杂。许多应用程序质量问题。

除了正常的数据 Pipeline 活动之外，RAG 还可以从数据丰富中受益。通常，其他系统（或人）具有有关源数据的上下文，这对于评估其含义非常有益。例如，可以使用来自其他系统的添加相关信息的标签或注释来丰富客户数据库。通常，其他生成模型或 NLP 用于创建更清晰或汇总的元数据。将所有这些视为嵌入生成之前的“预处理”，如果做得正确，它可以显着提高检索质量。

如果您正在评估 RAG 检索系统的质量，那么在数据到达 RAG Pipeline 的精美 AI 部分之前，非常值得您花时间了解数据的来源和摄取方式。

2、 分块

数据被摄取后但在通过嵌入模型运行之前，必须将其分割成离散的部分。那么，您如何决定如何分割数据呢？这称为分块策略。

多大或多小的块是最佳的？块应该重叠吗？除了按页面、段落或固定长度划分之外，还有更聪明的分块方法吗？非标准格式（代码、JSON 等）的数据应如何分块？

这些是分块策略试图回答的问题，并且没有完美的解决方案。不同的策略有不同的权衡。有些实施起来简单且快速，并给出了令人满意的结果。有些更加复杂和复杂，它们可以提供更好的命中率和LLM响应质量。将数据分块得太粗，您可能会用不相关的数据填充上下文窗口，排挤其他相关数据块，或者创建过于通用而无法获得有意义的匹配的嵌入。将其分块得太细，您可能会“剪掉”相关数据。

还有许多其他方法可用于优化分块。例如，在*从小到大检索中，*使用小块进行搜索，但每个块都链接到被检索以插入到上下文模型中的较大父块。上下文感知分块使用有关文档性质的现有知识将其智能地拆分为逻辑块。

此列表可能并不详尽，但显示了 RAG 实施者可用选项的多样性以及适当且经过调整的分块策略对应用程序整体质量的重要性。Pinecone 博客提供了有关其中许多策略的更多详细信息。

3、 嵌入模型选择和配置

有很多模型可以用来生成嵌入，不同的模型在不同的情况下会表现得更好或更差。有些模型经过预训练以供一般用途，有些则针对特定领域（即医疗记录）进行了微调。还可以针对应用程序处理的特定数据微调您自己的嵌入模型。

此外，许多模型具有不同的大小（这会影响嵌入生成的成本和时间）、不同的输入长度（它可以处理的最大块大小）和不同的输出向量维度（更高的维度 = 更准确，但需要更多的空间和慢点）。

某些嵌入模型只能通过 API 访问（例如，OpenAI嵌入端点），而其他嵌入模型则完全开源，可以在本地下载和运行或托管在云提供商中。

还可以对应用程序中的不同数据路径使用不同的嵌入模型。

虽然通常良好的嵌入模型可能足以满足许多 RAG 应用程序的需求，但其他应用程序可能会受益于特定的嵌入模型或定制训练的模型。

了解嵌入策略的设计注意事项以及该选择的质量特征将有助于深入了解应用程序的评估需求和方法。如需更多阅读，这里有关于评估嵌入模型选择的更深入的讨论。

4、 查询处理和嵌入

没有规则规定您必须在收到查询时完全按照传入查询运行嵌入模型。事实上，有很多方法可以优化此查询和生成的嵌入搜索，以提高应用程序的整体质量。如果查询直接来自可能编写了模糊、异想天开、不明确的查询的人类用户，则情况更是如此。

有了一些关于应用程序的性质或意图的额外知识，就有可能使用 LLM 或传统逻辑以更紧凑和明确的方式减少或重写查询，即，将查询重写为预期的内容，而不是实际问了什么。

查询处理的一种高级形式是HyDE，它创建一个假设的答案文档，并对相似文档（答案到答案）进行矢量搜索，而不是嵌入和搜索查询（问题到答案）。

另一种选择是将查询拆分为多个相关查询并并行运行每个查询，组合结果 - 多检索器模式。这个选项显然会带来处理成本，但它可以提高检索质量。

根据您的用例的具体情况，自定义查询处理可能是必要的，并且可能会显着影响应用程序的质量和行为。

5、 —矢量数据库和矢量搜索

虽然矢量搜索速度很快，但在矢量数据库中搜索与查询类似的嵌入仍然需要时间（也可能是金钱）成本。最小化这种成本的一种方法是语义缓存。在语义缓存中，在最初检索嵌入后，响应将被缓存，因此将来的类似搜索将直接从缓存返回数据。

当然，缓存增加了复杂性（并且是计算机科学中的两个难题之一 - 我不记得另一个问题的名称）。虽然缓存可以提高性能，但过时的缓存可能会损害响应质量，尤其是在源数据不稳定的环境中。

6、 重新排名

在上面的描述中，我们天真地假设我们可以用向量搜索返回的所有相关数据填充上下文窗口。显然，这是一种简化，并且必须有一些过程来确定应优先考虑所有返回向量中的哪些向量以包含在上下文窗口中。

即使我们可以将搜索结果放入上下文窗口中，许多研究表明上下文填充（填充上下文窗口）也会通过引入中间丢失问题对LLM召回率产生负面影响，从而影响响应质量（召回率是 LLM 在其上下文窗口中使用信息的能力）。

解决方案是在初始向量搜索之后添加重新排名作为附加步骤。

重新排序的 TLDR：嵌入模型针对速度进行了优化，因为它们需要针对大量文档运行。其他称为重新排序模型（或交叉编码器）的模型速度较慢，但针对准确性进行了优化。因此，使用快速不准确的嵌入模型来生成嵌入（保存在 VectorDB 中），然后使用慢速准确的模型在这个较小的集合中查找最高质量的文档。慢速准确搜索中的最佳匹配在上下文窗口中优先排序。

再说一遍，事情远不止这些，但这就是重新排名的本质。Pinecone 博客对该过程有更详细的描述。

重新排序可以显着提高 RAG（检索质量的衡量标准）返回的数据的相关性。上下文窗口中更多相关（或更少不相关）的数据将提高响应质量。虽然它增加了复杂性和延迟，但质量权衡在许多 RAG 应用程序中可能很有价值。

7、 大上下文窗口与 RAG

我们终于要调用 LLM 了，但在讨论即时工程之前，我们应该花点时间提一下 RAG 和大型上下文窗口之间的关系。

LLM技术正在快速发展，其中改进的一个维度是上下文窗口的大小。一个典型的例子是Gemini 1.5 Pro，于 2024 年 2 月发布，具有 128K 上下文窗口和（未公开发布）高达 100 万（！！！）代币的选项。

一些人最初推测一百万个令牌上下文窗口会使 RAG Pipeline 过时，但事实并非如此。这篇博客解释了为什么 RAG 即使在使用具有巨大上下文窗口的模型时也是有价值的（甚至是必需的）（剧透：成本、延迟和召回质量）。

大型上下文模型很有价值，可以帮助 LLM 响应需要综合大量事实（可能已或可能未通过 RAG 向下选择）的查询。

大型上下文窗口和 RAG 之间的关系将继续发展，RAG 实施者和测试人员应该了解这些权衡及其对应用程序质量的影响。

8、 快速生成

您从 VectorDB 中获取一堆相关数据，对其进行重新排序，最后得到一组适合您的 LLM 上下文窗口的相关数据。现在怎么办？您是否只是将这些数据与最初的问题一起推到提示的末尾并称其为好？

任何与 LLM 合作过的人都可以告诉你，其中的细微差别远不止于此。LLM 可能很强大，但也可能变化无常且令人沮丧。事实证明，提示中的小细节会显着影响响应质量。你的提示措辞方式、数据的顺序、你使用的语气、“慢慢来”等建议，甚至使用情感语言都会影响 LLM 的回答质量。有一些策略可以使用……您猜对了，其他经过专门训练来生成提示的模型可以自动生成最佳提示。这都是快速发展的即时工程领域的一部分。

将生成最高质量响应的精确提示模板通常是特定于模型和应用程序的，并且通常需要一些反复试验。考虑到 RAG 这个看似微小细节的质量影响，所采用的特定提示工程应该像系统的任何其他部分一样受到严格的评估和审查。

测量和评估 RAG 系统

我们已经了解了 RAG Pipeline 的主要部分，并（简要）讨论了它们对应用程序质量的影响。这是一个介绍，但应该提供对这些类型应用程序的内部工作原理和质量挑战的深入了解。有很多精彩的文章、博客和论文对 RAG 进行了更深入的探讨。

关键要点：实施 RAG 时有大量的选项和选择，每个选项和选择都需要权衡和质量影响。其中一些选择可以直接评估，有些选择会影响整体检索或响应质量。了解这些选择以及它们如何影响您的 RAG 系统对于实现整体应用的生产质量至关重要。

显而易见的下一个问题是：好的，但是我如何评估 RAG？如何衡量开放式自由答复的质量？我可以使用什么指标来实际测量什么？这些评估如何实现自动化，自动化程度如何？当 LLM 本质上是不确定的并且他们所使用的数据本质上是不稳定的时，我如何确保质量？