Agent与RAG的常见结合模式有哪些

1️⃣ 考察意图

面试官想考察你对 Agent 与 RAG 集成模式的系统性认知，而非简单背诵概念。这是系统设计 + 工程取舍型题目，刁钻点在于：多数候选人只知“Agent 调用检索工具”这一种模式，缺乏对迭代、自适应、记忆增强等变体的理解，更无法给出场景化的选型依据。答好了能展示你对 Agent 决策流程、检索成本控制、记忆管理三者的深度耦合能力，以及从论文（如 Self-RAG、FLARE）到落地的实战经验。

2️⃣ 标准答

Agent 与 RAG 的结合本质是将检索作为 Agent 的一项工具或决策环节，常见模式有四种，按复杂度递增排列：

**简单 RAG（Tool-Calling RAG）**Agent 将检索视为一个独立工具（如 retrieve(query)），在需要外部知识时直接调用。
实现：定义 OpenAI Function Calling 或 LangChain Tool，输入用户问题，输出检索到的文档片段。
适用：单轮问答、事实性查询（如“2024 年诺贝尔物理学奖得主是谁？”）。
坑：Agent 可能过度依赖检索，忽略自身推理能力。解法：给工具加 description 限制触发条件，如“仅当问题需要最新/外部知识时调用”。
Trade-off：简单高效，但无法处理需要多步推理的复杂问题（如“对比 RAG 和微调在问答中的优劣”）。
**迭代 RAG（Iterative RAG / ReAct + RAG）**Agent 在推理过程中多次调用检索，根据前一次结果决定下一步行动。典型框架是 ReAct（Reasoning + Acting）。
流程：Agent 输出思考 → 检索 → 整合 → 再思考 → 再检索，直到生成最终答案。
论文参考：Self-RAG（通过反射 token 决定是否检索）、FLARE（主动预测缺失信息并检索）。
适用：复杂推理任务（如多跳问答、代码生成需查 API 文档）。
坑：检索次数失控导致高延迟和成本。解法：设置最大迭代次数（如 3 轮），或引入“置信度阈值”——当 Agent 对当前答案的置信度 > 0.8 时停止检索。
Trade-off：准确率提升 15-30%（通用知识），但每次检索增加 200-500ms 延迟。
**自适应 RAG（Adaptive RAG）**Agent 动态决定是否检索、检索什么、检索多少次，而非固定流程。
实现：训练一个“检索决策器”（如小型分类器或 LLM 自身），根据问题复杂度输出 retrieve / no-retrieve / decompose 等动作。
论文参考：Adaptive RAG（2024，通过分类器判断问题类型）、CRAG（Corrective RAG，检索后验证质量，低质量则重写查询）。
适用：资源敏感场景（如移动端、API 调用计费），或问题复杂度分布不均的混合场景。
坑：决策器本身可能误判，导致该检索时未检索。解法：采用“保守策略”——默认检索，仅当问题明显简单（如“你好”）才跳过；或使用 LLM-as-Judge 二次验证。
Trade-off：灵活性高，但设计复杂度增加 2-3 倍，且决策器需要额外训练数据。
**记忆增强 RAG（Memory-Augmented RAG）**Agent 将历史检索结果存入短期或长期记忆，供后续对话复用。
实现：用向量数据库（如 Chroma）存储检索结果，并关联对话 ID；Agent 在每次检索前先查询记忆，命中则直接返回。
适用：多轮对话（如客服系统，用户连续追问同一主题）、长文档分析（如法律合同审查）。
坑：记忆污染——旧检索结果可能过时。解法：给记忆加时间戳，超过 TTL（如 1 小时）自动过期；或每次检索后更新记忆。
Trade-off：减少重复检索 40-60%（通用知识），但增加存储开销和记忆管理逻辑。

选型建议：

