作者:Tula Masterman
如今,新的库和低代码平台使得构建AI代理(也称为数字员工)比以往任何时候都更加容易。工具调用是驱动生成式AI模型“代理”性质的主要能力之一,它扩展了这些模型在对话任务之外的能力。通过执行工具(功能),代理可以代表您采取行动,并解决需要稳健决策和与多种外部数据源交互的复杂多步问题。
本文聚焦于通过工具调用表达推理的方式,探讨了工具使用中的一些挑战,涵盖了评估工具调用能力的常见方法,并提供了不同模型和代理与工具交互的例子。
成功的代理的核心在于两种关键的推理表现形式:通过评估和规划进行推理以及通过工具使用进行推理.
虽然这两种推理表达都很重要,但并不总是需要结合它们来创造强大的解决方案。例如,开放AI的新版 o1模型在通过评估和规划进行推理方面表现出色因为它经过了使用链式思维推理的训练。这显著提高了它解决复杂挑战的能力,这一能力在各种基准测试中得到了体现。例如,o1模型已经展示了在GPQA基准上超越人类博士级别的准确性涵盖物理、生物和化学,并且在这些科目中取得了分数Codeforces网站上第86到93百分位区间竞赛。虽然o1的推理能力可以用来根据工具描述生成基于文本的回答,但它目前缺乏明确调用工具的能力(至少目前是这样!)
相比之下,许多模型经过专门微调以通过工具使用进行推理使它们能够有效地生成函数调用并与其交互API。这些模型专注于在正确的时间以正确的格式调用正确的工具,但通常不会像o1那样设计来彻底评估自己的结果。The伯克利函数调用排行榜(BFCL) 是一个很好的资源,用于比较不同模型在函数调用任务上的表现。它还提供了一个评估套件以比较您自己的微调模型在各种具有挑战性的工具调用任务上。事实上,最新数据集,BFCL v3刚刚发布并现在包含多步、多轮函数调用进一步提高了基于工具的推理任务的标准。
这两种推理类型各自都很强大,当结合使用时,它们有可能创建能够有效分解复杂任务并自主与其环境互动的代理。欲了解更多关于推理、规划和工具调用的人工智能代理架构的例子查看我团队在ArXiv上的调查论文.
构建稳健可靠的代理需要克服许多不同的挑战。在解决复杂问题时,一个代理通常需要同时平衡多个任务,包括规划、适时使用正确的工具、正确格式化工具调用、记住之前步骤的输出、避免重复循环以及遵循指导以保护系统免受破解/提示注入等风险。
过多的需求很容易压垮单个代理,导致这样一种趋势:用户看起来面对的是一个代理,但实际上幕后是一群代理和提示协同工作,分工合作以完成任务。这种划分使得任务可以被分解并由不同的模型和代理并行处理,这些模型和代理专门用于解决拼图中的特定部分。
这里就是那些具备出色工具调用能力的模型发挥作用的地方。虽然工具调用是一种使能生产性代理的强大方式,但它也伴随着其自身的一系列挑战。代理需要理解可用的工具,从一组可能相似的选项中选择正确的工具,准确地格式化输入,以正确的顺序调用工具,并且可能还需要整合其他代理或人类提供的反馈或指令。许多模型专门针对工具调用进行了微调,使它们能够在正确的时间高精度地选择功能。
在对模型进行微调以用于工具调用时,一些关键考虑因素包括:
随着语言模型中工具使用的重要性日益增加,许多数据集应运而生,旨在帮助评估和提升模型的调用工具能力。目前最流行的两个基准测试是伯克利函数调用排行榜和Nexus函数调用基准测试,两者都Meta 用来评估他们的 Llama 3.1 模型系列的性能最近的一篇论文,工具ACE展示了代理如何被用来创建一个多样化的数据集以用于模型工具使用的微调和评估。
让我们更详细地探索每个基准测试:
这些基准测试有助于我们评估通过工具调用表达的模型推理能力。这些基准测试和经过微调的模型反映了开发更专门化以执行特定任务的模型以及通过扩展与现实世界的交互能力来增强大语言模型功能的发展趋势。
如果你对探索工具调用的实际应用感兴趣,这里有一些示例可以帮你开始,这些示例按易用性排列,从简单的内置工具到使用微调模型以及具有工具调用能力的代理。
一级 — ChatGPT开始并实时观看工具调用而无需自己定义任何工具的最佳地点是通过ChatGPT。在这里,你可以使用通过聊天界面的GPT-4来调用和执行网络浏览工具。例如,当被问到“本周最新的AI新闻是什么?”时,ChatGPT-4将进行网络搜索,并根据找到的信息返回答复。记住新的o1模型目前还没有调用工具的能力,无法进行网络搜索。
虽然这个内置的网页搜索功能很方便,但大多数使用场景将需要定义可以直接集成到您自己的模型工作流和应用程序中的自定义工具。这把我们带到了下一个层次的复杂性。
级别2——使用具有工具调用能力的模型并定义自定义工具:
这一级别涉及使用具有工具调用能力的模型来了解该模型如何有效地选择和使用其工具。重要的是要注意,当模型被训练用于调用工具时,它只会生成调用工具的文本或代码,但不会实际执行该代码。外部的某个系统需要调用这个工具,在这里——即将生成与执行结合在一起的地方——我们从语言模型的能力过渡到了代理系统。
为了了解模型如何表达工具调用,我们可以转向Databricks Playground。例如,我们可以选择Llama 3.1 405B模型,并赋予它访问示例工具get_distance_between_locations和get_current_weather的权限。当用户消息为“我将从洛杉矶前往纽约旅行,这两个城市相距多远?纽约的天气如何?我希望在到达时做好准备”时,模型决定调用哪些工具以及传递什么参数以有效地回复用户。
在这个例子中,模型建议调用两个工具。由于模型无法执行这些工具,用户需要填写一个样本结果来模拟工具的输出(例如,“2500”表示距离,“68”表示天气)。然后模型使用这些模拟的输出回复用户。
这种方法使用Databricks Playground允许你观察模型如何使用自定义定义的工具,并且这是在将功能定义实现在你的工具调用启用的应用程序或代理中之前进行测试的一个很好的方式。
在Databricks Playground之外,我们可以观察和评估像HuggingFace这样的平台上可用的不同模型通过代码有效使用工具的情况。例如,我们可以从HuggingFace加载不同的模型,如Llama 3.2–3B-Instruct、ToolACE-8B、NexusRaven-V2–13B等,给它们提供相同的系统提示、工具和用户消息,然后观察并比较每个模型返回的工具调用。这是一种很好的方式来理解不同模型在使用自定义定义的工具方面的推理能力,并且可以帮助你确定哪些工具调用模型最适合你的应用程序。
以下是一个示例,展示了基于以下工具定义和用户消息由Llama-3.2–3B-Instruct生成的工具调用,其他模型也可以按照相同的步骤来比较生成的工具调用。
导入torch
从transformers导入pipeline函数定义 = """[
{
"name": "搜索谷歌"
"description": "执行给定查询的Google搜索并返回顶部结果。"
"参数": {
"type": "字典"
"required": [
"查询"
],
"属性": {
"查询": {
"type": "字符串"
"description": "用于Google搜索的查询字符串。"
},
"num_results": {
"type": "整数",
"描述": "返回的搜索结果的数量。"
"默认": 10
}
}
}
},
{
"name": "发送电子邮件",
"描述": "向指定的收件人发送电子邮件。"
"参数": {
"type": "词典"
"required": [
"收件人电子邮件"
"主题"
"消息"
],
"属性": {
"收件人邮箱": {
"type": "字符串"
"描述": "收件人的电子邮件地址。"
},
"主题": {
"type": "字符串"
"描述": "电子邮件的主题。"
},
"消息": {
"type": "字符串"
"描述": "电子邮件的正文。"
}
}
}
}
]
"""
这是Meta建议的系统提示词
系统提示 = "你是一位函数编写的专家。你会收到一个问题和一组可能的函数。"
根据问题,您需要调用一个或多个函数/工具来实现目的。
如果没有任何函数可以使用,指出来。如果给定的问题缺少函数所需的参数,
也指出来。你应当仅在工具调用部分返回函数调用。
如果您决定调用任何一个函数,您必须以[func_name1(params_name1=params_value1, params_name2=params_value2...), func_name2(params)]的格式进行。
您不应在响应中包含任何其他文本。
以下是您可以调用的函数列表,以JSON格式显示。\n\n{functions}\n""".format(functions=function_definitions)
从这里我们可以进入Level 3,在那里我们定义执行语言模型生成的工具调用的代理。
三级代理(调用/执行LLM工具调用)代理通常通过规划和执行以及调用工具来表达推理,这使它们成为基于AI的应用程序中越来越重要的一部分。使用LangGraph、AutoGen、Semantic Kernel或LlamaIndex等库,您可以快速创建一个使用GPT-4o或Llama 3.1–405B等模型的代理,这些模型支持与用户对话和工具执行。
查看这些指南,了解一些有趣的角色示例:
未来,具有强大推理能力的代理系统将主导发展,使它们能够有效地与其环境互动。随着该领域的演变,我预计我们将继续看到更多小型专业化模型的出现,这些模型专注于特定任务,如工具调用和规划。
在构建代理时,考虑模型大小的当前限制是很重要的。例如,根据Llama 3.1 模型卡,Llama 3.1–8B模型在同时保持对话和调用工具的任务中不可靠。相反,对于此类任务应使用具有70B+参数的更大规模模型。此外,其他关于微调小型语言模型的新研究也表明,较小的模型可能最适合专门用于调用工具,而较大的模型则更适合进行更高级别的推理。通过结合这些能力,我们可以构建越来越有效的代理,提供无缝的用户体验,并使人们能够在专业和个人活动中利用这些推理能力。
有兴趣进一步讨论或合作吗?请联系我。领英!