看完这张图，我觉得很多人可能一直没有真正理解 RAG 和 Agentic RAG 的区别。 尤其是现在很多人一上来就想做 Agentic RAG，觉得普通 … · @UPing123zzz · TwKit

@UPing123zzz

看完这张图，我觉得很多人可能一直没有真正理解 RAG 和 Agentic RAG 的区别。 尤其是现在很多人一上来就想做 Agentic RAG，觉得普通 RAG 已经过时了，加上 Agent、多轮推理、工具调用，系统就一定会变得更智能。 但实际上，这两种架构解决的根本就不是完全一样的问题。 普通 RAG 的逻辑其实很简单：用户提出问题，系统去知识库检索相关内容，把检索到的证据交给大模型，再由模型生成答案。整个流程相对固定，核心是把正确的信息找出来，让模型基于证据回答。 而 Agentic RAG 最大的不同，就是把一部分检索决策权交给了 Agent。它可以根据用户的问题，决定去哪里检索、调用什么工具、要不要拆分问题，以及第一次检索失败以后，是否需要重新查询或者切换数据源。 举个例子，用户问一家公司的报销制度，普通 RAG 可能检索几份相关文档就能回答。但如果用户问的是：今年的报销政策相比去年发生了哪些变化？哪些部门受到了影响？有没有特殊审批流程？ 这时候系统可能就需要查询不同版本的制度，确认生效时间，检索多个部门的规定，甚至调用内部业务系统，最后再把这些证据整合起来。这才是 Agentic RAG 更适合发挥作用的地方。 但我觉得最值得警惕的一件事，就是很多开发者正在把 Agentic RAG 当成一种技术炫耀。 明明一个普通的混合检索加 Rerank 就能解决的问题，非要加上好几个 Agent，让它自己规划、自己检索、自己评估、自己重试。 结果架构越来越复杂，Token 消耗越来越高，响应越来越慢，系统甚至还可能因为错误的规划而检索到不相关的信息。 我自己最近一直在研究企业级 RAG，也越来越发现，真正困难的地方往往不是选什么框架，而是文档解析、权限隔离、增量同步、版本管理、检索质量、证据引用，以及怎么通过 Evals 去验证系统到底有没有回答正确。 这些基础工程没有做好，就算给 RAG 套上十层 Agent，也不代表它能可靠地进入生产环境。 所以我现在有一个越来越明确的判断：能用普通 RAG 解决的问题，就不要为了 Agent 而 Agent。只有当任务真的需要动态规划、多步检索、跨数据源查询和工具协作时，再考虑 Agentic RAG。 真正优秀的 AI 工程师，不是能把系统设计得多复杂，而是知道什么时候应该使用复杂的系统，什么时候应该保持简单。 技术架构从来不是越高级越好，而是谁能以更低的成本、更稳定的方式，把真实问题解决掉。 这才是我认为企业 AI 落地最应该坚持的工程思维。

曝光 327 · 评论 1 · 点赞 4 · 书签 1