任务简单、实时性高 → 简单 RAG
需要多步推理 → 迭代 RAG
成本敏感、问题多样 → 自适应 RAG
多轮对话、知识复用 → 记忆增强 RAG实际落地常混合使用，例如：自适应 RAG 做顶层决策，内部用迭代 RAG 处理复杂子问题，记忆增强 RAG 缓存中间结果。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从四种常见模式、适用场景和工程取舍三个层面回答。第一，简单 RAG 是 Agent 直接调用检索工具，适合单轮问答；第二，迭代 RAG 通过 ReAct 循环多次检索，适合复杂推理；第三，自适应 RAG 用决策器动态控制检索，适合资源敏感场景；第四，记忆增强 RAG 缓存历史结果，适合多轮对话。总结一句：选型取决于任务复杂度、实时性要求和成本预算，实际落地常混合使用。”

4️⃣ 高频追问 & 应对

追问 1：你提到自适应 RAG 的决策器，具体怎么训练？用什么数据？

决策器可以用一个小型分类器（如 BERT-base）或 LLM 自身。训练数据来自人工标注：对每个问题打标签（retrieve / no-retrieve / decompose），标签依据是问题是否包含实体、是否需要外部知识。也可以用弱监督方法：先用简单 RAG 跑一批数据，如果检索结果与答案匹配度低，则标记为需要 decompose。实际落地中，我更倾向用 LLM 做决策（如 GPT-4o-mini），因为零样本泛化性好，但成本高；分类器成本低但需要持续更新。Trade-off 是准确率 vs 成本。

追问 2：迭代 RAG 中，如何避免 Agent 陷入死循环（不断检索但不出答案）？

设置硬性限制：最大迭代次数（如 5 轮）、超时时间（如 10 秒）。更优雅的解法是引入“终止条件”：当 Agent 连续两次检索结果相似度 > 0.9 时，强制终止并输出当前答案。另外，可以在 prompt 中加指令：“如果检索结果无法帮助回答，请基于已有知识给出最佳猜测，并标注不确定性。” 这借鉴了 Self-RAG 的反射机制。

追问 3：记忆增强 RAG 中，如何管理记忆的容量和优先级？

用 LRU（最近最少使用）策略淘汰旧记忆，或设置最大条目数（如 1000 条）。优先级方面，可以给记忆加“重要性分数”，由 Agent 在存储时评估（如“这个检索结果对当前问题贡献度 0.8”），检索时按分数排序。实际坑是：记忆可能被无关对话污染，所以需要按对话 session 隔离，或者用 embedding 相似度做去重。

5️⃣ 避坑 · 常见错误答法

❌ 只提“Agent 调用 RAG 工具”一种模式，忽略迭代、自适应等变体。→ ✅ 至少列举 3 种模式，并给出每种模式的论文或框架名（如 ReAct、Self-RAG、CRAG）。
❌ 说“自适应 RAG 最好，因为它最智能”，没有 trade-off 分析。→ ✅ 明确指出自适应 RAG 的设计复杂度高、决策器可能误判，并给出“保守策略”等解法。
❌ 把记忆增强 RAG 和简单 RAG 混为一谈，认为“记忆就是缓存”。→ ✅ 区分短期记忆（对话内）和长期记忆（跨对话），并讨论 TTL 过期、去重等工程细节。

6️⃣ 简历呼应

如果你有 RAG 项目：从“我在项目中实现了迭代 RAG 模式，用 ReAct 框架处理多跳问答，准确率提升 20%”切入，并提到你如何控制检索次数（如设置置信度阈值）。
如果你只做过传统 NLP：用“传统 QA 系统的流水线 vs Agent 的决策循环”类比，强调 Agent 让检索从被动变为主动，并引用 Self-RAG 论文作为理论支撑。
如果你是校招无项目：聚焦“我复现了 Adaptive RAG 论文中的决策器，用 BERT 分类器在 HotpotQA 上测试，发现准确率 85%”，并讨论分类器误判的 case study。
Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (2023)
FLARE: Active Retrieval Augmented Generation (2023)
Adaptive RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity (2024)
CRAG: Corrective Retrieval Augmented Generation (2024)
LangGraph 官方文档：Agent 与 RAG 集成模式示例

—— 本场面试完 ——