当大模型开始"说胡话"——RAG复兴的那个夜晚

当大模型开始"说胡话"——RAG复兴的那个夜晚

2023 年 5 月的一个周五晚上 11 点，深圳某金融科技公司的技术总监林启明正盯着大屏幕上的客服对话流，额头上渗出了细密的汗珠。他们用了三个月时间、花了近两百万训练和微调费用打造的"智能信贷顾问"——"慧贷"——在当天下午四点正式灰度上线，覆盖了 10% 的日活用户。原本预期是一场"用大模型重塑金融服务体验"的漂亮仗，但到晚上九点，运营团队在三个小时内连续收到了 47 条紧急客诉。

客诉的内容触目惊心。有用户截图显示，慧贷信誓旦旦地告诉客户"我们支持以贷换贷，年化利率最低可达 2.88%"；有用户被告知"只要社保连续缴满 3 个月，无需任何抵押即可申请 50 万额度"；更离谱的是，一位接近准客户的用户在聊天记录里截到了这样一句话——"根据央行 2023 年新规，本平台所有信贷产品已纳入存款保险保障范围"。最后这一条直接上了当晚的财经自媒体推文，被解读为"又一家平台暴雷前兆"。

林启明点开模型的生成日志，看到那些话术并不是用户输入的——它们是模型在没有任何事实依据的情况下，顺着上下文"续写"出来的。这就是大语言模型行业里那个臭名昭著、却又因为难以根除而被反复讨论的现象：幻觉（Hallucination）。

七十二小时之后，林启明的团队没有重训模型、没有更换基座、没有抛弃大模型路线，而是上线了一套看似朴素、却彻底改变了"慧贷"命运的方案：检索增强生成（Retrieval-Augmented Generation, RAG）。上线后第一周，幻觉相关的客诉从 47 条降到了 3 条；一个月后，这个数字稳定在每周 1 条以下。那个差点让产品经理当场辞职的夜晚，后来被团队戏称为"慧贷 1.0 的至暗时刻"，也成了林启明职业生涯里一次彻底的范式转折——他从那以后坚信一件事：大模型不能裸跑。任何把它直接暴露在最终用户面前的工程决策，都应当被视为一种疏忽。

本章的使命，就是把这个故事背后那条更深层的逻辑链拆开。我们会回答三个看似简单、实则决定整个行业走向的根本问题：

• 为什么大模型的能力越强，幻觉的代价反而越高？
• RAG 究竟是在"修补"模型的缺陷，还是在重新定义模型的角色？
• 为什么我们必须用工程化的思维，而不是算法思维，去对待 RAG？

读完这一章，你会形成一种判断：RAG 不是一个技巧，而是一种架构哲学——它把"知识—检索—生成"这条链条变成了一条可观测、可控制、可问责的工程管道。这是后续十四章所有内容的地基。

---

一、幻觉的代价——为什么"一本正经胡说八道"是结构性问题

要理解 RAG 为何在 2023 年之后忽然成为整个 AI 工程界的主旋律，我们必须先理解幻觉为什么不是 bug，而是 feature——它是 Transformer 架构和训练目标在数学上的必然产物。

1.1 从优化目标看幻觉的必然性

大语言模型的训练目标，说到底只有一句话：在给定前文的情况下，最大化下一个 token 的条件概率。无论是 GPT、LLaMA 还是 Qwen，它们的损失函数都形如：

$$\mathcal{L} = -\sum_{i=1}^{N} \log P_\theta(x_i \mid x_{<i})$$

这是一个语言建模损失。它优化的是"流畅性"和"统计合理性"，而不是"事实正确性"。模型学到的是："在人类的写作中，什么样的句子最可能出现在这里"，而不是"在现实世界中，什么样的陈述是真的"。

这两件事在大多数时候恰好重合——因为人类写作本身就倾向于陈述真实信息。但只要上下文出现了某种"信息真空"，模型就会自然地填补它，而填补的依据是"什么最像真的"，而不是"什么是真的"。这就是为什么幻觉特别容易发生在以下几类场景：

1. 训练数据截止之后的时事：模型被问到 2024 年的政策，但它的训练数据停在 2023 年 10 月，它不会说"我不知道"，而会编一个听起来合理的版本。 2. 私域知识：模型从未见过某公司的内部产品手册，于是它根据通用知识"合理推断"，给出一个似是而非的答案。 3. 长尾实体：被问到某个只有 200 人知道的小镇的历史沿革，模型会用通用语料拼接出一个听起来权威的描述。 4. 多跳推理的中间步骤：模型需要链式推理时，会在中间步骤出错，而错误会被后面的步骤进一步放大。

