什么是 RAG？

引言

大语言模型（LLM）极大地提升了自然语言处理能力，能够生成流畅、连贯的文本。不过，它们仍面临一些挑战，例如训练数据带来的知识有限且相对静态，以及容易生成不准确或编造的事实。检索增强生成（Retrieval-Augmented Generation，RAG）通过在生成过程中结合 LLM 与外部知识源，应对这些问题。

在 RAG 系统中，用户发起查询后，系统从外部数据库或文档集中检索相关信息，再将这些信息作为补充上下文提供给 LLM。这样，LLM 可以生成更准确、更新且更符合上下文的回答。RAG 让模型能够访问初始训练数据之外的最新信息和领域知识。

本课介绍 RAG 的核心组件、采用 RAG 的动机、系统内部的信息流、重要设计事项、适用场景，以及有效实现 RAG 所需的取舍。

RAG 的核心概念组件

现代 RAG 系统包含若干概念组件，共同完成信息检索、语义匹配，以及将信息以可用形式注入模型上下文的过程。核心组件包括：

• 检索抽象层（Retrieval Abstraction）：检索器对外部知识进行抽象，根据查询需求选择合适大小和语义层级的内容。RAG 框架将知识库中的数据划分为有语义意义的单元，例如文本段、章节或事实，为它们建立索引，再检索相关内容。这种抽象可以在多个层级上进行，例如根据需求检索整篇文档或其中一个文本段。选择合适的层级至关重要：检索单元过小，可能需要获取大量片段，导致重要信息被大量内容淹没；检索单元过大，则可能把无关或重复内容一起送入 LLM 的上下文。
• 事实依据（Factual Grounding）：RAG 的主要目的之一，是让生成模型的输出以检索证据为依据。明确使用可验证文本作为生成条件，有助于降低无依据内容的出现概率，使回答更符合已知事实。在设计良好的系统中，理想情况下，答案中的每项重要事实都能追溯到检索上下文。这也提高了透明度，下游用户或系统可以检查模型使用的来源，因此 RAG 常用于需要证据或引用的应用。前提是外部知识包含正确事实；语料过时或有误时，模型也可能复述这些错误。因此，检索语料库的完整性和正确性十分重要。
• 表征对齐（Representation Alignment）：检索器查找信息的方式，需要与生成器使用信息的方式紧密配合。查询与检索文档应在含义上相符，文档还应提供 LLM 回答问题所需的信息。内容虽然相关，却不能直接帮助回答问题时，生成质量仍可能不佳。改进方法包括查询改写，即修改或扩展问题，使其更贴近文档内容；以及嵌入微调，即调整嵌入表示，使查询与文档在语义上更加接近。目标是检索恰当信息，并以 LLM 容易使用的形式提供。
• 动态上下文注入（Dynamic Context Injection）：RAG 在查询时将外部上下文动态加入模型输入，每次查询都会即时确定需要使用的证据。系统可以根据用户请求灵活获取不同数据，使回答符合具体情境。有效注入需要控制信息量及组织方式，例如在用户查询前加入“以下是一些相关摘录：”，随后提供相关文本。它具有适应性，同一个模型可以服务多个领域，每次使用的领域知识由检索内容决定；也具有针对性，只加入预计相关的信息，提高有限上下文空间的使用效率。新信息可以在推理时直接检索并加入输入，从而立即影响回答，无须重新训练模型。

这些组件共同工作：检索器抽象并选择知识，事实依据支持模型根据证据回答，表征匹配使检索与生成在语义上协调，动态注入则将这些信息组织为模型输入。

朴素 RAG（Naive RAG）架构

检索组件

F．分块（Chunking）

定义：将外部知识划分为较小、易于管理的片段，以便有效检索和使用。

推荐做法：

• 分块大小：较小的分块定位准确，但上下文可能不完整；较大的分块信息更充分，但可能稀释相关内容，需要根据任务进行取舍。
• 窗口策略：根据上下文连续性要求，选择有重叠的滑动窗口，或者没有重叠的滚动窗口。
• 父子检索：除主要结果外，可以检索相关或具有层级关系的分块，丰富上下文。

