← 返回 PaperDaily 大模型与智能体

函数调用也要算“把握”：Apple新论文给出两招改造

函数调用最怕的不是答错，而是答错还直接执行，后果可能比胡说八道严重得多。本文第一次把“不确定性评估”系统搬到函数调用场景里，结果很反常识：复杂的多采样并没有天然赢过简单单采样，反而是“会挑 token”的改造更实用。

龙哥读论文发布于 2026-08-14 09:11:10 阅读 3 查看原文

#大语言模型 #AI科研 #综述

🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
函数调用最怕的不是答错，而是答错还直接执行，后果可能比胡说八道严重得多。本文第一次把“不确定性评估”系统搬到函数调用场景里，结果很反常识：复杂的多采样并没有天然赢过简单单采样，反而是“会挑 token”的改造更实用。

原论文信息如下：

论文标题:
Uncertainty Quantification for LLM Function-Calling 发表日期:
2026年04月发表单位:
University of Oxford, Apple 原文链接:
https://arxiv.org/pdf/2604.22985

函数调用时LLM靠不靠谱？首个不确定性评估基准来了

函数调用这件事，最怕的不是模型“不会”，而是模型“看起来很会”，然后把错误参数、错误函数、错误调用顺序一股脑塞进去，系统还真的执行了。文本答错了，最多是尴尬；函数调用答错了，可能就是数据被改、钱被转、操作被误触发。这个场景里，先判断把握大不大，再决定要不要执行，比单纯追求“答对率”更重要。

图1：函数调用场景下的不确定性评估结果概览。本文来自 Apple Research 与牛津大学，第一次把不确定性量化系统搬到 LLM Function-Calling 场景里，专门研究“模型到底有多大把握”。

这篇论文的切入点很实在：不是再给模型加一个花里胡哨的工具链，而是先问一句——模型在准备调用函数时，到底靠不靠谱。如果不靠谱，就别急着执行。这个思路非常像给自动驾驶加“刹车系统”，不是为了让车更快，而是为了让车别在关键时刻冲进沟里。

简单方法竟胜出？单采样UQ效果不输复杂多采样

先把几个缩写讲明白。UQ 是 Uncertainty Quantification，中文叫不确定性量化，意思是给模型的输出打一个“把握分数”。FC 是 Function-Calling，中文叫函数调用。这篇论文要解决的，不是“模型会不会调用函数”，而是“模型调用这个函数时，值不值得相信”。

论文最有意思的结论之一是：在函数调用场景里，复杂的多采样方法，并没有像在自然语言问答里那样明显压过简单的单采样方法。尤其是语义熵这类多采样方法，在这个任务上没有展现出想象中的统治力；反而是最朴素的 G-NLL（Greedy Negative Log-Likelihood，贪心负对数似然）经常更稳。

这事不难理解。函数调用输出通常是高度结构化的，很多 token 只是语法壳子，真正决定对错的 token 并不多。多采样方法擅长处理“同义不同句”的自然语言，但在函数调用里，很多采样最后都长得几乎一样，差别没大到足以形成有效区分。简单说就是：在这个场景里，复杂算法有点像拿高射炮打蚊子，气势很足，收益不一定高。

图4：单独任务上的 AUROC 对比。AUROC 可以理解为“把正确输出和错误输出分开的能力”，0.5 接近瞎猜，1.0 则是完美区分。这里能看到，单采样方法整体不虚，多采样方法并没有形成压倒性优势。

为了让评估更接近真实部署，论文没有只盯着单个任务，而是把多个函数调用任务混在一起测。原因也很朴素：真实系统里不会给每种请求单独设一套阈值，模型面对的是混合分布。这个设计很重要，因为 AUROC 不是线性指标，不同任务混在一起之后，UQ 方法的表现可能比单任务更难看，也更接近线上现实。

针对性改造：AST聚类与语义有效令牌提取

论文没有止步于“简单方法更强”这个结论，而是继续追问：能不能把已有方法改得更适合函数调用。答案是可以，而且改法并不玄学。

