布吉岛 Agent

Appearance

1.1.4 哪些场景适合用 RAG，哪些场景不适合？ ​

RAG 很有用，但不是所有大模型应用都应该上 RAG。

判断是否适合，最关键的不是看“这个技术火不火”，而是看你的问题是否真的依赖外部知识检索。

RAG 适用场景判断

哪些场景适合用 RAG ​

适合用 RAG 的场景，通常有一个共同点：回答时必须参考外部资料，而且这些资料对答案质量影响很大。

常见场景包括：

1. 基于知识库的问答 ​

比如企业内部文档问答、产品手册问答、帮助中心问答、FAQ 助手。

这类场景里，答案本来就应该建立在已有资料之上。RAG 能把这些资料接入进来，让系统不是凭感觉说话。

2. 依赖私有数据的场景 ​

比如公司流程、内部规范、售后记录、客户文档、项目资料、代码仓库说明。

这类内容不在模型通用训练语料里，所以不接外部知识，系统就没有真正可用的信息基础。

3. 知识经常变化的场景 ​

比如政策更新、产品版本更新、库存和价格变化、规则频繁调整。

这类场景中，如果你希望系统尽量跟上最新资料，RAG 通常比“把知识写死在模型里”更现实。

4. 希望答案可追溯、可引用的场景 ​

比如医疗、金融、法律、企业知识系统、面向客户的专业问答。

这类场景中，用户往往不仅关心答案是什么，还关心答案依据是什么。RAG 更容易和引用来源、证据链、人工复核结合。

5. 问题本身像“先找资料，再组织答案” ​

还有一类很适合 RAG 的问题，判断方式很直接：

如果你让一个专业人员来回答，他也会先去：

  • 查制度
  • 查手册
  • 查 FAQ
  • 查项目文档

然后再把信息组织成答案

那这类问题通常就很适合 RAG。

因为它的本质，本来就是“基于现有资料回答”，而不是“凭脑内规则直接执行”。

哪些场景不一定适合用 RAG ​

有些问题看上去也在用大模型，但核心并不在“查资料”，这时 RAG 可能不是重点，甚至会增加不必要的复杂度。

1. 主要是行为类任务，而不是知识类任务 ​

比如：

  • 文案改写
  • 风格模仿
  • 分类打标签
  • 情感分析
  • 固定格式抽取

这类任务更关注模型“怎么做”，而不是“去哪里查资料”。如果外部知识不是关键依赖，RAG 通常不会带来决定性收益。

2. 输出高度固定、规则明确的任务 ​

如果一个任务本质上更像规则系统、表单校验或工具调用编排，那么直接用程序规则、工作流、结构化约束往往更稳。

RAG 可以补充背景知识，但不一定应该成为主方案。

3. 问题不依赖外部知识，只依赖模型通用能力 ​

比如基础翻译、文本润色、标题生成、摘要改写等。

这类任务即使接了检索，很多时候也不会带来明显收益，反而会让链路更长、成本更高。

4. 需要极强确定性的场景 ​

如果一个问题必须严格按规则输出，不允许自由生成，那就不能只依赖 RAG。因为 RAG 本质上仍然是“检索 + 生成”，而生成天然带概率性。

这时更合理的做法通常是：

  • 规则系统
  • 工具调用
  • 数据库查询
  • 工作流编排

把 RAG 放在辅助位置，而不是核心执行位置。

5. 本质上是“查状态”而不是“查知识”的问题 ​

比如：

  • 这张订单现在是什么状态
  • 这个用户今天有没有下单
  • 当前库存还剩多少
  • 这个审批单是谁卡住了

这类问题看起来也像“问答”，但底层更像：

  • 数据查询
  • 实时状态读取
  • 工具调用

如果把这类问题一股脑做成 RAG，系统反而容易变慢、变贵，还更不稳定。

更合理的做法通常是：

  • 先查数据库或业务系统
  • 必要时再用 RAG 补背景解释

一个更有操作性的判断框架 ​

很多时候，读者真正难的不是“听懂这些原则”，而是遇到一个新问题时，不知道到底该怎么选。

更实用的判断方式，是先把问题分成下面四类：

第一类：我要找资料，但想自己判断 ​

这类更像：

  • 搜索
  • 搜索结果页
  • 文档导航

重点是“把资料找出来”，而不是“系统替你下结论”。

第二类：我要基于资料，直接得到一个答案 ​

这类更像：

  • RAG
  • 知识库问答
  • 检索增强回答

重点是“先找到证据，再组织答案”。

第三类：我要查一个确定状态或执行一个确定动作 ​

这类更像：

  • 数据库查询
  • API 调用
  • 工作流
  • 工具调用

重点是“拿到确定结果”或“完成确定动作”，而不是生成一段自然语言。

第四类：我要完成一个多步目标 ​

这类更像：

  • Agent
  • Workflow + Agent
  • 多工具协作系统

重点是“规划、决策、调用工具、根据中间结果继续往下做”。

为什么很多场景会被误判成“适合上 RAG” ​

最常见的误判有三种：

1. 只要是问答界面，就以为应该上 RAG ​

但问答界面只是一种交互形式，不代表底层问题一定是知识检索问题。

有些问答界面背后真正需要的是：

  • 实时数据库查询
  • 工具执行
  • 流程审批

2. 只要有文档，就以为文档一定该进 RAG ​

但如果用户真正关心的是当前实时状态，文档往往只是背景资料，不是主答案来源。

3. 只要模型回答不稳定，就下意识加 RAG ​

但如果问题本质上是：

  • 格式控制
  • 行为稳定
  • 确定性执行

那更合理的方向可能是规则、工具、工作流或微调，而不是先加检索。

一种实用判断方式 ​

遇到一个新场景时，可以先问自己四个问题：

  1. 回答是不是必须依赖外部资料？
  2. 这些资料是不是会变化？
  3. 这些资料是不是模型默认拿不到？
  4. 用户是不是很在意答案的依据和可核验性？

如果这四个问题里，大多数答案都是“是”，RAG 往往值得认真考虑。

如果大多数答案都是“否”，那就要警惕自己是不是把 RAG 用成了默认答案。

如果你还想再判断得更稳一点，可以再追问两个问题：

  1. 这个问题的答案更像“知识说明”，还是“实时状态”？
  2. 即使没有大模型，这个问题本来是不是也会先去查资料？

这两个问题往往能帮你把“RAG 问题”和“查询 / 工具 / 工作流问题”更快分开。

不要把“适合”理解成“只能” ​

最后要注意，适合与不适合，不是绝对二元判断。

很多系统都是组合方案：

  • 用 RAG 解决知识接入
  • 用规则或工具解决确定性执行
  • 用微调解决格式和行为稳定性

真正成熟的设计，通常不是“什么都交给 RAG”，而是把 RAG 放在它最擅长的位置上。