常见问题

• 分块过小，丢失有意义的上下文。
• 分块过大，超出模型有效关注的范围，并降低相关性。

C．嵌入模型选择

定义：选择适当的嵌入模型，为查询和上下文生成向量表示。

推荐做法：

• 语义相关性：选择适合业务领域的模型，例如 SentenceTransformers 或 OpenAI 嵌入模型。
• 上下文嵌入：上下文敏感性特别重要时，采用上下文嵌入模型。

常见问题：

• 模型与业务领域匹配程度较低，影响检索准确性。
• 忽视上下文嵌入，限制语义理解能力。

D．向量数据库

定义：高效存储和管理向量表示，支持快速检索。

推荐做法：

• 数据库选择：根据规模与性能要求，选择支持完善的向量数据库，例如 Weaviate、Pinecone、Qdrant。
• 托管方式：根据扩展需求与安全要求选择云托管或自行托管。云托管可以简化扩展，自行托管可以加强对部署环境的直接控制；安全性仍取决于具体配置和管理。
• 元数据管理：保存时间戳、文档 ID、来源等有用信息，支持检索前过滤和检索后过滤。
• 索引策略：优化查询性能，兼顾准确性与检索速度。

常见问题：

• 数据库选择不合适，造成性能问题。
• 忽视元数据管理，影响检索效率。

E．向量搜索

定义：根据语义相似性检索相关信息。

推荐做法：

• 相似性指标：根据数据类型和场景选择余弦相似度、点积、欧氏距离等指标。
• 查询路径：根据查询特征，决定优先进行元数据过滤（metadata-first），还是优先进行近似最近邻搜索（ANN-first）。
• 混合搜索：结合语义搜索和词法搜索，提高准确性。

常见问题：

• 使用不合适的相似性指标，降低检索准确性。
• 忽视混合搜索，错过改善准确性的机会。

G．检索启发式规则

定义：通过具体业务规则或条件引导检索。

推荐做法：

• 时间重要性：优先选择较新的信息，或者与目标时间范围相关的信息。
• 多样性排序：保证结果具有多样性，减少重复上下文。
• 来源核验：优先考虑可信或权威来源。

常见问题：

• 忽视启发式规则，得到无关或过时的上下文。
• 多样性不足，导致上下文重复。

生成组件

A．选择大语言模型（LLM）

定义：选择最适合任务的生成模型，以获得准确、符合上下文的回答。

推荐做法：

• 从领域知识、生成准确性、延迟和推理成本等方面评估模型。
• 选择上下文长度适合任务的模型。

常见问题：

• 模型缺乏足够的领域理解能力，或者上下文长度不足，影响答案准确性。

B．提示词工程

定义：设计有效的提示词，引导模型回答。

推荐做法：

• 明确要求的回答格式。
• 清楚说明如何整合检索信息。
• 采用防范越狱攻击的技术，保障模型安全。

常见问题

• 过度依赖检索上下文，忽视提示词的设计。
• 忽视安全要求，使系统可能被滥用。

反馈循环

• 根据监测结果，持续完善分块、嵌入、检索启发式规则和提示词。
• 定期检查检索与生成策略，使二者有效配合，并检查回答的事实依据。

RAG 系统的架构设计模式

