RAG在AI项目中的核心要点

RAG 基础概述

Retrieval-Augmented Generation（检索增强生成，RAG）是一个框架，通过外部数据获取或检索机制来增强大型语言模型。当你提出一个问题时，RAG 系统首先在知识库（数据库、内部文档等）中搜索相关信息。然后将这些检索到的信息与你的原始问题结合起来，一起提供给 LLM。这为 LLM 提供了背景信息——问题和支持文档——使其能够生成更准确、更符合事实、基于所提供信息的答案。

Retrieval（检索）： 工具或系统在 LLM 生成答案之前，在特定的知识源（比如存储在 Google Drive 中的你的文档）中搜索与查询相关的信息。

Augment（增强）： 这些检索到的信息（上下文）被添加到你的原始查询中，创建一个"增强"或扩展的 prompt。

Generation（生成）： LLM 随后使用这个增强的 prompt（原始查询 + 检索到的上下文）生成一个基于所提供信息的答案，使其更加准确和相关。

为什么我们需要检索增强生成？

RAG 解决了独立 LLM 的几个局限。传统的 LLM 是在大但静态的数据集上训练的，因此有固定的知识截止日期。它们也可能会"幻觉"——产生似乎合理但实际上错误或虚构的信息——尤其是在被问及从未训练过的细节时，比如私有公司数据或新产品的具体信息。此外，验证为什么标准 LLM 给出特定答案是很复杂的。RAG 通过将 LLM 的响应基于特定的检索文档来帮助克服这些问题，这也可以允许生成信息的可追溯性和验证。

让我们从视觉上理解这一点。

假设一个 LLM 被安装在一家公司 ACME Corp. 内部，一名员工问 LLM："Saturn Analytics 产品的功能是什么？"这个产品是新产品，由 ACME 内部开发，细节还未公开。LLM 不知道这个特定产品的实际信息（因为它不在其训练数据中），可能会根据它对分析产品的一般知识甚至不相关的信息来捏造一些似乎合理的功能。这导致生成了事实上不正确的信息。这被称为幻觉。

如果 LLM 有一个工具可以基于用户查询检索文档，AI 系统可以首先从知识库中搜索相关文档。然后它将这些检索到的信息附加到原始 prompt 上（创建一个"增强的" prompt）。最后，LLM 基于这些文档的上下文生成答案，产生事实上正确的信息。

既然我们理解了 RAG 的必要性，让我们探索它的优势。

RAG 的优势是什么？

我们看到了标准 LLM 如何可能与特定或新信息相抗争，有时会导致幻觉。Retrieval-Augmented Generation（RAG）直接解决了这些问题。以下是主要优势：

访问当前和特定信息： RAG 系统在回答之前从外部源检索信息。它可以访问最新的数据、私有公司文档或你提供的任何特定知识库。这克服了传统 LLM 的静态性质和知识截止日期的问题。

提高准确性和减少幻觉： 通过将 LLM 的答案基于实际检索到的文档，RAG 显著减少了模型凭空捏造的情况。LLM 不仅仅是基于其泛化的训练进行猜测；它是基于与用户问题一起提供给它的具体事实来构建答案。

信任和可验证性： 当 RAG 系统提供答案时，很容易看到它在检索步骤中使用了哪些文档。这意味着你可以潜在地验证信息或理解答案的来源，增强对生成的答案的信任。

成本效益的知识更新： 每次需要纳入新信息时，你不需要不断进行昂贵和复杂的整个 LLM 重新训练或微调，而是可以简单地更新 RAG 检索的外部知识库。添加新产品文档或更新信息表要便宜得多且更快。

RAG 将 LLM 转变为可靠的工具，使其更加安全、知识丰富，对于需要特定、当前或专有信息的任务更加实用。这缩小了 LLM 的通用能力与现实世界信息需求之间的差距，使你对 AI 项目有更多信心。

接下来，考虑 RAG 管道工作和在 AI 生成答案前开始提供上下文所需的重要工具。

你如何为 RAG 向 LLM 提供信息？

我们已经确立了给 LLM 访问外部信息对于准确、最新答案的重要性。但我们如何将 LLM 连接到这些知识呢？以下是构建 RAG 系统的一些标准技术：

使用向量数据库进行语义搜索： 在这种方法中，我们获取你的信息（如产品手册、公司政策和文章），然后使用嵌入模型将每个文档转换为称为"向量"的数值表示。所有这些向量都存储在一个专门的向量数据库中。当用户提出问题时，系统在向量数据库中搜索含义最接近的文本（最接近的向量）。即使用户在文档中没有使用完全相同的关键词，这也允许 LLM 找到相关信息。