林启明的"慧贷"几乎完美地踩中了所有这四类场景：金融政策更新极快、私域产品手册繁多、用户问题往往涉及具体到县级市的政策细节、贷款决策链条又常常涉及多步推理。模型的"创造能力"在这里不是优点，而是灾难。

1.2 幻觉的成本不对称性

工程上对幻觉最危险的认知，是把它等同于传统软件的"bug"。不是的。传统 bug 表现为程序崩溃或返回错误码，它的存在本身是可观测的；而幻觉表现为一段流畅、自信、语法完美、看起来权威的回答。在客服场景里，这种"自信"会被用户解读为"专业"，从而放大了错误信息的传播半径。

我们可以用一个简单的成本模型来说明这种不对称性。假设一个模型回答正确率是 95%，错误率是 5%。在一个低风险场景（比如聊天机器人陪你闲聊），5% 的错误几乎无人在意；但在一个高风险场景（比如医疗建议、金融咨询、法律解释），每一次错误可能意味着：

• 用户的真实经济损失
• 公司品牌的不可逆伤害
• 监管层面的合规风险
• 个别情况下的生命安全

而模型却对此毫无感知。它不会因为刚才说错了话而降低自信度，反而会以同样的语气继续输出。这才是幻觉最让人不安的地方——它的失败模式在视觉上和成功模式不可区分。

林启明事后在内部复盘里写了一段话，后来被他们团队奉为信条：

> "我们以为自己在用大模型做客服，其实是在用大模型赌客服。每一句没有事实依据的输出，都是一次没有保额的事故。"

1.3 那些年我们一起追过的"反幻觉"幻觉

在 RAG 重新成为显学之前，业界其实已经尝试过很多方法来压制幻觉。最常见的包括：

• **更大的模型**：人们一度以为模型足够大，幻觉就会消失。但事实证明，模型变大之后，"自信地胡说八道"的能力也变大了。
• **更好的微调**：用人类反馈强化学习（RLHF）让模型更"谨慎"。这确实降低了模型胡说八道的频率，但代价是模型开始大量说"我无法回答"——在客服场景里，这等于把用户推给了人工，并不解决根本问题。
• **链式思维提示（Chain-of-Thought）**：让模型"一步一步想"。这在数学推理上有奇效，但在事实性问题上，反而可能让模型在错误推理链上越走越远。
• **事实性评估后处理**：在生成之后用一个独立的"裁判模型"去检查事实性。这个方法在某些场景下有效，但它的裁判模型本身也会幻觉，于是我们进入了"用幻觉检查幻觉"的无限递归。

所有这些方法的共同特点是：它们都在模型的"生成阶段"做文章。而林启明的团队在 72 小时之内意识到的核心洞察是——问题不在于生成阶段，而在于模型的输入阶段。模型之所以幻觉，是因为它不知道。它不知道正确的政策文件内容，所以它编了一个。如果我们在它生成之前，就把正确的政策文件喂给它呢？

这就是 RAG 的第一性原理：用外部知识，弥补模型参数化记忆的不完整性和时效性。

---

二、RAG 的三段论——检索、增强、生成

RAG 的概念在 2020 年由 Facebook AI 的 Patrick Lewis 等人在论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中正式提出。但它的工程形态远比论文里的简化版本复杂。一个真正能在生产环境扛住流量的 RAG 系统，本质上是一条由三个紧密耦合的子系统构成的流水线：检索（Retrieval）、增强（Augmentation）、生成（Generation）。

2.1 检索：从模糊意图到精准证据

检索阶段的任务是：给定用户的 query，从一个庞大的知识库中找出最相关的若干条文档（或段落），作为后续生成阶段的"事实弹药"。

听起来简单，但工程上的复杂度远超想象。检索的目标不是"召回尽可能多的相关内容"，而是"在保证召回的前提下，把最关键的那几条送到 LLM 面前"。因为上下文窗口是稀缺资源——你不可能把整个知识库塞给模型，你只能送入有限的 top-k 个片段。

现代 RAG 系统中的检索，通常由以下几个层次组成：

1. 粗召回层：用向量检索（dense retrieval）、倒排索引（sparse retrieval，如 BM25）或两者的混合（hybrid retrieval），从百万级文档里快速圈出 top-100~1000 的候选。这一层的关键是速度和召回率。 2. 精排层（reranker）：用一个跨编码器模型（如 bge-reranker、cohere rerank）对粗召回的结果重新打分，选出 top-3~10 的最终片段。这一层的关键是精准度，它决定了 LLM 拿到的"弹药"质量。 3. 预处理层：对最终选中的片段做截断、去噪、模板化等操作，使其适配下游 prompt 的格式要求。

