阿里一面：你的 RAG 召回一堆垃圾，就这么硬塞给大模型？它不会自己再查一遍

之前我们把传统 RAG 的零件几乎拆了个遍:怎么解析、怎么分块、怎么做混合检索、怎么加 reranker、怎么评估。但这些都还在一个大前提下打转，RAG 是一条直线:用户问一句,系统查一次,把查到的塞给模型,模型答一句。

今天这篇,要把这个大前提本身掀掉。

先看一个阿里大模型应用岗的一面场景。候选人简历上写了"独立搭建金融文档 RAG 问答系统",面试官没绕弯,上来就让他把召回流程从头讲一遍。

他答得挺顺:“用户 query 先做 embedding,去向量库取 top_k,再过一遍 reranker 重排,取前五条拼进 prompt,最后让大模型基于这五条生成答案。”

面试官点点头,问了第一个追问:“如果用户问的这个问题,第一次检索回来的五条全是噪声、跟问题不沾边,你这套系统会发生什么?”

他想了想:“那模型就只能基于这五条噪声硬答,大概率会答错,或者编一个。”

“对。那你怎么解决?”

“我可以把 top_k 调大,或者把 reranker 换成更强的 cross-encoder,提升排序质量。”

面试官换了个问法:“你还是在那条直线上修修补补。我换个问法——你这套系统召回完那五条,自己知道这五条是不是垃圾吗?如果是垃圾,它能自己再查一遍、换个关键词、或者换个数据源吗?”

他卡住了。第一反应想说"可以加个判断逻辑",但马上意识到,整个系统从架构上就没有"再查一遍"这个动作，检索是一次性的,查完就进生成,没有回头路。

面试官最后补了一句:“你做的是一条流水线,零件再好它也是条流水线。可真实问题需要的不是流水线,是一个会自己判断够不够、会自己回头补查的 Agent。这两者差的不是一个 reranker,是整个范式。”

这道题之所以越来越高频,是因为它卡的正是一个分界:你到底是把 RAG 当成一个固定管线在调参,还是真把它当成一个能自主决策的系统在设计。这两种人,面试官三五句话就能分出来。

今天这篇,我就把 Agentic RAG 从原理到代码、再到一条真实轨迹,全部拆开讲。讲完你会明白,从传统 RAG 到 Agentic RAG,变的不是某个零件,是检索这件事在系统里的"身份"。

一、传统 RAG 为什么是一条"死链路"

要讲清楚 Agentic RAG 好在哪，得先把传统 RAG 的天花板摆明白，不然解法是悬空的。

传统 RAG 的工作方式，本质是一条单向流水线：用户 query 进来，做向量检索，把 top_k 结果拼进 prompt，交给大模型生成，结束。中间可以塞 reranker、可以做 query 改写、可以加混合检索，但不管塞多少零件，它的拓扑结构没变——信息只往一个方向流，没有任何一个环节能回头。

我把它叫"死链路"，是因为它有三个从架构上就没法绕过去的死穴。

第一个死穴：检索质量一锤定音，错了无法挽回。整条链路里，只有一次检索机会。这一次召回f户问"某款重疾险的等待期是多久"，向量检索经常把好几款产品的等待期条款一起召回，因为它们文本太像了。reranker 能缓解，但只要这一次没排对，答案就废了，系统自己毫不知情。

第二个死穴：处理不了多跳问题。很多真实问题不是一次检索能答的，它需要先查到 A，再根据 A 去查 B，最后综合 A 和 B 才能答。比如"这款产品 2023 年的理赔率，比 2022 年高的主要原因是什么"。这个问题里藏着至少三次检索：2023 年的理赔率、2022 年的理赔率、理赔率变化的归因说明。传统 RAG 只做一次检索，用整个问题去召回，结果往往是召回了一堆同时提到"理赔率"和"2023"的片段，但每一条都只覆盖问题的一个角，凑不齐完整答案。它没有"基于上一次的结果决定下一次查什么"的能力。

第三个死穴：不知道"够不够"，也不知道"准不准"。传统 RAG 召回完就直接进生成，它从来不评估这批结果到底相不相关、信息够不够支撑一个回答。够也答，不够也答，相关也答，不相关也答。它没有一个"反思"的环节去判断当前手里的料能不能开工。

