揭秘高级检索增强生成 (RAG) 管道

由大型语言模型（LLM）驱动的检索增强生成（RAG）管道在构建端到端问答系统中越来越受欢迎。LlamaIndex 和 Haystack 等框架在使 RAG 管道易于使用方面取得了显著进展。虽然这些框架为构建高级 RAG 管道提供了出色的抽象，但这是以牺牲透明度为代价的。从用户角度来看，底层发生了什么并不显而易见，特别是在出现错误或异常情况时。

在这个 EvaDB 应用中，我们将通过检查通常保持不透明的机制、限制和成本，来揭示高级 RAG 管道的内部工作原理。

在笔记本电脑上工作的 Llama 🙂

快速开始

如果您想立即开始，请使用以下命令运行应用程序：

pip install -r requirements.txt

echo OPENAI_API_KEY='yourkey' > .env
python complex_qa.py

RAG 概述

检索增强生成（RAG）是一种用于基于 LLM 的问答的前沿 AI 范式。 一个 RAG 管道通常包含：

1. 数据仓库 - 包含与问答任务相关的信息的数据源集合（例如，文档、表格等）。

2. 向量检索 - 给定一个问题，找到与该问题最相似的 Top K 个数据块。这是使用向量存储（例如，Faiss）完成的。

3. 响应生成 - 给定最相似的 Top K 个数据块，使用大型语言模型（例如 GPT-4）生成响应。

RAG 相比传统的基于 LLM 的问答提供了两个关键优势：

1. 最新信息 - 数据仓库可以实时更新，因此信息始终是最新的。

2. 来源追踪 - RAG 提供清晰的追溯性，使用户能够识别信息来源，这对于准确性验证和减轻 LLM 幻觉至关重要。

构建高级 RAG 管道

为了能够回答更复杂的问题，最近的 AI 框架如 LlamaIndex 引入了更高级的抽象，例如 子问题查询引擎。

在本应用中，我们将以子问题查询引擎为例，揭开复杂 RAG 管道的神秘面纱。我们将检查子问题查询引擎的内部工作原理，并将抽象简化为其核心组件。我们还将确定与高级 RAG 管道相关的一些挑战。

设置

数据仓库是包含与问答任务相关的信息的数据源的集合（例如，文档、表格等）。

在本示例中，我们将使用一个简单的数据仓库，其中包含多个关于不同热门城市的维基百科文章，灵感来自 LlamaIndex 的 说明性用例。每个城市的维基都是一个独立的数据源。请注意，为了简单起见，我们将每个文档的大小限制在 LLM 上下文限制范围内。

我们的目标是构建一个系统，能够回答诸如以下问题：

1. “芝加哥的人口是多少？”
2. “请总结亚特兰大的积极方面。”
3. “哪个城市人口最多？”

如您所见，问题可以是针对单个数据源的简单事实型/摘要型问题（Q1/Q2），也可以是针对多个数据源的复杂事实型/摘要型问题（Q3）。

我们有以下检索方法可供选择：

1. 向量检索 - 给定一个问题和一个数据源，使用来自该数据源中与问题最相似的前-K 个数据块作为上下文，生成 LLM 响应。我们使用来自 EvaDB 的现成 FAISS 向量索引进行向量检索。但是，这些概念适用于任何向量索引。

2. 摘要检索 - 给定一个摘要问题和一个数据源，使用该数据源的全部作为上下文，生成 LLM 响应。

秘诀

我们的关键见解是，高级 RAG 管道中的每个组件都由单次 LLM 调用驱动。整个管道是一系列精心设计的提示模板的 LLM 调用。这些提示模板是使高级 RAG 管道能够执行复杂任务的秘诀。

事实上，任何高级 RAG 管道都可以分解为遵循通用输入模式的一系列单独 LLM 调用：

其中：

• 提示模板 - 针对特定任务策划的提示模板（例如，子问题生成、摘要）
• 上下文 - 用于执行任务的上下文（例如，最相似的 Top-K 个数据块）
• 问题 - 要回答的问题

现在，我们通过检查子问题查询引擎的内部工作原理来说明这一原则。

子问题查询引擎必须执行三个任务：