一个常见的误区是：很多团队只做了第一层就以为自己在做 RAG 了。但真正的差距往往出在第二层。一份来自 LangChain 的社区调研显示，那些在生产环境表现稳定的 RAG 系统，几乎都在重排序上投入了大量工程精力；而那些频繁出问题的系统，往往只跑了一层向量召回就草草了事。

2.2 增强：把检索结果"嫁接"到 prompt 里

增强阶段是 RAG 最容易被低估、却最决定最终输出质量的环节。它的核心问题是：如何把检索到的片段，与用户的原始 query 一起，组织成一个 LLM 能够稳定遵循的 prompt？

这不是"复制粘贴"那么简单。一个高质量的增强 prompt 需要处理至少五类子问题：

• **相关性排序**：把最相关的片段放在最前面，还是最后面？研究表明，LLM 对上下文窗口的不同位置有不同的敏感度——开头的片段往往被赋予更高权重，这种现象被称为 "lost in the middle"。
• **冲突解决**：如果检索到的多个片段之间存在矛盾（比如政策文件的新旧版本），应该以哪一个为准？这需要引入元数据（如文档时间戳、版本号）作为冲突仲裁的依据。
• **截断与压缩**：当检索到的片段总长度超出 LLM 的上下文窗口时，怎么取舍？是按 token 数硬切，还是先用一个小模型做一次摘要压缩？
• **来源标注**：在 prompt 中明确告诉模型"以下信息来自 XXX 文档，发布于 YYYY-MM-DD"，这样模型在生成答案时会自然倾向于引用和尊重这些信息。
• **指令注入**：在 prompt 中显式声明"如果以下信息不足以回答问题，请直接说不知道，不要编造"。这就是工程上常说的"anti-hallucination prompt"。

林启明团队在 72 小时冲刺里做的第一版 RAG，几乎只做了"检索 + 拼接"两步。但他们很快发现，仅仅这样还不够——模型在拿到文档后，仍然会在某些边缘问题上"自由发挥"。最终让幻觉率显著下降的关键改动，是他们在 prompt 里加入了严格的指令约束和文档引用规范。这一步看似不起眼，却把幻觉率又砍掉了 60%。

2.3 生成：让 LLM 做一个克制的"编辑"

到了生成阶段，RAG 系统的故事其实已经讲完了大半。剩下的，是让 LLM 严格扮演它在这个架构里应有的角色：一个有据可依的编辑，而不是一个天马行空的作家。

但即使到了这一步，工程上仍然有大量可以优化的空间：

• **温度参数（temperature）**：在事实性任务上，温度应该被压低到 0 或接近 0，以最大化输出的确定性和可复现性。
• **结构化输出**：通过 JSON schema 或 grammar-constrained decoding，强制模型输出包含引用编号、置信度评分等元信息的结构化响应，便于下游做事实核查。
• **引用追溯**：让模型在回答中明确标注每条信息的来源文档编号。这样做有两个好处：一是用户可以验证，二是后处理系统可以自动核查每条引用是否真的来自检索片段。
• **拒答策略**：当检索系统没有召回任何相关文档时（top-1 相似度低于某个阈值），系统应当选择拒答，而不是强行让模型基于"几乎无关"的文档生成答案。

这三个阶段合在一起，构成了 RAG 的工程主干。它看似只有三个单词，但每个单词背后都是一整套需要被精密设计、持续监控、随时迭代的子系统。这就是为什么我们说 RAG 不是一个技巧，而是一项工程。

下面这张流程图展示了一个生产级 RAG 系统的典型工作流，它把上面讨论的每个组件都映射到了具体的步骤上：

```mermaid flowchart LR A[用户Query] --> B[Query预处理<br/>改写/扩写/HyDE] B --> C[粗召回<br/>BM25 + 向量检索] C --> D[候选文档Top-K<br/>通常K=100~1000] D --> E[精排Reranker<br/>Cross-Encoder] E --> F[Top-N片段<br/>通常N=3~10] F --> G[Prompt组装<br/>指令+上下文+Query] G --> H[LLM生成] H --> I[后处理<br/>引用校验/拒答/格式化] I --> J[最终答案] ```

注意这张图里省略的"细节"比画出来的还要多：每个箭头背后都可能藏着一套独立的微服务、一套缓存策略、一套 A/B 测试框架、一套监控告警。在后续章节里，我们会逐层把这张图展开。但在此之前，我们先要回答一个更根本的问题——为什么我们必须用工程的思维去对待 RAG，而不是算法的思维？

---

三、工程视角的 RAG——把 LLM 从"创作者"变回"编辑者"

工程思维和算法思维的根本区别，在于你对"系统"边界的定义不同。

