RAG 导论：为什么大模型需要知识库

第 1 章：RAG 导论——为什么大模型需要知识库

大模型看起来什么都知道，但只要把它放进真实业务里，它就会迅速暴露三块短板：一本正经地胡说八道、对半年内的新事件一无所知、对你们公司的内部制度完全摸不着头脑。这三个问题不是 Bug，而是当下 Transformer-based 大语言模型（LLM, Large Language Model）的结构性限制。要让大模型真正可用，就必须在它的"参数记忆"之外，再外挂一套可被业务方掌控的知识系统——这就是检索增强生成（RAG, Retrieval-Augmented Generation）出现的根本原因。

本章会带你建立对 RAG 的第一性认知：我们会拆解大模型的三大硬伤，对比微调与 RAG 的工程权衡，画出一张完整的 RAG 全景架构图，并埋下一条贯穿全书的"企业 FAQ 助手"案例线，让你看到 RAG 是如何从一个原型一步步演化成生产级系统的。

1. 三大硬伤：为什么参数记忆撑不起真实世界的问答

1.1 幻觉——模型不是在"回忆"，而是在"编造"

很多人误以为大模型的工作方式是"读取训练语料中的相关段落，然后复述"。事实上，从 GPT 系列到开源的 Llama、Qwen、Mistral，它们在回答问题时真正做的事情，是逐 token 地根据上下文概率挑选下一个字。如果模型在参数中"见过"类似模式，它能给出听起来非常自信的答案；但当问题超出了它的训练分布（training distribution），它依然会输出语法完整、措辞专业的句子，只是这些句子在事实上可能是错的。这就是 AI 领域的"幻觉"（hallucination）。

举一个真实场景：让 ChatGPT 列举某本 2024 年出版的 RAG 综述论文，它能列出作者姓名、期刊、页码——但其中 60% 以上是它"编"出来的。把这种回答直接交给用户，会立刻引发信任危机。

从技术视角看，幻觉的根源有三层：

1. 训练目标的错配。大模型的训练目标是"下一个 token 最大化似然"，而不是"事实正确"。这意味着即使一个回答在统计上流畅，但如果它没有事实锚点（factual grounding），模型依然会输出它。 2. 知识存储的"压缩失真"。数千亿 token 的世界知识被压缩进数百 GB 的模型权重里，必然有信息损失。这和 JPEG 压缩图片会失真是同一道理——只是失真的不是像素，而是事实细节。 3. 缺乏"我不知道"的退出机制。标准的大模型解码过程（decoding）几乎没有显式的拒答通道。要让模型主动说"我不知道"，需要额外的对齐训练（alignment）或后处理。

RAG 的核心对策是用检索到的外部证据去约束生成过程：模型在回答前先看到一段来自权威知识库的原文，然后被要求基于这段原文作答。这相当于把"开卷考试"机制引入生成式 AI，从根本上让模型有机会"有据可查"。

1.2 知识陈旧——训练数据的截止线是一道不可逾越的墙

每一个预训练大模型都有一个"知识截止日期"（knowledge cutoff）。比如 GPT-4o 的训练数据停留在 2023 年 10 月，Llama 3.1 截至 2024 年 7 月。任何在这之后发生的事件——新产品发布、法规更新、CEO 变更、股价波动——都对模型透明。

这不只是"新事件不知道"这么简单。在企业场景里，知识陈旧会造成直接的业务损失：客服系统告诉用户一款已经停售的产品仍在销售；合规系统引用一条已经被废止的监管条款；财经助手给出过时一年的财报分析。

面对这个问题，传统思路有两条：要么定期重新预训练（成本高到只有少数巨头能玩），要么微调（fine-tuning，即用新数据继续训练模型，注入新知识）。前者一条路径就需要数百万美元和数月时间，后者虽然便宜一些，但也存在严重的"灾难性遗忘"（catastrophic forgetting）风险——新知识灌进去，旧能力可能丢失。

RAG 提供了一条更轻量的解法：把"知识"和"模型"解耦。模型本身保持不变，所有更新都在外部知识库里完成——增删一条记录只需几秒钟，发布也只需几分钟。这就是为什么 RAG 在"知识保鲜"这件事上几乎是当下最具性价比的方案。

1.3 私域盲区——通用模型不懂你的公司

