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 因为链路变长，更需要评估。课程里通常会引入检索评估 + 生成评估两层：检索层看 recall@k、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 + 描述，不建独立向量索引。
另外，多模态检索的评估比文本更难。文本可以用 recall@k，图片的"相关性"很主观。我的做法是建一个小规模的人工标注集，定期抽样评估，而不是完全依赖自动指标。
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 个真实问题就够，但必须覆盖你的核心场景，并且每个问题都要标注"正确答案应该来自哪份文档"。
有了这个集子，你每次改动都能量化对比。我自己的习惯是维护一个表格，记录每次改动的 recall@5 和答案准确率，这样能清楚看到哪个改动真正有效。没有评估集的优化，本质上是在赌博。
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 的所有复杂度，本质上都是为了跨过这道坎。
