开卷有益：为什么大模型需要一本'参考书'

开卷有益：为什么大模型需要一本"参考书"

凌晨一点二十三分，某 SaaS 公司的 CEO 张磊被一封邮件炸醒。邮件来自他们最大的客户——一家世界 500 强企业的采购总监，措辞冰冷而客气："贵公司 ChatGPT 客服助手告诉我们的员工，你们旗舰产品的合同起算日是'每月自动续费、随时可以取消'。请核实。"

张磊打开后台日志，看到的事实让他后背发凉：他们的客服助手被接入了 ChatGPT API 来自动回答产品问题，而 ChatGPT 在没有看到任何合同条款的情况下，凭着"看起来合理"的语言模式，编造了一条公司从未承诺过的退订规则。这条规则正在被用户截图、转发、引用。

这就是大模型时代最经典的翻车现场——不是模型不够聪明，而是模型太会"瞎编"了。

这一章，我们就从这起真实的"胡说八道"事件出发，搞清楚三件事：大模型为什么会一本正经地编瞎话？我们能用什么样的工程手段阻止它？为什么"给模型一本参考书"——也就是 RAG（Retrieval-Augmented Generation，检索增强生成）——会成为企业落地大模型时几乎人手一份的标配？

读完之后，你不仅能在饭局上用三句话讲清楚 RAG 是什么，还能用不到 30 行代码在本地跑通一个真正能用的问答 Demo。

---

一、一次价值百万的"幻觉"：大模型为什么会胡说八道

让我们先把张磊的案例拆开看，看看到底是哪一环出了问题。

那天客户的提问是："我们的合同里关于自动续费是怎么规定的？"这个问题的正确答案是：查合同原文，找到对应条款，原样引用。但 ChatGPT 接到的指令是"以专业客服身份回答用户问题"，它手边没有合同，也没有数据库连接。它能做的，是"根据训练时见过的海量文本，预测下一个最合理的词"。

于是它预测出了一段听起来极其专业的回答——包括"每月自动续费"和"随时可以取消"——这两句话在人类语料里出现频率高得吓人，但跟这家公司的实际合同毫无关系。

这就是所谓的幻觉（Hallucination）。但幻觉只是表象。如果我们再深入一层，会发现 ChatGPT 在那次回答中至少踩中了三个深坑。

1.1 知识截止：模型是个"活在过去的学者"

大模型的知识来自训练数据。以 GPT-4 为例，其主要训练数据截止到 2023 年 10 月，之后发生的事情它完全不知道——2024 年的新法规、2024 年发布的产品、昨天才更新的内部文档，对它而言都像是不存在的平行宇宙。

更麻烦的是，模型无法区分"自己不知道"和"自己以为知道"。当被问到一个它训练数据里没有的实体（比如你们公司昨天才上线的功能），它不会老老实实回答"我不知道"，而是会用统计概率最高的拼凑方式，给你一个听起来特别像那么回事的回答。这就是为什么你问它"请介绍一下 XX 公司 2024 年发布的 YY 平台"，它会给你写出一篇 800 字的产品介绍，引言、亮点、技术架构一应俱全——然而这家公司的 YY 平台根本不存在。

用一个不太恰当的比喻：大模型像一个只读到了 2023 年报纸的博学教授，你问他 2024 年的新闻，他要么说"我不清楚"，要么就开始编。为了显得博学，他倾向于选第二个选项。

1.2 幻觉：不是在"回忆"，而是在"创作"

很多人误以为大模型像数据库一样在"查找"答案，其实不是。大模型生成文本的过程，本质是一次次的概率采样——给定前面已经写出的内容，预测下一个 token（可以理解为一个字或半个词）的概率分布，然后从中选一个。

这意味着什么呢？意味着哪怕你问的是一个训练数据里确实存在的事实，模型也不是 100% 会原样还原。它可能把张三的事迹安到李四头上，可能把 2021 年的数据说成 2023 年的，可能把"美国"写成"加拿大"。这种"细节漂移"在大模型身上非常常见，越是长文本生成越严重。

更危险的是结构性幻觉。比如你让模型总结一份合同，它会"读"出根本不存在于合同里的条款——但这些条款在结构上、措辞上完全符合合同该有的样子，所以读的人很难立刻发现是假的。在张磊那个案例里，ChatGPT 编出来的"每月自动续费"就是典型的结构性幻觉：它完美契合用户提问的语境，又完美符合合同中常见的句式。

1.3 私有数据盲区：再博学的教授也没读过你的笔记

第三个局限是最致命的：大模型没有读过你的私有数据。