算法思维倾向于把系统边界画在模型本身：给定一个模型，它的输入是 query，输出是 answer，中间的一切都是"模型内部的事"。在这种视角下，提升系统性能的唯一手段是改进模型——更大的参数量、更多的训练数据、更巧妙的损失函数。这种思维在深度学习的黄金十年里几乎是唯一正确的范式，它推动了从 ResNet 到 GPT-4 的一波又一波突破。

但 RAG 强制我们把系统边界往外推：模型不再是孤岛，它被嵌入到一个更大的、由检索器和知识库构成的生态系统里。在新的视角下，模型的能力只是一个必要条件，而不是充分条件。决定系统最终表现的，是这条"知识—检索—生成"链条上的每一个环节。

3.1 一次思想实验：LLM 是 CPU，知识库是内存

让我用一个工程上更熟悉的类比来澄清这个转变。如果你把 LLM 看作一台 CPU，那么 RAG 就是在为这台 CPU 配备可寻址的外置内存。

CPU 本身有"指令缓存"（对应 LLM 的参数化记忆），但它容量有限、不可更新、且充满压缩失真。RAG 给 LLM 配上了"主存"（向量数据库）和"二级存储"（原始文档库），让模型在每次推理时都能按需加载最相关的事实数据。

这个类比带来三个深刻的工程启示：

1. 关注内存的延迟和带宽：在 CPU 体系里，决定性能的不是 ALU 的频率，而是内存子系统的设计。同理，决定 RAG 系统表现的不是 LLM 的参数量，而是检索子系统的延迟、吞吐和精度。 2. 关注内存的一致性：当知识库更新时（CPU 视角下的 cache invalidation），如何保证检索子系统返回的永远是最新版本？这是个分布式系统问题，不是机器学习问题。 3. 关注内存的访问模式：哪些数据应该被预取（prefetch）、哪些应该被淘汰（eviction）、哪些应该被压缩（quantization），这些数据库领域的经典问题，在 RAG 时代一一复活。

这个类比还能解释为什么微调（fine-tuning）不能完全替代 RAG。微调相当于把数据写进了 CPU 的"指令缓存"——容量小、不可热更新、且容易污染原有指令集（灾难性遗忘）。RAG 相当于把数据放在可寻址内存里——容量大、随时更新、不污染模型本身。两者解决的是不同的问题，前者改变"能力"，后者改变"知识"。

3.2 编辑者 vs. 创作者：角色定位的范式转移

从 LLM 的角色定位上看，RAG 实际上完成了一次深刻的范式转移：把 LLM 从一个"创作者"（author），重新定位为一个"编辑者"（editor）。

在创作者角色下，模型被要求独立产出内容——这是它在创作类任务（写诗、写小说、写营销文案）上的理想角色。在这种角色下，幻觉不是 bug，而是 feature，因为它体现了模型的"创造性"。

但在企业级知识问答场景下，用户需要的是事实，不是创意。这时，模型的正确角色是编辑者：它的工作是基于已有的、可追溯的事实材料，组织出一份清晰、准确、有据可查的回答。它的"创作空间"被严格限制在"如何表达"上，而不是"说什么"上。

林启明团队在 72 小时冲刺后期做的最重要的一次 prompt 改动，就是把系统提示词从"你是一个友好的信贷顾问"改成了"你是一个严格基于所提供文档回答问题的金融信息编辑，任何超出文档范围的内容都不得编造"。这一字之差，让模型的输出风格从"自由发挥"彻底转向了"克制度量"。

这种角色定位的转移，对整个 RAG 系统的设计都有深远影响：

• **评估指标的转变**：从"流畅度"转向"事实准确率"和"引用覆盖率"。
• **错误分析的转变**：从"模型为什么生成错了"转向"检索为什么没召回正确的文档"。
• **优化的转变**：从"调参调 prompt"转向"改文档分块策略、改 embedding 模型、改 reranker"。

3.3 工程化的本质：可观测、可控制、可问责

最后一个，也是最关键的：为什么 RAG 必须是工程化的？因为企业级应用对系统的要求，本质上是三个"可"——可观测、可控制、可问责。

• **可观测**：当用户报告"慧贷"给了错误答案时，工程师必须能在几分钟内定位：是检索器召回了错误的文档？是 reranker 把无关文档排到了前面？是 LLM 忽略了检索结果？还是文档本身就过时了？没有可观测性，所有这些问题都无法回答。
• **可控制**：当产品经理决定下架某条过时的贷款政策时，工程师必须能立刻让所有相关 query 都停止召回这条文档。这要求知识库有版本管理、有灰度发布、有紧急下架机制——这些都是工程问题，不是算法问题。
• **可问责**：当一个错误的回答导致用户损失时，法务和合规部门必须能精确追溯：