1. 从“能跑通”到“敢上线”Agentic RAG 的工程化分水岭很多人第一次接触 RAG都是从一段几十行的脚本开始的加载文档、切块、向量化、检索、拼进 Prompt、调模型。跑通那一刻确实很爽但只要你把它往真实业务里推一步问题就会像潮水一样涌上来——检索召回忽高忽低、多跳问题答不全、知识库更新后旧答案还在、用户问“上个月那份合同里的违约金比例”时系统直接懵掉。这就是我常说的RAG 瓶颈Demo 阶段靠的是模型能力兜底生产阶段拼的是工程体系。production-agentic-rag-course这个标题核心就落在两个词上production和agentic。前者意味着它讨论的不是“怎么搭一个能问答的机器人”而是“怎么搭一个能扛住真实流量、真实数据、真实刁钻问题的系统”后者意味着它不再把 RAG 当成一条固定的“检索→生成”流水线而是把检索本身变成一个会思考、会决策、会多轮行动的过程。简单说普通 RAG 是“查一次就答”Agentic RAG 是“想清楚要查什么、查几次、查完够不够、不够再查”。这篇文章适合三类人看一是已经把基础 RAG 跑通、但卡在效果和稳定性上的开发者二是正在做企业知识库、智能客服、文档问答的产品和技术负责人三是想系统理解agentic、rag 框架、kg 知识库这些概念到底怎么落地的人。我会围绕这个课程标题背后的技术主线把整体设计思路、核心细节、实操过程、常见坑全部拆开讲尽量做到你看完能直接对照自己的项目改。先说一个我踩过的坑。早期我做过一个内部文档问答向量库用的是最朴素的固定长度切块检索 Top-5 直接塞给模型。上线第一周用户反馈最多的问题是“答非所问”。排查后发现问题根本不在模型而在检索一份 30 页的制度文档被切成 200 个字一块关键条款被切断了上下文检索出来的片段语义不完整模型只能靠猜。后来我引入重排和查询改写准确率肉眼可见地往上走。这件事让我彻底明白RAG 的效果上限往往由检索质量决定而不是模型参数决定。Agentic RAG 要解决的正是把这个“检索质量”从静态变成动态、从单次变成多轮。2. 整体架构设计为什么 Agentic 是 RAG 的必经之路2.1 普通 RAG 的三个结构性缺陷要理解 Agentic RAG 的价值得先看清普通 RAG 到底差在哪。我把它的缺陷归纳为三条每一条都对应一个真实场景。第一条是查询与文档的语义鸿沟。用户问“报销流程怎么走”文档里写的是“费用核销操作规范”字面不重合纯向量检索可能召回一堆不相关的财务制度。用户的口语化表达和文档的书面化表述之间天然存在一道沟。第二条是单次检索无法覆盖多跳推理。用户问“去年营收增长最快的部门它的负责人是谁”这需要先查营收数据、再定位部门、再查组织架构一次检索根本拿不全。普通 RAG 只能把问题原样丢给检索器检索器只能返回它“觉得像”的片段。第三条是缺乏自我校验。检索回来的内容到底相不相关、够不够回答问题普通 RAG 没有判断机制直接一股脑塞给模型。模型要么硬答要么幻觉要么说“根据提供的资料无法回答”——而其实资料库里明明有答案只是没被检索到。提示如果你现在的 RAG 系统经常出现“资料里有但答不出”的情况八成不是模型问题而是检索链路缺少决策和校验环节。2.2 Agentic RAG 的核心思想把检索变成“行动”Agentic RAG 的本质是把大模型从“被动接收检索结果的生成器”升级为“主动决定检索策略的智能体”。它具备几个关键能力查询理解与改写、工具调用检索只是其中一种工具、多轮迭代、结果评估与反思。打个比方。普通 RAG 像一个只会按关键词去图书馆找书的实习生你说“帮我找点关于合同的资料”他抱回来一堆书对不对全看运气。Agentic RAG 像一个有经验的研究助理他会先问你“你是要合同模板、合同法规还是合同纠纷案例”然后去对应区域找翻了几本发现不够再换个书架继续找最后还会告诉你“这几本比较相关但那本可能过时了”。这个“研究助理”的工作方式对应到技术实现上就是一套Plan → Act → Observe → Reflect的循环。Plan 阶段做查询改写和任务拆解Act 阶段调用检索工具、可能还有数据库查询、API 调用Observe 阶段拿到结果Reflect 阶段判断是否足够不够就回到 Plan 重新来。这个循环可以跑一到三轮直到信息足够或达到预算上限。2.3 方案选型为什么不是“堆更多向量”有人会问既然检索不准那我多召回一些、把 Top-20 全塞进去不就行了我实测过这条路走不通。一是上下文窗口有限塞太多会挤掉真正有用的信息还会让模型注意力分散二是噪声比例上升模型被无关内容干扰反而更容易答错三是成本和延迟飙升生产环境扛不住。所以正确的方向不是“堆量”而是“提纯”和“多轮”。提纯靠的是重排Rerank和查询改写多轮靠的是Agent 循环。这也是production-agentic-rag-course这类课程通常会覆盖的主线先解决单次检索的质量再解决多跳和复杂问题的覆盖最后解决工程上的稳定性、可观测性和成本控制。维度普通 RAGAgentic RAG检索次数单次多轮迭代查询处理原样检索改写、拆解、扩展结果校验无有评估与反思工具范围仅向量检索向量、关键词、图数据库、API适用问题简单事实问答多跳、对比、推理类问题工程复杂度低中高3. 核心细节解析知识库、检索与 Agent 循环3.1 RAG 知识库到底能存什么图片行不行这是热词里被问得最多的问题之一rag 知识库能存储图片嘛答案是能但要分清楚“存”和“用”是两回事。向量库本身存的是向量图片可以通过多模态嵌入模型转成向量存进去检索时用文本查询去匹配图片向量这叫跨模态检索。但更常见的工程做法是图片不直接进向量库而是把图片的文字描述、OCR 提取的文本、图片所在的上下文存进去图片本体存在对象存储里向量库里存一个指向图片的引用。检索命中后把图片 URL 一起返回给前端展示。为什么这么做因为纯图片向量的检索精度目前还不够稳尤其是文档里的图表、流程图直接做图像嵌入效果往往不如“OCR 描述”来得可靠。我在做产品手册问答时就吃过亏直接把产品图做嵌入用户问“这个接口长什么样”检索回来的图经常对不上。后来改成对每张图生成结构化描述接口类型、引脚数、颜色标识检索准确率立刻上来了。注意如果你的知识库里有大量图表建议走“图片描述 OCR 原图引用”的组合方案而不是指望图像嵌入一步到位。3.2 RAG 知识库和结构化知识库的区别与应用场景热词里还有一个高频问题rag 知识库和结构知识库区分以及应用场景。这两者不是替代关系而是互补关系理解清楚能帮你少走很多弯路。RAG 知识库非结构化/半结构化擅长处理的是文档、邮件、聊天记录、PDF、网页这类“自然语言为主”的内容。它的优势是灵活什么都能塞缺点是精确查询能力弱比如“统计上季度华东区销售额”这种聚合问题向量检索基本无能为力。结构化知识库关系库、图数据库、kg 知识库擅长处理的是实体、关系、属性明确的数据。比如“张三属于哪个部门”“A 产品的供应商是谁”这类问题用图查询或 SQL 秒出结果而且可解释、可追溯。缺点是构建成本高需要预先定义 schema 和本体ontology。实际生产里最稳的做法是混合架构用 RAG 处理开放式的文档问答用结构化库处理精确查询和关系推理Agent 负责判断当前问题该走哪条路。比如用户问“帮我找找关于供应商违约的合同条款”走 RAG用户问“我们一共有多少个供应商”走 SQL。Agent 的价值就在于它能做这个路由决策。对比项RAG 知识库结构化/KG 知识库数据类型文本、PDF、图片描述实体、关系、属性查询方式语义相似度检索精确查询、图遍历优势灵活、易扩展精确、可解释劣势精确聚合弱构建成本高典型场景文档问答、客服关系推理、统计报表3.3 切块策略被低估的效果杠杆切块Chunking是 RAG 里最不起眼、却最影响效果的环节。我见过太多项目模型换了三四个效果就是上不去最后发现是切块切废了。固定长度切块简单但会切断语义。按段落切块好一些但遇到长段落还是得再切。我目前比较推荐的组合是按语义边界切标题、段落、列表项 重叠窗口overlap 元数据附加。重叠窗口是为了防止关键信息正好落在切口上一般设 chunk 的 10% 到 20%。元数据来源文件、章节、页码、时间一定要带上后面做引用溯源和过滤全靠它。还有一个细节父子块Parent-Child策略。检索时用小块精确匹配返回时给大块完整上下文。这样既保证了检索精度又保证了生成时有足够上下文。这个策略在多跳问答里特别有用我实测下来比单纯调大 chunk size 效果好得多。3.4 查询改写与重排让检索“听懂人话”查询改写解决的是“用户说的”和“文档写的”不一致的问题。常见手法有三种同义扩展把口语词映射到书面词、多查询生成一个问题生成多个角度的查询分别检索后合并、HyDE先让模型生成一个假想答案再用这个答案去检索。重排解决的是“召回了一堆哪个最相关”的问题。向量检索是粗筛重排模型是精筛。流程是向量检索召回 Top-50重排模型打分排序取 Top-5 给生成模型。重排模型通常比嵌入模型更重、更准但只对少量候选打分成本可控。我一般用交叉编码器类的重排模型效果比纯向量排序稳定不少。提示查询改写和重排是“性价比最高”的两个优化点。如果你只能做两件事来提升 RAG 效果就做这两个。4. 实操过程从零搭一个可上线的 Agentic RAG4.1 环境准备与依赖选型先明确技术栈。向量库我推荐从轻量级开始本地开发用 FAISS 或 Chroma生产环境再考虑 Milvus、Qdrant 这类支持分布式和过滤的。嵌入模型选中文效果好的重排模型单独配一个。Agent 编排框架可以用 LangGraph 或自己写状态机前者省事后者可控。在 Mac 上搭建的话注意几个点Apple Silicon 对某些深度学习库的兼容性要确认版本Python 建议用 3.10 或 3.11虚拟环境一定要隔离。如果本地跑嵌入模型吃力可以先用 API 版本过渡等流程跑通再换本地模型。# 创建隔离环境 python3.11 -m venv rag_env source rag_env/bin/activate # 核心依赖 pip install langchain langgraph chromadb sentence-transformers pip install rank-bm25 jieba # 关键词检索用4.2 数据入库清洗、切块、元数据入库这一步决定了后面检索的天花板。我的流程是解析 → 清洗 → 切块 → 打标 → 向量化 → 入库。解析阶段PDF 用 PyMuPDF 或 pdfplumber注意处理表格和双栏排版。清洗阶段去掉页眉页脚、乱码、重复空行。切块按前面说的语义边界加重叠。打标阶段给每个块加上来源、章节、时间、文档类型。向量化时批量处理注意控制 batch size太大容易爆内存。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, # 约 16% 重叠 separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(raw_text) # 每个 chunk 附加元数据后再入库4.3 Agent 循环的实现骨架Agent 循环是整个系统的“大脑”。我用一个简化的状态机来说明核心是四个节点理解问题 → 决定行动 → 执行检索 → 评估结果。def agentic_rag(question, max_rounds3): context [] for round in range(max_rounds): # 1. 改写查询 queries rewrite_query(question, context) # 2. 多路检索 docs [] for q in queries: docs vector_search(q, top_k10) docs bm25_search(q, top_k10) # 3. 重排 docs rerank(question, docs, top_k5) # 4. 评估是否足够 if is_sufficient(question, context docs): break context docs # 5. 生成答案 return generate(question, context)这里的关键是is_sufficient这个评估函数。它可以用一个小模型来判断“当前上下文能否回答问题”也可以让主模型自己判断。我一般用主模型加一个结构化输出让它返回“足够/不足够 缺什么”缺什么就作为下一轮改写的输入。4.4 参数计算与预算控制Agentic RAG 最大的风险是成本失控。多轮检索、多次模型调用如果不设上限一个复杂问题可能烧掉几十次调用。我的做法是设三个预算最大轮数一般 3 轮、最大检索次数每轮不超过 4 次、最大 token 预算上下文总长不超过模型窗口的 70%。延迟方面多轮会累加。我的经验是首轮检索加生成控制在 2 秒内每多一轮增加 1 到 1.5 秒。如果业务对延迟敏感可以把“是否多轮”做成可配置简单问题走单轮快路径复杂问题才进 Agent 循环。注意一定要给 Agent 循环设硬性上限。我见过没设上限的系统遇到一个模糊问题疯狂检索最后超时还烧了一堆钱。5. 常见问题与排查技巧实录5.1 检索召回不准的排查顺序遇到“答非所问”按这个顺序查先看切块是否合理是不是切断了关键信息再看嵌入模型是否匹配语种和领域然后看是否需要查询改写最后看重排是否生效。我一般会打印出检索命中的原文片段人工判断“如果我是模型看到这些能答对吗”这一步能快速定位问题层级。5.2 多跳问题答不全怎么办多跳问题的核心是“信息分散在多个文档”。解决办法是查询拆解把复合问题拆成子问题逐个检索最后合并。比如“A 公司 CEO 的母校在哪”拆成“A 公司 CEO 是谁”和“这个人的母校”。Agent 循环天然适合做这件事第一轮查 CEO第二轮查母校。5.3 知识库更新后旧答案还在这是缓存和索引不同步的问题。检查三点向量库是否真的更新了、检索缓存是否失效、生成层是否有历史对话污染。我一般会给文档加版本号和时间戳检索时优先返回最新版本并在 Prompt 里明确告诉模型“以最新资料为准”。问题现象可能原因排查动作答非所问切块/嵌入/改写问题打印命中片段人工核对多跳答不全单次检索覆盖不足启用查询拆解与多轮旧答案残留缓存/索引未同步检查版本号与缓存失效延迟过高轮数过多/模型过大设预算上限分级处理幻觉严重上下文不足或噪声多加强重排明确拒答策略5.4 独家避坑心得第一不要迷信大模型能兜底。检索烂再强的模型也救不回来。第二评估集要早建。没有评估集你所有的优化都是盲调。我一般会人工标注 50 到 100 个问答对覆盖简单、多跳、对比、拒答四类。第三日志要全。每次检索的查询、命中、分数、最终答案都要落盘出问题时能复盘。第四拒答要设计。当检索结果确实不足时让模型明确说“资料中没有相关信息”比硬编一个答案强得多。这套东西我在几个项目里反复打磨过最大的体会是Agentic RAG 不是把简单问题复杂化而是把复杂问题拆成可控的步骤。普通 RAG 像一把锤子Agentic RAG 像一个工具箱关键不在于工具多而在于知道什么时候用哪把。后续如果你想继续深入可以往ontology rag方向走把本体和知识图谱接进来让检索从“相似度匹配”升级到“关系推理”那是另一个值得单独展开的话题。 
长河君 · 2026/10/8 5:00:23 · 阅读 1.2k Agentic RAG工程化实战：从Demo到生产环境的架构设计与避坑指南
1. 从“能跑通”到“敢上线”Agentic RAG 的工程化分水岭很多人第一次接触 RAG都是从一段几十行的脚本开始的加载文档、切块、向量化、检索、拼进 Prompt、调模型。跑通那一刻确实很爽但只要你把它往真实业务里推一步问题就会像潮水一样涌上来——检索召回忽高忽低、多跳问题答不全、知识库更新后旧答案还在、用户问“上个月那份合同里的违约金比例”时系统直接懵掉。这就是我常说的RAG 瓶颈Demo 阶段靠的是模型能力兜底生产阶段拼的是工程体系。production-agentic-rag-course这个标题核心就落在两个词上production和agentic。前者意味着它讨论的不是“怎么搭一个能问答的机器人”而是“怎么搭一个能扛住真实流量、真实数据、真实刁钻问题的系统”后者意味着它不再把 RAG 当成一条固定的“检索→生成”流水线而是把检索本身变成一个会思考、会决策、会多轮行动的过程。简单说普通 RAG 是“查一次就答”Agentic RAG 是“想清楚要查什么、查几次、查完够不够、不够再查”。这篇文章适合三类人看一是已经把基础 RAG 跑通、但卡在效果和稳定性上的开发者二是正在做企业知识库、智能客服、文档问答的产品和技术负责人三是想系统理解agentic、rag 框架、kg 知识库这些概念到底怎么落地的人。我会围绕这个课程标题背后的技术主线把整体设计思路、核心细节、实操过程、常见坑全部拆开讲尽量做到你看完能直接对照自己的项目改。先说一个我踩过的坑。早期我做过一个内部文档问答向量库用的是最朴素的固定长度切块检索 Top-5 直接塞给模型。上线第一周用户反馈最多的问题是“答非所问”。排查后发现问题根本不在模型而在检索一份 30 页的制度文档被切成 200 个字一块关键条款被切断了上下文检索出来的片段语义不完整模型只能靠猜。后来我引入重排和查询改写准确率肉眼可见地往上走。这件事让我彻底明白RAG 的效果上限往往由检索质量决定而不是模型参数决定。Agentic RAG 要解决的正是把这个“检索质量”从静态变成动态、从单次变成多轮。2. 整体架构设计为什么 Agentic 是 RAG 的必经之路2.1 普通 RAG 的三个结构性缺陷要理解 Agentic RAG 的价值得先看清普通 RAG 到底差在哪。我把它的缺陷归纳为三条每一条都对应一个真实场景。第一条是查询与文档的语义鸿沟。用户问“报销流程怎么走”文档里写的是“费用核销操作规范”字面不重合纯向量检索可能召回一堆不相关的财务制度。用户的口语化表达和文档的书面化表述之间天然存在一道沟。第二条是单次检索无法覆盖多跳推理。用户问“去年营收增长最快的部门它的负责人是谁”这需要先查营收数据、再定位部门、再查组织架构一次检索根本拿不全。普通 RAG 只能把问题原样丢给检索器检索器只能返回它“觉得像”的片段。第三条是缺乏自我校验。检索回来的内容到底相不相关、够不够回答问题普通 RAG 没有判断机制直接一股脑塞给模型。模型要么硬答要么幻觉要么说“根据提供的资料无法回答”——而其实资料库里明明有答案只是没被检索到。提示如果你现在的 RAG 系统经常出现“资料里有但答不出”的情况八成不是模型问题而是检索链路缺少决策和校验环节。2.2 Agentic RAG 的核心思想把检索变成“行动”Agentic RAG 的本质是把大模型从“被动接收检索结果的生成器”升级为“主动决定检索策略的智能体”。它具备几个关键能力查询理解与改写、工具调用检索只是其中一种工具、多轮迭代、结果评估与反思。打个比方。普通 RAG 像一个只会按关键词去图书馆找书的实习生你说“帮我找点关于合同的资料”他抱回来一堆书对不对全看运气。Agentic RAG 像一个有经验的研究助理他会先问你“你是要合同模板、合同法规还是合同纠纷案例”然后去对应区域找翻了几本发现不够再换个书架继续找最后还会告诉你“这几本比较相关但那本可能过时了”。这个“研究助理”的工作方式对应到技术实现上就是一套Plan → Act → Observe → Reflect的循环。Plan 阶段做查询改写和任务拆解Act 阶段调用检索工具、可能还有数据库查询、API 调用Observe 阶段拿到结果Reflect 阶段判断是否足够不够就回到 Plan 重新来。这个循环可以跑一到三轮直到信息足够或达到预算上限。2.3 方案选型为什么不是“堆更多向量”有人会问既然检索不准那我多召回一些、把 Top-20 全塞进去不就行了我实测过这条路走不通。一是上下文窗口有限塞太多会挤掉真正有用的信息还会让模型注意力分散二是噪声比例上升模型被无关内容干扰反而更容易答错三是成本和延迟飙升生产环境扛不住。所以正确的方向不是“堆量”而是“提纯”和“多轮”。提纯靠的是重排Rerank和查询改写多轮靠的是Agent 循环。这也是production-agentic-rag-course这类课程通常会覆盖的主线先解决单次检索的质量再解决多跳和复杂问题的覆盖最后解决工程上的稳定性、可观测性和成本控制。维度普通 RAGAgentic RAG检索次数单次多轮迭代查询处理原样检索改写、拆解、扩展结果校验无有评估与反思工具范围仅向量检索向量、关键词、图数据库、API适用问题简单事实问答多跳、对比、推理类问题工程复杂度低中高3. 核心细节解析知识库、检索与 Agent 循环3.1 RAG 知识库到底能存什么图片行不行这是热词里被问得最多的问题之一rag 知识库能存储图片嘛答案是能但要分清楚“存”和“用”是两回事。向量库本身存的是向量图片可以通过多模态嵌入模型转成向量存进去检索时用文本查询去匹配图片向量这叫跨模态检索。但更常见的工程做法是图片不直接进向量库而是把图片的文字描述、OCR 提取的文本、图片所在的上下文存进去图片本体存在对象存储里向量库里存一个指向图片的引用。检索命中后把图片 URL 一起返回给前端展示。为什么这么做因为纯图片向量的检索精度目前还不够稳尤其是文档里的图表、流程图直接做图像嵌入效果往往不如“OCR 描述”来得可靠。我在做产品手册问答时就吃过亏直接把产品图做嵌入用户问“这个接口长什么样”检索回来的图经常对不上。后来改成对每张图生成结构化描述接口类型、引脚数、颜色标识检索准确率立刻上来了。注意如果你的知识库里有大量图表建议走“图片描述 OCR 原图引用”的组合方案而不是指望图像嵌入一步到位。3.2 RAG 知识库和结构化知识库的区别与应用场景热词里还有一个高频问题rag 知识库和结构知识库区分以及应用场景。这两者不是替代关系而是互补关系理解清楚能帮你少走很多弯路。RAG 知识库非结构化/半结构化擅长处理的是文档、邮件、聊天记录、PDF、网页这类“自然语言为主”的内容。它的优势是灵活什么都能塞缺点是精确查询能力弱比如“统计上季度华东区销售额”这种聚合问题向量检索基本无能为力。结构化知识库关系库、图数据库、kg 知识库擅长处理的是实体、关系、属性明确的数据。比如“张三属于哪个部门”“A 产品的供应商是谁”这类问题用图查询或 SQL 秒出结果而且可解释、可追溯。缺点是构建成本高需要预先定义 schema 和本体ontology。实际生产里最稳的做法是混合架构用 RAG 处理开放式的文档问答用结构化库处理精确查询和关系推理Agent 负责判断当前问题该走哪条路。比如用户问“帮我找找关于供应商违约的合同条款”走 RAG用户问“我们一共有多少个供应商”走 SQL。Agent 的价值就在于它能做这个路由决策。对比项RAG 知识库结构化/KG 知识库数据类型文本、PDF、图片描述实体、关系、属性查询方式语义相似度检索精确查询、图遍历优势灵活、易扩展精确、可解释劣势精确聚合弱构建成本高典型场景文档问答、客服关系推理、统计报表3.3 切块策略被低估的效果杠杆切块Chunking是 RAG 里最不起眼、却最影响效果的环节。我见过太多项目模型换了三四个效果就是上不去最后发现是切块切废了。固定长度切块简单但会切断语义。按段落切块好一些但遇到长段落还是得再切。我目前比较推荐的组合是按语义边界切标题、段落、列表项 重叠窗口overlap 元数据附加。重叠窗口是为了防止关键信息正好落在切口上一般设 chunk 的 10% 到 20%。元数据来源文件、章节、页码、时间一定要带上后面做引用溯源和过滤全靠它。还有一个细节父子块Parent-Child策略。检索时用小块精确匹配返回时给大块完整上下文。这样既保证了检索精度又保证了生成时有足够上下文。这个策略在多跳问答里特别有用我实测下来比单纯调大 chunk size 效果好得多。3.4 查询改写与重排让检索“听懂人话”查询改写解决的是“用户说的”和“文档写的”不一致的问题。常见手法有三种同义扩展把口语词映射到书面词、多查询生成一个问题生成多个角度的查询分别检索后合并、HyDE先让模型生成一个假想答案再用这个答案去检索。重排解决的是“召回了一堆哪个最相关”的问题。向量检索是粗筛重排模型是精筛。流程是向量检索召回 Top-50重排模型打分排序取 Top-5 给生成模型。重排模型通常比嵌入模型更重、更准但只对少量候选打分成本可控。我一般用交叉编码器类的重排模型效果比纯向量排序稳定不少。提示查询改写和重排是“性价比最高”的两个优化点。如果你只能做两件事来提升 RAG 效果就做这两个。4. 实操过程从零搭一个可上线的 Agentic RAG4.1 环境准备与依赖选型先明确技术栈。向量库我推荐从轻量级开始本地开发用 FAISS 或 Chroma生产环境再考虑 Milvus、Qdrant 这类支持分布式和过滤的。嵌入模型选中文效果好的重排模型单独配一个。Agent 编排框架可以用 LangGraph 或自己写状态机前者省事后者可控。在 Mac 上搭建的话注意几个点Apple Silicon 对某些深度学习库的兼容性要确认版本Python 建议用 3.10 或 3.11虚拟环境一定要隔离。如果本地跑嵌入模型吃力可以先用 API 版本过渡等流程跑通再换本地模型。# 创建隔离环境 python3.11 -m venv rag_env source rag_env/bin/activate # 核心依赖 pip install langchain langgraph chromadb sentence-transformers pip install rank-bm25 jieba # 关键词检索用4.2 数据入库清洗、切块、元数据入库这一步决定了后面检索的天花板。我的流程是解析 → 清洗 → 切块 → 打标 → 向量化 → 入库。解析阶段PDF 用 PyMuPDF 或 pdfplumber注意处理表格和双栏排版。清洗阶段去掉页眉页脚、乱码、重复空行。切块按前面说的语义边界加重叠。打标阶段给每个块加上来源、章节、时间、文档类型。向量化时批量处理注意控制 batch size太大容易爆内存。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, # 约 16% 重叠 separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(raw_text) # 每个 chunk 附加元数据后再入库4.3 Agent 循环的实现骨架Agent 循环是整个系统的“大脑”。我用一个简化的状态机来说明核心是四个节点理解问题 → 决定行动 → 执行检索 → 评估结果。def agentic_rag(question, max_rounds3): context [] for round in range(max_rounds): # 1. 改写查询 queries rewrite_query(question, context) # 2. 多路检索 docs [] for q in queries: docs vector_search(q, top_k10) docs bm25_search(q, top_k10) # 3. 重排 docs rerank(question, docs, top_k5) # 4. 评估是否足够 if is_sufficient(question, context docs): break context docs # 5. 生成答案 return generate(question, context)这里的关键是is_sufficient这个评估函数。它可以用一个小模型来判断“当前上下文能否回答问题”也可以让主模型自己判断。我一般用主模型加一个结构化输出让它返回“足够/不足够 缺什么”缺什么就作为下一轮改写的输入。4.4 参数计算与预算控制Agentic RAG 最大的风险是成本失控。多轮检索、多次模型调用如果不设上限一个复杂问题可能烧掉几十次调用。我的做法是设三个预算最大轮数一般 3 轮、最大检索次数每轮不超过 4 次、最大 token 预算上下文总长不超过模型窗口的 70%。延迟方面多轮会累加。我的经验是首轮检索加生成控制在 2 秒内每多一轮增加 1 到 1.5 秒。如果业务对延迟敏感可以把“是否多轮”做成可配置简单问题走单轮快路径复杂问题才进 Agent 循环。注意一定要给 Agent 循环设硬性上限。我见过没设上限的系统遇到一个模糊问题疯狂检索最后超时还烧了一堆钱。5. 常见问题与排查技巧实录5.1 检索召回不准的排查顺序遇到“答非所问”按这个顺序查先看切块是否合理是不是切断了关键信息再看嵌入模型是否匹配语种和领域然后看是否需要查询改写最后看重排是否生效。我一般会打印出检索命中的原文片段人工判断“如果我是模型看到这些能答对吗”这一步能快速定位问题层级。5.2 多跳问题答不全怎么办多跳问题的核心是“信息分散在多个文档”。解决办法是查询拆解把复合问题拆成子问题逐个检索最后合并。比如“A 公司 CEO 的母校在哪”拆成“A 公司 CEO 是谁”和“这个人的母校”。Agent 循环天然适合做这件事第一轮查 CEO第二轮查母校。5.3 知识库更新后旧答案还在这是缓存和索引不同步的问题。检查三点向量库是否真的更新了、检索缓存是否失效、生成层是否有历史对话污染。我一般会给文档加版本号和时间戳检索时优先返回最新版本并在 Prompt 里明确告诉模型“以最新资料为准”。问题现象可能原因排查动作答非所问切块/嵌入/改写问题打印命中片段人工核对多跳答不全单次检索覆盖不足启用查询拆解与多轮旧答案残留缓存/索引未同步检查版本号与缓存失效延迟过高轮数过多/模型过大设预算上限分级处理幻觉严重上下文不足或噪声多加强重排明确拒答策略5.4 独家避坑心得第一不要迷信大模型能兜底。检索烂再强的模型也救不回来。第二评估集要早建。没有评估集你所有的优化都是盲调。我一般会人工标注 50 到 100 个问答对覆盖简单、多跳、对比、拒答四类。第三日志要全。每次检索的查询、命中、分数、最终答案都要落盘出问题时能复盘。第四拒答要设计。当检索结果确实不足时让模型明确说“资料中没有相关信息”比硬编一个答案强得多。这套东西我在几个项目里反复打磨过最大的体会是Agentic RAG 不是把简单问题复杂化而是把复杂问题拆成可控的步骤。普通 RAG 像一把锤子Agentic RAG 像一个工具箱关键不在于工具多而在于知道什么时候用哪把。后续如果你想继续深入可以往ontology rag方向走把本体和知识图谱接进来让检索从“相似度匹配”升级到“关系推理”那是另一个值得单独展开的话题。