Agent+RAG

1. 为什么要把 Agent 和 RAG 放在一起

RAG 解决的是“模型不知道”。

Agent 解决的是“模型不知道该怎么连续做事”。

两者结合后，系统才能同时具备：

• 获取外部知识的能力
• 根据知识推进任务的能力

2. 两者各自负责什么

RAG 负责

• 从外部知识库中找相关信息
• 把相关上下文送给模型
• 降低幻觉
• 让回答覆盖私有知识和最新知识

Agent 负责

• 拆解目标
• 决定何时检索
• 决定检索什么
• 决定是否继续执行其他工具
• 在中间结果不足时追加检索

3. 为什么“只做 RAG”通常不够

只做基础 RAG 时，常见流程是：

用户问题 -> 检索 -> 拼接上下文 -> 生成答案

这适合单轮问答，但一旦任务变成：

• 先查资料再做分析
• 先对比多份文档再生成报告
• 先检索事实再调用工具执行

单轮 RAG 就不够了。

这时需要 Agent 来决定：

• 检索几次
• 用什么查询词
• 是否需要重写查询
• 是否需要换数据源
• 是否要结合其他工具继续处理

4. 一个典型 Agent+RAG 流程

用户目标
  -> Agent 拆解任务
  -> 发起第一次检索
  -> 读取检索结果
  -> 判断信息是否足够
  -> 不够则重写查询再次检索
  -> 足够则进入分析 / 生成 / 执行
  -> 输出结果并附带引用

5. 关键设计点

5.1 检索不是一次性的

很多任务需要多轮检索：

• 初检索：找到大方向
• 深检索：补关键细节
• 验证检索：交叉确认事实

5.2 Agent 不应该直接吃完整知识库

RAG 的价值在于“先过滤再生成”。

如果把大批无关材料直接塞给模型，会带来：

• 成本上升
• 噪声变多
• 关键信息被淹没

5.3 检索质量决定上限

常见影响项：

• chunk 切分方式
• embedding 模型
• top-k 设置
• rerank
• metadata 过滤
• 查询重写

6. 常见架构模式

6.1 Retrieve-then-Read

先检索，再让模型阅读。

优点：简单、便宜。

缺点：对复杂任务不够灵活。

6.2 Agentic RAG

由 Agent 动态控制检索步骤。

优点：

• 更适合复杂任务
• 可以多跳检索
• 可以中途换策略

缺点：

• 成本更高
• 调试更复杂

6.3 RAG + Tool Chain

检索后不直接回答，而是：

• 先检索
• 再计算
• 再写报告
• 再写入系统

这种模式更接近业务系统而不是聊天机器人。

7. 评测 Agent+RAG 时要看什么

不要只看最终答案是否像样，还要拆开看：

• 检索召回是否正确
• 引用是否对应原文
• 是否使用了错误来源
• Agent 是否进行了无效重复检索
• 总步数是否合理
• 成本是否可接受

8. 典型失败模式

• 检索到了不相关片段
• 检索到了相关片段，但拼接顺序差
• Agent 没意识到信息不足，直接生成
• Agent 反复检索同样内容，陷入空转
• 引用存在，但结论并不被引用支持

9. 实践建议

从简单开始

先做：

• 单轮检索
• 固定模板回答
• 引用可追踪

再逐步加入：

• 查询重写
• 多轮检索
• rerank
• agent 控制循环

保留中间产物

建议保留：

• 原始 query
• 重写后的 query
• 检索结果
• 采用的片段
• 最终引用

否则很难调优。

10. 一句话总结

Agent+RAG 的本质是：让模型在执行任务时，按需获取外部知识，而不是只靠参数记忆硬答。