P1-14.2 RAG 与工具使用的位置¶
Section ID:
P1-14.2Version:v2026.07.23
在 P1-14.1 中，我们把 AI 服务看成 模型(model)、应用(application)、数据(data)、工具(tool)、编排(orchestration) 的组合。接下来要区分其中两个最容易混淆的部分。
RAG：
找到外部资料，并把它接到模型输入上下文里。工具使用(tool use)：
调用模型之外的系统来查询信息或执行动作。
它们看起来都像是在“使用模型外部的东西”，但角色并不相同。
RAG 是把回答所需资料引入模型上下文的结构，
工具使用则是调用外部系统功能的结构。
这里会把两种结构摆在一起比较，并说明它们分别处在 AI 服务的什么位置。
Part 1 会在这里建立 RAG、工具使用(tool use)、检索(retrieval)、工具调用(tool call)、审批(approval) 的基本区分。13.3 已经把 RAG 先介绍成“把检索结果贴到生成输入”的结构，14.1 又把视角放大到完整服务。这一节会把两条脉络接起来，回答：
在一个服务里，RAG 和工具使用到底分别站在什么位置？
先把最容易混在一起的三个词固定下来：
| 区分 | 一句话基准 | 最接近的角色 |
|---|---|---|
| RAG | 找外部文档并贴到模型上下文 | 阅读与依据补强 |
| 工具使用(tool use) | 调用外部系统功能来查询或行动 | 执行与外部连接 |
| agent | 为了目标，把 RAG 与工具使用串成多步流程 | 工作流与状态管理 |
这张表最重要的点是：RAG、工具使用、agent 可以互相配合，但它们不是同一个概念。这一节先把 阅读 与 执行 分开，而“把多个步骤持续串起来”的 agent 结构会在紧接着的 P1-14.3 再展开。
这里比较 RAG 与工具使用在服务中的位置。更完整的 agent 结构放到 P1-14.3，MCP 等连接标准放到 P1-14.4，harness、评估、执行日志放到 P1-14.5。
RAG、工具使用、检索、工具调用、审批 分别对应不同的阅读、执行与控制步骤。
| 术语 | 极简含义 | 本节中的作用 |
|---|---|---|
| RAG | 找到外部资料并把它贴到输入上下文的结构 | 连接依据资料的代表方式 |
| 工具使用 | 调用外部系统功能的结构 | 真正执行查询与动作的路径 |
| 检索 | 找到相关资料或目标的步骤 | RAG 的起点 |
| 工具调用 | 用名字和参数执行外部功能的步骤 | 工具使用的核心动作 |
| 审批 | 在执行前由人或策略确认是否允许 | 高风险动作的安全装置 |
这里先把 RAG 是阅读、工具使用是执行、审批是在行动前做检查 作为基准线。
| 主题 | 本节要看的问题 |
|---|---|
| RAG | 为什么要把外部资料搜出来并放进输入上下文？ |
| 工具使用(tool use) | 为什么要调用外部系统？ |
| 差异 | 阅读资料和执行动作究竟哪里不同？ |
| 组合 | RAG 与工具使用可以一起出现吗？ |
| 责任 | 检索结果与工具执行结果由谁来审查？ |
RAG 与工具使用在系统中的位置¶
- 把 RAG 理解为读取外部资料的结构。
- 把工具使用(tool use)理解为调用外部系统功能的结构。
- 区分二者虽然都用了模型外资源，但目的与风险不同。
- 理解 RAG 与工具使用可以组合使用。
- 在进入 agent 之前先整理基本构件的角色。
三个基准¶
这两种结构之所以容易混在一起，是因为它们都“使用模型之外的东西”。阅读正文时，可以先抓住下面三个基准。
| 基准 | 为什么重要 | 本节所需的理解水平 |
|---|---|---|
| RAG 是找资料并把资料贴进上下文的结构 | 这能清楚说明“检索 + 生成”到底是什么意思。 | 只要理解成它会把文档读进回答依据里即可。 |
| 工具使用是实际调用外部功能的结构 | 这能把“参考资料”和“执行动作”区分开。 | 只要理解成它会调用搜索 API、计算器、数据库、文件工具等即可。 |
| 两者能一起用，但角色与风险不同 | 这为后面的 agent 说明建立边界。 | 只要理解成阅读与行动不是一回事，审查责任也不同即可。 |
RAG 会把资料找出来并接到上下文¶
正如 P1-13.3 所说，RAG 会把 检索(retrieval) 与 生成(generation) 连起来。
用户问题
-> 找相关文档
-> 把检索到的片段放进输入上下文
-> 模型生成回答
RAG 的中心问题是：
模型回答时，应当从哪里取得它要参考的资料？
例如，假设用户问：
在这组文档里，有没有把嵌入解释成“意义本身”？
RAG 可以先在文档集合里找出相关片段。
| 步骤 | 作用 |
|---|---|
| 问题嵌入 | 把问题转换成向量 |
| 相似度搜索 | 找出相关文档候选 |
| 上下文增强 | 把检索出的片段加入提示词 |
| 回答生成 | 模型依据资料作答 |
在这里，RAG 的本质是把外部资料 读进来。它不是在修改文档、发送邮件或触发支付。
工具使用会调用外部系统¶
工具使用(tool use)允许模型借助外部系统的功能。OpenAI 的 function calling 文档也会说明：模型可以通过这种方式连接到外部数据和系统。
这里可以先这样区分：
模型：
提议要用哪个工具、给什么参数。应用或服务器：
审核工具调用并真正执行它。工具：
完成搜索、计算、文件处理、API 调用等工作。
例如，假设用户请求：
查看明天首尔的天气，并把它加到我的日程备注里。
这会混合两类外部动作：
| 工作 | 可能方式 |
|---|---|
| 查询天气 | 调用天气 API 工具 |
| 写入日程备注 | 调用日历或备忘录 API 工具 |
| 解释结果 | 由模型生成自然语言说明 |
工具使用可以读取外部系统状态，也可以改变外部系统状态。因此，它承担的执行责任通常比 RAG 更重。
RAG：
把资料找来并接到输入里。工具使用：
调用外部系统来查询或行动。
RAG 与工具使用的目的不同¶
把二者并排放在一起看，差异会更清楚：
| 区分 | RAG | 工具使用(tool use) |
|---|---|---|
| 中心目的 | 找到回答所需资料 | 执行外部功能 |
| 主要对象 | 文档、知识库、搜索索引 | API、数据库、文件系统、业务系统 |
| 与模型输入的关系 | 检索结果进入提示词上下文 | 工具结果返回给模型或应用 |
| 代表性问题 | 模型应该参考什么？ | 系统应该执行什么？ |
| 主要风险 | 资料错误、过期或无关 | 执行错误、权限问题、外部状态改变 |
同样是“会议记录”，也可能走向不同结构：
请解释会议记录里的决议事项。
-> 主要是 RAG 或文件检索请从会议记录里找出决议事项，并登记到日历里。
-> RAG + 工具使用
第一个请求主要是找资料并总结；第二个请求则需要在找到资料之后，进一步对外部系统执行动作。
两者可以组合使用¶
真实 AI 服务里，RAG 与工具使用往往会同时出现。
例如，想象一个使用组织内部文档的工作助手：
用户：
请按照差旅报销规定处理这张发票。
可能的流程如下：
- 用 RAG 检索差旅报销规定。
- 模型比较规定与发票内容。
- 如果必要字段缺失，就继续追问用户。
- 如果符合条件，就调用报销系统 API。
- 向用户展示处理结果与依据文档。
在这条流程里，RAG 与工具使用分工不同：
| 步骤 | 结构 | 作用 |
|---|---|---|
| 检索规定 | RAG | 找到判断依据 |
| 解读发票 | 模型 | 阅读并整理输入资料 |
| 提交报销 | 工具使用 | 执行外部业务系统 |
| 展示结果 | 应用 | 呈现结果与依据 |
这种组合也可能进一步发展成一个 agent 结构。但这一节不会深入到“多个步骤如何自动串起来”的 agent 解释里去。
工具使用需要权限与审批流¶
因为工具使用会调用外部系统，所以 权限(permission) 与 审批(approval) 很重要。
如果 RAG 检错文档，主要影响的是回答质量；工具使用出错时，可能直接改变外部系统状态。
| 情况 | 风险 |
|---|---|
| 发错邮件 | 错误信息发给真实收件人 |
| 错误支付 | 可能造成资金损失 |
| 访问无权限文档 | 可能泄露隐私或机密信息 |
| 错误修改文件 | 可能破坏工作产出 |
| 重复 API 调用 | 同一动作可能被执行多次 |
因此，工具使用通常必须同时回答下面这些问题：
这个用户是否有权限调用该工具？
这个工具会改变什么外部状态？
是否需要用户审批后才能执行？
如果执行失败，怎样回滚或记录？
如何审查执行结果？
这也会连到安全(security)、隐私(privacy)、运维(operation)等问题。但更长的伦理、版权与安全讨论会留到 P1-15。
模型提出调用，系统负责执行¶
讲工具使用时，有一个边界尤其重要：
不是模型自己直接改变外部世界，
而是应用与服务器代码真正执行工具调用。
模型可以生成类似下面的内容：
工具名：
calendar.create_event参数：
日期、时间、标题、参与人
但真正去调用日历 API 的，仍是应用或服务器代码。它必须做权限检查、参数校验，并在需要时请求用户审批。
这个区分能让责任更清楚：
| 组成部分 | 责任 |
|---|---|
| 模型(model) | 生成工具与参数的候选 |
| 应用/服务器(application/server) | 检查权限、校验输入、决定是否执行 |
| 工具(tool) | 查询或操作外部系统 |
| 用户(user) | 在需要时审批或修改 |
这个视角对于理解 Codex 这类 agent 风格工具也很重要。即使模型提出了动作建议，真正的文件修改、命令执行、提交与部署，仍然发生在执行环境和权限策略之内。
用一个小例子看位置差异¶
拿“检查并更新一篇较长的学习文档”来举例：
请求：
核对向量搜索说明的依据，并补强相关段落。
可能的流程如下：
| 步骤 | 结构 | 说明 |
|---|---|---|
| 读取当前文档 | 工具使用 | 从文件系统读取当前 section |
| 查找支撑资料 | 搜索或 RAG | 找到相关论文和文档候选 |
| 审查依据 | 模型 + 人 | 判断资料是否真的支撑当前论断 |
| 修改文档 | 工具使用 | 对文件打补丁 |
| 验证构建 | 工具使用 | 运行 MkDocs build |
| 汇报结果 | 应用或对话 UI | 展示修改与验证结果 |
在这条流程里，RAG 更接近 找到支撑资料并补强回答上下文 的部分；工具使用则是 读文件、打补丁、构建、提交 这种真正触碰外部环境的部分。
检查清单¶
- 能把 RAG 解释为检索外部资料并把它贴进输入上下文的结构。
- 能把工具使用(tool use)解释为调用外部系统功能的结构。
- 能把两者的差别说明成
阅读资料和执行动作的差别。 - 能举例说明 RAG 与工具使用可以在同一服务流程里组合出现。
- 能说明工具使用为什么需要权限(permission)、审批(approval)、校验(validation)、执行日志(log)。
- 能说明模型可以提出工具调用，但真正执行的是应用或服务器。
- 能在比较 RAG 与工具使用时，把
阅读资料、执行外部功能、行动前审批这三种责任分开。
出处与参考资料¶
- Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv, 2020, 确认日期：2026-06-23.
- OpenAI, Function calling, OpenAI API Docs, 确认日期：2026-07-19.
- OpenAI, Text generation, OpenAI API Docs, 确认日期：2026-07-19.