RAG全景：为什么你的大模型需要外挂一个知识库

第 1 章：RAG全景——为什么你的大模型需要外挂一个知识库

你刚刚花了三个月微调了一个 7B 的模型，在你的内部测试集上准确率从 73% 飙升到 91%。你的老板很兴奋，让它上线。结果第二天，客服团队发来截图——模型在回答"我们公司今年发布的旗舰产品是哪款"时，引用了一个根本不存在的产品名称，还编造了发布会日期。CEO 亲自下场问："为什么我们的 AI 还在胡言乱语？"

这，就是大模型的"幻觉"（hallucination）问题。它不是 bug，它是一种结构性缺陷——语言模型的训练目标（next-token prediction）和它实际承担的工作（给出准确、可信的答案）之间，存在一条天然的鸿沟。Retrieval-Augmented Generation（RAG，检索增强生成） 之所以从 2020 年一篇看似普通的论文，发展成 2024-2025 年整个 AI 工程界最炙手可热的范式，正是因为它直接针对这条鸿沟提供了一套工程上可落地的解决方案。

但 RAG 不是银弹。在你决定给自己的业务上 RAG 之前，你需要回答三个问题：第一，RAG 到底解决了什么、不解决什么？第二，它和 fine-tuning（微调）、long-context（长上下文窗口）到底怎么选？第三，最小可行的 RAG 长什么样，自己能不能跑起来？

本章就是要正面回答这三个问题。

---

1.1 大模型的"幻觉"困境：为什么会胡说八道？

1.1.1 幻觉的本质：模型在"编"而不是在"查"

从工程视角看，主流大语言模型（LLM）的本质是一个自回归的概率生成器（autoregressive probabilistic generator）。给定一个上下文，它的目标是产出下一个 token 的概率分布，然后采样（或取 argmax）。训练时，它的 loss 函数是 cross-entropy on next token——它从未被明确训练成"在不知道的时候说我不知道"。

这导致模型在面对训练数据中没有明确答案的问题时，会倾向于"平滑地"生成一个看起来合理、语法正确、但事实错误的答案。这个现象在 2021 年 OpenAI 的 GPT-3 时代就已经被注意到，在 2023 年的 TruthfulQA 基准测试中，GPT-4 在 zero-shot 设置下的"truthful"得分也只有约 59%。换句话说，一个 200B+ 参数的 SOTA 模型，在事实准确性上甚至打不过 1960 年代的基于规则的系统——前提是你给后者足够完整的规则。

举个真实的例子。某车企在 2024 年初部署了一个客服机器人，底层是某闭源大模型。用户问："我的车在 2024 年 1 月 1 日后做的保养还在保修范围内吗？"模型答："不在，2024 年新政策规定保养必须每 5000 公里做一次。"——这条"新政策"完全是模型编造的。问题不在模型笨，而在它的训练数据截止于 2023 年 6 月，它根本无法知道 2024 年的政策。但它不会说"我不知道"，它会编。

1.1.2 为什么"塞上下文"和"微调"都不能根治

工程师的第一反应通常是：那我把相关知识塞进 prompt 不就行了？ 这就是所谓的 "prompt stuffing" 或者 "in-context learning"。这个方法在很多场景下 work，但有三个致命问题：

1. 上下文窗口是有限的。即使 GPT-4 Turbo 把窗口扩到 128K tokens，你的企业知识库可能有几十 GB，根本塞不下。 2. 位置偏差（position bias）。研究表明，LLM 对上下文窗口中间位置的信息关注度低于两端，著名的 "Lost in the Middle" 现象（Liu et al., 2023）显示，当关键信息被放在 200 个文档的中间位置时，召回率可能下降 30%+。 3. 成本爆炸。GPT-4 Turbo 的 128K 上下文定价约为 $10/M tokens。如果每次请求都塞 100K tokens，单次成本就是 $1+。一个中型客服系统一天 10 万次请求，光 token 成本就是 10 万美金/天。

那 fine-tuning 呢？Fine-tuning 是把知识"烧进"模型权重里。它的优势是推理时零检索开销、单次推理成本低。但它的劣势对生产系统来说几乎是致命的：

