什么是 RAG（检索增强生成）

注意：本文档是英文原版的自动翻译。

什么是 RAG（检索增强生成）

想象一个学生在参加一场开卷考试。他不是仅凭记忆回答每一道题，而是翻阅教科书、找到最相关的页面、读完它们，然后写出一个把记忆中的知识与刚查到的事实结合起来的答案。检索增强生成（Retrieval-Augmented Generation, RAG）对大语言模型的运作方式与此相同。模型不再仅仅依赖它在训练期间记住的内容——它先搜索一个外部知识库，检索最相关的文档，并在生成回应时把它们用作额外的上下文。

这项技术之所以重要，是因为即便是最强大的 LLM 也有知识截止日期、会“幻觉”（产生看似可信却错误的陈述），并且可能缺乏专门的领域知识。RAG 通过在每次回答问题时让模型访问最新的、特定领域的、可验证的来源，一举解决了这三个弱点。

简而言之： RAG 是一种把检索系统与 LLM 结合起来的架构模式。它不是一种单独的模型类型——它是一种处理外部知识和上下文的方式。

工作原理

一条 RAG 流水线遵循清晰的五步序列。理解每一步有助于你评估：一个声称使用 RAG 的项目，究竟拥有一个真正可运行的检索层，还是仅仅包裹了一次标准的 LLM 调用。

第 1 步 — 用户查询

流程始于用户提交一个问题、命令或提示。这个查询是后续一切的起点。例如，用户可能会问：“过去一个月里 Ethereum 上有哪些重大的治理提案？”系统不会试图仅凭 LLM 的记忆来回答——相反，它把这个查询当作一条搜索指令。

第 2 步 — 查询嵌入

原始文本查询被转换为一种称为嵌入（embedding）的数值表示——一个捕捉查询语义含义的数字向量。这一步使用专门的嵌入模型（如 OpenAI 的 text-embedding-ada-002，或开源替代品 E5 或 BGE）。所得到的向量让系统能够执行语义搜索——按含义而非精确关键词匹配来查找文档。

第 3 步 — 从知识库检索

查询嵌入会与一个向量数据库（也称向量存储）进行比对，后者保存着文档、段落或数据块的预计算嵌入。数据库返回语义上最相似的前 k 个条目。常见的向量数据库包括 Pinecone、Weaviate、Qdrant、Milvus 和 Chroma。

检索的质量取决于若干因素：

分块策略 — 原始文档是如何被切分成更小片段的。块太大会稀释相关性；块太小会丢失上下文。找到合适的块大小是 RAG 流水线中最具影响力的工程决策之一。
嵌入模型 — 含义被向量捕捉得有多准确。无论数据库如何，弱的嵌入模型都会导致弱的检索。
相关性排序 — 搜索返回的是真正相关的结果，还是仅仅表面相似的结果。一些系统会增加一个重排序（re-ranking）步骤，用交叉编码器对初始结果重新打分。

第 4 步 — 上下文注入

检索到的文档与用户的原始查询被合并为一个单一的提示（有时称为“增强提示”），并发送给 LLM。该提示通常会指示模型使用所提供的上下文来回答问题，并在上下文不包含足够信息时予以说明。

第 5 步 — LLM 生成与输出

LLM 读取增强提示，并生成一个既植根于其预训练知识、又植根于所检索证据的回应。一个设计良好的 RAG 系统还可能包含一个引用层，把答案的各个部分链接回具体的来源文档，让用户有办法核实主张。

阶段	输入	输出	关键组件
查询	用户文本	原始查询	用户界面
嵌入	原始查询	查询向量	嵌入模型
检索	查询向量	相关文档	向量数据库
上下文注入	查询 + 文档	增强提示	提示模板
生成	增强提示	最终答案	LLM

为什么 RAG 很重要

RAG 解决了独立 LLM 三个众所周知的局限：

幻觉。 LLM 可能产出自信却错误的答案。RAG 通过把回应植根于真实文档来减少这一点。当模型能够引用某个具体段落时，编造的风险显著下降。
知识陈旧。 一个预训练模型有知识截止日期。RAG 允许访问新鲜的、持续更新的数据——一个外部数据库可以每天甚至实时刷新。
领域专门性。 为狭窄领域微调一个 LLM 既昂贵又耗时。RAG 让一个通用模型无需再训练即可使用专门的知识库，从而更快、更便宜地部署特定领域的应用。

RAG 与微调