1. 子问题生成 - 给定一个复杂问题，将其分解为一组子问题，同时为每个子问题识别适当的数据源和检索函数。
2. 向量/摘要检索 - 对于每个子问题，使用所选的检索函数在相应的数据源上检索相关信息。
3. 响应聚合 - 将来自子问题的响应聚合成最终响应。

让我们详细检查每个任务。

任务 1：子问题生成

我们的目标是将复杂问题分解为一组子问题，同时为每个子问题识别合适的数据源和检索函数。例如，问题 "Which city has the highest population?"（哪个城市人口最多？）被分解为五个子问题，每个城市一个，形式为 "What is the population of {city}?"（{城市}的人口是多少？）。每个子问题的数据源必须是相应城市的维基百科，检索函数必须是向量检索。

乍一看，这似乎是一项艰巨的任务。具体来说，我们需要回答以下问题：

1. 我们如何知道要生成哪些子问题？
2. 我们如何知道每个子问题使用哪个数据源？
3. 我们如何知道每个子问题使用哪个检索函数？

值得注意的是，这三个问题的答案都是一样的——一次单一的 LLM（大型语言模型） 调用！整个子问题查询引擎由一次精心设计的提示模板的单一 LLM 调用驱动。让我们称这个模板为 子问题提示模板。

-- Sub-question Prompt Template --

"""
    You are an AI assistant that specializes in breaking down complex questions into simpler, manageable sub-questions.
    When presented with a complex user question, your role is to generate a list of sub-questions that, when answered, will comprehensively address the original question.
    You have at your disposal a pre-defined set of functions and data sources to utilize in answering each sub-question.
    If a user question is straightforward, your task is to return the original question, identifying the appropriate function and data source to use for its solution.
    Please remember that you are limited to the provided functions and data sources, and that each sub-question should be a full question that can be answered using a single function and a single data source.
"""

LLM 调用的上下文是系统可用的数据源名称和函数。问题是用户问题。LLM 输出一系列子问题，每个都包含一个函数和一个数据源。

对于这三个示例问题，LLM 返回以下输出：

LLM 输出表格

问题	子问题	检索方法	数据源
"芝加哥的人口是多少？"	"芝加哥的人口是多少？"	向量检索	Chicago
"给我总结一下亚特兰大的积极方面。"	"给我总结一下亚特兰大的积极方面。"	摘要检索	Atlanta
"哪个城市人口最多？"	"多伦多的人口是多少？"	向量检索	Toronto
	"芝加哥的人口是多少？"	向量检索	Chicago
	"休斯顿的人口是多少？"	向量检索	Houston
	"波士顿的人口是多少？"	向量检索	Boston
	"亚特兰大的人口是多少？"	向量检索	Atlanta

任务 2：向量/摘要检索

对于每个子问题，我们使用选定的检索函数在相应的数据源上检索相关信息。例如，对于子问题 "What is the population of Chicago?"（芝加哥的人口是多少？），我们在芝加哥数据源上使用向量检索。同样，对于子问题 "Give me a summary of the positive aspects of Atlanta."（给我总结一下亚特兰大的积极方面。），我们在亚特兰大数据源上使用摘要检索。

对于这两种检索方法，我们使用相同的 LLM 提示模板。事实上，我们发现来自 LangchainHub 的流行 RAG Prompt（检索增强生成提示词） 开箱即用，非常适合此步骤。

-- RAG Prompt Template --

