如何判断RAG（检索增强生成）和代理系统实际上是否有效

随着人工智能领域的不断发展，无论是模型的开发还是围绕这些模型构建应用程序的范式的进步，一些常见的设计趋势已经出现。两个常见的趋势是：

• 检索增强生成（RAG）： 一种工作流程，涉及查找与用户的查询相关的信息，并利用这些信息结合查询本身来构建一个增强的提示。该提示会被传递给大模型，以生成对用户的响应。
• 代理（Agent）: 一种围绕语言模型的应用程序抽象，允许大型语言模型执行工具并根据该工具的执行结果做出决策。

这两种方法都依赖于LLM的一个基本特征，即它们是“上下文学习者”，这意味着如果你在提示中给出LLM一些信息，那么LLM可以利用这些信息来回答问题。

从我的《Retrieval Augmented Generation》文章中的一个上下文学习的例子

上下文信息最常见的表现形式是文档。包括PDF、PowerPoint演示文稿和文本记录等。这些文档包含丰富的信息，可以为用户的问题提供背景解释甚至直接答案。RAG（Retrieval-Augmented Generation检索增强生成）系统和智能代理系统可以利用这些信息更有效地回答问题。

理论上。

实际上，全面测试与文档信息交互的AI系统可能非常困难。当AI从业者将他们的产品从实验室推向现实世界时，这可能会导致（潜在灾难性的）意外情况。

在这篇文章中，我们将讨论RAG和代理系统用于为LLM应用程序添加上下文的主要步骤，这些步骤如何可能出现问题，以及我们如何测试上下文AI系统以确保它们在生产环境中不会出现故障。

与传统的软件系统不同，测试基于文档语境化的系统非常困难。因此，大多数开发人员干脆不进行这类测试，这简直是疯狂的。——摘自文章后面的段落

测试很难，但越早将其作为开发工作流程的核心部分，就越好。您将能够更好地进行测试，并且您的产品也会更快地变得更好。

这对谁有帮助？对于有兴趣建立稳健的AI驱动系统的数据科学家和从业人员。

文档上下文AI的失败点

对于我们而言，“文档上下文化人工智能”系统利用来自文档（如PDF、幻灯片和网站）中的信息，为语言模型提供背景信息，使该语言模型更好地完成任务。想象一下，你收集了一组关于某个餐厅的文件；包括菜单、季节性活动、食物介绍以及过敏信息等。文档上下文化的理念便是将这些信息传递给语言模型，使其能够基于真实的信息与客户讨论你的餐厅。

文档上下文化的核心思想；将文档中的信息注入语言模型，从而使语言模型能够更好地回答用户的问题。

The essential idea of document contextualization; to inject the information from documents into a language model, so the language model can answer a users question better.

有许多工具、技术和方法可以用来构建文档上下文化的AI系统。因此，一个基于企业文档回答问题的理想系统可能与为代码库生成代码而设计的理想系统截然不同。尽管如此，大多数文档上下文化AI系统仍会使用一些基本操作：

大多数基于文档的上下文AI系统的主要步骤。解析、分块、以可查询的形式存储、提示、以及大模型完成。在本文中，我们将深入讨论这些步骤。

我们可以在两种最流行的文档情境化方法中找到这种通用的工作流程，“RAG”和“agents”。

在RAG（检索增强生成）的背景下，每当收到一个查询时，我们会根据用户的查询从数据存储中检索相关数据，并使用这些数据构建一个增强提示。然后我们利用这个增强提示通过大语言模型生成答案。

在代理（Agentic）背景下，我们将从数据存储中查询视为代理可以执行的工具。如果代理确实选择执行该工具，我们会使用结果构造增强型提示词，然后将此提示词输入语言模型进行生成。这会影响代理后续的行为。通常，“检索和生成”（RAG）可以映射到一个代理可使用的工具；因此，测试代理系统与测试 RAG 系统在本质上是相似的，唯一的区别在于被测试系统的复杂程度不同。

这两种方法都有很大的潜力，但也存在很多需要在开发产品并将其推向市场之前解决的技术风险。就像任何传统的软件系统一样，文档化的上下文人工智能系统也可能容易出现错误和bug，从而导致较差的用户体验。

与传统的软件系统不同，测试文档上下文化系统的难度可能非常大。因此，大多数开发者根本不会去做这件事，这简直是疯狂的。

