RAG比之MCP或长上下文LLM，要没落了吗？

今天和大家讲一下关于 Retrieval-augmented generation（RAG）的一些内容，特别是它在大语言模型（LLM）中的应用。如果你经常关注AI行业的话，这里的内容会让你对RAG有更深的理解。

RAG 是一种框架，它通过外部数据获取或检索机制来增强 LLM 的能力。当你提出一个问题时，RAG 系统会首先从知识库（如数据库、内部文档等）中搜索相关信息。然后，它将这些检索到的信息与你的原始问题一起输入给 LLM。这样就为 LLM 提供了上下文——即问题和支持文档——从而让它能够生成更准确、更符合事实的答案，并且这些答案是基于所提供的信息的。

分解概念：

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

• 增强：检索到的信息（上下文）会被添加到你的原始查询中，创建一个“增强”的或扩展的提示。

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

当然，传统的 LLM 也有它的局限性，比如固定的训练数据集和可能会“胡编乱造”（hallucinate），尤其是在面对它从未被训练过的细节时，比如私有公司数据或新产品的具体信息。此外，验证为什么标准 LLM 给出某个特定答案也很复杂。而 RAG 可以帮助克服这些问题，因为它将 LLM 的响应基于具体的、检索到的文档，这也可以允许进行可追溯性和验证生成的信息。

为什么我们需要 RAG？

RAG 解决了几个独立 LLM 的限制。

传统 LLM 是在大型但静态的数据集上进行训练的，因此有一个固定的知识截止日期。它们还可能“产生幻觉”——生成听起来合理但实际上不正确或虚构的信息——特别是在被问及它们从未被训练过的细节时，比如私人公司的数据或新产品的具体信息。

此外，验证标准 LLM 为什么给出某个特定答案是很复杂的。RAG 通过将 LLM 的响应基于具体的、检索到的文档来帮助克服这些问题，这也允许进行可追溯性和验证生成的信息。

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

RAG 的好处有哪些？

我们都知道现在 LLM 都是通过大量文本组成的，而 RAG 直接解决了这些 LLM 在特定或新信息方面的挣扎，有时会导致幻觉的问题。以下是 RAG 的主要优势：

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

• 提高准确性和减少幻觉：通过将 LLM 的答案基于实际检索到的文档，RAG 大幅减少了模型捏造的可能性。LLM 不再仅仅基于其泛化的训练进行猜测；它是根据用户问题以及提供的具体事实构建答案的。

• 信任和可验证性：当 RAG 系统提供答案时，很容易看到它用于检索步骤的文档。这意味着你可以潜在地验证信息或理解答案的来源，从而建立对生成答案的信任。

• 成本有效的知识更新：无需每次需要纳入新信息时都进行昂贵且复杂的整个 LLM 的重新训练或微调，只需更新 RAG 检索的外部知识库即可。添加新产品文档或更新信息表单既便宜又快捷。

RAG 将 LLM 转变为可靠的工具，使它们更加安全、知识丰富，并且对于需要特定、当前或专有信息的任务来说更为实用。这弥合了 LLM 的一般能力和现实世界信息需求之间的差距，让你对你的 AI 项目更有信心。

接下来，考虑我们在 RAG 管道工作时需要知道的重要工具，以及如何在 AI 生成答案之前提供上下文。

如何向 LLM 提供信息以实现 RAG？

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

1. 使用向量数据库进行语义搜索：在这种方法中，我们将你的信息（如产品手册、公司政策和文章）转换为称为“向量”的数值表示。所有这些向量都存储在专用的向量数据库中。当用户提问时，系统会在向量数据库中搜索具有最接近含义的文本（最近的向量）。这使得即使用户没有使用文档中的确切关键词，LLM 也能找到相关信息。

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

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

构建有效的 RAG 系统涉及一个深思熟虑的过程，不仅仅是简单地插入 LLM。我们很快就会深入探讨如何利用强大的语义搜索和向量数据库来检索相关信息，并讨论像 LangChain 这样的框架如何显著简化这些组件的协调。

在点 2 中提到了 MCPs，你可以在这里阅读更多相关内容。然而，许多人混淆了 MCPs 和 RAG 之间的区别，并提出了诸如“由于 MCPs，RAG 已死”之类的毫无根据的说法。在这一部分中，我们将探讨 RAG 的不同方法。正如我们所讨论的，核心思想是给 LLM 提供数据，这可以通过多种方式实现。让我们探索 MCP 和 RAG 之间的差异和相似之处，为你提供清晰的理解。

RAG 和 MCP：RAG 要淘汰了吗？

很多人常常混淆主要概念或工具。RAG 被视为向量数据库、LangChain、嵌入、搜索引擎、数据管道等的同义词。然而，情况并非如此。正如我们所讨论的，RAG 是一种通过检索数据并增强提示前的上下文来提供上下文的方法，从而使 AI 生成的答案更加准确和事实正确。

我们也应该讨论 MCPs，即 Model Context Protocol，这是 Anthropic 为其 Claude AI 开发的。它是一种访问不同数据库、工具、函数等的方式，并执行诸如抓取网页、检索相关文档和读取数据库中的最新查询等操作。

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

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

长上下文 AI 模型和 RAG：再一次，要淘汰了吗？

Meta AI 发布了具有 10 百万标记上下文窗口的 Llama 4 系列 AI 模型。为了便于理解，它可以容纳整个《哈利波特》、《指环王》和《权力的游戏》书系列——还有剩余空间。这种扩展的上下文允许模型处理和推理跨越更大的文本跨度，从而实现更深层次、更连贯的输出。

RAG（Retrieval-Augmented Generation）背后的想法很简单：不仅是 LLM 知道什么，而是我们如何为它提供正确的上下文。在许多实际应用中，LLM 要么需要检索相关数据，要么需要即时提供这些数据，以便生成知情、准确的响应。

简而言之，尽管标准 LLM 很令人印象深刻，但它们的固定知识和产生幻觉的倾向限制了它们在特定或当前数据方面的实际用途。通过使 LLM 首先检索来自你选择的来源的相关信息，增强其提示与此上下文，并生成基于事实的答案，RAG 提供了一个强大的修复方案。RAG 是将 LLM 从通用对话者转变为可靠、知识丰富的特定、实际应用工具的关键。