RAG 到底是什么 RAG的目标、局限和适用场景

第一节 Agentic RAG 的目标、局限和适用场景​

​

本节目标：先不急着搭 Agent，而是回答一个更重要的问题：Agentic RAG 到底解决什么问题、不能解决什么问题、什么时候值得用、什么时候普通 RAG 就够了。​

​

​

1.为什么要讨论 Agentic RAG​

很多人第一次接触 RAG 时，会形成一个很自然的理解：​

​

代码块​

Plain Text

只要把企业文档放进知识库，大模型回答时就不会乱说。​

​

这只对了一半。​

普通 RAG 确实比纯大模型问答可靠，因为它把外部知识检索出来，作为模型 回答的上下文。但普通 RAG 仍然有一个核心缺陷：​

​

代码块​

Plain Text

检索到了内容，不等于检索内容足以回答问题。​

​

例如企业知识库里只有火电厂设备运维资料，用户问：​

​

代码块​

Plain Text

2026 年火星的天气如何？​

​

​

🔔

•

普通 RAG 可能仍然召回包含“温度、压力、风量”的火电厂片段。模型看到上下文后，为了完成回答任务，可能开始把不相关资料包装成答案。​

•

企业场景里，这类问题尤其危险。因为用户不是在和一个娱乐聊天机器人对话，而是在查询制度、流程、设备、合规、安全操作或生产经验。​

​

这时系统最重要的能力不是“尽量回答”，而是：​

​

代码块​

Plain Text

能回答时准确回答；​

不能回答时可靠拒答；​

问题不清时先追问；​

证据不足时不编造；​

高风险问题进入更保守的流程。​

​

Agentic RAG 的价值，就在这里。​

2.普通 RAG 的基本流程​

普通 RAG 通常是一个固定管道：​

​

​

它适合处理这样的问题：​

​

代码块​

Plain Text

给煤机皮带跑偏常见原因有哪些？​

​

​

如果知识库里确实有给煤机检修规程，普通 RAG 可以召回相关片段，然后回答：​

​

​

🔔

•

头尾滚筒不平行；​

•

托辊卡涩；​

•

皮带接头偏斜；​

•

张紧力不均；​

​

这类问题有几个特点：​

​

​

在这种场景下，普通 RAG 已经够用。​

3.普通 RAG 在企业场景中的能力边界​

​

普通 RAG 的问题不是“不能用”，而是它默认所有问题都适合走同一条链路。​

​

​

​

​

但企业问题不是同一种类型。​

​

​

​

普通 RAG 最大的问题可以总结为四个。​

​

3.1 它不知道问题该不该检索​

用户问：​

​

代码块​

Plain Text

你好，你能做什么？​

​

​

其实不需要检索知识库，直接说明能力范围即可。​

但普通 RAG 可能仍然去知识库里找“你好”或“能力范围”，浪费成本，也可能召回无关片段。​

​

​

3.2 它不知道检索结果能不能用​

用户问：​

​

代码块​

Plain Text

苹果公司的股价今天是多少？​

​

​

知识库里如果有“给水泵电流、发电机有功、厂用电电压”等内容，向量检索可能召回一些“数值、指标、公司”相关片段。​

普通 RAG 不一定知道这些片段无法回答股价问题。​

​

​

3.3 它不擅长处理模糊问题​

用户问：​

​

代码块​

Plain Text

振动高怎么办？​

​

​

🔔

这至少需要补充：​

•

是磨煤机、风机、给水泵，还是汽轮机？​

•

是缓慢升高还是突增？​

•

是否达到保护动作值？​

•

用户要运行处置建议，还是检修检查建议？​

​

​

普通 RAG 可能直接召回一堆振动相关片段，然后拼成一个“看似全面、实际不够精准”的答案。​

​

​

3.4 它对高风险问题缺少流程控制​

用户问：​

​

代码块​

Plain Text

