快速探讨大模型中Function Call的设计与实现路径

有关 Function call 的面试题，网上流传的并不多，很多同学都会用商业大模型的 use tools 这个功能，但一细问到这个能力是怎么训练出来的，大都一脸懵。

所以这篇笔记，我们就来详细拆解这个 Function call 的面试连环炮，如果你在面试现场被问到这些题目，应该如何作答？

01 Function call 怎么训练的，怎么微调的？

第一个问题，Function call 是怎么训练，怎么微调的。我们可以根据 Llama3 的开源细节来回答这个问题。

根据 Llama 的技术报告，大模型工具调用能力，是在 post training 的时候加上去的，包含了多个 SFT和 DPO 的迭代过程。

Llama3 使用 tool 的流程大致和 GPT4 的 tool call 差不多：

工具调用的工作流程大致如下:

1. 用户交互: 1.1: 用户向执行器(Executor)发送提示(Prompt)。 1.2: 执行器最终将响应(Response)返回给用户。
2. 执行器与Llama模型的交互: 2.1: 执行器将用户的提示传递给Llama模型。 2.2: Llama模型生成包含工具调用的响应。
3. 执行器与工具的交互: 3.1: 执行器根据Llama模型的响应调用相应的工具。 3.2: 工具执行后返回结果给执行器。
4. 执行器再次与Llama模型交互: 4.1: 执行器将原始提示和工具调用结果一起发送给Llama模型。 4.2: Llama模型生成最终的综合响应。

这张图就是一个完整的工具调用循环，从用户输入到最终输出，包括了Llama3.1模型的决策过程、工具的调用，以及如何将工具的结果整合到最终响应中。这种设计允许Llama3.1模型利用其内置的工具来增强能力，能够快速、精准地回答用户的问题，减少”幻觉“现象

参考 Llama3 对 SFT Tool 数据集的描述：标注员只对 assistant 信息进行排名打分，通常模型对当前问题的推理能力越强，打分越高，而不对 tool 信息进行排名打分。

其次，不采用 rejection sampling，因为 Llama 团队没有在后期的 tool 测评中，观察到它带来的收益。

为了加快标注过程，Llama 团队首先通过在之前的 Llama 3 检查点生成的合成数据上进行微调，以此来引导基本的工具使用能力。因此标注员需要进行的改动较少。

同样地，随着 Llama 3 在训练过程中逐渐改进，逐步复杂化人类标注协议：从标注单轮 tool use 的对话数据开始，逐步过渡到标注对话中包含了 tool use 的数据，最后到标注对话中包含了多步 tool use 以及数据分析的训练数据。

02 Fucntion call 怎么组织文本的格式喂给模型？

比较有名的 function call 的数据集有 glaive-function-calling-v2-sharegpt，其输入格式为：

tools：

[
  {
    "name":"generate_password",
    "description":"Generate a random password with specified criteria",
    "parameters":{
      "type":"object",
      "properties":{
        "length":{
          "type":"integer",
          "description":"The length of the password"
        },
        "include_numbers":{
          "type":"boolean",
          "description":"Include numbers in the password"
        },
        "include_special_characters":{
          "type":"boolean",
          "description":"Include special characters in the password"
        }
      },
      "required":[
        "length"
      ]
    }
  }
]

tools 会像 system prompt 一样，一起放到输入的 prompt 里。组织好的对话数据：

[
  {
    "from":"human",
    "value":"I need a new password. Can you generate one for me?"
  },
  {
    "from":"gpt",
    "value":"Of course! How long would you like your password to be? And do you want it to include numbers and special characters?"
  },

  {
    "from":"human",
    "value":"I want it to be 12 characters long and yes, it should include both numbers and special characters."
  },

  {
    "from":"function_call",
    "value":"{\"name\": \"generate_password\", \"arguments\": {\"length\": 12, \"include_numbers\": true, \"include_special_characters\": true}}"
  },

  {
    "from":"observation",
    "value":"{\"password\": \"4#7gB6&9L1!0\"}"
  },

  {
    "from":"gpt",
    "value":"Here is your new password: 4#7gB6&9L1!0. Please make sure to save it in a secure place."
  }
]

这部分对话数据会和普通的多轮对话数据一样，进行多次的 SFT+DPO/RLHF 的微调。

03 Function call 怎么把下游的一些工具 / 插件变成模型可以理解的方式？

其实通过把 tools 翻译成 json 文本，也就是把 tool 的函数名，工具描述，变量名，变量类型打包成 prompt 的一部分。

然后再全局设计这样的指令模版，例如 qwen-agent 里设置了这样的包含工具的对话模版：

"""# 工具

你拥有如下工具：

{tool_descs}

你可以在回复中插入零次、一次或多次以下命令以调用工具：

#FUNCTION#: 工具名称，必须是[{tool_names}]之一。
#ARGS#: 工具输入
#RESULT#: 工具结果
#RETURN#: 根据工具结果进行回复"""

然后通过 post-training 或者微调，可以让模型理解工具的含义。当然实际在定义所使用的工具时，前面提到的这些必要的工具信息需要含义清楚，定义清晰，否则实际使用的效果也会大打折扣。