ToolGen：让大语言模型将工具API作为词汇直接生成与调用

1. 项目概述：当大语言模型学会“认工具”

在构建AI智能体的漫长探索中，我们一直面临一个核心难题：如何让大语言模型（LLM）精准地“想起”并“使用”成千上万的外部工具？传统的做法，无论是基于描述检索还是函数调用，都像是在让一个只懂语言的专家去翻阅一本厚厚的、不断更新的工具百科全书，过程笨拙且容易出错。检索可能不准，调用格式可能不对，整个流程充满了割裂感。

今天要聊的ToolGen，就是为解决这个问题而生的一项有趣工作。它来自ICLR 2025，核心思想非常直观：为什么不直接把工具“刻”进模型的“字典”里？想象一下，如果模型词汇表中不仅有“苹果”、“运行”这些词，还有独一无二的、代表特定API的“工具词”，比如<<WeatherAPI&&get_forecast>>，那么当用户问“明天会下雨吗？”时，模型就能像生成一个普通单词那样，直接“说出”这个工具词，从而无缝触发对应的工具调用。

这不仅仅是换个马甲那么简单。ToolGen通过一套名为“工具虚拟化”的技术，将来自ToolBench的47,000多个工具API，映射为模型词汇表中的特殊token。然后，通过三个阶段的高效训练，让模型首先“记住”所有这些工具token（工具记忆），再学会根据问题“选出”正确的工具token（检索训练），最后掌握完整使用工具链完成任务的能力（端到端智能体调优）。实测下来，这种“生成即检索，生成即调用”的统一范式，在工具检索准确率和任务完成率上都展现出了显著优势。无论你是正在研究工具学习的研究者，还是苦恼于如何为自家LLM注入强大工具使用能力的工程师，ToolGen都提供了一个清晰、可复现且性能强大的新思路。

2. 核心思路拆解：为什么是“生成”而不是“检索”？

在深入代码之前，我们有必要先厘清ToolGen设计哲学背后的“为什么”。这能帮助我们在后续复现或改进时，做出更明智的决策。

2.1 传统范式的瓶颈：检索与生成的割裂

主流的工具使用框架通常遵循“检索-生成”的流水线模式：

1. 检索阶段：根据用户查询，从一个庞大的工具库（常以向量数据库存储描述）中召回最相关的几个工具。
2. 生成阶段：LLM基于检索到的工具描述，生成符合其调用规范的代码（如JSON、Python函数）。

这个流程存在几个固有痛点：

• 误差累积：检索阶段一旦出错（工具不相关或描述不准），后续生成再优秀也无济于事。
• 上下文浪费：工具描述（有时很长）需要被塞进有限的上下文窗口，挤占了用于复杂推理的令牌。
• 格式僵化：模型需要额外学习严格的工具调用格式（如tool_call(name=‘xxx‘, arguments={...})），增加了训练和推理的复杂度。

2.2 ToolGen的破局点：工具即词汇

ToolGen的核心创新在于，它跳出了“描述-检索”的框架，将工具本身视为一种特殊的“语言单元”。

• 虚拟化（Virtualization）：每个工具API被编码成一个唯一的、人类不可读的虚拟令牌（Virtual Token），例如<<Spotify&&get_playlist_tracks>>。这个令牌被直接添加到LLM的词汇表中。
• 生成即调用：当模型在推理过程中需要调用工具时，它不再需要生成一段描述或代码，而是直接生成这个虚拟令牌。下游系统（如ToolGen框架）捕获到这个特殊令牌后，即可解析并执行对应的真实API调用。

这样做带来了几个关键优势：