这第三个死穴在我们项目里造成的事故是最隐蔽的。有一次用户问一款产品的"保险责任范围"，知识库里这款产品的责任条款恰好缺失，但向量检索还是"尽职"地返回了五条最相近的——全是别的产品的责任条款。传统 RAG 不会判断"这五条其实都不是这款产品的"，它照样把这堆料拼进 prompt，模型也照样基于这些不相干的条款编出了一段看似专业的回答。最后是用户投诉过来我们才发现，系统从头到尾都"以为"自己答对了。这种错最可怕的地方，就在于系统对自己的错一无所知，因为它根本没有自我审查这个动作。

这三个死穴的根，是同一个东西：检索在传统 RAG 里是一个被动的、一次性的步骤，不是一个能被反复调用、被主动决策的能力。你想在死链路上修出"回头"的能力，是修不出来的，因为链路本身不允许回头。

传统 RAG 的单次检索：一条无法回头的"死链路"

二、核心转变：把"检索"从一个步骤变成一个工具

Agentic RAG 的核心思想，一句话就能说清：不再把检索当成流水线上的一个固定步骤，而是把它做成一个 Agent 可以反复调用的工具（tool）。

这个转变看着小，影响是颠覆性的。一旦检索变成工具，决定"要不要检索、检索什么、检索几次、查完够不够"的，就不再是写死的流程，而是一个会推理、会规划的 Agent。链路从一条直线，变成了一个带反馈的循环。

我们先看这个循环长什么样。一个最基础的 Agentic RAG，主循环里有这么几个动作在转：

第一步，规划（Plan）。Agent 拿到用户问题，先判断：这个问题需要检索吗？如果需要，第一步该查什么？复杂问题要不要先拆成几个子问题？

第二步，检索（Retrieve）。Agent 调用检索工具，传入它自己决定的查询词——注意，这个查询词不一定等于用户的原始问题，可能是 Agent 改写过、聚焦过的。

第三步，反思（Reflect）。这是传统 RAG 完全没有的环节。Agent 拿到检索结果后，自己评估：这批结果跟我要查的相关吗？信息够回答问题了吗？还缺哪一块？

第四步，决策（Decide）。基于反思的结论，Agent 决定下一步：信息够了就生成答案；不够就带着"还缺什么"回到第二步，换个查询词再查；如果发现整个方向都不对，甚至可以换数据源、改写问题重新规划。这一步的动作空间比传统 RAG 丰富得多——传统 RAG 检索完只有"生成"这一条路，而这里至少有"继续查、换数据源、改写问题、直接回答、放弃并说没有"这么几个出口，每一个都由 Agent 根据当前局面自己选。正是这种多出口，才让它有了应对复杂局面的弹性。

这四步转起来，就是 Agent 把检索当工具反复调用的过程。它跟传统 RAG 最本质的区别，是多了"反思"和"决策"这两个让链路能回头的环节。

落到代码上，第一件要做的事，就是把检索包成一个工具，而不是写死在流程里：

def retrieve(query: str, top_k: int = 5, source: str = "vector") -> list[dict]: """检索工具：Agent 自主决定 query / top_k / 数据源。 返回带来源标注的文档片段，供 Agent 反思时判断相关性。""" if source == "vector": hits = vector_store.search(embed(query), top_k=top_k) elif source == "bm25": # 关键词召回，补向量召回的短板 hits = bm25_index.search(query, top_k=top_k) elif source == "web": # 知识库里没有时，兜底走外部搜索 hits = web_search(query, top_k=top_k) return [{"text": h.text, "source": h.doc_id, "score": h.score} for h in hits] # 注册成工具，交给 Agent 自己决定怎么用、用几次 TOOLS = {"retrieve": retrieve}

有了工具，主循环就是经典的"思考—行动—观察"在转，只不过行动主要是调retrieve：

