RAG 到底解决什么问题：私有知识、外部资料和模型幻觉边界
很多人第一次听说 RAG，会以为它是在“教模型新知识”。
其实不是。
假设你问模型：
订单取消接口在什么情况下会返回 ORDER_LOCKED？
模型回答：
一般是订单正在处理、库存锁定或支付状态未确认时返回。
听起来挺像那么回事。
但你们内部接口文档里写的是：
当订单已经进入仓库拣货流程后，取消接口会返回 ORDER_LOCKED。
模型为什么答不准？
不是它不聪明。
是这次调用里，它根本没看到你们公司的接口文档。
RAG 解决的就是这个问题：
回答前，先把相关资料找出来给模型看。
模型参数没变。
只是这次回答前，它多看了一份参考资料。
一、RAG 到底是什么
RAG 的全称是 Retrieval-Augmented Generation，通常翻译成“检索增强生成”。
别被名字吓住。
它的流程很简单：
用户提问 -> 检索相关资料 -> 把资料放进上下文 -> 模型基于资料回答所以 RAG 的重点不是“让模型变聪明”。
而是：
让模型回答时看到该看的资料。
这些资料可以来自向量库，也可以来自关键词检索、数据库查询、混合检索，甚至是你自己写的检索逻辑。
常见实现是向量检索，但 RAG 不等于“必须上向量库”。
关键是先找到相关内容，再交给模型。
二、它主要解决三类问题
第一类，模型不知道你的私有知识。
比如内部接口文档、项目部署手册、公司制度、团队 FAQ。
这些内容不在公开训练数据里，模型没见过，就只能猜。
第二类，知识更新太快。
框架升级了，接口改了，配置项废弃了。
如果模型训练数据没有覆盖最新版本，它可能还在一本正经地讲旧 API。
RAG 的做法更轻：
文档更新了，更新检索内容就行。
第三类，回答需要依据。
大模型会尽量回答你的问题。
哪怕它不确定，也可能生成一个听起来合理的答案。
RAG 不能从根上消灭幻觉，但可以降低“无依据回答”的概率。
前提是两件事要做好：
- 检索到的资料本身是对的；
- prompt 明确要求模型基于资料回答，资料里没有就说不知道。
一句话总结：
RAG 让模型基于你提供的资料回答，而不是只凭训练数据猜。
三、RAG 和微调不是一回事
很多人会问：
那我能不能直接微调模型，让它学会这些知识？
可以，但它们解决的问题不一样。
微调会改变模型参数。
它更适合让模型稳定学会某种行为，比如：
- 固定回答格式；
- 某类任务模式；
- 某种表达风格；
- 某个领域的写作习惯。
RAG 改的不是模型。
它改的是这次调用时，模型能看到什么资料。
可以这样记：
| 维度 | RAG | 微调 |
|---|---|---|
| 是否改模型 | 不改参数 | 改参数 |
| 知识更新 | 更新检索内容 | 通常要重新训练或继续训练 |
| 更适合 | 私有知识、变化快的事实 | 任务模式、格式、风格 |
如果你想让模型基于内部接口文档回答，用 RAG。
如果你想让模型更稳定地按某种方式表达，再考虑微调。
两者不是替代关系，也可以一起用。
四、RAG 不是 Memory
RAG 还经常和 Memory 混在一起。
Memory 解决的是：
这段对话前面聊了什么？
比如用户第一轮问：
订单取消接口会返回哪些错误码？
第二轮接着问：
刚才那个 ORDER_LOCKED 具体是什么意思？
这里的“刚才那个”，需要 Memory 帮模型接上前文。
RAG 解决的是：
外部资料里有什么？
用户问：
ORDER_LOCKED 在什么情况下返回？
RAG 会检索《订单接口文档》《取消订单错误码说明》，再把相关片段交给模型。
一个真实 Agent 里，两者经常一起用：
Memory：补历史对话 RAG：补外部资料边界清楚，就不容易用乱。
五、RAG 的边界
RAG 很有用，但不是万能补丁。
第一个边界，是检索质量。
正确答案在文档里，但如果检索没召回，或者排在很后面，模型还是看不到。
所以要关注：
- 文档怎么切；
- embedding 模型选得合不合适；
- topK 和相似度阈值怎么设；
- 要不要 rerank；
- 检索日志能不能查。
第二个边界，是文档质量。
RAG 只是把文档递给模型。
如果文档本身写得很虚，比如：
订单取消可能会失败，请注意异常处理。
那模型还是答不出“什么情况下返回 ORDER_LOCKED”。
RAG 不能把烂文档变成好答案。
第三个边界，是模型能力。
检索到了资料，模型还要能读懂、整合、判断。
比如资料里分别写着：
订单进入拣货流程后，取消接口返回 ORDER_LOCKED。 ORDER_LOCKED 表示订单已锁定，无法取消。用户问：
订单已经拣货了，还能取消吗？
模型需要把两段信息合起来，才能答出：
不能取消。订单进入拣货流程后会被锁定，取消接口会返回 ORDER_LOCKED。
资料到了眼前，不代表模型一定能用好。
写在最后
RAG 不复杂。
它解决的是一个很具体的工程问题：
模型回答前，先把相关资料找出来给它看。
记住这几句话就够了：
- RAG 不是训练模型；
- RAG 不是长期记忆；
- RAG 不是幻觉消除器；
- RAG 适合私有知识、更新快的知识、需要依据的回答；
- RAG 的效果取决于检索质量、文档质量和模型能力。
用对了，它能让系统更可靠。
用错了，只会多一层复杂度。
后续会继续更新 RAG、Memory、Tool Calling、MCP 等 AI Agent 基础知识。
