TaskBench 完整指南：3 个阶段构建 28,271 条 LLM 工具调用评估数据

TaskBench 完整指南3 个阶段构建 28,271 条 LLM 工具调用评估数据【免费下载链接】JARVISJARVIS, a system to connect LLMs with ML community. Paper: https://arxiv.org/pdf/2303.17580.pdf项目地址: https://gitcode.com/gh_mirrors/jarvis3/JARVIS为 LLM 构建自动调工具的评估数据有多麻烦人工标注一批用户请求 → 任务步骤 → 工具调用链三元组往往标到一半就发现请求写得含糊、步骤和实际调用对不上、参数类型张冠李戴。JARVIS 项目的 TaskBench 模块给出的解法是用工具图Tool Graph节点为工具、边为调用依赖的有向图自动定义任务骨架再用反向指导Back-Instruct让 LLM 从骨架反推出贴近真实场景的用户请求与标注最后叠加人工核验。本文先摆出数据集规模与质量数字再倒推三阶段构建法与评测流程收尾给出自定义数据时的扩展点与常见坑。先看结论规模与质量数字TaskBench 覆盖三个领域共28,271条样本。每条样本包含用户请求user request、任务步骤task steps和工具调用图invoking graph含节点与依赖边可直接作为LLM 任务自动化能力的评测基准。领域数据目录样本数自动质检通过人工核验通过Hugging Face Toolsdata_huggingface12,21769.22%61.76%Multimedia Toolsdata_multimedia8,90470.54%62.71%Daily Life APIsdata_dailylifeapis7,15075.97%60.42%三个领域的结构分布按工具调用图拓扑领域single单工具chain链式dag有向无环图Hugging Face Tools3,0673,642837Multimedia Tools2,0372,982565Daily Life APIs1,2582,787275工具图怎么建两种依赖类型决定图的形状工具库是一个 JSON包含每个工具的描述与参数。TaskBench 支持两种工具格式对应两种依赖类型这也是后续所有脚本中--dependency_type参数的来源依赖类型适用工具工具库要求字段建边规则resource资源依赖有明确输入/输出类型的工具如多媒体处理input-type/output-type仅当 A 的输出类型与 B 的输入类型有交集时才连边temporal时间依赖带请求参数的 API如查天气、发短信parameters参数名/类型/说明任意两个工具间均可连边边表示调用先后以多媒体领域为例tool_desc.json中一条节点形如Image Downloader输入url、输出image与Video Synchronization输入含video、audio之间就能自动生成一条资源依赖边。命令python generate_graph.py --tool_desc 工具描述文件 --dependency_type resource --data_dir 输出目录参数--dependency_type图类型resource或temporal决定建边规则参数--tool_desc工具库路径省略时回退读取--data_dir下的graph_desc.json输出生成graph_desc.json节点 边一个常被忽略的点README 明确提示自动生成的图未必合理建议用visualize_graph.py渲染后人工修正——这一步决定了后续所有环节的上限因为采样与生成都在这张图上做。三阶段生成采样子图再让 LLM 反向写出请求与标注数据引擎 data_engine.py 对每条样本执行采样 → 生成 → 自检三步。采样策略结构权重决定难度分布data_engine.py内置了两组权重默认值采样方式权重single单节点 3chain链 7dagDAG 8——链与 DAG 占大头贴近真实任务以多步调用为主工具数量权重非 single 时生效2 个工具 10%、3 个 20%、4 个 30%、5 个 20%、6 个 10%、7~10 个各 2.5%DAG 采样最少 3 个节点权重在脚本main()内的method_weights/number_weights两个字典中可按评估需求调整。Back-Instruct从子图反推请求采样得到子图后脚本把节点 描述 类型/参数与边调用链拼进 prompt要求 LLM 一次性输出三部分task_steps任务步骤、user_request自包含、可直接求解的用户请求、invoking_graph工具调用图资源依赖下节点带input时间依赖下节点带arguments。prompt 内置的硬约束保证了标注一致性任务步骤与工具图节点/边严格对齐步骤数 节点数每个工具只用一次请求必须自包含所需文本/图片/视频/音频都写在请求里资源文件用example.[jpg/mp4/wav/png]占位参数数量与类型必须匹配工具的输入/输出类型定义生成即质检节点与边的一致性比对生成结果解析后脚本把 LLM 输出的invoking_graph与采样子图的节点 id、边集合分别排序比对不一致即记 fail 并落日志。开启--check时LLM 还会额外填写check_by_teacher字段以教师口吻逐条评估生成图的 Executable可执行与 Correct与给定工具图严格一致相当于一次 LLM-based 自检查。参数--temperature生成多样性README 推荐 1.0、--top_p采样截断参数--dependency_type须与工具图类型一致参数--check启用教师自检字段参数--use_async/--multiworker异步并发与并发数参数--api_addr/--api_port/--api_keyOpenAI 兼容服务地址默认localhost:4000质量怎么把关双 critic 人工核验LLM-based 与 Rule-based 双通道两条自动检查通道都基于生成结果与采样工具图的对齐LLM-based criticcheck_by_teacher字段里的自检查结论Rule-based critic纯规则直接比对节点与边的集合是否一致领域LLM 检查通过规则检查通过双通道都通过Hugging Face Tools74.01%84.22%69.22%Multimedia Tools78.16%82.69%70.54%Daily Life APIs79.63%87.70%75.97%人工核验正确、废弃、修复三档双通道通过的样本再进人工环节检查三个维度指令语法、工具调用图正确性、调用参数正确性。最终处置分为三档领域进入人工核验直接正确废弃修复语法修复指令修复调用图Hugging Face Tools8,45782.46%10.77%0.32%3.87%9.96%Multimedia Tools6,28183.77%11.09%0.17%1.70%9.96%Daily Life APIs5,43279.29%13.14%0.11%1.68%6.11%修复样本以工具调用图居多约 6%~10%说明 LLM 生成时最容易出错的正是依赖边的对齐——这也解释了为什么双通道质检都以节点 边为核心。每个领域目录最终落盘 4 个文件data.json样本、graph_desc.json工具图、tool_desc.json工具描述、user_requests.json用户请求推理时只读这个文件。跑起来推理、评估与排行榜读数评测框架的三个维度评测环节指标任务分解task decompositionRouge-1、Rouge-2、BertScore F1工具调用tool invocation节点 F1n-F1、边 F1e-F1依赖关系是否正确参数预测parameter prediction参数名 F1t-F1、参数值 F1v-F1两步跑完评测环境Python 3.8pip install -r requirements.txt评开源模型推荐用fastchatvllm把服务部署到localhost:4000推理python inference.py --llm gpt-4 --data_dir data_multimedia --temperature 0.2 --top_p 0.1 --multiworker 5 --dependency_type resource预测结果写入{data_dir}/predictions/{llm}.json评估python evaluate.py --data_dir data_multimedia --prediction_dir predictions --llm gpt-4 --splits all --n_tools all --mode add -m all结果落到metrics目录的 JSON可按任务结构 × 工具数量分档查看排行榜怎么读三个领域各取三行完整 17 个模型的榜单见 taskbench/README.md领域模型R1R2BsFn-F1e-F1t-F1v-F1Multimediagpt-460.8440.0891.1990.9069.2787.0672.31Multimediaclaude-248.8523.5989.2280.9453.0171.6351.58Hugging Facegpt-452.4230.3890.1281.5454.7077.3160.86Hugging Facegpt-3.5-turbo42.9921.5888.4769.4933.3655.8836.32Daily Lifegpt-485.0772.3696.9196.9180.5397.0271.14Daily Lifecodellama-13b89.8683.2797.9087.7363.1684.2662.38注意 Daily Life 一栏codellama-13b 的 R1/R2/BsF 反而高于 gpt-4但 n-F1、t-F1、v-F1 仍落后——文本层面的分解接近不等于工具调用与参数预测达标这是读评估结果时最容易踩的误判。扩展到自定义领域参数对应关系与常见坑三步扩展流程写工具库支持两种格式——资源依赖工具必须有id/desc/input-type/output-typeAPI 工具必须有id/desc/parameters每项含name/type/desc生成工具图generate_graph.py依赖类型与工具格式对应生成样本data_engine.py跑完后再过format_data.py--data_dir 目录 --dependency_type 类型把data_raw.json转成data.json与user_requests.json不合格样本写入data_error.json容易踩的坑--dependency_type必须与工具库字段匹配带input-type的库用resource带parameters的库用temporalresource类型仅支持data_huggingface与data_multimediainference.py中有硬断言data_dailylifeapis必须用temporal自动生成的工具图建议人工修正后再跑生成否则质检通过率会明显下滑生成中断后用--data_dir指向已有结果目录即可续跑脚本会跳过已完成样本并自动从目录内读取graph_desc.json/tool_desc.json样本结构分布想调改data_engine.py里的method_weights/number_weights完整流程与 17 个模型的榜单在 taskbench/README.md评估指标实现见 taskbench/evaluate.py数据格式转换见 taskbench/format_data.py。跑评测或构建数据遇到问题可在 JARVIS 仓库gitcode.com 上的 gh_mirrors/jarvis3/JARVIS提交 issue。【免费下载链接】JARVISJARVIS, a system to connect LLMs with ML community. Paper: https://arxiv.org/pdf/2303.17580.pdf项目地址: https://gitcode.com/gh_mirrors/jarvis3/JARVIS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考