RAG是什么？企业为什么需要自己的知识库？

2025年的某一天，老板突然把我叫进办公室："小黒啊，咱公司有2000多份内部文档散落在各个群里，每次来个新人得翻一周——你能不能搞个AI，让它帮大伙把资料找出来？"我拍胸脯："没问题，这叫RAG，一个周末给你搞出来。"然后周末变成了三个月……这就是我和RAG的开始。

大家好，我是黒漂技术佬。

如果你想搞企业知识库——那种扔进几百份PDF、Word，然后用大白话问问题，AI就能翻出准确答案的系统——那你一定绕不开RAG这三个字母。不管你是做AI数据助手、企业文档问答、还是智能客服，RAG都是地基。

今天作为开篇，我们先不敲代码。先把「RAG是什么」这个事儿聊透。因为后面你会看到——80%的RAG问题，根源都是没真正理解RAG的边界。

一、大模型看起来很聪明，但它有两个致命缺陷

2023年ChatGPT火了之后，大语言模型（Large Language Model，简称LLM）给人的感觉就是"无所不知的老师"。但实际上，你往企业场景一用，马上暴露两个硬伤：

缺陷1：知识有截止日期，消息不灵通

GPT-3.5 的知识截止到 2021 年 9 月，GPT-4 的几个版本也分别截止在 2023 年。你问它「最新的 Spring Boot 3.2 有什么特性」，它就开始一本正经地胡说八道。这在学术上叫「模型幻觉（Hallucination）」——模型不会说"我不知道"，它只会编一个看起来最像答案的东西。

缺陷2：只懂"公共知识"，不懂"你公司的私有知识"

你公司的报销流程、产品的硬件规格、内部API文档、上周开会定的技术方案——这些LLM统统不知道，也永远不会知道，因为这些数据根本没有被喂给模型。

这就好比一个哈佛毕业的博士来到你们公司：智商很高，但第一天上班，啥也不懂。

那怎么办？两种思路：

显然，在企业场景下，RAG才是正道。除非你有几万张GPU和几个月的训练时长，否则别碰微调。

一句话总结RAG：先查后答。把企业文档存起来，用户提问题时，先搜索出相关的文档片段，再把这些片段"喂"给大模型，让它基于这些材料回答问题。

二、RAG到底是怎么工作的？拆成4步给你看

RAG的全称是 Retrieval Augmented Generation，即「检索增强生成」。拆开来理解：

• Retrieval（检索）：从知识库里找到和用户问题相关的文档片段
• Augmented（增强）：把找到的片段"塞进"给大模型的提示词里
• Generation（生成）：大模型根据这些片段，生成最终答案

用一张流程图来表示：

用户提问: "公司年假怎么请？" │ ▼ ┌──────────────────┐ │ Step 1: 用户问题 │ │ 转为向量 │ ← Embedding 模型 └──────┬───────────┘ │ [0.12, -0.83, 0.45, ...] ▼ ┌──────────────────┐ │ Step 2: 向量库 │ │ 搜索相似文档 │ ← 向量相似度计算（余弦相似度） └──────┬───────────┘ │ 返回 Top-K 最相关的文档片段 ▼ ┌──────────────────┐ │ Step 3: 拼接提示 │ │ 词（Prompt） │ ← "根据以下文档内容回答用户问题……" └──────┬───────────┘ │ 提示词 = 系统指令 + 检索到的文档 + 用户问题 ▼ ┌──────────────────┐ │ Step 4: LLM生成 │ │ 最终答案 │ ← "您好，公司年假需在OA系统提交……" └──────────────────┘

第一步：文档→向量（Embedding）

这是RAG最核心的一步：把文字变成数字。

计算机不懂"中文"，它只懂数字。所以我们需要一个叫"嵌入模型（Embedding Model）"的东西，把任意一段文字转换成一个固定长度的数字数组——这个数组就叫向量（Vector）。

比如"公司年假怎么请"经过嵌入后可能变成：

[0.12, -0.83, 0.45, 0.06, -0.33, ...] ← 通常是768维或1024维的浮点数

这个向量的魔力在于：语义相近的句子，它们的向量在空间中距离也近。

• “公司年假怎么请” 和 “请假流程是什么” ——向量距离很近
• “公司年假怎么请” 和 “今天的天气真好” ——向量距离很远

第二步：向量相似度检索

用户的问题也经过同样的嵌入模型转成向量，然后在向量数据库里做「最近邻搜索（Approximate Nearest Neighbor，简称ANN）」，找出和问题最相似的Top-K个文档片段。

这里涉及的算法叫余弦相似度（Cosine Similarity），数学上非常简单，就是用两个向量夹角的余弦值来衡量相似度：值越接近1越相似，越接近0越不相关。

第三步：组装修饰提示词

