为什么大模型需要 RAG？一个不得不补的课
为什么大模型需要 RAG？一个不得不补的课
ChatGPT 写诗写代码写邮件，看起来无所不能。但你只要把它扔进企业里，让它回答"我们公司去年的差旅报销标准是什么"或者"客户合同里关于违约金的条款是怎么写的"，它大概率会一脸认真地给你编一份看起来非常合理、实际上完全不存在的内容。
这种"一本正经地胡说八道"的现象，业内有个专门的术语叫幻觉（Hallucination）。它不是模型偶尔的 bug，而是大语言模型（LLM）原生的、与生俱来的特质。你不能通过"再训练几天"来消灭它，只能通过工程化的手段去约束它。RAG（Retrieval-Augmented Generation，检索增强生成） 就是当前最主流、性价比最高的一种约束手段。
这一章，我们要回答一个看起来朴素但至关重要的问题：为什么大模型不能直接用，必须搭配一套检索系统？如果你正在评估要不要上 RAG、或者领导问你"为什么非得搞这么复杂"，这一章就是你的弹药库。
1.1 大模型的"三大原罪"：它为什么总会犯错？
要理解 RAG 的必要性，得先理解原生 LLM 的三个结构性问题。这三个问题被业界戏称为"原罪"，因为它们不是 Bug，而是 Feature——是大模型这种技术范式与生俱来的代价。
1.1.1 知识截止：模型活在"过去"
大模型的知识全部来源于训练数据，而训练是有截止日期的。GPT-4o 的训练数据截止到 2023 年 10 月，Claude 3.5 截止到 2024 年 4 月，国内的通义、文心、混元等模型同样存在半年到一年的滞后。
这意味着什么？意味着当你问它"今天北京天气怎么样"，它只能回答"抱歉，我无法访问实时信息"。当你问它"2024 年欧盟 AI Act 的最新条款"，它可能给你一份基于草案推测出来的"合理想象"。当你问它"我们公司上周发布的财报"，它压根不知道这家公司存在。
知识截止不是一个能用"加大训练量"解决的问题。哪怕你把全互联网的数据都喂进去，也总有比你训练时间更晚的事情发生。模型越大、训练越贵，时效性问题反而越突出，因为重训一次的周期和成本根本跟不上信息产生的速度。
更麻烦的是，模型对截止日期之后的内容并不是"沉默"，而是倾向于"补全"——用训练时学到的语言模式，硬生生给你生成一个看起来像那么回事的答案。这就是幻觉的温床之一。
1.1.2 私域盲区：模型没读过你的数据
第二个原罪是私域知识缺失。LLM 在公开互联网上训练，吃的是维基百科、Reddit、GitHub、新闻网站这些"公粮"。但任何一家企业都有自己的内部知识：产品手册、技术文档、客户案例、合规规范、会议纪要、代码仓库、工单系统……这些数据要么在防火墙内，要么根本没上网，模型天然看不见。
举个最常见的例子。一家做 SaaS 产品的公司，他们的产品有 200 多个功能点，每个功能点都有详细的 API 文档和使用示例。客服团队想用大模型做一个智能助手，能自动回答客户"我该怎么集成你们的支付模块"。这时候不管你用 GPT-4 还是 Claude 3.5，它都答不上来——因为这些文档根本没出现在训练数据里。
有人会想：那我把文档喂给模型不就行了？嗯，欢迎来到"上下文窗口"的另一个原罪。LLM 的上下文窗口虽然越来越大（GPT-4 Turbo 128K，Claude 3.5 200K，Gemini 1.5 Pro 100 万），但把 200 个功能点的完整文档塞进去，问一个问题，要消耗几万甚至几十万的 token。成本先不说，模型在超长上下文里的"中间遗忘"现象依然严重——研究显示，当关键信息被埋在长文本中间时，模型的检索准确率会显著下降。
所以私域知识的问题，单纯靠"塞上下文"也不解决。必须有一套外部的、按需检索的机制。这就是 RAG 存在的根本理由之一。
1.1.3 幻觉：模型的"创造性"是把双刃剑
第三个原罪是幻觉，也是最让人头疼的一个。幻觉指的是模型生成的内容语法流畅、逻辑自洽，但事实层面是错误的或根本不存在的。
幻觉的成因很复杂，目前主流的解释有几个：
1. 生成式的本质：语言模型本质上是个"下一个 token 预测器"。它在生成时追求的是概率意义上的流畅，而不是事实意义上的准确。它不知道什么是真的，它只知道"这个词后面最可能跟什么"。 2. 训练数据的噪声：训练数据里有错误、有矛盾、有过时信息，模型忠实地学到了这些模式。 3. 过度的归纳能力：模型试图把训练时学到的模式应用到没见过的场景上，结果生成了看似合理但完全虚构的内容。
关键的一点是：幻觉不是模型的缺陷，而是它的副产品。一个完全没有幻觉的模型，也就丧失了创造性和泛化能力。我们不可能消灭幻觉，只能约束它。
而约束幻觉最有效的手段，不是祈祷模型"自觉"，而是给它一个事实依据。告诉它"根据这份文档回答"和"自由发挥"得到的结果，准确率能差出好几个数量级。这就是 RAG 的核心价值——把模型的"自由创作"约束在"给定资料"的范围内。
把这三个原罪放在一起看，你会发现它们其实是同一个问题的三个侧面：大模型是一个"封闭的系统"，它的知识在训练完成的那一刻就固化了，并且永远不会更新。任何超出训练数据的真实信息，它都不可能"知道"，只能"猜"。
1.2 为什么 ChatGPT 这么强，企业用起来还是频频翻车？
很多企业第一次接触大模型时都有类似的体验：用 ChatGPT 写周报、翻译邮件、改文案，效果惊艳。然后老板说"那我们能不能用它做客服？"一试就翻车。
这种"个人场景惊艳、企业场景翻车"的反差，背后有四个具体原因。
1.2.1 个人场景容忍度高，企业场景零容忍
个人用 ChatGPT 写个邮件、改个 bug 提示词，写错了你能看出来也能改。但企业场景里，模型给出的回答如果是错的，轻则误导客户，重则引发法律纠纷。一次幻觉可能毁掉客户对整个 AI 系统的信任，这种成本是没法接受的。
1.2.2 企业场景对"出处"有刚需
企业内部使用 LLM 时，几乎所有的应用都有溯源需求——回答客户问题时要引用知识库，回答法务问题时要引用法规条款，回答技术问题时要引用文档章节。如果模型告诉你"根据《员工手册》第 3.2 条规定……"，但这条规定根本不存在或者被它篡改过了，那这个回答比没有回答更糟糕。
而原生 LLM 是不提供出处的。它的回答是基于参数里的"印象"生成的，没有引用源、没有证据链、没有"我是从哪知道的"。
1.2.3 企业知识是动态变化的
企业知识不是静态的。产品每周迭代、政策每月更新、人员每天变动。一个知识问答系统如果不能实时反映这些变化，回答的准确率会随时间快速衰减。
而原生 LLM 是冻结的——你不能在每次产品更新时都重新训练一遍模型，成本和周期都不可行。
1.2.4 企业对成本和数据安全极度敏感
调用 OpenAI 的 API 看起来便宜，但放到企业级流量下可能完全不一样。一个日活 10 万的客服系统，每次问答消耗 2000 token，光 API 费用一个月就是几百万。这还没算数据出境带来的合规风险——很多行业（金融、医疗、政府）的客户数据是不允许传到境外的，更不允许传给第三方 API。
企业场景对 LLM 的要求可以用四个词概括：准确、可溯源、实时可控、数据安全。这四个要求，单独拎出来原生 LLM 都能勉强应付，但合在一起它就完全扛不住了。
所以问题不是"大模型强不强"，而是"大模型能不能直接用在企业里"。答案是：不能，至少不能裸着用。你需要给它加一层"基础设施"，让它从一个"什么都懂一点的通才"，变成"基于你公司知识的专才"。
这层基础设施有几条路线可选，我们下一节就来横评。
1.3 三种路线横评：纯 Prompt、纯微调、RAG 谁更适合你？
面对"让大模型用上企业知识"这个需求，主流的技术路线有三条：纯 Prompt 工程、模型微调（Fine-tuning）、检索增强生成（RAG）。每条路线都有自己的适用场景和代价，选错了代价非常大。
下面我们用一张决策图来帮你快速定位：
```mermaid flowchart TD Start[企业知识问答需求] --> Q1{需要引用最新文档?} Q1 -->|是| RAG1[首选 RAG] Q1 -->|否| Q2{需要严格的输出格式/特定风格?} Q2 -->|是| FT[考虑 Fine-tuning] Q2 -->|否| Q3{只是简单问答/总结?} Q3 -->|是| Prompt[纯 Prompt 即可] Q3 -->|否| Q4{数据量大且高频?} Q4 -->|是| RAG2[推荐 RAG + 微调混合] Q4 -->|否| Prompt2[Prompt + 少量示例] ```
1.3.1 路线一：纯 Prompt 工程
这是最轻量的路线：不改模型、不训练，只通过精心设计 Prompt，把企业知识"塞"到上下文里，让模型基于这些上下文回答。
优势：
- 零训练成本，几乎零延迟启动
- 知识更新即时生效，改 Prompt 就行
- 实现简单，普通工程师几天就能搭起来
劣势：
- 上下文窗口有限，知识多了装不下
- 关键信息埋在长文本里时，模型容易"中间遗忘"
- 每次调用都要把全部知识传一遍，token 成本高
- 无法处理需要"在海量文档中精准定位"的场景
典型适用场景：
- 知识量小（几十页文档以内）
- 任务简单（总结、翻译、改写）
- 知识更新不频繁
举个具体例子：你要做一个"把会议纪要改成周报"的小工具，会议纪要通常就 1000-2000 字，完全可以塞进 Prompt 让模型改写。这种场景纯 Prompt 就够了，RAG 反而是过度设计。
1.3.2 路线二：模型微调（Fine-tuning）
这条路线的思路是：既然模型不知道你的企业知识，那就把它"喂"进去，让模型通过训练"记住"这些知识。
具体做法是用企业数据继续训练模型（或训练一个 LoRA 适配器），让模型的参数里沉淀这些知识。
优势：
- 知识"内化"在模型里，推理时不需要额外传上下文，token 成本低
- 可以学到特定的输出风格、术语、格式
- 推理延迟低（不需要额外的检索步骤）
劣势：
- 训练成本高（GPU 资源 + 时间 + 调参）
- 知识更新困难——每次新增文档都要重训
- 容易"灾难性遗忘"——学了新知识丢了旧能力
- 幻觉问题依然存在，无法保证事实准确
- 训练数据量大时，微调效果也不一定好
- 对数据量和质量要求高，小样本容易过拟合
典型适用场景：
- 知识相对固定，更新频率低（半年到一年）
- 有大量高质量的"输入-输出"配对数据
- 需要特定的输出风格或格式（比如法律文书风格）
- 已经有专门的 ML 团队能维护训练流程
举个具体例子：一家律所想训练一个"法律文书生成助手"，需要模型学会严谨的法言法语、特定的条款结构。这种"风格和格式"的需求，微调很合适。但如果你想让模型"知道最新的法律法规"，微调就不行——因为法律一直在变，重新训练跟不上。
1.3.3 路线三：检索增强生成（RAG）
RAG 的核心思路是：不修改模型本身，而是在推理时动态地从外部知识库中"检索"相关内容，把它和用户的问题一起拼成 Prompt 喂给模型。
优势：
- 知识更新即时——改知识库就行，不需要重训模型
- 答案可溯源——能告诉用户"这个回答来自哪份文档"
- 幻觉显著减少——模型被约束在"给定资料"范围内
- 实现门槛低——核心组件就三块：检索器、向量库、生成器
- 成本可控——检索是廉价的，生成只处理少量相关内容
劣势：
- 检索质量决定答案质量，garbage in garbage out
- 需要维护一套独立的知识库和检索系统
- 延迟比纯 LLM 高（多了一次检索）
- 对文档切分、嵌入模型选择等工程细节敏感
典型适用场景：
- 知识库规模大（几千到几百万文档）
- 知识更新频繁（日更甚至实时）
- 需要严格的出处和准确性
- 团队没有专门的 ML 训练能力
1.3.4 一句话总结三者的取舍
- **纯 Prompt**：适合"小而美"的场景，能塞进上下文的就 Prompt。
- **微调**：适合"教模型某种风格或格式"，不适合"让模型知道新知识"。
- **RAG**：适合"让模型基于最新/最权威的资料回答"，是企业知识问答的事实标准。
一个反直觉但很重要的判断：微调和 RAG 不是非此即彼的关系，而是可以叠加的。先 RAG 提供事实，再微调塑造风格——这是很多成熟系统的标配。但对刚起步的团队来说，先做 RAG 是最稳妥的选择：成本低、见效快、出问题容易排查。等 RAG 跑通了，再考虑用微调去做风格定制。
1.4 RAG 的核心思想：让模型"查资料"再回答
RAG 的概念其实一点都不复杂，它模仿的就是人类回答问题的方式。
1.4.1 类比：人类是怎么回答专业问题的？
想象一下，你去面试一个算法工程师，面试官问："请解释一下 B+ 树和 B 树的区别。"
你大概率不会立刻凭"记忆"回答，而是会说："让我想一下……" 或者 "根据我之前看过的资料……" 然后你会回忆自己读过的教材、博客、笔记，把这些"检索"到的信息和你的理解结合起来，给出一个有条理的回答。
如果你是一个完全没学过数据结构的人，你可能会强行编一个答案——这就是幻觉。
而 RAG 就是把这个过程显式化、自动化：
1. 检索（Retrieval）：根据用户问题，从知识库里找出最相关的几段资料。 2. 增强（Augmented）：把这些资料和用户问题一起打包成 Prompt。 3. 生成（Generation）：让大模型基于这个"增强过的" Prompt 生成答案。
模型不需要"记住"所有知识，它只需要学会"看资料回答"这个技能。这就是 RAG 名字里"增强"的含义——用外部知识增强模型的回答能力。
1.4.2 一个最简化的 RAG 流程
我们来看一个最朴素的 RAG 系统长什么样。假设你已经有一份企业知识库（可能是产品手册、FAQ、内部 Wiki），整个流程分两步：
第一步：离线准备（数据预处理）
把企业知识库里所有的文档切分成合适大小的段落（通常 200-500 字一段），用嵌入模型（Embedding Model）把每段转成一个向量（一串数字，代表这段文字的"语义"），存到向量数据库里。这个过程是一次性的，文档不变就可以一直用。
第二步：在线问答（实时处理）
用户提了一个问题，系统做这几件事： 1. 把用户的问题也用同一个嵌入模型转成向量。 2. 在向量数据库里搜，找出和这个问题向量最相似的 K 个段落（K 通常是 3-10）。 3. 把这些段落连同用户问题一起塞进 Prompt："请根据以下资料回答用户问题：[检索到的资料] 用户问题：[问题]" 4. 大模型基于这个 Prompt 生成回答。
整个过程的核心思想可以用一句话概括：让模型"带着资料"回答问题，而不是"凭记忆"回答。
1.4.3 为什么这个简单的思路如此有效？
你会发现 RAG 几乎没有用什么"高大上"的技术——它就是检索 + 拼接 + 生成。但它有效，是因为它精准地击中了原生 LLM 的三个原罪：
1. 解决知识截止：知识库可以实时更新，永远是最新数据。 2. 解决私域盲区：企业知识在向量库里，模型随时可查。 3. 缓解幻觉：模型被要求"根据资料回答"，凭空编造的概率大幅下降。
而且 RAG 还有几个"附赠"的好处：
- **答案可溯源**：检索到的段落本身就是引用源，可以直接展示给用户。
- **成本可控**：检索是廉价的，模型只处理最相关的内容，token 消耗大幅下降。
- **实现门槛低**：核心组件都是成熟的开源方案，一个小团队几周就能上线。
理解了 RAG 的核心思想，我们再来看一个反面的问题：RAG 是不是万能的？什么情况下它不适合？
1.5 RAG 的边界：哪些场景它搞不定？
RAG 不是银弹。它在很多场景下表现出色，但也有明显的边界。在你决定上 RAG 之前，必须清楚它的局限性。
1.5.1 边界一：需要"推理"而不是"查找"的场景
RAG 的本质是"找资料"，但有些问题不是查资料能解决的。比如：
- "根据这三份合同条款，推导一下我们公司在 X 项目上的总风险敞口是多少？"
- "对比 A 方案和 B 方案的优缺点，给出选型建议。"
这类问题需要跨文档的逻辑推理，而 RAG 只是把相关段落找出来丢给模型。如果相关段落分散在三份文档的不同章节，模型可能找不全；如果需要复杂的数学计算，模型可能算错。
这种情况下，单纯靠 RAG 不够，往往需要配合一些工程手段：比如先让模型"列出推理步骤"，再针对每一步去检索，或者把推理拆分成多个子问题分头检索再汇总。
1.5.2 边界二：需要"个性化记忆"的场景
RAG 的知识库是公开的、所有用户共享的。但有些应用需要记住每个用户的"私人信息"——比如用户上次问了什么、偏好什么格式、有没有特殊需求。
这种"用户级别的记忆"通常不在 RAG 的知识库里，而是需要单独的"记忆系统"来处理（比如 LangChain 的 Memory 模块，或者自己维护一个用户状态库）。
1.5.3 边界三：实时性要求极高的场景
RAG 是"检索 + 生成"，多了一步检索操作，延迟通常比直接调用 LLM 高几百毫秒。如果你的应用要求响应时间在 200ms 以内（比如高频对话场景），RAG 的延迟可能成为瓶颈。
当然，可以通过异步检索、预缓存等手段优化，但这会增加系统复杂度。
1.5.4 边界四：需要"风格和人格"高度定制化的场景
RAG 解决的是"知识准确"的问题，但它解决不了"输出风格"的问题。如果你的产品需要一个"永远用文言文回答"的助手，或者一个"严格按某种模板输出"的助手，RAG 帮不了你——你得用微调。
这时候典型的方案是 RAG + 微调的组合：RAG 提供事实依据，微调塑造输出风格。
1.5.5 一句话总结 RAG 的适用边界
RAG 擅长的是"基于已有知识回答问题"，不擅长的是"在没有知识的情况下创造新内容"。前者是检索问题，后者是生成问题。混淆这两者，是很多 RAG 项目翻车的根本原因。
如果你要做的应用是知识问答、文档分析、信息提取、客服辅助这类场景，RAG 几乎就是为你量身定做的。如果你要做的是创意写作、复杂推理、个性化对话，RAG 可能只是整个系统的一部分，你需要更多的工程组件来配合。