• **知识更新成本高**。每次法规、产品、政策变化，你都要重新训练或做 continual fine-tuning。一次全量微调 7B 模型的成本是几千到上万美元（GPU hours + 数据准备 + 评估）。
• **无法溯源**。模型告诉你"答案是 B"，你没法问它"为什么是 B"。这在医疗、法律、金融场景下是 deal-breaker。
• **灾难性遗忘**（catastrophic forgetting）。新知识进去，旧知识可能丢失。你好不容易让模型学会了你公司的产品手册，结果它忘了怎么做基础数学题。
• **数据隐私**。Fine-tuning 需要把数据送进训练 pipeline，对很多企业（尤其是金融、医疗）来说合规风险极高。

所以问题就变成了：有没有一种方法，既能把外部知识注入到生成过程中，又不需要把这些知识烧进模型权重里？

RAG 就是这个问题的答案。

1.1.3 RAG 的核心思想：让模型"开卷考试"

RAG 的思想朴素得让人怀疑为什么没早点想到——让模型在做题的时候可以查资料。

具体来说，RAG 把生成过程拆成两步：

1. 检索（Retrieval）：给定用户问题 $q$，从外部知识库 $K = \{d_1, d_2, ..., d_n\}$ 中找出最相关的 top-k 个文档片段。 2. 增强生成（Augmented Generation）：把这 k 个文档片段作为上下文，和用户问题一起拼成 prompt，送进 LLM 生成答案。

形式化一点，整个流程可以写成：

$$\text{answer} = \text{LLM}(q, \text{Retrieve}(q, K))$$

其中 $\text{Retrieve}(q, K)$ 通常是一个 dense retriever（基于向量相似度）或 sparse retriever（基于 BM25 等关键词匹配），有时两者结合。

这个"开卷考试"的设计，本质上把模型的职责从"记忆所有知识"降级为"理解并整合检索到的知识"。前者是模型不擅长的，后者是模型擅长的。

---

1.2 RAG 的历史定位：从 2020 到 2024 的演化谱系

RAG 不是一夜之间冒出来的。它的演化可以分成四个阶段，每一个阶段都对应着当时主流 LLM 范式的局限性。

1.2.1 阶段一：Naive RAG（2020-2022）——开山立派

2020 年，Patrick Lewis 等人在 Facebook AI 发表了一篇论文 *Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks*。这篇论文首次系统地提出了 RAG 框架，并在一个叫 Natural Questions 的开放域问答基准上做到了 SOTA。

当时的背景是：BERT 时代，模型参数还相对小（330M），open-domain QA 主要靠 DrQA、BERTserini 这类 retrieve-then-read 的两阶段系统。Lewis 等人的贡献是把 retriever 和 generator 端到端地联合训练——retriever 用的是 DPR（Dense Passage Retrieval），generator 用的是 BART。两者通过 marginalizing over retrieved documents 来计算 loss。

这是一个工程上非常重要但当时没有被充分重视的工作。它的核心 insight 是：显式的检索 + 生成，比让模型把所有知识压进参数里更高效、更可解释。

但 2020-2022 年间，GPT-3 的横空出世让社区的关注点全面转向了"scale is all you need"。RAG 进入了短暂的沉寂期。

1.2.2 阶段二：Advanced RAG（2023）——和 ChatGPT 一起重生

2022 年底 ChatGPT 发布，2023 年 GPT-4 发布，整个行业进入了 LLM 应用爆发的元年。但很快，所有认真做应用的人都撞上了幻觉墙。

2023 年春天开始，LangChain、LlamaIndex 等开源框架迅速崛起，把 RAG 从论文里的玩具变成了生产环境里可用的工程组件。这段时间，社区贡献了大量"Advanced RAG"技巧，包括：