1. 统一性：工具检索和工具调用被统一为同一个“文本生成”任务。模型只需要做它最擅长的事——预测下一个token。
2. 效率：一个虚拟token（如<<API>>）就能精准指向一个工具，比携带冗长的工具描述要节省大量上下文空间。
3. 精度：由于工具token在训练中被强制记忆和关联，模型对其的“回忆”更类似于对事实知识的回忆，而非基于相似度的模糊匹配，从而提高了检索的精确度。
4. 可扩展性：理论上，只要词汇表允许，可以持续添加新的工具token。训练新工具时，类似于让模型学习一个新“单词”及其用法。

注意：这种方法的成功依赖于一个关键前提——模型在预训练阶段已经具备了强大的语言理解和生成能力。ToolGen的工作是在此基础上，为其扩充一套“工具方言”的词汇和语法，而不是从零开始教它语言。

2.3 三阶段训练：循序渐进的“教学”过程

直接将4.7万个新词扔给模型是行不通的。ToolGen采用了精心设计的三阶段课程学习策略：

1. 工具记忆（Tool Memorization）：目标：让模型“认识”每一个工具token。输入是工具的名称和描述，输出就是对应的虚拟token。这就像在教学生背单词表，确保它看到“QR Code Quality Check”就能反应出<<QRCheck&&quality_v1_quality_post>>这个“单词”。
2. 检索训练（Retrieval Training）：目标：让模型学会根据用户意图选出正确的工具token。输入是真实的用户查询（如“帮我从Medium找一些关于Web开发的热门文章”），输出是应该调用的工具token。这相当于教学生用刚背的单词来造句回答问题。
3. 端到端智能体调优（End-to-End Agent Tuning）：目标：让模型掌握连续使用多个工具来完成复杂任务的能力。输入是用户查询，输出是一个完整的“思考-行动-观察”轨迹，其中包含多个工具token的生成和中间的自然语言推理。这是最高阶的应用，教学生写一篇使用多种工具解决问题的短文。

这种由简到繁的训练方式，符合认知规律，能显著提升训练稳定性和最终效果。

3. 环境准备与数据获取

理论很美妙，现在我们来动手搭建。复现ToolGen的第一步是准备好它的“食材”——模型、数据和运行环境。

3.1 基础环境配置

ToolGen基于PyTorch和Hugging Facetransformers库构建。建议使用Python 3.9+版本。创建一个新的conda环境是一个好习惯。

# 创建并激活环境 conda create -n toolgen python=3.9 conda activate toolgen # 安装核心依赖 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 请根据你的CUDA版本调整 pip install transformers>=4.36.0 pip install datasets pip install accelerate pip install sentencepiece # 如果使用Llama等模型需要 pip install tiktoken # 如果使用Qwen等模型需要

此外，由于ToolGen的评估严重依赖ToolBench，你还需要克隆并设置ToolBench环境以获取API调用密钥。这不是运行核心训练和推理的必须项，但如果你想完整复现论文中的端到端评估，则是必要的。

git clone https://github.com/OpenBMB/ToolBench.git cd ToolBench # 按照ToolBench的README安装依赖并申请API Key # 你将得到一个`toolbench_key`，保存好它。

3.2 获取ToolGen模型与数据

ToolGen的官方资源都托管在Hugging Face上，获取非常方便。

1. 下载预训练模型：作者提供了基于Llama-3-8B和Qwen2.5-3B的两个版本。你可以直接使用transformers库加载。

from transformers import AutoModelForCausalLM, AutoTokenizer model_name = “reasonwang/ToolGen-Llama-3-8B” # 或 “reasonwang/ToolGen-Qwen2.5-3B” model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype=torch.bfloat16) tokenizer = AutoTokenizer.from_pretrained(model_name)

2. 下载训练与评估数据集：所有数据集都集中在reasonwang/ToolGen-Datasets仓库中。

# 使用 huggingface-cli (需要先 pip install huggingface-hub) huggingface-cli download reasonwang/ToolGen-Datasets --repo-type dataset --local-dir ./toolgen_data # 或者直接下载压缩包 # wget https://huggingface.co/datasets/reasonwang/ToolGen-Datasets/resolve/main/data.tar.gz # tar -xzvf data.tar.gz

