Agentic RAG 深度解析:让 Agent 自己决定要不要检索、检索几次,这才是 RAG 的正确打开方式
你有没有遇到过这种情况搭了一套标准 RAG上线后发现检索结果驴唇不对马嘴——用户问「2024 和 2025 的年度报告对比一下」系统只检索到了 2024 的内容然后大模型用这半桶水给了你一个「信心满满但完全错误」的答案。你反复调 top-K、调 chunk size就是不稳。根本原因不是参数没调对而是传统 RAG 的架构本身就没有自我纠错的能力——它就是个固定管道检一次生成完事。Agentic RAG 的核心思路是把检索这件事交给 Agent 来决策。要不要检索检哪个数据源检完发现不够怎么办这些都由 Agent 在运行时自主判断而不是你在代码里硬编码。这篇从原理到实战把四种 Agentic RAG 模式拆透。01 为什么说传统 RAG 是「一次性赌注」传统 RAG 的执行路径是固定的用户提问 → Embedding → 向量检索(top-K) → 塞进 Prompt → 生成答案。这个流程在生产环境中有三个死穴死穴一单次检索没有回头路。第一次检索结果质量差没有任何机制能发现这一点并重试。系统会继续往下走用一堆不相关的 chunk 生成一个「看起来很正经」的错误答案。死穴二单一数据源知识孤岛。用户的问题往往跨越多个数据域——文档库、数据库、实时 API。传统 RAG 只能连一个向量库碰到跨域问题直接哑火。死穴三无法分解复杂问题。「对比 Q3 和 Q4 的用户留存率结合客服反馈分析原因」——这个问题需要至少三次独立检索再汇总。传统管道里你只能硬塞进一个 query然后祈祷。根据多个生产系统的统计15%-30% 的 RAG 失败都源于检索质量问题——而这些失败在传统架构里根本无从发现更无法修复。Agentic RAG 的解法很直接在检索和生成之间加一层「会思考的 Agent」。能力维度传统 RAGAgentic RAG检索策略固定单次向量搜索动态Agent 选数据源、改查询检索轮次永远是 1 次按需决定1 到 N 次质量评估无Agent 给检索结果打分错误恢复无检测到失败后换策略重试工具调用无可调用 API、SQL、网页搜索查询分解无把复杂问题拆成子问题02 四种模式Agentic RAG 的设计图谱Agentic RAG 不是一种固定架构而是四种可组合的模式。理解这四种模式是选型的基础。模式一路由型 RAGRouting RAG适用场景知识分散在多个后端——向量库、SQL 数据库、知识图谱、实时 API。核心逻辑是 Agent 先理解问题意图再决定去哪里取数据。用户问「Q3 营收」走 SQL问「产品规格」走向量库问「最新股价」走实时 API。模式二多步型 RAGMulti-step RAG适用场景单个 Query 需要多轮独立检索才能回答。Agent 把复杂问题拆解成子问题依次检索最后汇总。「新定价方案上线后流失率怎么变化客服反馈如何」拆成三个独立子查询分别检索最后合并推理。模式三纠错型 RAGCorrective RAG / CRAG适用场景需要对检索结果进行可信度评估。检索 → 评分相关吗→ 相关就生成不相关就改写 Query 重试完全没有就降级到网页搜索。这是实际项目里最实用的模式。模式四自适应型 RAGAdaptive RAG适用场景需要在「要不要检索」这一步就做判断。Agent 先判断这个问题是常识、上下文已覆盖还是真的需要检索不需要就直接生成避免无意义的检索开销。03 CRAG 实战给检索加一个「评分官」CRAGCorrective RAG是工程价值最高的模式用 LangGraph TypeScript 完整实现它。先定义 State 和图结构importAnnotationStateGraphENDfromlangchain/langgraphimportChatOpenAIfromlangchain/openaiimportfromzod// 定义 Graph 状态constAgenticRAGStateAnnotationRootquestionAnnotationstringdocumentsAnnotationstringreducer(prev, next) default() generationAnnotationstringretrieval_gradeAnnotationrelevantirrelevantnoneretry_countAnnotationnumberreducer(prev, next) default() 0typeRAGStatetypeofAgenticRAGStateStateconstnewChatOpenAImodelgpt-4o-minitemperature0检索节点 评分节点——从向量库取文档再让 LLM 判断相关性// 检索节点asyncfunctionretrieveNodestate: RAGStateconstawaitsimilaritySearchquestion5returndocumentsmap(d) pageContent// 评分节点constGradeSchemaobjectscoreenumrelevantirrelevantnonereasonstringasyncfunctiongradeDocumentsNodestate: RAGStateconstwithStructuredOutputGradeSchemaconst你是一个检索结果评分器。用户问题${state.question}检索到的文档${state.documents.join(\n\n---\n\n)}评估这些文档是否能回答用户问题- relevant高度相关可以据此生成可靠答案- irrelevant关联性很弱但还有一些信息- none完全无关或为空给出评分和原因。constawaitinvokereturnretrieval_gradescoreQuery 改写节点 生成节点// Query 改写节点——检索质量差时优化问题表述asyncfunctionrewriteQueryNodestate: RAGStateconst原始问题${state.question}向量检索结果质量不佳。请重写问题包含更多关键词、拆解更具体、去除歧义。只输出改写后的问题不要任何解释。constawaitinvokereturnquestioncontentasstringdocuments// 清空旧结果准备重新检索retry_countretry_count1// 生成节点asyncfunctiongenerateNodestate: RAGStateconstdocumentsjoin\n\nconst基于以下文档回答问题。文档${context}问题${state.question}给出准确、有据可查的回答。如果文档不足以完整回答请明确说明。constawaitinvokereturngenerationcontentasstring条件路由 组装 Graph// 条件路由——核心决策逻辑constMAX_RETRY2functionrouteAfterGradingstate: RAGStatestringifretrieval_graderelevantreturngenerateifretry_countMAX_RETRYconsolelog⚠️ 超过重试上限降级生成returngenerateifretrieval_gradenonereturnrewrite_queryreturngenerate// irrelevant 但有一些信息接受并生成// 组装 GraphconstnewStateGraphAgenticRAGStateaddNoderetrieveaddNodegrade_documentsaddNoderewrite_queryaddNodegenerateaddEdge__start__retrieveaddEdgeretrievegrade_documentsaddConditionalEdgesgrade_documentsgenerategeneraterewrite_queryrewrite_queryaddEdgerewrite_queryretrieve// 改写后重新检索addEdgegenerateENDconstcompile// 运行constawaitinvokequestionLangGraph 的 Checkpoint 是什么consolelog最终答案generation04 路由型 RAG让 Agent 决定去哪个「图书馆」找书路由型 RAG 的关键在于把每个数据源封装成 Tool让 LLM 自主选择。importfromlangchain/core/toolsimportfromzod// 工具1向量库搜索文档、FAQconsttoolasyncquerystringconstawaitsimilaritySearch5returnmap(d) pageContentjoin\n\nnamesearch_docsdescription搜索产品文档、技术规格、使用指南。适用于功能介绍、操作步骤类问题。schemaobjectquerystring// 工具2SQL 数据库结构化数据consttoolasyncsqlstringconstawaitqueryreturnJSONstringifyrowsnamequery_databasedescription查询业务数据库。适用于营收、用户量、留存率等量化指标问题。只支持 SELECT 语句。schemaobjectsqlstringdescribe只读 SQL 查询语句// 工具3网页搜索实时信息consttoolasyncquerystringconstawaittavilySearchreturnmap(r: any) contentjoin\n\nnameweb_searchdescription搜索互联网获取最新信息。适用于当前事件、最新版本、外部市场数据。schemaobjectquerystring// 绑定工具让 Agent 自主路由constbindTools工具描述是路由准确性的关键——越清晰LLM 选错的概率越低。每个工具描述都要写清楚适用于什么问题而不只是「功能是什么」。反例就在上面如果你把三个工具描述都写成「搜索相关信息」LLM 会倾向于总选第一个路由完全失效。05 自适应 RAG连「要不要检索」都让 Agent 决定自适应 RAG 在所有模式里成本最优因为它在最上游就做了一次过滤这个问题需要检索吗constRouteSchemaobjectdatasourceenumvectorstoreweb_searchdirect_answerreasonstringasyncfunctionrouteQuestionstate: RAGStateconstwithStructuredOutputRouteSchemaconst你是一个问题路由器决定如何最高效地回答用户问题。问题${state.question}选择路由策略- direct_answer通用知识或对话上下文已覆盖不需要检索- vectorstore关于特定文档、产品内部知识- web_search需要实时信息或外部知识选择最合适的一个给出原因。returnawaitinvoke// Graph 中根据路由结果分叉functionrouteNodestate: RAGState { routing_decision?: string }stringconstrouting_decisionifdirect_answerreturngenerateifweb_searchreturnweb_searchreturnretrieve这个模式特别适合通用助手场景——用户既会问「你好帮我写段代码」不需要检索也会问「我们的 API 文档里 rate limit 是多少」需要检索内部文档。统一入口自适应路由。06 常见坑Agentic RAG 踩过才知道坑1忘记设置最大重试次数Graph 无限循环纠错型 RAG 最容易踩这个坑。如果向量库里压根没有这个知识CRAG 会一直循环到 token 耗尽。// 正确做法硬性保护State 里记录重试计数ifretry_countMAX_RETRYreturnfallback_generate// 降级绝不继续循环坑2评分 Prompt 太模糊LLM 永远返回 “relevant”如果评分 Prompt 只说「判断文档是否相关」LLM 倾向于给「相关」——它在训练时被优化为「有帮助」的助手不喜欢说「这个我不知道」。解法在 Prompt 里给出具体的 “irrelevant” 判断条件比如「如果文档只是包含相同关键词但讨论完全不同话题算 irrelevant」。坑3多步 RAG 子问题有依赖却并行执行把复杂问题拆成子问题后如果直接并行检索但子问题 B 的答案依赖子问题 A 的结果最终合并时会出现逻辑断层。解法在分解步骤里判断依赖关系有依赖的串行独立的才并行。坑4工具描述写得太像LLM 每次都选同一个路由型 RAG 里如果三个工具描述都是「搜索相关信息」LLM 会分布极不均匀。解法每个工具描述要突出差异化适用场景用反例说明「什么情况下不要用这个工具」。坑5评分节点用大模型贵还不稳定用 LLM 评估 LLM 检索结果本身有幻觉风险。评分用小模型gpt-4o-mini配 Zod schema 强制结构化输出不要用大模型做简单分类任务——成本高且评分反而更不稳定。总结这篇我们把 Agentic RAG 从头到尾拆完了传统 RAG 的三个死穴单次检索无回头、单一数据源孤岛、无法分解复杂问题——不是调参能解决的是架构层的缺陷。四种模式各有适场路由型解决多数据源、多步型解决复杂分解、CRAG 解决检索质量、自适应型解决无意义检索开销——实际项目经常组合使用。CRAG 是工程价值最高的起点加一个评分节点 Query 改写节点 重试上限三步改造让 RAG 具备自我纠错能力。最大重试次数是生命线任何带循环的 Agentic RAG都要在 State 里记录重试计数超限强制降级永远不要让 Graph 无限重试。工具描述决定路由准确率路由型 RAG 里工具的 description 比代码逻辑更关键——写清楚适用场景和反例。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】