def agentic_rag(question: str, max_steps: int = 6) -> str: history = [] # 攒每一步的检索与反思 for step in range(max_steps): # 1. 规划 + 决策：让模型基于已有信息决定下一步动作 decision = llm_plan(question, history) # 返回 {action, query, reason} if decision["action"] == "answer": # Agent 自己判断信息够了，进入生成 return llm_generate(question, history) # 2. 行动：按 Agent 自己定的 query / 数据源去检索 docs = retrieve(decision["query"], source=decision.get("source", "vector")) # 3. 反思：让模型评估这批结果相不相关、够不够 reflection = llm_reflect(question, decision["query"], docs) history.append({"query": decision["query"], "docs": docs, "reflection": reflection}) # 兜底：步数用完也得给个答案，避免空转 return llm_generate(question, history)

你对比一下传统 RAG 那条retrieve → generate的直线，区别一眼就出来了：这里retrieve被放进了一个循环，每次检索后都有llm_reflect在判断，每次循环开头都有llm_plan在决策要不要继续、查什么。检索从"流程的一环"变成了"Agent 手里随时能拿起来用的工具"。

这里有个细节得讲透，不然你只是把代码抄了一遍，没理解它为什么转得起来——llm_plan和llm_reflect这两个环节，本质上都是用一个结构化的提示词让模型吐出结构化的判断。以llm_reflect为例，它给模型的提示词大致是："这是用户问题，这是我刚才用某查询词检索回来的几条结果，请你判断：每条结果跟问题相不相关；现在手里的信息够不够回答；如果不够，还缺哪一块、下一步该查什么。"模型回一个结构化结论，比如：

{ "relevant_docs": [1, 3], "enough": false, "missing": "缺 2022 年的理赔率基准，无法做同比", "next_query": "2022 年重疾险理赔率" }

这个missing和next_query，就是让链路能"回头"的燃料——它把"还缺什么"明确地传给下一轮的llm_plan，下一轮就不再用原问题瞎查，而是奔着这个缺口去。传统 RAG 整条链路里，根本没有任何一个地方会生成这种"我还缺什么"的判断，这是两者最本质的能力差。

这就是范式的转变。面试官说的"差的是整个范式"，差的就是这个——不是给流水线加零件，是把流水线换成一个会自己拿工具、查完还会回头看一眼够不够的人。

Agentic RAG 的决策循环：把"检索"变成可反复调用的工具

三、三种主流模式，别只会说一个名词

“把检索当工具反复调用"是总思路，但具体怎么个调法、反思反思什么、纠错怎么纠，业界沉淀出了几种成型的模式。面试时如果只会说"Agentic RAG 就是让 Agent 多查几次”，是会被追着问细节问到露馅的。我把最主流的三种讲清楚，每一种解决的问题都不一样。

模式一：Self-RAG，让模型自己决定"要不要查、查得对不对"

Self-RAG 的核心，是给模型加上一套反思标记（reflection token）。模型在生成的过程中，会主动吐出几类特殊标记，来对自己的行为做判断：

一是要不要检索。不是所有问题都需要查知识库，"帮我把这段话润色一下"就不用查。模型先吐一个标记，判断当前这步需不需要检索。这一点很关键，它避免了传统 RAG 那种"不管问什么都先查一遍"的浪费和干扰。

二是检索回来的片段相不相关。对每一条召回的文档，模型会标注它跟问题相不相关、支不支持接下来的生成。不相关的直接弃掉，不进生成。

三是生成的内容有没有被文档支撑。模型生成一句话后，会回头标注这句话是不是真的有检索片段在背书，还是自己编的。这是在源头上压制幻觉。

这三类标记里，最值钱的是第三类。传统 RAG 最让人头疼的就是模型"一本正经地编"——它读了五条文档，但生成答案时偷偷掺了一句文档里根本没有的话，你还很难发现。Self-RAG 让模型每生成一段就回头标注"这段有没有出处"，等于在生成的同时做了一道自查，没出处的内容会被标记出来，可以直接拦掉或要求重新生成。

Self-RAG 的价值，在于它把"判断"这件事内化进了模型本身，让模型对自己的检索和生成有了自我审查。代价是这套反思标记的能力，通常需要专门的训练数据去微调模型才能稳定吐出，不是套个提示词就能完美复现的。它适合那种对答案可信度要求很高、不能容忍模型瞎编的场景，比如金融、医疗的问答。

模式二：CRAG，给检索结果加一个"质检员"

