RAG 是什么？一文讲清检索增强生成，以及怎么用它搭知识库
老老一·2026-05-30·8 分钟阅读
如果你曾经问过 AI「我们公司的退换货政策是什么」，然后收到一堆通用废话，或者更糟糕的——一本正经的胡说八道，那你就已经遇到了 RAG 要解决的核心问题。
大语言模型（LLM）知道的是训练时喂进去的公开知识，但你的企业文档、内部规章、产品手册、研究报告，它根本不知道。RAG（Retrieval-Augmented Generation，检索增强生成）就是让 AI 在回答之前，先去检索你提供的资料，用真实内容作为依据再生成答案。
这篇文章从原理到实践，把 RAG 讲清楚。
用一个比喻理解 RAG
想象你雇了一位助理，他非常聪明，会写作、会总结、会推理，但他对你公司的情况一无所知。
不用 RAG 的情况：你问他「我们的 VIP 客户有哪些专属权益」，他只能猜，或者给你一个通用行业答案。
用了 RAG 的情况：他手边有一个文件柜，里面放着你们公司所有的规章制度、产品手册、客服记录。你问他问题之前，他会先在文件柜里翻一翻，找到相关的几页，然后基于这些内容给你回答。
RAG 就是这个「先检索，再回答」的机制。
RAG 的工作流程
一个完整的 RAG 系统，后台发生了这些事：
第一阶段：建立知识库（离线处理）
- 文档摄入：把你的 PDF、Word、Markdown、网页等资料上传进来
- 文本切块（Chunking）：把长文档切成小段（通常 300–800 字一块），因为模型每次只能处理有限长度
- 向量化（Embedding）：用 Embedding 模型把每一小块文字转成一串数字向量——数字之间的距离代表语义的相似程度
- 存入向量数据库：把这些向量连同原始文字一起存进向量数据库（如 Milvus、Qdrant、pgvector）
第二阶段：检索 + 生成（在线查询）
- 用户提问：用同样的 Embedding 模型把问题也向量化
- 相似度检索：在向量数据库里找出与问题最相似的 Top-K 块文本
- 拼装上下文：把检索到的文本片段拼进 Prompt
- LLM 生成回答：让大模型基于检索到的内容回答问题，而不是凭空发挥
整个流程用公式表示：RAG = 检索到的上下文 + 用户问题 → LLM 生成答案
RAG 能解决哪些问题？
| 问题类型 | 不用 RAG 的结果 | 用了 RAG 的结果 |
|---|---|---|
| 公司内部文档查询 | 模型不知道，乱答 | 基于上传文档精准回答 |
| 最新政策/价格查询 | 给训练截止日期前的旧信息 | 基于你维护的最新文档回答 |
| 私密/保密信息 | 无法回答 | 在你部署的私有系统内回答 |
| 答案可溯源验证 | 无法追溯来源 | 可标注「来源：第 X 章 X 节」 |
| 幻觉问题 | 容易一本正经地瞎编 | 有文档约束，幻觉大幅减少 |
RAG 不能彻底消灭幻觉，但有了参考文档的「锚点」之后，模型胡说的空间大幅缩小。
2026 年 RAG 的主流玩法
RAG 从 2023 年开始爆发，到 2026 年已经从「实验技术」变成「生产级标配」。几个重要进展：
混合检索已成标准
早期 RAG 只用向量搜索，但纯向量搜索在精确关键词匹配上不如传统关键词搜索（BM25）。现在生产环境基本都用混合检索：同时跑向量搜索和关键词搜索，再用 Reranker 模型对结果重新排序，综合质量更高。
Agentic RAG 是新范式
传统 RAG 是「问一次，检索一次，回答一次」。Agentic RAG 让 Agent 自主决定：要不要检索？检索哪个知识库？检索到的信息够不够？需不需要多轮检索？这让知识库问答系统能处理更复杂的多跳推理问题（答案藏在多个不同文档里的情况）。
图谱增强 RAG
对于逻辑关系复杂的领域（医疗、法律、金融），有团队在向量检索的基础上叠加知识图谱，让模型理解实体之间的关系，而不只是找相似文段。
动手实践：用 Dify 搭一个知识库问答系统
Dify 是目前最流行的开源 LLM 应用开发平台，内置完整的 RAG pipeline，不需要自己处理 Embedding、向量库、检索逻辑，适合快速上手。它有云端版（免费额度），也支持本地私有部署。
步骤一：创建知识库
登录 Dify，左侧菜单点「知识库」→「创建知识库」，给它起个名字。
步骤二：上传文档
支持格式：PDF、Word（.docx）、Markdown、TXT、CSV、HTML。
关键设置：
- 分块大小：推荐 600 tokens，重叠 100 tokens（太小容易断句，太大检索精度下降）
- 索引方式：选「高质量」（使用 Embedding 模型，效果最好）
- 检索设置：推荐「混合检索」，向量权重 0.7，关键词权重 0.3
步骤三：测试检索效果
知识库创建后，在「检索测试」里输入几个典型问题，看看召回的文档片段是否包含正确答案。如果不对，调整分块策略或检索权重。
步骤四：创建应用
在「工作室」创建一个「对话型应用」，在「上下文」里关联刚才的知识库，配置好提示词模板：
你是公司内部助手，只根据以下检索到的资料回答问题。
如果资料中没有相关信息，请明确说「我在知识库中没有找到相关内容」，不要猜测。
检索到的资料：
{{#context#}}
用户问题：{{question}}
步骤五：上线或集成
Dify 应用可以直接用内置的对话界面分享给团队，也可以通过 API 接入你已有的系统（网站、企业微信、飞书等）。
搭知识库的常见坑
坑 1：文档质量差
RAG 的上限取决于你的文档质量。扫描版 PDF 如果 OCR 不准确、格式混乱，检索效果会很差。上传前做好文档清洗。
坑 2：分块太粗或太细
分块太大（> 1000 tokens）：一块里有太多主题，检索时「相关」但「不精确」 分块太小（< 200 tokens）：一块里信息太碎，缺乏上下文，模型读不懂
针对不同文档类型调整：FAQ 可以小块（按问答对切），长篇报告适合大块（按章节切）。
坑 3：没有 Reranker
第一轮向量检索召回的 Top-20 结果质量参差不齐。加一个 Reranker 模型（如 bge-reranker）对结果重排，能显著提升最终 Top-3 的精准度。
坑 4：知识库没有维护机制
业务变化了，旧文档没更新，RAG 照样会给出过时答案。建立定期更新流程，至少和源文档同步。
RAG vs. 直接用大模型，怎么选？
- 问题答案完全在公开知识里（历史、常识、编程语法）→ 直接用大模型即可
- 问题答案在你的私有文档里（公司政策、产品文档、研究报告）→ 用 RAG
- 需要引用来源，结果可审计→ 用 RAG
- 实时信息（今天的股价、最新新闻）→ 搜索 + 联网，不是 RAG 擅长的范畴
总结
RAG 的价值用一句话说：让 AI 基于你的知识说话，而不是凭记忆猜测。
对于想搭建内部知识库、客服 Bot、文档问答系统的团队，Dify 是目前最好的起点——开源、可私有部署、有完整的 RAG pipeline、中文支持良好。
如果你只是个人用户，想快速体验「文档对话」，NotebookLM（谷歌出品、完全免费）是最零门槛的方式：上传 PDF 就能对话，不需要任何配置。
选型建议：
- 个人探索/小团队：Dify 云端版（免费额度够用）+ 上传文档 + 配置知识库
- 企业私有部署：Dify 自托管 + Milvus 向量库 + 私有 Embedding 模型
- 零技术门槛体验：NotebookLM 直接上传文档对话