如果说幻觉和知识陈旧是"通用问题"，那私域盲区（private-domain blindness）就是"企业级应用的致命伤"。

通用大模型在公网数据上训练，它知道"苹果公司发布了 iPhone 15"，但它不知道：

• **你公司的报销流程**——出差住宿标准是多少、哪些发票可以抵扣。
• **你公司的产品手册**——某个工业传感器的故障代码 E07 到底代表什么含义。
• **你公司的客户档案**——某位 VIP 客户的历史订单记录与偏好。
• **你公司的合规红线**——哪些话术在金融监管下是禁止的。

这些知识有两个共同特点：高度专有、持续变化。它们永远不会被公开爬取，也不会被允许送进通用模型的训练集。

要让大模型具备"私域能力"，本质上只有两条技术路径：

1. 微调：用私域数据继续训练模型，把私域知识烧进参数。 2. RAG：把私域数据建成可检索的索引，让模型在回答时按需取用。

两条路径不是非此即彼，而是常常组合使用。但在绝大多数"知识注入"的场景里，RAG 是性价比更高、合规风险更低、迭代速度更快的首选。这是我们下一节要展开的核心命题。

2. 三条路线的工程权衡：纯生成、微调与 RAG

面对"让大模型具备私域知识"这个需求，工程团队的备选方案其实有三条：纯生成式提示工程（prompt engineering）、微调、RAG。我们用一个四象限的决策矩阵，把它们的代价、收益、风险讲清楚。

2.1 决策矩阵：成本、可更新性、可解释性、可控性

| 维度 | 纯生成式提示（Prompt-only） | 微调（Fine-tuning） | RAG | |------|------------------------------|----------------------|------| | 一次性成本 | 极低 | 高（GPU + 数据 + 工程师） | 中（向量库 + ETL） | | 持续更新成本 | 零（但知识不会更新） | 高（每次更新需重训） | 极低（增删文档即可） | | 可解释性 | 弱（黑盒） | 弱（参数化） | 强（可追溯到引用） | | 合规审计 | 难 | 难（参数不可读） | 易（可看到引用来源） | | 幻觉率 | 高 | 中（仍然存在） | 低（有锚定证据） | | 冷启动速度 | 即时 | 数周 | 数天 |

纯生成式提示工程适合"轻量、临时、对话式"的场景，比如让模型扮演一个虚拟人物、做一些创意写作。但一旦任务需要事实准确性，这条路线就立刻碰壁。

微调适合"风格、格式、专有能力"的注入，比如让模型学会某种编程语言的口吻、学会生成特定格式的 SQL、把一个通用模型调成法律垂直模型。但微调对"知识更新"是非常不友好的——你把"2024 年的法规"烧进参数，2025 年这些法规修订时，模型依然会按旧版回答。

RAG则把"知识"和"能力"清晰切分：模型提供"理解和生成的语言能力"，知识库提供"事实和证据"。这种架构带来的好处是：

• **可更新性极强**：知识库是普通文档，加一条记录几秒钟。
• **可解释性极强**：每一条答案都能追溯到来源段落，便于审计与人工核验。
• **合规风险低**：私域数据不需要离开你的服务器，仅在推理时被检索。
• **成本可控**：向量数据库与嵌入模型的边际成本远低于 GPU 训练。

2.2 一个直观的对比实验

为了让你对三种路线的能力差异有"体感"，我们用一个真实的小实验来对比。

任务：给定一份虚构的"Acme 公司 2024 报销制度"（1500 字 PDF），回答 20 个相关问题。问题包括"出差住宿标准是多少""哪些发票可以抵扣""跨城市出差是否包含餐补"等。

方案 A：纯提示。把 PDF 全文粘进 prompt，要求模型基于它回答。结果：模型确实能给出大致正确的方向，但偶有细节错误（比如把"住宿上限 800 元"说成"600 元"），且无法明确指出原文段落。

方案 B：微调。把 PDF 加 20 组 Q&A 整理成监督数据，对一个 7B 模型做 LoRA 微调。结果：模型对训练集中出现的问题回答精准，但面对"微调数据外的问题"（比如临时新增的"差旅新规"），模型依然按旧版回答——因为新知识没有被训练进去。

方案 C：RAG。把 PDF 切成 30 个 chunk，嵌入到本地向量库，查询时先检索再生成。结果：模型不仅能精准回答，还能引用原文段落（"根据《报销制度》第 3.2 条……"），并且新增一条差旅新规后，只需更新向量库就能立刻生效。

