2023年老文回顾：RAG 系统构建流程与评估指南

检索增强生成（Retrieval Augmented Generation，RAG）正在成为大语言模型（LLM）和向量数据库最受欢迎的应用之一。RAG 是通过从向量数据库（例如 Weaviate）检索的上下文增强对大语言模型输入的过程。RAG 应用通常用于聊天机器人和问答系统。

像任何工程系统一样，性能评估对于 RAG 应用的开发至关重要。RAG 流水线被分为三个组件：

1. 索引
2. 检索
3. 生成

由于这些组件之间的交互复杂性以及收集测试数据的难度，RAG 评估具有一定的挑战性。本文将展示使用 LLM 进行评估和当前 RAG 组件状态的一项激动人心的发展。

简而言之：我们的灵感来源于与 Ragas 的创建者 Jithin James 和 Shauhul Es 在  中的对话。这些由 Ragas 和 ARES 开创的 LLM 评估 RAG 系统的新进展，促使我们反思现有指标并盘点可调整的 RAG 参数。在研究过程中，我们进一步思考了 RAG 实验跟踪软件的可能形态，并进一步明确了 RAG 系统与 Agent 系统的区别及其评估方式。

我们的博客文章包含以下五个主要部分：

• LLM 评估：使用 LLM 对 RAG 性能进行评分的新趋势，包括零样本、少样本和微调 LLM 评估器的规模。
• RAG 指标：用于评估生成、搜索和索引的常用指标及其相互作用方式。
• RAG 的调节参数：影响 RAG 系统性能显著不同的决策是什么？
• 调优编排：如何管理 RAG 系统的实验配置跟踪？
• 从 RAG 到 Agent 评估：我们将 RAG 定义为一个索引、检索和生成的三步过程。本节描述 RAG 系统何时转变为 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），成本约为每 1,000 个 Token 0.005 美元，则评估 100 个查询需要 3 美元。

随着像 Ragas 这样的框架推广零样本 LLM 评估，人们开始质疑少样本 LLM 评估是否必要。由于零样本 LLM 评估的效果“足够好”，它可能已经足以作为 RAG 系统调优的北极星。如下图所示，RAGAS 评分由 4 个零样本 LLM 提示组成，分别评估生成的两个指标：真实性（Faithfulness） 和 答案相关性（Answer Relevancy），以及检索的两个指标：上下文精度（Context Precision） 和 上下文召回率（Context Recall）。

 来源

从零样本到少样本 LLM 评估的转变非常直接。我们在指令模板中加入了一些标注的搜索结果与查询相关性的例子，也就是所谓的上下文学习。这一技术的发现是 GPT-3 的关键突破之一。

例如，添加 5 个人工相关性评分的例子将使提示增加 30,000 个 Token。假设与上述相同的成本，我们评估 100 个查询的费用从 3 美元增加到 15 美元。需要注意的是，这是一个简单的估算例子，并不基于 LLM 的真实定价模型。一个关键的考量是，添加少样本示例可能需要更长的上下文模型，这些模型的定价通常高于较小输入的 LLM。

这种基于零样本或少样本推断的 LLM 评估已经非常具有吸引力，但进一步研究表明，通过知识蒸馏训练算法可以进一步降低 LLM 评估的成本。这是指使用 LLM 生成评估任务的训练数据，并将其微调为一个更小的模型。

在 ARES：一个自动化的检索增强生成系统评估框架中，Saad-Falcon 等人发现，训练自己的 LLM 评估器可以比零样本提示表现更好。初始阶段，ARES 需要三种输入：目标语料库中的段落集合，150 个或更多的人工偏好验证数据点，以及 5 个领域内查询的少样本示例。ARES 使用这些少样本示例生成大量的合成查询数据，并通过回环一致性原则进行过滤：即当使用合成查询进行搜索时，能否检索出生成合成查询的文档。然后，ARES 为 上下文相关性、答案真实性 和 答案相关性 微调轻量级分类器。

