RAG 在 Agent 中的角色
Q：在渐进式披露的架构下，还需要 RAG 吗？RAG 的角色会怎么变？
来源：蚂蚁集团 Agent 开发二面
新手答：“模型上下文窗口越来越大，RAG 可能不需要了。”
高手答：
RAG 不会消失，但角色会发生本质变化——从“弥补模型知识不足”变成“渐进式披露架构的信息供给层”。
为什么上下文窗口变大不能替代 RAG：
即使窗口有 100 万 token，也不能把所有文档都塞进去：
- 成本问题：塞 100 万 token 的成本是塞 1 万 token 的 100 倍
- 精度问题：信息越多，模型在噪声中迷失的概率越大（Lost in the Middle）
- 实时性问题：长上下文解决不了“信息需要实时更新”的问题
所以不是“要不要 RAG”，而是“RAG 在新架构里扮演什么角色”。
RAG 在渐进式披露架构中的新角色：
传统 RAG：用户提问 → 检索文档 → 塞进上下文 → 生成回答（一次性、静态）
新角色 RAG：Agent 执行到某阶段 → 按需检索该阶段需要的知识 → 精确注入 → 继续执行（多次、动态）| 维度 | 传统 RAG | 渐进式架构下的 RAG |
|---|---|---|
| 触发时机 | 用户提问时一次性触发 | Agent 执行过程中多次按需触发 |
| 检索粒度 | 和用户 query 匹配 | 和当前执行阶段的子目标匹配 |
| 结果用途 | 直接喂给模型生成答案 | 作为当前阶段的决策依据 |
| 生命周期 | 检索一次用到结束 | 阶段切换后可能需要重新检索 |
具体变化：
- 从“回答前检索”到“执行中检索”：RAG 不只在开头检索一次，而是 Agent 在规划、执行、验证各阶段都可能触发检索，每次检索的 query 不同
- 从“通用检索”到“阶段感知检索”：同一个用户问题，规划阶段需要检索的是“方法论文档”，执行阶段需要的是“API 文档”，验证阶段需要的是“规范标准”——检索策略随阶段变化
- 从“替代模型知识”到“精确注入运行时上下文”：RAG 的价值从“给模型不知道的知识”转变为“在正确的时机给出正确的精确信息”
差距在哪：新手用“窗口大了不需要 RAG”的线性思维。高手看到了 RAG 在新架构下的角色转变——从一次性的知识注入变成多阶段的动态信息供给。面试官考的是你对 RAG 技术演进方向的理解，以及能不能把 RAG 放到更大的架构图景中思考。
Q：RAG 在 Agent 体系里应该被看成工具、记忆，还是推理前置步骤？
来源：Agent 开发面试 30 题
新手答：“RAG 就是个工具，需要的时候调一下。”
高手答：
RAG 在 Agent 体系里的定位取决于使用方式，三种定位都成立，适用场景不同：
当工具用——按需调用：
Agent 在执行过程中判断“我需要查资料”，主动调用 RAG 检索。这时 RAG 和其他工具（搜索、计算器）是同级的。
适用场景：开放性任务，Agent 不一定每次都需要检索。比如用户问“1+1 等于几”不需要 RAG，问“公司休假制度”才需要。
当记忆用——上下文扩展：
每次对话开始时，自动检索和当前话题相关的历史文档注入上下文。RAG 充当的是“长期记忆的检索接口”。
适用场景：垂直领域问答，几乎每次都需要外部知识。比如客服机器人，每个问题都要查产品文档。
当推理前置步骤——先检索再思考：
RAG 不是可选步骤，而是必经环节——先检索证据，再基于证据推理。模型不允许在没有证据的情况下直接回答。
适用场景：高准确性要求的场景（法律、医疗），必须有据可依。
| 定位 | 触发方式 | 适用场景 | 典型架构 |
|---|---|---|---|
| 工具 | Agent 主动调用 | 开放性任务 | ReAct + RAG Tool |
| 记忆 | 每轮自动注入 | 垂直领域问答 | RAG-augmented Chat |
| 前置步骤 | 强制先检索 | 高准确性要求 | Retrieve-then-Read |
实际生产中这三种往往混合使用：基础知识自动注入（记忆模式），需要深入查找时主动调用（工具模式），关键结论必须有证据支撑（前置步骤模式）。
差距在哪：新手把 RAG 固定为“工具”一种定位。高手看到了 RAG 在 Agent 体系中的三种不同角色，且说清了各自的适用场景和触发方式。面试官考的是你对 RAG 和 Agent 系统集成方式的灵活理解。
Q：如果检索结果很多但质量参差不齐，你会把控制点放在召回、重排，还是 Agent 规划层？
来源：Agent 开发面试 30 题
新手答：“加 ReRank 重排就行。”
高手答：
三个控制点都需要，但投入产出比不同：
召回层——控制“进来什么”：
问题：召回 50 条，30 条不相关
解法：① 优化 query（多维度改写）② 收紧召回阈值 ③ 加关键词路补充精确匹配
效果：减少噪声进入下游，降低精排压力召回层的控制是成本最低、效果最直接的——垃圾在入口就拦住，比在后面处理便宜得多。
重排层——控制“排在前面的是什么”：
问题：相关文档被召回了，但排在第 8 位，top-3 都是噪声
解法：用 Cross-Encoder 精排，把真正相关的推到前面
效果：精度提升显著，但增加延迟和计算成本重排层解决的是顺序问题，前提是相关文档已经被召回了。如果召回阶段就漏了，重排也救不了。
Agent 规划层——控制“怎么用检索结果”：
问题：top-3 文档质量还行，但信息分散，模型拼出了错误答案
解法：Agent 在使用检索结果前做质量判断——
"这些证据是否足够回答问题？是否有矛盾？需不需要再查一次？"
效果：提升最终回答质量，但增加一轮模型调用规划层是最后一道防线，也是唯一能做“再查一次”决策的地方。
优先级排序：
投入优先级：召回优化（成本低效果大）> ReRank（精度提升明显）> 规划层判断（兜底）先把召回质量做好，再加精排提升排序，最后在 Agent 层做质量兜底。很多团队跳过前两步直接在 Agent 层“让模型自己判断”，这是最贵且最不可靠的做法。
差距在哪：新手只想到 ReRank 一个点。高手从召回、重排、规划三层分别分析了控制方法和投入产出比，且给出了明确的优先级排序。面试官考的是你对 RAG 质量控制的全链路思维。
Q：Agent 场景下，什么时候该做一次检索、多次使用；什么时候该边执行边检索？
来源：Agent 开发面试 30 题
新手答：“复杂问题多查几次。”
高手答：
判断标准是信息需求在任务开始时是否完全可知：
一次检索、多次使用（Retrieve-once）：
适用条件：
- 任务开始时就能确定需要什么信息
- 信息需求不会随执行过程变化
- 检索结果在整个任务周期内有效
典型场景：
- 客服问答：用户问"退货政策是什么"→ 一次检索产品文档，回答完整问题
- 报告生成：给定主题，一次性检索所有相关数据，然后生成报告
- FAQ 类问答：一问一答，信息需求明确优势是延迟低、成本低，只调用一次检索管线。
边执行边检索（Iterative Retrieval）：
适用条件：
- 下一步需要查什么取决于上一步的结果
- 任务目标可能在过程中细化或变化
- 单次检索无法覆盖所有需要的信息
典型场景：
- 故障排查："服务挂了"→ 查架构文档 → 发现依赖 Redis → 查 Redis 变更记录 → 定位根因
- 竞品分析：查到竞品 A 的信息后，发现需要对比的维度，再查竞品 B
- 多跳推理：答案分布在多个文档中，需要逐步追溯优势是信息覆盖全，但延迟和成本成倍增加。
工程上的混合策略：
先做一次广泛的初始检索，如果 Agent 判断信息不足再触发增量检索。设一个检索预算上限（如最多 3 次），避免无限检索。
第一次：广泛检索，覆盖主要信息需求
执行中判断：信息够 → 继续执行。信息不够 → 生成更精确的子查询，再检索一次
最多追加 2 次，超过后用已有信息给出最优答案差距在哪：新手用“复杂度”判断。高手用“信息需求是否可预知”做精确判断，且给出了一次检索和迭代检索的各自适用场景，以及“初始广泛 + 按需增量”的混合策略。面试官考的是你在 RAG 和 Agent 结合时的架构设计能力。
Q：如果 RAG 返回了看似可信但实际过时的信息，你会怎么降低 Agent 被误导的概率？
来源：Agent 开发面试 30 题
新手答：“定期更新知识库。”
高手答：
定期更新是必要的，但更新和检索之间一定有时间差——今天更新的文档可能要到明天才入库，而在这个窗口期内返回的就是过时信息。更根本的问题是：很多文档没有明确的“过期时间”，系统不知道它过时了。
需要多层防线：
第一层：离线端——给文档打时间标签和可信度标签
- 每个 chunk 存储文档创建时间、最后更新时间、来源权威等级
- 有明确时效性的内容（价格、政策、版本号）标记为“时效敏感”
- 建立文档更新监控——源文档变更后自动触发重新入库
第二层：检索端——时间感知的检索和排序
- 检索时对结果按时间新鲜度加权——同等相关性下，新文档排在前面
- 对“时效敏感”标签的 chunk，如果超过 TTL（如 30 天）直接降权或过滤
- 返回结果时附带时间元信息，让 Agent 知道证据的时效性
第三层：Agent 端——生成前做时效性判断
在 Prompt 中明确要求模型：
注意：以下检索结果附带了文档日期。如果信息可能已过时（如价格、政策、版本号），
请在回答中标注"此信息来源于 YYYY-MM-DD 的文档，建议确认是否仍然有效"。模型看到日期后会主动判断时效性，并在回答中加上免责提示。
第四层：用户端——可追溯的引用
回答中附带引用来源和日期，让用户自行判断信息是否过时。这是最后一道防线——即使系统没发现过时，用户看到“来源：2024 年 3 月的文档”也会自己注意。
差距在哪：新手只想到“更新知识库”——这是必要但不充分的。高手从离线（时间标签）、检索（时间加权）、Agent（时效性判断）、用户（可追溯引用）四层构建了防过时信息的完整体系。面试官考的是你对 RAG 系统“证据可靠性”这个核心问题的工程化思考。