当LLMs遇上顺序API调用:StateGen与StateEval如何破解测试难题?
Evaluating LLMs on Sequential API Call Through Automated Test Generation
arXiv:2507.09481
Evaluating LLMs on Sequential API Call Through Automated Test Generation
Yuheng Huang, Da Song, Zhenlan Ji, Shuai Wang, Lei Ma
Subjects: Software Engineering (cs.SE); Artificial Intelligence (cs.AI); Computation and Language (cs.CL)
研究背景:LLMs的"工具使用考试"缺了份靠谱的考卷
想象一下,你刚买了一台多功能料理机,说明书上写了20种功能,但你只会用其中3种——不是机器不好,而是没人告诉你怎么把这些功能按顺序组合起来做一顿大餐。大型语言模型(LLMs)现在就面临类似的问题:它们能调用外部API(相当于料理机的功能)来扩展能力,比如用翻译API做跨语言对话、用计算API解数学题,但要让它们把多个API按顺序串起来完成复杂任务(比如"先查天气API,再用日历API预约野餐,最后用消息API通知朋友"),就经常掉链子。
为什么会这样?因为之前评估LLMs的"考试卷"(基准测试)太简陋了:
- 大多是人工出的题,数量少、覆盖窄,像只考了"切菜"却想判断会不会"做满汉全席";
- 批改方式粗糙,比如只看输出文字是不是和标准答案一模一样,不管实际功能对不对(比如调用API后没真正预约成功,却因为文字匹配给了满分);
- 忽略了API之间的"隐藏关系",比如前一个API的输出必须作为后一个的输入,就像打游戏时"拿到钥匙才能开宝箱",但考题里没说清楚这种依赖。
于是,研究者们想:能不能自动出一套更难、更贴近真实场景的"考卷",专门测试LLMs处理顺序API调用的能力?这就是这篇论文要解决的核心问题。
主要作者及单位信息
这篇论文由来自三所高校的研究者合作完成:
- Yuheng Huang、Lei Ma(东京大学,日本)
- Da Song、Lei Ma(阿尔伯塔大学,加拿大)
- Zhenlan Ji、Shuai Wang(香港科技大学,中国)
他们的研究聚焦于LLMs在工具调用领域的评估,试图填补现有测试体系的空白。
创新点:自动"出题"+ 精准"阅卷",LLMs的专属"能力诊断仪"
这篇论文的最大亮点,是提出了两个核心工具:StateGen(自动出题系统)和StateEval(标准化考卷),它们的创新之处在于:
从"人工出题"到"机器自动生成":StateGen能根据API文档,自动生成大量含顺序API调用的可执行程序,就像老师根据教材自动出不同难度的练习题,既高效又多样。
从"死记硬背"到"灵活应用":生成的程序会被转换成自然语言指令(比如"用ElevenLabs的API把这段文字转成女声语音,再调用存储API保存结果"),测试LLMs是否真的理解指令,而不是死记硬背API用法。
从"只看表面"到"深究本质":通过记录程序执行时的状态变化(比如变量值、API返回结果),精准判断LLMs生成的代码是否"真的能跑通",而不是只看语法对不对。
研究方法:StateGen如何"出卷"?分四步走
StateGen的工作流程就像出一份复杂的考卷,拆解开来其实很清晰:
第一步:生成API调用"轨迹"(Trace Generation)
先确定API之间的"合法顺序"。比如调用"查天气API"后才能调用"预约野餐API",不能反过来。StateGen用"状态机"建模这种依赖关系,再通过"能量采样"确保生成的顺序足够多样(比如有时先查温度,有时先查风力),避免重复出题。
第二步:生成完整程序(Program Generation)
在API调用轨迹的基础上,增加"控制流"(比如if-else分支)。比如"如果下雨就取消野餐,调用取消预约API;否则继续调用通知API",让程序更贴近真实场景的复杂性。
第三步:翻译成自然语言指令(Instruction Translation)
让两个LLM"代理"合作:一个把程序翻译成人类能懂的指令(比如"根据天气情况决定是否取消野餐,并通知朋友"),另一个检查指令是否清晰、准确。如果不合格就反复修改,直到符合要求。
第四步:记录"标准答案"(Oracle Generation)
执行生成的程序,记录每一步的状态变化(比如变量值、数据库更新结果),作为评判LLMs输出的"标准答案"。比如调用通知API后,检查朋友是否真的收到消息。
实验:用StateEval给LLMs"考试",结果如何?
研究者用StateGen生成了120道题,组成StateEval基准,覆盖三个场景:
- 会话服务(Session Service):调用RESTful API管理用户会话;
- 张量操作(Tensor Operation):用PyTorch API处理张量计算;
- 语音工具(ElevenLabs MCP):调用文本转语音等API。
然后让5个主流LLM(开源的Qwen2.5-Coder、Llama-4-Scout;闭源的GPT-4.1、Gemini-2.5-Flash等)“考试”,结果很有意思:
闭源LLM表现更好,但仍有提升空间:GPT-4.1总分最高(56%正确率),但离满分还差很远;开源模型平均正确率不到30%。
场景差异明显:所有模型在张量操作上表现最好(GPT-4.1正确率78%),可能因为PyTorch是常用框架,训练数据多;在会话服务上表现最差,因为这类API的公开资料少。
错误集中在"执行"和"结果":大部分错误不是语法错,而是程序能跑但结果不对(比如没正确更新数据库),或执行到一半崩溃(比如张量形状不匹配)。
主要贡献:给LLMs的"工具使用能力"画了张清晰的"体检表"
这篇论文的价值,就像给LLMs的"API调用能力"做了一次全面体检:
提供了自动化测试工具:StateGen能自动生成海量、多样的测试案例,解决了人工出题效率低、覆盖窄的问题。
建立了更难的"评估标准":StateEval比现有基准更复杂(平均每道题含7个API调用,是其他基准的2倍以上),能更真实地反映LLMs在实际场景中的表现。
指出了LLMs的短板:测试发现,LLMs在处理API依赖关系、状态管理上容易出错,尤其是开源模型,为后续改进指明了方向。
一段话总结:
为评估大型语言模型(LLMs)在顺序API调用中的能力,研究提出了StateGen自动测试生成框架和StateEval基准。StateGen通过状态机基于API文档生成含顺序API调用的可执行程序,并经LLM代理转换为自然语言指令;StateEval包含120个手动验证的测试案例,覆盖Session Service、Tensor Operation、ElevenLabs MCP三个场景。评估显示,闭源LLM(如GPT-4.1)表现优于开源LLM,在Tensor Operation任务上表现最佳(GPT-4.1达78%通过率),而Session Service任务所有模型表现较差,LLMs在处理API依赖和状态管理上仍有较大改进空间。
思维导图(mindmap):
详细总结:
1. 研究背景与问题
现有LLMs通过集成外部API扩展了能力,但对其工具使用的测试和评估仍处于早期阶段。多数基准依赖手动收集的测试案例,难以自动检查语义正确性,且忽视了顺序API调用间的复杂交互。现有研究存在局限:依赖手动数据集、聚焦简单API调用场景、缺乏对复杂API编排的评估。因此,研究核心问题是:如何设计自动测试生成方法,系统评估LLMs理解顺序API调用和管理程序状态的能力。
2. StateGen框架设计
StateGen是用于评估LLMs顺序函数调用能力的自动测试生成框架,核心流程包括:
- Trace生成:基于状态机,通过自底向上策略生成有效API序列,结合能量采样和成对转换覆盖引导,确保多样性和有效性。
- 程序生成:注入控制流(如if-else分支),增强程序复杂度,最终输出包含初始化块、控制流和RESULT变量的可执行程序。
- 指令翻译:由生成器和评估器两个LLM代理协作,将程序转换为自然语言指令,确保清晰性和自然性。
- 场景与预言机生成:覆盖三个场景(Session Service、Tensor Operation、ElevenLabs MCP),通过本地执行记录状态转换作为评估基准。
3. StateEval基准构建
利用StateGen生成并手动验证120个测试案例,形成StateEval基准:
- 场景分布:Session Service、Tensor Operation、ElevenLabs MCP各40个案例。
- 关键特点:与现有基准相比,具有更长的指令和代码长度(指令717.08 tokens,代码442.11 tokens)、更多API调用(平均7.16次)、更高路径深度(2.00)和绑定计数(5.03),反映更强的API依赖复杂性。
4. 实验评估结果
研究问题 | 核心发现 |
---|---|
RQ1:StateGen有效性 | 优于无覆盖引导(StateGen-w/o-COV)和LLM-only方法,相邻转换覆盖率更高且收敛更快。 |
RQ2:StateEval与现有基准对比 | 在指令长度、代码长度、API调用数等指标上复杂度更高,更能反映真实API使用挑战。 |
RQ3:LLM在StateEval上的表现 | 闭源LLM表现更优(GPT-4.1达56%通过率),开源LLM差距大(Qwen2.5-Coder为25%);Tensor Operation任务表现最佳(GPT-4.1达78%),Session Service最差。 |
RQ4:LLM错误分析 | 主要错误为执行错误(如数据访问异常、张量形状不兼容)和结果错误(如状态更新失败),语法错误较少。 |
5. 结论与局限
- 贡献:提出StateGen自动测试框架和StateEval基准,揭示LLMs在顺序API调用中的能力与不足。
- 局限:新场景需手动建模API,分析范围有限;未来可自动解析API文档,扩展LLM评估范围。
关键问题:
StateGen框架的核心创新点是什么?
核心创新在于结合状态机建模、能量采样和控制流注入生成多样化顺序API调用程序,并通过多LLM代理协作将程序转换为自然语言指令,实现对LLMs顺序API调用能力的自动化评估,解决了现有手动测试案例的局限性。StateEval基准与现有代码生成基准相比,在复杂度上有何优势?
相比HumanEval、BFCL等基准,StateEval具有更长的指令和代码长度、更多的API调用次数、更高的路径深度和绑定计数,能更有效地评估LLMs处理复杂API依赖和状态管理的能力,更贴近真实世界API使用场景。不同类型LLM在StateEval上的表现差异及原因是什么?
闭源LLM(如GPT-4.1)表现显著优于开源LLM(如Qwen2.5-Coder),因训练数据中相关API资源更丰富;模型在Tensor Operation任务上表现最佳(依赖PyTorch等常见框架的大量数据),在Session Service上最差(资源稀缺且数据操作复杂),表明API熟悉度对性能影响显著。
总结:LLMs的"工具使用课"还得补
这篇论文的核心结论很明确:现有LLMs在处理顺序API调用时,还不够"聪明"。但研究者提供了两个关键工具——StateGen(自动出题)和StateEval(标准化考卷),让我们能更精准地发现LLMs的不足。
未来,随着这些工具的普及,LLMs可能会像学开车一样,从"只会单个操作"进步到"能流畅完成复杂流程",真正成为我们处理复杂任务的得力助手。