作者实验微调 DeBERTa-v3-large，该模型包含更经济的 4.37 亿参数，每个分类器头共享基础语言模型，合计添加了 3 个分类头。通过将合成数据分为训练集和测试集，ARES 系统的评估发现微调模型显著优于零样本和少样本的 GPT-3.5-turbo-16k。更多细节（例如预测驱动推理（PPI）中置信区间的创新使用及实验细节）请参考 Saad-Falcon 等人的论文。

为了更好地理解 LLM 在评估中的潜在影响，我们将继续介绍现有的 RAG 系统基准方法及其在 LLM 评估中的特别变化。

RAG 指标

我们从生成、检索到索引的顶层视角介绍 RAG 指标。随后从构建索引、调优检索方式到生成选项的底层视角介绍 RAG 的调节参数。

从顶层视角介绍 RAG 指标的另一个原因是，索引中的错误会传递到搜索和生成，但生成中的错误（如我们定义的层级）不会影响索引中的错误。在当前的 RAG 评估状态下，很少有对 RAG 堆栈进行端到端评估，通常假设 oracle 上下文 或 受控干扰项（例如 Lost in the Middle 实验）来确定生成的真实性和答案相关性。同样，嵌入通常用不考虑近似最近邻误差的暴力索引进行评估。近似最近邻误差通常通过寻找权衡查询每秒和召回率的准确性最优点来测量，ANN 召回率为查询的真实最近邻，而不是被标记为与查询“相关”的文档。

生成指标

RAG 应用的总体目标是生成有帮助的输出，并使用检索到的上下文作为支持。评估必须考虑到输出使用了上下文而没有直接从来源中获取，避免冗余信息，并防止答案不完整。为了给输出评分，需要制定涵盖每个标准的指标。

Ragas 引入了两个分数来衡量大语言模型（LLM）输出的性能：可信度和答案相关性。可信度 评估答案在检索上下文基础上的事实准确性。答案相关性 确定答案在给定问题下的相关性。答案可以具有很高的可信度分数，但答案相关性分数很低。例如，一个可信的回答可能直接复制上下文，但这会导致答案相关性较低。当答案缺乏完整性或包含重复信息时，答案相关性分数会受到惩罚。

2020 年，Google 发布了 Meena，一个对话代理。Meena 的目标是展示它能够进行 合理且具体 的对话。为了衡量开放领域聊天机器人的性能，他们引入了 Sensibleness and Specificity Average (SSA) 评估指标。该机器人响应的合理性需要在上下文中有意义，并且具有具体性（具体性平均值）。这确保了输出内容全面且不含糊。2020 年，这需要人类与聊天机器人对话并手动评分。

虽然避免模糊回答是好的，但同样重要的是防止大语言模型出现 幻觉 。幻觉指的是大语言模型生成的答案未基于实际事实或提供的上下文。LlamaIndex 使用 FaithfulnessEvaluator 指标来衡量这一点。分数基于回答是否与检索到的上下文一致。

评估生成的回答是否优质取决于一些指标。答案可能具有事实性，但与给定查询无关。此外，答案可能模糊且缺乏支持回应的关键上下文信息。接下来，我们将回溯到管道的上一层，讨论检索指标。

检索指标

评估堆栈的下一层是信息检索。评估检索历史上需要人类标注哪些文档与查询相关。因此，为创建 1 个查询标注，我们可能需要标注 100 个文档的相关性。这对于一般搜索查询来说已经是一个极其困难的任务，而在构建特定领域（例如法律合同、医疗患者历史记录等）的搜索引擎时，这种挑战进一步加剧。

为了减轻标注成本，通常使用启发式方法来判断搜索相关性。其中最常见的是点击日志，即：给定查询，被点击的标题可能是相关的，而未点击的标题则不相关。这在机器学习中也称为弱监督。