• 组件的模块化组合：RAG 架构具有模块化特征。检索器与生成器作为独立模块，通过检索文本这一明确接口交互，因此可以分别改进或扩展。例如，更换向量数据库或检索模型时，无须重新训练生成器。现代 RAG 流程还可能包含关键词搜索模块、优化检索结果的重排序模块、整合多份文档信息的融合模块，以及处理格式或决策路由的任务适配模块。这样可以提高可维护性和灵活性：知识源从文档库变为数据库时，可以替换或扩充检索模块；需要在生成之前整理检索文本的摘要时，可以加入相应模块。以检索器、排序器、生成器等模块组织设计，有助于构建可扩展系统，并独立进行检索结果缓存、检索器微调等优化。
• 参数化记忆与外部记忆分离：RAG 将模型内部知识与外部知识源分开管理。外部知识库，例如向量存储和搜索索引，保存可检索的事实；LLM 负责推理和组织信息。这可以类比 CPU 按需读取内存或磁盘中的数据：模型需要额外信息时，从外部存储进行检索。这样可以持续更新知识库，无须修改 LLM，特别适合需要实时知识的应用。数据集更新后，建立索引通常比重新训练或微调大型模型更加高效、经济。外部记忆也可以限定领域范围或设置访问权限，例如公司私有文档；应用通过访问控制和输出核验，管理哪些资料可以参与回答。许多企业级 LLM 应用出于治理需要采用这种设计。
• 自适应上下文组织：LLM 输入容量有限，需要有策略地筛选、排序或转换检索信息，提高其利用价值。例如，检索得到十篇文档，但上下文只能合理容纳三篇，就可以使用第二阶段的相关性规则选择最合适的子集，简单做法是取评分最高的 top-k 个文本段。上下文压缩可以把有用文本整理成摘要，在有限窗口中保留更多内容。上下文工程也可以通过指示模型忽略某些内容、关注特定信息来引导注意力。例如，重新排列检索内容，让重要事实出现在上下文开头；某些模型会因位置因素而更加关注开头的信息。也可以在每个文本块前添加标题或问题，明确它与当前任务的关系。组织方式还可以根据查询调整：定义类问题可以使用简短定义和较长解释，数值类问题可以只提供表格或数值列表。检索之后、生成之前的这一步优化，可以作为检索模块的后处理，也可以独立实现。它处理检索与 LLM 之间信息容量有限、内容可能包含干扰的问题。减少无关信息有助于提高答案质量，并降低模型受到干扰而产生幻觉的风险。

其他模式还包括迭代式检索与生成：模型在多轮交互中发起进一步检索，将复杂查询划分为多次“检索—阅读”循环。这些方法延伸了前面的设计原则，例如迭代式 RAG 仍使用模块化组件，并依据生成器输出调整下一次检索。模块化架构、记忆分离和上下文组织，是从头设计 RAG 系统时的重要指导原则，有助于维持可维护性、扩展能力及清楚的组件职责。

RAG 的适用范围

需要根据任务判断 RAG 能否带来明确收益，以及额外检索是否必要、是否可能影响效果。

适合采用 RAG 的场景

• 知识密集型查询，且数据持续变化：当查询需要最新事实，或者需要使用随时间变化的大型知识库时，RAG 尤其有用。开放域问答是典型场景，例如有关时事、近期科学发现或公司最新政策的问题。参数固定的 LLM 可能缺少这些知识，也可能产生幻觉；检索可以从当前数据源提供答案依据。在企业中，从产品手册查找答案的客服机器人、检索学术论文的研究助手等使用大型动态文档库的应用，都适合考虑 RAG。判断原则是：任务需要大量事实查询，而这些知识难以全部预先编码进模型时，RAG 很可能适用。
• 特定领域或自定义语料：当模型需要使用指定文档，例如律师事务所的法律文书库或医疗知识库时，可以按需检索，使回答有这些资料作为依据。整个语料库的微调可能受到规模或隐私条件限制，检索则支持追溯正式来源。例如，辅助医生的 LLM 在回答治疗问题时，可以检索医院内部指南或最新研究并引用相关依据。经过整理的知识源能够为领域回答提供可靠基础；领域正确性、资料权限与输出内容仍需要核验。
• 较高的可追溯性和证据要求：出于信任或监管要求，需要核验答案来源时，RAG 可以同时提供答案和支撑文本，方便人工检查。例如，助手可以回答：“根据文档 X，……（引用内容）……因此答案是 Y。”研究助手需要标注来源，客服答案需要指向知识库文章时，这种能力尤其适用。可检查的证据能让相关人员更容易理解和信任系统。
• 标注数据稀缺，但相关未标注文本丰富：如果任务缺少标注数据，却有大量相关的非结构化文本，RAG 可能比训练专用模型更加实用。这常见于智能助手或聊天机器人。让模型通过训练记住产品或政策信息，需要整理问答对或微调数据；RAG 可以直接检索产品文档，利用原始文本。其基础假设是答案存在于这些资料中，系统通过合适的检索与生成方法寻找并呈现答案，从而减少专门训练的需求。
• 结合外部工具的多步推理：复杂分析查询等任务可以采用智能体方法，规划多个步骤、调用工具并反复检索信息。信息检索作为工具时，RAG 能自然融入这个流程。例如，教学辅导系统可能需要查找参考材料，再回答学生问题。从架构上看，这是 RAG 或其扩展形式，把知识查询明确设置为推理中的一个步骤。需要分阶段使用外部知识时，可以考虑多轮 RAG。