CRAG 全称 Corrective RAG，纠错式 RAG。它的思路比 Self-RAG 更工程化、更轻量：在检索之后、生成之前，插一个轻量的检索质量评估器（retrieval evaluator），给这批召回结果打个分，判断它属于三种情况的哪一种：

• Correct（可靠）

  ：召回结果跟问题高度相关，直接拿去生成。

• Incorrect（不可靠）

  ：召回结果跟问题基本不沾边，这时候不能硬用，触发纠错——通常是改写查询去重查，或者直接走 web 搜索兜底。

• Ambiguous（模棱两可）

  ：介于两者之间，既不能全信也不能全弃，做法是把知识库召回的和 web 搜索的结果合在一起，让生成环节自己取舍。

CRAG 最聪明的地方，是这个评估器很轻，可以用一个小模型甚至一个微调过的判别器来做，不用每次都动用大模型。它等于在死链路里硬插了一个"质检"环节，质检不过就打回重查。落到代码上，就是在检索和生成之间加一道判断：

def crag_retrieve(question: str) -> list[dict]: docs = retrieve(question, source="vector") grade = evaluate_retrieval(question, docs) # 轻量评估器：correct/incorrect/ambiguous if grade == "correct": return docs # 召回靠谱，直接用 elif grade == "incorrect": # 召回是垃圾，改写查询走 web 兜底，绝不把噪声喂给模型 new_query = rewrite_query(question) return retrieve(new_query, source="web") else: # ambiguous # 拿不准，知识库 + web 一起上，让生成环节去权衡 web_docs = retrieve(rewrite_query(question), source="web") return docs + web_docs

你回头看开头那道面试题——“它召回完那五条，自己知道是不是垃圾吗”——CRAG 的这个评估器，正面回答了这个问题。这就是为什么我说，能把 CRAG 的三档评分讲出来，比空说"Agentic RAG 会自己重查"要值钱得多。

模式三：多跳 ReAct 检索，把检索嵌进推理循环

前两种主要解决"单次检索的质量"问题，多跳 ReAct 检索解决的是"一次根本查不完"的问题，也就是第一节说的多跳死穴。

它的做法，是把检索工具直接嵌进 ReAct（推理与行动，Reasoning and Acting）循环里。Agent 面对一个复杂问题，先在脑子里把它拆成几跳，然后一跳一跳地查：第一跳查到的结果，成为第二跳查询词的依据；第二跳的结果，又喂给第三跳。每一跳之间，模型都在推理"我现在知道了什么，还差什么，下一步该查什么"。

这里的关键，是每一跳的查询词都不是凭空来的，而是基于上一跳的检索结果推理出来的。这跟"一次性把问题拆成三个子查询，并行查三次"有本质区别——并行拆分没法处理"下一步查什么取决于上一步查到什么"的依赖关系。比如"某高管现在任职的公司，去年营收多少"，你得先查到他现在在哪家公司，才知道第二跳该查哪家公司的营收，这种链式依赖只能靠多跳串行去解，拆成并行查询是查不对的。

这套东西，跟我之前写的 Deep Research Agent 系列其实是同源的——Deep Research 本质上就是一个把搜索、访问网页当工具反复调用的多跳 Agent。区别只在于，Deep Research 的工具是面向开放网络的搜索，而多跳 RAG 的工具是面向你自己知识库的检索。底层的"分解问题、逐跳推进、综合作答"是一回事，连"步数多了上下文怎么管"的坑都是共通的。

这套从问题分解到逐跳检索的完整实现，我整理成了一组按公司和难度分好的面试题，放在了官网题库里（www.wushixiongai.com），里面每道题都标了面试官常见的追问链，想提前练手的可以去翻翻。

三种模式不是互斥的，真实系统里经常组合用：用 Self-RAG 的思路决定要不要查，用 CRAG 的评估器把噪声挡在生成之前，用多跳 ReAct 处理复杂问题。下面这张图，把三者各自管的事和触发条件摆在一起看更清楚。

三种主流 Agentic RAG 模式：Self-RAG / CRAG / 多跳 ReAct

四、走一遍真实轨迹：一个多跳问题怎么被啃下来

光讲模式还是抽象，我用我们金融项目里一个真实的多跳问题，走一遍完整轨迹，你就能看清 Agentic RAG 跟传统 RAG 在同一个问题上的差距到底有多大。

