27届大模型面试准备（三十二）：RAG 进阶------从朴素 RAG 到 Agentic RAG 与多模态检索增强
A12 讲过朴素 RAG 的"标准三件套"：切块、向量召回、拼进 prompt。B19 讲了怎么"评测 RAG"有没有用。这一篇站在两者之上谈进阶：朴素 RAG 在真实复杂问题前会露怯------问题要跨文档、要边查边想、要判检索到的东西靠不靠谱。于是 Self-RAG、Corrective RAG、Agentic RAG、Graph RAG、Fusion RAG 依次出现。本文还会把我们自己的 4MRAG / MCTS-MRAG 研究放进去，说明"面向复杂推理的多模态检索增强"是怎么把这条线推到工程前沿的。按"朴素 RAG 的天花板 → Self-RAG → Corrective RAG → Agentic RAG → Graph/Fusion → 多模态 RAG 与 4MRAG → 工程落地 → 可观测与故障复盘 → RAG 与微调取舍 → 选型速查表 → 面试速答"展开。
一、朴素 RAG 的天花板在哪
1.1 三个结构性缺陷
朴素 RAG 一次性把 query 向量化、召回 top-k、拼进上下文。它在"单跳、答案集中在一两段"的问题上很好用，但遇到复杂问题就崩：
-
查询不善：用户问句长而模糊，直接向量化召回偏；
-
一锤子召回：只召一次，漏掉互补信息，也不知"召回来的是否够"；
-
不会反思：检索到的内容若有误或无关，模型照单全收，幻觉照出。
朴素 RAG 的线性流水（脆弱点标 ）
query -> [embed] -> [召回 top-k] -> [拼 prompt] -> [生成]*
↑ 查询没改写 ↑ 只召一次 ↑ 不校验相关性/正确性
1.2 复杂问题需要"过程"
真实知识问答常是"多跳"的：答案分散在多篇文档，要先查 A 得到中间事实，再带着它查 B。朴素 RAG 没有"查到一半再决定下一步查什么"的机制，所以天然做不了多跳。这正是进阶 RAG 的共同动机------把检索从"一次函数调用"变成"一个可被推理驱动的过程"。
二、Self-RAG：让模型自己决定"要不要查、查得对不对"
2.1 核心思想
Self-RAG 训练模型在生成时自主插入特殊标记：Retrieve（我需要查一下）、IsRel（这段检索相关吗）、IsSup（答案有检索支撑吗）、IsUse（这段有用吗）。模型一边生成一边判断是否检索、并自我批判检索质量，过滤掉不相关/不支持的内容。等于把"检索决策"和"相关性校验"内化进生成过程。
2.2 与朴素 RAG 的区别
| 维度 | 朴素 RAG | Self-RAG |
|---|---|---|
| 检索时机 | 生成前固定一次 | 生成中按需多次 |
| 相关性判断 | 无 | 模型显式打分过滤 |
| 幻觉控制 | 弱 | 用 IsSup 强制有据 |
| 成本 | 低 | 高（多次检索+批判） |
# Self-RAG 决策逻辑（示意）
def self_rag_generate(llm, retriever, q):
out, ctx = [], []
for step in llm.stream(q):
if step.token == "<Retrieve>":
docs = retriever(q if not ctx else f"{q}\n已知:{ctx}")
kept = [d for d in docs if llm.judge("<IsRel>", d) == "yes"]
ctx += kept
elif step.token == "<IsSup>":
if llm.judge("<IsSup>", step.text, ctx) == "no":
continue # 无支撑则不输出，防幻觉
else:
out.append(step.text)
return "".join(out)三、Corrective RAG：检索质量兜底
3.1 什么时候该"重查"
Corrective RAG（CRAG）给召回结果做"整体相关性"评级：全相关 → 直接用；部分相关 → 先"知识精炼"（把相关句子摘出来再喂）；全不相关 → 触发"回退检索"，去网页等更可靠源补查。它把"检索可能失败"当成常态来处理，而不是假设一次召回必中。
3.2 适合什么
CRAG 很像 RAG 管道的"重试+兜底"层，工程上很好接：在朴素 RAG 外面套一层"相关性门禁"，不相关就换源或换 query。它比 Self-RAG 轻，因为只在检索边界做评级，不侵入生成。面试对比题常问"Self-RAG 和 CRAG 取舍"------答：要细粒度自我批判、质量优先选 Self-RAG；要低成本兜底、工程优先选 CRAG。
四、Agentic RAG：把检索变成 Agent 的技能
4.1 从"管道"到"智能体"
Agentic RAG 把检索增强交给一个 Agent：Agent 能用多种工具（向量库、网页、SQL、知识图谱），能规划多步检索、能根据中间结果改写 query、能决定"查够了没"。它和前面两种的本质区别是------检索不再是固定算法，而是 Agent 在推理循环中可调用的能力（呼应 B12 ReAct、B18 Function Calling）。
4.2 典型循环
Agentic RAG 推理循环
问题 -> [规划: 需要哪些证据]
-> [行动: 调 retriever / web / sql]
-> [观察: 得到证据]
-> [思考: 够了吗? 不够 -> 改写 query 再查]
-> [回答]
# Agentic RAG 的最小 ReAct 循环（示意）
def agentic_rag(agent, tools, q, max_step=5):
traj = f"问题：{q}\n"
for _ in range(max_step):
act = agent.decide(traj, tools) # 决定调哪个检索工具/是否停止
if act.name == "Answer":
return act.arg
obs = tools[act.name](act.arg) # 执行检索
traj += f"\n行动:{act.name}({act.arg})\n观察:{obs[:300]}"
return agent.decide(traj, tools, force_answer=True)五、Graph RAG 与 Fusion RAG
5.1 Graph RAG：用知识图谱扛"全局抽象"
微软 Graph RAG 先把语料抽成"实体-关系"图谱，再做社区摘要，回答时能利用图的结构做"全局性、总结性"提问（如"这家公司整体战略是什么"）。朴素向量检索擅长"点查"，Graph RAG 擅长"面查"。代价是建图贵、更新难。适合语料稳定、问题偏宏观的场景。
5.2 Fusion RAG：多路召回再融合
Fusion（如 RRF，Reciprocal Rank Fusion）把多种检索器（向量、BM25、重排）的结果按排名融合，弥补单检索器盲区。它和"查询改写多次"互补：多次查询解决"问法"，多路融合解决"召回器各有偏好"。生产 RAG 几乎必上一路 BM25 + 一路向量，再用重排模型收口。
六、多模态 RAG 与我们的 4MRAG
6.1 为什么多模态让 RAG 更难也更有价值
当证据不只是文字，还有图、表、版式时，检索要"跨模态"：用问题去匹配图里的信息，或把图转成可检索的表示。这正是 4MRAG（面向复杂推理的多模态检索增强生成）的切入点------复杂推理问题往往需要图文混合证据，单一文本检索召回不到图里的关键事实。
6.2 4MRAG 的 pipeline 与多智能体
4MRAG 用多智能体 pipeline 做"按需组合模态检索器集成"：遇到不同子问题，动态选不同模态的检索器（文本检索器、图表理解、版面解析），把各自召回的证据融进推理。它还给出计算复杂度分析章节，说明不同组合策略的代价。和朴素 RAG 比，4MRAG 把"召什么模态、怎么组合"变成了可推理、可分析的决策，而不是固定一路向量召回。
6.3 MCTS-MRAG：用树搜索替"一次性生成"
MCTS-MRAG 进一步把推理过程建模成一棵搜索树：每个节点是一次"检索+推理"动作，用蒙特卡洛树搜索在多条"检索-推理"路径里择优。这解决了 Agentic RAG 里"贪心一步错、步步错"的问题------搜索能保留多条候选路径、按回报回溯。它做消融实验验证"按需组合模态检索器"的贡献，正好对应 A31 里"多模态推理要靠证据"的结论。面试讲这个，能体现你既懂前沿方法（Agentic/树搜索），又有真实可落地的系统（4MRAG/MCTS-MRAG），是极强的差异化。
4MRAG / MCTS-MRAG 的演进关系
朴素 RAG ──> 多模态召回(图/表/文) ──> 多智能体按需组合检索器(4MRAG)
│
把"检索-推理"建成搜索树, MCTS 择优(MCTS-MRAG)七、工程落地的几个硬骨头
7.1 召回质量决定上限
所有进阶 RAG 都假设"检索器能召到对的"。实践中先花力气在切块策略、embedding 选型、重排上，再谈 Self/Corrective/Agentic。检索差，上层再聪明也救不回。
7.2 成本与延迟
Self-RAG / Agentic RAG 要多轮检索+生成，延迟和 token 成本显著上升。工程上用"简单问题走朴素 RAG，复杂问题才升级"的分级策略，呼应 B26 成本工程。
7.3 评估闭环
B19 强调的 RAG 评估在这里更关键：多跳准确率、检索命中率、归因可追（答案能不能指回证据）。没有评估，进阶 RAG 只是在"感觉更聪明"。
7.4 知识更新
Graph RAG 建图贵、更新难；向量库增删相对易。选型时要把"知识更新频率"算进去------高频更新的语料慎用重图结构。
八、检索质量的可观测：把 RAG 当系统来守
进阶 RAG 上了多层逻辑，更要能"看见"每一层健不健康，否则线上退化无人知晓。可观测要盯三层指标：检索层（召回命中率、空召回率、平均召回延迟、各检索器贡献占比）、决策层（Self-RAG 的 IsRel/IsSup 通过率、Agentic RAG 的平均检索步数/改写次数）、结果层（答案有依据占比、归因可追率、用户反馈的负例率）。这些指标和 B20 的可观测性、B31 的评测共用一套口径最省事------评测集是离线基线，线上监控是实时版本，两者漂移就报警。一个实战信号：若"答案有依据占比"持续下滑但准确率没变，往往是检索源悄悄变了（网页结构改版、知识库更新），该去查检索层而不是怪生成模型。把 RAG 当成带队列、带缓存、带外部依赖的分布式系统来守，而不是当成"一个 prompt 技巧"，是它能不能上生产的分水岭。
九、一个真实故障复盘：RAG 答非所问怎么查
讲一个典型翻车，看清定位思路。现象：某客服 RAG 突然开始答非所问，准确率从 92% 掉到 70%。排查顺序：第一步看检索层，发现空召回率从 3% 升到 40%------根因是知识库做了一次迁移，文档切块的标题丢了，向量召回匹配不上；第二步看决策层，Self-RAG 的 IsRel 通过率同步掉，说明模型自己也在"勉强用不相关的块"；第三步看结果层，答案有依据占比掉、用户负评涨，印证是检索而非生成的问题。修复：补回切块标题、加 BM25 一路 Fusion（标题丢失时正文还能命中），准确率回到 91%。这个案例的三点教训：一是故障大概率在检索层而非模型层，先查召回；二是分层指标让定位从"猜"变"看"；三是 Fusion/回退（Corrective RAG 思路）能在单路检索退化时托底。能对着一次真实故障，用"检索-决策-结果"三层指标一步步定位根因，是 RAG 工程师面试的强加分项，比背架构名词值钱得多。
十、RAG 与微调怎么选：检索增强还是改权重
面试高频二选一："知识老变，我该 RAG 还是微调"。先给结论：知识频繁变、要可引用溯源、长尾覆盖广------选 RAG；要改的是"风格/格式/稳定窄技能"、延迟极敏、无法接外部检索------选微调；两者不互斥，工程上常混合。
为什么变的知识别微调：微调把知识烤进权重，更新要重新训、易灾难性遗忘、且难溯源（说不出答案来自哪条数据），知识一月一变就别想微调。RAG 知识在外部库，更新只是改文档，答案可指回证据（呼应 B19 归因），合规和时效性都赢。
为什么稳定窄技能可考虑微调：若任务是对固定模板抽取、或要极低成本低延迟且环境不允许检索，微调能把"能力"固化进模型，省掉检索链路。但注意：这牺牲了可更新性，适合"技能不变、只换输入"的场景。
混合范式最实用：用 RAG 承载"会变的知识"，用微调（或 LoRA，呼应 A18）承载"稳定的指令遵循/格式/路由判断"。典型架构是微调一个小模型当"检索路由器+相关性判别器"（Self-RAG 的 IsRel/IsSup 判别就常被微调出来），知识仍走 RAG。这样既保知识新鲜，又让决策快而稳。
一个判断清单：问自己四个问题------知识更新频率高吗？（高→RAG）需要答案可溯源吗？（要→RAG）要改的是知识还是能力？（知识→RAG，能力→FT）能接受检索延迟吗？（不能且能力型→FT）。四个问题基本能定。面试被问"为什么不上微调"，答"知识在变+要溯源+长尾广，RAG 更新成本和可解释性碾压微调"即可，反之也能说出微调的适用边界，显得你不是 RAG 原教旨主义者。
十一、选型速查表
| 你的痛点 | 推荐方案 | 代价 |
|---|---|---|
| 单跳问答、求快求省 | 朴素 RAG + 重排 | 低 |
| 查询模糊、召回偏 | Query 改写 + Fusion | 中 |
| 检索常不相关 | Corrective RAG 兜底 | 中 |
| 质量优先、防幻觉 | Self-RAG | 高 |
| 多跳、要边查边想 | Agentic RAG | 高 |
| 宏观总结、语料稳 | Graph RAG | 很高 |
| 图文混合复杂推理 | 多模态 RAG（如 4MRAG） | 高 |
十二、把进阶 RAG 的成本算清楚：延迟、token 与质量的三角
进阶 RAG 多轮检索、多次生成，成本肉眼可见地涨，工程上必须把它当成"延迟-成本-质量"的权衡来管理，而不是"越高级越好"。
先看钱花在哪。一次 Agentic RAG 请求，成本 = 多轮检索的 embedding/重排调用 + 多轮生成的 token（含反复塞回的上下文）+ 可能的网页抓取。Self-RAG 每插入一次 Retrieve/IsRel/IsSup 判定，就多一次前向；Agentic RAG 每多一步，就多一次工具调用加一次生成。所以"步数"和"成本"几乎线性相关，这也回头印证了 B31 为什么说"路径效率"是核心指标------它不只是质量指标，也是成本指标。
工程优化有套路。第一，查询并行：多个子查询同时发出而非串行，把延迟压下来（代价是瞬时并发高）。第二，结果缓存：对"高频问题 + 稳定知识"的检索结果做缓存，命中就跳过整段检索；对"个性化/时效"的才实时查（呼应 B26 成本工程）。第三，分级降级：简单问题走朴素 RAG（一次召回），只有检测到的复杂问题才升级到 Self/Agentic，用路由模型预先判难度。第四，限定步数上限与超时：Agentic RAG 设 max_step 和每步超时，避免"无限循环烧钱"------这正是 B30 生产化改造里"错误自愈 + 预算护栏"的同一思路。
一个容易忽略的点：质量提升不等于成本无上限。Self-RAG 的 IsSup 判定若每次都触发重检索，成本可能翻倍而准确率只涨一个点------这种"边际不划算"的优化要砍掉。正确做法是按业务定"质量门槛"：到达门槛后，剩余预算留给吞吐而非继续堆检索轮数。面试能对着一笔账说清"我的 RAG 每请求多花 X token 换 Y 点准确率、阈值设在哪"，比空谈架构更有说服力。
再给一个具体账本，方便面试当场算。假设一个 7B 主模型跑 RAG，朴素 RAG 单次请求约 1500 输入 token + 400 输出 token；升级到 Agentic RAG 后，平均 4 轮检索、每轮重新拼上下文，输入 token 膨胀到约 6000、输出约 1600，单请求推理成本翻 3 倍以上，延迟从 2 秒涨到 8 秒。若业务是"高并发客服问答"，这种升级直接把吞吐打到原来的三分之一------除非准确率提升能换来可观的商业收益（如少转人工），否则不划算。工程师的判断应是：先用评测集测"朴素 vs Agentic 的准确率差"，差小于 5 个点就别升级；差大于 15 个点且业务愿意为质量付费，才上。
另一个常被忽视的成本是"检索器自身的开销"：向量库查询、reranker 推理、网页抓取都不是免费的。多路 Fusion（一路 BM25 + 一路向量 + 一路重排）每次查询要跑三个检索器再加一次重排，延迟和费用都比单路高。对策是"按 query 难度路由"------简单 query 走单路向量，只有复杂/低置信 query 才升 Fusion，把重检索留给真正需要的人。这又回到"分级"这个反复出现的主题：RAG 的每一层优化，本质都是在"质量"和"成本/延迟"之间按业务画分界线。面试能对着一笔具体账说"我为什么不在所有请求上堆高级检索"，体现的是成熟的工程权衡意识，而非堆功能的炫技。这也是 B26 成本工程在 RAG 侧最具体的落地------把"省了多少、贵在哪"算清楚，再决定上哪一层。
最后给一句选型心法，免得在"上哪个"上纠结：进阶 RAG 没有"最强"，只有"最合适"。判断顺序建议固定为------先问知识变不变（变→RAG），再问问题多跳不（跳→Agentic），再问检索稳不稳（不稳→Corrective/CRAG），再问质量阈值高不高（高且不计成本→Self-RAG），最后才考虑宏观总结且语料稳→Graph RAG。这个顺序是从"成本最低能满足"往前推，而不是从"最先进"往后选。能把这个决策链讲顺，面试基本不会在 RAG 选型上被问倒，因为你有的是"按约束收敛"的工程逻辑，不是"背了一堆名词"。落地时先把朴素 RAG + 重排这条基线跑稳，再按需一层层加，既控制复杂度也控制成本------这和 A30 推理优化"先用配置级优化吃下大部分收益"的节奏如出一辙。
再补一个工程细节，常是面试加分项：进阶 RAG 的"检索质量"要可观测（呼应 B31 评测）。具体盯三件事------召回命中率（召回来的是不是该召的）、空召回率（有没有召空）、各路检索器贡献占比（Fusion 里哪路在干活）。这三者一掉，上层 Self/Agentic 再聪明也救不回，所以它们是 RAG 健康的"仪表盘"。能把"检索质量可观测"当默认动作，说明你不是把 RAG 当黑盒调参，而是当系统运营------这点和 B20 可观测性一脉相承，也是进阶 RAG 能不能稳稳上生产的分水岭：方法决定上限，可观测决定下限。这也是为什么不少 RAG 项目上线前先补监控、再谈高级方法------顺序错了就是拿复杂给烂地基贴金。
十三、面试速答 + 高频追问清单
面试速答（一句话版）：
-
朴素 RAG 弱在多跳、查询不善、不会反思；进阶 RAG 把检索变成"过程"。
-
Self-RAG 让模型自主决定"查不查、查得对不对"，靠特殊标记内化检索决策。
-
Corrective RAG 给召回做相关性评级，不相关就回退检索兜底。
-
Agentic RAG 把检索当 Agent 工具，能规划多步、改写 query、判是否查够。
-
Graph RAG 扛全局抽象，Fusion 多路融合；多模态 RAG（4MRAG）按需组合模态检索器，MCTS-MRAG 用树搜索择优。
-
知识常变/要溯源选 RAG，稳定窄技能选微调，实战多混合。
高频追问清单：
-
朴素 RAG 的三个结构性缺陷？为什么做不了多跳？
-
Self-RAG 的特殊标记有哪些？它怎么防幻觉？
-
Corrective RAG 和 Self-RAG 怎么取舍？工程上更常上哪个？
-
Agentic RAG 和 Self-RAG 本质区别？检索从"算法"变成"什么"？
-
Graph RAG 解决什么朴素 RAG 解决不了的？代价是什么？
-
Fusion / RRF 为什么要多路召回？和 query 改写互补在哪？
-
多模态 RAG 比文本 RAG 难在哪？跨模态检索怎么做？
-
你的 4MRAG 怎么"按需组合模态检索器"？复杂度分析说明了什么？
-
MCTS-MRAG 相对贪心 Agentic RAG 解决了什么？树搜索的回报怎么定？
-
给一个"知识高频更新 + 多跳问答"的业务，你选哪套 RAG？为什么？
-
知识老变时为什么不上微调？RAG 和微调怎么混合最实用？