"""
You are an assistant for question-answering tasks. Use the following pieces of retrieved context to answer the question. If you don't know the answer, just say that you don't know. Use three sentences maximum and keep the answer concise.
Question: {question}
Context: {context}
Answer:

这两种检索方法仅在用于 LLM 调用的上下文上有所不同。对于向量检索，我们使用与子问题最相似的 Top K 个数据块作为上下文。对于摘要检索，我们使用整个数据源作为上下文。

任务 3：响应聚合

这是最后一步，将来自子问题的响应聚合成最终响应。例如，对于问题 "Which city has the highest population?"（哪个城市人口最多？），子问题检索了每个城市的人口，然后响应聚合查找并返回人口最多的城市。 RAG Prompt 在此步骤中也表现优异。

LLM 调用的上下文是来自子问题的响应列表。问题是原始用户问题，LLM 输出最终响应。

整合所有内容

在解开抽象层的奥秘后，我们发现了驱动子问题查询引擎的秘密成分——4 种类型的 LLM 调用，每种都有不同的提示模板、上下文和问题。这完美契合了我们之前确定的通用输入模式，与我们最初开始的复杂抽象相去甚远。 总结如下：

要查看完整流程的运行情况，请运行以下命令：

pip install -r requirements.txt

echo OPENAI_API_KEY='yourkey' > .env
python complex_qa.py

以下是系统回答问题 "Which city with the highest population?"（哪个城市人口最多？）的示例。

挑战

既然我们已经揭开了高级 RAG（检索增强生成）管道内部运作的神秘面纱，让我们来看看与之相关的挑战。

1. 问题敏感性 - 我们观察到的这些系统面临的最大挑战是问题敏感性。大语言模型（LLM）对用户问题极其敏感，导致管道在某些用户问题上意外失败。以下是我们遇到的一些示例失败案例：
   • 不正确的子问题 - 大语言模型有时会生成不正确的子问题。例如，"Which city has the highest number of tech companies?" 被分解为 "What are the tech companies in each city?" 5 次（每个城市一次），而不是 "What is the number of tech companies in Toronto?", "What is the number of tech companies in Chicago?" 等。
   • 不正确的检索函数 - "Summarize the positive aspects of Atlanta and Toronto." 导致使用了向量检索（vector retrieval）函数，而不是摘要检索（summary retrieval）方法。

我们必须投入大量精力进行提示工程（Prompt Engineering），才能使管道针对每个问题正常工作。这对于构建稳健的系统是一个重大挑战。

为了验证这种行为，我们使用 LlamaIndex 子问题查询引擎 实现了该示例。与我们的观察一致，该系统经常生成错误的子问题，并且为子问题使用了错误的检索函数，如下所示。

2. 成本 - 第二个挑战是高级 RAG 管道的成本动态变化。这个问题有两方面：
   • 成本敏感性 - 问题的最终成本取决于生成的子问题数量、使用的检索函数以及查询的数据源数量。由于 LLM 对提示词敏感，问题的成本会根据问题和 LLM 输出而有显著差异。例如，上述 LlamaIndex 基线示例中错误的模型选择（summary_tool）导致成本比 vector_tool 高出 3 倍，同时还会生成错误的响应。
   • 成本估算 - RAG 框架中的高级抽象模糊了问题的预估成本。建立成本监控系统具有挑战性，因为问题的成本取决于 LLM 的输出。

结论

由 LLM 驱动的高级 RAG 管道彻底改变了问答系统。 然而，正如我们所见，这些管道并非即插即用解决方案。在底层，它们依赖于精心设计的提示模板和多次链式调用的 LLM。正如本 EvaDB 应用所示，这些管道可能对问题敏感、脆弱，且其成本动态不透明。理解这些细微差别是利用其全部潜力的关键，并为未来构建更稳健和高效的系统铺平道路。

rag-demystified 快速上手指南

本工具旨在揭示高级 RAG（检索增强生成）管道的内部机制，通过拆解复杂的抽象层，展示其核心由一系列精心设计的 LLM 调用组成。

环境准备

• Python 环境：需安装 Python 3.8 或更高版本。
• API Key：需要准备一个有效的 OpenAI API Key，用于驱动大语言模型。
• 网络环境：确保能够访问 PyPI 包仓库及 OpenAI 服务接口。

安装步骤

1. 将项目代码克隆或下载到本地目录。
2. 在项目根目录下安装所需依赖：

   pip install -r requirements.txt
   

3. 创建 .env 文件并配置 API Key（请将 yourkey 替换为实际密钥）：

   echo OPENAI_API_KEY='yourkey' > .env
   

基本使用

运行主脚本即可启动应用，体验针对多数据源复杂问题的问答功能（示例场景为比较不同城市的人口数据）：

python complex_qa.py

系统将自动执行以下流程：

1. 子问题生成：将复杂问题拆解为多个简单子问题。
2. 检索与生成：对每个子问题进行向量或摘要检索并生成回答。
3. 聚合响应：汇总所有子问题的回答，输出最终结果。