1. 从“能跑通”到“敢上线”Agentic RAG 到底在解决什么问题做过 RAG 的人大概都有过这种体验Demo 阶段效果惊艳一旦放到真实业务里用户问三个问题就开始露馅——要么检索回来的东西答非所问要么模型一本正经地胡说八道要么多轮对话之后它连刚才聊过什么都忘了。这套production-agentic-rag-course想干的事情说白了就是把“实验室里能跑通的 RAG”变成“生产环境里敢上线的 RAG”而中间差的这一大截恰恰就是 Agentic 这个词要填的坑。先把概念掰开。RAGRetrieval-Augmented Generation检索增强生成的核心逻辑是模型本身的知识是静态的、有截止日期的遇到私有数据或实时信息就抓瞎所以我们在生成之前先去外部知识库里捞一把相关资料把资料塞进上下文让模型“看着材料答题”。这个思路本身没问题问题出在“捞”这个动作上——传统 RAG 的检索是一次性、无反馈、无规划的用户问什么系统就拿这句话去向量库里做一次相似度搜索捞回 Top-K 个片段然后祈祷这些片段里正好有答案。Agentic RAG 的转变在于它把“检索”从一个固定步骤升级成了一个由智能体Agent驱动的决策过程。Agent 会先判断这个问题需不需要检索、需要检索什么、检索几次、检索结果够不够、不够的话要不要换个关键词再捞、要不要调用别的工具比如查数据库、调 API、做计算最后再决定怎么组织答案。这就像你问一个靠谱的助理问题他不会拿着你的原话去档案室随便抽几份文件就回来交差而是会先想清楚“我到底要找什么”找不到就换个思路再找找到之后还会核对一下信息是否自洽。这套课程标题里带production和course两个词信息量很大。production意味着它关注的不是玩具级实现而是可观测性、可评估性、成本控制、错误处理、并发与延迟这些工程问题course意味着它是有体系、有递进、能跟着一步步复现的教学内容而不是零散的经验贴。所以它适合的人群很明确已经了解 RAG 基本概念、动手搭过简单 Demo、但一提到“上线”就心里没底的开发者以及正在做企业级知识库、智能客服、文档问答这类项目被检索质量和幻觉问题反复折磨的工程师。我个人的判断是2024 年之后 RAG 的竞争焦点已经从“能不能检索”彻底转向了“检索得准不准、答得稳不稳、跑得贵不贵”。Agentic RAG 不是又一个新名词炒作而是对传统 RAG 那几个致命瓶颈的正面回应。接下来我会把这套课程涉及的核心思路、关键实现、踩坑经验完整拆一遍尽量让你看完就能对照着自己的项目改。2. 传统 RAG 的四个瓶颈与 Agentic 的破局思路2.1 瓶颈一单次检索的“一锤子买卖”传统 RAG 最要命的地方在于它假设“用户的问题”和“知识库里的文档”之间存在一次向量相似度就能命中的映射关系。但现实是用户的提问方式和文档的表述方式往往差着十万八千里。用户问“我上个月买的东西怎么还没到”文档里写的是“订单物流状态查询流程”这两句话在向量空间里的距离可能远得离谱因为一个是口语化的抱怨一个是规范化的流程标题。更麻烦的是多跳问题multi-hop。比如“我们公司去年营收最高的那个产品线它的负责人是谁”这个问题需要先查营收数据找到产品线再查组织架构找到负责人两次检索之间有依赖关系。传统 RAG 一次性把原问题丢进向量库捞回来的大概率是营收数据或者组织架构其中之一很难同时命中模型就只能靠猜。Agentic 的破局方式是引入查询规划Query Planning。Agent 拿到问题后先做一次分解这个问题需要几个信息点每个信息点该用什么关键词去检索检索顺序是什么然后按计划逐步执行每一步的检索结果都会影响下一步的决策。这背后通常用到一个ReActReasoning Acting或者Plan-and-Execute的框架让模型在“思考”和“行动”之间交替进行。2.2 瓶颈二检索结果的相关性无法自证传统 RAG 捞回 Top-K 个片段后直接一股脑塞给模型从不检查这些片段到底相不相关。结果就是模型经常被无关片段干扰或者明明检索结果里没有答案它也要硬编一个出来——这就是幻觉的重要来源之一。Agentic RAG 会加一道相关性评估Relevance Grading的关卡。每个检索回来的片段先让模型打个分这个片段和问题相关吗能部分回答问题还是完全无关如果相关片段数量不够Agent 会触发查询重写Query Rewriting换一种表述重新检索如果所有片段都不相关它会诚实地告诉用户“知识库里没有相关信息”而不是硬答。这个“知道自己不知道”的能力在生产环境里比“什么都敢答”重要得多。2.3 瓶颈三知识库结构单一撑不起复杂查询热词里提到的“rag知识库和结构知识库区分以及应用场景”“kg知识库”“ontology rag”其实指向同一个痛点纯向量检索擅长语义相似但不擅长精确匹配、关系推理和结构化查询。你问“2023 年 Q3 华东区销售额超过 500 万的客户有哪些”这种带明确条件和聚合逻辑的问题向量库基本无能为力因为它是按语义相似度排序的不是按数值条件过滤的。生产级的 Agentic RAG 通常是混合检索架构向量库负责语义召回关键词索引如 BM25负责精确匹配图数据库或关系库负责结构化查询Agent 根据问题类型决定走哪条路或者把几条路的结果融合。这就是所谓的Hybrid RAG和Graph RAG的由来。课程里如果涉及 KG知识图谱知识库大概率是在讲如何把实体和关系抽出来构建图谱让 Agent 能够沿着关系边做多跳推理。2.4 瓶颈四没有评估就没有优化这是最容易被忽视、但在生产环境里最致命的一点。很多团队做完 RAG 之后靠“感觉”判断效果好不好今天觉得答得不错明天用户投诉答错了根本不知道问题出在检索环节还是生成环节。Agentic RAG 的工程化必须配套一套评估体系检索命中率、答案忠实度faithfulness、答案相关性、上下文召回率等指标用一批标注好的问答对做回归测试每次改动都跑一遍用数据说话。下面这张表把传统 RAG 和 Agentic RAG 的核心差异做个对照方便你快速判断自己的项目该往哪个方向演进维度传统 RAGAgentic RAG检索次数单次多次、自适应查询处理原样检索规划、重写、分解结果校验无相关性评分、自反思工具调用仅检索检索计算API图谱知识库类型纯向量向量关键词图谱结构化失败处理硬答或报错承认未知、降级回复评估方式人工感觉指标化、回归测试成本低较高需优化3. 核心架构拆解一个生产级 Agentic RAG 该长什么样3.1 整体链路从入口到出口的六个环节一个能上生产的 Agentic RAG我习惯把它拆成六个环节来看每个环节都有独立的职责和可替换的实现第一环是入口路由Router。用户的问题进来先判断它属于哪一类是闲聊、是简单事实查询、是需要多跳推理的复杂问题、还是需要调用外部工具的请求。路由可以用一个轻量分类模型也可以用规则小模型组合。这一步的价值在于避免所有问题都走最重的链路简单问题直接走快速通道省时省钱。第二环是查询理解与改写Query Understanding。把用户的口语化提问转成适合检索的形式包括指代消解把“它”“那个”还原成具体实体、关键词提取、同义词扩展、查询分解。多轮对话场景下这一步还要结合历史对话把省略的信息补全。第三环是检索执行Retrieval。根据查询类型选择检索策略向量检索、关键词检索、混合检索、图谱查询。这里的关键是并行化——多个检索源可以同时发起用异步的方式拿结果而不是串行等待。第四环是结果评估与过滤Grading Filtering。对检索回来的每个片段做相关性打分过滤掉低分片段判断信息是否充足。不足则回到第二环重写查询形成循环。这个循环必须有最大迭代次数限制否则可能死循环烧钱。第五环是生成Generation。把筛选后的上下文和问题一起交给生成模型要求它严格基于上下文作答并给出引用来源。生产环境里通常还要做流式输出让用户尽快看到第一个字而不是等整段生成完。第六环是后处理与观测Post-processing Observability。包括答案的格式校验、敏感信息过滤、引用链接生成以及全链路的日志记录和指标上报。这一环是生产系统和 Demo 的分水岭。3.2 状态管理Agent 的“记忆”怎么设计Agentic RAG 比传统 RAG 复杂的地方在于它是有状态的。一次请求可能经历多轮检索、多次工具调用这些中间状态需要被妥善管理。常见的设计是用一个状态对象State贯穿整个流程里面包含原始问题、改写后的查询列表、每轮检索的结果、相关性评分、已调用工具记录、当前迭代次数、最终答案等。这个状态对象在 LangGraph 这类框架里就是节点之间传递的state在自研系统里通常是一个字典或数据类。设计状态时有两个坑要避开一是状态膨胀把所有中间结果都塞进去导致上下文越来越长、成本越来越高二是状态丢失多轮对话时没有把关键信息持久化用户换个话题再回来就断片了。我的经验是状态里只保留“对后续决策有影响”的信息原始检索片段在评估完之后就可以丢弃只留评分和摘要。3.3 工具层设计Agent 的手脚怎么接Agentic 的“agentic”体现在它能调用工具。除了检索生产环境里常见的工具包括计算器处理数值问题、数据库查询处理结构化数据、外部 API查天气、查汇率、查订单、代码执行处理复杂逻辑。工具设计有几个原则工具描述要精准模型是根据工具的 name 和 description 来决定调不调的描述写得含糊模型就会乱调或该调不调。参数校验要严格模型生成的参数可能格式错误工具入口必须做校验和容错不能直接把模型的输出透传给下游。失败要有明确返回工具调用失败时返回结构化的错误信息让 Agent 知道是重试、换工具还是放弃而不是抛一个异常把整个流程打断。权限要隔离不是所有工具都对所有用户开放工具层要做权限判断避免越权操作。3.4 成本与延迟生产环境绕不开的两座山Agentic RAG 因为要多次调用模型做规划、评估、重写成本和延迟天然比传统 RAG 高。我实测过一个中等复杂度的多跳问题传统 RAG 一次检索加一次生成大概 2 秒、几分钱Agentic 流程走下来可能要 5 到 8 次模型调用延迟到 8 到 15 秒成本翻好几倍。所以生产落地必须做优化模型分级规划、评估这类“判断型”任务用便宜的小模型最终生成用强模型。缓存相同或相似的查询结果缓存起来尤其是高频问题。并行独立的检索和工具调用并行发起。提前终止评估环节一旦判断信息充足立即停止检索不要为了“凑满 K 个”而多跑一轮。流式生成阶段流式输出改善用户感知延迟。4. 实操落地从零搭一个可评估的 Agentic RAG4.1 环境准备与依赖选型假设你在 Mac 上从零开始热词里“怎么在mac上搭建rag知识库”问的人不少我建议的起步配置是这样Python 3.10用venv或conda建独立环境别污染系统 Python。向量库本地开发用 Chroma 或 FAISS轻量、零配置要上生产再考虑 Milvus、Qdrant、Weaviate 这类支持分布式和持久化的。Embedding 模型本地跑用bge-m3或bge-large-zh中文效果好且免费追求效果可以用商用 API。编排框架LangGraph 适合有状态的多步 Agent 流程LlamaIndex 在检索和索引这块封装更全两者可以混用。生成模型本地可以用 Ollama 跑量化模型做开发调试生产接商用 API。评估RAGAS 是目前比较成熟的 RAG 评估库能算忠实度、答案相关性、上下文召回等指标。安装核心依赖大致是这样python -m venv rag-env source rag-env/bin/activate pip install langgraph langchain chromadb sentence-transformers ragas pip install fastapi uvicorn # 如果要暴露成服务注意不要一上来就装一大堆框架先把最小链路跑通再按需引入。我见过太多项目因为依赖冲突卡在环境配置上还没开始写业务逻辑就放弃了。4.2 文档入库切分策略决定检索上限文档切分Chunking是 RAG 里最被低估的环节。切得太碎语义不完整检索回来的是半句话切得太大噪声多模型抓不住重点。我的经验是按语义边界切优先按段落、标题、列表项切不要机械地按固定字符数切。块大小 300 到 800 字是中文场景比较稳的区间具体看文档密度。设置重叠overlap一般 10% 到 20%避免关键信息正好被切断。保留元数据来源文件、章节标题、页码这些在生成引用时要用到。表格和图片单独处理热词里问“rag知识库能存储图片嘛”答案是能但通常不是把图片本身存进向量库而是把图片的文字描述或 OCR 结果向量化图片原文件存对象存储检索命中后把图片作为附件返回。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap100, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(document)4.3 混合检索向量加关键词的双保险纯向量检索对精确匹配不友好比如产品型号、人名、专有名词向量可能召回一堆语义相近但实体不对的片段。加上 BM25 关键词检索做融合能显著提升召回质量。融合方式常用RRFReciprocal Rank Fusion倒数排名融合它不需要两路分数可比只看排名简单稳健。def rrf_fusion(vector_results, bm25_results, k60): scores {} for rank, doc in enumerate(vector_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) for rank, doc in enumerate(bm25_results): scores[doc.id] scores.get(doc.id, 0) 1 / (k rank 1) return sorted(scores.items(), keylambda x: x[1], reverseTrue)提示RRF 的k值一般取 60这是原论文的推荐值实测下来对大多数场景都够用不用过度调参。4.4 相关性评估节点让 Agent 学会“挑食”这是 Agentic RAG 区别于传统 RAG 的关键节点。每轮检索后用一个评估提示词让模型给每个片段打分GRADE_PROMPT 你是一个检索结果评估器。判断以下文档片段与用户问题的相关性。 用户问题{question} 文档片段{document} 请只输出一个词 - relevant片段包含回答问题的关键信息 - partially片段部分相关可作为补充 - irrelevant片段与问题无关 评分评估完之后如果 relevant 的片段数量为 0就触发查询重写如果数量足够就进入生成。这里有个实操技巧评估用的小模型和生成用的大模型分开评估任务简单小模型足够能省不少钱。4.5 查询重写换个姿势再捞一次查询重写不是简单地把问题换个说法而是要有策略。常见的手法包括同义扩展把“怎么退款”扩展成“退款流程 退货 售后”。实体替换把代词还原成具体实体。分解把复合问题拆成多个子问题分别检索。HyDE先让模型“幻想”一个答案再用这个假答案去检索因为答案和文档的表述风格更接近命中率往往更高。REWRITE_PROMPT 用户问题检索不到相关内容请重写查询以提高检索命中率。 原问题{question} 已尝试的查询{tried_queries} 请生成 2 个不同角度的新查询每行一个不要编号注意重写次数一定要设上限我一般设 2 次。超过 2 次还找不到说明知识库里大概率真没有这时候诚实回复比继续烧钱更明智。4.6 生成与引用让答案可追溯生成阶段的提示词要把约束写死只基于给定上下文回答上下文没有就说不知道每个关键结论标注来源编号。这样用户能点开引用核对也方便你排查是检索错了还是生成错了。GENERATE_PROMPT 基于以下上下文回答用户问题。 上下文 {context} 用户问题{question} 要求 1. 只使用上下文中的信息不要编造 2. 如果上下文不足以回答直接说根据现有资料无法回答 3. 每个关键结论后用 [编号] 标注来源 回答4.7 评估闭环用数据驱动迭代搭好链路只是开始真正让它变好的是评估。准备一批覆盖典型场景的问答对至少 50 条每次改动后跑一遍 RAGAS看四个核心指标指标含义低了说明什么Faithfulness答案是否忠于上下文生成模型在幻觉Answer Relevancy答案是否切题检索或提示词有问题Context Recall上下文是否覆盖答案检索召回不足Context Precision上下文是否精准检索噪声太多我的经验是Context Recall 低就优化切分和检索策略Context Precision 低就加评估过滤Faithfulness 低就收紧生成提示词。每个指标对应不同的优化方向别瞎调。5. 常见问题与排查技巧实录5.1 检索明明命中了模型却说不知道这是最常见的问题之一。原因通常是检索回来的片段被评估节点误判为 irrelevant 过滤掉了或者片段虽然相关但被放在了上下文的末尾模型注意力没覆盖到。排查方法是把每轮检索的原始片段、评分、最终进入生成的上下文全部打日志对比一下就知道是哪一环丢的。如果是评估误判把评估提示词写得更宽松一点或者把 partially 的片段也保留如果是位置问题把最相关的片段放在上下文开头和结尾模型对首尾的注意力更强。5.2 多轮对话之后 Agent 开始“失忆”多轮场景下用户第二句问“那它的价格呢”这个“它”指代的是上一轮提到的产品。如果查询重写环节没有结合历史对话做指代消解检索就会用“它的价格”去搜结果可想而知。解决办法是在查询理解阶段把最近几轮对话一起喂给模型让它输出一个自包含的完整查询。但要注意历史对话不能无限长一般保留最近 3 到 5 轮就够太长了反而干扰。5.3 成本失控一次提问烧掉几毛钱Agentic RAG 的成本主要来自模型调用次数。我见过一个没优化的流程一个问题触发了 12 次模型调用其中 8 次是评估。优化手段前面提过这里补充一个实操细节评估节点可以批量处理把 10 个片段一次性喂给模型让它输出 10 个评分而不是调 10 次模型。这样调用次数直接降到十分之一效果几乎没差别。5.4 延迟太高用户等不及延迟优化除了并行和流式还有一个容易被忽视的点首字延迟TTFT。用户感知的“快”不是总耗时短而是第一个字出来得快。所以生成阶段一定要流式哪怕后面生成得慢用户看到字在往外蹦心理上就能接受。另外检索阶段可以设置超时某个检索源超过 2 秒没返回就直接放弃用已有的结果继续不要让一个慢查询拖垮整个请求。5.5 知识库更新后效果变差文档更新后旧的向量还在库里新的向量加进去可能导致同一主题出现多个版本的片段检索时互相干扰。解决办法是给每个片段打上版本号和时间戳检索时优先返回最新版本或者定期做全量重建索引。增量更新虽然省事但长期不清理会积累大量过期数据我一般建议每周做一次增量、每月做一次全量。5.6 问题速查表现象可能原因排查方向答非所问检索召回错误看检索片段和问题是否相关幻觉严重上下文不足或提示词太松检查 Context Recall收紧提示词说不知道但实际有评估误判或召回不足看评估日志放宽评分标准多轮断片指代未消解检查查询重写是否用了历史成本高模型调用次数多统计各节点调用次数批量评估延迟高串行调用、无流式并行化、开流式、设超时更新后变差旧数据干扰检查版本管理重建索引提示排查问题的第一原则永远是先看日志再改代码。我踩过最大的坑就是凭感觉调提示词调了半天发现是检索环节根本没召回白忙活。6. 知识库选型向量、图谱、结构化到底怎么选热词里反复出现“rag知识库和结构知识库区分以及应用场景”“kg知识库”“ontology rag”说明很多人卡在选型上。我的建议是不要非此即彼而是按问题类型分层语义模糊、表述多样的问题如“怎么申请报销”走向量库靠语义相似度召回。精确匹配、专有名词多的问题如“型号 X200 的参数”走关键词索引BM25 或倒排索引。关系推理、多跳问题如“A 的上级的部门负责哪些项目”走知识图谱沿关系边遍历。聚合统计、条件过滤如“上季度销售额前 10 的客户”走结构化数据库SQL 查询。生产系统通常是这四者的组合Agent 根据问题类型路由到对应的检索源。知识图谱的构建成本最高需要做实体抽取、关系抽取、本体设计ontology但它在处理复杂关系查询时的效果是向量库完全达不到的。如果你的业务里这类问题占比高值得投入如果只是偶尔出现用向量库加提示词硬扛也能凑合。至于“rag知识库能存储图片嘛”前面提过标准做法是图片走对象存储向量库存图片的文字描述或 OCR 结果检索命中后把图片 URL 一起返回给前端展示。多模态 RAG 是另一个话题需要多模态 embedding 模型成本和复杂度都更高建议先把文本链路做扎实再考虑。7. 我踩过的坑和几条实在建议第一个坑是过早优化。我一开始就想着上最复杂的 Agent 架构规划、评估、重写、图谱全上结果链路太长调试困难效果还不如一个调好切分的朴素 RAG。后来退回去先把基础检索做扎实再逐个环节加 Agent 能力每加一个就用评估数据验证是否真的有提升。没有评估数据的优化都是耍流氓。第二个坑是忽视数据质量。RAG 的效果上限由知识库质量决定垃圾进垃圾出。我见过团队花大力气调模型结果知识库里全是过期的、格式混乱的文档怎么调都没用。花在数据清洗、切分、标注上的时间回报率远高于调提示词。第三个坑是不做降级。生产环境什么都会发生向量库挂了、模型 API 超时、检索返回空。如果没有降级策略用户看到的就是一个报错页面。我的做法是每一环都有兜底检索失败就返回“暂时无法查询”模型超时就返回检索到的原文片段让用户自己看总比什么都不给强。最后分享一个实用技巧把每次线上请求的完整链路存下来定期抽样人工评估。自动化指标能发现大问题但细微的体验问题还得靠人看。我每周会抽 20 条真实请求从头到尾看一遍检索和生成往往能发现指标看不出来的问题比如引用编号错位、语气生硬、答非所问但指标正常。这些细节才是生产级和 Demo 级真正的差距所在。