问题是这个：“这款重疾险产品 2023 年的理赔率，比 2022 年高的主要原因是什么？”

先看传统 RAG 怎么处理。它把整个问题做 embedding，去向量库取 top_k。召回回来的，是一堆同时提到"理赔率""2023""重疾险"的片段，可能包含 2023 年的理赔率数字，但 2022 年的数字、以及归因分析，大概率没召全——因为这些信息分散在年报的不同章节，单次检索很难一网打尽。模型拿着残缺的料硬答，结果要么漏了对比，要么把原因编一个出来。

再看 Agentic RAG 怎么处理。它不会一上来就用整个问题去查，而是先规划，把问题拆开，一跳一跳推进：

第一跳，Agent 判断要先拿到 2023 年的数据，查询词聚焦成"2023 年重疾险理赔率"。检索回来命中年报里的具体数字。反思：拿到了 2023 年的数，但问题要的是"比 2022 年高的原因"，还缺 2022 年的基准和归因，继续。

第二跳，Agent 基于上一跳的缺口，把查询词改成"2022 年重疾险理赔率"。检索命中 2022 年的数字。反思：现在两年的数都有了，能算出确实是涨了，但"为什么涨"还没有，继续。

第三跳，Agent 把查询词聚焦到归因上，“2023 年理赔率上升 原因 年报说明”。这一跳触发了 CRAG 的评估器——召回结果里噪声偏多，评估器给了 incorrect。于是 Agent 不硬用，改写查询词重查，换成更贴年报口径的"理赔率上升 重大疾病 出险率 老龄化"。这次召回到了年报里的归因段落。反思：归因有了，信息齐了。

第四跳，Agent 判断信息已经够支撑一个完整回答，停止检索，进入生成。它把三跳攒下来的料综合起来，给出一个带数据对比、带原因、带来源标注的答案。

你把这两条路一对比就明白了：传统 RAG 是拿整个问题赌一次检索，多跳 Agentic RAG 是把问题拆成几个能查准的小问题，逐个击破，中间还能靠反思发现缺口、靠 CRAG 评估器挡住噪声重查。同样一个问题，前者大概率残缺或编造，后者能稳稳啃下来。代价是后者花了四次检索、好几次大模型调用，慢、也更贵——这个代价该不该花，是下一节要讲的事。

一个多跳问题的真实执行轨迹：Agentic RAG 逐跳啃下来

五、上生产前必须堵的三个坑

把 demo 跑通和把 Agentic RAG 放上生产，中间隔着好几个坑。这几个坑我都实打实踩过，面试官也爱拿这些来分辨你是只在 notebook 里跑过，还是真把它接过线上流量。

第一个坑：循环不收敛，Agent 在那儿空转烧钱。Agentic RAG 最危险的失败模式，不是答错，是停不下来。我第一版上线后遇到过一个 case：用户问的问题，知识库里压根没有相关内容。结果 Agent 检索一次发现不相关，改写查询再查，还是不相关，再改写……它陷进了一个"反思说不够、决策说再查、查了还是不够"的死循环，一个问题烧掉了二十多次模型调用，最后还是没答上来。

解法有三层，得叠着用。最硬的一层是max_steps强制上限，到了步数无论如何停下来，用现有信息给个答案或者老实说"知识库里没有"。第二层是重复查询检测，把每一跳的查询词存下来，如果新查询词和历史查询词的相似度过高，说明 Agent 在原地打转，直接中断。这个我在 Deep Research 系列里写过，用 embedding 算查询词之间的余弦相似度，超过阈值就判定为重复。第三层是给反思环节加一个"还值不值得继续"的判断：如果连续两跳都没有带来新信息，就果断收手。三层一叠，才能保证它该停的时候一定能停。

def agentic_rag_safe(question, max_steps=6, sim_threshold=0.92): history, past_queries = [], [] for step in range(max_steps): # 第一层：步数硬上限 decision = llm_plan(question, history) if decision["action"] == "answer": return llm_generate(question, history) q = decision["query"] # 第二层：重复查询检测，相似度过高说明在原地打转 if any(cosine(embed(q), embed(pq)) > sim_threshold for pq in past_queries): break # 已经查过类似的，果断收手 past_queries.append(q) docs = retrieve(q, source=decision.get("source", "vector")) history.append({"query": q, "docs": docs, "reflection": llm_reflect(question, q, docs)}) return llm_generate(question, history) # 兜底：到上限也得给答案