使用 API 和外部工具（LLM Agents、Tool Calling、MCP）： LLM 也可以访问"工具"，包括调用外部 API。这允许它获取实时信息（例如，检查当前股票价格、获取天气预报、查询特定公司的微服务），这些信息不存储在任何静态文档集合中。这种方法通常会进入"LLM Agents"领地，其中 LLM 可以更动态地与外部系统交互。你可以在这里详细了解这种方法。

查询结构化数据库（SQL）： 有时，关键信息不在非结构化文档中，而是整齐地组织在结构化数据库中（如 SQL 数据库）。对于这些情况，你可以实现通常称为"Text-to-SQL"的技术。系统获取用户的自然语言问题，将其转换为正式的 SQL 查询，针对数据库运行该查询，并检索所需的特定数据行。然后，这些检索到的数据被提供给 LLM 作为上下文。

构建有效的 RAG 系统涉及一个周思熟虑的过程，而不仅仅是插入一个 LLM。我们很快将深入研究细节，并利用强大的向量数据库语义搜索来检索相关信息。我们还将讨论 LangChain 等框架如何能够显著简化这些组件的编排。

在第 2 点中，提到了 MCP，你可以在这里阅读更多。然而，许多人对 MCP 和 RAG 之间的区别感到困惑。并做出毫无根据的声称，如"因为 MCP，RAG 已死"。在本节中，我们分享 RAG 的不同方法。正如我们所讨论的，核心思想是向 LLM 提供数据，这可以通过各种方式发生。让我们探索 MCP 和 RAG 之间的区别，为你提供它们如何不同和相同的清晰理解。

RAG 和 MCP：RAG 已死吗？

许多人经常将主要概念或哲学与工具混淆。RAG 变成了向量数据库、LangChain、嵌入、搜索引擎、数据管道等的同义词。然而，事实并非如此。正如我们讨论的，RAG 是一种在 AI 生成答案前通过增强 prompt 来获取数据和提供上下文的方法，使其更准确和事实上正确。

我们也应该讨论 MCP，它代表 Model Context Protocol，由 Anthropic 为其 Claude AI 开发。它是一种访问不同数据库、工具、函数等并执行操作（如抓取网页、获取相关文档和从数据库读取最新查询）的方式。

这种连通性允许 AI 模型执行各种操作、执行特定函数，并从不同源检索必要数据。MCP（或通过该协议运行的工具/服务器）可以有效地作为 RAG 架构中的检索器。这种收集信息的方法可能不同于，甚至绕过，其他标准检索工具（如简单的向量搜索）。但是，关键是要理解，即使检索是通过 MCP 管理的，基本过程仍然构成 RAG，因为外部知识被主动检索以在 AI 生成其最终响应之前增强 prompt。

所以，MCP 并不意味着 RAG 已死。它意味着我们找到了一种更容易设置的获取数据的方式，但使用方式取决于个人或公司的需求。

长上下文 AI 模型和 RAG：再次，RAG 已死吗？

Meta AI 发布了 Llama 4 系列 AI 模型，具有巨大的 1000 万个 token 上下文窗口。相比之下，它可以容纳整个《哈利·波特》、《指环王》和《权力的游戏》书系列——还有多余的空间。这种扩展的上下文允许模型在更大的文本跨度上处理和推理，使更深入、更连贯的输出成为可能。

RAG 背后的思想很简单：它不仅仅是关于 LLM 知道什么，而是关于我们如何能够为其提供正确的上下文。在许多现实应用中，LLM 需要检索相关数据或在运行时被提供数据，以生成知情、准确的响应。

结论：使用 RAG 为 LLM 提供上下文

简而言之，虽然标准 LLM 令人印象深刻，但它们的固定知识和倾向于幻觉限制了它们在特定或当前数据方面的实际应用。Retrieval-Augmented Generation（RAG）通过使 LLM 能够首先从你选择的源检索相关信息、用这个上下文增强其 prompt，然后生成事实上有根据的答案，提供了一个强大的解决方案。RAG 是将 LLM 从通用对话者转变为特定、现实世界应用的可靠、有知识工具的关键，我们在本文中探索了这一思想。

这是一篇 3 部分的文章。在下一篇中，我们将深入探讨如何使用所提到的工具和框架编写 RAG 解决方案。这将为你提供更实际的方法和信心来为你的项目构建检索增强生成管道。

额外资源

感谢阅读。如果你寻求深入的研究论文和文章来增加你的理解。你可以点击以下链接：

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Paper)

Internet-Augmented Dialogue Generation (Paper)

Improving language models by retrieving from trillions of tokens (Paper)

Retrieval augmented generation: Keeping LLMs relevant and current

Retrieval Augmented Generation (RAG)

准备开始？

扩展你的集成策略，并在创纪录的时间内交付你的客户需要的集成。