不管模型参数量多大、训练数据多丰富，它不可能见过你们公司内部的合同、产品手册、技术文档、客服工单、Slack 聊天记录、Confluence 页面。这些数据要么存在于公司内网，要么涉及商业机密，根本不可能喂给公共的大模型去训练。

但企业的真实业务场景，恰恰高度依赖这些私有数据。一个客服系统如果只能回答通用知识，那它还不如直接放一个维基百科链接；一个法律助手如果不能引用本事务所的判例库，那它就只是个法学院学生而不是执业律师。

把三个局限放在一起看，问题就很清楚了：

• 模型有知识截止 → 它不知道最新发生的事
• 模型有幻觉 → 它会编造看起来很真的内容
• 模型看不到私有数据 → 它无法回答真正跟业务相关的问题

这三个局限单独出现都不致命，叠加起来就成了"幻觉现场"——模型会用陈旧的知识，用编造的内容，去回答它本不该回答的私有问题，并且说的时候还特别自信。

---

二、开卷考试：大模型最优雅的解题方式

理解了三个局限之后，下一步自然是：怎么解决？

如果你回忆一下自己上学时候的经历，答案其实呼之欲出。

2.1 一个让你恍然大悟的比喻

想象两个学生参加同一场考试。

学生 A（闭卷）：所有知识都靠记忆。考试时不能翻书，只能把脑子里装的东西倒出来。优点是反应快；缺点是记忆会出错，会遗忘，遇到没背过的题就开始胡编。

学生 B（开卷）：可以带参考书进考场。考试时遇到不会的题，先翻书找到对应章节，再结合自己的理解组织答案。优点是答案准确、可追溯；缺点是得先把书准备好，而且考试时翻书会花点时间。

传统的大模型就像学生 A——所有"知识"都压缩在参数里，考试时只能靠记忆答题。这就是为什么它会有幻觉、会遗忘、答不了私有问题。

RAG（Retrieval-Augmented Generation，检索增强生成）就是让学生 B 走进考场：考试时允许"翻书"。这里的"书"，就是企业的私有文档库、产品手册、合同库、客服 FAQ 等等。

用工程语言来说，RAG 让大模型在生成答案之前，先去检索相关的资料，把检索到的内容作为上下文（context）拼到 prompt 里，再让模型基于这些上下文生成回答。这样一来：

• 模型不会凭空编造，因为它"眼前"有真实资料可参考
• 模型可以回答最新问题，因为资料库可以实时更新
• 模型可以回答私有问题，因为资料库就是企业自己的

这个比喻虽然简单，但它几乎完美刻画了 RAG 的本质。后面我们会发现，RAG 所有的工程优化、所有的复杂架构、所有的论文研究，都可以追溯到这个"开卷考试"的核心思想。

2.2 一个让你一目了然的流程图

为了把"闭卷"和"开卷"的区别画清楚，我们用一个流程图来对比：

```mermaid flowchart LR subgraph Closed[闭卷考试：传统 LLM] A1[用户提问] --> A2[大模型] --> A3[直接生成回答<br/>依赖训练知识] end subgraph Open[开卷考试：RAG] B1[用户提问] --> B2[检索模块<br/>查找参考资料] B2 --> B3[从知识库<br/>召回相关片段] B3 --> B4[拼装 Prompt<br/>问题+参考资料] B4 --> B5[大模型] --> B6[基于参考资料<br/>生成回答] end ```

你看，左边那条路和右边那条路的区别，就是中间多了"检索"和"拼装"两步。这两步看似不起眼，却把模型的"必答题"变成了"开卷题"。

2.3 为什么是"现在"才火？

RAG 这个概念其实并不是新东西。它的学术雏形可以追溯到 2020 年 Facebook AI 发表的论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》。但那时候大模型还处于 GPT-2 时代，检索技术也还不够成熟，RAG 只是一个学术概念。

真正让 RAG 火起来的，是两件事在 2023 年同时成熟：

1. ChatGPT 级别的生成模型出现：模型的指令遵循能力、长文本理解能力达到了"开卷答题"够用的水平。如果模型连 prompt 都读不懂，RAG 也白搭。 2. 向量数据库（Vector Database）走向成熟：以 Pinecone、Weaviate、Chroma、Milvus 为代表的向量数据库，让"从百万文档里秒级找到相关段落"变成了开箱即用的工程能力。

两件事叠在一起，RAG 才从论文走进了生产线。2023 年下半年开始，几乎所有做大模型应用的公司——从硅谷的 Notion、Anthropic，到国内的字节、阿里、腾讯——都把 RAG 作为企业落地的默认起点。

