很多团队做知识库，一上来就想用 Agentic RAG。 我的判断是：先别急。 普通 RAG 的流程很固定： 用户提问 → 检索一次 → 把资料放进上下文 … · @RwatitFahsa · TwKit

@RwatitFahsa

很多团队做知识库，一上来就想用 Agentic RAG。 我的判断是：先别急。 普通 RAG 的流程很固定： 用户提问 → 检索一次 → 把资料放进上下文 → 模型回答。 它适合公司制度、产品手册、客服 FAQ 这类数据来源明确的问题。流程短，成本低，也容易排查错误。 Agentic RAG 则把检索本身交给智能体。 它可以选择不同工具，搜索文档、数据库、API 或网页；如果证据不够，还会调整关键词、换数据源，再查一次。 它更适合跨系统调查、复杂比较和需要反复验证的问题。 但代价也很直接： 更多模型调用、更高延迟、更难预测的执行路径，以及更复杂的评估和监控。 说简单点： RAG 是把资料交给模型。 Agentic RAG 是让模型自己决定去哪里找、找几次，以及什么时候停止。 需求稳定，先用普通 RAG。 只有当“如何检索”本身也需要推理时，才值得引入 Agent。 复杂不是能力，解决了必要的问题才是。

曝光 155 · 评论 2 · 点赞 3 · 书签 0