AI 智能体如何学习使用工具，以及如何测试

Diyi Yang 介绍本次讲座的主题：智能体为什么需要工具、模型如何学习选择和使用工具，以及工具如何通过接口提供。最后，她会介绍工具使用的基准测试和可靠性指标。

她首先回顾检索增强生成（RAG）：检索外部材料，并用它回答问题或完成任务。即使采用这种设计，检索、阅读以及各阶段之间的衔接仍可能出错。

检索可能暴露智能体不应访问的材料。阅读模型可能被看似相关的文档分散注意力，或面对相互冲突的证据；早期错误也可能沿着检索、阅读、生成的流程传播。

提示注入带来另一种风险：攻击者可以在检索到的文档中放入恶意指令。Yang 说，系统必须谨慎处理检索材料，而不能假定它们可信。

为了说明“中间丢失”现象，她描述了一个包含多份文档的问答提示，其中一份包含答案。她问，如果答案所在文档从开头移到中间或结尾，模型能否同样有效地使用它。

在她展示的经典研究中，性能往往呈 U 形：位于开头或结尾附近的相关材料比中间材料更容易被可靠利用。正确答案可能就在上下文里，却仍然被忽略。

Yang 用一个早期问答例子说明这种效应：图中闭卷得分约为 56，而提供相关文档可以提高到 88。当文档位于中间时，性能可能降回接近没有检索的基线。

检索更多文档会提高答案存在于结果中的概率，但不能保证阅读模型会使用它。图中检索覆盖率在约 50 篇文档时达到 90%，而阅读准确率更早进入平台期；Yang 建议谨慎选择和重排结果。

引用有助于核查答案，但生成的引用本身也可能出错。Yang 说，不能仅因为回答中包含链接或参考文献，就相信流畅且看似权威的内容。

她展示了一项较早的比较：用户对答案的评价很高，但引用精确率低得多。这一反差说明，感知有用性和事实支持是不同的衡量指标。

Yang 说，研究人员在会议论文和学生作业中发现了虚构参考文献，并介绍了会议采取直接拒稿等应对措施。她敦促学生核实参考文献，对自己提交的内容负责。

她提醒说，链接或引文可能让答案看似权威，但不会自动验证内容。提交者仍有责任检查来源。

“大海捞针”测试在长上下文中放入一个相关事实，并改变其位置和周围文本的长度。Yang 展示了较早的 Claude 2.1 结果：上下文越长，失败越多，尤其当事实远离最近阅读的位置时。

在这项测试中，上下文长度和插入事实的位置分别变化。模型随后回答一个依赖该事实的问题。

较早的 GPT-4 测试整体表现更强，但 Yang 指出，上下文较长时仍有性能下降的区域，中间位置仍会出现失败。她认为，标称上下文窗口很大，并不保证模型能可靠使用其中每个事实。

Yang 强调，这些例子针对特定的早期模型和测试。经验教训是应衡量实际检索和阅读表现，而不是从上下文窗口大小推断能力。

被问到为什么出现位置效应时，Yang 提出长距离依赖和位置偏差可能是原因。她将其作为理解观察现象的直觉，而不是对原因的完整证明。

她将模型对近期信息的关注，与人更容易记住昨天而非更早发生的事作比较。这是她用来解释位置偏差的类比。

一名学生问，获取外部知识是否有检索之外的替代方法。Yang 仍然推荐将 RAG 作为有用的通用方法，同时检查正确性、位置偏差、访问权限和注入内容。

对于具体应用，她建议检查系统能否给出正确答案，而不受文档顺序过度影响。安全检查也应涵盖注入内容。

Yang 用早期模型的例子转向工具：模型可能擅长看似更难的问题，却在当前日期、实时事实或算术上遇到困难。她展示了乘法准确率随位数增加而下降的情况。

Yang 用乘法具体说明这种反差：早期模型能解决一些复杂问题，却可能在简单的精确算术中出错。计算器可以提供独立的计算能力。

谜题和动态规划的例子也出现类似趋势：步骤越多，任务对模型可能越难。Yang 建议将精确计算交给外部工具，而不是假设语言模型必须在内部完成每项操作。

她说，当问题需要更多中间步骤时，表现往往变差。这促使人们把操作交给专用软件，而不只依赖流畅的文本生成。

她将局限归为精确推理、获取训练中没有的信息，以及与非语言系统或物理世界互动。计算器和代码可以帮助计算；检索和实时搜索可以提供变化中的信息或私有信息。

实时 API 可以提供当前信息，而检索公司文档可以提供模型训练时没有的材料。不同外部工具解决不同的局限。

其他工具可以提供数据库、浏览器、API、图像生成器或机器人能力。Yang 将工具使用视为广义的智能体能力：系统选择外部操作，并在任务中使用返回结果。

工具可以看作通向模型外部程序的接口。模型以文本形式生成名称和参数；外部程序执行操作并返回结果。

文本接口很重要，因为语言模型本来就处理文本。即使执行发生在外部，时间函数、计算器或天气服务也可以用可识别的名称和指定参数表示。

Yang 将例子扩展到日历、电子邮件、图像生成、翻译系统和词典。工具不一定是新模型：现有服务或专用模型也可以提供智能体缺少的能力。

工具目录可以包括常规服务和专用模型，例如翻译系统。智能体不必在内部重新实现每项能力。

对于乘法问题，模型会输出带有操作数的计算器调用；天气问题则可以触发天气函数。两种情况下，模型都使用外部答案，而不是仅靠自身生成结果。

工具调用以包含操作和输入的结构化文本表示。外部系统完成工作，再把输出返回给模型。

一位观众问，基于文本的调用如何应对类型检查、版本管理和语义变化。Yang 说，生成的名称或参数可能是虚构的或无效的，因此外部检查可能失败；这些都是实际的工具使用故障模式。

另一个问题问模型能否动态创建工具。Yang 说，已有研究探索即时生成工具或接口，但生成的工具本身可能包含错误，也可能重现模型记住的内容。

接着，讲座讨论模型如何学习何时调用工具、选择哪个工具以及提供哪些参数。Yang 介绍 Toolformer，将其作为把这些决定转化为学习问题的早期方法。

Toolformer 的设置是在普通文本中加入调用、结果和后续文本。Yang 用计算和事实性问题说明，在哪个位置插入外部答案可能改善后续文字的预测。

预期行为包括确定调用位置、选择合适的 API、生成参数并使用返回结果。Yang 将每一步都视为学习问题的一部分。

早期系统使用五种工具：问答、计算器、搜索、翻译和日历。在增强后的示例上训练，可以让模型在推理时学会输出工具调用并使用结果。

通过在普通句子中加入候选 API 调用来构建训练示例。推理时，训练后的模型可以在生成文本时输出特殊调用格式。

为了构建示例，该方法会考虑句子中哪些位置可能适合插入 API 调用，然后在这些位置采样候选调用并在外部执行。

选定插入位置后，流程会采样可能的调用并执行，得到可以比较其有用性的候选响应。

筛选步骤要判断返回结果是否改善了对后续文本的预测。加权损失更重视附近的词元，因此工具结果的即时影响比远处词语更重要。

损失比较包括一个提供调用但不提供结果的基线。这用于检验返回信息是否在调用文本之外增加了价值。

Yang 将包含完整调用和结果的损失，与没有调用或有调用但没有输出的基线比较。如果结果让预测改善超过某个阈值，候选示例就可以保留用于训练。

在 Pittsburgh 的例子中，图中没有调用时损失为 2.5，有调用但没有答案时为 2.1，提供执行后的答案时为 0.8。相对于较强基线的改善为 1.3；损失越低越好。

一位观众问，当外部服务可能返回缓存数据或发生故障时，这种方法有多可靠。Yang 同意，服务器不可用、请求格式错误和错误响应都会影响训练信号，说明学习式方法存在局限。

Yang 指出，即使候选调用看起来合理，外部服务也可能不可用或返回错误。流程评估的是实际返回内容，这可能限制得到的信号。

她展示的例子中，有用的日历调用比无用调用得到更高分数。这个分数旨在判断特定工具响应是否对文本中的特定位置有帮助。

Yang 说，相比大得多的基线模型，Toolformer 基于 GPT-J 的小模型在展示的数学和时间信息等任务上表现良好。这一历史结果说明，工具访问可以弥补模型的某些局限。

一名学生问，工具调用发生在词元生成之中，还是发生在智能体轮次之间。Yang 说，早期例子将调用插入生成流；较新的智能体可以产生更长的轨迹，先尝试一个工具，再选择另一个。

这一区别在历史上很重要：在词元流中插入调用，并不是组织智能体的唯一方式。后来的系统可能明确规划、检查结果，再选择下一步行动。

ToolkenGPT 采用相关的词元方法：用学习得到的词元嵌入表示每个工具。选中该词元时，生成暂停，模型提供参数，外部工具运行，结果返回后再继续生成。

Yang 用数学问题中的最大公约数函数说明这个机制。系统在普通推理文本和工具模式之间切换，而不是在一段不间断的生成中算出全部答案。

合成示例可以训练工具嵌入，但 Yang 强调了一个历史弱点：在展示的结果中，需要多次调用的任务表现远差于单次调用任务。她说，多步工具使用仍比选择单个操作更难。

被问到原因时，Yang 指出可能的调用序列搜索空间很大，而训练数据中的多步工具示例相对有限。在她的解释中，组合搜索问题是主要原因。

一名学生问，模型如何发现新创建的工具。Yang 借此从固定的少量工具转向旨在扩展到数千个 API 的方法。

ToolLLM 收集大量 API 描述，并使用能力较强的模型合成合理的用户请求和解决轨迹。Yang 说，她展示的系统覆盖了该集合中超过 16000 个 API。

这一流程先提示 ChatGPT 为工具生成用户请求，再让它尝试使用可用工具完成任务。生成的解决路径构成 ToolBench 数据集；较小的 Llama 模型可以在这些示例上微调，得到 ToolLLaMA。

运行时，ToolLLaMA 接收一条指令和候选 API，利用学到的工具使用行为生成答案。训练示例来自模拟请求和解决路径。

Yang 区分了用生成的任务示例训练较小模型与经典知识蒸馏。这些示例模拟具体用户请求和解决步骤，不需要访问另一个模型私有的内部推理。

Yang 强调，生成具体合成任务与提取模型的隐藏推理不同。产生的示例仍可用于训练另一个模型。

她展示了语音转文字的工具调用失败：一个例子虚构了参数，另一个则为转写请求选择了翻译工具。相似的名称和接口让正确选择 API 与参数变得困难。

调用可能以多种方式失败：API 可能是虚构的，参数可能不存在，所选函数也可能针对错误任务。Yang 用转写与翻译说明这些区别。

Gorilla 是另一个将语言模型连接到 API 的系统。Yang 介绍了从模型中心收集的约 1600 个 API，以及用 GPT-4 生成合成指令后进行模型训练的方式。

她介绍了检索感知训练，让模型同时接触正确和错误的文档。目标是在检索文档不匹配时提高稳健性，而不是简单复制上下文中的内容。

推理时，系统将用户请求与可用 API 描述匹配并构造调用。Yang 指出，用户可能只看到最终结果，尽管中间选择和调用会消耗词元并产生成本。

精确字符串匹配对 API 评估可能过于严格。她介绍的方法将调用解析为抽象语法树，并与参考结构比较，帮助区分不存在的 API 和其他格式错误的调用。

语法树让提出的调用结构可以与参考结构比较。Yang 用它讨论无效 API 名称，以及原本可以识别的调用内部出现的错误。

Yang 展示的结果中，Gorilla 相对于所比较的基线，测得的 API 幻觉更少、准确率更高。结构有效只是评估的一部分；一个看似可执行的调用，本身并不能证明任务已正确完成。

这些训练方法带来维护问题：新 API 可能需要额外训练或更新工具表示。Yang 转向讨论运行时一致描述工具，让模型通过共享接口发现它们。

共享的运行时描述改变了集成问题：模型可以读取可用工具的描述，而不必通过重新训练将每个工具永久编码进去。这并不消除测试其选择的必要性。

她比较了三种接口模式：REST 请求、结构化函数调用和模型上下文协议（MCP）。思路从让模型适应固定工具集合，转向让应用能够发现服务。

Yang 将 REST、函数调用和 MCP 描述为连接应用与服务的不同方式。它们在不同层次提供信息，而不会自动解决所有集成问题。

一个 REST 示例向天气端点发送带位置参数的 HTTP 请求，并读取响应。调用方需要知道端点、参数名称和响应格式等细节。

函数调用以结构化模式描述工具，并让模型给出名称和带类型的参数。应用代码可以验证请求、执行函数并返回结果；随着工具变化，模式仍需要维护。

函数调用周围的应用可以在执行前检查输出参数是否符合预期模式。模式描述调用，但不能保证模型选择了正确函数。

Yang 将 MCP 介绍为 AI 应用与工具或数据提供方之间的通用协议。服务器提供能力，客户端连接让宿主在运行时发现和调用这些能力，使集成可以在兼容应用之间复用。

按她使用的术语，宿主是应用程序，服务器提供对资源或工具的访问，客户端是宿主与服务器建立的连接。多个连接并不意味着有多个人类用户。

宿主可以请求服务器的工具列表，其中包括名称、描述和输入模式，然后带参数调用选定工具。模型仍须选择合适的操作并提供有效输入。

Yang 说，开发者可以使用库表达较高层次的工具规范，而不必手写每条协议消息。她的例子为智能体封装了课程服务。

对于课程学习管理系统，Yang 设想可以列出作业、读取提交内容或发布成绩的工具。这些能力需要不同权限：仅仅连接智能体，不能让每位用户都有权修改成绩。

在她的例子中，MCP 服务器位于智能体与课程 API 之间并检查访问权限。她描述了如何将课程 API 令牌与智能体令牌分开，以便集成能够执行对每个调用者的权限限制。

Yang 介绍 Berkeley Function Calling Leaderboard，将其作为工具使用评估的参考来源。她描述了对调用结构、实际执行和最终状态的检查，包括正确答案是没有合适工具可用的情况。

她回顾 ToolBench，随后介绍 τ-bench：智能体与模拟客户互动，例如更改或取消航班，并必须按照任务要求使用工具。

对于多轮交互，Yang 区分了 pass@k 和更严格的可靠性指标 pass-hat@k：前者要求 k 次尝试中至少成功一次，后者要求选中的所有尝试都成功。用户需要系统稳定工作，而不是多次尝试中只成功一次。

她指出，τ-bench 已扩展到早期零售和航空场景之外。Yang 最后强调，评估指标会影响基准测试对可靠性的判断。