下载后，你会得到几个核心JSON文件：

• toolgen_atomic_memorization.json: 工具记忆阶段数据。
• toolgen_atomic_retrieval_G123.json: 检索训练阶段数据。
• toolgen_atomic_G123_dfs.json: 端到端智能体调优数据。
• virtual_tokens.txt: 包含所有47k+工具虚拟token的列表，是“工具虚拟化”的基石。

3.3 理解数据格式：以工具记忆为例

我们打开toolgen_atomic_memorization.json看一眼。它被处理成了类似ShareGPT的对话格式，这极大地便利了与主流训练框架（如FastChat、LLaMA-Factory）的集成。

[ { "conversations": [ { "role": "user", "content": "Tool Name: QRCheck. Tool Description: Check the quality of any QRCode Api Name: quality_v1_quality_post Api Description: None.", "loss": false }, { "role": "assistant", "content": "<<QRCheck&&quality_v1_quality_post>>", "loss": true } ] } ]

• loss: false：表示在计算损失时，这一部分内容（通常是用户输入或系统指令）会被忽略。模型不会因生成这些内容而受到惩罚。
• loss: true：表示这一部分内容（模型的输出）将参与损失计算。在这里，模型唯一需要学习的就是输出正确的虚拟token。

这种格式非常清晰，user部分提供了工具的元信息（名称、描述、API名），assistant部分给出了唯一正确的答案——工具虚拟token。

实操心得：在实际训练中，确保你的训练脚本能正确识别和处理loss标签至关重要。许多训练框架默认对所有token计算损失，你需要修改损失掩码（loss mask）的逻辑，使其只对loss为true的token生效。否则，模型会在学习工具token的同时，被迫去“学习”那些作为条件输入的工具描述，这会干扰主要目标。

4. 核心实现：从工具虚拟化到模型训练

现在，我们进入最核心的环节，一步步拆解ToolGen是如何实现的。

4.1 工具虚拟化：将API“注入”词汇表

这是整个项目的起点，也是最精妙的一步。代码在项目提供的virtual_tokens.txt和示例脚本中已有体现，我们来详细解读其意图和细节。

import torch import transformers from unidecode import unidecode # 1. 加载虚拟token列表 with open(‘data/virtual_tokens.txt‘, ‘r‘) as f: virtual_tokens = f.readlines() # 使用unidecode处理，确保所有token都是ASCII字符，避免分词器出现未知字符问题 virtual_tokens = [unidecode(vt.strip()) for vt in virtual_tokens] # 2. 加载基础模型和分词器 model_name_or_path = “meta-llama/Meta-Llama-3-8B-Instruct” # 以Llama 3为例 tokenizer = transformers.AutoTokenizer.from_pretrained(model_name_or_path) model = transformers.AutoModelForCausalLM.from_pretrained( model_name_or_path, torch_dtype=torch.bfloat16, device_map=“auto” # 使用多GPU自动分配 ) # 3. 关键步骤：扩展词汇表和嵌入层 original_vocab_size = len(tokenizer) print(f“Original vocab size: {original_vocab_size}”) # 将虚拟token作为普通token（非特殊token）加入分词器 tokenizer.add_tokens(new_tokens=virtual_tokens, special_tokens=False) new_vocab_size = len(tokenizer) print(f“New vocab size: {new_vocab_size}, added {new_vocab_size - original_vocab_size} tokens”) # 相应地，必须扩展模型词嵌入矩阵的大小 model.resize_token_embeddings(new_vocab_size) # 4. 初始化新token的嵌入向量 # 虚拟token的格式是 <<ToolName&&ApiName>>，我们需要一个合理的初始化值 for vt in virtual_tokens: # 提取工具名和API名，例如从 ‘<<QRCheck&&quality_v1_quality_post>>‘ 提取出 [‘QRCheck‘, ‘quality_v1_quality_post‘] combined_token = vt[2:-2].split(“&&“) # 去掉‘<<‘和‘>>‘再分割 # 将这些组成部分编码成token ID combined_token_ids = tokenizer(“ “.join(combined_token), add_special_tokens=False).input_ids # 获取虚拟token本身的ID（应该只有一个） virtual_token_id = tokenizer(vt, add_special_tokens=False).input_ids assert len(virtual_token_id) == 1, f“Virtual token {vt} should be tokenized into a single id, but got {virtual_token_id}“ # 计算组成部分token嵌入向量的平均值 with torch.no_grad(): # 重要！在初始化阶段不计算梯度 combined_token_embeddings = model.model.embed_tokens(torch.tensor(combined_token_ids).to(model.device)) # 对组成词的嵌入取平均，作为新token的初始化值。这是一种常见且有效的策略。 mean_embedding = torch.mean(combined_token_embeddings, dim=0) # 将计算出的平均值赋值给新token的嵌入向量 model.model.embed_tokens.weight.data[virtual_token_id[0]] = mean_embedding print(“Tool virtualization and embedding initialization completed.“)