一旦数据集准备好，评估中常用的三个指标是： nDCG 、Recall 和 Precision 。NDCG（归一化折扣累积增益）通过多个相关性标签测量排名。例如，关于维生素 B12 的文档可能不是关于维生素 D 查询的最相关结果，但比关于波士顿凯尔特人队的文档更相关。由于相对排名的额外复杂性，通常使用二元相关性标签（相关为 1，不相关为 0）。Recall 衡量搜索结果中捕获了多少正样本，Precision 则衡量搜索结果中标记为相关的比例。

因此，大语言模型可以通过以下提示计算 Precision：“以下搜索结果中有多少与查询 {query} 相关？{search_results}”。还可以通过大语言模型提示获得 Recall 的代理指标：“这些搜索结果是否包含回答查询 {query} 所需的所有信息？{search_results}”。我们同样鼓励读者查看 Ragas 中的一些提示 此处。

另一个值得探索的指标是 LLM Wins，其中大语言模型的提示为：“基于查询 {query}，哪个搜索结果集更相关？集合 A {Set_A} 或集合 B {Set_B}。非常重要！请将输出限制为‘Set A’或‘Set B’”。

现在让我们更深入一层，了解如何比较向量索引。

索引指标

熟悉 Weaviate 的资深用户可能了解 ANN Benchmarks，该基准测试启发了 Weaviate 1.19 版本中的 gRPC API 的开发。ANN 基准测试衡量每秒查询次数 (Queries Per Second, QPS) 与召回率 (Recall) 的关系，并包括对单线程限制等细节的考量。数据库通常基于延迟和存储成本进行评估，而随机向量索引则更加注重精度的测量。这与 SQL select 语句中的近似计算 有些相似，但我们预测，随着向量索引的日益流行，由近似引起的误差将受到更多关注。

精度通过召回率 (Recall) 进行衡量。在向量索引中，召回率指的是近似索引算法返回的地面真值最近邻数量与暴力搜索确定的最近邻数量的比例。这与信息检索 (Information Retrieval) 中“召回率”的典型用法不同，后者指的是检索出的相关文档占所有相关文档的比例。两者通常都与一个关联的 @K 参数一起测量。

在完整 RAG 堆栈的背景下，有一个有趣的问题：ANN 精度误差何时会导致信息检索 (IR) 中的误差？ 例如，我们可能能够以 80% 的召回率实现 1,000 QPS，或者以 95% 的召回率实现 500 QPS，这对上述搜索指标（如搜索 nDCG 或大语言模型 (LLM) 召回分数）的影响是什么？

关于 RAG 指标的总结

总之，我们展示了评估索引、检索和生成的指标：

• 生成：忠实性和答案相关性，以及从大规模检测幻觉等指标（如合理性与特异性平均值，Sensibleness and Specificity Average, SSA）的演变。
• 检索：LLM 评分的上下文精度与上下文召回率的新机遇，以及人类标注用于测量召回率、精度和 nDCG 的概述。
• 索引：通过向量搜索算法返回的地面真值最近邻数量来测量召回率。我们认为这里的关键问题是：ANN 错误何时会渗透到 IR 错误中？

所有组件通常都可以在性能与延迟或成本之间进行权衡。通过使用更昂贵的语言模型，我们可以获得更高质量的生成；通过使用重新排序器过滤结果，我们可以获得更高质量的检索；通过使用更多内存，我们可以获得更高召回率的索引。如何管理这些权衡以提升性能，可能会随着我们对“RAG 的调节旋钮”的持续研究而变得更加清晰。最后需要提醒的是，我们选择从生成到搜索和索引的自上而下的视角来展示指标，因为评估时间更接近用户体验。我们还将从索引到检索和生成的自下而上的视角展示调节旋钮，因为这更类似于 RAG 应用开发者的体验。

RAG 调节参数

现在我们已经讨论了比较 RAG 系统的指标，接下来深入探讨可以显著影响性能的关键决策。

索引调节参数

