工具调用微调：让模型学会使用外部 API

工具调用微调：让模型学会使用外部 API

在现代大语言模型（LLM）的应用中，工具调用（Function Calling / Tool Use） 是一项突破性的能力。它让模型不仅能生成文字，还能像一个智能调度中心那样，判断何时需要调用外部工具，并生成结构化的参数。而这种行为的可靠性，往往需要通过微调来固化，这就是“工具调用微调”。

本教程将带你从零开始，理解工具调用微调的核心概念、数据构造方法、训练流程以及评估指标。无论你是想为业务系统接入稳定的 API 调用助手，还是想打造能操作数据库的智能代理，这都将是你的第一份系统指南。

什么是工具调用与工具调用微调？

从“生成文本”到“执行动作”

原生的大语言模型只能生成自然语言。当你问它“北京今天天气怎么样？”时，它无法实时查询，只能靠记忆里的旧数据给出可能错误的回答。

工具调用则让模型意识到自己的知识边界。当它识别出用户意图需要外部信息或操作时，它会输出一个特殊的、规范化的函数调用请求，而不是直接回答。这个请求通常包含：

• 函数名：例如 get_weather
• 参数：{"city": "Beijing", "date": "today"}
• 调用标识：系统据此暂停生成，执行真实 API，再将结果传回模型生成最终回答。

为什么需要微调？

开源模型或部分小型模型在工具调用场景下常有“幻觉”：

• 该调时不调：遇到超出知识范围的问题仍强行捏造答案。
• 乱调瞎编：调用不存在的函数，或传入格式错误的参数。
• 并行调用混乱：需要同时查询多个独立信息源时，只查了一个就停止。

微调本质上是用大量“对话-函数调用”示例，纠正模型的上述行为，使其像条件反射一样稳定、准确地决定调与不调、调哪个、传什么参。

微调数据：如何构造高质量的训练样本

数据质量直接决定微调后的工具调用成功率。你需要为模型提供多样化的对话上下文和期望的调用输出。

核心数据格式：以 OpenAI 格式为例

主流微调框架普遍支持类似 ChatML 的对话格式。一个完整的样本包含三个角色：

1. 系统消息：定义可用工具列表（函数名、描述、参数模式）
2. 用户消息：用户输入的自然语言指令
3. 助手消息：模型应输出的工具调用指令（而非自然语言）

{
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant.\n\n# Tools\n\n## get_weather\nDescription: 获取指定城市的天气\nParameters: city (string, required), unit (string, optional)"
    },
    {
      "role": "user",
      "content": "上海今天热吗？"
    },
    {
      "role": "assistant",
      "content": null,
      "tool_calls": [
        {
          "id": "call_weather_001",
          "type": "function",
          "function": {
            "name": "get_weather",
            "arguments": "{\"city\": \"上海\"}"
          }
        }
      ]
    }
  ]
}

数据构造的四大关键原则

1. 覆盖“不调用”场景：大约 20%-30% 的样本应为无需调用工具即可直接回答的普通对话。助手消息只包含普通文本，不包含 tool_calls。这能防止模型“过度调用”。

2. 指令多样化：同一意图用不同句式表达：“查北京天气”、“北京今天多少度”、“我想知道北京天气状况”。让模型理解多变的口语。

3. 参数边界与缺省值：刻意包含省略可选参数的请求，以及要求精准必填参数的请求。比如用户问“天气怎么样”却不给地点，可构造一条助手先追问地点的样本，或者设计一个需要“拒不生成”的边缘案例（这取决于你的产品逻辑）。

4. 多工具与并行调用：引入至少两个以上的工具，并在某些用户请求中要求同时调用它们。例如：“查一下北京和上海的天气，然后告诉我明天深圳的航班”。期望输出应包含一个包含两个 tool_calls 项的助手消息块。

扩增技巧

• LLM 辅助生成：先用最强模型（如 GPT‑4）生成一批符合格式的种子数据。
• 模板变体：针对参数类型，用代码批量替换城市名、日期、数字等，生成海量组合。
• 负例构建：故意留下错误输出（如漏掉必填参数）作为训练中的“修正”样本，或者将这些坏例剔除。

微调实施：从平台选择到训练配置

选择合适的模型基座

• 通用对话模型（如 LLaMA‑3、Qwen2）：本身具备指令遵循能力，工具调用微调只需在之上叠加 1000~5000 条高质量样本，就可快速收敛。
• 专用轻量模型（如 7B 规模的模型）：成本低、推理快，适合单一领域或少量工具的场景，但训练数据需更充足（万条级别）。
• 评估基座能力：先检查基础模型在 0-shot 下的工具调用准确率，了解“起始水平”，才能衡量微调带来的增益。

训练环境与关键超参数

使用 Hugging Face Transformers + PEFT（LoRA）是目前最高效的方式，只需训练极小部分参数，降低显存需求。

推荐起步配置：

• LoRA rank：16~64，文本生成任务中等即可。
• 学习率：5e-5 至 2e-4，使用余弦退火调度。
• Batch size：批量 128 往往较稳定，实际据 GPU 累积。
• Epochs：3~5 轮，防止过拟合至死记硬背。
• 数据拆分：90% 训练，10% 验证，按函数类型分层抽样。

训练时务必监控：

• Loss 曲线：验证损失稳定下降后若反弹立刻停止。
• 功能正确率：每个 epoch 用验证集测试一次工具调用的格式合格率和参数一致性。

沙盒化验证与评估体系

微调后的模型需要一套标准化的离线评估，因为它输出的 tool_calls 结构稍有错就会导致系统崩溃。

评估指标矩阵

构建专属测试集

测试集必须完全不在训练数据中出现，且刻意设计：

• 模糊意图句子：“我有点冷”——应调用温度调节工具还是查询天气？
• 多轮对话场景：第二轮补全参数，而不应重新独立调用。
• 长尾工具：确保每个工具都有至少 20 个测试用例。

利用脚本自动化批量测试，将模型输出解析为 JSON 后与预期对比，生成错误分布报告。常见“重灾区”包括：多参数时参数顺序混乱、字符串引号缺失、数值类型未加引号。

部署陷阱与持续优化

为什么 Prompt 仍需保留工具定义？

微调只是增强了模型“解读工具定义并配合调用”的能力，并非把工具硬编码进大脑。推理时仍必须在系统提示中提供完全相同的函数模式。甚至可以更新模式版本（加新参数），微调模型多能泛化理解，无需立刻重训。

发布后的监控闭环

• 记录所有真实调用日志，识别格式异常或空返回。将失败案例清洗后作为新训练数据。
• 定期重训：当工具新增或用户行为漂移时，用持续入库的高质量案例更新。

性能与延迟的平衡

如果业务要求极低延迟，可考虑将微调后的模型与规则引擎结合：先用规则拦截明确无工具调用的简答，将复杂多工具需求路由至微调模型，降低平均耗时。

快速动手清单

1. □ 确明确利地用场景和工具列表，编写 10 条最佳实践的对话示例。
2. □ 用脚本或强模型将示例扩展为 1000+ 条，覆盖多工具、缺省、并行等情形。
3. □ 选择 7B 及以上基座模型，配置 LoRA 并执行第一轮微调。
4. □ 构建不少于 200 条的测试集，运行自动化评估得到基线分数。
5. □ 根据评估结果，分析失败案例，针对性补充训练数据，再次微调。
6. □ 部署后开启日志美收集，进入“数据飞轮”持续迭代。

工具调用微调并不是一次性工程，而是一个将模型判断力逐渐逼近“业务确定性”的过程。把握数据质量和评估闭环，你就能让大模型真正成为连接数字世界与真实 API 的可靠桥梁。