
LangChain实战 | Tool Calling :让AI真正动起来的关键技术
近年来大模型发展过程中面临的几个核心挑战:静态知识的局限性、执行能力的缺失、与外部系统的割裂。为了应对这些挑战,推动大模型从单纯的语言生成工具演变为真正的任务执行引擎,Function calling 诞生了,成为大模型一项不可或缺的核心能力。
概念 Function calling 和 Tool Calling 会混用
我们在做应用开发的时候,大部分时候尽量避免直接耦合到OpenAI,会使得程序兼容性不好,这时只要面向 LangChain 开发就可以了。
LangChain 是一个灵活的框架,它提供了与多种大模型进行交互的能力。
它的设计允许集成和使用来自不同源的多种模型,包括但不限于OpenAl、Cohere和 Hugging Face 等模型库中的模型。这样,你不必拘泥于某种模型,而是为自己的应用选择最合适的模型。对于Tool Calling能力来说,LangChain 也做了抽象。
调用其他工具的 API(如:Database Tool) 通常需要特定的有效负载格式。可以使用 Tool Calling 来向模型请求与特定格式匹配的响应。随后可以使用这个响应作为负载去做“工具(Tool)实际的执行”。
通俗来将就是:让大模型通过理解用户的提示词,来决定是否需要调用工具(如上图),
如果需要调用工具,会返回需要调用的工具名称和调用参数(不是直接执行工具),后续由代码去执行对应的工具(Tool)。
如果不需要调用工具,那么就直接回复自然语言(如:How can I assist you?)。
工具(Tool)
tool抽象 在 LangChain 中将 Python函数 与 定义“函数名称、描述和预期参数”的schema 关联起来。
工具(Tool) 可以传给支持 tool calling 的 聊天模型,允许模型使用特定输入执行特定函数。
创建工具的推荐方法是使用@tool 装饰器。此装饰器旨在简化工具创建过程,在大多数情况下应使用它。定义函数后,可以使用@tool 对其进行装饰,以创建实现工具接口 的工具。
代码如:
默认情况下,装饰器使用函数名称作为工具名称。
装饰器将使用函数的文档字符串作为工具的描述 —— 因此必须提供文档字符串。
定义工具后,可以通过调用直接使用它。
也能直接看到工具的具体信息。
通过参数自定义工具
@tool("multiplication-tool", args_schema=CalculatorInput, return_direct=True)
属性 | 类型 | 描述 |
名称 | str | 在提供给 LLM 或代理的一组工具中必须是唯一的。 |
描述 | str | 描述工具的作用。用作 LLM 或代理的上下文。 |
args_schema | pydantic.BaseModel | 可选但推荐,如果使用回调处理程序则为必需。它可用于提供更多信息(例如,少量示例)或验证预期参数。 |
return_direct | 布尔值 | 仅与agent相关。当为 True 时,在调用给定的工具后,代理将停止并将结果直接返回给用户。 |
代码如:
输出:
通过解析文档字符串配置定义工具
@tool 可以选择性地解析Google Style 文档字符串,并将文档字符串组件(例如参数描述)与工具schame的相关部分关联起来。使用这种方法,需要指定 parse_docstring
代码如:
结果:
通过大模型的 Tool calling 调用工具
Tool calling 允许聊天模型通过“Tool calling”来响应给定的提示词。
虽然“Tool calling”这个名字暗示模型正在直接执行某些操作,但实际上并非如此!模型仅生成工具的参数,而是否运行工具(或不运行)取决于用户。
Tool calling 可以从模型生成结构化输出,即使您不打算调用任何工具,也可以使用它。该技术是从非结构化文本中提取信息。
如下图,把用户输入的文本,通过大模型的Tool calling提取出了符合工具get_weather的信息。
代码示例
第一步:定义工具
第二步:把工具绑定到大模型
第三步:大模型 Tool calling
第四步:工具的执行(Tool calling 返回需要执行的工具)
第五步:大模型处理工具的返回结果
用户输入 :2乘以3
大模型返回 : 2乘以3的结果是6。
日志:
本文转载自 AI取经路,作者: AI取经路