在设计 RAG 系统时，最重要的索引调节参数是向量压缩设置。Weaviate 1.18 于 2023 年 3 月推出了产品量化（Product Quantization, PQ）。PQ 是一种向量压缩算法，它将向量的连续片段分组，聚类其集合中的值，然后通过质心减少精度。例如，一个包含 4 个 32 位浮点数的连续片段需要 16 字节表示，而一个长度为 4 且具有 8 个质心的片段仅需 1 字节，实现了 16:1 的内存压缩比率。PQ 重排序的最新进展显著减小了压缩导致的召回损失，但在非常高压缩水平时仍需谨慎考虑。

接下来是使用的路由索引。对于少于 10K 向量的数据集，RAG 应用可能可以满足于暴力索引。然而，随着向量数量增加，暴力索引的延迟远高于基于近邻图（Proximity Graph）算法的索引，例如 HNSW。如在 RAG 指标中所述，HNSW 性能通常通过 Pareto 最优点来测量，其权衡查询每秒与召回率。这是通过调整推理时使用的搜索队列大小 ef 来实现的。较大的 ef 会在搜索过程中进行更多距离比较，从而显著放慢速度，但会产生更准确的结果。接下来的参数包括构建索引时使用的参数，例如 efConstruction （插入数据到图时的队列大小）和 maxConnections （每个节点的边数，需与每个向量一同存储）。

我们正在探索的另一个新方向是分布偏移对 PQ 质心的影响，以及与混合聚类和图索引算法（如 DiskANN 或 IVFOADC+G+P）的交互作用。使用召回率指标可能足以判断是否需要重新拟合质心，但问题是：使用哪些向量子集进行重新拟合。如果我们使用导致召回下降的最近 100K 向量，可能会过拟合到新的分布，因此我们可能需要对数据分布时间线进行混合采样。这一主题与我们关于深度学习模型持续优化的观点密切相关，可在“调控优化”部分进一步讨论。

在将数据插入 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 栈中微调自定义模型的最简单切入点之一，我们将在“调控优化”中进一步讨论。

另一个有趣的调节参数是多索引搜索。类似于我们对分块的讨论，这涉及对数据库的结构性更改。总体问题是：什么时候应该使用单独的集合而不是过滤器？ 应该将 blogs 和 documentation 分为两个集合，还是将它们联合存储在具有 source 属性的 Document 类中？

使用过滤器为我们提供了快速测试这些标签效用的方法，因为我们可以为每个块添加多个标签，然后消融分析分类器如何利用这些标签。有许多有趣的想法，例如在输入给 LLM 的上下文中明确标注上下文的来源，例如“以下是来自博客的搜索结果 {search_results}。以下是来自文档的搜索结果 {documentation}”。随着 LLM 能够处理更长的输入，我们预计多数据源之间的上下文融合将变得更加普遍，因此另一个相关超参数出现了：从每个索引或过滤器中检索多少文档。

生成

关于生成，首先需要关注的是选择哪种大语言模型（LLM）。例如，您可以选择来自 OpenAI、Cohere、Facebook 以及许多开源选项的模型。许多 LLM 框架（例如 LangChain、LlamaIndex 和 Weaviate 的生成模块）提供了与各种模型的简单集成，这也是一个很大的优势。模型的选择可能取决于您是否希望数据保持私密性、成本、资源等因素。

一个常见的、特定于 LLM 的调节参数是温度（temperature）。温度设置控制输出的随机性。温度为 0 意味着响应更可预测且变化较小；温度为 1 则允许模型在响应中引入随机性和创造性。因此，如果您多次运行生成模型，并将温度设置为 1，则每次重新运行后响应可能会有所不同。