• **Chunking 优化**：把长文档切成合理大小的 chunk（典型 256-512 tokens），并保留 overlap 避免边界信息丢失。
• **Hybrid Retrieval**：dense + sparse 双路召回，BM25 负责精确关键词，vector search 负责语义。
• **Re-ranking**：先用 bi-encoder 召回 top-100，再用 cross-encoder（如 Cohere Rerank、BGE-reranker）精排到 top-5，精度大幅提升。
• **Query Rewriting**：让 LLM 先把用户的问题改写成更适合检索的 query。
• **Hypothetical Document Embeddings (HyDE)**：让 LLM 先虚构一个答案，再拿这个答案去做检索，反向找相似文档。

Advanced RAG 的核心思想是：检索质量决定 RAG 上限。很多人以为 RAG 不 work 是模型不够强，其实是检索这一步就把垃圾捞上来了，模型再聪明也没用。

1.2.3 阶段三：Modular RAG（2024 上半年）——RAG 变成乐高

2024 年初，一篇叫 *Modular RAG: Transforming RAG Systems into LEGO-like Reconfigurable Frameworks* 的综述（So et al.）彻底改变了社区对 RAG 的认知。它把 RAG 拆成了七个基本模块：Indexing、Pre-retrieval、Retrieval、Post-retrieval、Generation、Evaluation、Orchestration。每个模块都可以独立替换和优化。

这个抽象层次让 RAG 从"一个固定 pipeline"变成了"一套可组合的范式"。工程师可以根据业务需求选择：

• 要不要 query rewriting？
• 要不要加 reranking？
• 要不要做 query expansion？
• 要不要多路召回融合？

这就让 RAG 从"一种方法"升级成了"一种工程哲学"——把复杂的知识问答问题分解成可控的子模块。

1.2.4 阶段四：GraphRAG & Agentic RAG（2024 下半年至今）——走向智能

2024 年中，Microsoft Research 发布了一篇震动社区的博客：*GraphRAG: Unlocking LLM discovery on narrative private data*。他们发现，对全局性问题（例如"这个数据集的主题是什么"），传统的 chunk-based RAG 完全失效——因为答案需要跨多个 chunk 推理。GraphRAG 的解决思路是：

1. 先用 LLM 从文档中抽取实体和关系，构建知识图谱（knowledge graph）。 2. 再用 Leiden 算法做社区检测，把图谱分成多个主题社区。 3. 每个社区生成一个 summary。 4. 检索时，先匹配相关社区，再去 graph 里查找具体实体和关系。

这个思路在财报分析、学术文献综述、多跳问答等场景下大幅超越了 Naive RAG。

几乎同一时间，Agentic RAG 的概念开始流行。它的核心思想是：让 LLM 本身成为 RAG 系统的"调度器"，而不是被动接收检索结果。Agent 可以：

• 决定要不要检索（有时直接答就行）
• 决定检索几次（多跳推理）
• 决定用什么工具（向量库 / 搜索引擎 / 数据库）
• 决定什么时候停止（自我验证）

这意味着 RAG 系统从"流水线"变成了"智能体"。

总结一下这张演化图谱：

| 阶段 | 时间 | 核心创新 | 代表工作 | |------|------|----------|----------| | Naive RAG | 2020-2022 | 端到端 retrieve + generate | Lewis et al. 2020 | | Advanced RAG | 2023 | 检索质量优化（chunking/reranking） | LangChain, LlamaIndex | | Modular RAG | 2024 H1 | 模块化、可组合 | So et al. 2024 | | GraphRAG | 2024 H2 | 知识图谱增强全局推理 | MS Research 2024 | | Agentic RAG | 2024 H2+ | LLM 作为调度器 | LangGraph, AutoGen |

理解这条演化线非常重要，它能帮你判断：网上看到一篇 RAG 文章时，它讨论的是哪一代的方法，方法的天花板和地雷分别在哪里。

---

1.3 RAG vs Fine-tuning vs Long Context：到底怎么选？

1.3.1 一个真实的三选一困境

假设你是一家 SaaS 公司，你们有 5000 篇产品文档、3000 条内部 wiki、2000 个客户工单。现在老板让你做一个 AI 助手，能回答客户关于产品的任何问题。你面前有三条路：

