要是你的AI助手忽地告知你没办法查询到实时天气,且没办法操作数据库,甚至没法完成简易的计算,那你便碰到了大模型跟真实世界相隔绝的根本难题。而Function Calling,也就是函数调用,恰恰是冲破这堵障碍物的关键技术,它使得大模型从只会理论空谈的聊天机器人,转变成能够实际操控工具的智能个体。
Function Calling是大模型厂商于模型层面原生予以支持的一种能力,此最早是被OpenAI在2023年给引入的。它的核心价值在于使得AI模型不但能够生成文本,而且还能够依据对话内容自行判断什么时候需要调用外部工具。从技术实现方面来说,这就等同于在模型内部预先设置了一套“工具开关”,当用户所提出的问题超出模型本身所具有的知识范围或者需要实时数据的时候,模型会主动进行请求去调用开发者预先定义好的函数。
此番能力跟传统的硬编码调用全然不一样,传统的那种方式要求开发者自行去判断何时去调用怎样的函数,然而Function Calling却把决策权给予了模型自身。开发者仅仅要在AI应用里注册一系列函数,详尽地描述每一个函数的功能以及参数要求,模型便能够如同人类一般去分析用户意图,进而挑选最为合适的工具去达成任务。
Functions Calling系统若完整,便含有三个绝对不可缺少的组成部分。其一为函数名称,它属于唯一标识,模型凭借其在众多工具里精准定位要调用的那个。其二是函数作用描述,这一部分真无比重要,只是因为模型依靠阅读这些自然语言描述去明白每个函数能够做什么、适应何等场景。
首先,第三部分涉及函数入参的构结构定义,这一环节要求依据JSON Schema格式,清晰地阐明每个参数的含义,明确其类型,界定取值范围。比如说,当定义一个天气查询函数时,你得告知模型,存在一个名为“城市名称”的参数,此参数属于字符串类型,而且是必须予以提供的。这三个要素,共同组建起了模型调用工具之际的“操作手册”。
在用户朝着AI应用发出问题以后,整个Function Calling流程会历经五个关键步骤。第一步,AI应用会把用户输入跟预先设定好的函数描述一块儿打包发送至大模型。第二步,模型剖析用户意图,要是觉得需要调用工具,便会返回特定的调用指令,这其中涵盖要调用的函数名称以及已经填好参数的JSON对象。
第三步,AI应用在接收到指令之后,去执行本地的函数代码,进而获取真实的数据。第四步,把函数执行的结果,与对话历史一起,重新提交给模型。第五步,模型依据新获得的数据,生成最终回复给用户。整个过程是在用户毫无察觉的情形下完成的,体验方面就如同模型本身就具备这些能力那般自然。
按照最具代表性的天气查询情形来讲,在用户询问“广州今天天气怎样”之际,AI应用会朝着模型递送涵盖函数定义的请求。函数定义里表明存在一个称作get_weather的工具,它接纳一个名为location的参数,其功能是获取指定城市的即时天气数据。
模型做出判断,这实际确实得调用外部 API,接着返回一条结构化指令,即调用 get_weather 函数,其参数值是“广州”。AI 应用去执行这个函数,从天气服务商接口那儿获取到“35 度,暴雨”的数据,随后把结果返回给模型。模型最后结合这些信息告知用户:“广州今天 35 度,暴雨,建议在室内活动”,很好地解决了实时信息获取的难题。
当前时兴的AI开发框架均给予了对Function Calling颇为便利的支持。Spring AI框架借由注解途径,对于开发者而言,只要在方法之上添加上@Tool注解并且恰当写好描述,该框架便会自行生成契合模型需求的函数定义。LangChain却给出了更为灵活的Tool抽象,它准许开发者把任意Python函数包装成为能够供模型调用的工具。
{
"messages": [
{
"role": "system",
"content": "你是一个助手,可以根据用户的请求调用工具来获取信息。"
},
{
"role": "user",
"content": "广州今天天气如何?适合出门吗?"
}
],
// 函数列表
"functions": [
{
"name": "getWeather",
"description": "获取指定城市的天气",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "城市名称,比如北京"
},
"date": {
"type": "string",
"description": "日期,比如 2025-08-07"
}
},
"required": ["location", "date"]
}
}
]
}
以下这些框架的关键工作,皆是把开发者所编写的函数以及其描述信息,转变为大模型 API 所要求的特定格式。在模型返回调用请求之际,框架承担起解析参数以及执行相应方法的职责,最终把结果再度注入对话流程当中。这样的一种封装,使得开发者能够全神贯注于业务逻辑的实现,而不用去操心与模型交互的那些繁杂细节。
Function Calling不是所有大模型都有的标配功能,不同厂商在实现标准方面有显著差异,对于能力来说这种差异也存在。OpenAI的GPT系列对Function Calling的支持极为成熟,Google的Gemini在Function Calling上逐步完善,Anthropic的Claude也在Function Calling方面不断发展着。国内的百度文心提供了Function Calling的类似能力,对于Function Calling阿里通义千问也提供了相似能力,不过百度文心和阿里通义千问在Function Calling格式上有不同,在Function Calling参数限制方面也各不一样。
{
"function_call": {
"name": "getWeather",
"arguments": {
"location": "Guangzhou",
"date": "2025-07-17"
}
}
}
对于开发者而言,当处于选择模型这个行为过程之时,存在着三个维度是需要予以重点瞩目的,分别是:其一为支持的函数数量其所具备的上限情况,其二是参数嵌套这个方面所呈现出的复杂程度状况,其三则是函数调用这一环节所展现出的准确率情形。LangChain4j官网之处,有着一个能够提供详细信息的模型支持对比表,借助这个对比表能够助力开发者依据具体的需求从而挑选到最为适宜的基础模型。有部分属于开源性质的模型,尽管它们也对外宣称自身具备支持能力,然而在面对复杂场景状况下,其稳定性以及准确率方面仍旧是需要以谨慎的态度去进行评估的。
思索过没,要是把设计这种需调用外部工具的人工智能应用这事儿给予你,你会给它配备什么样的各项函数,欢迎于评论区域分享你那有创意的应用情境,点个赞并加以收藏这篇文章以便将来随时能够去查阅,同时也欢迎转发给正钻研人工智能技术的友人一块儿去探讨。
相关标签: # FunctionCalling # 工具 # 大模型 # 扩展功能 # 流程