1. 从能跑通到敢上线agentic RAG 课程到底在解决什么如果你已经用 LangChain 或者 LlamaIndex 搭过一个能回答问题的 RAG demo大概率经历过这个阶段本地跑得挺欢文档一多就开始胡言乱语用户问一个需要跨三份文档才能拼出答案的问题系统直接给你编一段听起来很合理但完全错误的内容。这不是你的 prompt 写得不好而是朴素 RAG 的架构本身就到瓶颈了。production-agentic-rag-course这个标题里有两个词值得拆开看production和agentic。前者意味着这套东西不是给你在 notebook 里跑着玩的它要面对真实流量、真实脏数据、真实并发后者意味着检索这件事不再是一次性的向量搜索 拼接 生成而是由模型自己决定我要不要检索、检索几轮、用哪个工具检索、检索结果够不够、不够要不要换个问法再来一次。我见过太多团队卡在同一个位置demo 阶段用 200 页 PDF 效果惊艳一上生产知识库变成 2 万份文档、格式横跨 PDF/Word/Excel/网页快照、还有大量扫描件和图表召回率断崖式下跌。这时候你需要的不是换一个更大的 embedding 模型而是把整个检索链路从管道改造成智能体。这篇内容适合三类人一是已经写过基础 RAG、想搞清楚 agentic 到底怎么落地的工程师二是正在被RAG 瓶颈折磨、想知道知识库该怎么分层设计的技术负责人三是想系统学习 RAG 实战、包括在 Mac 上从零搭一套可演进知识库的开发者。我会把课程背后涉及的核心机制、工程取舍、踩坑经验全部摊开讲不讲空话只讲能直接抄作业的东西。2. 朴素 RAG 到底卡在哪四个瓶颈的根因拆解2.1 单轮检索的一锤子买卖问题朴素 RAG 的流程是固定的用户提问 → 向量化 → top-k 检索 → 拼进 prompt → 生成。这个流程最大的问题是它假设第一次检索一定命中。但真实场景里用户的问法千奇百怪embedding 空间里的相似度和语义相关性经常对不上。举个我实际遇到的例子用户问去年Q3我们在大客户续约上踩了什么坑向量检索很可能召回一堆Q3季度总结客户续约流程的文档但真正包含坑的那份复盘纪要因为措辞是经验教训而不是坑相似度排到了第 15 位top-5 根本捞不到。单轮检索没有第二次机会模型只能拿着半相关的内容硬编。Agentic RAG 的核心改动就在这里把检索变成可迭代的动作。模型先看检索结果判断这些内容能不能回答如果不能它会改写查询、换检索策略、或者拆成子问题分别检索。这个判断—行动—再判断的循环就是 agentic 的本质。2.2 知识库一锅炖导致的召回污染很多人的 RAG 知识库是把所有文档一股脑塞进一个向量库这在小规模下没问题但文档一多就出大问题。原因在于不同类型的知识检索方式根本不一样。结构化知识比如产品参数表、价格表、组织架构这类内容用向量检索是浪费直接查数据库或走 SQL 更准。半结构化知识比如带标题层级的制度文档、API 文档需要保留层级关系检索时要能定位到章节而不是碎片。非结构化知识比如会议纪要、客服对话、经验分享这类才真正适合向量检索。图谱化知识比如实体之间的关系A 产品依赖 B 组件B 组件由 C 团队维护这类需要知识图谱来承载。把这几类混在一个索引里结果就是结构化查询被向量相似度带偏非结构化的语义又被结构化字段干扰。RAG 知识库和结构化知识库必须区分对待这是 agentic 系统能路由到正确工具的前提。2.3 多模态内容被文本化后的信息丢失热词里有个很实际的问题RAG 知识库能存储图片吗答案是能但存进去和用起来是两回事。大部分方案是把图片 OCR 成文字再入库这会导致两类信息永久丢失一是图表里的趋势和对比关系OCR 只能提取数字提取不了这条线在上升二是流程图、架构图里的空间关系。生产级 agentic RAG 的做法是多模态分治图片单独存用多模态 embedding比如 CLIP 类模型建索引检索时文本走文本通道、图片走图片通道最后由 agent 决定要不要把图片喂给多模态大模型做理解。这比无脑 OCR 复杂但这是能上线和能演示的分水岭。2.4 没有评估闭环优化全靠感觉朴素 RAG 最致命的工程问题是没有量化评估。你改了 chunk size、换了 embedding 模型、调了 top-k效果到底变好还是变差很多人靠我试了几个问题感觉还行来判断这在生产环境是灾难。Agentic RAG 因为链路变长更需要评估。课程里通常会引入检索评估 生成评估两层检索层看 recallk、MRR生成层看忠实度faithfulness和答案相关性。没有这套东西你根本不知道 agent 的再检索一次到底是有用还是添乱。3. Agentic RAG 的架构骨架把管道改成决策循环3.1 从线性管道到感知—决策—行动循环朴素 RAG 是线性的agentic RAG 是循环的。我用一个实际项目的架构来说明这个循环长什么样用户提问进来后先经过一个路由层判断这个问题该走哪条路——是直接查结构化数据库、还是走向量检索、还是需要多步推理。路由可以由一个轻量分类模型做也可以由大模型自己判断。路由之后进入检索执行层这里 agent 可以调用多个工具向量检索、关键词检索BM25、SQL 查询、图谱查询、甚至调用外部 API。关键在检索之后agent 拿到结果要做一个充分性判断。如果结果够进入生成如果不够它会决定下一步动作——改写查询、拆分子问题、换工具、或者扩大检索范围。这个循环可以设最大轮次通常 2-4 轮防止无限循环烧 token。3.2 工具设计agent 能调什么决定了它的上限Agentic RAG 的能力边界本质上由你给它配了哪些工具决定。我建议至少配这几类工具类型适用场景实现要点向量检索语义相似的非结构化内容注意 chunk 策略和 embedding 模型匹配关键词检索精确术语、编号、人名BM25 或倒排索引弥补向量对精确匹配的弱项结构化查询参数、统计、聚合转成 SQL 或 API 调用不要让模型直接写 SQL 上生产图谱查询实体关系、多跳推理需要先建 ontology查询走图遍历多模态检索图片、图表独立索引检索后交给多模态模型理解这里有个经验工具不是越多越好。工具太多agent 的选择困难会显著上升路由准确率反而下降。我一般控制在 4-6 个核心工具每个工具的 description 写得极其明确告诉模型什么时候该用我、什么时候不该用我。3.3 查询改写与子问题拆解的实际做法Agentic RAG 里最值钱的能力是查询改写。当第一轮检索不理想时agent 需要把原始问题改写成更容易命中的形式。常见策略有三种第一种是同义扩展把踩了什么坑扩展成经验教训、问题复盘、失败案例。第二种是具体化把去年Q3具体成2024年7月到9月。第三种是子问题拆解把我们的续约策略和竞品比有什么差异拆成我们的续约策略是什么和竞品的续约策略是什么两个独立检索。实测下来子问题拆解对多跳问题的提升最明显但代价是检索次数翻倍。所以我会给 agent 设一个判断只有当问题里出现对比关系为什么这类词时才触发拆解。3.4 循环终止条件别让 agent 无限检索这是生产环境必须处理的工程问题。Agent 如果判断结果还不够就一直检索token 成本会失控。我的做法是设三重终止条件最大轮次硬性上限一般 3 轮、边际收益判断新一轮检索结果和上一轮重合度超过 80% 就停、置信度阈值agent 自评结果充分性达到阈值就停。提示最大轮次这个参数不要设太大。我见过设成 10 轮的结果一个简单问题烧掉几万 token响应时间从 2 秒变成 30 秒用户体验直接崩掉。4. 知识库分层RAG 知识库、结构化知识库与 KG 的边界4.1 三类知识库的本质区别热词里反复出现rag知识库和结构知识库区分以及应用场景这个问题确实是很多人的困惑点。我用一张表把边界划清楚维度RAG 知识库向量结构化知识库知识图谱KG存储内容非结构化文本、多模态表格、字段、记录实体、关系、属性检索方式语义相似度SQL / 精确匹配图遍历 / 多跳查询擅长问题讲了什么怎么做的是多少有几个有什么关系影响谁典型场景文档问答、经验检索报表查询、参数核对依赖分析、影响面评估更新成本低重新 embedding中改表结构高要维护 ontology关键认知是这三者不是替代关系是互补关系。一个成熟的生产系统往往是 agent 根据问题类型路由到不同的库。问这个产品的价格是多少走结构化库问这个产品为什么定价这么高走 RAG 库问这个产品涨价会影响哪些客户走图谱。4.2 Ontology RAG给检索加上关系维度Ontology RAG 是最近比较热的方向它的思路是在向量检索之上叠加一层本体ontology来约束和增强检索。本体定义了领域内的实体类型、关系类型和约束规则。举个例子在医疗领域本体可以定义疾病—症状—药物—禁忌这几类实体和它们之间的关系。当用户问这个药能不能给这个病人用系统不只是做向量检索还会沿着本体关系去查这个病人的症状是否命中该药的禁忌。这种结构化约束 语义检索的组合比纯向量检索准确率高出一大截。但 ontology RAG 的门槛在于本体建设成本高。你需要领域专家参与定义实体和关系还要持续维护。我的建议是如果你的领域关系复杂、且对准确性要求极高比如金融风控、医疗辅助值得投入如果是通用问答先用好向量 关键词混合检索就够了。4.3 知识库分层的落地策略实际落地时我不会一上来就搞三层架构而是按需演进第一阶段先搭好向量 RAG 库把非结构化文档跑通验证核心场景。第二阶段把高频的精确查询参数、编号、统计抽出来单独建结构化查询接口让 agent 路由过去。第三阶段当出现大量多跳关系问题时再引入图谱。这个演进路径的好处是每一步都有明确的收益验证不会一上来就陷入架构过度设计的泥潭。我见过团队一开始就上图谱结果本体没建好查询准确率还不如纯向量白白浪费三个月。5. 多模态与图片存储RAG 知识库到底能不能存图5.1 图片入库的三条技术路线回到那个高频问题RAG 知识库能存储图片吗能但有三条路线效果和成本差异很大路线一OCR 转文本。把图片里的文字提取出来当作文本入库。优点是实现简单、复用现有文本检索链路缺点是丢失所有视觉信息图表、流程图、示意图基本废掉。路线二多模态 embedding。用 CLIP 这类模型把图片编码成向量和文本向量存在同一个空间或独立空间。检索时可以用文本查图片也可以用图片查图片。优点是保留视觉语义缺点是对细粒度文字内容不敏感且需要额外的模型和存储。路线三图片描述生成。用多模态大模型给每张图生成一段详细描述把描述文本入库原图单独存。检索命中描述后把原图一起喂给多模态模型做最终理解。这是目前生产环境最实用的方案兼顾了检索效果和理解深度。5.2 图片描述生成的实操细节路线三的关键在于描述质量。我一般会要求描述覆盖这几个维度图片类型是图表、流程图还是照片、核心内容图表在表达什么趋势、关键数据点如果有数字要提取、以及可能的用途这张图能回答什么问题。生成描述时有个坑不要让模型自由发挥。我见过模型给一张销售曲线图生成的描述是这是一张展示业务增长的图表这种描述检索时毫无区分度。正确的做法是给模型一个结构化模板强制它填横轴是什么、纵轴是什么、峰值出现在哪、整体趋势如何。5.3 多模态检索的工程取舍多模态检索的成本比纯文本高不少主要体现在存储图片向量维度通常更高和推理多模态模型调用更贵。所以我的策略是分级处理高频访问的图片比如产品图、核心架构图做完整的多模态索引低频图片只做 OCR 描述不建独立向量索引。另外多模态检索的评估比文本更难。文本可以用 recallk图片的相关性很主观。我的做法是建一个小规模的人工标注集定期抽样评估而不是完全依赖自动指标。6. 在 Mac 上从零搭一套可演进的 RAG 知识库6.1 环境准备Mac 上的现实约束Mac 搭 RAG 最大的约束是显存和统一内存。M 系列芯片的统一内存架构让本地跑模型成为可能但也要量力而行。我的经验是16GB 内存的机器本地跑 7B 级别的 embedding 和生成模型勉强够用但一旦上多模态就吃紧32GB 以上会舒服很多。工具链上我推荐用 Python 虚拟环境 本地向量库比如 Chroma 或 LanceDB都支持本地文件存储不需要额外起服务。如果你要跑本地大模型Ollama 是最省心的选择它把模型管理和推理都封装好了。6.2 分阶段搭建从最小可用到生产级第一阶段最小可用 RAG。准备 10-20 份文档用最简单的固定长度切分选一个中文效果好的 embedding 模型搭一个检索 生成的最小链路。这一步的目标不是效果好而是把链路跑通确认每个环节都能工作。第二阶段引入混合检索。加上 BM25 关键词检索和向量检索做融合常用 RRF 倒数排名融合。这一步通常能带来最明显的效果提升因为很多查询其实是精确匹配需求向量检索反而会漏。第三阶段加上 agent 循环。引入查询改写和充分性判断让系统能多轮检索。这一步要配合评估集否则你不知道 agent 是在帮忙还是添乱。第四阶段多模态和分层。按前面讲的策略把图片处理和结构化查询加进来。6.3 评估集建设没有它一切优化都是玄学我必须强调这一点在 Mac 上搭 RAG评估集比模型选型重要十倍。评估集不需要很大50-100 个真实问题就够但必须覆盖你的核心场景并且每个问题都要标注正确答案应该来自哪份文档。有了这个集子你每次改动都能量化对比。我自己的习惯是维护一个表格记录每次改动的 recall5 和答案准确率这样能清楚看到哪个改动真正有效。没有评估集的优化本质上是在赌博。7. 生产化的那些坑我踩过的和见过的7.1 检索质量问题的排查链路当 RAG 答错时很多人第一反应是换模型这是错的。正确的排查顺序是先看检索结果再看生成。我遇到过 80% 的答错其实是检索就没召回正确文档模型只是忠实地基于错误上下文生成。排查时我会把检索到的 top-k 文档和它们的相似度分数打出来人工判断正确文档在不在里面、排第几。如果正确文档根本没召回问题在 embedding 或 chunk 策略如果召回了但排太后问题在排序或融合策略如果召回了也排前面但答案还是错才是生成环节的问题。7.2 Chunk 策略最容易被低估的环节Chunk 策略对效果的影响比大多数人想象的大。固定长度切分简单但会切断语义按段落切分保留了语义但长度不均。我的经验是按语义结构切分 适度重叠优先按标题层级切其次按段落最后才按长度兜底。重叠部分保留 10%-20%防止关键信息正好卡在边界上。还有个细节chunk 里要带上上下文元数据。比如一个 chunk 来自第三章第二节这个层级信息要作为元数据存进去检索时可以辅助过滤生成时也能给模型提供上下文。7.3 成本与延迟的平衡Agentic RAG 因为多轮检索成本和延迟天然比朴素 RAG 高。生产环境必须做平衡。我的做法是简单问题走快路径复杂问题走 agent 路径。用一个轻量分类器判断问题复杂度简单问题直接单轮检索复杂问题才启动 agent 循环。这样大部分请求的延迟能控制在可接受范围只有少数复杂请求会慢一些。另外缓存也很重要。高频问题的检索结果可以缓存避免重复计算。但要注意缓存失效策略知识库更新后要及时清理。7.4 一个真实的翻车案例我见过一个团队agentic RAG 上线后效果反而比朴素 RAG 差。排查发现他们的 agent 判断结果不充分的阈值设得太低导致几乎每个问题都要检索三四轮而多轮检索引入的噪声文档反而干扰了生成。后来把阈值调高、限制最多两轮效果立刻回升。这个案例的教训是agentic 不是越多越好循环要有明确的收益判断。如果一轮检索已经能拿到正确文档多检索只会引入噪声。8. 关于这套课程的学习路径建议如果你打算系统学production-agentic-rag-course这类内容我的建议是不要按章节顺序线性学而是按最小可用 → 逐步增强的路径来。先把最基础的检索生成跑通建立直觉然后带着具体问题去学对应章节——召回不好就学混合检索和 chunk 策略多跳问题答不好就学查询改写和子问题拆解需要处理图片就学多模态。学习过程中一定要自己准备一份真实数据用课程里的方法去处理。看别人跑通和自己跑通是两回事很多坑只有自己踩过才知道。我自己的习惯是每学一个技术点就在自己的知识库上做一次 A/B 对比记录效果变化这样积累下来的经验才是真正属于你的。最后分享一个我一直在用的判断标准如果一个 RAG 系统你不敢让它直接面对用户那它就没到生产级。Agentic RAG 的所有复杂度本质上都是为了跨过这道坎。