这个实验背后揭示的工程真相是：RAG 不是万能解，但它在"知识注入 + 可更新 + 可解释"这一组约束下的综合得分，往往是最高的。

2.3 RAG 没能解决什么

诚实地说，RAG 也有自己的局限。理解它的边界，比盲目夸大它的能力更重要。

1. 它解决不了"模型本身的能力短板"。如果你的基础模型连中文都说不利索，再好的 RAG 也救不回来。 2. 它解决不了"超出检索范围的推理"。RAG 能给模型"参考资料"，但不能替代模型本身的推理。如果文档里只写了"A 公司在 2022 年收购了 B 公司"，模型依然很难回答"这次收购对 2024 年的供应链有什么影响"——这种问题需要文档中没有的推断能力。 3. 它解决不了"语义匹配的极限"。当用户问"我们的年假是几天"，但文档里写的是"员工每年享有 5 天带薪休假"，模型有可能因为检索的 chunk 不在 top-k 而漏掉正确答案。这就是为什么 RAG 系统需要查询改写（query rewrite）、重排序（rerank）、混合检索（hybrid retrieval）等机制——这些我们会在后续章节深入展开。 4. 它解决不了"文档质量本身的问题"。如果你的私域文档本身就是过时的、矛盾的、结构混乱的，RAG 会忠实地把这些问题"传染"给最终用户。RAG 不是数据清洗的替代品。

理解了 RAG 的"能"与"不能"，我们才能在工程实践中做出合理的架构选择。

3. RAG 全景架构：从一条 query 到一条 answer 的完整旅程

现在，让我们把视角从"为什么"切换到"是什么"。一个生产级的 RAG 系统，绝不只是"把文档塞给大模型"那么简单。它由两条核心流水线组成：离线索引流水线（offline indexing pipeline） 与 在线检索生成回路（online retrieval-generation loop）。

3.1 离线索引流水线：把世界知识炼成可检索的向量

离线流水线的目标，是把"人类可读的文档"转换成"机器可高效检索的向量"。它通常包含以下步骤：

1. 文档接入（Ingestion）：从各种数据源拉取文档。常见源包括 Confluence、Notion、SharePoint、Slack、邮件归档、CRM 系统、工单系统、PDF/Word 附件，以及通过爬虫抓取的网页。每种源的接入方式都不一样，需要专门的 connector。 2. 解析与清洗（Parsing & Cleaning）：把 PDF、Word、HTML 等富文本转换成纯文本或结构化 JSON。这一步远比看起来难——PDF 中的表格、扫描件、公式、跨页表格常常丢失结构。我们会在第 4 章专门讨论文档解析的工程难点。 3. 切块（Chunking）：把长文档切成"语义完整的小段落"，每个 chunk 通常 200–800 token。切块策略有固定窗口、滑动窗口、按段落、按句子、按语义等多种。没有"最好"的切块策略，只有"最适合你这份文档"的策略。 4. 嵌入（Embedding）：用 embedding model 把每个 chunk 转换成一个高维向量（常见维度 384、768、1024、1536、3072）。语义相近的文本，对应的向量在空间中距离也更近。OpenAI 的 `text-embedding-3-large`、开源的 BGE-M3、Qwen3-Embedding 都是当下主流选择。 5. 存入向量库（Vector Store）：把向量连同原始文本、元数据（来源、更新时间、作者、权限标签等）一起写入向量数据库。常见选项包括 Milvus、Weaviate、Qdrant、Pinecone、Chroma、PGVector。 6. 同时构建关键词索引：仅靠向量检索有时不够——当用户查询一个精确的产品型号、合同编号、人名时，关键词检索（BM25、Elasticsearch）反而更准。所以生产系统通常采用"混合检索"：向量召回 + 关键词召回，再融合排序。

整个离线流程可以是一次性的，也可以是周期性的（每日、每小时、甚至流式）。我们在第 9 章会详细讨论"增量索引"和"近实时更新"的工程方案。

3.2 在线检索生成回路：从用户提问到最终答案

在线回路是真正面向用户的那条路径。每当用户发起一次查询，以下步骤会在几百毫秒到几秒内完成：

