K5 · 什么是 RAG？它如何工作？ - Retrieval-Augmented Generation

所属知识库：Agent 全栈技术地图
所属领域：01 · AI
所属章节：04 · AI 如何获取和利用外部知识？ - Knowledge & Retrieval
文档类型：技术原理与工程实践研究
版本：v1.0
更新日期：2026 年 10 月 27 日
核心问题：RAG 为什么出现？它如何连接外部知识检索与模型生成？离线索引、在线查询、证据组织、引用与拒答分别如何工作？如何设计单轮、多轮和复杂任务 RAG，解决检索失败、证据冲突、权限、时效性和提示注入问题？如何实施、评估和运维一个可靠的 RAG 系统？

专题导读

当 AI 模型需要回答超出自身训练知识范围的问题，或者需要依据最新资料、专业文档和企业内部信息完成任务时，如何将外部知识与模型的语言理解和生成能力结合起来，就成为 AI 知识系统的重要技术问题。

本篇围绕 Retrieval-Augmented Generation（检索增强生成，RAG）展开研究，从模型参数知识的局限出发，解释 RAG 如何通过外部信息检索、证据组织和模型生成建立知识利用机制，并系统分析文档采集、解析与分块、索引构建、查询理解、候选召回、重排序、上下文构造和答案生成之间的技术关系。

在此基础上，进一步研究混合检索、查询改写、多跳检索、证据充分性判断、引用溯源与拒答机制，比较 Basic RAG、Advanced RAG、Modular RAG、Agentic RAG 和 Graph RAG 等不同架构的特点与适用场景。

在工程实践部分，通过企业内部制度问答系统案例，研究如何构建具有权限控制、版本管理、知识更新和质量评估能力的 RAG 应用，并分析检索失败、证据冲突、模型幻觉和提示注入等常见问题。

最后结合 Agent 与 Agent System 的实际需求，讨论如何将 RAG 封装为可复用的知识服务，使 Agent 能够在任务执行过程中主动获取、核验和利用外部信息，为后续 AI 知识库构建与检索质量评估建立基础。

一、研究概述：RAG 是一种知识利用架构，而非单个模型或数据库

检索增强生成（Retrieval-Augmented Generation，RAG）是一类将外部信息检索与生成模型结合的系统方法。用户提出问题后，系统从授权的信息来源中找到相关证据，将证据与问题组织成模型可处理的上下文，再由模型生成答案、解释或后续动作。其价值不是让模型“永久学会”检索到的内容，而是在当前任务中向模型提供可更新、可核查的外部信息。

在 K1 中，我们研究模型参数知识：模型通过训练获得能力，但参数不是可以直接逐条查询的事实数据库。在 K2 中，我们研究 Embedding 如何表示语义；K3 研究向量索引与数据库；K4 研究信息检索的完整流程。K5 的新增问题是：检索到内容以后，怎样让生成模型正确使用它？ 这要求研究证据选择、上下文构造、生成约束、来源归因、无答案处理和端到端质量，而不仅是搜索结果的相关性。

例如，用户问：“根据今年生效的差旅制度，外地出差住宿费上限是多少？”模型可能知道一般差旅报销规则，却不知道某公司的最新制度。RAG 系统需要识别“今年生效”“该公司”“住宿费上限”等约束，查找当前有效且用户有权访问的制度，核对适用城市与职级，必要时查找附表，然后给出带有条款来源的回答。若制度缺少关键条件，系统应追问或说明无法确定，而不是补造金额。

RAG 不等于向量数据库。 向量检索只是可选的召回手段；RAG 也可以使用 BM25、SQL、图查询、搜索 API 或多种方式组合。RAG 不等于知识库。 知识库涉及资料采集、版本、权限和维护，RAG 是利用这些资料完成任务的一种运行机制。RAG 也不保证事实正确。 检索错误、文档错误、上下文污染和模型误读都会传播到最终答案。

二、技术来源与概念边界

2.1 原始 RAG 研究的含义

Lewis 等人在 2020 年的《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中，将参数化的序列到序列生成模型与非参数化的外部文档记忆结合，并讨论 RAG-Sequence、RAG-Token 两类模型化方式。论文中的具体结构、训练方式和检索边际化公式，属于研究模型的实现；今天工程界常说的“RAG”，通常是更广义的“检索—上下文—生成”应用架构，不一定采用论文中的端到端训练或逐 Token 文档边际化。

因此要区分三层：第一，学术意义上的检索增强生成模型；第二，工程意义上的检索增强应用流水线；第三，在 Agent 中被调用的检索工具与多步证据工作流。三者共享“外部信息参与生成”的思想，但状态管理、训练方式、控制权与质量保障不同。

2.2 与微调、长上下文和联网搜索的区别

方法	改变模型参数？	信息如何进入任务	主要优势	主要限制
参数知识	通常不在单次推理时改变	训练时形成的参数与当前提示	不必每次检索	可能过时、来源难核验
微调 / 后训练	是	通过训练更新参数	改善行为、格式、领域能力	不适合频繁同步大量精确事实
长上下文直接输入	否	把资料直接放入上下文	简化少量资料的检索环节	成本、容量、位置效应与噪声
RAG	否（常规推理阶段）	先检索，再注入相关证据	更新灵活、可引用、范围可控	依赖检索和证据利用质量
联网搜索工具	否	动态搜索网页并读取结果	获取公开变化信息	来源质量、可访问性、时效与安全

联网搜索可以成为 RAG 的检索来源；长上下文可以与 RAG 结合；微调也可以用于改进检索器、重排序器或答案风格。它们不是互斥的产品类别。

三、RAG 的总体架构：离线数据路径与在线查询路径

一个可维护的 RAG 系统通常包含两条相互关联的数据路径。

离线/增量数据路径                          在线查询路径
文档、网页、数据库                         用户问题 + 身份/会话
       │                                           │
采集 → 解析 → 清洗 → 去重                    查询理解与约束提取
       │                                           │
分块 + 元数据 + 权限标签                       检索策略选择
       │                                           │
全文索引 / 向量化 / 结构化索引 ─────────────→ 候选检索
       │                                           │
版本与删除同步                                合并 / 过滤 / 重排序
                                                   │
                                            证据充分性检查
                                                   │
                                          上下文构造与引用映射
                                                   │
                                              模型生成
                                                   │
                                          证据核验 / 拒答 / 输出
                                                   │
                                         反馈、追踪与评估

离线路径决定系统“能够找到什么”；在线路径决定“面对当前问题找到什么、怎样使用”。两者的故障表现不同：索引缺失导致无法召回，查询误解导致搜错范围，生成模型忽视证据则导致“检索正确、回答错误”。排查必须保留分阶段记录，而不能只看最终答案。

3.1 离线侧的最小数据契约

一个可检索片段至少应保留：chunk_id、document_id、text、source_uri、title、document_version、updated_at、effective_at（如适用）、section_path、tenant_id、access_scope、index_version。其中，原始文档和可引用定位必须能追溯；只保存向量而丢弃原文，无法实现可信引用。

文档的更新与删除要能够传播到索引。删除原文但遗留旧向量，会产生陈旧检索和潜在的权限风险。多租户系统不能只在生成阶段隐藏无权内容：应在候选检索阶段实施可验证的访问控制，必要时再做结果复核。

3.2 在线侧的最小请求契约

查询请求除 question 外，还应传入身份与授权上下文、知识范围、时间约束、会话标识和输出要求。输出最好包括 answer、citations、status（answered / insufficient_evidence / needs_clarification）、retrieval_trace_id、使用的知识版本。证据引用应指向稳定的文档片段与版本，而不只是模型自行生成的标题。

四、文档准备：解析、分块与索引

4.1 为什么不能直接把 PDF 按固定字数切开

实际资料可能包含标题层级、表格、脚注、跨页段落、代码、图表、扫描图片和修订记录。简单的固定长度切分可能把“条件”和“结论”分开，或者将表头与数据行拆散。例如，“高级职级适用”出现在前一段，而住宿上限出现在下一段；检索只命中金额片段时，模型就可能错误泛化。

数据处理顺序通常是：先解析文件结构与内容，再按语义或结构分块，最后生成检索索引。分块策略包括固定 Token 长度、按标题段落、递归分割、句子边界、表格专用解析，以及父子块检索。不存在对所有语料都最优的块大小。

4.2 Chunk Size 与 Overlap 的取舍

较小块有利于精确匹配、降低无关上下文，却可能丢失前后条件；较大块保留上下文，但降低检索粒度、占用更多 Token。重叠窗口能减轻边界截断，却增加索引体积和重复命中。应该以“答案所需证据是否被完整召回”为核心评估，而不是只看向量相似度。

对于制度类资料，可先按“章节—条款—附表”结构切分，保留 section_path，检索命中细粒度片段后按需回溯父章节；对于代码库，可按函数、类和文件路径建立关联；对于研究论文，应保留图表标题、引用与页码。K6 将系统研究知识库数据工程。

4.3 文本、图片与表格的不同处理

多模态资料不应假定所有信息都能可靠转成纯文本。表格需要保留行列关系；图片可能需要视觉理解或图像 Embedding；扫描件依赖 OCR 或多模态解析，但识别错误应进入质量标记。检索系统可混合使用文本索引、结构化数据查询和多模态索引，生成阶段则需要能够核验的证据表示。

五、查询理解：用户问题不是检索指令的全部

用户问题通常包含隐含的范围、实体、时间、角色和任务目标。在线系统应尽可能将这些条件显式化。例如“上季度华东区渠道成本为什么上升？”可能需要明确季度范围、组织定义、成本口径以及对比基期，并且往往需要 SQL 汇总而非只检索文本段落。

常见查询处理技术包括：查询清洗与实体标准化、关键词扩展、同义词处理、基于会话的指代消解、查询改写、复杂问题拆解、时间条件提取，以及根据问题类型选择搜索源。查询改写可能改善召回，也可能把用户原意改坏，因此应保存原始查询、改写查询和对应检索结果，必要时采用并行多查询召回。

5.1 多查询与 HyDE

多查询检索会针对同一问题生成不同表达并合并结果，适合用户措辞与文档表达差异较大的情形，但会增加延迟与成本。HyDE（Hypothetical Document Embeddings）先生成一段假设性的相关文档，再将其编码为检索向量；假设文档不是证据，只能作为检索中间表示。若把它直接交给生成模型当作事实，会引入凭空编造的信息。

5.2 问题拆解与多跳检索

问题“某项政策修订后，哪些项目受影响，影响金额是多少？”可能需要先查政策修订、再查项目清单、最后查财务记录。一次 Top-K 召回不一定覆盖完整证据链。系统可以将问题拆为子问题，逐步检索并保留每一步的依据。这里的多轮检索可由固定工作流或 Agent 决策驱动，但应有最大轮数、预算和终止条件。

六、候选召回：检索器负责发现证据，不负责决定答案

6.1 稀疏检索、稠密检索与结构化查询

BM25 等稀疏检索适合精确术语、产品型号、编号、专有名词和词项匹配；Dense Retrieval 通过 Embedding 捕捉语义近邻，适合不同措辞描述同一概念的情况；SQL、图查询与元数据过滤适合精确条件、聚合、关系与授权范围。现代 RAG 常组合多种检索方法。

例如，“ERR_CONN_RESET 解决方法”可能更适合词项检索；“如何降低长对话带来的上下文成本”可能受益于语义检索；“2026 年 8 月之后生效的上海地区制度”必须优先处理时间与地域过滤。将所有问题都转成向量相似度查询，容易错过关键约束。

6.2 混合检索与融合

混合检索可以分别从 BM25 与向量索引取回候选，经过去重后使用 Reciprocal Rank Fusion（RRF）等方法融合排名。RRF 的典型形式为：

$$\mathrm{RRF}(d)=\sum _{r\in R}\frac{1}{k+{\mathrm{rank}}_r(d)}$$

其中 R 是多个排序列表，rank_r(d) 为文档在列表中的名次，k 为平滑常数。RRF 使用排名而非原始相似度，避免直接相加不同检索器不可比的分数。但它不能保证所有结果都正确，也不能代替权限、时间和事实核验。

6.3 检索 Top-K 不等于上下文 Top-K

检索器可以先取回较大的候选集合，例如 30—100 条，再经过重排序、去重和证据覆盖筛选，将少量高价值片段放入生成上下文。这里的数量只是可调的工程参数，并非推荐固定值。实际值应由语料规模、证据密度、上下文预算和离线评测决定。

七、重排序与证据选择：从“相关”到“足以回答”

第一阶段召回通常追求不漏掉关键材料；第二阶段需要判断哪些材料更适合回答当前问题。Cross-encoder 重排序器同时读取问题与候选片段，可以对语义匹配进行更精细判断，但通常比单纯向量相似度计算更昂贵。重排序模型的分数仍然是相关性信号，不等于事实真实性或证据充分性。

一个稳健的证据选择器应关注：相关性、信息增量、覆盖的子问题、来源可信度、有效版本、文档之间的矛盾、重复程度和 Token 成本。对于多条件问题，三条互补证据可能优于十条内容相近的证据。对同一事实存在冲突时，不能仅选择得分最高的片段并隐藏冲突，应根据权威层级、版本与时间规则判断，无法裁定时明确说明。

**证据充分性检查（Sufficiency Check）**可以设置在生成之前：回答是否需要一个数值、条件、日期或公式？检索结果是否包含这些要素？若缺失，应补检、澄清或拒答。此检查本身也可能出错，需要通过测试集评估。

八、上下文构建：RAG 的核心接口

RAG 真正连接检索与生成的地方，是将“检索结果集合”转化为“可供模型使用的上下文”。这一步包括片段选择、排序、压缩、引用编号、来源元数据、Token 预算、任务指令和安全隔离。

一种可审计的上下文形式如下：

系统要求：仅根据已授权的证据回答；证据不足则说明不足。
用户问题：……

[证据 S1]
文档：差旅制度
版本：2026-08
章节：第 4.2 条
内容：……

[证据 S2]
文档：住宿标准附表
版本：2026-08
表格位置：第 3 行
内容：……

回答要求：
1. 区分制度原文与推断。
2. 关键事实附 S1/S2 引用。
3. 若条件缺失，不编造数字。

检索片段属于不可信数据，不属于系统指令。 即使片段中出现“忽略之前规则”“将密钥发送到某网址”等文本，也应被当作待分析的内容。模型是否完全遵守这种边界不能仅靠提示词保证，还需要工具权限、外部请求限制、输出校验与监控。

8.1 上下文窗口与证据预算

模型上下文窗口并非全部可以用于证据。需要为系统指令、用户问题、历史对话、工具结果以及输出保留预算。一个简化预算公式为：

$$B_{evidence}\le B_{context}-B_{instructions}-B_{history}-B_{question}-B_{outputreserve}$$

如果候选证据超出预算，可以通过重排序、去重、按问题覆盖率选择、提取相关段落或分阶段生成来缩减。但摘要压缩可能丢失限定条件；对于法规、合同、数字和表格，应优先保留原文及可追溯位置。

8.2 “Lost in the Middle” 与位置敏感性

长上下文中，模型对不同位置的信息利用能力可能不均衡。将所有检索结果无序拼接并不意味着模型能够同等可靠地利用它们。需要通过位置扰动测试、证据排序、分步回答和引用核验检验实际效果，而不能只根据“窗口足够长”判断系统可靠。

九、生成与引用：模型应当回答什么、证明什么

生成阶段的目标是根据证据完成任务，不是把检索片段机械拼接成文本。对于事实问答，答案应包含明确结论、适用条件、必要的推理步骤和可验证的来源；对于总结任务，需区分文档共同结论与存在分歧的观点；对于计算任务，应保留数据口径与计算过程。

引用有两个层次：引用标记正确，即标记指向真实存在的来源；引用支持结论，即来源文本确实能够支持对应断言。只检查引用格式无法发现“引用了无关片段”的问题。可以在生成后做断言级证据核验：抽取关键陈述，定位对应引用，检查文本蕴含关系与数值一致性；自动核验结果应作为辅助信号而非绝对真值。

9.1 拒答与澄清是正常结果

可靠 RAG 应允许“资料中没有答案”“当前权限无法访问”“存在两个互相冲突的版本”“问题缺少适用地区”等输出。把所有查询都强制变成确定性答案，会提高幻觉风险。拒答策略需平衡漏答与误答，并通过有答案、无答案、证据冲突和权限不足等测试集校准。

9.2 不要把模型生成的内容反写为事实

模型生成的摘要、假设或中间分析可以作为任务缓存，但在未经审核前，不应自动写回权威知识库并作为后续检索的事实来源。否则错误会在“生成—入库—再次检索”的循环中被放大。知识入库应保留来源、审核状态和更新责任人。

十、RAG 架构的主要变体

10.1 Naive / Basic RAG

典型流程是文档分块、向量化、Top-K 检索、拼接上下文和生成。它结构简单、易于构建原型，适合语料清晰、问题直接、对权限和复杂推理要求较低的场景。常见问题是分块不合理、召回不足、上下文冗余、证据冲突与引用失真。

10.2 Advanced RAG

在基础流程中增加查询改写、混合检索、重排序、父子块、元数据过滤、证据压缩、引用检查和评估反馈。这些组件各自带来收益与成本，应通过消融实验确认必要性，而不是机械堆叠。

10.3 Modular RAG

将数据源、检索器、排序器、证据组装器、生成器和评估器拆成可替换模块，便于按任务选择策略、进行版本管理和灰度发布。模块化的核心价值是可测试与可维护，不代表一定需要微服务拆分。

10.4 Iterative / Multi-hop RAG

系统根据中间结果继续提出检索请求，适合跨文档推理、比较与调查。需要记录每一跳的问题、证据与推理依据，设置检索次数和预算上限，并避免模型依据未核实的中间猜测无限扩展搜索。

10.5 Agentic RAG

Agent 可自主决定是否检索、检索哪个来源、何时继续搜索以及何时结束。它增强了复杂任务的灵活性，同时引入工具调用错误、执行路径不确定、权限扩张、循环和成本失控等风险。Agentic RAG 的检索器仍应提供结构化结果与来源标识，Agent 的决策过程应接受观测与治理。它属于 RAG 与 Agent 编排的交叉区域，具体 Agent 设计将在后续章节展开。

10.6 Graph RAG 与结构化知识

对于实体关系密集、需要全局主题归纳或跨多条关系推理的问题，可以利用知识图谱、实体关系索引或图聚合策略辅助检索。但“Graph RAG”不是统一算法名称，不同实现差异很大。图构建、实体消歧和关系抽取会引入新的错误与维护成本；对简单 FAQ，传统检索往往更直接。

十一、工程案例：企业内部制度问答系统

11.1 业务目标与约束

假设某组织希望支持员工查询差旅、采购和财务制度。资料来源包括 PDF、Word、网页和结构化附表；文档会更新，不同岗位具有不同访问权限。目标是回答具体制度问题，提供可追溯条款，并在资料不足时澄清或拒答。

成功标准不应只写“回答流畅”。应包括：在授权范围内找出正确版本、覆盖问题需要的条款、引用可核验、无权内容不泄露、更新后旧版本不再误用、在目标延迟和成本预算内完成回答。

11.2 最小可行技术架构

数据侧：原始文件存储 + 解析与分块流水线 + 文档元数据库 + 全文索引 + 可选向量索引。查询侧：鉴权与租户过滤 + 查询理解 + BM25/向量召回 + 重排序 + 证据检查 + LLM 生成 + 引用校验。运维侧：索引任务日志 + 查询 Trace + 质量评估集 + 版本与删除同步。

对于数据规模较小的团队，可以先采用关系数据库及其全文检索能力、加上少量文档的精确扫描，验证需求后再引入专用向量基础设施。选择向量数据库应由召回质量、规模和运维约束驱动，而不是把它当作 RAG 的必要条件。

11.3 一个查询的逐步执行

用户：“上海地区高级职级员工，2026 年 9 月出差住宿费上限是多少？”

1. 身份层确认用户有权访问差旅制度及对应附表。
2. 查询解析出地区=上海、职级=高级、生效时间=2026-09、目标字段=住宿费上限。
3. 检索优先查制度目录和生效版本，再定位“住宿费”条款与地区/职级附表。
4. 重排序和证据检查确保同时获得适用规则、金额及例外条件。
5. 上下文保留原始表格行列信息和条款编号。
6. 生成器输出金额、适用条件和引用；若资料中没有“高级职级”的定义，则追问而非猜测。
7. 日志记录使用的文档版本、索引版本、引用 ID、延迟和结果状态。

这是一种教学设计，不代表任何真实公司的差旅制度或金额。

十二、可执行离线示例：从检索结果到有证据的回答

下面的代码不依赖网络和第三方模型，仅演示一个关键控制点：回答只能引用确实被选中的证据；证据缺失时必须返回不足状态。 它不是完整 RAG，也不模拟真实语义检索质量。

from dataclasses import dataclass

@dataclass(frozen=True)
class Evidence:
    source_id: str
    text: str
    authorized: bool = True


def select_evidence(items, required_terms):
    """教学示例：用词项包含模拟证据筛选；非生产级检索。"""
    return [e for e in items
            if e.authorized and all(term in e.text for term in required_terms)]


def grounded_answer(selected, claim):
    """不让示例程序自行编造事实：只输出证据中确实存在的声明。"""
    supporting = [e for e in selected if claim in e.text]
    if not supporting:
        return {"status": "insufficient_evidence", "answer": None, "citations": []}
    return {"status": "answered", "answer": claim,
            "citations": [e.source_id for e in supporting]}


def test_demo():
    docs = [Evidence("S1", "2026年上海住宿费标准为示例数值500元。"),
            Evidence("S2", "机密住宿费标准为示例数值900元。", authorized=False)]
    selected = select_evidence(docs, ["上海", "住宿费"])
    assert [e.source_id for e in selected] == ["S1"]
    result = grounded_answer(selected, "示例数值500元")
    assert result["status"] == "answered" and result["citations"] == ["S1"]
    assert grounded_answer(selected, "示例数值900元")["status"] == "insufficient_evidence"

if __name__ == "__main__":
    test_demo()
    print("3 assertions passed")

这个示例的价值在于展示“授权过滤—证据选择—断言支持—来源引用”的接口关系。真实系统还需要可靠的检索器、自然语言推理、版本规则、来源解析、断言级核验和安全测试。字符串包含不等于语义蕴含；生产系统不能据此判断答案真实。

十三、RAG 的典型失败模式与诊断

现象	可能原因	优先排查	改进方向
明明有资料却搜不到	解析遗漏、分块不当、索引滞后、查询不匹配	原文→块→索引链路、Recall@K	修复解析、混合召回、查询改写
搜到相关内容但答不出	证据不足、上下文截断、模型忽视条件	进入上下文的实际片段、答案覆盖	重排序、父子块、证据充分性检查
引用看似完整却不支持结论	引用映射错误、模型自行拼接	断言与引用逐条比对	稳定引用 ID、生成后核验
使用过期制度	版本字段缺失、删除未同步	文档版本、生效日期、索引更新时间	时间过滤、版本优先级、增量同步
不同用户看到同一敏感资料	权限过滤过晚、缓存隔离失败	访问控制、缓存键、审计日志	检索前授权、租户隔离、负向测试
回答中执行了文档里的指令	提示注入、工具权限过宽	证据内容与工具调用 Trace	数据/指令隔离、权限最小化
延迟或成本失控	过量多查询、重复重排、上下文过长	分阶段耗时、Token 与调用次数	预算、缓存、分级检索、早停
复杂问题只回答一部分	多跳证据缺失、覆盖检查不足	子问题覆盖率	查询拆解、分步检索、证据集合选择

诊断时应区分 Retrieval Failure、Context Construction Failure 和 Generation Failure。只有把中间产物保存下来，才能判断应该优化索引、检索器还是生成提示。

十四、质量评估：不能只评最终答案

14.1 建立有代表性的评测集

评测集应覆盖直接事实问答、术语差异、精确编号、表格查询、多条件过滤、多跳推理、无答案、冲突版本、权限不足、长文档、过期资料和恶意文档指令。每个样本最好记录：问题、用户权限、目标知识版本、期望答案或判定规则、支持证据 ID、允许的拒答状态。

14.2 分阶段指标

检索阶段：Recall@K 衡量相关证据是否进入候选集；Precision@K 衡量前 K 个结果中的相关比例；MRR、nDCG 衡量排序表现。需要注意：相关片段标签的粒度必须与实际检索单位一致。

证据构造阶段：证据覆盖率、上下文噪声率、重复率、权限违规率、版本正确率、证据 Token 成本。可以评估“回答所需的全部事实是否进入上下文”，而不是只看是否检索到一条相关段落。

生成阶段：答案正确率、事实支持度（faithfulness / groundedness）、引用精确度、完整性、拒答正确率、冲突处理质量。自动 LLM-as-judge 可能有偏差，应使用人工标注样本校准，并对数值、日期、法规等高风险事实设置确定性校验。

系统阶段：端到端任务成功率、P50/P95 延迟、检索调用次数、每次成功回答成本、索引新鲜度、权限事件和可用性。优化一个阶段的局部指标不一定提高整体任务成功率。

14.3 消融实验与版本管理

采用固定评测集，对比“仅 BM25”“仅向量”“混合召回”“混合 + 重排序”“加入查询改写”“加入证据核验”等配置，记录质量、延迟和成本变化。应固定文档快照、索引版本、Embedding 模型、生成模型、提示词与采样设置；否则实验结果难以归因。

线上 A/B 需要考虑用户流量差异、数据更新和安全门槛。对知识类系统，离线回归测试是发布前必要步骤，但不能代替真实用户反馈。

十五、安全、权限与数据治理

15.1 Prompt Injection：检索文档不是可信指令

外部文档、网页、邮件和搜索摘要可能包含诱导模型泄露信息、修改任务或调用危险工具的文本。RAG 应把检索结果作为低信任数据，通过明确的信任边界、工具调用授权、输出验证和敏感操作审批降低风险。仅在提示词中声明“忽略恶意指令”并不足以建立安全保证。

15.2 权限与多租户隔离

检索前应限制可搜索的知识范围；索引或数据库必须支持可靠的租户/文档权限过滤。对缓存、重排序器输入、日志、引用链接和结果摘要也要实施同等隔离。尤其要测试“用户有权看到摘要但无权看到原文”“文档权限刚被撤销”“共享缓存命中其他租户结果”等边界。

15.3 数据保留与合规

需要定义原始文件、解析文本、Embedding、查询日志和生成答案的保留周期；处理删除请求时同步清理相关索引和缓存。Embedding 不是天然匿名化的数据形式，不能因为它是向量就忽略敏感信息风险。对外部模型 API 发送检索片段前，应检查数据处理协议、驻留要求和组织政策。

十六、性能与成本：优化的是成功任务，而不是单次检索

RAG 的端到端延迟可近似拆为：

$$T_{total}\approx T_{auth}+T_{query}+T_{retrieve}+T_{rerank}+T_{context}+T_{generation}+T_{verify}$$

并行检索可以使部分阶段重叠，实际耗时并非永远简单相加。成本则包括离线解析与向量化、索引存储、在线查询、重排序模型、生成模型 Token、日志与运维。对于频繁更新的大规模知识库，离线重建成本可能很重要；对于低并发高复杂度任务，生成和多轮检索可能是主要成本。

优化策略应先通过 Trace 定位瓶颈，再考虑缓存热门查询、增量索引、分层检索、候选数量调优、按需重排序、上下文去重和早停。不应为了降低 Token 数量而删除答案必需的限定条件。最有意义的指标是“在质量和权限约束下，每次成功任务的总成本”。

十七、与 Agent 和 Agent System 的关系

在普通 RAG 应用中，检索策略往往由固定流水线决定；在 Agent 中，模型可能先判断信息缺口，再选择搜索工具、制定查询、比较来源并继续行动。两者共享检索、证据与引用基础，但 Agent 增加了自主决策、循环控制、状态管理和工具权限问题。

建议把 RAG 能力封装为明确的知识服务接口，例如 search(query, filters, top_k)、fetch(source_id, version)、answer(question, scope, policy)。其中 search 返回证据而非结论，fetch 返回可核查原文，answer 才负责生成带引用的回答。这样可以避免把检索逻辑、生成逻辑和 Agent 的任务规划混为一体。

跨多个 Agent 共享知识时，必须保留调用身份、授权范围、知识版本和来源标识。不能因为多个 Agent 属于同一工作流，就默认拥有相同的数据权限。Agent Memory 与 RAG 的区别在于：Memory 还需要决定什么信息值得保留、何时更新或遗忘，以及记忆与当前任务状态的关系；RAG 主要提供按需获取和利用外部信息的机制。

十八、实施路线：从最小闭环到可治理系统

阶段一：建立基线。 选择明确语料和 30—100 条具有代表性的问题（数量是项目设计示例），先实现文档解析、BM25 或简单向量召回、证据拼接与带引用回答，建立人工核验集。不要在缺少基线时直接叠加复杂框架。

阶段二：修复检索质量。 记录检索失败样本，优化分块、元数据、版本、混合检索和重排序。对每项新增组件进行消融测试，确认质量收益超过延迟与运维成本。

阶段三：增强证据可靠性。 引入证据充分性判断、拒答、引用映射与断言级核验，覆盖无答案、冲突版本、表格和多跳场景。

阶段四：生产化。 加入权限隔离、索引增量更新、审计日志、可观测性、故障降级、成本预算和发布回滚。

阶段五：Agent 集成。 将检索与文档获取封装为工具，支持按任务选择知识源、多轮检索和结构化证据传递，同时限制调用次数、时间和权限。

阶段顺序可根据业务风险调整。涉及敏感资料时，访问控制不是“第四阶段才做”的附加功能，而应在原型阶段就进入设计。

十九、常见误解与边界判断

误解一：“有向量数据库就有 RAG。” 向量数据库提供相似性检索，不能自动完成查询理解、证据选择、生成与引用。

误解二：“RAG 能解决幻觉。” RAG 可以提供外部证据并改善某些知识任务，但错误检索、错误资料和模型误读仍会造成幻觉。

误解三：“Top-K 越大，答案越准确。” 更多候选可能改善召回，也可能引入噪声、冲突与上下文成本；需要评测。

误解四：“模型给出引用就证明回答正确。” 引用可能不存在、指向错误位置或无法支持对应陈述，必须核验。

误解五：“RAG 一定比长上下文便宜。” 取决于语料大小、请求频率、索引成本、检索次数、模型价格和上下文策略。

误解六：“所有知识都应该 Embedding。” 精确表格、数值聚合、时间筛选和关系查询往往更适合结构化方法。

误解七：“Agentic RAG 总是更先进。” 自主检索增加灵活性，也增加延迟、成本、可测试性和权限风险；简单任务优先选择简单可控的流程。

二十、研究总结与后续专题

RAG 的核心不是某个流行框架，而是一条能够接受检验的证据链：从可靠资料出发，经过正确索引与检索，将适用证据交给模型，并验证最终输出确实得到证据支持。 这一过程既包含信息检索技术，也包含模型上下文工程、数据治理、安全与评估。

通过本篇，应能回答：为什么需要 RAG；检索器、重排序器、上下文构造器与生成器分别负责什么；为什么检索相关不等于回答正确；如何处理无答案、冲突、权限与更新；怎样通过分阶段指标定位问题；如何将 RAG 作为 Agent 可调用的知识能力。

下一篇 K6 · Knowledge Base 将从“单次检索增强回答”扩展到“持续维护可用知识资产”，系统研究数据来源、采集、解析、知识组织、索引、版本、更新、权限与生命周期。随后 K7 · Retrieval Evaluation 将进一步建立检索与回答质量的完整评估体系。

二十一、参考文献与延伸阅读

以下优先列出原始论文与经典研究。链接提供可追溯的研究入口；具体供应商 API、框架版本和部署参数应在实际实施时重新核验。

1. Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS. https://arxiv.org/abs/2005.11401 —— RAG 原始代表性研究，区分参数化与非参数化记忆。
2. Karpukhin, V., et al. (2020). Dense Passage Retrieval for Open-Domain Question Answering. EMNLP. https://arxiv.org/abs/2004.04906 —— 双编码器稠密检索的基础研究。
3. Robertson, S., & Zaragoza, H. (2009). The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in Information Retrieval. https://doi.org/10.1561/1500000019 —— 稀疏词项检索的理论基础。
4. Cormack, G. V., Clarke, C. L. A., & Büttcher, S. (2009). Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods. SIGIR. https://doi.org/10.1145/1571941.1572114 —— 多检索器排名融合方法。
5. Nogueira, R., & Cho, K. (2019). Passage Re-ranking with BERT. arXiv:1901.04085. https://arxiv.org/abs/1901.04085 —— Cross-encoder 重排序研究。
6. Gao, L., et al. (2022). Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE). https://arxiv.org/abs/2212.10496 —— 假设文档嵌入用于检索的研究。
7. Liu, N. F., et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics. https://arxiv.org/abs/2307.03172 —— 长上下文信息位置效应研究。
8. Gao, Y., et al. (2023/2024). Retrieval-Augmented Generation for Large Language Models: A Survey. https://arxiv.org/abs/2312.10997 —— RAG 体系与演进综述。
9. Es, S., et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. https://arxiv.org/abs/2309.15217 —— RAG 自动化评估的代表性研究。
10. Manning, C. D., Raghavan, P., & Schütze, H. (2008). Introduction to Information Retrieval. Cambridge University Press. https://nlp.stanford.edu/IR-book/ —— 检索、索引和评价基础教材。
11. Edge, D., et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. https://arxiv.org/abs/2404.16130 —— 基于图结构的全局主题归纳研究。
12. Asai, A., et al. (2023/2024). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. https://arxiv.org/abs/2310.11511 —— 检索、生成与自我评估的研究路径。

二十二、研究声明

研究与验证说明： 本文是技术原理与工程实践研究稿，基于经典信息检索与 RAG 原始论文、通用工程方法及此前 K1—K4 的研究脉络整理。企业制度问答案例和金额均为教学假设，不代表真实机构制度。代码示例是离线的证据筛选与引用控制演示，不是完整 RAG 系统，不包含真实 Embedding、向量数据库或语言模型调用。本文不将字符串匹配视为语义蕴含或事实核验。

最新性状态： 研究日期为 2026 年 10 月 27 日。本文所列论文和经典机制具有可追溯出处；本次未逐一在线核验所有论文页面、现行产品文档、框架版本及供应商接口。涉及最新 API、产品功能、许可协议、模型能力和部署配置的实际使用，应以对应版本的官方资料为准。

实验与测试边界： 本文未进行真实模型 API 调用、向量数据库部署、线上 A/B 测试、生产压力测试或安全渗透测试。文中离线 Python 示例已在本地执行，3 项断言通过；示例参数、架构与实施阶段仅用于解释工程决策，不构成可直接上线的生产配置。RAG 的可靠性需针对具体数据、权限、任务与模型进行独立验证。