RAG 是什么？为什么企业知识库都离不开它？

如果你关注 AI 应用开发，一定绕不开一个词：RAG。

很多企业做 AI 知识库、智能客服、内部文档问答、合同检索、代码助手、规章制度查询时，都会提到 RAG。甚至可以说，RAG 是大模型落地企业知识场景最常见、最实用的一种架构。

但很多人第一次听到 RAG，会觉得它很抽象：不就是把文档丢给大模型吗？为什么还要搞向量数据库、Embedding、召回、重排、切片？直接把资料发给模型不行吗？

这篇文章就从零开始讲清楚：RAG 是什么，它解决什么问题，企业知识库为什么离不开它，以及普通开发者应该怎么入门。

一、先用一句话解释 RAG

RAG 的全称是 Retrieval-Augmented Generation，中文通常翻译为“检索增强生成”。

一句话解释：

RAG 是先从外部知识库中检索相关资料，再把资料交给大模型生成答案的一种技术架构。

它不是一个单独的模型，也不是某个固定产品，而是一种让大模型结合外部知识回答问题的方法。

传统大模型回答问题，主要依赖训练时学到的知识和当前对话上下文。但企业知识往往有几个特点：

• 内容私有，模型训练时没有见过。
• 更新频繁，模型参数不可能天天重训。
• 文档数量庞大，无法全部塞进上下文窗口。
• 答案需要可追溯，不能只靠模型“感觉”回答。

RAG 的思路就是：不要指望模型记住所有知识，而是在回答前先帮它找到相关资料。

二、为什么不能直接把所有文档丢给模型？

很多人做知识库的第一个想法是：既然大模型能读文本，那我把公司文档全部放进 prompt，不就能回答了吗？

问题是，这在现实中很快会失败。

第一，上下文窗口有限。

即使现在大模型上下文窗口越来越长，也不可能无限放文档。一个企业知识库可能有几千篇文档、几十万页资料、数百万行日志。全部放进去既不现实，也非常昂贵。

第二，成本会非常高。

模型按 token 消耗资源。每次用户问一个简单问题，如果都把大量无关文档传给模型，成本会迅速失控。

第三，无关信息会干扰答案。

上下文越多不一定越好。如果把大量无关资料塞给模型，模型可能抓错重点，甚至被冲突信息误导。

第四，更新维护困难。

企业文档每天都在变化。如果依赖重新训练模型来更新知识，成本和周期都无法接受。

第五，答案缺乏引用依据。

企业知识问答通常需要知道答案来自哪篇文档、哪一段内容。单纯让模型凭记忆回答，很难做到可信追溯。

所以，企业知识库的关键不是“把所有知识给模型”，而是“每次只把最相关的知识给模型”。

这就是 RAG 的核心思想。

三、RAG 的基本流程

一个典型 RAG 系统通常包含两个阶段：离线构建知识库，在线回答问题。

离线阶段主要做文档处理：

1. 收集文档。
2. 清洗文本。
3. 按合适长度切片。
4. 为每个文本片段生成 Embedding。
5. 把向量和原文、元数据存入向量数据库或检索系统。

在线阶段主要做问答：

1. 用户提出问题。
2. 系统将问题转换成向量。
3. 在知识库中检索相似片段。
4. 可选：对候选片段进行重排。
5. 把最相关片段拼进 prompt。
6. 大模型基于这些资料生成回答。
7. 返回答案和引用来源。

这个流程看起来步骤很多，但核心只有一句话：先找资料，再回答。

四、Embedding 是什么？

理解 RAG，绕不开 Embedding。

Embedding 可以理解为把文本转换成一组数字向量。这个向量不是随便的数字，而是尽量表达文本语义。

比如：

“如何申请年假？”

和

“员工休假流程是什么？”

字面上不完全一样，但语义接近。通过 Embedding，它们在向量空间中的距离就会比较近。

而

“服务器 CPU 使用率过高怎么办？”

和休假流程语义完全不同，向量距离就会比较远。

这就是向量检索能用于知识问答的原因：它不是只按关键词匹配，而是可以按语义相似度找资料。

当然，Embedding 不是万能的。它可能找不到需要精确匹配的内容，例如订单号、合同编号、错误码、专有名词。实际系统里经常会把向量检索和关键词检索结合起来，这叫混合检索。

五、文档切片为什么重要？

很多 RAG 系统效果不好，不是模型不行，而是文档切片做得不好。

所谓切片，就是把长文档拆成较小的文本片段。

为什么要切？

因为用户的问题通常只对应文档中的某一小段。如果整篇文档太长，检索粒度会很粗，模型拿到的上下文也会有很多无关内容。

但切得太碎也不行。一个片段如果只有一句话，可能缺少上下文，模型看不懂它在讲什么。

切片需要平衡：

• 太大：召回不准、上下文浪费。
• 太小：语义不完整、答案缺依据。

常见做法是按标题、段落、章节结构切，而不是机械地每 500 字切一次。对于 Markdown、PDF、网页、代码、表格，不同格式也应该用不同策略。

比如制度文档可以按章节切；API 文档可以按接口切；代码仓库可以按函数或类切；FAQ 可以按问答对切。

切片质量直接决定 RAG 的上限。

六、召回和重排是什么？

RAG 中经常听到两个词：召回和重排。

召回是从知识库里先找出一批可能相关的内容。比如用户问一个问题，系统先找出相似度最高的 20 个片段。

重排是对这 20 个片段重新打分，挑出真正最相关的 5 个。

为什么需要重排？

因为第一轮向量检索追求速度和覆盖率，它可能把一些看起来相似但并不真正回答问题的片段找出来。重排模型可以更细致地比较“问题”和“候选片段”的相关性，从而提升最终上下文质量。

可以把它理解成：

召回负责“别漏掉可能有用的资料”。

重排负责“把真正有用的资料排到前面”。

在企业知识库里，重排非常重要。尤其是文档很多、术语相似、内容重复时，只靠向量相似度往往不够。

七、RAG 为什么能减少幻觉？

大模型幻觉是指模型生成看起来很合理但实际上错误的内容。

RAG 能减少幻觉，原因是它给模型提供了外部依据。

如果用户问：“我们公司的报销标准是什么？”

没有 RAG 时，模型可能根据通用经验编一个答案。

有 RAG 时，系统会先检索公司内部报销制度，把相关条款交给模型。模型就可以基于真实资料回答。

但要注意，RAG 不是幻觉终结者。

如果检索错了，模型会基于错误上下文回答。

如果文档本身过期，模型会引用过期资料。

如果 prompt 没有限制，模型仍可能在资料不足时补充猜测。

所以一个好的 RAG 系统通常会要求模型：

• 只基于给定资料回答。
• 找不到依据时明确说不知道。
• 给出引用来源。
• 不编造文档中没有的信息。

RAG 的本质不是让模型“绝对正确”，而是把答案从“凭记忆生成”变成“基于检索资料生成”。

八、企业知识库为什么离不开 RAG？

企业知识库的核心难点，不是把文档存起来，而是让员工快速找到准确答案。

传统知识库常见问题是：

• 文档太多，搜索困难。
• 关键词不一致，搜不到。
• 内容分散在不同系统里。
• 新员工不知道该看哪篇。
• 文档更新后旧答案仍在流传。
• 客服和运营重复回答相同问题。

RAG 可以把这些问题变成自然语言问答。

员工不用知道文档标题，也不用精确输入关键词，只需要问：

“试用期员工能申请年假吗？”

“客户要求开专票需要哪些资料？”

“这个错误码在部署文档里是什么意思？”

“销售合同超过 100 万需要谁审批？”

系统先检索相关制度、流程、FAQ、历史案例，再让模型整理成答案。

这就是企业知识库需要 RAG 的原因：它让知识从“可存储”变成“可问答”。

九、RAG 和微调有什么区别？

很多人会问：既然要让模型懂企业知识，为什么不用微调？

微调和 RAG 解决的问题不同。

