Skip to main content

概述

LLM 支持的最强大的应用之一是复杂的问答(Q&A)聊天机器人。这些应用能够回答关于特定来源信息的问题。这些应用使用一种称为检索增强生成(Retrieval Augmented Generation,简称 RAG)的技术。 本教程将展示如何构建一个简单的问答应用,用于处理非结构化文本数据源。我们将演示:
  1. 一个使用简单工具执行搜索的 RAG 代理。这是一个良好的通用实现。
  2. 一个两步 RAG ,每次查询仅使用一次 LLM 调用。这是一种快速且有效的方法,适用于简单查询。

概念

我们将涵盖以下概念:
  • 索引:从数据源摄取数据并对其进行索引的管道。这通常在单独的进程中进行。
  • 检索和生成:实际的 RAG 过程,在运行时获取用户查询,从索引中检索相关数据,然后将其传递给模型。
一旦我们索引了数据,我们将使用一个代理作为我们的编排框架来实现检索和生成步骤。
本教程的索引部分在很大程度上遵循语义搜索教程如果你的数据已经可用于搜索(即,你有一个执行搜索的函数),或者你熟悉该教程的内容,请随时跳转到检索和生成部分。

预览

在本指南中,我们将构建一个回答网站内容问题的应用。我们将使用的特定网站是 Lilian Weng 的 LLM 驱动的自主代理 博客文章,这使我们能够就文章内容提问。 我们可以创建一个简单的索引管道和 RAG 链,用大约 40 行代码来完成此操作。完整代码片段如下:
查看 LangSmith 跟踪

设置

安装

本教程需要以下 langchain 依赖项:
更多详情,请参阅我们的安装指南

LangSmith

你使用 LangChain 构建的许多应用将包含多个步骤,并多次调用 LLM。随着这些应用变得越来越复杂,能够检查你的链或代理内部到底发生了什么变得至关重要。最好的方法是使用 LangSmith 在上面的链接注册后,请确保设置你的环境变量以开始记录跟踪:

组件

我们需要从 LangChain 的集成套件中选择三个组件。 选择一个聊天模型:
👉 阅读 OpenAI 聊天模型集成文档
选择一个嵌入模型:
选择一个向量存储:

1. 索引

本节是语义搜索教程内容的简略版本。如果你的数据已经索引并可用于搜索(即,你有一个执行搜索的函数),或者你熟悉文档加载器嵌入向量存储,请随时跳转到下一节检索和生成
索引通常按以下方式工作:
  1. 加载:首先我们需要加载数据。这通过文档加载器完成。
  2. 分割文本分割器将大型 Document 分割成更小的块。这对于索引数据和将其传递给模型都很有用,因为大块数据更难搜索,并且无法放入模型有限的上下文窗口中。
  3. 存储:我们需要一个地方来存储和索引我们的分块,以便稍后可以进行搜索。这通常使用向量存储嵌入模型来完成。
index_diagram

加载文档

我们需要首先加载博客文章内容。我们可以使用 DocumentLoaders 来完成此操作,它们是从数据源加载数据并返回 Document 对象列表的对象。
深入了解 DocumentLoader:从数据源加载数据并作为 Documents 列表返回的对象。
  • 集成:160 多种集成可供选择。
  • BaseLoader:基础接口的 API 参考。

分割文档

我们加载的文档超过 42k 个字符,太长而无法放入许多模型的上下文窗口中。即使对于那些可以将整篇文章放入其上下文窗口的模型,模型也可能难以在非常长的输入中找到信息。 为了解决这个问题,我们将把 Document 分割成块,以便进行嵌入和向量存储。这应该有助于我们在运行时仅检索博客文章中最相关的部分。 语义搜索教程一样,我们使用 RecursiveCharacterTextSplitter,它将使用常见的分隔符(如换行符)递归地分割文档,直到每个块达到适当的大小。这是通用文本用例的推荐文本分割器。

存储文档

现在我们需要索引我们的 66 个文本块,以便在运行时可以对它们进行搜索。遵循语义搜索教程,我们的方法是嵌入每个文档分割的内容,并将这些嵌入插入到向量存储中。给定一个输入查询,我们然后可以使用向量搜索来检索相关文档。 我们可以使用在教程开始时选择的向量存储和嵌入模型,通过单个命令嵌入和存储所有文档分割。
深入了解 Embeddings:文本嵌入模型的包装器,用于将文本转换为嵌入。
  • 集成:30 多种集成可供选择。
  • 接口:基础接口的 API 参考。
VectorStore:向量数据库的包装器,用于存储和查询嵌入。
  • 集成:40 多种集成可供选择。
  • 接口:基础接口的 API 参考。
