这道题其实是在问,怎么让大模型不光能聊天,还能实际操作外部系统,比如查数据库、调API。我拆开说一下几种主流做法,以及我实际落地时怎么选。
先说最成熟的,原生[[Function Calling]]。像OpenAI、Claude这些平台直接内置了,模型在训练阶段就学过输出结构化JSON,推理时你传个tools参数,它能自主决定什么时候调用,返回格式固定。这个方案的优点是准确率高,多轮对话里也能记住上下文。但前提是你得依赖平台,模型决策是个黑盒,你不知道它为什么选这个工具。所以它适合生产环境,特别是对可靠性要求高的场景,比如客服系统里查订单状态。
再一个是用[[ReAct]]模式的Prompt工程。说白了就是给模型写[[Few-shot]]样例,让它按Thought、Action、Observation的格式输出。比如用户问天气,模型先想一下,再调get_weather函数。这个方案零成本,开源模型也能用,适合快速验证MVP。但坑也很明显,格式不稳定,模型可能多输出几句废话,你得用正则硬解析。多轮对话里更容易出错,上下文一长,格式就崩。所以它只适合原型阶段,上线我不太放心。
第三种是微调专用模型,像ToolLLM、Gorilla那套思路。用大量指令、工具描述、参数三元组数据做[[SFT]],让模型学会选工具和填参数。这适合垂直领域,比如金融风控里要调几十个内部API,或者需要完全私有化部署。优点是工具集可定制,不受Prompt长度限制。但前提是你要有高质量的训练数据,构建成本很高,而且泛化性依赖训练质量,换一个领域可能就不行了。
实际生产里,我倾向于混合路由。用户query进来,先过一个意图分类模型,决定是直接回答、调用工具还是追问澄清。调用工具时,我会加一层参数校验,比如JSON Schema校验加类型转换兜底。如果调用失败,把错误信息回传模型,让它自我修正。多个独立工具可以并发,有依赖的按拓扑排序。这样既保证可靠性,又灵活。
不过有个细节值得注意,工具调用失败后让模型自我修正,这个重试机制其实依赖模型的[[In-Context Learning]]能力,如果模型本身不强,重试几轮可能还是错的,这时候就需要引入兜底策略,比如转人工或者预设回复。
所以我会把原生Function Calling作为首选,但一定配上校验层和降级策略。Prompt方案只用来快速试错,微调只在工具集稳定且规模大时考虑。整体上,我更看重可靠性和可观测性,而不是一味追求模型自主决策。