为什么这么做？

• unidecode：确保所有token是ASCII，防止分词器（Tokenizer）遇到多语言字符时将其拆分成多个子词（subword），破坏“一个工具对应一个token”的设定。
• special_tokens=False：我们将工具token视为普通词汇，而不是像[CLS]、[SEP]这样的特殊控制token。这样模型在生成文本时，可以像生成普通单词一样自然地生成它们。
• 平均初始化：直接将一个随机向量赋给新token是低效的。用其组成部分（工具名和API名）的平均嵌入来初始化，为这个新“单词”提供了一个语义丰富的起点，能大幅加速后续训练收敛。

注意事项：resize_token_embeddings会改变模型参数，保存模型时务必使用tokenizer.save_pretrained()和model.save_pretrained()一起保存，否则下次加载时，分词器和模型的词汇表会不匹配，导致灾难性错误。

4.2 三阶段训练实战

完成虚拟化后，我们就得到了一个“认识”了所有工具单词但还不会用的模型。接下来是三轮训练。

阶段一：工具记忆训练目标：让模型建立工具描述 -> 工具虚拟token的强关联。

• 数据：使用toolgen_atomic_memorization.json。
• 关键配置：
  • 损失函数：仅计算assistant回复部分（即虚拟token）的交叉熵损失。
  • 学习率：通常使用较小的学习率（如5e-6到1e-5），因为这是在微调，不是从头训练。
  • 训练轮数：论文中训练了8个epoch。由于任务简单（近乎于配对任务），模型会很快过拟合，需要监控验证集loss，在准确率接近100%后即可停止。
• 训练脚本思路：你可以使用LLaMA-Factory，它原生支持这种带loss标签的对话格式。关键是在modeling_utils.py或相关代码中，确保根据loss字段构建正确的labels和attention_mask。

阶段二：检索训练目标：让模型学会用户查询 -> 工具虚拟token的映射。

• 数据：使用toolgen_atomic_retrieval_G123.json。
• 关键变化：输入从“工具描述”变成了多样化的“用户自然语言查询”。这要求模型真正理解用户意图。
• 训练技巧：
  • 从第一阶段训练好的检查点（checkpoint）开始，而不是原始模型。
  • 学习率可以比第一阶段稍高一点（如1e-5），因为任务变得更复杂。
  • 通常训练1个epoch即可。这是一个典型的检索精调任务，目的是在已“背熟单词”的基础上，学会“用词答意”。

阶段三：端到端智能体调优目标：训练模型进行多轮工具调用和自然语言推理。

