什么是 RAG？

引言

大语言模型（LLM）具备强大的自然语言生成能力，但其参数化知识受限于静态的预训练语料，无法自动获取最新信息或企业私有知识，在缺乏依据时还容易产生事实幻觉（Hallucination）。检索增强生成（Retrieval-Augmented Generation，RAG）通过在生成阶段引入外部知识检索来解决这一局限。

当用户发起查询时，RAG 系统先从外部数据库或文档库中检索与问题相关的资料片段，再将这些片段作为补充上下文连同用户问题一起送入 LLM。模型据此生成有据可查、时效性更强且贴合业务语境的回答，无需重新训练即可动态利用训练数据之外的领域知识。

本课涵盖 RAG 的核心概念组件、朴素 RAG（Naive RAG）标准链路、架构设计模式、适用边界，以及工程落地中的核心取舍。

RAG 的核心概念组件

现代 RAG 系统由四个紧密配合的概念层组成，分别负责知识的粒度抽象、事实约束、语义对齐与上下文动态组装：

• 检索抽象层（Retrieval Abstraction）：检索器对外部知识进行抽象，根据查询需求选择合适大小和语义层级的内容。RAG 框架将知识库中的数据划分为有语义意义的单元，例如文本段、章节或事实，为它们建立索引，再检索相关内容。这种抽象可以在多个层级上进行，例如根据需求检索整篇文档或其中一个文本段。选择合适的层级至关重要：检索单元过小，可能需要获取大量片段，导致重要信息被大量内容淹没；检索单元过大，则可能把无关或重复内容一起送入 LLM 的上下文。
• 事实依据（Factual Grounding）：RAG 的核心目标是让模型输出严格锚定在可验证的外部证据上，降低无依据编造的概率。在设计良好的 RAG 系统中，回答里的每项关键事实都应能回溯到具体的检索片段，便于下游用户或审计系统核验引用来源。需要注意，事实依据的可靠性完全取决于底层语料库的质量——如果知识库本身存在过期或错误记录，模型同样会忠实地复述错误。因此，持续维护检索语料库的完整性与准确性是 RAG 生效的前提。
• 表征对齐（Representation Alignment）：检索器召回信息的标准必须与生成器消费信息的需求保持一致。用户提问的表达方式往往与文档库中的陈述方式存在差异，单纯字面或浅层语义相似的片段，未必包含回答问题所需的实质证据。为弥合查询与文档之间的表征鸿沟，工程上常采用查询改写（Query Rewriting）（将用户原始提问改写或扩充为更贴近文档表述的检索词）与嵌入模型微调（Embedding Fine-tuning）（调整向量空间分布，拉近问题与对应答案片段的距离）。
• 动态上下文注入（Dynamic Context Injection）：系统在每次推理请求到达时，实时检索并筛选所需证据，按特定结构（例如在问题前插入“以下是相关参考摘录：”及对应文本块）动态拼接到提示词中。这种机制赋予了系统极高的灵活性：同一个基础模型只需切换挂载的检索库即可服务于不同业务领域；每次仅注入与当前查询高度相关的片段，提高了有限上下文窗口的利用率；知识库一旦更新，新内容在下一次查询时即可立即生效，无需微调模型权重。

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

朴素 RAG（Naive RAG）架构

检索组件拆解

F．分块（Chunking）

定义：将外部长文档切分为大小适中、语义相对完整的文本片段，以便构建向量索引并按需召回。

推荐做法：

• 权衡分块大小：小分块语义聚焦、定位精准，但容易丢失前后文语境；大分块上下文完整，但可能混入无关内容、稀释核心语义，需结合具体任务与评估结果确定尺寸。
• 选择窗口策略：对上下文连贯性要求高时，采用带重叠区的滑动窗口（Sliding Window）；段落边界清晰时，可采用无重叠的滚动窗口（Tumbling Window）。
• 父子检索：除主要结果外，可以检索相关或具有层级关系的分块，丰富上下文。

常见问题：

• 分块过小，丢失有意义的上下文。
• 分块过大超出模型的有效注意力集中区间，拉低检索相关性。