这是"Augmented"增强这一步。把搜索到的文档片段拼成一段文本，塞到提示词里：

你是一个企业知识库助手。请根据以下文档内容回答用户的问题。 如果你不知道答案，请直接说"不知道"，不要编造。 【相关文档】 文档1：根据《公司管理制度2024版》第三条，年假需在OA系统提交申请， 由直属领导审批后报HR备案。年假天数按入职年限计算…… 文档2：OA系统请假入口：登录portal.company.com → 人事管理 → 请假申请…… 【用户问题】 公司年假怎么请？

第四步：LLM生成答案

LLM收到这个提示词后，因为有了「参考答案」在手，就不再胡乱编造了。它会把找到的文档片段，用自己的理解重新组织成流畅的回答。

注意：LLM在这里只是"阅读理解+重新组织"，而不是凭空创造知识。这就是RAG能减少幻觉的根本原因。

三、RAG vs 传统搜索（全文检索），区别在哪？

很多人问：这不就是一个加强版的全文搜索吗？公司不是已经有 Elasticsearch（简称ES）了吗？为什么要搞RAG？

区别大了去了。传统搜索和RAG的核心差异：

举个例子：用户问"二面面试官应该关注什么"，传统搜索只会搜出包含"二面""面试官"这些词的文档，可能会漏掉标题是「技术复试评价标准」但内容完全相关的那篇。

RAG因为走的是语义向量匹配，"二面"和"复试"在向量空间里距离很近，所以能命中。

但这不意味着ES就过时了。在企业级RAG中，最佳实践往往是「混合检索」：ES做关键词召回 + 向量库做语义召回，两路融合后重排序，各取所长。这个我们后面专门写一期。

四、企业为什么需要自己的RAG知识库？

说了这么多技术原理，落到业务上，到底解决什么问题？

场景1：新员工入职

一个新人进来要看的文档：员工手册、社保说明、开发规范、项目Wiki、公共组件文档……没有集中的知识库，新人不是在问问题，就是在去问问题的路上。有了RAG知识库后，新人在聊天框里直接问，AI从已有的文档里检索答案。

场景2：客服/技术支持

把产品手册、FAQ、售后服务条款、历史工单扔进知识库，客服只需要把用户问题输入AI助手，AI立刻给出标准答案，速度提升5~10倍。

场景3：研发知识管理

架构文档、API文档、设计评审纪要、代码Review规范——这些知识散落在Confluence、语雀、飞书文档、微信群聊天记录里。RAG可以把它们全部索引起来，研发同事直接对话式查询。

场景4：制度合规

公司制度、合规条例、安全红线。员工随时用大白话问，系统基于制度原文给出答案并标注出处。既能减少HR/法务的答疑负担，又能保证答案的一致性。

共性需求拆出来就是一句话：把散落在各处的企业知识，变成随问随答的AI助手。

五、搭建企业RAG知识库，你会经历这5个阶段

根据我的实践经验，一个企业RAG系统从0到生产，大致分为5步：

阶段1: 数据准备（文档解析 + 文本分块） │ 难点：PDF格式千奇百怪，表格、图片、扫描件…… ▼ 阶段2: 向量化（Embedding + 向量存储） │ 难点：中文语义的嵌入模型怎么选？多长的片段合适？ ▼ 阶段3: 检索优化（召回策略 + 重排序） │ 难点：用户问法千变万化，怎么保证"问法不同"也能搜到？ ▼ 阶段4: 生成增强（Prompt工程 + 上下文管理） │ 难点：搜索出3条文档 VS 30条文档，该给LLM看多少？ ▼ 阶段5: 上线运维（权限控制 + 效果评估 + 持续优化） │ 难点：不同部门看不同文档，数据安全怎么控制？

后续的每一篇，我会逐一拆解这5个阶段的核心技术、代码实现和踩坑经验。

这个系列写什么？

本系列的目标非常明确：手把手带你从0搭建一个企业级RAG知识库，覆盖文档问答、AI数据助手等核心场景。

不会只教你调个LangChain跑通demo就完事。我会按照我从零到落地踩过的坑，把每个环节掰开来讲：

• 怎么处理真实的PDF和Word文档（特别是那些排版乱七八糟的）
• 中文Embedding模型怎么选（实测对比，给数据不给结论就耍流氓）
• 向量数据库 Chroma / Milvus / Elasticsearch 到底用哪个
• 检索效果不好怎么办（重排序、Query改写、HyDE——这些我都会用大白话讲清楚）
• 上线后怎么知道知识库好不好用（评估指标 + 用户反馈闭环）

每篇都有可复现的代码，每篇都基于真实的企业场景。

💬 你们公司现在有没有在搞AI知识库？你觉得RAG最适合先解决公司里的哪个场景？评论区聊聊，我每条都回！