---

三、RAG vs Fine-tuning：为什么企业更爱 RAG

聊到这，可能有读者会问：让模型学习私有知识，不是还有另一条路吗——微调（Fine-tuning）？没错，微调是另一条主流路线。但在企业落地时，绝大多数情况下，RAG 是更优先的选择。为什么？

3.1 两条路线的本质区别

我们用一个具体的场景来对比：让模型回答"贵公司的年假政策是什么？"

Fine-tuning 路线：准备几千条"问题-标准答案"对，用这些数据对模型进行额外训练，把答案"灌进"模型的参数里。训练完后，模型的参数变了，年假政策的知识被"刻"进了它的"脑子"。

RAG 路线：把公司的年假政策文档放进向量数据库。提问时，先从数据库里检索到对应的政策条款，再把条款和问题一起交给模型，让模型组织成自然语言回答。模型的参数没变，只是"考试时桌上多了几份参考资料"。

两条路的目标看似一样（让模型能答对私有问题），但工程上的差异是巨大的。

3.2 五个维度的对比

我们从五个维度对比一下两种方案：

| 对比维度 | Fine-tuning（微调） | RAG（检索增强生成） | |---------|---------------------|---------------------| | 数据准备成本 | 需要数千条高质量问答对，标注成本高 | 只需要原始文档，自动切分即可 | | 知识更新成本 | 模型重新训练，GPU 小时数 × 几万元 | 重新入库或更新文档，几分钟搞定 | | 可解释性 | 答案来自模型参数，无法追溯依据 | 答案附带引用文档，可逐条核查 | | 数据隐私 | 数据进入了模型参数，可能被反向提取 | 数据保留在向量库，不进入模型参数 | | 通用能力 | 微调可能导致"灾难性遗忘"，损失通用能力 | 不修改模型，通用能力完全保留 |

逐条解读一下：

数据准备成本：微调需要的不是"原始文档"，而是"问题-答案"对。比如你不能直接把《员工手册》扔给模型训练，你得请人把手册改写成"问：年假有几天？答：5 天"这样的格式。改写 1000 条这样的问答对，对一个中型企业来说就是几周到几个月的人力投入。RAG 完全不需要这一步，把手册 PDF 扔进去就行。

知识更新成本：这是企业最痛的点。如果公司年假政策从 5 天改成 7 天了：

• 微调方案：你需要重新准备数据、重新训练、重新部署。整个流程少则几天，多则几周。
• RAG 方案：把文档里"5 天"改成"7 天"，重新跑一遍入库脚本，几分钟上线。

可解释性：这是法律、金融、医疗等高合规行业最在意的特性。用户问"为什么能这么判断"，RAG 可以直接列出"依据《员工手册》第 12 条第 3 款"，微调做不到这一点——答案已经"融"进了模型参数里，没有人知道它为什么这么答。

数据隐私：这一点至关重要。把客户合同喂给模型做微调，意味着客户的敏感信息永久地写进了模型参数。即使你删掉了训练数据，也无法把模型里的痕迹抹掉——这是深度学习的基本特性。而 RAG 方案下，合同始终在你的向量数据库里，模型本身"看不见"也没"记住"这些内容，审计和删除都非常方便。

通用能力：微调最大的副作用是"灾难性遗忘"——模型在你自己的数据上练得越多，它原本的通用能力（写作、推理、代码）就越容易退化。RAG 不修改模型参数，模型的通用能力永远在线。

3.3 不是二选一，而是组合拳

需要强调的是，RAG 和微调不是非此即彼的关系。

在很多成熟的工业级方案里，工程师会同时使用两者：

• **微调**用来给模型注入"风格"和"领域语言习惯"。比如让模型学会用法律行业的术语来表达。
• **RAG** 用来给模型注入"事实"和"最新信息"。比如让模型引用最新的判例库。

这种"微调 + RAG"的组合拳，既保留了模型的领域专业感，又确保了答案的事实准确性和可解释性。但作为入门，我们先掌握 RAG 这一条主线就足够了——它是 80% 企业场景的"默认答案"。

---

四、RAG 的三大步骤：检索、增强、生成

现在我们把 RAG 的内部结构拆开看看。虽然前面的流程图里只画了"检索"和"拼装"两步，但在工程实现里，RAG 系统通常被分为三大步：检索（Retrieve）、增强（Augment）、生成（Generate）。这三个英文单词的首字母正好组成 RAG。

4.1 第一步：检索——从海量文档里捞出相关的几段

目标：给定用户的提问，从企业的文档库中找出最相关的几段内容。

