大模型Function Calling评测：用同一批工具调用任务比出真实差距
Function Calling 评测真正要测的不是模型能不能吐出一段 JSON，而是它能否在给定工具定义和用户意图下选对工具、填对参数，并在多轮调用中把任务真正完成。
本文给出一套可落地的评测流程：固定工具 schema、构造带标准答案的任务集、用脚本校验参数、按完成率评分，适合正在做模型选型或接口接入的开发者参考。
先明确评测对象和边界
评测前要先把“Function Calling 能力”拆成可测量的几个维度，否则很容易变成人工看输出凭感觉打分。
- 工具选择准确率：用户意图对应多个工具时，模型是否选中正确的那一个。
- 参数填写正确率：必填参数是否齐全，类型、枚举值、格式是否符合 schema。
- 多轮调用能力：需要连续调用两个以上工具时，模型能否根据前一次返回结果决定下一步。
- 异常处理：工具返回错误或缺少信息时，模型是追问用户还是胡乱编造参数。
- 端到端完成率：整条任务链路跑完，最终结果是否正确。
边界也要说清楚：本文的评测针对通过 API 暴露工具定义的模型，不涉及模型内部实现。
不同厂商对工具定义的字段命名和调用格式存在差异，评测脚本需要做适配层，不能直接拿一套请求体套所有模型。
准备一套固定的工具定义
评测结果要可比，工具定义就必须固定。
建议选 3 到 5 个有代表性的工具，覆盖不同参数类型：
{
"name": "get_weather",
"description": "查询指定城市某天的天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名，如 杭州"},
"date": {"type": "string", "description": "日期，格式 YYYY-MM-DD"},
"unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
},
"required": ["city", "date"]
}
}再配一个带枚举和数值范围的工具，例如按价格区间筛选商品，以及一个需要读取上一步结果的工具，例如根据订单号查询物流。
工具描述要写得像真实业务，不要用 foo、bar 这类占位名，否则测不出模型对语义的理解能力。
构造任务集，每条都要有标准答案
任务集建议从 30 条起步，覆盖简单单工具、多工具选择、缺参数追问、参数格式陷阱四类。
每条用例包含用户输入、期望调用的工具名、期望参数和是否需要追问。
示例用例：
{
"input": "帮我查一下杭州明天天气，用摄氏度",
"expected_tool": "get_weather",
"expected_args": {"city": "杭州", "unit": "celsius"},
"need_clarify": false
}陷阱用例要专门设计，比如用户说“查下北京天气”，没给日期，正确行为是追问日期而不是编一个日期；
再比如用户要求“按 100 到 300 元筛选”，要验证模型是否把区间拆成 min_price 和 max_price 两个参数。
用脚本校验参数而不是肉眼比对
拿到模型返回的调用请求后，用校验脚本逐项比对，重点做三件事：
- 用 JSON Schema 校验参数结构，检查必填项、类型和枚举值。
- 与标准答案比对关键参数，城市、日期这类字符串做归一化后再比。
- 记录模型是否调用了不存在的工具，或一次返回多个冲突调用。
伪代码逻辑如下：
for case in cases:
resp = call_model(case.input, tools)
calls = parse_tool_calls(resp)
ok_tool = calls and calls[0].name == case.expected_tool
ok_args = schema_validate(calls[0].args) and match(calls[0].args, case.expected_args)
record(case.id, ok_tool, ok_args)评分时分开统计工具选择准确率和参数正确率，不要合成一个总分，否则无法定位问题出在意图理解还是参数生成。
多轮调用要模拟真实工具返回
单轮评测通过不代表链路可用。
多轮用例需要你写一个假的工具执行器，按预设返回结果，例如第一次调用返回订单号，第二次调用根据订单号返回物流状态。
评测时把上一轮的返回结果原样塞回对话，观察模型是否用对了上一步的输出。
这里最容易出问题的是模型把工具返回的结构化数据当成用户输入，或者重复调用同一个工具。
评分时记录调用次数，超过预期次数就判定为链路异常。
常见坑和验证方式
- 只测 JSON 格式不测语义：格式合法但城市填错，仍应判错，必须以标准答案为准。
- 工具描述写得太模糊：模型选错工具可能是描述问题，不是模型问题，评测前先自查描述是否区分度足够。
- 忽略温度参数：同一用例建议跑 3 次取稳定结果，避免单次随机性误导结论。
- 验证方式：最终输出一张按维度拆分的表格，列出每个模型的工具选择准确率、参数正确率、多轮完成率和平均调用次数，再结合你的实际业务权重做选择。
如果评测中发现某模型在缺参数场景频繁编造日期，这类行为在真实业务里风险较高，选型时应优先排除，而不是只看总体准确率。