C．嵌入模型选择（Embedding Model）

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

推荐做法：

• 匹配垂直领域语义：根据语种与专业领域评估模型表现（如开源 SentenceTransformers 系列或商用嵌入模型）。
• 上下文嵌入：上下文敏感性特别重要时，采用上下文嵌入模型。

常见问题：

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

D．向量数据库（Vector Database）

定义：持久化存储高维向量与关联元数据，并提供低延迟的相似性检索能力。

推荐做法：

• 按规模与生态选型：结合数据量级、QPS 要求与运维能力，选择 Qdrant、Weaviate、Pinecone 等成熟向量数据库。
• 托管方式：根据扩展需求与安全要求选择云托管或自行托管。云托管可以简化扩展，自行托管可以加强对部署环境的直接控制；安全性仍取决于具体配置和管理。
• 精细化管理元数据：随向量一同存储时间戳、文档 ID、来源路径、权限标签等字段，支撑检索前过滤（Pre-filtering）与检索后过滤（Post-filtering）。
• 索引策略：优化查询性能，兼顾准确性与检索速度。

常见问题：

• 数据库选型与实际并发或数据规模不匹配，引发生产性能瓶颈。
• 忽视元数据管理，影响检索效率。

E．向量搜索（Vector Search）

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

推荐做法：

• 相似性指标：根据数据类型和场景选择余弦相似度、点积、欧氏距离等指标。
• 规划过滤与检索顺序：根据过滤条件的选择性高低，决定采用先元数据过滤再向量检索（Metadata-first），还是先近似最近邻搜索再过滤（ANN-first）。
• 混合搜索：结合语义搜索和词法搜索，提高准确性。

常见问题：

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

G．检索启发式规则（Retrieval Heuristics）

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

推荐做法：

• 时间衰减与时效加权：在新闻、政策或迭代文档场景下，优先提权最新发布的资料或匹配目标时间窗口的文档。
• 多样性排序：保证结果具有多样性，减少重复上下文。
• 来源核验：优先考虑可信或权威来源。

常见问题：

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

生成组件拆解

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

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

推荐做法：

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

常见问题：

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

B．提示词工程（Prompt Engineering）

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

推荐做法：

• 明确要求的回答格式。
• 清楚说明如何整合检索信息。
• 加入防范提示词注入（Prompt Injection）与越狱攻击的安全边界指令。

常见问题：

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

持续反馈循环

• 基于生产环境监测与评估数据，持续迭代分块粒度、嵌入模型、检索启发式规则及提示词模板。
• 定期检查检索与生成策略，使二者有效配合，并检查回答的事实依据。

RAG 系统的架构设计模式

• 组件的模块化组合（Modular Composition） RAG 将检索器与生成器解耦为独立模块，二者通过“检索到的文本上下文”这一标准接口交互。得益于这种解耦设计，团队可以独立升级向量数据库或替换嵌入模型，而无需重新训练生成端 LLM。在实际工程中，标准链路还可灵活插拔更多模块：用于补充字面匹配的关键词检索模块、对粗召回结果精排的重排序（Reranker）模块、整合多文档信息的融合模块，以及负责格式化与分支判定的路由模块。当底层知识源从静态文档迁移至关系型数据库，或需要在生成前新增一步长文摘要提取时，只需局部替换或串联对应组件，便于独立开展检索缓存与局部微调。
• 参数化记忆与外部记忆分离：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 设计需要根据任务管理这些取舍。

把企业知识加入 RAG

课程演示链路从飞书新版文档（docx）、旧版文档及多维表格中读取已授权的企业资料，经过文本分块与独立配置的 embedding 服务向量化后存入 Qdrant。在线查询时，请求必须携带服务端校验过的真实用户身份，先按用户权限过滤出可读资料范围，再执行检索、组装引用并生成答案。遇到目标资料缺失、未知文档块类型或权限状态不明的情况时，系统必须明确返回原因说明并立即停止引用该来源，严禁跳过权限检查或猜测内容。

练习：记录本课使用的配置、测试输入、预期输出与异常失败分支，并使用脱敏数据完整复现流程。