路线 A：RAG——把所有文档索引到向量库，查询时检索 top-5 喂给 LLM。 路线 B：Fine-tuning——拿所有文档数据 fine-tune 一个开源模型（比如 Llama-3-8B）。 路线 C：Long Context——直接把文档全塞进 GPT-4 Turbo 的 128K 上下文，每次请求都全文 prompt。

你选哪个？

答案不是非黑即白。但有一个相对清晰的决策框架。

1.3.2 三个维度的对比

我们从知识更新频率、答案可解释性、单位成本三个维度对比这三种方案。

维度 1：知识更新频率

• RAG：✅ 极高。文档进向量库就生效，毫秒级更新。
• Fine-tuning：❌ 极低。每次更新都要重新训练，几小时到几天。
• Long Context：⚠️ 中等。新文档写进去，但需要重新构建 prompt 模板。

维度 2：答案可解释性

• RAG：✅ 极高。可以返回"答案来自文档 X 的第 Y 段"，用户可以验证。
• Fine-tuning：❌ 极低。模型权重里看不出哪个知识来自哪里。
• Long Context：⚠️ 中等。可以告诉用户答案来自哪段，但需要模型自己指认，存在 hallucination。

维度 3：单位推理成本（单次请求）

• RAG：✅ 低。检索是常数级成本，prompt 长度可控。
• Fine-tuning：✅ 低。推理时和普通 LLM 一样。
• Long Context：❌ 高。128K tokens 的 prompt 成本是 4K 的 32 倍（按 GPT-4 Turbo 价格），且推理延迟线性增加。

维度 4：开发复杂度

• RAG：⚠️ 中等。需要搭建向量库、retriever、reranker 等 pipeline。
• Fine-tuning：⚠️ 中等。需要标注数据、训练 pipeline、评估体系。
• Long Context：✅ 低。直接把文档粘进 prompt 就行。

维度 5：长尾知识覆盖

• RAG：✅ 优。理论上可以覆盖知识库中所有文档。
• Fine-tuning：⚠️ 中。取决于训练数据分布，长尾知识容易被遗忘。
• Long Context：✅ 优。只要塞得下，全覆盖。

1.3.3 决策树：什么时候选哪个

下面是一棵精简版的决策树，能帮你在 5 分钟内做出判断。

```mermaid flowchart TD A[你有知识更新需求吗] --> B{知识每月都变} B -->|是| C[RAG是首选] B -->|否| D{答案需要可溯源吗} D -->|是| C D -->|否| E{知识库有多大} E -->|>100万tokens| F{需要全局推理吗} F -->|是| G[GraphRAG或Long Context] F -->|否| C E -->|<10万tokens| H{你需要改变模型行为风格吗} H -->|是| I[Fine-tuning适合调整风格/格式] H -->|否| J[Long Context最简单] C --> K[再用Fine-tuning微调风格] I --> K ```

1.3.4 一个反直觉的事实：组合使用才是正解

在真实生产环境中，RAG + Fine-tuning 的组合往往是效果最好的。具体来说：

• 用 RAG 注入**事实性知识**（facts）——产品参数、法规条款、用户历史。
• 用 Fine-tuning 注入**行为模式**（style/format）——比如"回答必须分点"、"语气要正式"、"代码必须用 Python"。

这样做的好处是：RAG 解决"答什么"，fine-tuning 解决"怎么答"。两者各司其职，互不干扰。

OpenAI 在他们的 RAG 最佳实践文档中也明确建议：对于有强风格要求的场景（如客服、技术支持），先 fine-tune 风格，再用 RAG 注入知识，效果显著优于单一方案。

但要注意：fine-tuning 不要用来注入知识，那是 RAG 的活。网上很多教程教人用 fine-tuning 喂产品文档，这种做法短期看似乎 work，长期维护成本会让你后悔。

---

1.4 RAG 的三大核心优势

RAG 之所以成为 LLM 应用的事实标准（de facto standard），是因为它在三个关键维度上提供了独特的价值。

1.4.1 优势一：知识实时更新——不再受限于训练截止日

Fine-tuning 的痛点：某法律咨