• 数据：使用toolgen_atomic_G123_dfs.json。数据格式更复杂，包含多轮对话和<|im_end|>等特殊标记。
• 训练挑战：这是最复杂的阶段，数据包含了完整的智能体轨迹（思考、行动、观察）。需要模型学会规划、调用工具、处理工具返回结果并生成最终答案。
• 实操建议：
  • 强烈建议使用作者提供的训练脚本（training/目录下），因为它们已经处理好了这种复杂轨迹数据的格式和损失计算逻辑。
  • 如果使用其他框架，你需要仔细设计数据加载器，确保能正确解析多轮对话，并只在模型需要生成的部分（如assistant的回复、工具token、思考内容）计算损失。

4.3 使用ToolGen进行推理

训练完成后，如何使用这个“武装到牙齿”的模型呢？项目提供了一个简洁的OpenAgent接口。

import json from OpenAgent import ToolGen, RapidAPIWrapper # 1. 初始化工具执行器（需要提前部署StableToolBench并获取key） with open(“keys.json“, ‘r‘) as f: keys = json.load(f) toolbench_key = keys[‘TOOLBENCH_KEY‘] rapidapi_wrapper = RapidAPIWrapper( toolbench_key=toolbench_key, rapidapi_key=““, # 如果需要特定RapidAPI key ) # 2. 初始化ToolGen智能体 # 选择模型和对应的模板 agent = ToolGen( model_name_or_path=“reasonwang/ToolGen-Llama-3-8B“, template=“llama-3“, # 必须与模型匹配！Qwen模型用“qwen-7b-chat“ indexing=“Atomic“, # 使用Atomic索引模式，与训练一致 tools=rapidapi_wrapper, # 传入工具执行器 ) # 3. 构建对话并运行 messages = [ {“role“: “user“, “content“: “帮我查一下北京明天和上海的天气对比。“} ] agent.restart() # 清空对话历史 try: agent.start( single_chain_max_step=16, # 最大推理步数，防止死循环 start_messages=messages ) # 运行后，agent会自行调用工具、获取结果、并生成最终回答 final_response = agent.get_response() print(“最终回答：“, final_response) except Exception as e: print(f“推理过程中出现错误：{e}“)

在这个流程中，ToolGen类内部会处理：

• 工具token检测：监控模型生成的文本，一旦出现<<...>>格式的虚拟token，就将其截获。
• 工具解析与调用：将虚拟token解析为对应的工具名和API名，然后通过RapidAPIWrapper调用真实的API。
• 结果整合：将API返回的结果格式化后，作为“观察”重新插入到对话上下文中，让模型继续生成后续内容（可能是下一个工具调用，也可能是最终答案）。

5. 评估与结果分析：它到底有多强？

论文中展示了ToolGen在多个基准测试上的优异表现。作为实践者，我们更关心如何复现这些评估，以及结果背后的含义。

5.1 工具检索评估

这是评估模型“找工具”能力的核心。使用项目中的evaluation/retrieval/eval_toolgen.py脚本。

python -m evaluation.retrieval.eval_toolgen \ --model_name_or_path “./checkpoints/toolgen_retriever“ \ # 你第二阶段训练出的检索模型 --indexing “Atomic“ \ --stage “G1“ \ # 评估集分组，G1/G2/G3代表不同难度或领域 --split “instruction“ \ # 使用指令分割的数据集 --result_path “./eval_results/retrieval/“ \ --constrain True # 是否将检索范围限制在Ground Truth涉及的工具集内

关键指标解读：

• Hit@k (k=1, 3, 5)：模型生成的前k个token中，包含正确工具token的比例。这是最直接的指标。ToolGen在Hit@1上提升显著，说明其“直接命中”能力极强。
• MRR (Mean Reciprocal Rank)：正确工具token在生成序列中排名的倒数的平均值。衡量排名质量。
• 为什么强？因为传统检索器（如基于BERT的编码器）是将查询和工具描述映射到同一个向量空间进行相似度计算。而ToolGen是将工具知识内化到了语言模型的生成概率中，它“回忆”工具更像是在“回忆知识”，对于训练中见过的工具模式，其准确性有天然优势。

5.2 端到端任务解决评估

这是评估模型“用工具解决问题”的最终能力。流程更复杂：

1. 推理生成轨迹：使用训练好的完整ToolGen模型，在测试查询集上运行，生成包含工具调用和自然语言的完整轨迹文件（.json）。
2. 轨迹格式转换：使用scripts/convert_answer/run_convert_answer.sh将生成的轨迹转换为ToolBench标准评估格式。
3. 可解通过率评估：运行scripts/pass_rate/run_pass_rate.sh。这个脚本会调用ToolBench的评估器，模拟执行轨迹中的工具调用，判断任务是否被成功解决。核心指标是Solvable Pass Rate。
4. 胜率评估：运行scripts/preference/run_preference.sh，通常是将ToolGen的解决方案与基线模型（如GPT-4 with ReAct）的解决方案交由GPT-4作为裁判进行偏好比较，得出Win Rate。

避坑指南：端到端评估是整个复现过程中最耗时的环节，且严重依赖外部API（ToolBench的RapidAPI）的稳定性和额度。建议：

• 先在小规模测试集（如10-20条数据）上跑通全流程。
• 仔细管理你的API调用密钥和额度，避免因超额导致评估中断。
• 保存好中间生成的轨迹文件，便于出错时调试。

5.3 结果分析与启示

根据论文，ToolGen在工具检索上大幅领先传统检索器，在端到端任务解决上也达到了SOTA或接近SOTA的水平。这给我们带来几点启示：

1. 生成式检索的潜力：对于高度结构化、离散化的信息（如工具、实体、代码），将其编码为离散token并让生成模型直接输出，可能比连续的向量检索更精准、更高效。
2. 课程学习的有效性：三阶段训练是一个被验证有效的范式。对于其他需要让LLM掌握复杂技能的任务（如编程、数据库查询），也可以借鉴这种“记忆-应用-综合”的渐进式训练策略。
3. 系统设计的简洁性：ToolGen将复杂的工具使用流程，简化为了一个“生成特殊token”的动作。这大大降低了智能体系统的工程复杂度，使得工具调用可以像文本生成一样流式进行。

6. 常见问题与排查技巧实录

在实际复现和实验过程中，我踩过不少坑，这里总结一下最常见的问题和解决方法。

6.1 训练相关问题

Q1: 在工具虚拟化后，模型输出乱码或无法生成虚拟token。

• 可能原因A：分词器（Tokenizer）和模型的词汇表未同步保存和加载。
  • 检查：加载模型时，是否使用了与训练时完全相同的分词器文件？务必使用model.save_pretrained(‘path‘)和tokenizer.save_pretrained(‘path‘)保存到同一目录，并从这个目录加载。
• 可能原因B：虚拟token在输入文本中被错误地拆分。
  • 检查：使用tokenizer(‘<<MyTool&&my_api>>‘, add_special_tokens=False).input_ids，查看输出是否是一个单独的ID列表。如果不是，说明你的分词器将这个token拆分了，回顾虚拟化步骤是否使用了unidecode确保其为ASCII。
• 可能原因C：训练不充分或数据格式有误。
  • 检查：在记忆训练阶段，模型在验证集上对工具token的预测准确率是否接近100%？如果没有，增加训练轮数或检查数据中loss标签是否正确。

Q2: 损失（Loss）不下降或下降非常慢。

• 可能原因A：学习率设置不当。
  • 尝试：对于LoRA等参数高效微调方法，学习率通常设在1e-4量级；对于全参数微调，设在5e-6到2e-5之间。使用学习率预热（warmup）和余弦衰减（cosine decay）调度器。
• 可能原因B：损失掩码（Loss Mask）未正确应用。
  • 调试：打印一个batch的labels和attention_mask。确保只有assistant回复部分（对应loss: true）的token在labels中不是-100（在PyTorch中，-100的标签会被损失函数忽略）。
• 可能原因C：批次大小（Batch Size）太小。
  • 尝试：在GPU内存允许的情况下，增大批次大小。如果使用梯度累积（Gradient Accumulation），确保有效批次大小足够大（如32以上）。

6.2 推理与评估相关问题

Q3: 模型在推理时陷入循环，反复生成同一个工具token或无意义内容。

• 可能原因A：single_chain_max_step设置过小或过大。
  • 调整：这个参数控制单次任务的最大推理步数。太小时任务可能未完成就被强制结束；太大时模型可能在一个错误步骤上无限循环。根据任务复杂度调整，一般8-20步是合理的起点。在agent.start()中设置。
• 可能原因B：温度（Temperature）和Top-p采样参数过于激进。
  • 调整：在生成工具token这类需要高确定性的任务时，应使用低温度（如0.1）和低Top-p（如0.9），甚至直接使用贪婪解码（do_sample=False）。你可以在初始化ToolGen时通过generation_config参数传递这些设置。
• 可能原因C：工具执行失败或返回异常结果，导致模型上下文混乱。
  • 检查：在RapidAPIWrapper中增加日志，打印每次工具调用的请求和响应。确保API服务正常，返回格式符合预期。ToolGen框架应能处理常见的API错误，并将其作为“观察”反馈给模型。

Q4: 端到端评估的通过率（Pass Rate）远低于论文报告值。

• 可能原因A：评估环境不一致。
  • 检查：你使用的ToolBench API Key对应的后端服务（StableToolBench）是否与论文实验时一致？API的版本、可用性可能影响结果。确保你运行的评估脚本版本和数据集划分与官方完全一致。
• 可能原因B：模型过拟合或欠拟合。
  • 检查：在保留的验证集上检查模型的工具检索准确率和单步任务完成率。如果验证集性能尚可但测试集很差，可能是过拟合，需要更多样化的训练数据或更强的正则化。如果验证集性能就很差，则是欠拟合，需要更多训练或调整模型容量。
• 可能原因C：轨迹转换或评估脚本参数错误。
  • 仔细核对：run_convert_answer.sh和run_pass_rate.sh脚本中的路径、模型名称、数据集路径等参数是否正确。一个常见的错误是评估了错误的数据分割（split）。

6.3 工程化与扩展思考

Q5: 如何为我自己的工具集定制ToolGen？

1. 创建虚拟token列表：为你每个工具的唯一标识（如<MySystem::getUserInfo>）创建一个虚拟token字符串。确保格式唯一且易于解析。
2. 生成训练数据：
   • 记忆数据：(工具描述/文档) -> 虚拟token。
   • 检索数据：(用户可能的问题/指令) -> 虚拟token。这部分数据需要精心构造或通过少量样本+大模型生成。
   • 轨迹数据：编写或模拟用户使用你的工具完成任务的完整对话记录。
3. 重复训练流程：从你的基础模型（如Llama 3）开始，执行虚拟化、记忆训练、检索训练、轨迹训练。

Q6: ToolGen方法有什么局限性？

• 词汇表膨胀：每增加一个工具，就永久占用一个词汇表位置。对于超大规模工具库（百万级），这会显著增加模型参数（嵌入层）并可能影响原有语言的生成能力。需要权衡。
• 工具更新成本高：新增或修改工具，需要重新进行虚拟化和至少是记忆训练，不如基于描述的检索方法灵活。
• 对闭源模型不友好：虚拟化需要修改模型的词汇表和嵌入层，这对于仅提供API的闭源大模型（如GPT-4）是无法实现的。
• 多模态工具：当前方法主要针对API工具。对于需要图像输入或输出的工具，如何将其“虚拟化”是一个开放问题。

尽管有这些局限，ToolGen无疑为工具学习领域提供了一个强大、简洁且可解释性高的新范式。它让我们看到，让大模型“掌握”工具，或许可以像教它一门新的方言一样自然。