保护信号能不能先短接，等运行稳定后再说？​

​

这不是普通知识问答，而是高风险合规问题。系统应该强制进入安全流程：​

​

代码块​

Plain Text

识别高风险 -> 检索制度 -> 明确禁止事项 -> 要求审批和人工确认​

​

不能只靠一句“请注意安全”的提示词 。​

4.Agentic RAG 到底是什么​

RAGFlow 官方文章把 Agentic RAG 描述为一种通过动态 Agent 编排增强 RAG 的方式。它不再只是一次检索和一次生成，而是让系统可以：​

​

🔔

•

批判检索结果；​

•

根据用户意图改写查询；​

•

处理多跳推理；​

•

根据不同问题选择不同流程；​

•

调用工具或子流程；​

​

RAGFlow官方文档对中Agentic RAG的定义:​

​

​

可以把普通 RAG 和 Agentic RAG 的概要流程对比成这样：​

​

​

所以 Agentic RAG 不是一个单独节点，而是一种工作流 思想：​

​

代码块​

Plain Text

把判断、检索、评分、改写、工具调用、追问、拒答和回答组织成可执行流程。​

​

5.Agentic RAG 的目标​

​

​

6.应用效果能提高到什么程度​

Agentic RAG 的效果提升不是平均发生在所有问题上，而是集中在特定问题类型上。​

​

​

结论很直接：​

​

代码块​

Plain Text

如果问题简单、答案固定、风险低，普通 RAG 或 FAQ 就够了。​

如果问题复杂、风险高、证据不足时不能乱答，Agentic RAG 才有明显价值。​

当然Agentic RAG的绝对价值必须要评测集来进行评估。​

​

7.Agentic RAG 的局限​

Agentic RAG 不是万能药。它引入了控制能力，也引入了复杂度。​

​

​

因此，Agentic RAG 的正确使用方式不是“所有问题都走复杂 Agent”，而是：​

​

代码块​

Plain Text

只把确实需要判断、追问、评分、重试和工具调用的问题送入 Agentic 流程。​

​

8.适用场景​

​

​

9.不适合或不优先使用的场景​

​

​

10.Agentic RAG在不同业务情景下的可替代方案​

Agentic RAG 不是唯一方案。实际选型时可以这样看。​

​

​

11.推荐的企业分层架构​

不要让所有问题都进入复杂 Agentic RAG。更实用的架构是分层。​

​

​

​

🔔

​

这样做的好处是：​

​

•

简单问题保持低成本、低延迟；​

•

复杂问题才进入复杂编排；​

•

高风险问题有独立安全边界；​

•

知识库外问题不会被硬答；​

•

后续可以逐步评估和扩展。​

​

12.软件架构师判断是否值得使用 Agentic RAG​

可以用下面的决策表。​

​

​

13.Agentic RAG / Self-RAG / Adaptive-RAG:​

•

Agentic RAG 是总概念，解决“把判断、检索、工具、反思、回答编排成一个可执行流程”。​

•

Self-RAG 是一种“检索后反思”的 Agentic RAG， 解决“查到的资料能不能用”。​

•

Adaptive-RAG 是一种“先分析问题，再选择策略”的 Agentic RAG，解决“这个问题该走哪条路”。​

•

Self-RAG 和 Adaptive-RAG 不是互斥关系。实际企业方案通常会把两者组合起来：​

•

Adaptive-RAG：先判断问题类型​

•

Self-RAG：检索后判断证据是否足够​

•

Agentic RAG：把这些节点编排成完整流程​

14.本节结论​

Agentic RAG 的目标不是让系统“更爱回答”，而是让系统更会判断：​

​

代码块​

Plain Text

​

这个问题该不该答？​

应该查哪里？​

查到的证据够不够？​

不够时要追问、改写、重试、搜索，还是拒答？​

高风险时是否必须走保守流程？​

​

最重要的判断是：​

​

代码块​

Plain Text

​