当任务能否成功取决于获取正确信息，而模型内部未必掌握这些信息时，RAG 很有价值。适用场景包括开放域问答、企业知识助手、提供叙述式答案的搜索引擎、需要使用用户特定信息或个人喜好的个性化助手，以及其他重视事实依据的任务。

可能无需采用 RAG 的场景

• 任务所需信息已经充分：摘要、翻译、风格转换等文本处理任务，或者故事写作、开放式创意讨论等任务，可能已经从输入或通用知识获得所需信息。加入检索文本可能干扰模型，或者限制创作。例如，写一首描绘夕阳的诗，通常只需要模型理解相关概念和写作要求，检索百科资料的帮助有限。工程师需要判断查询是否确实依赖外部知识；如果直接调用 LLM 或使用任务专用微调模型已满足要求，这些方法通常更简单、快速。
• 范围有限、知识稳定的领域：领域知识变化较少时，可以通过提示词工程或任务适配满足需要。例如，只有固定的 100 条商品描述，需要围绕它们回答问题，而且这些文本能够放入上下文时，可以直接提供给模型。微调也可以用于适配任务行为，但知识能否准确保留需要单独评估。知识库规模较小、内容稳定且已有更简单的可行方案时，RAG 可能增加不必要的复杂性。
• 极低延迟或高度简洁的系统要求：RAG 比单次 LLM 调用增加了检索与上下文处理步骤，通常更复杂、耗时更多。例如，某些实时系统需要在几毫秒内响应，嵌入式设备可能计算资源有限，向量搜索及额外上下文处理的开销可能难以接受。增加向量数据库等组件，也会增加故障点和工程复杂性。如果更简单的方法已经充分满足产品要求，即使准确性略有差别，也值得考虑。速度、资源使用和系统简洁性具有最高优先级时，需要认真评估 RAG 的成本。
• 知识源不完整或不可靠：RAG 效果受外部资料质量限制。知识库缺少关键事实或包含大量干扰内容时，检索可能降低回答质量。模型经过广泛训练、内部已有相关知识时，质量较差的外部文本反而可能使回答出错。例如，模型原本掌握正确事实，却被检索到的错误材料误导。这时需要改善语料和检索，在检索可靠后再用于回答。外部知识系统的质量会直接影响整体表现。
• 创意与连贯性优先：长篇创作或复杂叙事任务中，加入零散事实可能破坏语言连贯性和作品风格。如果主要目标是形成风格一致的作品，事实准确性的优先级较低，可以更多依靠模型学到的知识表达和写作能力。例如，故事创作或哲学随笔通常可以直接生成。

RAG 主要解决外部知识获取和事实依据的问题。工程师应根据任务性质，比较 RAG、微调、更长上下文模型，以及直接使用基础模型等方案的能力和复杂性，选择适合具体需求的方法。

RAG 的设计取舍与挑战

RAG 提供新的能力，同时引入需要处理的成本、限制和设计取舍。