长上下文模型（Long Context Models）是为您的应用程序选择 LLM 时的一种新兴方向。增加更多的搜索结果作为输入是否能提高回答质量？关于“中间丢失”实验（Lost in the Middle）的研究对此提出了一些警示。在 “Lost in the Middle” 中，斯坦福大学、加州大学伯克利分校和 Samaya AI 的研究人员进行了对照实验，显示如果相关信息被放置在搜索结果的中间，而不是开头或结尾，语言模型在生成响应时可能无法整合这些信息。另有一篇由 Google DeepMind、丰田和普渡大学的研究人员撰写的论文指出：“大语言模型很容易被无关上下文分心”。尽管这一方向充满潜力，但截至本文撰写时，长上下文 RAG 仍处于早期阶段。幸运的是，诸如 Ragas 分数等指标可以帮助我们快速测试新系统！

与我们之前讨论的 LLM 评估的最新突破类似，生成方面的调优分为三个阶段：1. 提示调优（Prompt Tuning），2. 少样本示例（Few-Shot Examples），3. 微调（Fine-Tuning）。提示调优涉及调整特定的语言表达，例如：“请根据提供的搜索结果回答问题。”与“请回答问题。重要，请严格按照以下指示操作。您对问题的回答必须基于提供的搜索结果，仅限于此！！”之间的差异。

如前所述，少样本示例是指收集一些手动编写的问题、上下文和答案对，以引导语言模型的生成。最近的研究（如 “上下文向量”）进一步表明了这样引导潜在空间的重要性。在 Weaviate Gorilla 项目中，我们使用 GPT-3.5-turbo 生成 Weaviate 查询，当我们添加了自然语言到查询翻译的少样本示例后，性能显著提升。

最后，针对 RAG 应用的 LLM 微调正受到越来越多的关注。这里有几种方式值得考虑。再次回到我们关于 LLM 评估的讨论，我们可能希望使用更强大的 LLM 生成训练数据，以打造一个由自己拥有的小型、更经济的模型。另一个想法是提供对响应质量的人为标注，从而用指令跟随来微调 LLM。如果您对模型微调感兴趣，请查看 Brev 提供的关于如何使用 HuggingFace PEFT 库的 教程。

关于 RAG 调优选项的总结

总之，我们介绍了 RAG 系统中主要的调优选项：

• 索引：在最高层面上，我们需要考虑何时仅使用暴力搜索，何时引入 ANN 索引。当调整具有新用户与强力用户的多租户用例时，这尤其有趣。在 ANN 索引中，我们有 PQ 的超参数（片段、质心和训练限制）。HNSW 包括（ef、efConstruction 和 maxConnections）。
• 检索：选择嵌入模型、调整混合搜索权重、选择重排序器、以及将集合划分为多个索引。
• 生成：选择一个 LLM，并决定何时从提示调优过渡到少样本示例或微调。

了解了 RAG 指标以及如何通过调优提升它们的表现后，让我们讨论实验追踪可能的实现方式。

调优编排

鉴于近期在大语言模型（LLM）评估领域的进展以及对一些可调参数的概述，将所有这些与实验跟踪框架结合起来是一个令人兴奋的机会。例如，一个简单的编排器，其直观的 API 可以供用户执行以下操作：1. 请求对 5 个 LLM、2 个嵌入模型和 5 种索引配置进行全面测试；2. 运行实验；3. 向用户返回高质量报告。Weights & Biases 已为训练深度学习模型开辟了卓越的实验跟踪路径。我们预计，对于带有本文中概述的可调参数和指标的 RAG 实验支持，兴趣将迅速增长。

我们正在关注这一领域的两个发展方向。一方面，现有的零样本 LLM（如 GPT-4、Command、Claude，以及开源选项 Llama-2 和 Mistral）在具有 oracle context 时表现相当不错。因此，有一个巨大的机会可以 专注于搜索的部分 。这需要在多种配置中找到权衡 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）实验通过权重归因的因果中介分析，更新诸如“LeBron James plays basketball”为“LeBron James plays soccer”之类的事实。这是一种相当先进的技术，另一种机会可能是简单地标记训练中使用的分块（如“LeBron James plays basketball”）并使用包含新信息的检索增强训练数据进行重新训练。这是我们密切关注的一个重要领域。