先看多采样方法。原始的语义熵会把多个采样结果按语义相近程度聚类，但论文发现，函数调用输出太结构化了，直接按字符串完全匹配（EXM，Exact String Matching）有点太死板。比如参数顺序变了、空白字符变了，本质上可能还是同一个调用。于是作者改用 AST（Abstract Syntax Tree，抽象语法树）做聚类：只要语法树一致，就算同一类。这样一来，函数调用里那些“表面不同、骨子里一样”的输出就不会被误拆成多个簇。

表5：All Combined 切分上，各模型成功通过 AST 解析的有效样本数。这个表其实很关键，因为多采样方法的前提是样本得能被稳定解析；如果连语法都过不去，后面的聚类和熵计算都是空中楼阁。

再看单采样方法。论文发现函数调用里很多 token 根本不该被一视同仁地算进不确定性分数。比如一些符号、括号、等号，更多是语法需要，不是真正决定任务成败的“语义点”。于是作者提出 SMT（Semantically Meaningful Tokens，语义有效令牌）提取，只挑那些真正影响函数选择、参数选择、参数值选择的 token 来算分。

这一步很像做题时不看草稿纸上的废话，只盯着真正会出错的那几行。论文里给出的规则也很务实：如果 token 只是为了让代码“长得像个合法调用”，那它不该过度影响不确定性；如果 token 直接决定函数名、参数名、参数值，才应该被重点关注。这个思路和自然语言 UQ 里“只看相关 token”的做法一脉相承，但在函数调用场景里做了更贴合结构的定义。

图2：一个错误的函数调用样例中，模型给出的 top token 概率分布。可以看到，真正出错的位置往往只集中在少数几个 token 上，而大量 token 的概率几乎接近 1。

这一张图把问题讲得很透。函数调用里，模型对大部分 token 都非常自信，只有少数关键位置略微犹豫；而且这些犹豫 token 的第二选择，常常不是“更正确”，而是“语法上差不多”。这就解释了为什么多采样方法经常采来采去还是同一个意思，熵上不去，区分力自然也就一般。相反，单采样方法直接看序列概率，反而更容易捕捉到那几个关键分叉点。

图3：自然语言问答中的错误样例 token 概率分布。和函数调用相比，这里的不确定性更分散，语义差异也更大，所以多采样方法更容易发挥优势。

这就是论文最有价值的地方之一：它不是简单说“某方法不行”，而是把函数调用和自然语言生成的结构差异讲明白了。自然语言里，多个采样结果可能在措辞、表达、语义上都差异很大；函数调用里，很多样本只是表面噪声，真正的语义空间更窄。算法如果不承认这个差异，就容易在错误的地方发力。

是否能识别“无法解决”的请求？

函数调用系统里还有一种更现实的情况：请求本身就无解。也就是说，给定的工具根本不够完成任务。这个时候，模型最好的行为不是“硬编一个函数调用”，而是老老实实拒绝执行。论文把 BFCL 里的 Irrelevance 任务也纳入评估，就是为了测试 UQ 能不能帮系统识别这种“该停手”的请求。

这里的逻辑很重要：如果只看 Irrelevance 任务单独表现，模型甚至可以靠“永远拒绝”拿到很高准确率，根本不说明问题。所以论文把它和可回答任务混合起来测，才能看出 UQ 是否真的能在“能做”和“不能做”之间拉开差距。这个设计挺像真实产品里的风控逻辑，不是看单项成绩单，而是看系统能不能在复杂场景里做出合理决策。

图6：答得出来与答不出来的混合场景下，各类 UQ 方法的 AUROC 对比。这里同样能看到，单采样方法整体并不吃亏，甚至略占优势。

这部分的结论其实很接地气：真正上线的系统，最值钱的不是“每次都硬答”，而是“该答就答，该停就停”。如果 UQ 能把无解请求筛出来，系统就能把高风险调用交给人工或直接拒绝，避免把错误动作执行到底。说白了，函数调用里的不确定性，不是学术玩具，而是安全阀门。

适配后效果如何？从表3看性能提升

论文最终把两条改造路线都落到了结果上：多采样侧用 AST 聚类，单采样侧用 SMT 过滤无关 token。整体来看，改造是有效的，但没有把格局彻底翻盘。也就是说，方法变得更贴场景了，性能有提升；但单采样方法依然没有被多采样方法甩开。