微调更适合让模型学习某种风格、格式、任务模式或领域表达。例如让模型更像客服、按固定格式输出、理解特定标注任务。

RAG 更适合让模型使用经常变化的外部知识。例如公司制度、产品文档、合同条款、客户资料。

如果企业知识每天更新，用微调同步知识是不现实的。每次文档改动都重新训练模型，成本太高，也难以追溯。

RAG 的优势是知识更新快。你只需要更新知识库索引，不一定需要改模型参数。

一个简单判断：

要模型学会“怎么回答”，考虑微调。

要模型知道“最新资料是什么”，考虑 RAG。

很多成熟系统会二者结合：用 RAG 提供知识，用微调或 prompt 规范回答风格。

十、一个 RAG 系统的关键模块

一个企业级 RAG 系统通常不只是“向量数据库 + 大模型”这么简单。

它至少包括：

文档接入模块：负责从飞书、钉钉、Notion、Confluence、企业网盘、数据库等来源同步文档。

文档解析模块：负责解析 PDF、Word、Markdown、网页、表格、图片 OCR 等格式。

切片模块：决定如何拆分文档。

Embedding 模块：把文本转换成向量。

索引模块：保存向量、原文、元数据、权限信息。

检索模块：根据用户问题召回相关片段。

重排模块：提升相关性排序。

生成模块：把检索内容交给大模型生成答案。

引用模块：返回答案依据。

权限模块：确保用户只能看到自己有权访问的文档。

评估模块：检测回答准确率、召回率、引用质量。

其中最容易被低估的是权限和评估。

企业知识库不能只回答得像，还要回答得准、可追溯、符合权限。

十一、RAG 常见失败原因

第一，文档质量差。

如果原始文档混乱、过期、互相矛盾，RAG 也很难给出好答案。AI 不能从低质量知识中稳定生成高质量结论。

第二，切片策略粗糙。

机械切片会破坏语义结构，导致检索片段缺上下文。

第三，只做向量检索。

很多企业文档需要关键词、编号、时间、权限等精确过滤。单纯向量检索容易漏掉关键内容。

第四，没有重排。

召回结果看似相关，但真正能回答问题的片段没排到前面。

第五，prompt 没有限制模型。

如果不要求模型基于资料回答，不允许编造，模型可能继续自由发挥。

第六，没有引用来源。

没有引用，用户很难信任答案，也无法验证。

第七，没有评估集。

很多团队只凭几次演示判断效果，真正上线后才发现大量边界问题。

十二、如何从零搭一个简单 RAG？

如果你是初学者，可以用最小闭环入门：

第一，准备 10 篇 Markdown 或 PDF 文档。

第二，把文档解析成纯文本。

第三，按标题和段落切片。

第四，用 Embedding 模型生成向量。

第五，把向量存到向量数据库，或者先用本地库做相似度搜索。

第六，用户提问时，检索 top 5 相关片段。

第七，把片段和问题一起放进 prompt。

第八，让模型回答，并要求引用片段来源。

这个版本不一定企业级，但能帮你理解 RAG 的本质。

等最小版本跑通后，再逐步加入：

• 混合检索。
• 重排模型。
• 权限过滤。
• 文档增量更新。
• 多轮对话上下文。
• 答案质量评估。
• 用户反馈闭环。

不要一开始就堆很多组件。RAG 的关键是可验证地提高答案质量。

十三、总结

RAG 是检索增强生成，它的核心流程是：先从外部知识库检索相关资料，再让大模型基于资料生成答案。

企业知识库离不开 RAG，是因为企业知识私有、更新频繁、数量庞大、需要引用和权限控制，不能单纯依赖模型训练时的记忆。

一个好的 RAG 系统，不只是向量数据库，也不只是把文档塞给模型。它需要高质量文档、合理切片、准确检索、有效重排、严格 prompt、引用来源、权限控制和持续评估。

如果你想学习 AI 应用开发，RAG 是非常值得优先掌握的方向。因为它是大模型从“能聊天”走向“能解决企业问题”的关键技术之一。