第二个坑：成本和延迟失控，扛不住高并发。前面算过账，一个走四跳的问题背后是十几次模型调用。如果你把所有问题都丢给这套链路，线上的延迟和账单会非常难看。我们的做法是在入口加一个很轻的问题复杂度分类器，判断这个问题到底要不要走 Agentic 链路——简单的单跳查询直接走传统 RAG，秒回；只有判断为多跳或复杂的，才路由到 Agentic 链路。这个分类器可以很简单，一个小模型甚至一组规则就够，关键是别让简单问题白白承担多轮调用的成本。另外，CRAG 的评估器一定要用小模型或判别器来做，绝不能每次评估都调一次大模型，否则评估本身就成了新的成本黑洞。

第三个坑：反思不可信，模型自己骗自己。Agentic RAG 高度依赖模型的"反思"判断——它说够了就生成，说不够就重查。但模型的自我评估并不总是靠谱，有时候明明召回的是噪声，它却反思说"相关、够了"，然后基于噪声硬答。这就是为什么我更偏向 CRAG 那种用独立评估器的思路，而不是完全信任模型的自我反思。让一个独立的、专门训练过的判别器来给检索结果打分，比让生成模型自己评价自己，要可靠得多。自己考自己的卷子，分数不能全信，这个道理在 Agent 里一样成立。

这三个坑，本质上对应着 Agentic RAG 为了换取"灵活"所付出的三种代价：可能不收敛、可能很贵、可能自欺。理解这些代价，比单纯会画那个漂亮的循环图重要得多。

六、什么时候该上 Agentic RAG，什么时候是过度设计

讲到这你可能觉得 Agentic RAG 哪哪都好，应该全面替换传统 RAG。这恰恰是面试里最容易被反杀的地方——但凡你表现出"无脑上 Agentic RAG"的倾向，面试官立刻会问你成本，而这正是很多人答不上来的。

Agentic RAG 的代价是实打实的。传统 RAG 一个问题就一次检索、一次生成，两次模型调用打底。Agentic RAG 呢？每一步规划是一次模型调用，每一次反思是一次调用，CRAG 的评估是一次调用，多跳几次这些就翻几倍。一个走了四跳的问题，背后可能是十几次模型调用。延迟从几百毫秒拉到好几秒，成本翻好几倍。

所以选型的核心判断，不是"哪个更先进"，是"这个问题值不值得这么查"。我自己的判断标准大致是这样：

我在那个金融项目里的实际做法，是混着来的：占大多数的简单条款查询，走传统 RAG 加 reranker，快又省；只有那些明显是多跳、或者用户问得很复杂的问题，才路由到 Agentic 的链路上去。判断走哪条，用一个很轻的分类器在入口处分流。这样既没有让简单问题白白承担 Agentic 的成本，又让复杂问题能享受到多跳的好处。

这个入口分类器，我一开始想得很复杂，后来发现没必要。最简单的版本，就是用几条规则加一个轻量判断：问题里有没有同时出现两个以上的实体、有没有"对比"“为什么”"变化"这类需要综合推理的词、问题长度超不超过某个阈值。命中这些信号的，判为复杂走 Agentic，其余走传统。这套规则上线后能把大概八成的简单问题挡在传统链路里，只有两成走重链路，整体的延迟和成本就压住了。后来流量大了，才把规则换成一个小模型来分类，准确率更高，但思路是一样的——核心是别让分类器本身变成新的瓶颈，它必须比它要保护的链路轻得多。

能把"我不会无脑上 Agentic RAG，我会按问题复杂度做路由"这层讲出来，面试官就知道你是真在生产环境里权衡过成本的，而不是看了几篇文章就来秀名词。这种"知道什么时候不用"的判断力，比"知道它怎么用"更能体现你做没做过真东西。

传统 RAG vs Agentic RAG：能力与成本对比

七、面试怎么答 Agentic RAG

如果面试官问"什么是 Agentic RAG"“它跟传统 RAG 有什么区别”“什么场景用”，按下面四步答，能把这道题接得又稳又有深度。