这完成了管道的索引部分。此时,我们拥有一个可查询的向量存储,其中包含博客文章的分块内容。给定一个用户问题,我们理想情况下应该能够返回回答该问题的博客文章片段。

2. 检索和生成

RAG 应用通常按以下方式工作:
  1. 检索:给定用户输入,使用检索器从存储中检索相关的分块。
  2. 生成模型使用包含问题和检索到的数据的提示来生成答案。
retrieval_diagram 现在让我们编写实际的应用逻辑。我们想要创建一个简单的应用,它接收用户问题,搜索与该问题相关的文档,将检索到的文档和初始问题传递给模型,并返回答案。 我们将演示:
  1. 一个使用简单工具执行搜索的 RAG 代理。这是一个良好的通用实现。
  2. 一个两步 RAG ,每次查询仅使用一次 LLM 调用。这是一种快速且有效的方法,适用于简单查询。

RAG 代理

RAG 应用的一种表述是作为一个简单的代理,带有一个检索信息的工具。我们可以通过实现一个包装我们向量存储的工具来组装一个最小的 RAG 代理:
这里我们将 responseFormat 指定为 content_and_artifact,以配置工具将原始文档作为工件附加到每个 ToolMessage。这将使我们能够在应用中访问文档元数据,与发送给模型的字符串化表示分开。
给定我们的工具,我们可以构建代理:
让我们测试一下。我们构建一个通常需要一系列迭代检索步骤才能回答的问题:
注意代理:
  1. 生成一个查询来搜索任务分解的标准方法;
  2. 收到答案后,生成第二个查询来搜索其常见扩展;
  3. 收到所有必要的上下文后,回答问题。
我们可以在 LangSmith 跟踪中看到完整的步骤序列,以及延迟和其他元数据。
你可以使用 LangGraph 框架直接添加更深层次的控制和自定义——例如,你可以添加步骤来评估文档相关性并重写搜索查询。查看 LangGraph 的 Agentic RAG 教程以获取更高级的表述。

RAG 链

在上面的 agentic RAG 表述中,我们允许 LLM 自行决定生成一个工具调用来帮助回答用户查询。这是一个良好的通用解决方案,但也带来了一些权衡: 另一种常见的方法是两步链,其中我们始终运行一次搜索(可能使用原始用户查询),并将结果作为单个 LLM 查询的上下文。这导致每次查询只有一次推理调用,以牺牲灵活性为代价换取降低的延迟。 在这种方法中,我们不再循环调用模型,而是进行单次传递。 我们可以通过从代理中移除工具,并将检索步骤合并到自定义提示中来实现此链:
让我们试试这个:
LangSmith 跟踪中,我们可以看到检索到的上下文被合并到模型提示中。 这是一种快速且有效的方法,适用于受限环境中的简单查询,当我们通常确实希望将用户查询通过语义搜索以获取额外上下文时。
上述 RAG 链将检索到的上下文合并到该次运行的单个系统消息中。agentic RAG 表述一样,我们有时希望在应用状态中包含原始源文档,以便访问文档元数据。我们可以通过以下方式为两步链的情况实现这一点:
  1. 向状态添加一个键来存储检索到的文档
  2. 通过中间件钩子(如 before_model)添加一个新节点来填充该键(以及注入上下文)。

安全:间接提示注入

RAG 应用容易受到间接提示注入的影响。检索到的文档可能包含类似指令的文本(例如,“以 JSON 格式响应”或“忽略之前的指令”)。因为检索到的上下文与你的系统提示共享相同的上下文窗口,模型可能会无意中遵循嵌入在数据中的指令,而不是你预期的提示。例如,本教程中索引的博客文章包含描述 Auto-GPT JSON 响应格式的文本。如果用户查询检索到该块,模型可能会输出 JSON 而不是自然语言答案。
为了缓解这个问题:
  1. 使用防御性提示:明确指示模型将检索到的上下文仅视为数据,并忽略其中的任何指令。本教程中的提示包含此类指令。
  2. 用分隔符包裹上下文:使用清晰的结构标记(例如,像 <context>...</context> 这样的 XML 标签)将检索到的数据与指令分开,使模型更容易区分它们。
  3. 验证响应:检查模型的输出是否符合预期格式(例如,纯文本),并优雅地处理意外格式。
没有缓解措施是万无一失的——这是当前 LLM 架构的固有限制,其中指令和数据共享相同的上下文窗口。有关此主题的更多信息,请参阅关于提示注入的研究。

后续步骤

现在我们已经通过 createAgent 实现了一个简单的 RAG 应用,我们可以轻松地添加新功能并深入探索: