图解计算机原理：一文看懂 RAG，为什么大模型需要外接知识库？

你在公司里接了一个需求做一个智能问答助手让它能回答这些问题差旅报销标准是多少某个产品接口怎么调用这份合同模板该走哪个审批流程内部系统报错该找谁处理很多人的第一反应是把这些资料都拿去训练一个大模型。但真到业务里这条路往往很重。公司制度会更新产品文档会改接口会迭代内部知识还可能有权限边界。你总不能每改一份文档就重新训练一次大模型。更常见的做法是「不把所有知识塞进模型参数而是在回答时先去知识库里查资料。」这就是 RAG。RAG 的全称是 Retrieval-Augmented Generation通常翻译成“检索增强生成”。一句话解释先检索相关资料再让大模型基于资料生成回答。01 为什么大模型还需要外接知识库大模型很强但它不是实时资料库。它的参数里确实压缩了大量知识但这些知识有几个天然限制训练后才出现的新信息它不一定知道公司内部资料它训练时大概率没见过长文档里的细节它不一定记得准确不确定的问题它可能也会给出很像真的回答所以在企业知识问答、客服、法务、运维、产品文档助手这类场景里只靠模型本身往往不够。RAG 的思路更像一个会读资料的人用户问问题时先去资料库里找相关内容。找到后把相关片段放到模型面前。模型再基于这些资料组织答案。这样做有几个好处知识更新更轻不需要每次重新训练模型可以接入私有文档、内部制度、产品手册回答可以带来源方便用户核对能减少模型凭空补内容的概率RAG 不是让模型“突然知道一切”。它是让模型回答前先拿到应该参考的资料。02 RAG 不是一个功能点而是一条流水线很多人以为 RAG 就是“接一个向量数据库”。其实没这么简单。一套能跑起来的 RAG通常至少包含这几步文档 - 切分 - 向量化 - 召回 - 重排 - 上下文拼接 - 生成回答 - 效果评估每一步都可能影响最终效果。文档切得太碎模型拿不到完整语义。向量化效果差相关资料找不回来。召回片段太多上下文变得很吵。重排不好真正有用的资料排在后面。拼接太长模型抓不住重点。生成时不约束来源答案可能看起来流畅但依据不清。所以 RAG 调优不能只盯着大模型本身。它更像一条检索增强生成流水线。03 第一步文档切分业务资料通常不是一小段文本。它可能是一份几十页的 PDF一篇很长的产品文档或者一堆内部 FAQ。如果把整篇文档直接塞给模型会遇到几个问题上下文窗口有限塞不下长文档里只有一小段和问题相关检索时粒度太粗很难命中准确位置所以第一步通常是切分。切分不是随便按字数切。切得太长召回不精准。切得太短语义容易断。比如一条制度原本是差旅报销标准包括交通、住宿、餐补三部分其中住宿标准按城市等级区分。如果切分时把“住宿标准”和“城市等级”切散后面用户问“二线城市住宿能报多少”模型可能拿不到完整依据。比较好的切分方式通常会考虑标题层级段落结构表格和列表片段长度相邻片段重叠原文来源信息RAG 的第一道质量线就在文档切分这里。04 第二步向量化并建立索引文档切好以后每个片段还只是普通文本。机器要快速找到“语义相关”的片段需要先把文本变成向量。这个过程通常叫向量化。比如一个片段是员工出差住宿标准按城市等级分为一线、二线和其他城市。向量化模型会把它转换成一串数字[0.12, -0.38, 0.76, ...]这串向量会和原文片段、标题、来源链接、权限信息一起存进索引里。为什么要存向量因为用户问的问题不一定和文档原文一模一样。用户可能问二线城市住酒店最多能报多少文档里写的是住宿标准按城市等级区分。关键词不完全一致但语义相关。向量检索就是为了处理这种“说法不同但意思接近”的问题。05 第三步召回相关片段当用户提出问题后RAG 不会直接把问题丢给大模型回答。它会先把用户问题也向量化。然后拿这个“问题向量”去知识库里找相近的文档片段。这一步叫召回。召回的目标不是一步到位选出最完美答案而是先把可能相关的资料找出来。常见做法是取 top-ktop-5top-10top-20也就是先拿回若干个候选片段。召回阶段最怕两件事第一关键资料没找回来。如果正确依据根本没进入候选集后面重排和生成再强也很难补救。第二召回太宽。如果拿回来一堆不相关片段后面的上下文会变得很吵模型容易被干扰。所以召回要在“别漏”和“别太乱”之间找平衡。06 第四步重排候选片段召回拿到的是候选片段。但候选片段的顺序不一定最适合生成回答。这时候就需要重排。可以这样理解召回像粗筛。先把可能相关的资料都捞上来。重排像复核。再仔细判断这些片段和用户问题到底有多匹配。比如用户问试用期员工能报销差旅吗召回可能找回来这些片段差旅报销标准试用期员工管理制度交通费报销流程正式员工福利说明它们都可能相关。但真正能回答问题的可能是“试用期员工管理制度”和“差旅报销标准”的组合。重排要做的就是把更能回答问题的片段排到前面。07 第五步上下文拼接检索到资料以后还不能直接结束。RAG 还要把这些资料组织成一次大模型输入。这一步叫上下文拼接。一次输入里通常会包含用户问题检索到的相关片段回答要求引用来源限制条件比如可以组织成请根据以下资料回答用户问题。如果资料中没有答案请说明无法从资料中确定。用户问题二线城市住宿最多能报多少相关资料片段 1……片段 2……片段 3……拼接不是越长越好。上下文窗口是有限的。资料太少模型可能缺依据。资料太多模型可能抓不住重点还会增加成本和延迟。好的拼接是把最相关、最完整、最有依据的片段放进去。08 第六步生成回答到了这一步大模型才真正开始生成回答。它拿到的不只是用户原始问题还有前面检索出来的资料片段。所以 RAG 里的生成和普通聊天不太一样。普通聊天更像用户问 - 模型直接答RAG 更像用户问 - 先查资料 - 带着资料答一个好的 RAG 回答通常要做到直接回答问题不随意扩展没有依据的内容说明关键依据必要时给出来源资料不足时明确说不确定比如用户问试用期员工能不能报销差旅如果检索资料里只写了“正式员工差旅报销规则”没有提试用期员工就不应该硬编一个答案。更合适的回答是根据当前资料只能确认正式员工的差旅报销规则试用期员工是否适用资料中没有明确说明。这才是业务系统里更需要的回答方式。09 第七步效果评估RAG 的评估不能只看回答是否流畅。因为回答流畅不代表资料找对了。它至少要看三层第一召回质量。要看相关资料有没有被找回来。如果关键片段没进候选集后面的回答大概率不稳。第二回答质量。要看答案是否真正回答了问题是否忠于资料是否存在编造来源是否对应。第三业务结果。比如用户是否采纳人工复核通过率问题解决率平均处理时长是否下降。很多 RAG 项目失败不是因为模型不会写句子。而是检索没找对、上下文没拼好、评估只看了表面流畅度。10 高阶 RAG不止“向量检索 生成”前面讲的是最常见的基础 RAG文档切分 - 向量化 - 召回 - 重排 - 拼接 - 生成真实业务里问题经常会更复杂。比如用户的问题既需要语义理解也需要精确关键词命中答案分散在多份文档里查一次不够文档之间有复杂实体关系比如系统、部门、流程、负责人任务不只是问答还要多轮查证、调用工具、检查答案这时候就会出现一些更高阶的 RAG 形态。下面挑 4 种最常见的讲一下。10.1 Hybrid RAG向量检索 关键词检索Hybrid RAG 的思路是「不要只靠一种检索方式。」向量检索擅长找语义相近的内容。关键词检索擅长找精确命中的内容。结构化过滤可以处理权限、时间、文档类型、业务线等约束。比如用户问接口 E1007 报错怎么处理这里的E1007是一个精确错误码。如果只做向量检索可能会找回一堆“接口报错处理”的泛化文档。但关键词检索能直接命中E1007。再比如用户问新员工差旅报销标准是什么这时候向量检索能找语义相关制度关键词检索能命中“新员工”“差旅报销”结构化过滤还能限制到当前公司、当前地区、当前生效版本。Hybrid RAG 适合这种场景既要语义匹配也要精确命中还要业务字段过滤10.2 Multi-hop RAG一个问题分多步查基础 RAG 通常是问一次 - 查一次 - 答一次但有些问题的答案不在一份文档里。它需要多跳检索。比如用户问某产品上线后如果客户投诉应该找谁审批这个问题可能要拆成几步第 1 跳先查这个产品属于哪个业务线第 2 跳再查客户投诉流程第 3 跳再查这个业务线对应的审批负责人最后再把多份资料合起来回答。Multi-hop RAG 适合答案分散在多份文档里问题需要跨文档关联中间结论会影响下一步检索它比普通 RAG 更像“顺着线索查资料”。10.3 GraphRAG把知识组织成图GraphRAG 更进一步。它不只把文档切成片段还会把文档里的实体和关系抽出来组织成图。比如产品 A - 依赖 - 系统 B系统 B - 归属 - 部门 C部门 C - 负责 - 流程 D这样检索时就不只是找“相似片段”。还可以沿着图上的关系查某个实体的邻居是谁两个实体之间有什么路径某个部门关联了哪些系统某个流程涉及哪些产品GraphRAG 适合实体关系复杂的知识场景。比如企业组织架构、产品依赖、供应链、金融风控、法律条款关系、科研论文关系等。它的优势是能更好处理跨文档关联。但代价也更高图谱构建、实体抽取、关系质量、图上检索策略都需要额外设计。10.4 Agentic RAG让智能体自己规划检索Agentic RAG 里的重点是 Agent。它不是固定走一条检索链路而是让智能体根据任务动态决定要不要检索检索哪里要不要换关键词要不要调用工具资料够不够要不要继续查比如用户问帮我比较这两个版本的合同模板指出风险点并给出修改建议。这不是简单查一个片段就能回答的问题。Agent 可能需要先读取两份合同再检索公司模板规范再查历史风险条款再对比差异最后生成结论Agentic RAG 适合任务不确定、步骤不固定、需要多轮查证和工具协作的场景。但它也更难控调用链路更长延迟更高成本更高每一步都可能出错需要更强的日志、权限和结果校验所以不是所有场景都要上 Agentic RAG。如果基础 RAG 已经能稳定回答就先把基础链路做好。高阶 RAG 不是为了显得复杂而是为了解决基础 RAG 处理不了的问题。11 RAG 常见坑RAG 看起来流程清楚但落地时坑不少。「坑一文档切分太随意。」片段太短语义断掉。片段太长召回不准。标题、表格、来源丢失后面很难恢复。「坑二只看向量相似度。」向量召回很有用但不代表所有问题都适合只靠向量。有些场景还需要关键词、结构化字段、权限过滤一起配合。「坑三召回结果不重排。」候选片段里混入很多噪声模型就可能被带偏。「坑四上下文拼接太贪心。」把一堆资料都塞进去模型不一定更准反而可能更慢、更贵、更容易抓错重点。「坑五没有评估闭环。」用户说“有时候答得不准”但系统不知道是召回错、重排错、拼接错还是生成阶段没约束好。RAG 调优要沿着流水线定位。不能只盯着最后的大模型。12 一张图总结最后把 RAG 再压缩成一句话RAG 检索相关资料 基于资料生成回答它解决的核心问题是大模型不一定知道最新、私有、细节化的业务知识。但知识库知道。所以先让系统从知识库里检索相关资料再把资料交给大模型组织答案。完整链路可以记成文档切分向量化建索引问题召回候选重排上下文拼接生成回答效果评估如果基础链路已经不够用再考虑 Hybrid RAG、Multi-hop RAG、GraphRAG、Agentic RAG 这些增强形态。它们解决的不是同一个问题Hybrid RAG 解决“语义匹配 精确命中”的问题Multi-hop RAG 解决“答案分散在多份文档里”的问题GraphRAG 解决“实体关系复杂、跨文档关联强”的问题Agentic RAG 解决“任务步骤不固定、需要多轮查证”的问题RAG 比重新训练模型更贴近很多真实业务场景。因为业务需要的往往不是让模型把所有资料背下来而是让它在回答时能查到正确资料、引用正确依据、给出稳定答案。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】