RAG 是什么？用外部知识增强大模型回答的实用方案

RAG 解决什么问题

你让 ChatGPT 帮你回答一个公司内部流程的问题，它大概率会编一个听起来很合理但完全是假的答案。不是它不想帮你，是它真的不知道——模型的训练数据里没有你公司的文档。

RAG（Retrieval-Augmented Generation，检索增强生成）就是干这个的：在模型回答之前，先帮它"翻资料"。你把公司的文档、产品手册、代码仓库等资料预先处理好，模型回答的时候先去查，查到了再回答。

这样做的好处是：模型不用记住所有东西，只需要会查就行。知识库更新了，回答也跟着更新，不需要重新训练模型。

工作流程

整个过程分三步：

第一步：把文档处理好（离线，只做一次）

原始文档 → 切成小段（chunk）→ 每段转成向量 → 存进向量数据库

这一步叫"索引"。切块的大小、用什么 Embedding 模型、怎么分段，都会直接影响最终效果。这块后面会讲坑。

第二步：用户提问时检索（在线）

用户问题 → 转成向量 → 在向量数据库里找最相似的几个段落 → 返回

关键点是"语义相似"而不是关键词匹配。用户问"怎么报销差旅费"，即使文档里写的是"出差费用报销流程"，也能找到。

第三步：把检索结果喂给模型生成回答

系统提示词 + 用户问题 + 检索到的参考段落 → 大模型 → 生成回答

模型拿到参考资料后，基于这些内容来回答，而不是凭空编造。

RAG vs 微调：选哪个

这是被问得最多的问题之一。简单说：

经验判断：如果你的需求是"让模型基于某些文档回答问题"，用 RAG。如果你的需求是"让模型用特定的语气说话"或者"在某个专业领域能力更强"，考虑微调。大多数实际项目用 RAG 就够了。

RAG 实际落地的常见坑

文档质量决定回答质量

垃圾进垃圾出。如果你的文档本身写得不清楚、有矛盾、格式混乱，RAG 检索出来的内容也是烂的，模型再怎么生成也好不了。先把文档整理清楚，比调任何参数都重要。

切块策略很关键

块太大，检索结果里混入太多无关信息；块太小，丢失上下文。没有万能答案，取决于你的文档类型。一般经验是 200-500 个 token 一块，但一定要拿自己的数据测试。

向量检索不是万能的

语义搜索对"这个东西叫什么""怎么做某件事"这类问题效果好。但对"最近一个月的销售额是多少"这种需要精确计算的问题，向量检索帮不上忙，还是得靠结构化查询（SQL 等）。

Embedding 模型选错会翻车

中文场景如果用了英文为主的 Embedding 模型，检索效果会差很多。选模型时要注意它在你的目标语言上的表现。可以参考 Embedding 是什么 了解更多。

常用工具

想动手试？从 Dify 教程 开始最快，它有可视化界面，不用写代码就能搭一个 RAG 应用。

从业者提醒

RAG 不是银弹。很多项目觉得"加上 RAG 就能解决幻觉问题"，实际上如果检索质量不行，模型还是会编——只不过这次它会编得"有理有据"，因为你喂给它的参考资料就不对。 评估环节不能省。上线之前一定要做评测：准备一批真实问题和标准答案，跑一遍看准确率。不评测就上线，等于盲开。 考虑混合方案。实际项目里经常是 RAG + 规则引擎 + 结构化查询混合使用。纯靠向量检索解决所有问题是不现实的。

下一步

• 想了解 Agent 怎么用 RAG？看 AI Agent 是什么
• 想动手搭建？从 Dify 教程 开始
• 想了解不同模型的表现？看 ChatGPT vs Claude