RAG和Agent是什么关系？都有Agent了还要RAG吗？
本文目录
30秒版回答
RAG 解决的是模型不知道的知识怎么补进来；Agent 解决的是任务怎么分步骤自主完成。一个是能力，一个是架构，不是替代关系。
传统 RAG 是固定流程：问题进来 → 检索一次 → 拼上下文 → 生成。它的问题是不会追问、不会换个方式再查、不会判断检索结果够不够。
Agentic RAG 把检索变成 Agent 的一个工具：模型可以改写问题、分多次检索、在知识库和数仓之间选择数据源、判断证据不足时继续查。
选型上：问题类型单一、知识库稳定、对延迟敏感的，固定 RAG 更合适；需要多跳推理、跨数据源、问题开放的，才用 Agentic RAG。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
面试官：「你们之前做过 RAG，现在大家都在做 Agent。你觉得 RAG 和 Agent 是什么关系？有了 Agent 之后，RAG 是不是就过时了？」
这道题很有迷惑性。网上有“RAG 已死”的说法，也有“Agentic RAG 才是未来”的说法，候选人很容易被带偏，要么全盘否定 RAG，要么说不清两者的边界。
我的观点很明确：RAG 是一种能力（给模型补充外部知识），Agent 是一种架构（让模型自主决策和行动）。两者不是替代关系——在 Agent 里，检索通常就是它最常用的工具之一。变化的是：检索从“固定的一步”变成了“模型按需调用的工具”。
面试官在考什么
• 能否分清能力和架构，不被“XX 已死”之类的说法带偏。
• 是否理解传统 RAG 的局限：一次检索、固定 TopK、无法多跳推理、检索失败无法自我纠正。
• 是否知道 Agentic RAG 的做法：查询改写、多轮检索、自我评估、按需选择数据源。
• 能否给出选型判断：什么时候固定 RAG 就够了，什么时候需要 Agentic。
展开一：传统 RAG 的流程和局限
传统 RAG（一次检索，固定流程）
用户问题 → Embedding → 向量/关键词检索 TopK → 重排 → 拼接上下文 → 模型生成
局限：
1. 只检索一次：第一次没查到，就只能硬答或拒答
2. 不会拆问题："A 产品和 B 产品去年退货率谁高" 需要查两次再比较
3. 数据源单一：只能查文档，不能顺便查数仓里的真实数字
4. 不判断证据是否充分：检索到不相关内容也会塞给模型这四个局限，本质都是因为流程是写死的。这也正是第 01 题讲的 Workflow 和 Agent 的区别在 RAG 场景的体现。
展开二：Agentic RAG 怎么做
Agentic RAG 的核心是把“检索”封装成工具，交给 Agent 按需调用。常见的增强点有四个：
| 增强点 | 做法 | 解决什么问题 |
|---|---|---|
| 查询改写 | 把口语化问题改写成更适合检索的关键词或子问题 | 用户问法和文档写法不一致 |
| 多跳检索 | 先查 A 得到中间结论，再基于结论查 B | 需要多步推理的问题 |
| 数据源路由 | 根据问题选知识库、数仓、API 或网页 | 文档里没有实时数字 |
| 自我评估 | 检索后先判断证据是否足够，不够就换关键词再查 | 首次检索质量差 |
# Agentic RAG：检索是工具，由 Agent 决定查什么、查几次、查哪里
tools = [
tool("search_docs", "检索产品文档、制度、SOP，返回带出处的段落"),
tool("query_metric", "查询指标平台的标准指标，如退货率、GMV"),
tool("run_readonly_sql", "复杂分析时执行只读 SQL，必须带分区条件"),
]
system = """回答必须基于工具返回的证据，并给出出处。
如果证据不足，先改写关键词再检索，最多 3 次；仍不足则明确说不知道。
涉及数字时优先使用 query_metric，不要从文档里摘抄过期数字。"""
answer = run_agent(goal=user_question, tools=tools,
system=system, max_steps=6)注意 system 里的最后一句——“涉及数字时优先查指标平台，不要从文档里摘抄过期数字”。这是数据人特有的视角：文档里的数字往往是某个时间点的快照，真正的数字在数仓里。
展开三：两种方案的取舍
| 维度 | 固定 RAG | Agentic RAG |
|---|---|---|
| 延迟 | 低且稳定（一次检索 + 一次生成） | 高且波动（多次检索 + 多次推理） |
| 成本 | 可预估 | 随步数变化，可能是固定 RAG 的数倍 |
| 复杂问题能力 | 弱：单跳、单源 | 强：多跳、多源、可自我纠错 |
| 可控性 | 高，容易测试和评估 | 较低，需要完整 Trace 和评测集 |
| 适合场景 | FAQ、客服、制度问答 | 研究分析、跨系统排查、开放式问数 |
实际项目里我更推荐分层路由：先用一个轻量分类判断问题复杂度，简单问题走固定 RAG，复杂问题才进 Agentic 流程。这样大部分请求享受低延迟低成本，少数复杂请求享受更强能力。
展开四：为什么说 RAG 不会过时
“上下文窗口越来越长，RAG 就没必要了”——这是面试官很喜欢抛出来试探的说法。我的回答是：长上下文可以减少对切分精度的依赖，但解决不了以下问题：
• 规模：企业知识库动辄几十万、上百万文档，不可能每次都塞进上下文。
• 成本和延迟：每次请求都带几十万 Token，成本和延迟都不可接受。
• 权限：不同用户能看的文档不同，必须在检索阶段过滤，而不是全塞进去再让模型“别说”。
• 新鲜度和可追溯：文档更新后需要快速生效，回答需要给出处，这些都依赖检索链路和索引治理。
所以准确的说法是：RAG 的形态在演进，从固定流水线变成 Agent 的工具；但“按需、按权限、可追溯地取外部知识”这个需求不会消失，而这条链路恰恰是数据开发最擅长的部分。
典型场景：问数助手只查文档，答出了过期数字
一个常见的翻车：公司做了一个内部知识问答助手，知识库里有大量周报、月报文档。业务问“上个月华东区退货率是多少”，助手从某份月报里检索到一个数字直接回答了。问题是：那份月报是两个月前的，而且退货率口径后来还调整过。
改进方案就是 Agentic 化：给助手同时挂文档检索和指标查询两个工具，并在系统提示里规定“数字类问题必须查指标平台”。文档检索负责回答“退货率口径是什么、为什么上升”这类解释性问题，指标平台负责给出准确数字。一个讲“为什么”，一个讲“是多少”，各司其职。
追问链
追问一：Agentic RAG 延迟太高，线上怎么优化？
几个方向：一是分层路由，大部分简单问题不进 Agent；二是并行检索，多个子问题或多个数据源同时查，而不是串行；三是限制步数，比如最多 3 轮检索；四是缓存，高频问题的检索结果和中间结论可以缓存，但要注意权限维度和数据更新后的失效。
追问二：怎么评估 Agentic RAG 比固定 RAG 好？
不能只看最终答案的好坏，要用同一份评测集对比几项：答案正确率、引用正确率、拒答准确率（该说不知道时有没有说）、平均和 P95 延迟、单次成本。复杂问题子集上 Agentic 应该明显更好，简单问题子集上两者应该持平；如果简单问题上 Agentic 反而更差，说明路由或提示词有问题。详细的评估方法在第 11 题展开。
追问三：GraphRAG 你了解吗？什么时候用？
GraphRAG 是先从文档里抽取实体和关系构建知识图谱，检索时结合图结构，适合需要全局归纳或者实体关系推理的问题，比如“这批合同里涉及哪些供应商、彼此什么关系”。代价是构建成本高，图谱需要随文档更新维护。普通的事实问答用向量 + 关键词混合检索就够了，没必要上图。
加分说法 vs 减分说法
| ✔ 加分说法 | ✘ 减分说法 |
|---|---|
| RAG 是能力，Agent 是架构，不是替代关系 | RAG 已经过时了 |
| Agentic RAG：检索变成工具，按需改写、多跳、路由 | 上下文够长就不需要检索 |
| 分层路由：简单问题走固定 RAG，复杂问题进 Agent | Agentic RAG 一定比固定 RAG 好 |
| 数字类问题查数仓/指标平台，不从文档摘抄 | 只讲向量检索，不提权限和更新 |
| 长上下文解决不了规模、成本、权限、新鲜度 | 说不清两者的边界 |
怎么挂到你的项目上
话术模板：“我们的知识问答一开始是固定 RAG，后来发现数字类问题经常答出过期值。我们把它改成了检索 + 指标查询双工具的模式，文档负责解释口径和原因，数字统一从指标平台取。同时做了分层路由，简单问题仍然走固定流程，保证大部分请求的延迟。”
总结
这道题一定要先摆明立场：RAG 是能力，Agent 是架构。然后讲清楚传统 RAG 为什么不够、Agentic RAG 怎么增强、两者怎么选。最后用“文档讲为什么，数仓讲是多少”收尾，把数据开发的视角带进去，就是一个有观点、有深度的回答。
下一篇聊一个所有数据人都关心的问题：Agent 时代，数据开发会被取代吗？面试官问这个问题时，到底想听什么？
你觉得 RAG 未来会被什么替代吗？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长