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

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统统不知道也永远不会知道因为这些数据根本没有被喂给模型。这就好比一个哈佛毕业的博士来到你们公司智商很高但第一天上班啥也不懂。那怎么办两种思路方法怎么做缺点微调Fine-Tuning把你的文档做成训练数据重新训练模型成本高一张A100跑几天、更新慢新文档要重新训、效果不稳定RAG检索增强生成文档先存好提问时先搜再让AI回答成本低、更新快、可解释性强显然在企业场景下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备案。年假天数按入职年限计算…… 文档2OA系统请假入口登录portal.company.com → 人事管理 → 请假申请…… 【用户问题】 公司年假怎么请第四步LLM生成答案LLM收到这个提示词后因为有了「参考答案」在手就不再胡乱编造了。它会把找到的文档片段用自己的理解重新组织成流畅的回答。注意LLM在这里只是阅读理解重新组织而不是凭空创造知识。这就是RAG能减少幻觉的根本原因。三、RAG vs 传统搜索全文检索区别在哪很多人问这不就是一个加强版的全文搜索吗公司不是已经有 Elasticsearch简称ES了吗为什么要搞RAG区别大了去了。传统搜索和RAG的核心差异维度全文检索如ElasticsearchRAG匹配方式关键词匹配倒排索引语义匹配向量相似度能搜到什么包含相同关键词的文档含义相近的文档结果形式返回文档列表返回阅读理解的答案举例搜请假只能找到包含请假二字的文档搜怎么休假也能找到年假申请流程用户体验用户需要一篇篇翻看文档直接给答案一步到位举个例子用户问二面面试官应该关注什么传统搜索只会搜出包含二面面试官这些词的文档可能会漏掉标题是「技术复试评价标准」但内容完全相关的那篇。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最适合先解决公司里的哪个场景评论区聊聊我每条都回