先点破范式差异（30 秒）：“传统 RAG 是一条单向流水线，检索是一次性的、被动的步骤，召回错了无法挽回，也处理不了多跳问题。Agentic RAG 的核心转变，是把检索从一个固定步骤变成一个 Agent 可以反复调用的工具，链路从直线变成带反思和决策的循环。Agent 能自己判断要不要查、查什么、够不够、要不要重查。”

再讲清三种模式（40 秒）：“落地主要有三种成型的模式。Self-RAG 是给模型加反思标记，让它自己判断要不要检索、召回相不相关、生成有没有被支撑。CRAG 是纠错式，在检索和生成之间加一个轻量评估器，给召回打 correct、incorrect、ambiguous 三档，不可靠就改写查询或走 web 兜底。多跳 ReAct 检索是把检索嵌进推理循环，把复杂问题拆成几跳逐个查。真实系统经常组合用。”

然后给一个具体轨迹（30 秒）：“举个例子，问’2023 年理赔率比 2022 年高的原因’，传统 RAG 一次检索凑不齐料。Agentic RAG 会拆成三跳：先查 2023 年数据，反思发现缺 2022 年的，再查，再发现缺归因，第三跳查归因时召回噪声多，CRAG 评估器打回重查，最后信息齐了才生成带来源的答案。”

最后亮选型判断（20 秒）：“但我不会无脑上 Agentic RAG，它每多一跳就多好几次模型调用，延迟和成本翻几倍。简单单跳 FAQ 用传统 RAG 就够，只有多跳、对召回质量敏感、知识库噪声大的场景才值得上，而且我会在入口做路由，让简单问题走轻链路。”

能把第四步这个"什么时候不用"答出来，整道题的分量就不一样了。

答完这四步，面试官大概率还会顺着往下追。我把最常见的三个追问和接法也给你备着：

追问一：“Agentic RAG 会不会陷入死循环？怎么防？”这是在考你有没有真上过生产。答：会，最典型的就是知识库里没有相关内容时它反复改写重查停不下来。我会叠三层防护——max_steps 硬上限、用 embedding 算查询词相似度做重复检测、连续两跳无新信息就收手。能把这三层说出来，面试官就知道你踩过这个坑。

追问二：“你怎么判断一个问题该走 Agentic 还是传统 RAG？”答：在入口加一个轻量的复杂度分类器做路由，简单单跳的走传统 RAG 秒回，多跳或复杂的才进 Agentic 链路。绝不能一刀切，否则简单问题白白承担多轮调用的延迟和成本。

追问三：“Self-RAG 和 CRAG 你更倾向用哪个？”答：看场景，但工程上我更偏 CRAG 的独立评估器思路。因为模型自己反思自己有时不可信，明明是噪声它也可能说"够了"。用一个独立训练的判别器来打分，比让生成模型自己考自己的卷子要可靠。能讲出"为什么不完全信任模型自我反思"这一层，是加分项。

写在最后

这一篇，本质上是把 RAG 从"一条流水线"重新理解成"一个会用工具的 Agent"。

传统 RAG 的天花板，不在某个零件不够好，而在它的拓扑结构——信息只能往一个方向流，检索是一次性的，错了无法回头。Agentic RAG 的解法，是把检索变成可反复调用的工具，给链路加上反思和决策，让系统能自己判断够不够、准不准，能回头重查。Self-RAG、CRAG、多跳 ReAct，是这个思路下三种各有侧重的成型模式。

理解这个转变，不只是为了答面试题。真实项目里，一旦你的 RAG 开始频繁出现"召回了一堆不相关的东西还硬答"“复杂问题答得残缺”“明明知识库里有却查不到”，基本就能断定，你撞到了单次检索这条死链路的天花板，该考虑往 Agentic 的方向走了。但记住那句最值钱的判断，别无脑上，按问题复杂度做路由，把成本花在真正需要它的问题上。

我自己的体会是，从传统 RAG 到 Agentic RAG，最难的不是写出那个循环，而是想清楚每一个"让 Agent 自己决定"的环节背后，你愿意为这份自主付出多少成本、又怎么给它兜底。把这两件事想透了，你做的就不再是调参，而是真正在设计一个系统。

学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%免费】