表3：全部任务上的平均 AUROC 与标准误。它汇总了前面所有设置，能比较清楚地看出：G-NLL 这类单采样方法依然稳居前列，而 AST 聚类和 SMT 提取能带来增益，但增益更像“锦上添花”，不是“改天换地”。

表格截图：论文中不同任务组合下的结果汇总。任务一旦混合，UQ 的难度就更接近真实部署环境，也更能暴露方法是否真的稳定。

表格截图：校准指标相关结果。论文还额外看了 smoothECE，说明它不只关心“能不能分开对错”，也关心“分数像不像概率”。不过在函数调用的选择性执行场景里，区分能力通常比校准更关键。

从实验设计上看，这篇工作比较扎实的地方在于：它没有只拿一个模型、一个任务做结论，而是覆盖了 8 个不同规模和家族的模型，并且把单任务、混合任务、无解任务都测了一遍。这样得到的结论更像“场景规律”，而不是“某个模型的偶然现象”。

不过也要客观一点：这类方法离真正的大规模产品化还有距离。因为函数调用格式并不统一，不同模型的输出 schema 不同，SMT 提取需要写不同规则；多采样方法还要额外付出推理成本，样本数一多，延迟和费用就上来了。论文自己也点出了这一点：UQ 不是白送的，越复杂越贵。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是“LLM 调用函数时，能不能先判断自己靠不靠谱”这个问题。核心不是让模型更会调用，而是让系统知道什么时候该执行、什么时候该拒绝。

AST 聚类和 SMT 提取分别是什么意思？AST 聚类是按抽象语法树判断两个函数调用是否本质相同，避免把“换了空格、换了顺序”的输出拆成不同类；SMT 提取是只选那些真正影响函数选择和参数选择的 token 来算不确定性，避免把纯语法 token 也算进去。

为什么多采样方法没有明显赢过单采样方法？因为函数调用输出太结构化，很多采样结果只是表面差异，语义上几乎一样；而真正出错的位置只集中在少数几个 token 上。这样一来，多采样的“多”没有转化成有效信息，反而是单采样对关键 token 的敏感性更有用。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

把 UQ 系统性搬到函数调用场景，这个切口很新；真正加分的是没有停留在“测一测”，而是顺手给出 AST 聚类和 SMT 提取两条可落地改造路线。

实验合理度：★★★★☆

覆盖 8 个模型、多个任务组合和无解请求，设置比较完整；不足是部分结论仍依赖特定函数调用格式，外推到更多工具形态时还要继续验证。

学术研究价值：★★★★☆

它补上了工具调用安全性里的一个空白：不只看“答没答对”，还看“该不该执行”。对后续研究函数调用可靠性、选择性执行和安全拒绝都有启发。

稳定性：★★★☆☆

思路稳定，但规则依赖输出格式；一旦模型 schema 变化，SMT 提取和 AST 解析都要跟着改，工程维护成本不低。

适应性以及泛化能力：★★★☆☆

对 Python 风格或结构清晰的函数调用很合适，但面对更杂的工具协议、自然语言混合输出时，适配难度会明显上升。

硬件需求及成本：★★★☆☆

单采样几乎没额外负担，多采样则要按样本数乘上推理成本；如果是端侧或低延迟场景，成本会很敏感。

复现难度：★★★☆☆

主思路清楚，但要把不同模型的输出格式、解析器和评估流程都跑通，仍然需要一定工程能力。

产品化成熟度：★★★☆☆

适合先作为“执行前风险筛子”加入函数调用链路，但要真正上线，还需要和拒答策略、人工兜底、校准机制一起配套。

可能的问题：方法很实用，但仍偏格式驱动；论文证明了“能改进”，还没证明“跨所有工具协议都稳”。

主要参考文献

Ye, Z., Aichberger, L., Kirchhof, M., Williamson, S., Zappella, L., Gal, Y., Blaas, A., & Goliński, A. Uncertainty Quantification for LLM Function-Calling. arXiv preprint, 2026.

Yan, et al. Berkeley Function Calling Leaderboard (BFCL). 2024.

Kuhn, et al. Semantic Entropy for Natural Language Generation. 2023.

Kadavath, et al. Language Models (Mostly) Know What They Know. 2022.

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
wechat_helper