• 延迟与事实依据：每次向向量数据库或搜索引擎查询，都会增加流程耗时。模型已经能够充分回答的问题，可以直接生成以缩短延迟；需要外部依据的问题则可通过检索提高答案的可核验程度，同时承担额外时间成本。缓存常见检索结果、异步检索等方法可以减少开销。在聊天机器人中，即使增加一秒延迟，也可能影响体验。部分系统根据问题类型和复杂度动态路由：事实性问题使用 RAG，观点性或简单问题直接回答。复杂查询连续执行两三次检索与 LLM 调用时，即使答案有充分依据，延迟仍会增加。研究和工程实践因此持续改进检索器与索引方法，以缩短检索时间。
• 上下文容量与“迷失在中间”（Lost-in-the-Middle）效应：即使 RAG 有策略地控制提示词内容，上下文容量仍然构成限制。查询范围广或含义模糊时，选择哪些信息并不容易：信息太少，模型可能缺少答案依据；信息太多，则可能无法充分关注各个部分。模型有时更关注输入开头和结尾，对长上下文中间的信息利用不足。例如，输入 50 个文本段时，位于中间的内容可能对生成结果影响较小。RAG 常把用户查询放在一端、系统指令放在另一端，检索文本位于中间，因此需要注意这一现象。可能的解决方法包括分块和层级检索，例如检索整体摘要后继续获取具体内容；也包括使用长上下文模型，并通过近期内容优先机制（recency biasing）或位置重缩放（position-rescaling）等方法引导注意力。无关信息还会稀释上下文，即使只是部分内容与问题不符，也可能使模型沿着无关线索生成答案。上下文扩大时，选择和利用正确信息的难度也会增加，这正是长上下文模型仍需要检索和信息组织的重要原因。模型对长输入的有效利用程度需要通过评估确认。
• 多跳推理与系统复杂性：基础 RAG 每次查询执行一次检索。对于需要多跳推理的问题，可以一次检索较多信息，让模型在同一提示词中推理；也可以明确划分为多个“检索—生成”步骤，形成迭代式 RAG。前者可能需要搜索广泛文档，带来上下文容量和信息组合问题；后者通过“检索、获得部分答案、据此继续检索”的过程引导模型，可能提高效果，但需要更多运行组件和模型调用，也可能传播早期错误。支持更多跳数有助于处理复杂问题，但收益可能逐渐减小，系统复杂性也会增加。MultiHop-RAG 基准强调了检索并综合多份证据的需求，Hop RAG 等方法则使用类似图结构的检索处理跨文档关系。这些方法可能需要控制检索顺序的组件和问题分解模块。一个关键设计问题是何时结束检索，把剩余推理交给模型。例如，问题理论上需要五跳推理时，需要评估完整实现这种流程的价值，以及只提供部分资料让模型继续推理的效果。中间问题和输出还需要在用户对话中妥善管理。工程上可以限定显式处理两跳或三跳，将更长任务交给专用流程，具体上限应根据任务、模型和评估结果确定。随着模型推理能力提升，也可以利用它在内部组合已有证据；对准确性要求较高时，仍应评估显式多跳检索的可靠性与时间成本。
• 语义召回与精确匹配：基于嵌入的语义搜索可以广泛检索概念相关的信息，但有时得到的内容只是主题相关，缺少所需的确切事实，也可能遗漏与查询语义特征差别较大的关键文档。数值或代码片段查询就可能遇到这种情况。关键词精确匹配能够准确查找特定名称或短语，但可能遗漏使用其他措辞表达的信息。混合检索结合两种方法，例如用关键词过滤后按嵌入相似度排序，或者同时执行向量搜索和词法搜索，再合并结果。代码、精确公式或专有名词较多的语料，通常更需要精确匹配；语料主要涉及概念时，纯语义搜索也可能适用。语义搜索可能出现看似相关、实际上属于其他语境的假阳性结果；精确搜索可能因为措辞不同，出现未检索到相关资料的假阴性结果。设计时需要兼顾语义覆盖范围与精确匹配能力。
• 幻觉与答案整合：LLM 仍可能产生幻觉或忽略检索信息，因此需要检查答案是否真正使用证据，以及是否包含矛盾或无依据的陈述。完全遵循来源文本的回答可能不够自然，更流畅的回答也可能不够忠于检索文本，需要在事实准确性与表达质量之间进行取舍。

为答案提供依据可能改善准确性，同时增加耗时；更多上下文提供更多信息，也增加管理难度；多跳检索有助于复杂查询，同时增加系统复杂性和延迟；语义检索扩大覆盖范围，精确匹配则帮助定位具体内容。RAG 设计需要根据任务管理这些取舍。