RAG 和**微调（fine-tuning）**都旨在提升 LLM 在特定任务上的表现，但它们的工作方式根本不同。

方面	RAG	微调
何时加入知识	在推理时（每次查询）	在训练时（一次，之后静态）
更新成本	低——更新知识库即可	高——重新训练或重新微调模型
知识新鲜度	可接近实时	冻结在训练截止时刻
是否需要训练基础设施	否	是（GPU、数据集、训练流水线）
最适合	事实性检索、文档问答	风格、语气、格式、狭窄任务优化
可审计性	高——检索到的来源可被记录	低——知识嵌入在权重中

在实践中，许多生产系统会同时使用两者：一个微调模型提供正确的语气和任务行为，而 RAG 供给最新的事实依据。

高级 RAG 模式

上文描述的基本五步流水线有时被称为朴素 RAG（naive RAG）。随着这项技术的成熟，工程师们开发出了更复杂的变体：

多步（迭代）RAG。 系统不是只检索一次，而是检索、生成一个中间答案、识别知识缺口、用经过精炼的查询再次检索，并重复直到答案足够完整。这种做法能处理无法通过单次检索回答的复杂问题。
代理式 RAG（Agentic RAG）。 检索步骤被包裹在一个 AI 代理框架内。代理决定何时检索、查询哪个知识库、是否重新表述查询，以及何时已有足够上下文来生成最终答案。这种模式模糊了 RAG 与自主代理之间的界线。
混合搜索。 在同一检索步骤中，把基于向量的语义搜索与传统的关键词搜索（BM25）结合起来。混合搜索同时捕捉基于含义和基于词项的匹配，提升了对包含特定技术术语或专有名词的查询的召回率。
图 RAG（Graph RAG）。 知识库不再是扁平的文档块，而是被构建为一个知识图谱——实体与关系。检索沿着图的边进行，而非（或除了）向量相似度，从而支持在结构化数据上进行多跳推理。这些模式对评估很重要：一个描述了带迭代检索的图-RAG 流水线的项目，所做的主张比一个只说“我们使用 RAG”的项目更具体（也更难伪造）。

RAG 的真实世界示例

RAG 不是一个理论概念——它为当今一些使用最广泛的 AI 产品提供动力。

Bing Chat（Microsoft Copilot）。 当你向 Bing Chat 提问时，它会搜索网络、检索相关页面，并把这些页面用作 LLM 答案的上下文。你在回应中看到的内联引用，正是检索步骤的直接结果。
Perplexity。 Perplexity 是围绕一个 RAG 架构构建的：每一次用户查询都会触发一次网络搜索，结果被喂给一个 LLM，答案中包含带编号的来源引用。用户可以点击进去核实每一个主张。
企业知识助手。 公司使用内部 RAG 系统，让员工用自然语言查询 HR 政策、工程文档或法律合同。检索层搜索的是公司的内部文档库，而非开放网络。这些示例表明 RAG 是主流技术。当一个加密 AI 项目说“我们使用 RAG”时，问题不在于 RAG 是否是真实技术，而在于该项目的具体实现是否扎实：检索的是什么数据、它如何被索引，以及检索质量是否被衡量过。

为什么 RAG 出现在加密 AI 项目中

许多加密 AI 项目在其架构中使用 RAG 或声称使用它。常见的使用场景包括：

文档助手 — 检索协议文档、白皮书或治理提案，以回答用户关于某个协议规则或参数的问题。
加密情报工具 — 拉取实时市场数据、链上事件或新闻文章，以生成分析摘要或警报。
代理的知识库 — 构建结构化的存储库，供 AI 代理在行动前查询，确保决策基于最新数据。
链上数据接地 — 把检索层连接到区块链索引器，使 LLM 能够用当前信息（而非训练时的快照）回答关于钱包余额、交易历史或智能合约状态的问题。

DecAIHub 项目卡片中涉及 RAG 模式的典型 AI 组件取值包括：“3D AI agents (RAG/memory/LLM catalog)”“AI summaries + crypto intelligence terminal”以及“AgentData (real-time data streams for AI agents)”。

RAG 不是一种模型

一个常见的误解是把 RAG 当作一种 AI 模型类型。它不是。RAG 是一种架构模式——一种把检索系统与 LLM 结合起来的方式。RAG 流水线内部的模型可以是 GPT、DeepSeek、Mistral 或任何其他 LLM。检索组件可以是一个向量数据库、一个搜索 API，或一个结构化的知识图谱。