要真正理解我们面临的问题的严重性，让我们依次审视每一个基本操作，解释它们为什么是必要的，以及它们是如何失败的。我们将从解析开始探讨，然后研究块处理、搜索和完成功能。

解析

文档上下文AI的第一种故障模式，解析。

The%20first%20failure%20mode%20of%20document%20contextualized%20AI%2C%20parsing.

解析是构建大多数基于文档上下文的AI系统的基本第一步，这一点至关重要，因为文档通常包含丰富的空间和视觉信息，而当前的AI模型在处理这些信息方面根本上无能为力。

![一个复杂视觉文档的示例。在此示例中，我们将要求LLM计算IPE 360的“m”表面积。来源^[1]

如果你在ChatGPT中添加一个PDF文件，你会发现有一个进度条。这个进度条（可能）代表了一个解析过程，将论文内容转化为语言模型可以理解的表示形式。

将文档添加到ChatGPT。上传过程中注意进度条，这可能包括一个解析步骤，该步骤将PDF转换为文本信息。

当你询问语言模型论文中的内容时，你得到的回答不是基于论文本身，而是基于解析器的输出。根据解析器选择提取的信息及其提取方式的不同，某些查询可能可以被大语言模型回答，也可能无法回答。

向ChatGPT询问图中的信息。这里写的是m表面积为23平方米/吨。

在这里插入图片描述

有许多解析器可供选择，它们优先处理不同类型文档，并在不同的使用场景下表现出色。

分块技术

文档上下文人工智能的第二种失败模式，切片处理。

The second failure mode of document contextualized AI, chunking.

现代AI模型可以接受的给定提示的信息量是长但有限的。许多文档，或一个大型文档，可能无法完全适应LLM的上下文窗口，无论它们被解析得多完美。

文档可以包含大量信息。如果你试图根据一组文档回答问题，总的信息量可能会迅速令大语言模型感到不堪重负。

因此，当与一个文档上下文化的AI系统合作时，通常会将文档分成称为“块”的部分。在向模型提供上下文时，我们将使用这些块而不是从文档中解析出的全部内容。

解析文档后，该文档会被分成若干块。这些块最终会被输入到模型中。

实际上有很多方法可以实现这一点。例如，LlamaIndex提供了17种不同的分块策略供您选择（来源^[2]）。一些方法根据单词数量简单地对文档进行划分，而其他方法则利用AI模型来聚合文档中语义相近的部分。选择合适的分块策略很重要，因为如果分块不当，您提供给大语言模型（LLM）的上下文可能根本没有任何意义。

分块的性质重要的文本示例。如果以不同的块提供这些信息，可能会导致模型得出不准确的结论。

搜索

块最终需要存储在某种可查询的表示形式中，以便我们可以搜索与用户查询相关的块。

在我与各种使用RAG（检索增强生成）和代理系统在实际产品中的企业客户交流时，我发现了三个主要问题，这些问题占了这一阶段管道中大部分的问题。

1. 无法精炼
2. 规模化的脆弱性
3. 相对于搜索引擎技术而言不公平的难题查询

大多数检索增强生成（RAG）系统以及使用它们作为工具的代理，依赖于一个嵌入模型，该模型将每个片段编码为某个高维向量空间中的向量。当用户提问时，使用相同的模型将问题编码到相同的空间中。编码器存在的原因是将类似的内容放在相似的位置上，因此对于用户查询的相关片段进行搜索就变成了在这一高维空间中查找附近向量的操作。

在多个文档情境化人工智能上下文中搜索的概念图。块通过编码器传递，被表示为向量。用户查询通过相同的编码器传递，以向量形式进行总结。想法是向量越相似，该块对特定查询的相关性越高。

这种做法之所以常见，是因为它可能非常有效，并且只需要几行代码就可以设置。然而，这种方法有一个主要的实际问题：你正在使用AI模型来告诉你哪些片段与用户的查询相关。嵌入式模型并不是魔法，它们是根据训练方式来组织数据的。如果你的应用场景完全符合该模型的归纳偏差，那当然很好，但这种黑箱性质使得围绕搜索进行增量改进变得困难。

许多搜索策略的另一个常见问题是规模脆弱性。自然地，当使用自然文本查询查找信息时，如果你想要在一个不断增加的文档集合中搜索特定的文件，在搜索的过程中出错的可能性也会越来越大。无论你选择哪种搜索方式都是如此。不过，当我们测试EyeLevel的RAG系统时发现，基于嵌入的搜索策略在无关文档数量增加时性能会迅速下降^[3]。虽然这只是我的猜测，但我想这是因为基于嵌入的搜索具有松弛性，在文档数量上升时会导致高维嵌入空间受到污染。

通过文档传递编码器所创建的高维向量空间可能非常复杂。随着文档被添加到这个空间中，我们发现噪声可能导致性能迅速下降。

另一个问题是不公平的问题。假设你给一个RAG系统发送了一个查询：“我的投资组合中最新房子的价格是多少？”，再假设你的文档数据集看起来像这样：

在一个单一的问题中，RAG系统需要：

• 查找你的投资组合
• 找到最新上市的房子
• 查一下那栋房子
• 然后找到价格

如果你正在构建一个仅根据用户查询搜索文档的简单RAG系统，它没有办法仅仅通过查询本身来确定要查找的是哪栋房子。代理通常在这种类型的问题上表现更好，特别是如果它们被设计为专门解决此类问题的话，但是多跳问题仍然是一项具有挑战性的任务。

对于许多检索增强生成（RAG）和代理系统而言，聚合是另一个难题。大多数人工智能中的上下文搜索系统的根本思想是在文档中找到与用户查询相关的片段。这对于寻找针在干草堆中的问题或一般的摘要来说非常棒，但如果需要详尽地列出贯穿整个文档的实体，则这种策略可能效果不佳。

通常，检索增强生成（RAG）和代理系统采用混合搜索策略，其中基于语义的搜索与某种其他形式的搜索相结合。这有助于提升那些不完全符合经典文档上下文化管道的问题类型的表现。

对于复杂应用来说，通常会创建多种形式的搜索并行执行以回答给定提示。例如，可以与语义基础搜索并行定义实体关系图。这些并行方法通常是为特定目的和应用程序定制的。

所以，简而言之，搜索是很困难的。“只需使用文本嵌入版本3”可能足以帮助你达到目标，也可能达不到。

让我们再来看看一种更一般的失败模式，然后我们将讨论实际是如何进行测试的。

提示和问答

最后一个失效模式最受关注，但实际上往往是最不重要的。

大多数现代语言模型（LLM），甚至是低成本的低参数模型，如果上下文定义清晰且充分，都能够回答用户的问题。这实际上是原始RAG论文的主要观点：不是向LLM引入新的信息，而是通过将相关训练数据注入提示本身来提高LLM的表现。

换句话说，一个恰当创建的向量数据库系统会让大型语言模型表现得更好，而不是更差。通常没有必要去调整提示策略或实验LLM生成模型。如果你有一个构造良好的包含良好上下文信息的提示，大多数大型语言模型都能出色地完成任务。

问题在于，大多数人将大部分时间花在调整这一步上。我想这是因为提示工程立即可以使用，并且许多人对大型语言模型（LLM）的理解比嵌入更深入，因此他们觉得自己更有能力尝试不同的完成模型以及这些模型的提示方式。不论原因是什么，将大部分时间花费在调整这样一个以文档为基础的人工智能系统阶段通常是浪费时间，而这往往是许多与这类系统打交道的企业关注的重点。

如果提供给模型的背景信息从根本上是有缺陷的，无论采用什么样的链式思维、代理性、结构化输出或其它复杂的解析策略都无法修复它。

“在RAG系统中优化提示的徒劳”. 作者使用MidJourney生成

不过，这还是很值得关注的，因为这是一种故障模式。我们稍后会讨论如何测试这种故障模式以及其他所有故障模式，但目前让我们谈谈可用于测试的数据集有哪些，以及一般而言应该如何进行测试。

数据集概览

从学术角度看，测试人工智能是有明确定义的。学者们通常就一类处于行业前沿的问题达成一致，围绕这些问题构建数据集，然后根据人工智能系统在这些建立的数据集上的表现来比较不同的方法。

问题在于，这些数据集是用于测试通用问题的，而不是特定产品的问题。例如，如果你想构建一个基于兽医和宠物主人对话数据集来回答兽医问题的人工智能代理，你很难找到完全合适的数据集。

然而，数据集仍然因其存在而为实践者提供巨大的价值。构建这样的基准可能困难、昂贵且耗时，因此如果不专门利用它们来更好地理解AI系统的性能（即便不是具体地），至少从总体上来说，这是个错误。

这些数据集在处理文档上下文化人工智能这一总体概念时有着广泛的多样性。其中一些采取了非常具体的方法，侧重于更大规模的文档上下文工作流程中的个别组件。而另一些则采用更高层次的方法，仅基于一个问题和一组文件来验证系统生成的答案。

回忆一下用于文档上下文化的AI的总体方法。一些测试策略侧重于单独的组件，而其他策略则通过基于一组文档验证答案来测试整个流程。

让我们来看看一些与我们讨论过的文档上下文管道相关的学术界流行基准。通过这样做，我们将探讨如何使用学术界的基准测试来测试AI产品，并且我们还将了解一般的基准测试，以便我们可以学习如何开发自己的基准测试。

测试文档接口AI产品

通过讨论几个数据集，应该可以明显看出有很多方法来定义“能够理解文档的AI模型”。如果你正在构建一个旨在理解特定文档以完成特定任务的AI产品，你可能会发现有许多不适合你的用例的数据集，有一些勉强符合你的用例的数据集，以及少数非常完美契合你的用例的数据集。

使用学术数据集来测试AI产品是一种艺术，需要创造性地思考如何操作数据集以测试您的产品。这也要求您开明地思考如何重新构思您的产品以便与现有的数据集相符。

我一直都在管理一个欺诈检测产品，其基本思路是分析与保险索赔相关的文档，并汇总证据以判断该索赔是否为欺诈性索赔。这可以让理赔调整员更好地优先处理那些有可能存在欺诈风险的索赔案件。

在那个努力中，我们有如下这样的问题：

“在寻求医疗救助之前，那个人X是否有律师？”

“在治疗过程中，Person X的伤势是否有显著变化？”

很难找到完全适用于这个特定应用的数据集，但有一些数据集在很多方面是相似的。一般来说，该产品可以被视为：

一个信息抽取问题

一个多页面和多模态的视觉问答问题

一个多跳问题回答问题模型

等等。因此，我可以使用这些数据集来测试我欺诈检测产品的核心技术，以了解该产品的大致优缺点。这可能不会立即与欺诈检测相关，但确实有助于解决更大问题中的子问题，并且肯定比不做任何测试要好。

回想一下测试文档上下文AI系统的数据集的核心理念。如果数据集旨在检验AI系统是否擅长理解复杂的视觉信息，那么结果可以告诉我我的AI系统可能擅长或不擅长的地方。这在产品开发周期中引导优先级和努力方向方面非常有帮助。

实际进行测试的方式取决于你正在测试的产品和数据集，但通常来说，你需要将文档加载到文档存储中，通过你的产品发出所有问题，并获得一份AI生成的答案列表。这个过程实际上可以非常困难且耗时。这些数据集可能很大且复杂，因此正确地将其整合进你的产品中会颇具挑战性，特别是在数据集不能完美匹配产品的功能时更是如此。此外，一旦你拿到一整套AI生成的回答后，根据这些答案来评估性能的实际表现也可以难于预期。

在EyeLevel，我们发现将LLM用作评判者是一个很好的起点，但我们不建议过度依赖。对于不了解的人来说，将LLM用作评判者的理念是将两个答案都传递给LLM，并让LLM判断AI生成的答案是否与人工策划的答案一致。

关于LLM作为裁判的基本理念。问题、AI生成的答案以及期望答案都被结合在一个单一的提示中，然后让一个大语言模型判断AI生成的答案是否好。当然，可以通过一些提示工作来鼓励更好的LLM评判。

尽管大型语言模型有一些奇怪的特性，并且往往会因为无关的细节缺失或微小差异而错误地将答案标记为不正确的。我们发现，由LLM作为评判标准与盲人人类测试相比，误差大约在10-20%左右。

另一种自动化的方法是使用两两比较。如果你有两个想要比较的AI系统，你可以让一个语言模型裁判选择它更喜欢哪一个答案，而不是说哪个“好”或“坏”。这有时会导致结果分析更为稳定，但也会放大裁判在风格偏好上的重要性，这种偏好可能与人类无关紧要。

一个大型语言模型可以用来直接比较两个答案。有许多专门设计的AI模型具有与人类相似的偏好，可以在这种情况下使用。(图片链接)

另一种技术是集成方法。你可以让多个不同的语言模型来评判一个答案，并将该问题的得分定义为所有评委评分的总和。

多个供应商的多种AI模型可以被使用，以最小化特定模型偏好带来的影响，从而导致更稳健的判断。

这可以通过利用LLM的温度输出进一步扩展，使其生成一系列答案，然后进行聚合。这样可以导致更一致的评估。

LLM的输出温度可以增加以鼓励更多随机性的输出。这可以用于创建多个输出，这些输出可以结合起来形成总体判断。

有许多方法可以改进LLM作为评判的角色，以帮助自动化人类评价，但如果你认真想提升你的AI系统的性能，我们建议保留人在环路之中。LLM有奇怪的偏好，过度投入时间和精力专注于根本源于LLM怪癖的变化可能是危险的。

当然，所有这些都假设您有一个可以测试的数据集。让我们谈谈如何定义我们自己的数据集。如果我们无法为我们的用例找到一个合适的数据集，或者我们想要创建一个非常特定的数据集，拥有自己的数据集可能会很有用。

构建自己的数据集

数据集的确切性质应该反映你所解决的问题。如果你试图建立一个可以在文档页面上画圈的人工智能系统，你可能需要一个相当复杂的测试数据集来评估其性能。本文主要关注的是测试基于用户查询上下文回答问题的文档相关人工智能系统的性能。

你可能认为获取文档是构建自己的数据集最困难的部分，但实际上收集文档其实相对容易。网络上有大量的商业、法律、政府、金融和教育资源可以免费访问。如果你与客户在某个特定问题上合作，许多客户有大量的相关文档可用于测试。

真的，创建数据集最困难的部分是生成问答对。如果你正在处理包含复杂信息的难懂文档，理解这些资料并据此生成问答对可能会非常耗时。在EyeLevel公司，我们发现人工生成的问答对对于测试来说至关重要，但是这些可以由大型语言模型（LLM）生成的问答对来增强效果。我们建议使用多种方法自动化生成问答对以最小化单一方法影响结果的风险。我们将完善一些内部工具并开源它们，请关注这方面的发展。

结论

在本文中，我们讨论了测试文档上下文化AI系统（如检索增强生成RAG和代理）的主要接触点。我们讨论了这些系统的组成部分、它们为何必要以及如何可能出错。然后，我们介绍了多种开源数据集，并探讨了它们如何用于测试文档上下文化的AI产品，同时解释了我们可以如何构建自己的数据集以进行更定制化的测试。本文是对这一问题的高层次概述，在未来的文章中，我将更加详细地介绍开发高度稳健的文档上下文化AI系统的方法。

我已经花费了不少时间为测试RAG系统构建数据集。这促使我总结出了一些经验法则，我想与大家分享：

可证伪性至关重要。如果你无法轻松地说出一个AI系统是正确的还是错误的，那么你的测试将不会很有效。

2. 在针对文档上下文化管道的特定组件进行测试和整体性测试之间取得平衡。具体的测试可以给你提供关于您的RAG/代理系统中哪些部分需要改进的理论，而整体性的测试则可以告诉你你的改动是否实际上改善了输出结果。
3. 删除研究是你的朋友。更换组件并测试你的RAG系统。用一个更简单的替代你昂贵和复杂的方案，看看性能是否会有显著变化。测试不仅是一个降低风险的机会，也是快速找出改进方法的一种方式。
4. 早些开始，从小处着手。测试很难，但你越早让它成为开发工作流程的核心部分，结果就会越好。你会变得更加擅长测试，并且你的产品会更快地变得更好。

引用链接

[1] 来源: https://chatdata-1257904505.cos.ap-guangzhou.myqcloud.com/public/1*aUYsc_ABqTz4AZCP_TglRw.png
[2] 来源: https://docs.llamaindex.ai/en/v0.10.17/api_reference/service_context/node_parser.html
[3] 基于嵌入的搜索策略在无关文档数量增加时性能会迅速下降: https://www.eyelevel.ai/post/most-accurate-rag
[4] RAGBench: https://arxiv.org/pdf/2407.11005
[5] PubMedQA: https://pubmedqa.github.io/
[6] HotPotQA: https://hotpotqa.github.io/