检索增强生成 (RAG) 正在成为大型语言模型和向量数据库最受欢迎的应用之一。RAG 是将大型语言模型 (LLM) 的输入与从向量数据库（如 Weaviate）检索到的上下文进行增强的过程。RAG 应用通常用于聊天机器人和问答系统。
与任何工程系统一样，评估性能对于 RAG 应用的开发至关重要。RAG 管道分解为三个组成部分：1. 索引，2. 检索，和 3. 生成。RAG 评估具有挑战性，因为其组件之间存在一系列交互，并且收集测试数据也比较困难。本文将介绍使用 LLM 进行评估的令人兴奋的进展，以及 RAG 组件的现状。
TL;DR：我们受到与 Ragas 的创建者 Jithin James 和 Shauhul Es 在 第 77 届 Weaviate 播客 上的对话的启发，撰写了这篇博文。Ragas 和 ARES 率先提出的使用 LLM 评估 RAG 系统的这些新进展，促使我们反思之前的指标，并盘点需要调整的 RAG 旋钮。我们的调查使我们进一步思考了 RAG 实验跟踪软件可能的样子。我们还进一步阐明了我们如何区分 RAG 系统和 Agent 系统，以及如何评估每个系统。
我们的博文包含 5 个主要部分
- LLM 评估：使用 LLM 评估 RAG 性能的新趋势，以及零样本、少样本和微调 LLM 评估器的规模。
- RAG 指标：用于评估生成、搜索和索引的常用指标，以及它们之间的相互作用。
- RAG：可调整的旋钮：是什么决定了 RAG 系统的性能显著不同？
- 调整编排：我们如何管理 RAG 系统的实验配置跟踪？
- 从 RAG 到 Agent 评估：我们定义 RAG 是一个索引、检索和生成的三步过程。本节描述了 RAG 系统何时成为 Agent 系统，以及 Agent 评估有何不同。
LLM 评估
让我们从所有这些中最新的、最令人兴奋的组成部分开始，即 LLM 评估！机器学习的历史很大程度上受到人工标注数据的繁重劳动驱动，例如 Yelp 评论是正面还是负面，或者关于营养补充剂的文章是否与“波士顿凯尔特人队的主教练是谁？”这一查询相关。LLM 正在变得非常有效地进行数据标注，而无需人工努力。这是加速 RAG 应用开发的重点 “新进展”。
像 Ragas 这样的框架率先采用的最常见技术是零样本 LLM 评估。零样本 LLM 评估描述了使用提示模板来提示大型语言模型，例如：“请根据 1 到 10 的量表对搜索结果与查询的相关性进行评分。查询是 {query}，搜索结果是 {search_results}”。下图显示了如何使用 LLM 评估 RAG 系统的性能。
零样本 LLM 评估有三个主要的调整机会：1. 指标的设计，例如精确率、召回率或 nDCG，2. 这些提示的确切措辞，以及 3. 用于评估的语言模型，例如 GPT-4、Coral、Llama-2、Mistral 等。在撰写本文时，人们主要关心使用 LLM 进行评估的成本。让我们以 GPT-4 为例，看看评估 10 个搜索结果的成本，假设每个结果 500 个 token，查询和指令 100 个 token，总共 6,000 个 token 用于每次 LLM 调用，以便简化计算。然后假设每 1K token 的费率为 $0.005，评估 100 个查询的成本将为 $3。
来自 Ragas 等框架的零样本 LLM 评估的应用越来越广泛。这导致人们质疑是否需要少样本 LLM 评估。由于其在权衡尺度上的“足够好”状态，零样本 LLM 评估可能足以成为 RAG 系统调整的北极星。下图显示，RAGAS 分数由 4 个用于评估生成指标（**保真度**和**答案相关性**）的零样本 LLM 提示，以及 2 个用于评估检索指标（**上下文精确度**和**上下文召回率**）的提示组成。
从零样本到少样本 LLM 评估的过渡非常简单。与其只使用指令模板，我们添加几个带有相关性标注的搜索结果与查询的示例。这也被称为上下文学习，而这一技术的发现是 GPT-3 的关键突破之一。
例如，添加 5 个人工相关性评分示例，我们向提示添加 30,000 个 token。假设与上述相同的成本，我们将评估 100 个查询的成本从 $3 提高到 $15。请注意，这只是一个示例，并非基于 LLM 的实际定价模型。一个关键的考虑因素是，添加少样本示例可能需要更长的上下文模型，而这些模型的价格目前高于较小的输入 LLM。
这对于使用零样本或少样本推理进行 LLM 评估来说已经是一个非常有吸引力的价格，但进一步的研究表明，可以使用知识蒸馏训练算法进一步降低 LLM 评估的价格。这描述了使用 LLM 生成评估任务的训练数据，然后将其微调到较小的模型中。
在 ARES：用于检索增强生成系统的自动化评估框架中，Saad-Falcon 等人发现训练自己的 LLM 评估器可以比零样本提示表现更好。首先，“ARES 需要三个输入：目标语料库中的一组段落、150 个或更多注释数据点的人工偏好验证集，以及五个领域内查询的少样本示例。”然后，ARES 使用查询示例生成大量合成查询。然后使用循环一致性原则过滤这些查询：我们能否在用合成查询搜索时检索生成合成查询的文档？除了用于创建合成查询的段落之外，ARES 还通过从语料库中的其他文档中随机采样其他段落来添加弱负样本，并通过查找与用于生成查询的段落相同的文档中的段落，或者如果不可用，则使用来自 BM25 查询的前 10 个结果来添加强负样本。现在，配备了查询、答案、黄金文档和负样本，ARES 微调了用于**上下文相关性**、**答案保真度**和**答案相关性**的轻量级分类器。
作者尝试微调 DeBERTa-v3-large，它包含一个更经济的 4.37 亿参数，每个分类器头共享基础语言模型，添加 3 个分类器头。然后通过将合成数据划分为训练-测试集，并将微调的裁判与零样本和少样本 GPT-3.5-turbo-16k 裁判进行比较，发现微调的模型表现更好。有关更多详细信息，例如对预测驱动推理 (PPI) 的置信区间的新颖使用以及更多实验细节，请参阅 Saad-Falcon 等人 的论文。
为了更好地了解 LLM 对评估的潜在影响，我们将继续介绍现有 RAG 基准测试方法，以及它们如何因 LLM 评估而发生变化。
RAG 指标
我们从生成、检索和索引的顶部视角呈现 RAG 指标。然后，我们从构建索引、调整检索方式和生成选项的底部视角呈现 RAG 可调整的旋钮。
呈现 RAG 指标的另一个原因是，索引中的错误会冒泡到搜索和生成，但生成中的错误（如我们所定义的堆栈）不会影响索引中的错误。在当前的 RAG 评估状态下，很少对整个 RAG 堆栈进行端到端评估，而是假设**预言上下文**或**受控干扰因素**（例如“迷失在中间”实验）来确定生成中的保真度和答案相关性。同样，嵌入通常使用不考虑近似最近邻错误的蛮力索引进行评估。近似最近邻错误通常通过查找在准确性和每秒查询数和召回率之间进行权衡的帕累托最优点来衡量，ANN 召回率是指查询的真实最近邻，而不是标记为与查询“相关”的文档。
生成指标
RAG 应用的总体目标是提供一个有帮助的输出，该输出使用检索到的上下文作为支持。评估必须考虑输出使用了上下文，而没有直接从来源获取，避免冗余信息，并防止不完整的答案。为了对输出进行评分，需要一个涵盖每个标准的指标。
Ragas 引入了两个指标来衡量 LLM 输出的性能：忠实度和答案相关性。忠实度 观察答案基于检索到的上下文的事实正确性如何。答案相关性 确定在给定问题的情况下，答案的相关性如何。一个答案可以具有较高的忠实度得分，但较低的答案相关性得分。例如，一个忠实的回答是逐字复制上下文，然而，这将导致较低的答案相关性。当答案缺乏完整性或包含重复信息时，答案相关性得分会受到惩罚。
2020 年，Google 发布了 Meena，一个对话代理。Meena 的目标是展示它能够进行有意义和具体的对话。为了衡量开放域聊天机器人的性能，他们引入了合理性和具体性平均值 (SSA) 评估指标。通过其合理性来衡量机器人的响应，这意味着它需要在上下文中说得通，并且具有具体性（具体性平均值）。这确保了输出内容全面且不含糊不清。早在 2020 年，这需要人类与聊天机器人进行对话并手动分配这些评分。
虽然避免含糊的回答是好的，但同样重要的是避免 LLM 产生幻觉。幻觉指的是 LLM 生成的响应并非基于实际事实或提供的上下文。 LlamaIndex 使用 FaithfulnessEvaluator 指标来衡量这一点。该分数基于响应是否与检索到的上下文匹配。
确定生成的响应是好是坏取决于几个指标。你可以拥有事实准确但与给定查询无关的答案。此外，答案可能含糊不清，并且缺少支持响应的关键上下文信息。现在我们将退一步，回顾管道，并介绍检索指标。
检索指标
评估堆栈的下一层是信息检索。评估检索历史需要人类标注哪些文档与查询相关。因此，为了创建 1 个查询标注，我们可能需要标注 100 个文档的相关性。这对于一般的搜索查询来说已经是一项极其困难的任务，但对于构建特定领域的搜索引擎（例如法律合同、医疗患者病史等）来说，更具挑战性。
为了减轻标注成本，通常使用启发式方法进行搜索相关性分析。最常见的是点击日志，其中：给定一个查询，点击的标题很可能相关，而其他标题则不相关。这在机器学习中也称为弱监督。
一旦准备好数据集，就会使用三个常用指标进行评估：nDCG、召回率和精确率。NDCG（归一化折扣累积增益）衡量具有多个相关性标签的排名。例如，关于维生素 B12 的文档可能不是关于维生素 D 的查询最相关的结果，但它比关于波士顿凯尔特人队的文档更相关。由于相对排名的额外难度，通常使用二元相关性标签（1 表示相关，0 表示不相关）。召回率衡量搜索结果中捕获了多少正样本。然后，精确率衡量搜索结果中有多少被标记为相关。
LLM 还可以使用以下提示计算精确率：“以下搜索结果中有多少与查询 {query} 相关？ {search_results}”。还可以使用 LLM 提示获得召回率的代理指标：“这些搜索结果是否包含回答查询 {query} 所需的所有信息？ {search_results}”。我们同样鼓励读者查看 Ragas 中提供的一些提示 此处。
另一个值得探索的指标是 LLM 获胜，其中 LLM 收到提示：“基于查询 {query}，哪一组搜索结果更相关？集合 A {Set_A} 或集合 B {Set_B}。非常重要！请将您的输出限制为“集合 A”或“集合 B”。
现在让我们深入一层，了解如何比较向量索引。
索引指标
经验丰富的 Weaviate 用户可能熟悉 ANN 基准测试，例如，它启发了 Weaviate 1.19 中 gRPC API 的开发。ANN 基准测试衡量每秒查询次数与召回率，以及单线程限制等细微差别。数据库通常根据延迟和存储成本进行评估，随机向量索引更加强调准确性测量。这与 SQL select 语句中的近似值 有些类似，但我们预测随着向量索引的普及，由近似引起的误差将更加重要。
准确性是根据召回率来测量的。向量索引中的召回率衡量通过近似索引算法返回的多少个真实最近邻居是由暴力搜索确定的。这与通常在信息检索中使用“召回率”来指返回多少个相关文档的方式不同。两者通常都使用相关的 @K 参数进行测量。
在 RAG 堆栈的完整上下文中，有趣的问题是：ANN 准确性错误何时会转化为 IR 错误？ 例如，我们可以在 80% 的召回率下获得 1,000 QPS，而在 95% 的召回率下获得 500 QPS，这会对上述搜索指标（例如搜索 nDCG 或 LLM 召回率得分）产生什么影响？
关于 RAG 指标的总结
总而言之，我们介绍了用于评估索引、检索和生成的指标
- 生成：忠实度和答案相关性，以及从大量关注检测幻觉和其他指标（例如合理性和具体性平均值 (SSA)）的演变。
- 检索：使用 LLM 评级的上下文精确度和上下文召回率的新机会，以及概述了如何使用人工标注来衡量召回率、精确率和 nDCG。
- 索引：测量召回率，即从向量搜索算法返回的真实最近邻居数量。我们认为这里的关键问题是：ANN 错误何时会渗入 IR 错误？
所有组件通常都有一个选项，可以在性能、延迟或成本之间进行权衡。我们可以使用更昂贵的语言模型获得更高质量的生成，可以使用重新排序器过滤结果以获得更高质量的检索，并且可以使用更多的内存来获得更高的索引召回率。如何管理这些权衡以提高性能，希望随着我们继续研究“RAG：要调整的旋钮”而变得更加清晰。作为快速提醒，我们选择从上到下地呈现指标，从生成到搜索和索引，因为评估时间更接近用户体验。或者，我们将从下到上地呈现要调整的旋钮，从索引到检索和生成，因为这类似于 RAG 应用程序开发人员的体验。
RAG 要调整的旋钮
现在我们已经介绍了比较 RAG 系统的指标，让我们深入研究可以改变性能的重大决策。
索引旋钮
为了设计 RAG 系统，最重要的索引旋钮看起来像是向量压缩设置。Weaviate 1.18 于 2023 年 3 月发布，推出了产品量化 (PQ)。PQ 是一种向量压缩算法，它将向量的连续片段分组，跨集合聚类其值，然后使用质心降低精度。例如，4 个 32 位浮点数的连续片段需要 16 字节来表示，片段长度为 4 个，8 个质心只需要 1 字节，内存减少了 16:1。最近在 PQ 重评分方面的进展有助于显着减少这种压缩带来的召回率损失，但仍然是使用非常高的压缩水平时需要考虑的重要因素。
下一步是使用的路由索引。对于少于 10K 向量的语料库，RAG 应用程序可能对暴力索引感到满意。但是，随着向量数量的增加，暴力索引的延迟会比 HNSW 等近似最近邻算法慢得多。如 RAG 指标中所述，HNSW 性能通常被测量为在每秒查询次数与召回率之间进行权衡的帕累托最优点。这是通过改变推理时使用的 ef（或搜索队列大小）来实现的。较大的 ef 会导致搜索期间进行更多的距离比较，从而显着减慢速度，但会产生更准确的结果。接下来要查看的参数是用于索引构建的参数，efConstruction 是将数据插入图时队列的大小，以及 maxConnections 是每个节点上的边数，这些边也必须与每个向量一起存储。
我们正在探索的另一个新方向是分布偏移对 PQ 中心点的影响，以及它与混合聚类和图索引算法的交叉点，例如 DiskANN 或 IVFOADC+G+P。使用召回率指标可能足以衡量这一点，从而触发中心点的重新拟合，然后的问题是：使用哪些向量子集进行重新拟合。如果我们使用导致召回率下降的最后 100K 个向量，我们可能会面临过度拟合新分布的风险，因此我们可能需要对 Weaviate 中插入的数据分布的时间线进行混合采样。这个话题与我们对深度学习模型持续优化的看法密切相关，在“Orchestrating Tuning”中会进一步讨论。
在将数据插入 Weaviate 之前，对数据进行分块是一个重要的步骤。分块将长文档转换为较小的部分。这增强了检索，因为每个分块都包含重要的信息片段，这有助于保持在 LLM 的 token 限制范围内。有很多策略可以解析文档。上面的可视化图示了基于标题将研究论文转换为分块。例如，分块 1 是摘要，分块 2 是引言，依此类推。此外，还有结合分块和具有重叠的方法。包括滚动窗口会从前一个分块中获取 token，并用它开始下一个分块。分块的轻微重叠可以改善搜索，因为检索器将理解先前的上下文/分块。下图展示了文本分块的高级图示。
检索
在检索中，有四个主要的旋钮可以调整：嵌入模型、混合搜索权重、是否使用 AutoCut 以及重新排序模型。
大多数 RAG 开发人员可能会立即跳到调整使用的嵌入模型，例如 OpenAI、Cohere、Voyager、Jina AI、Sentence Transformers 以及许多其他模型！开发人员还需要考虑模型的维度以及它如何影响 PQ 压缩。
下一个关键决策是如何权衡混合搜索中稀疏和密集检索方法的聚合。权重基于 alpha 参数。alpha 为 0 是纯 bm25，而 alpha 为 1 是纯向量搜索。因此，alpha 的设置取决于你的数据和应用。
另一个新兴的发展是零样本重新排序模型的有效性。Weaviate 目前提供 2 个 来自 Cohere 的重新排序模型：rerank-english-v2.0 和 rerank-multilingual-v2.0。顾名思义，这些模型的主要区别在于使用的训练数据以及由此产生的多语言能力。未来，我们预计会进一步选择性地削减模型的容量，因为性能和延迟之间存在固有的权衡，这对于某些应用来说可能是有意义的，而对于其他应用来说则不然。共同发现需要哪种容量的重新排序器以及要重新排序的检索结果数量是调整检索旋钮的另一个挑战。这也是 RAG 堆栈中微调自定义模型的最低成本机会之一，我们将在“Tuning Orchestration”中进一步讨论。
另一个有趣的旋钮可以调整的是多索引搜索。与我们对分块的讨论类似，这可能涉及数据库的结构性更改。从广义上讲，存在一个问题：何时使用单独的集合而不是过滤器？ blogs 和 documentation 是否应该分成两个集合，还是共同存储在一个 Document 类中，并具有 source 属性？
使用过滤器为我们提供了一种快速测试这些标签效用的方法，因为我们可以将多个标签添加到每个分块，然后评估分类器如何使用这些标签。这里有很多有趣的想法，例如显式地注释上下文来自 LLM 输入的来源，例如“以下是来自博客的搜索结果 {search_results}。以下是来自文档的搜索结果 {documentation}”。随着 LLM 能够处理更长的输入，我们预计跨多个数据源的上下文融合将变得更加流行，因此，与从每个索引或过滤器检索多少文档相关的超参数也会出现。
生成
在生成方面，显而易见的第一件事是选择 LLM。例如，你可以选择 OpenAI、Cohere、Facebook 和许多开源选项。许多 LLM 框架（如 LangChain 和 LlamaIndex，以及 Weaviate 的 generate 模块）提供与各种模型的轻松集成也很有帮助。你选择的模型可能取决于你是否希望保持数据的私密性、成本、资源等等。
一个常见的 LLM 特定旋钮可以调整的是温度。温度设置控制输出中的随机量。温度为 0 意味着响应更可预测，变化更小。温度为 1 赋予模型在响应中引入随机性和创造力的能力。因此，如果你多次运行生成模型并且温度为 1，则响应每次重新运行时可能会有所不同。
长上下文模型是选择应用程序的 LLM 的一个新兴方向。将更多的搜索结果添加到输入中是否能提高答案质量？“Lost in the Middle”实验在这里稍微降低了期望。在 Lost in the Middle 中，斯坦福大学、加州大学伯克利分校和 Samaya AI 的研究人员展示了受控实验，表明如果相关信息放置在搜索结果的中间，而不是开头或结尾，则语言模型将无法将其整合到生成的响应中。来自 Google DeepMind、丰田和普渡大学的研究人员的另一篇论文表明，“大型语言模型很容易被无关上下文分散注意力。” 虽然潜力令人着迷，但就目前而言，长上下文 RAG 似乎还为时过早。幸运的是，诸如 Ragas 分数之类的指标可以帮助我们快速测试新的系统！
与我们之前关于 LLM 评估的突破性进展的讨论类似，生成有 3 个调整阶段：1. 提示调整，2. Few-Shot 示例，以及 3. 微调。提示调整包括调整使用的特定语言，例如：“请根据提供的搜索结果回答问题。”与“请回答问题。重要提示，请密切遵循这些说明。你的答案必须基于提供的搜索结果，除此之外一无所有！！”。
如前所述，Few-Shot 示例描述了收集一些手动编写的问题、上下文、答案对，以指导语言模型的生成。最近的研究，例如 “In-Context Vectors”，进一步表明了引导潜在空间的重要性。我们使用 GPT-3.5-turbo 在 Weaviate Gorilla 项目中生成 Weaviate 查询，一旦我们添加了自然语言到查询翻译的 few-shot 示例，性能就飙升了。
最后，人们对为 RAG 应用程序微调 LLM 的兴趣日益浓厚。这方面有几种口味。再次让人想起我们对 LLM 评估的讨论，我们可能希望使用更强大的 LLM 来生成训练数据，从而生成一个更小、更经济的模型，由你拥有。另一个想法是提供人工对响应质量的注释，以微调具有指令遵循的 LLM。如果你有兴趣微调模型，请查看 Brev 的这个 教程，了解如何使用 HuggingFace PEFT 库。
关于 RAG 旋钮的总结
总而言之，我们已经介绍了 RAG 系统中要调整的主要旋钮
- 索引：在最高级别，我们考虑何时仅使用暴力搜索，以及何时引入 ANN 索引。这在调整具有新用户和高级用户的多租户用例时尤其有趣。在 ANN 索引中，PQ 的超参数为（segments、centroids 和训练限制）。HNSW 具有（ef、efConstruction 和 maxConnections）。
- 检索：选择嵌入模型、权衡混合搜索、选择重新排序器以及将集合划分为多个索引。
- 生成：选择 LLM 以及何时从提示调整过渡到 Few-Shot 示例或微调。
掌握了对 RAG 指标的理解以及我们可以调整它们以改进它们。让我们讨论实验跟踪可能是什么样子。
调整编排
鉴于 LLM 评估的最新进展以及对一些旋钮的概述，最令人兴奋的机会之一是将所有这些与实验跟踪框架结合起来。例如，一个简单的编排器，它具有一个直观的 API，供用户 1. 请求对例如：5 个 LLM、2 个嵌入模型和 5 个索引配置进行详尽的测试，2. 运行实验，以及 3. 向用户返回高质量的报告。Weights & Biases 为训练深度学习模型铺平了令人难以置信的实验跟踪道路。我们预计对这种 RAG 实验的支持兴趣会加速，包括我们在此文章中概述的旋钮和指标。
这方面有几个方向值得关注。一方面，像 GPT-4、Command、Claude 和开源选项（如 Llama-2 和 Mistral）这样的零样本 LLM 在它们具有 oracle 上下文 时表现相当不错。因此，有一个巨大的机会 只关注搜索部分。这需要找到 PQ 或 HNSW 权衡的 ANN 误差、嵌入模型、混合搜索权重和重新排序的配置中的一根针，如本文前面所述。
Weaviate 1.22 引入了异步索引功能，以及相应的节点状态 API。我们希望与专注于 RAG 评估和调优编排的合作伙伴合作，他们可以使用这些 API 来查看索引构建何时完成，然后运行测试。考虑到这些节点状态与每个租户的调优编排之间的接口，这一点尤其令人兴奋，因为有些租户可能可以使用蛮力方法，而另一些租户则需要为他们的数据找到合适的嵌入模型和 HNSW 配置。
此外，我们可能希望通过并行化资源分配来加速测试。例如，同时评估 4 个嵌入模型。如前所述，另一个有趣的组成部分是对来自我们数据导入器的分块或其它符号元数据进行调优。为了更清晰地说明，Weaviate Verba 数据集包含 3 个文件夹的 Weaviate Blogs、Documentation 和 Video 转录文件。如果我们想要消融 100 与 300 的分块大小，可能没有必要重新调用网络爬虫。相反，我们可能需要另一种格式，无论该数据存储在 S3 存储桶中还是其他地方，它都具有相关的元数据，但提供了一种更经济的方式来试验。
另一方面，我们还有模型微调和使用梯度进行持续学习，而不是数据插入或更新。在 RAG 中使用的最常见的模型是嵌入、重排序器和当然，LLM。使用新数据保持机器学习模型的最新状态一直是持续学习框架和 MLops 编排的长期关注点，这些框架和编排管理新模型的重新训练、测试和部署。从 LLM 的持续学习开始，RAG 系统最大的卖点之一是能够扩展 LLM 知识库的“截止”日期，使其与您的数据保持最新。LLM 能否直接做到这一点？我们认为，持续训练和纯粹使用 RAG 保持信息新鲜之间的相互作用效果尚不清楚。一些研究，例如 MEMIT，尝试使用因果中介分析的权重归因来更新事实，例如将“勒布朗·詹姆斯打篮球”更新为“勒布朗·詹姆斯打足球”。这是一种非常高级的技术，另一个机会可能是简单地标记用于训练的分块，例如“勒布朗·詹姆斯打篮球”，并使用包含新信息的回溯增强训练数据进行重新训练。这是我们正在密切关注的一个重要领域。
如前所述，我们还在考虑如何将这种持续调优直接与 Weaviate 的 PQ 中心点接口。PQ 中心点与进入 Weaviate 的前 K 个向量相适应，可能会受到数据分布显著变化的影响。机器学习模型的持续训练有一个臭名昭著的“灾难性遗忘”问题，即在最新一批数据上进行训练会损害早期批次数据的性能。这也是我们在设计重新拟合 PQ 中心点时正在考虑的一个问题。
从 RAG 到 Agent 评估
在整篇文章中，我们一直关注的是 RAG，而不是 Agent 评估。在我们的观点中，RAG 由索引、检索和生成流程定义，而 Agents 具有更开放的范围。下图说明了我们如何看待规划、记忆和工具等主要组件，它们共同为您的系统增加了强大的功能，但也使其更难以评估。
RAG 应用程序的常见下一步是添加高级查询引擎。对于对该概念感兴趣的读者，请查看我们的 LlamaIndex 和 Weaviate 系列的 第 3 集，其中提供了如何入门的 python 代码示例。有许多不同的高级查询引擎，例如子问题查询引擎、SQL 路由器、自我纠正查询引擎等。我们还在考虑 Weaviate 的模块中 promptToQuery API 或搜索查询提取器可能是什么样子。每个查询引擎在信息检索过程中都有其自身的优势，让我们深入研究其中的几个，以及我们可能如何考虑评估。
多跳查询引擎（也称为 子问题查询引擎）非常适合将复杂问题分解为子问题。在上面的视觉效果中，我们有查询“Weaviate 中的 Ref2Vec 是什么？”。要回答这个问题，您需要分别知道 Ref2Vec 和 Weaviate 是什么。因此，需要向您的数据库发出两次调用，以根据这两个问题检索相关上下文。然后将两个答案组合成一个输出。可以通过观察子问题来评估多跳查询引擎的性能。重要的是，LLM 正在创建相关子问题，准确地回答每个问题，并将两个答案组合起来提供一个事实和相关的输出。此外，如果您正在提出复杂的问题，最好使用多跳查询引擎。
多跳问题首先取决于子问题的准确性。我们可以想象在这里使用类似的 LLM 评估，提示为：“给定问题：{query}。系统决定将其分解为子问题 {sub_question_1} 和 {sub_question_2}。这种问题分解是否有意义？”。然后，我们对每个子问题进行两个单独的 RAG 评估，然后评估 LLM 是否能够组合来自每个问题的答案来回答原始问题。
作为从 RAG 到 Agent 复杂性演变的另一个例子，让我们考虑路由查询引擎。下图说明了一个 Agent 将查询路由到 SQL 或向量数据库查询。这种情况与我们对多索引路由的讨论非常相似，我们可以类似地使用解释 SQL 和向量数据库需求的提示以及询问 LLM 路由器是否做出了正确决定的提示来评估生成。我们还可以对 SQL 查询的结果使用 RAGAS 上下文相关性分数。
在结束我们对“从 RAG 到 Agent 评估”的讨论时，我们认为现在判断 Agent 使用的常见模式还为时过早。我们有意展示了多跳查询引擎和查询路由器，因为它们相对容易理解。一旦我们添加了更多的开放式规划循环、工具使用以及与模型格式化 API 请求到工具、以及更多元内部内存管理提示（例如 MemGPT 中的想法），就很难提供围绕 Agent 将如何被评估的通用抽象。
结论
非常感谢您阅读我们关于 RAG 评估的概述！作为快速回顾，我们首先介绍了使用 LLM 进行评估的新趋势，为迭代 RAG 系统提供了巨大的成本和时间节省。然后，我们提供了有关传统上用于评估 RAG 堆栈的指标的一些背景，从生成、到搜索，再到索引。对于希望提高这些指标性能的构建者，我们随后介绍了一些可以在索引、搜索和生成中调整的旋钮。我们提出了这些系统的实验跟踪带来的挑战，以及我们对 RAG 评估与 Agent 评估之间差异的看法。我们希望本文对您有所帮助！我们很乐意在 X 上与您联系，地址是 @ecardenas300 和 @CShorten30！
准备开始构建了吗？
请查看 快速入门教程，或使用 Weaviate Cloud (WCD) 的免费试用版构建令人惊叹的应用程序。