本文深入浅出地介绍了RAG检索增强生成技术帮助程序员和小白理解大模型如何获取原本未知的外部知识。文章从RAG解决的问题出发详细阐述了文档处理、Embedding、混合检索、Rerank等关键步骤并对比了传统RAG与Agentic RAG的区别。此外还探讨了RAG在多轮对话中的应用以及与传统知识库问答系统的区别最后提出了生产级RAG应关注的重点。通过本文读者可以全面了解RAG技术的基本原理和应用场景为大模型开发打下坚实基础。例如企业内部有产品文档、制度、合同、项目资料和会议纪要这些内容并不存在于通用大模型的训练数据中即使是公开信息也可能已经发生变化。如果用户问“公司目前北京地区的差旅住宿标准是多少”模型仅依靠自身知识很可能不知道答案甚至根据常见经验生成一个看起来合理但实际错误的数字。更合理的做法是先从企业知识库中找到最新的差旅制度再让模型基于这些资料回答。这就是 RAGRetrieval-Augmented Generation。但进入 Agentic AI 之后还需要进一步理解RAG 并不等于 Agent知识库问答系统也不等于 Agent。RAG 是 Agent 获取外部知识的一种能力而 Agent 还需要决定什么时候检索、检索什么、是否继续检索以及获取知识以后下一步应该做什么。一、RAG 到底解决什么问题大模型虽然掌握大量通用知识但天然存在几个限制不掌握企业私有数据训练数据存在时间边界很难保证具体事实始终准确不适合把大量企业资料永久放进 Prompt。一个最直接的办法是把所有资料都放进上下文System Prompt 用户问题 企业制度 产品资料 历史文档。但随着资料越来越多很快就会遇到上下文窗口、Token 成本和无关信息干扰等问题。RAG 的核心思路不是把所有知识交给模型而是先找到与当前问题最相关的少量知识再把它们放进本轮上下文。最基本的 RAG 流程用户问题↓检索相关知识↓得到少量证据↓加入模型上下文↓LLM 基于证据生成答案例如用户询问“北京员工出差酒店标准是多少”系统不需要把几十份公司制度全部交给模型而只需要检索出《2026 年差旅管理办法》中与北京住宿标准相关的几个段落。这就是 RAG 最核心的价值让模型按需获得知识而不是要求模型记住所有知识。二、一个完整的 RAG不只是“向量数据库 大模型”很多入门资料会把 RAG 简化为文档 → 向量数据库 → LLM这种理解没有错但对于生产系统来说还远远不够。一个比较完整的 RAG 通常包含两条链路。真正影响 RAG 效果的往往并不是最后一步调用哪个大模型而是前面的 知识处理和检索链路。三、RAG 的第一步其实是把文档处理好假设知识库中有一份 200 页的《员工管理制度》。不能简单把整份 PDF 转成一个向量因为用户询问某一个具体问题时绝大多数内容都是无关的。通常需要先把文档拆成多个 Chunk员工管理制度├─ 第一章 总则├─ 第二章 考勤│ ├─ 工作时间│ ├─ 请假制度│ └─ 加班管理└─ 第三章 差旅 ├─ 交通标准 ├─ 酒店标准 └─ 报销流程这里就会遇到一个典型问题Chunk 应该切多大 如果切得太大一个 Chunk 中可能同时包含大量无关内容降低检索准确率如果切得太碎又可能把一句完整规则的适用条件和具体标准分开。因此RAG 的文档切分正在从早期的固定字符数切分逐渐发展到按段落、标题、语义和文档结构进行切分。对于合同、制度、技术文档、表格等复杂文件还要尽量保留标题层级、表格结构、页码、章节和来源信息。否则即使后续 Embedding 和模型能力再强进入知识库的数据本身已经被破坏最终效果仍然不会理想。四、Embedding让“意思相近”也能够被找到Embedding 可以把文本转换成一组高维向量。例如“员工去北京出差住宿最多可以报销多少”可能被转换成[0.142, -0.287, 0.613, …] 知识库中的每个 Chunk 也会生成对应向量。查询时通过计算 Query Vector 与文档向量之间的距离就可以找到语义最相近的内容。即使制度中写的是“北京地区住宿费标准上限为……”而用户问的是“去北京住酒店最多能报多少”两句话的字面并不完全相同仍然可能通过语义向量被匹配到一起。这就是向量检索相对于传统关键词匹配的主要优势语义泛化它不仅寻找相同的词还可以寻找相近的意思。五、为什么只有向量检索还不够向量搜索擅长语义匹配但对编号、产品型号、人名和精确术语并不一定最稳定。例如用户搜索“BM-2026-0148 合同审批记录”这里最重要的信息实际上是 BM-2026-0148。传统关键词搜索反而更容易准确命中。因此生产级 RAG 越来越常见的方式是Hybrid Search——混合检索。┌─ 向量检索用户 Query ──┤ └─ 关键词 / BM25 检索 ↓ 结果融合两种检索方式分别解决不同问题向量检索关注“意思像不像”关键词检索关注“字面是不是它” 再配合 Metadata Filter可以进一步限制文档类型、创建时间、部门、作者、项目、权限范围等。因此现代 RAG 的检索通常已经不再只是Vector Search而更接近Vector Search Keyword Search Metadata Filter六、Rerank检索之后为什么还要再排一次第一次检索的目标通常是尽量不要漏掉相关内容。因此系统可能先召回 2050 个 Chunk。但如果把几十个 Chunk 全部放入 LLM 上下文不仅 Token 消耗高也可能因为无关信息过多降低最终回答质量。因此通常会增加 RerankQuery↓Retriever↓Top 30↓Reranker↓Top 5↓LLM可以简单理解为Retriever 更关注“召回来”Reranker 更关注“排得准”。Rerank 会重新判断 Query 与每一个候选 Chunk 之间的相关性然后只把最有价值的几个证据交给模型。因此生产 RAG 的典型链路往往是Retrieve → Merge → Rerank → Context → Generate而不是简单的Query → VectorDB → LLM七、引用和证据比“回答得像真的”更重要假设用户问“北京出差酒店标准是多少”系统回答“600 元 / 晚。”对于普通聊天来说这似乎已经完成了任务。但企业知识系统更应该继续告诉用户答案600 元 / 晚来源《2026 年差旅管理办法》 第三章第 12 条 第 8 页因此知识库中的 Chunk 不应该只有正文内容还应该保留 documentId、documentName、page、section、chunkId、score 等元数据。最终返回 答案 Citation。尤其在合同、制度、法律、财务、研发规范等场景中用户往往更关心“凭什么这么说”。因此RAG 的目标不是单纯让模型“回答得更像真的”而应该让答案拥有可以追溯的证据链。八、多轮对话为什么需要 Query RewriteRAG 进入聊天和 Agent 后还会遇到多轮对话的问题。例如第一轮用户问“公司的差旅标准是什么”第二轮继续问“那北京呢”如果直接把“那北京呢”拿去搜索知识库检索系统很难知道用户究竟想查什么。因此需要 Query Rewrite把当前问题结合历史对话改写为“公司当前北京地区的差旅住宿标准是什么” 然后再进行知识检索。完整过程就变成Conversation History Current Query↓Query Rewrite↓Standalone Query↓Retrieval这一步的价值主要是解决指代、省略和上下文依赖。在实际企业问答系统中Query Rewrite 往往会显著影响多轮 RAG 的稳定性。九、传统 RAG 为什么会继续演进到 Agentic RAG传统 RAG 通常是一条固定流水线Query → Retrieve → Rerank → Generate。无论问题简单还是复杂都执行一次检索然后生成答案。对于简单知识问答这种方式已经足够。但如果用户提出“比较 2025 年和 2026 年的销售政策变化并分析哪些调整会影响渠道合作伙伴”一次检索往往很难拿到完整证据。系统可能需要分别查询 2025 年销售政策、2026 年销售政策接着发现渠道返点相关信息不足还需要继续检索 2026 年渠道返点政策最后再将多轮结果进行综合。这时执行流程已经从“一次检索”变成 分析 → 检索 → 判断 → 再检索 → 综合。这就是 Agentic RAG 开始发挥作用的地方。十、Agentic RAG让 Agent 决定“怎么查”Agentic RAG 可以把传统固定检索流程升级为动态决策过程典型执行方式用户问题↓Agent 分析问题↓判断是否需要检索↓生成 / 改写 Query↓执行检索↓Rerank↓判断证据是否充分如果证据不足分析缺失信息 → 生成新 Query → 再次检索如果证据充分基于证据推理 → 生成答案传统 RAG 与 Agentic RAG 对比二者最重要的区别不是使用了不同的向量数据库而是 执行路径是否由 Agent 动态决策。十一、并不是所有问题都需要 Agentic RAGAgentic RAG 看起来比传统 RAG 更“智能”但并不意味着所有知识问答都应该升级。例如用户问“公司年假是多少天”一次普通 RAG 检索就可以完成Query → Retrieve → Answer。如果强行加入规划、反思、多轮检索反而会增加调用次数、Token 消耗、延迟和不确定性。因此更合理的架构是简单问题 → Traditional RAG如单一制度查询复杂问题 → Agentic RAG多文档对比、跨来源验证、复杂条件组合、多跳推理这仍然符合本系列一直强调的原则能用确定性流程解决的问题不必全部交给 Agent 自主判断。十二、RAG 也正在从向量检索继续扩展传统 RAG 最适合回答“哪个文档片段与这个问题最相关”。但有些问题真正关注的是实体之间的关系例如“A 公司与 B 公司参与过哪些共同项目这些项目分别由谁负责” 这类问题往往需要跨多个文档建立公司 → 项目 → 人员 → 合同之间的关系。于是出现了 GraphRAG文档 → 抽取实体/属性/关系 → 构建知识图谱 → 图关系检索 语义检索 → 多跳推理。目前 RAG 已经逐渐从最初的 Chunk Embedding VectorDB扩展为Naive RAG↓Hybrid RAG↓Rerank RAG↓GraphRAG↓Agentic RAG这些方式并不是简单的版本替代而是针对不同问题复杂度增加新的检索和推理能力。十三、一个更完整的 Agentic RAG 实例假设用户告诉一个合同分析 Agent“分析这批供应商合同找出付款、违约和解除条款中与公司最新采购制度冲突的内容并给出修改建议。”这里已经同时使用了前几篇介绍的能力Context Engineering负责管理本轮模型应该看到什么。Function Calling负责调用合同解析、文件读取等程序能力。Structured Output负责把风险项输出成程序可以处理的数据。RAG负责获取企业制度知识。Agent负责把这些能力组合起来完成整个任务。这也是为什么进入 Agentic AI 后单独理解某一个技术还不够更重要的是理解这些能力如何在 Agent Loop 中协同。十四、RAG、Memory 和 Tool 到底有什么区别这是 Agent 开发中最容易混淆的几个概念。能力主要解决的问题典型内容RAG去哪里找外部知识文档、制度、合同、知识库Memory以前发生过什么用户偏好、历史任务、长期信息Tool如何获取实时数据或执行操作API、数据库、搜索、文件系统Context本轮模型实际看到什么Prompt、RAG、Memory、Tool ResultAgent下一步应该做什么判断、规划、选择能力例如用户说“按照公司差旅制度帮我规划下周去上海的行程我还是喜欢以前住过的安静型酒店。” 系统可能这样处理公司差旅标准 → RAG喜欢安静型酒店 → Memory查询实时酒店价格 → Tool创建预订 → Tool是否需要检索、什么时候调用工具 → Agent。因此可以用一句话区分RAG 提供知识Memory 提供历史Tool 提供行动能力而 Agent 决定如何使用它们。十五、为什么“知识库问答系统”不能直接等同于 Agent现在不少 AI 系统的流程实际上是上传 PDF → 建立向量库 → 用户提问 → RAG → LLM 回答。如果流程始终是预先固定的每次问题都必须检索然后生成答案它更准确的定位仍然是 RAG Knowledge Assistant——知识库问答助手。真正进入 Agent 之后系统需要能够根据目标动态决定用户目标 ↓Agent ├─ 不需要知识 → 直接处理 ├─ 需要企业知识 → RAG ├─ 需要历史信息 → Memory ├─ 需要实时数据 → Tool ├─ 证据不足 → 再次 RAG ├─ 需要业务操作 → Function Calling └─ 完成任务 → Structured OutputRAG 是 Agent 的一个能力而非 Agent 本身。 这也是本篇最重要的概念边界。十六、生产级 RAG 真正应该关注什么真正建设企业 RAG 系统时与“选择哪个向量数据库”相比还有几个问题更值得关注。1. 知识质量如果知识库中存在过期制度、重复文档、错误版本和相互冲突的内容再好的检索算法也只能更加准确地找到错误知识。因此需要建立版本、有效期、来源和知识治理机制。2. 权限过滤用户只能检索自己有权限访问的文档。权限控制应该发生在检索阶段而不是先把所有文档检索出来并送入 LLM再决定哪些答案不能显示。否则可能已经产生数据泄漏。3. 可观测性至少应该记录Original Query、Rewritten Query、Retriever、Top-K、Rerank Score、最终证据、引用来源、Token、Latency。当用户说“这个答案不对”系统才能判断到底是文档没有入库、Chunk 切错、没有召回、Rerank 排错还是模型最终推理出了问题。4. 无证据时不要强行回答如果知识库没有足够证据更合理的结果应该是“抱歉未找到相关信息”而不是要求模型利用常识补全一个答案。RAG 的目标之一本身就是减少模型脱离证据自由生成带来的幻觉风险。十七、本篇小结RAG 最核心的思想其实非常简单不要要求模型记住所有知识而是在需要时把正确的知识找到并加入当前上下文。真正需要记住的是知识库负责保存知识RAG 负责找到知识Memory 负责保存历史Tool 负责获取实时数据和执行操作Agent 负责根据目标决定下一步。到这里第 69 篇介绍的几项基础能力已经逐渐连接起来Context Engineering如何给模型准备正确的上下文Function Calling如何让模型调用程序能力Structured Output如何让模型把结果可靠交给程序RAG如何让模型获得外部知识如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取 本文深入浅出地介绍了RAG检索增强生成技术帮助程序员和小白理解大模型如何获取原本未知的外部知识。文章从RAG解决的问题出发详细阐述了文档处理、Embedding、混合检索、Rerank等关键步骤并对比了传统RAG与Agentic RAG的区别。此外还探讨了RAG在多轮对话中的应用以及与传统知识库问答系统的区别最后提出了生产级RAG应关注的重点。通过本文读者可以全面了解RAG技术的基本原理和应用场景为大模型开发打下坚实基础。例如企业内部有产品文档、制度、合同、项目资料和会议纪要这些内容并不存在于通用大模型的训练数据中即使是公开信息也可能已经发生变化。如果用户问“公司目前北京地区的差旅住宿标准是多少”模型仅依靠自身知识很可能不知道答案甚至根据常见经验生成一个看起来合理但实际错误的数字。更合理的做法是先从企业知识库中找到最新的差旅制度再让模型基于这些资料回答。这就是 RAGRetrieval-Augmented Generation。但进入 Agentic AI 之后还需要进一步理解RAG 并不等于 Agent知识库问答系统也不等于 Agent。RAG 是 Agent 获取外部知识的一种能力而 Agent 还需要决定什么时候检索、检索什么、是否继续检索以及获取知识以后下一步应该做什么。一、RAG 到底解决什么问题大模型虽然掌握大量通用知识但天然存在几个限制不掌握企业私有数据训练数据存在时间边界很难保证具体事实始终准确不适合把大量企业资料永久放进 Prompt。一个最直接的办法是把所有资料都放进上下文System Prompt 用户问题 企业制度 产品资料 历史文档。但随着资料越来越多很快就会遇到上下文窗口、Token 成本和无关信息干扰等问题。RAG 的核心思路不是把所有知识交给模型而是先找到与当前问题最相关的少量知识再把它们放进本轮上下文。最基本的 RAG 流程用户问题↓检索相关知识↓得到少量证据↓加入模型上下文↓LLM 基于证据生成答案例如用户询问“北京员工出差酒店标准是多少”系统不需要把几十份公司制度全部交给模型而只需要检索出《2026 年差旅管理办法》中与北京住宿标准相关的几个段落。这就是 RAG 最核心的价值让模型按需获得知识而不是要求模型记住所有知识。二、一个完整的 RAG不只是“向量数据库 大模型”很多入门资料会把 RAG 简化为文档 → 向量数据库 → LLM这种理解没有错但对于生产系统来说还远远不够。一个比较完整的 RAG 通常包含两条链路。真正影响 RAG 效果的往往并不是最后一步调用哪个大模型而是前面的 知识处理和检索链路。三、RAG 的第一步其实是把文档处理好假设知识库中有一份 200 页的《员工管理制度》。不能简单把整份 PDF 转成一个向量因为用户询问某一个具体问题时绝大多数内容都是无关的。通常需要先把文档拆成多个 Chunk员工管理制度├─ 第一章 总则├─ 第二章 考勤│ ├─ 工作时间│ ├─ 请假制度│ └─ 加班管理└─ 第三章 差旅 ├─ 交通标准 ├─ 酒店标准 └─ 报销流程这里就会遇到一个典型问题Chunk 应该切多大 如果切得太大一个 Chunk 中可能同时包含大量无关内容降低检索准确率如果切得太碎又可能把一句完整规则的适用条件和具体标准分开。因此RAG 的文档切分正在从早期的固定字符数切分逐渐发展到按段落、标题、语义和文档结构进行切分。对于合同、制度、技术文档、表格等复杂文件还要尽量保留标题层级、表格结构、页码、章节和来源信息。否则即使后续 Embedding 和模型能力再强进入知识库的数据本身已经被破坏最终效果仍然不会理想。四、Embedding让“意思相近”也能够被找到Embedding 可以把文本转换成一组高维向量。例如“员工去北京出差住宿最多可以报销多少”可能被转换成[0.142, -0.287, 0.613, …] 知识库中的每个 Chunk 也会生成对应向量。查询时通过计算 Query Vector 与文档向量之间的距离就可以找到语义最相近的内容。即使制度中写的是“北京地区住宿费标准上限为……”而用户问的是“去北京住酒店最多能报多少”两句话的字面并不完全相同仍然可能通过语义向量被匹配到一起。这就是向量检索相对于传统关键词匹配的主要优势语义泛化它不仅寻找相同的词还可以寻找相近的意思。五、为什么只有向量检索还不够向量搜索擅长语义匹配但对编号、产品型号、人名和精确术语并不一定最稳定。例如用户搜索“BM-2026-0148 合同审批记录”这里最重要的信息实际上是 BM-2026-0148。传统关键词搜索反而更容易准确命中。因此生产级 RAG 越来越常见的方式是Hybrid Search——混合检索。┌─ 向量检索用户 Query ──┤ └─ 关键词 / BM25 检索 ↓ 结果融合两种检索方式分别解决不同问题向量检索关注“意思像不像”关键词检索关注“字面是不是它” 再配合 Metadata Filter可以进一步限制文档类型、创建时间、部门、作者、项目、权限范围等。因此现代 RAG 的检索通常已经不再只是Vector Search而更接近Vector Search Keyword Search Metadata Filter六、Rerank检索之后为什么还要再排一次第一次检索的目标通常是尽量不要漏掉相关内容。因此系统可能先召回 2050 个 Chunk。但如果把几十个 Chunk 全部放入 LLM 上下文不仅 Token 消耗高也可能因为无关信息过多降低最终回答质量。因此通常会增加 RerankQuery↓Retriever↓Top 30↓Reranker↓Top 5↓LLM可以简单理解为Retriever 更关注“召回来”Reranker 更关注“排得准”。Rerank 会重新判断 Query 与每一个候选 Chunk 之间的相关性然后只把最有价值的几个证据交给模型。因此生产 RAG 的典型链路往往是Retrieve → Merge → Rerank → Context → Generate而不是简单的Query → VectorDB → LLM七、引用和证据比“回答得像真的”更重要假设用户问“北京出差酒店标准是多少”系统回答“600 元 / 晚。”对于普通聊天来说这似乎已经完成了任务。但企业知识系统更应该继续告诉用户答案600 元 / 晚来源《2026 年差旅管理办法》 第三章第 12 条 第 8 页因此知识库中的 Chunk 不应该只有正文内容还应该保留 documentId、documentName、page、section、chunkId、score 等元数据。最终返回 答案 Citation。尤其在合同、制度、法律、财务、研发规范等场景中用户往往更关心“凭什么这么说”。因此RAG 的目标不是单纯让模型“回答得更像真的”而应该让答案拥有可以追溯的证据链。八、多轮对话为什么需要 Query RewriteRAG 进入聊天和 Agent 后还会遇到多轮对话的问题。例如第一轮用户问“公司的差旅标准是什么”第二轮继续问“那北京呢”如果直接把“那北京呢”拿去搜索知识库检索系统很难知道用户究竟想查什么。因此需要 Query Rewrite把当前问题结合历史对话改写为“公司当前北京地区的差旅住宿标准是什么” 然后再进行知识检索。完整过程就变成Conversation History Current Query↓Query Rewrite↓Standalone Query↓Retrieval这一步的价值主要是解决指代、省略和上下文依赖。在实际企业问答系统中Query Rewrite 往往会显著影响多轮 RAG 的稳定性。九、传统 RAG 为什么会继续演进到 Agentic RAG传统 RAG 通常是一条固定流水线Query → Retrieve → Rerank → Generate。无论问题简单还是复杂都执行一次检索然后生成答案。对于简单知识问答这种方式已经足够。但如果用户提出“比较 2025 年和 2026 年的销售政策变化并分析哪些调整会影响渠道合作伙伴”一次检索往往很难拿到完整证据。系统可能需要分别查询 2025 年销售政策、2026 年销售政策接着发现渠道返点相关信息不足还需要继续检索 2026 年渠道返点政策最后再将多轮结果进行综合。这时执行流程已经从“一次检索”变成 分析 → 检索 → 判断 → 再检索 → 综合。这就是 Agentic RAG 开始发挥作用的地方。十、Agentic RAG让 Agent 决定“怎么查”Agentic RAG 可以把传统固定检索流程升级为动态决策过程典型执行方式用户问题↓Agent 分析问题↓判断是否需要检索↓生成 / 改写 Query↓执行检索↓Rerank↓判断证据是否充分如果证据不足分析缺失信息 → 生成新 Query → 再次检索如果证据充分基于证据推理 → 生成答案传统 RAG 与 Agentic RAG 对比二者最重要的区别不是使用了不同的向量数据库而是 执行路径是否由 Agent 动态决策。十一、并不是所有问题都需要 Agentic RAGAgentic RAG 看起来比传统 RAG 更“智能”但并不意味着所有知识问答都应该升级。例如用户问“公司年假是多少天”一次普通 RAG 检索就可以完成Query → Retrieve → Answer。如果强行加入规划、反思、多轮检索反而会增加调用次数、Token 消耗、延迟和不确定性。因此更合理的架构是简单问题 → Traditional RAG如单一制度查询复杂问题 → Agentic RAG多文档对比、跨来源验证、复杂条件组合、多跳推理这仍然符合本系列一直强调的原则能用确定性流程解决的问题不必全部交给 Agent 自主判断。十二、RAG 也正在从向量检索继续扩展传统 RAG 最适合回答“哪个文档片段与这个问题最相关”。但有些问题真正关注的是实体之间的关系例如“A 公司与 B 公司参与过哪些共同项目这些项目分别由谁负责” 这类问题往往需要跨多个文档建立公司 → 项目 → 人员 → 合同之间的关系。于是出现了 GraphRAG文档 → 抽取实体/属性/关系 → 构建知识图谱 → 图关系检索 语义检索 → 多跳推理。目前 RAG 已经逐渐从最初的 Chunk Embedding VectorDB扩展为Naive RAG↓Hybrid RAG↓Rerank RAG↓GraphRAG↓Agentic RAG这些方式并不是简单的版本替代而是针对不同问题复杂度增加新的检索和推理能力。十三、一个更完整的 Agentic RAG 实例假设用户告诉一个合同分析 Agent“分析这批供应商合同找出付款、违约和解除条款中与公司最新采购制度冲突的内容并给出修改建议。”这里已经同时使用了前几篇介绍的能力Context Engineering负责管理本轮模型应该看到什么。Function Calling负责调用合同解析、文件读取等程序能力。Structured Output负责把风险项输出成程序可以处理的数据。RAG负责获取企业制度知识。Agent负责把这些能力组合起来完成整个任务。这也是为什么进入 Agentic AI 后单独理解某一个技术还不够更重要的是理解这些能力如何在 Agent Loop 中协同。十四、RAG、Memory 和 Tool 到底有什么区别这是 Agent 开发中最容易混淆的几个概念。能力主要解决的问题典型内容RAG去哪里找外部知识文档、制度、合同、知识库Memory以前发生过什么用户偏好、历史任务、长期信息Tool如何获取实时数据或执行操作API、数据库、搜索、文件系统Context本轮模型实际看到什么Prompt、RAG、Memory、Tool ResultAgent下一步应该做什么判断、规划、选择能力例如用户说“按照公司差旅制度帮我规划下周去上海的行程我还是喜欢以前住过的安静型酒店。” 系统可能这样处理公司差旅标准 → RAG喜欢安静型酒店 → Memory查询实时酒店价格 → Tool创建预订 → Tool是否需要检索、什么时候调用工具 → Agent。因此可以用一句话区分RAG 提供知识Memory 提供历史Tool 提供行动能力而 Agent 决定如何使用它们。十五、为什么“知识库问答系统”不能直接等同于 Agent现在不少 AI 系统的流程实际上是上传 PDF → 建立向量库 → 用户提问 → RAG → LLM 回答。如果流程始终是预先固定的每次问题都必须检索然后生成答案它更准确的定位仍然是 RAG Knowledge Assistant——知识库问答助手。真正进入 Agent 之后系统需要能够根据目标动态决定用户目标 ↓Agent ├─ 不需要知识 → 直接处理 ├─ 需要企业知识 → RAG ├─ 需要历史信息 → Memory ├─ 需要实时数据 → Tool ├─ 证据不足 → 再次 RAG ├─ 需要业务操作 → Function Calling └─ 完成任务 → Structured OutputRAG 是 Agent 的一个能力而非 Agent 本身。 这也是本篇最重要的概念边界。十六、生产级 RAG 真正应该关注什么真正建设企业 RAG 系统时与“选择哪个向量数据库”相比还有几个问题更值得关注。1. 知识质量如果知识库中存在过期制度、重复文档、错误版本和相互冲突的内容再好的检索算法也只能更加准确地找到错误知识。因此需要建立版本、有效期、来源和知识治理机制。2. 权限过滤用户只能检索自己有权限访问的文档。权限控制应该发生在检索阶段而不是先把所有文档检索出来并送入 LLM再决定哪些答案不能显示。否则可能已经产生数据泄漏。3. 可观测性至少应该记录Original Query、Rewritten Query、Retriever、Top-K、Rerank Score、最终证据、引用来源、Token、Latency。当用户说“这个答案不对”系统才能判断到底是文档没有入库、Chunk 切错、没有召回、Rerank 排错还是模型最终推理出了问题。4. 无证据时不要强行回答如果知识库没有足够证据更合理的结果应该是“抱歉未找到相关信息”而不是要求模型利用常识补全一个答案。RAG 的目标之一本身就是减少模型脱离证据自由生成带来的幻觉风险。十七、本篇小结RAG 最核心的思想其实非常简单不要要求模型记住所有知识而是在需要时把正确的知识找到并加入当前上下文。真正需要记住的是知识库负责保存知识RAG 负责找到知识Memory 负责保存历史Tool 负责获取实时数据和执行操作Agent 负责根据目标决定下一步。到这里第 69 篇介绍的几项基础能力已经逐渐连接起来Context Engineering如何给模型准备正确的上下文Function Calling如何让模型调用程序能力Structured Output如何让模型把结果可靠交给程序RAG如何让模型获得外部知识如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取 