1. 查询理解（Query Understanding）：对用户的原始 query 做规范化、改写、生成多个变体（multi-query）、生成 HyDE（hypothetical document embedding，假设性文档嵌入）等，目的是让检索更准。 2. 检索（Retrieval）：在向量库和关键词索引里并行查询，取回 top-K 个相关 chunk（典型 K=10 到 50）。 3. 重排序（Reranking）：用更强的 cross-encoder reranker 模型（如 BGE-reranker、Cohere Rerank）对召回的 chunk 重排，把真正相关的推到前面。 4. 上下文组装（Context Assembly）：把 top-N（典型 N=3 到 8）的 chunk 与用户 query 拼装成最终的 prompt，附上系统指令（如"只能基于以下文档回答，不知道就说不知道"）。 5. 生成（Generation）：把 prompt 送进 LLM，生成最终回答。 6. 后处理与回流（Post-processing & Feedback）：对生成结果做格式校验、引用标注、敏感词过滤，并可选择把用户的反馈（如"这个回答不对"）回流到知识库管理流程。

下面这张图展示了从原始文档到最终答案的完整端到端流程：

```mermaid flowchart LR subgraph OFF[Offline Indexing Pipeline] D1[Raw Documents] --> D2[Parse and Clean] D2 --> D3[Chunk Splitting] D3 --> D4[Embedding Model] D4 --> D5[(Vector Database)] D3 --> D6[(Keyword Index BM25)] end subgraph ON[Online Retrieval-Generation Loop] Q1[User Query] --> Q2[Query Rewrite] Q2 --> Q3[Hybrid Retrieval] D5 --> Q3 D6 --> Q3 Q3 --> Q4[Rerank] Q4 --> Q5[Context Assembly] Q5 --> Q6[LLM Generation] Q6 --> Q7[Final Answer with Citations] end ```

3.3 关键术语对照表

为了让后续章节的术语统一，我们在这一章就把 RAG 领域的核心词汇固定下来：

| 中文术语 | 英文术语 | 简要说明 | |---------|----------|---------| | 检索增强生成 | Retrieval-Augmented Generation (RAG) | 从外部知识库检索证据辅助生成的范式 | | 嵌入 | Embedding | 把文本映射为稠密向量的过程 | | 向量数据库 | Vector Database / Vector Store | 存储并高效检索向量的专用数据库 | | 切块 | Chunking | 把长文档切成小段的过程 | | 检索器 | Retriever | 从向量库中取回相关 chunk 的组件 | | 重排序器 | Reranker | 对召回结果精排的模型 | | 生成器 | Generator | 最终生成回答的 LLM | | 混合检索 | Hybrid Retrieval | 向量检索 + 关键词检索的组合 | | 引用 | Citation | 回答中标注答案来源段落的机制 | | 知识截止 | Knowledge Cutoff | 模型训练数据的最后日期 | | 幻觉 | Hallucination | 模型生成内容与事实不符的现象 |

这些术语会贯穿全书。第一次出现时我们会做完整解释，后续章节直接复用。

4. 贯穿全书的案例：企业 FAQ 助手的演进路线图

理论框架讲完了，让我们落地到一个具体案例。我们会用一个虚构的"Acme 公司内部 FAQ 助手"作为贯穿全书的例子——这本书的每一章，都会在这个案例上叠加一层新的能力，让你看到它如何从一个粗糙的原型一步步演化为生产级系统。

4.1 第一阶段：基于关键词的脚本（2018 年代风格）

最初，Acme 公司用了一套基于关键词匹配的 FAQ 脚本：当用户问题包含"报销"两个字时，机器人回复一段预设文字。这种系统搭建快、维护直观，但任何"语义变体"都会让它失效——用户写"出差花了多少钱能报"，它就完全接不住。

4.2 第二阶段：直接调用大模型（2023 年初风格）

2023 年初，工程师把公司制度 PDF 直接粘贴进 prompt，让 ChatGPT 回答。一开始效果惊人，团队兴奋了两个月。问题随之而来：用户问"上个月发布的差旅新规"时，模型依然按旧版回答；模型会编造不存在的条款编号；用户追问"你这段话出自文档哪里"时，模型无法回答。

4.3 第三阶段：最小可行 RAG（2023 年中后期风格）

团队决定引入 RAG：把 200 份制度文档切成 5000 个 chunk，嵌入到向量库