原创 孔某人 2024-11-19 16:35 北京
一地鸡毛的LLM tool支持现状，补全了目前常见模型厂的中高端模型。
本文和之前的LongContext测试一样，是我个人自力进行的测试。测试的代码和数据开源，供大家复现和拓展。
开源地址：
https://github.com/SomeoneKong/llm_tool_test_202411之前的LongContext测试问题缺乏实际应用中的代表性，所以这次是一个更加贴近实际实际LLM应用中可能会涉及的场景，数据多样性也进行了改进。
本次的测试的能力要求是综合性的，实际不止限于单纯的tool调用，还涉及到：
复杂指令理解和跟随能力
4k-8k左右context的能力
能够先产生一段回答，在过程中触发调用tool的能力（有些厂家似乎仍然还没实现该功能）
能够稳定地区分生成json和产生tool调用
2024.8横向对比各家LLM的Long Context 【V1.20】
首先得说，这个测试是比较难的。一些模型的表现没有大家自己使用的时候感觉好，是因为这个测试任务综合要求的点很多，并非一个简单的意图分类。
不过从构建测试方案的角度，足够难才是需要的，我们不需要一大堆接近满分的benchmark。
1.1、测试任务描述
本次测试方案取材于一个真实业务场景，原本没有tool调用，但由于在该场景下LLM算简单多个整数加法仍然会错的很离谱，所以尝试加入tool调用来辅助计算，却因此发现了一个大坑。当然本次测试的prompt并非原始业务prompt，已经经过了简化，但仍然保留了真实业务场景下的很多特征。
以及单就具体这个任务来说，这并非最好的实现实现方式，因为现在国内能用上的LLM tool能力在此问题下大多都很糟糕，而且还有的优化方式。所以对于真正做这类问题的读者，该prompt的设计思路不建议参考。而对于不做这类问题的读者，这个prompt已经足够能够代表某种真实业务的场景的需求。
测试的prompt模板如下：
以下是一个访谈录音的语音识别结果，需要将其按讨论的具体内容分割为多个小节。语音识别结果如下：```text{asr_text}```Step 1 总结整个输入文本每段的主题。总结每个主题的内容，并指名其开始和结束位置。每个主题的第一个block_idx 记为block_start_idx，最后一个block_idx记为block_last_idx。输出格式为：topic 1:- block_start_idx: xxx- description: <主题描述>- block_last_idx: xxx...Step 1.1 逐个计算每个topic的token_num。topic的token是topic包含的所有block的token_num之和。要调用calc_topic_token_batch进行计算，以获取最准确的结果。Step 2 优化topic的选择和分割位置。优化主题分割的规则：* 分析每个topic的语义完整性，尽量避免分割点不会打断完整的讨论。* 不要把不相邻的topic合并在一起。* 如果一个topic的token_num超过 {topic_token_num_limit} ，则要将这个topic拆分为多个topic。* 对于调整后的topic，要重新计算token_num。* 如果调整后的topic的token_num超过 {topic_token_num_limit}，则要继续思考如何调整topic的分割位置，例如将其切分为更小的topic。Step 3 整理输出结果。使用json格式进行输出，格式见下面的完整回答格式。请以以下的过程进行回答，当遇到函数调用返回后要接续上一次的回答位置继续回答。------Step 1 总结整个输入文本每段的主题。...Step 1.1 计算每个topic的token_num。要调用calc_topic_token_batch进行计算。...Step 2 优化topic的选择和分割位置。...Step 3 以json格式整理输出结果。{{ "topic_list": [ {{ "topic_description": str, "block_start_idx": int, "block_last_idx": int }}, ... ]}}tool配置如下
{ "type": "function", "function": { "name": "calc_topic_token_batch", "description": "计算topic的token num", "parameters": { "type": "object", "properties": { "topic_list": { "type": "array", "items": { "type": "object", "properties": { "topic_id": {"type": "integer"}, "start_block_idx": {"type": "integer"}, "last_block_idx": {"type": "integer"}, }, "required": ["topic_id", "start_block_idx", "last_block_idx"] } } }, "required": ["topic_list"] } }}在整个过程中，Step 1.1处应该必然进行一次调用。完整的过程中，在Step2中可能还会进行多轮tool调用，但那不在本次评价范围之内。
由于本次发现的问题实在太多，所以temperature仅取0.01，暂时不再设置更高temperature的组来进一步提高难度。
测试数据选择100个不同的文本段进行测试，由于目前各家LLM限速都较低，而且目前看起来100次评估已经足够有区分性，所以不再对于同一个输入进行多次抽样。
1.2、测试结果评价方式
这个测试任务没有唯一的答案，文本的分割方式可以有多种，也很难自动评价。所以测试评价主要集中于：
LLM是否能够在Step 1.1处正确触发tool调用，并给出合法的参数输入
第二次调用，提供tool结果后，LLM是否能够正确的继续进行。
如果请求中出现限流、偶然错误（不能正确返回结果）等，不计入失败，会重试来补全结果。
被风控的case不列入不符合期望，如果一个case被风控的供应商较多则会替换数据。一个模型的表现会按照剩余未被风控的case数量进行比例计算。
最终会给出每轮tool调用的“符合期望率”作为综合指标，主要的失败情况包括：
不能触发tools调用
一上来就触发tool调用，没有前面步骤的回答。
tools调用的函数名不匹配或参数不符合要求
返回tools调用结果后不能正确的继续执行
虽然tool给的是batch输入，但如果LLM将其拆分为多个tool调用也认为可以接受。
实际上很多家都有一些很奇怪的个性错误，具体见后续各家结果的单独说明。
3.1、Anthropic Claude（0.5）
Claude目前在国内可用性较差，封号力度较强，大多是使用第三方中转商或者海外openrouter进行请求。国内中转商大多不支持Claude模型的tool调用，我截至目前没发现可用的。通过openrouter进行tool请求时，会在返回tool调用结果后第二次请求时卡住，原因未知。
自己注册Claude账号难度尚可，但官方的请求日限额非常低，很难在实际业务中使用。
但从测试结果来说，Claude 3.5代是完美的，claude-3.5-sonnet-20241022和claude-3.5-haiku都能够达到100%。
claude-3-haiku看起来明显是上代方案了，不能在回答过程中产生tool调用。
3.2、OpenAI GPT
OpenAI的tool可用性是海外三家里最好的，openrouter没问题，GPT-4o符合期望率也很高。
但GPT-4o-mini的效果就较差了，会跳过前置步骤直接生成tool调用，并且生成的tool调用中还有明显的重复。
3.3、Google Gemini（0.5）
Gemini本身的python SDK本身比较混乱，分为 google-generativeai （genai） 和 google-cloud-aiplatform （vertexai）两套。此外还有OpenAI兼容接口和HTTP接口。目前两套python SDK和OpenAI的接口在测试项目中均已经适配完成。
个人账号用vertexai的会有比较低的并发限制，我也未作太多测试，建议用genai的，本次测试也使用此接口。
OpenAI的兼容接口我测试来看是基于其他接口包的，不能够正确透传后台的一些错误信息等，bug较多，不建议使用。
以genai接口为例，对于gemini-1.5-pro模型，能够看到在触发了function call调用后，并没有像其他家一样停止，而是后续直接开始生成其他part。后续内容没有function response的信息，没有意义，后续再对话时也会影响下一轮的回答，需要在client端手工剔除掉第一次function response之后的其他part。这在我来看属于一个明显的bug。OpenAI兼容端不会保留part的边界，所以在此情况下无法在client端做简单的剔除。
gemini-1.5-flash版本有比较高的比例会报MALFORMED_FUNCTION_CALL错误，感觉是bug。
虽然gemini系列在本次测试指标上看起来仍然较高，但个人从第二轮回答结果来看，感觉其在海外的三家里tool能力相对较差，不是很建议在目前版本使用其tool功能。
3.4、阿里巴巴 Qwen
本次测试使用qwen的OpenAI兼容接口测试。
Qwen这次的表现在国内大幅领先，中高端模型的符合期望率都很高。
如果Qwen能够像字节一样把默认的RPM和TPM限制给更大就好了，现在感觉明显是速率限制拖累了qwen API的应用。
qwen2.5-32b-instruct相对于其他模型本就不高的RPM和TPM限制进一步降低了，很奇怪。
3.5、智谱 GLM
本次仅选择了glm-4-plus和glm-4-0520进行测试，glm-4-0520几乎全挂，无法正确触发tool调用，会生成一个python代码放在回答中。
3.6、阶跃星辰 Step
step-1-8k的表现不错，但step-2-16k就出现大量不能触发调用的问题。
3.7、Moonshot
moonshot-v1-8k有几个tool args的json被截断，疑似超过最大context长度，然后改用moonshot-v1-32k。
几个参数错误是tool 参数args输出时被截断，原因未知。
3.8、深度求索 DeepSeek
deepseek-chat大部分时候无法触发tool调用，颇为可惜。
3.9、字节跳动 Doubao
本次测试使用字节的OpenAI兼容接口测试。
Doubao-pro-32k-functioncall-241028 的参数错误主要有几类：1、丢失外层object结构，只有数组；2、缺失topic_id。
3.10、百川智能 Baichuan
Baichuan4-Turbo的参数错误基本都是缺失topic_id的问题。
3.11、百度 ERNIE
本次测试使用百度的OpenAI兼容接口测试。
ernie-4.0和ernie-4.0-turbo看文档似乎还不支持tool调用，主力最强模型还不支持tool调用。
由于ERNIE模型的输入context长度限制，只能使用ernie-3.5-128k模型进行测试。即使如此还会有些测试请求报错：
{'code': 'tokens_too_long', 'message': 'Prompt tokens too long', 'type': 'invalid_request_error'}ernie-3.5-128k的参数错误大多是生成了错误的block_idx。
3.12、腾讯 hunyuan
本次测试使用腾讯的OpenAI兼容接口测试。
腾讯混元系列同样也是主力最强模型还不支持tool调用，只有一个似乎更小模型的hunyuan-functioncall特化版。
hunyuan-functioncall的参数错误基本都是缺失topic_id的问题。
3.13、商汤 SenseChat （V0.5）
本次测试使用商汤的OpenAI兼容接口测试。
商汤的SenseChat-5有时候会误返回一个interpreter调用当作tool调用。
SenseChat-5的参数错误基本都是缺失topic_id的问题。
3.14、Minimax abab （V0.5）
本次测试使用Minimax的OpenAI兼容接口测试。
Minimax的OpenAI兼容接口的tool设置不遵从于OpenAI标准，需要额外吧function parameters转成json字符串。
3.15、Meta LLama 3.1（V0.5）
Llama没有官方的API，所以选择从openrouter上的一些供应商进行测试。
看起来大部分Llama 3.1模型的第三方推理在本测试上的效果都较差。
3.16、MistralAI Mistral（V0.5）
刚发布的mistral-large-2411在本测试上表现也较差。
由于其请求速度较慢，到本期截稿时仍没有出完整结果，所以本次数据先忽略它，已有数据上是100%无法触发tool调用。
3.A、讯飞 Spark （V0.5）
使用讯飞的HTTP接口进行测试。
虽然该接口协议很类似OpenAI，但返回的tool调用并不符合OpenAI协议。第二步请求时总是无法成功，也没有返回任何错误码和错误信息，只能作罢。
一年多之前，我就在发文说tool调用对上层应用是很有价值的功能。但直到现在，这个评测的结果看下来，可能我们仍然不能再模型供应商受限的条件下使用tool。目前看下来感觉只有claude 3.5系列、gpt-4o、qwen 2.5系列和qwen闭源的9月份系列是可以的。Gemini还有一些问题需要打磨。
现在国内应该是所有模型厂都宣称自己有tool的能力，但实际上能够不是特化版本，能够集成到其最强模型上的大概只有一半左右。
第三方推理提供商在一些复杂问题上质量良莠不齐，在用openrouter的时候最好留意和指定特定供应商。
从结果上来看，在本测试中的效果也惨不忍睹，甚至已经得说目前要使用tool的话，得认真得评估候选模型在这方面的能力。
希望这次的地图炮能够推动各家模型厂商改进tool的能力吧。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，获取联系方式请点击 -> 联系方式。
本文V0.1于2024.11.18首发于微信公众号和知乎，V0.5版本发布于 2024.11.19。
知乎链接：https://zhuanlan.zhihu.com/p/7570655613