关键挑战：企业的文档库可能是几万份 PDF、几十万条工单、上百万行代码——要在几百毫秒内找出与提问最相关的几段。

核心技术：向量检索（Vector Search）。

简单来说，向量检索的流程是这样的：

1. 把文档切成小块：一份 100 页的合同不能整段检索，得切成 500 字左右的小块（chunk）。 2. 把每个小块变成一个向量：用一个 Embedding 模型（比如 OpenAI 的 text-embedding-3-small）把每个小块转换成一串数字（通常是 1536 维或 768 维）。这串数字可以理解为这块文本的"语义指纹"。 3. 把用户的问题也变成向量：用同一个 Embedding 模型，把"年假有几天"也变成一串数字。 4. 找最相似的几个向量：在向量数据库里，找到与问题向量最相似（通常用余弦相似度衡量）的 K 个文档块。

直觉上，语义相近的文本，它们的向量在多维空间里也"靠得近"。所以"年假有几天"这个问题的向量，会自然靠近"员工每年享有 5 天年假"这段文本的向量。

常见误区：检索不是简单的"关键词匹配"。传统的 Elasticsearch 也能搜文档，但它只能匹配字面上的关键词。向量检索能匹配"语义"——比如你搜"放假"，它能找出含"年假""休假""带薪假"的段落。这是 RAG 比传统搜索强大得多的关键原因。

4.2 第二步：增强——把检索结果塞进 Prompt

目标：把检索到的几段内容拼到用户提问的前后，形成一个新的、给大模型看的 prompt。

这一步听起来很简单，就是"复制粘贴"。但工程上有不少讲究。

典型的 Prompt 模板长这样：

``` 你是一个专业的企业知识助手。请基于以下参考资料回答用户的问题。 如果参考资料中没有答案，请直接说"我不知道"，不要编造。

【参考资料】 {context}

【用户问题】 {question}

【你的回答】 ```

这里的 `{context}` 就是检索到的几段文档，`{question}` 是用户的原始问题。

几个工程细节值得注意：

• **顺序问题**：把参考资料放在问题前面还是后面？经验上放在前面效果更好，因为大模型对 prompt 前段的注意力通常更高。
• **引用标注**：如果在 prompt 里给每段资料编号（比如 [1]、[2]、[3]），并要求模型在回答时标注引用来源，最终输出的可解释性会大幅提升。
• **长度限制**：大模型的上下文窗口是有限的（GPT-4 是 8K/32K/128K token，Claude 3 是 200K）。检索出来的内容如果太多，需要做截断或重排序。
• **"我不知道"指令**：这一行非常关键。如果不加这句，模型在资料里找不到答案时，会倾向于"硬编一个"。加了之后，模型会更诚实地承认"资料里没说"。

4.3 第三步：生成——大模型基于资料作答

目标：让大模型读懂拼装好的 prompt，生成最终回答。

这一步其实没什么"新东西"——就是普通的 LLM 调用。但正因为前面两步给模型提供了高质量的参考资料，模型在生成阶段的"幻觉率"会大幅下降。

为什么？因为模型在生成时，参考资料里的字面 token 会显著提升这些 token 在预测分布中的概率。简单来说，模型在写答案时，会"倾向于"重复参考资料里出现过的事实，而不是自创。这并不是因为模型"诚实"，而是因为从统计概率上，照抄资料里的字是概率最高的选择。

但要注意：即使有了 RAG，幻觉也不会被完全消除。我们会在后面的章节专门讨论"为什么 RAG 还是会出错"以及"如何评估 RAG 系统的可靠性"。

4.4 一个完整的 RAG 调用链

把这三步串起来，一个完整的 RAG 调用就是：

1. 用户提问："公司年假有几天？" 2. 检索阶段：Embedding 模型把问题变成向量 → 向量数据库找出最相似的 3 个文档块 3. 增强阶段：把 3 个文档块填进 Prompt 模板 → 拼成完整的 prompt 4. 生成阶段：把 prompt 发给大模型 → 大模型返回答案 → 同时附带引用来源 5. 展示阶段：前端把答案和引用一起呈现给用户

整个过程在生产环境里，端到端延迟通常在 1-3 秒之间（取决于检索耗时和模型生成耗时）。

---

五、30 行代码跑通第一个 RAG Demo

光说不练假把式。下面我们用不到 30 行代码，在本地跑通一个真正能用的 RAG 问答系统。

我们会用 LangChain 这个目前最主流的大模型应用开发框架，搭配 OpenAI 的接口和 Chroma 这个轻量级向量数据库。

5.1 准备工作

在跑代码之前，你需要：

1.