如前所述，我们还在考虑如何将此类持续调优直接集成到 Weaviate 中使用 PQ 质心。首次进入 Weaviate 的前 K 个向量的 PQ 质心可能会受到数据分布显著变化的影响。机器学习模型的持续训练存在一个臭名昭著的“灾难性遗忘”问题，即对最新一批数据的训练会损害对早期数据批次的性能。这也是我们在设计 PQ 质心重新拟合时考虑的内容之一。

从 RAG 到 Agent 评估

在整篇文章中，我们关注的是 RAG ，而不是 Agent 评估。在我们看来，RAG 定义为索引、检索和生成的流程，而 Agents 的范围更加开放。下图说明了我们如何看待主要组件，如规划、记忆和工具，这些组件共同为您的系统提供了显著的能力，但也使其评估变得更加困难。

RAG 应用程序的常见下一步是添加高级查询引擎。对于刚接触该概念的读者，请查看我们 LlamaIndex 和 Weaviate 系列的 ，其中提供了如何入门的 Python 代码示例。有许多不同的高级查询引擎，例如子问题查询引擎、SQL 路由器、自我修正查询引擎等。我们也在考虑 promptToQuery API 或搜索查询提取器在 Weaviate 模块中的可能形式。每种查询引擎在信息检索过程中都有其自身的优势，让我们深入探讨其中的几个以及我们如何进行评估。

多跳查询引擎（也称为子问题查询引擎）非常适合将复杂问题分解为子问题。在上图中，我们有查询“What is Ref2Vec in Weaviate?” 要回答这个问题，您需要分别了解 Ref2Vec 和 Weaviate 是什么。因此，您的数据库需要针对这两个问题进行两次调用以检索相关上下文。然后，将两个答案结合生成一个输出。多跳查询引擎的性能评估可以通过观察子问题来完成。重要的是，LLM 是否创建了相关的子问题、准确回答了每个问题，并结合两个答案提供了事实准确且相关的输出。此外，如果您提出复杂问题，最好使用多跳查询引擎。

多跳问题首先取决于子问题的准确性。我们可以想象在这里使用类似的 LLM 评估，提示如下：“Given the question: {query}. A system decided to break it into the sub questions {sub_question_1} and {sub_question_2}. Does this decomposition of the question make sense?” 然后我们对每个子问题分别进行两次 RAG 评估，并评估 LLM 是否能够结合每个问题的答案来回答原始问题。

作为从 RAG 到 Agents 的复杂性演变的另一个示例，让我们考虑路由查询引擎。下图说明了一个代理如何将查询路由到 SQL 或向量数据库查询。这种情况与我们对多索引路由的讨论非常相似，我们可以使用类似的方法评估生成结果，提示说明 SQL 和向量数据库的需求，然后询问 LLM 路由器是否做出了正确的决策。我们还可以使用 SQL 查询结果的 RAGAS 上下文相关性得分。

总结“从 RAG 到 Agent 评估”的讨论，我们认为，目前还无法判断 Agent 使用的常见模式是什么。我们有意展示了多跳查询引擎和查询路由器，因为这些相对容易理解。一旦我们添加更多开放式的规划循环、工具使用以及如何评估模型格式化工具 API 请求的能力的相关评估，以及诸如 MemGPT 中的元内部记忆管理提示，就很难围绕如何评估 Agents 提供通用抽象。

结论

非常感谢您阅读我们关于 RAG 评估的概述！快速回顾一下，我们首先介绍了使用 LLM 进行评估的新趋势，这为迭代 RAG 系统提供了巨大的成本和时间节省。接下来，我们介绍了评估 RAG 堆栈（从生成到搜索再到索引）所使用的传统指标的更多背景知识。对于希望提高这些指标性能的构建者，我们随后展示了一些用于索引、搜索和生成的可调参数。我们提出了这些系统的实验跟踪所面临的挑战，并阐述了我们对 RAG 评估与 Agent 评估的区别的看法。希望您觉得本文有用！