说“我们使用 RAG”告诉你的是系统如何组织。它并不告诉你使用的是哪个模型、它是否专有，或检索质量有多好。两个项目都可以声称使用 RAG，而其复杂程度却可能天差地别——一个拥有精心整理的知识库和定制嵌入，另一个则是一个匆忙拼凑、很少返回相关文档的原型。

RAG 不能证明什么

使用 RAG 并不能证明底层 LLM 是专有的或经过微调的。该项目可能在调用一个第三方 API。
构建一条 RAG 流水线并不能证明检索质量很高。质量取决于知识库、分块策略、嵌入模型和搜索相关性。
拥有一个 RAG 架构并不能证明答案是准确的。糟糕的检索可能喂入不相关的上下文，而 LLM 仍可能产生幻觉。
在着陆页上提到 RAG 并不能证明系统真的在执行检索。没有 Tier-1 证据——代码、架构图、演示日志——这一主张仍未经验证。在评估一个声称使用 RAG 的加密 AI 项目时，请寻找具体内容：搜索的是什么知识库、使用什么嵌入模型、如何衡量相关性，以及是否发布了任何质量指标。

它在 DecAIHub 项目卡片中的体现

RAG 通常在 AI component 字段中被提及——要么直接提及，要么通过暗示“检索加生成”流水线的描述来体现。AI_1 标志位检查 AI 组件是否被描述得足够具体。仅仅写上“RAG”是不够的；卡片应当解释检索的是什么、从何处检索、为了什么目的。

请勿混淆

LLM — RAG 流水线内部的生成引擎。RAG 在其之上增加了检索。
训练 — RAG 是一种推理时的模式。它不重新训练模型；它用检索到的上下文来增强提示。
AI 代理 — 一个代理可能把 RAG 用作它的工具之一，但仅有 RAG 并不能让一个系统成为代理。
微调 — 微调在训练阶段调整模型权重。RAG 在推理时注入外部知识，而不修改模型。
检索 / 知识层 — 检索组件是 RAG 的一半。RAG 在纯检索之上增加了生成步骤。

常见问题

RAG 与微调有什么区别？

微调通过在专门数据集上训练模型，永久性地改变模型的权重。新知识成为模型自身的一部分。RAG 不触碰模型，而是在查询时供给相关文档。微调更适合教模型一种新的风格或任务格式；RAG 更适合让答案植根于新鲜、可验证的事实。许多生产系统会同时使用两者——微调模型处理语气和格式，而 RAG 提供最新的事实依据。

RAG 会让 LLM 更准确吗？

RAG 可以通过把模型的输出植根于检索到的证据来显著减少幻觉。然而，准确性取决于检索质量。如果检索系统返回不相关或过时的文档，LLM 可能产出自信却错误的答案——而且现在还有错误的证据支撑。RAG 提高了准确性的上限，但并不保证它。衡量检索的精确率和召回率，对任何严肃的 RAG 部署都至关重要。

什么是向量数据库？

向量数据库是一种专门的数据存储，被设计用来保存和搜索高维数值向量（嵌入）。当一个查询嵌入被提交时，数据库会执行相似度搜索——通常使用 HNSW 或 IVF 等算法——来找到最接近的匹配向量。这实现了语义搜索：按含义而非精确关键词匹配来查找文档。流行的向量数据库包括 Pinecone、Weaviate、Qdrant、Milvus 和 Chroma。

RAG 在加密 AI 项目中如何被使用？

加密 AI 项目使用 RAG 把 LLM 与区块链特定的数据连接起来：协议文档、治理提案、链上交易历史、实时价格源和智能合约源代码。检索层搜索这些专门的来源，使 LLM 能用当前数据回答特定领域的问题，而不是依赖过时的训练知识。此类系统的质量差异很大——从索引良好、经过整理的知识库，到几乎检索不到有用上下文的最小化配置。

RAG 能与链上数据协同工作吗？

可以。RAG 流水线中的检索层可以连接到区块链索引器、子图或链上分析 API。当用户询问钱包余额、交易历史或智能合约状态时，检索系统会获取相关的链上数据，LLM 则生成一段人类可读的解释。主要挑战在于延迟（区块链查询可能很慢）、数据格式化（原始链上数据必须被解析并分块以便嵌入）以及新鲜度（索引必须足够频繁地更新，以反映当前的链状态）。

另请参阅

外部参考

Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview