Retrieval-Augmented Generation：RAG 原理
RAG 的关键不是给语言模型加一个搜索框，而是把模型参数中的隐式知识和外部可检索知识组合成一个可更新、可引用、可审计的生成系统。原论文把文档视为 latent variable：retriever 先给出候选 passages，generator 再在问题和证据条件下生成答案，并对多个候选文档路径进行概率整合。
Retrieval-Augmented Generation：RAG 的原理、价值与边界
本篇为经典论文精读（历史回顾/经典打底定位），机制正文以原论文为锚点；最新进展见文末「SOTA 检查」。
Source Anchors
- Original paper: https://arxiv.org/abs/2005.11401 （2020-05）
- NeurIPS 2020: Patrick Lewis et al.,
Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（论文 2020-05）
核心导读
RAG 的关键不是给语言模型加一个搜索框，而是把模型参数中的隐式知识和外部可检索知识组合成一个可更新、可引用、可审计的生成系统。原论文把文档视为 latent variable：retriever 先给出候选 passages，generator 再在问题和证据条件下生成答案，并对多个候选文档路径进行概率整合。
它的架构价值在于把知识治理从模型权重中拆出来：事实可以更新，来源可以追踪，权限可以过滤，版本可以回滚，评估可以分别覆盖检索和生成。现代企业 RAG 增加了 query routing、metadata filter、rerank、context packing、citation mapping 和 EvalOps，但核心取舍仍然是知识应该放在参数、上下文、索引、图谱还是工具中。
1. 这篇论文在解决什么问题
大语言模型有一种内置知识：训练数据被压缩进参数。论文称之为 parametric memory。它的优点是推理时不需要查外部系统；缺点也很明显：来源不可见，更新困难，事实可能过期，审计困难。
知识密集型任务恰好卡在这个矛盾上。开放域问答、事实解释、实体识别、政策说明、证据总结都需要外部事实。模型如果只依赖参数记忆，就会把“语言流畅性”误当成“事实可靠性”。
RAG 提出的核心问题是：
能不能把预训练生成模型的语言能力，和可检索、可更新的外部知识结合起来？
论文的回答是：把文档当作 latent variable。给定问题时，retriever 先从外部知识库找出可能相关的 passages；generator 再基于问题和这些 passages 生成答案；训练和推理时对多个候选文档进行概率整合。
2. 核心贡献
RAG 把 neural retriever 和 seq2seq generator 组合成一个端到端框架，让模型在生成答案时显式依赖可检索的 non-parametric memory，而不是只依赖模型参数里的隐式知识。
它的长期价值是奠定了现代企业 RAG 的基本抽象：问题、检索、证据、生成、引用、更新、评估、审计。今天的企业 RAG 系统远比原论文复杂，但核心逻辑仍然来自这篇论文。
3. Parametric memory vs non-parametric memory
3.1 Parametric memory
Parametric memory 是模型权重中的知识。模型可能知道“某个城市是某国首都”，不是因为它实时查了数据库，而是因为训练时见过类似文本，知识被压缩进参数。
这种记忆适合语言常识和稳定知识，却不适合企业事实：
- 不知道来源。
- 更新成本高。
- 很难删除特定知识。
- 难以按用户权限隔离。
- 无法证明答案基于哪个版本。
在金融零售里，如果模型回答“某类客户开户需要哪些 KYC 文件”，只靠参数记忆是不够的。合规要求会变，地区差异会变，产品政策会变，内部文件版本也会变。
3.2 Non-parametric memory
Non-parametric memory 是模型外部的可检索知识库。原论文使用的是 Wikipedia passages 的 dense vector index。企业场景中，它可以是政策库、SOP、产品手册、合同、监管规则、工单、案例库或知识图谱。
这种记忆的价值在于：
- 可以更新、删除和回滚。
- 可以保留来源、版本、生效日期和 owner。
- 可以按权限过滤。
- 可以为答案提供引用和审计证据。
RAG 的本质就是把语言模型的表达能力，接到一个可治理的外部记忆上。
4. 原始 RAG 架构
原论文里的 RAG 有两个主要组件。
Retriever 学习 p_eta(z | x)：给定输入 x，从外部文档集合中选出相关 passage z。
Generator 学习 p_theta(y | x, z)：给定输入 x 和检索到的 passage z，生成输出 y。
这里的 z 是 latent document。模型不是只认一个文档，而是在 top-K 检索结果上进行 marginalization，也就是把多个可能文档对答案的贡献加权合并。
用直觉说：
- 用户提出问题。
- Retriever 给出一组可能有用的资料。
- Generator 基于每份资料尝试生成答案。
- 模型把不同资料路径上的概率合并，得到最终输出。
这比“检索一个文档再让模型回答”更一般，因为它把检索不确定性纳入了生成过程。
5. RAG-Sequence 与 RAG-Token
论文提出两种形式。
5.1 RAG-Sequence
RAG-Sequence 假设整段输出主要由同一个 retrieved document 支撑。模型为每个候选文档计算生成整个答案的概率，再在文档维度加权。
直觉是：先为整段回答选择证据，再写出完整答案。
这更接近很多现代企业 RAG pipeline：检索若干段，拼成上下文，一次生成答案。它的优点是实现简单、引用相对清晰、工程稳定；缺点是多事实、多来源答案需要额外设计。
5.2 RAG-Token
RAG-Token 允许答案中的每个 token 基于不同文档分布生成。直觉是：答案的不同部分可以来自不同资料。
这适合多跳问题和跨文档综合，但工程解释性更复杂。企业系统通常不会真的逐 token 做引用，但应该吸收这个思想：每个关键事实点都要能追溯到自己的证据。
6. 为什么 RAG 有价值
6.1 把知识更新从模型训练中拆出来
如果知识只在参数里，更新知识往往意味着重新训练或微调。RAG 把知识放在外部索引里，更新资料、重建索引、调整 metadata，就能影响回答。
这对企业特别关键。政策、费率、流程、监管要求、产品条款、风险名单都在变化。把这些事实写进模型参数，不如放进可治理的知识层。
6.2 把事实依据显式化
原论文的目标不是企业引用系统，但它把 retrieved passages 作为生成条件，已经把“答案来自哪里”这个问题放到架构里。
现代企业 RAG 必须进一步工程化：不仅要检索证据，还要让关键断言绑定 source id、版本、页码、章节或字段。
6.3 降低纯生成模型的幻觉空间
如果正确证据进入上下文，generator 更可能生成 grounded answer。RAG 不会消灭幻觉，但它把问题从“模型凭记忆猜”变成“模型基于候选证据组织答案”。
这让错误更可诊断：是没检到、检错了、资料旧了、上下文冲突了，还是 generator 歪曲了证据。
6.4 让知识密集型任务可产品化
政策问答、KYC 文件判断、AML typology 解释、客户服务、信贷条款说明、合规审查，这些任务共同特点是：答案必须依赖外部资料，而且资料有版本、权限、适用范围。
RAG 给这些场景提供了基础架构语言。
7. 论文证据链
| 问题 | 论文做法 | 证据类型 | 结论 |
|---|---|---|---|
| 参数记忆是否足够处理知识密集型任务 | 将 seq2seq generator 接入 Wikipedia dense index | Open-domain QA 与知识生成任务实验 | 检索增强模型明显强于只靠参数记忆的生成模型 |
| 检索结果是否应该进入生成概率 | 将 document 视为 latent variable，在 top-K passages 上 marginalize | RAG-Sequence / RAG-Token 建模 | 检索不确定性可以被纳入生成过程 |
| 模型是否能生成更具体、更事实化的文本 | 生成任务对比 parametric-only baseline | 人工和自动评估 | 检索增强能提升事实具体性与多样性 |
| 外部记忆是否可替换 | 知识在 index 中而非只在参数中 | 架构性质 | 知识更新可以通过替换或更新索引实现 |
论文的价值不只是结果数字，而是证明了“生成模型 + 可检索外部记忆”是一个可训练、可评估、可扩展的范式。
8. RAG 没有解决什么
RAG 不是“接了向量数据库就可靠”。
它没有自动解决检索质量。正确资料没有召回，generator 再强也只能猜。
它没有自动解决权限。原论文的 Wikipedia index 没有企业级 RBAC/ABAC。金融场景里，检索前或检索中必须过滤权限，不能让模型先看到敏感资料再遮蔽。
它没有自动解决引用准确性。检索到某段资料，不代表答案中的每个断言都被这段资料支持。
它没有自动解决版本治理。企业政策有生效日期、废止日期、地区差异、草案状态、审批状态。没有 metadata，RAG 会引用旧资料。
它没有自动解决 prompt injection。检索内容可能包含恶意指令，系统必须把 retrieved docs 视为不可信数据，而不是系统指令。
它没有自动解决评估。最终答案正确不等于检索正确；检索正确不等于引用正确；引用正确也不等于业务流程可上线。
9. 现代企业 RAG 的端到端链路
原论文给的是研究框架。企业 RAG 至少要扩展成下面的链路。
9.1 Offline knowledge pipeline
source systems
-> ingestion
-> parsing / OCR / table extraction
-> structure-aware chunking
-> metadata enrichment
-> permission tagging
-> embedding
-> vector / lexical / hybrid index
-> versioned index release
这里最容易被低估的是 parsing、chunking 和 metadata。金融政策往往依赖标题层级、例外条款、表格、脚注和生效日期。固定长度切分很容易把规则切碎。
9.2 Online answer pipeline
user question
-> intent / query rewrite
-> permission-aware retrieval
-> hybrid candidate merge
-> reranking
-> context packing
-> generation
-> citation verification
-> safety / policy check
-> response
-> trace / feedback / eval log
在线链路的目标不是让模型多看资料，而是让模型只看“对这个用户、这个问题、这个时点、这个权限”合适的资料。
9.3 Eval pipeline
golden questions
-> expected answer
-> expected source
-> expected refusal
-> retrieval evaluation
-> answer evaluation
-> citation evaluation
-> permission / freshness tests
-> release gate
RAG 的评估必须分层。只看最终回答，会掩盖错误来源。
10. 失败模式
| Failure | 表现 | 根因 | 控制 |
|---|---|---|---|
| No retrieval | 知识库有答案但没召回 | query rewrite 差、chunking 差、过滤过严 | recall@k、同义词、hybrid retrieval |
| Wrong retrieval | 检到相似但错误资料 | 产品名/地区/版本相似 | metadata filter、reranker、负样本 |
| Stale source | 引用过期政策 | 缺生效/废止日期或默认不过滤 | version status、effective date gate |
| Permission leak | 用户看到无权资料 | 检索后才过滤、缓存串权限 | retrieval-time ACL、tenant isolation |
| Citation mismatch | 引用不支持断言 | 答案后贴来源、未做 claim check | claim-level citation verification |
| Context conflict | 上下文含冲突条款 | 新旧政策、地区或草案混入 | conflict detection、适用范围澄清 |
| Generator hallucination | 资料不足仍编答案 | prompt 弱、无拒答策略 | groundedness check、abstention |
| Prompt injection | 文档中指令劫持模型 | 把 retrieved text 当指令 | prompt hierarchy、sanitization、policy checker |
这些失败模式说明：RAG 的难点不是“向量库选型”，而是知识治理、检索质量、权限、引用、评估和运营。
11. RAG、微调、长上下文、搜索、知识图谱如何取舍
| 方案 | 适合什么 | 不适合什么 |
|---|---|---|
| RAG | 频繁变化、需要引用、需要权限控制的企业事实 | 无可信资料源、问题完全依赖规则计算 |
| Fine-tuning | 输出风格、格式、分类口径、领域表达 | 存储频繁变化的政策事实 |
| Long context | 单个案件包、单份长合同、一次性审阅 | 全企业知识库、复杂权限和版本治理 |
| Search | 找文档、排序、导航 | 需要综合解释和自然语言生成 |
| Knowledge graph | 实体关系、路径推理、规则关系 | 大量非结构化文本解释 |
成熟架构通常不是五选一，而是 search + RAG + graph + eval 的组合。RAG 管文本证据和生成解释，search 管可控召回，graph 管结构化关系，eval 管上线门禁。
12. 一个金融零售例子：KYC 政策助手
问题：客户经理问“新加坡注册的控股公司，最终受益人跨境，开户还缺哪些文件？”
如果只让 LLM 凭参数回答，风险很高。它可能混淆地区政策、忽略客户类型、引用过期清单，或者给出没有依据的合规建议。
一个合格的 RAG 系统应该这样工作：
- 识别问题中的地区、客户类型、业务线、文件类型和风险点。
- 根据用户身份过滤其有权访问的 KYC 政策。
- 检索当前有效版本的开户文件清单、UBO 规则、跨境补充要求和例外流程。
- 用 reranker 排除相似但不适用的地区或旧版本政策。
- 让 generator 输出缺失文件、适用范围、依据条款、不能确定的事项和下一步。
- 对每个关键断言绑定 policy id、version、section、effective date。
- 如果资料冲突或缺少地区政策，系统应拒答或升级人工，而不是编答案。
- 记录 query、retrieval、context、answer、citation、权限和人工反馈。
这里 RAG 的价值不是“回答得像专家”，而是把知识、权限、版本、证据和流程连成一个可审计系统。
13. 设计企业 RAG 时的最低指标
| 层 | 指标 | 为什么重要 |
|---|---|---|
| Retrieval | recall@k、MRR、negative retrieval rate | 判断资料是否被正确找出 |
| Metadata | filter accuracy、freshness accuracy | 判断地区、产品、版本、权限是否正确 |
| Generation | answer correctness、completeness、refusal accuracy | 判断答案是否可用、是否会过度回答 |
| Grounding | groundedness、citation coverage、citation accuracy | 判断断言是否被来源支持 |
| Security | permission leakage rate、prompt injection pass rate | 判断是否越权或被文档指令劫持 |
| Operations | P95 latency、cost per answer、zero-hit rate、feedback rate | 判断系统是否可运营 |
每个指标都应该绑定样本集、阈值、owner 和发布动作。没有 eval gate 的 RAG，只能靠主观试用上线。
14. 今天还应该怎么读这篇论文
读这篇论文要抓住四个判断。
第一，RAG 是知识架构，不是 UI 功能。用户看到的是问答，系统背后是 ingestion、index、permission、retrieval、generation、citation、eval。
第二，RAG 的上限先由检索和知识治理决定，再由生成模型决定。资料错、旧、无权限、无 metadata，模型越强越会把错误说得更像真的。
第三，RAG 不替代流程和责任。高风险答案需要拒答、升级、人工确认和审计记录。
第四，论文中的 parametric vs non-parametric memory 是理解企业 AI 的关键分界：稳定语言能力可以放在模型里，动态业务事实应该放在可治理知识层。
15. 读完后应该能回答
- 为什么参数记忆不适合作为企业事实的唯一来源？
- Retriever 和 generator 分别解决什么问题？
- 为什么 RAG 要在多个 retrieved documents 上做 marginalization？
- RAG-Sequence 与 RAG-Token 的核心差异是什么？
- 为什么 RAG 不能被简化成“向量数据库 + LLM”？
- 检索错误、引用错误、版本错误和权限错误分别如何发生？
- RAG、fine-tuning、long context、search、knowledge graph 如何取舍？
- 金融零售 RAG 为什么必须做权限前置、版本治理和 citation verification？
16. 后续阅读
- Dense Passage Retrieval: https://arxiv.org/abs/2004.04906 （2020-04）
- REALM: https://arxiv.org/abs/2002.08909 （2020-02）
- Fusion-in-Decoder: https://arxiv.org/abs/2007.01282 （2020-07）
- Atlas: https://arxiv.org/abs/2208.03299 （2022-08）
- Self-RAG: https://arxiv.org/abs/2310.11511 （2023-10）
- ColBERT: https://arxiv.org/abs/2004.12832 （2020-04）
- RAGAS: https://arxiv.org/abs/2309.15217 （2023-09）
SOTA 检查 (2026-07-01)
- Agentic RAG 已成为 2025-2026 企业主线：单次「retrieve-then-generate」被带反馈的有界循环取代——查询改写、多跳迭代、充分性判定（sufficiency assessment）。代表工作：Agentic RAG Survey（arXiv 2501.09136，2025-01）、FAIR-RAG 的充分性驱动检索（arXiv 2510.22344，2025-10）、A-RAG 分层检索接口 + test-time scaling（arXiv 2602.03442，2026-02）。库内实操见
docs/aipa/day41-agentic-retrieval.md（agentic 自适应检索）与docs/aipa/day40-jit-retrieval.md（JIT 检索与 context rot）。 - 本篇第 8/10/13 节的判断仍成立且被强化：2026 年行业分析显示 RAG 失败中约 73% 发生在检索环节而非生成环节——「上限先由检索和知识治理决定」这一结论没有过时；检索侧主流做法已固化为 hybrid search（BM25+向量）+ reranking + metadata filter 的复合系统，向量库单独裸用已不再是可接受的生产架构。
- RAG-Sequence / RAG-Token 的 latent-variable marginalization 训练范式已基本被替代：现代系统不再对 top-K 文档做概率整合联合训练，而是「检索结果拼入上下文 + 冻结的强 generator」或 agentic 循环；本篇第 4-5 节应作为历史机制理解，其思想遗产（每个事实点可追溯到自己的证据）以 claim-level citation verification 的形式存续。
- 长上下文没有杀死 RAG，但「RAG-centric」叙事已被 context engineering 吸收（本仓库 AIPA 纪律亦如此标注）：百万级 token 窗口下，权限前置、数据新鲜度、审计轨迹、成本/延迟仍使检索成为多用户企业场景的默认选择；2026 年主流做法是路由式混合（简单查询走检索、单案件包/长合同走长上下文），检索被视为 context engineering 的一个子环节。方法论见
docs/AI_CONTEXT_ENGINEERING_PLAYBOOK.md。 - 结构化关系检索用 GraphRAG 补位：Microsoft GraphRAG（2024 年由 Microsoft Research 提出并开源，持续迭代中）代表「vector + graph」互补路线，2025-2026 共识是二者组合而非替代——与本篇第 11 节「search + RAG + graph + eval 组合」的结论一致。检索评测与 GraphRAG 的库内 playbook 见
docs/AI_RETRIEVAL_EVAL_GRAPH_RAG_PLAYBOOK.md。 - 不随版本过时的框架性结论：parametric vs non-parametric memory 的分界（稳定语言能力在参数、动态业务事实在可治理知识层）、分层评估（检索/生成/引用/权限各自独立评测 + release gate）、权限前置检索、把 retrieved docs 视为不可信数据（prompt injection 防线）——这四条是本篇的长期价值，2026 年的 agentic RAG 和 context engineering 都建立在其上而非推翻它们。