RAG（Retrieval-Augmented Generation，检索增强生成）是让大模型“先查资料、再组织答案”的一套工作方法：用户提问之后，系统先去指定的知识库里检索出最相关的几段原文，把它们连同问题一起交给模型，模型再基于这些资料生成回答。记住它的基本盘：RAG 不改变模型本身的知识储备，只是给每一次回答临时配上一份“开卷参考资料”——模型记不住的、记错的，用检索到的原文现场补上。
所以当你遇到“模型答得头头是道、但细节全是编的”，或者“公司制度上周刚更新、模型还在背旧版本”，RAG 就是第一个值得考虑的解法。它最适合答案必须有出处的场景：企业知识库问答、产品文档助手、法规政策查询。但它不是万能药——检索不到的、资料本身就是错的，它照样会答错。读完这篇，你会清楚 RAG 到底做了什么、它和微调的边界在哪、以及什么时候不该用它。
RAG 的两步：先检索，再生成
RAG 的名字已经把流程说全了，分两步走。
第一步在提问之前就完成，叫“建索引”：把知识库里的文档切成小段（比如每 500 字一段），每一小段转成向量存进向量数据库。向量可以粗暴地理解成“语义坐标”——意思相近的段落，在坐标系里离得近。这一步做一次就行，之后文档更新了再增量处理。
第二步发生在每次提问时：用户的问题同样转成向量，去库里找出语义最接近的几段（通常 3 到 5 段），把这些原文拼在问题前面，一起发给大模型。模型看到的不再是光秃秃的问题，而是一个“问题 + 参考资料包”，回答自然就有了依据。
举个具体的例子：公司内部的报销制度问答。员工问“出差住宿标准是多少”，系统从制度文档里捞出“住宿标准”那几段，模型照着原文回答“一线城市每晚不超过 800 元”，而不是凭训练时的模糊记忆瞎猜。答案对了，还能顺手标出出处。
一句分清 RAG 和微调：一个外挂知识，一个改造大脑
这是最容易混的一对。微调是拿一批标注数据继续训练模型，把知识和行为模式“写进”模型参数里——相当于改造大脑；RAG 不动模型，只在每次回答时外挂检索到的资料——相当于开卷考试允许带资料。
| RAG | 微调 | |
|---|---|---|
| 改的是什么 | 每次回答时附带的参考资料 | 模型本身的参数 |
| 知识更新 | 换文档、重建索引就行，小时级 | 要重新准备数据、重新训练，天级起步 |
| 成本 | 低，主要是检索链路的工程量 | 高，需要算力和标注数据 |
| 答案可追溯 | 能标出“依据哪段原文” | 答对了也不知道依据哪条训练数据 |
| 适合解决 | 知识过时、知识缺失、私有知识 | 语气风格、固定格式、特定行为模式 |
边界就一句话：知识会变、用“查”解决，选 RAG；想要模型“换个说话方式”、按固定套路办事，选微调。两者也不互斥——很多企业级方案是微调定行为、RAG 供知识，各管一摊。
别搞混的三个相近概念
RAG vs 手动把文档粘进对话框。 本质都是“给模型看资料再答”，区别在谁来当检索员。手动粘贴是你自己翻文档、复制、粘贴，文档一多就放不下，还烧上下文额度；RAG 是机器自动完成“找哪几段”这一步，只给最相关的片段。文档少、问得少，手动粘贴更省事；文档多、问得多，RAG 才划算。
RAG vs 联网搜索。 检索的对象不同：RAG 查的是你指定的私有知识库（内部文档、产品手册），联网搜索查的是公开网页。一个管“自己家的资料”，一个管“全网的新鲜事”，两者经常叠加使用——先查内部知识库，没有再联网补。
RAG vs AI Agent。 RAG 是“查资料再回答”的一次性流程，Agent 是“规划、调用工具、多步执行”的完整任务循环。Agent 内部经常把 RAG 当作查资料的工具来用，但 RAG 本身不会规划、不会调用工具。把 RAG 叫成 Agent，是把零件当成了整机。
关于 RAG 的四个常见误解
误解一：上了 RAG，模型就不会胡编了。 检索质量决定了 RAG 的上限。捞回来的资料不相关、自相矛盾，或者干脆没捞到，模型照样会编——而且因为“有资料打底”，编得可能更有底气。想减少大模型幻觉，RAG 是重要手段，但不是保险箱，关键答案还是要人工核验。
误解二：RAG 就是向量数据库。 向量库只是存放和检索“语义坐标”的仓库，是 RAG 链路上的一个零件。完整的 RAG 包括文档切片、向量化、召回、重排、拼提示词、生成回答，任何一环拉胯都会拖累最终答案。只买了向量库，离可用的 RAG 还差得远。
误解三：资料给得越多，答得越准。 恰恰相反。一次塞 20 段不如精准的 3 段：无关资料会稀释模型的注意力，还可能引入互相矛盾的说法，反而增加胡编的概率，同时多烧 token。RAG 的功夫一半在“检得准”，不在“堆得多”。
误解四：RAG 可以替代微调。 RAG 解决的是“知识”问题，微调解决的是“行为”问题。想让模型说话像你们家客服、输出固定格式的工单、拒绝回答某些问题，这些要靠微调或指令设计，RAG 帮不上忙。反过来，微调也解决不了“知识天天变”——总不能每天重新训练一次模型。
什么时候用 RAG，什么时候别用
适合 RAG 的场景有一个共同点：答案有固定出处、且出处会变。企业知识库问答、产品文档助手、法规政策查询、客服标准话术，都是典型。它的限制也要心里有数：第一，检索是天花板，搜不到等于没有；第二，资料本身过时或写错了，RAG 会一本正经地转述错误；第三，有些问题根本不是“查资料”能解决的，比如数学证明、创意写作、开放讨论，RAG 派不上用场；第四，隐私合规——文档进了向量库，就等于进了另一套数据系统，权限管理、删除同步都得跟上，不能只管建不管治。
Q：个人用户有必要自己搭一套 RAG 吗？
A：多数情况下没必要。现在的笔记软件、知识库问答产品大多内置了 RAG，你把文档丢进去就能问。只有当资料量大、高度私有、更新频繁——比如律师的案例库、医生的文献库——才值得专门搭一套；否则用现成的产品更划算。
