从 SFT 到 RLHF：让模型不仅会调工具，还知道什么时候该调

开篇：模型不是天生会“调工具”

很多人第一次接触 Function Call，会以为模型在预训练时看过很多 API 文档和代码，所以自然就会调用工具。这个理解只说对了一半。

预训练确实能让模型理解“天气 API 是干什么的”“参数大概长什么样”，但这不等于它能稳定输出一段程序可解析、可执行、可校验的 tool_calls JSON。

真正的 Function Call 能力，本质上是把自然语言请求转换成结构化动作指令。它不是单纯聊天能力，而是协议遵守能力、参数抽取能力、工具选择能力和边界判断能力的组合。

一、Function Call 到底训练的是什么？

Function Call 训练不是让模型“知道更多知识”，而是让模型学会一种动作格式。

普通问答输出的是自然语言，Function Call 输出的是结构化调用请求。宿主程序拿到这个请求后，才会真正执行 API、查数据库、下订单、发邮件或调用内部系统。

所以模型至少要学会四件事：

什么时候需要调用工具，什么时候直接回答。

在多个工具里选择最合适的那个。

把用户话里的实体、时间、地点、数量等信息填进参数。

工具返回结果后，能把结果组织成用户听得懂的最终答案。

这四件事，单靠预训练很难学出来，因为预训练目标只是“预测下一个 token”。它不是为“输出合法 JSON 调用单”设计的。

二、为什么预训练不够？

预训练像让模型读完整个互联网，它能学到大量语言模式、代码模式和知识片段。但 Function Call 要求的是：在看到工具 schema 和用户问题后，严格输出一个符合协议的结构化调用。

这就像一个人读过很多报销制度，不代表他第一次上班就能把报销单填对。想让他填对，就要给他看标准表格、正确样例、错误样例和审批规则。

Function Call 的专项训练也是这个逻辑：SFT 负责给模型看标准样例，RLHF/RLAIF 负责告诉模型什么行为更符合真实用户需求。

三、阶段一：SFT，先教模型“怎么调”

SFT，全称 Supervised Fine-Tuning，可以理解成“看标准答案学动作”。训练数据里不是只放一个用户问题，而是放一整段完整对话：工具定义、用户问题、模型 tool_calls、工具执行结果、最终回答。

模型通过大量样本反复学习：看到什么需求应该选哪个工具，参数应该怎么填，工具结果回来后应该怎么说。

下面是一段简化后的工具 schema。它告诉模型：工具叫什么、什么时候用、有哪些参数、哪些字段必填。

JSON：工具定义示例

{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "查询某个城市某一天的天气",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {
                    "type": "string",
                    "description": "城市名称，例如：北京、上海"
                },
                "date": {
                    "type": "string",
                    "description": "日期，例如：today、tomorrow、2026-07-01"
                }
            },
            "required": [
                "city",
                "date"
            ],
            "additionalProperties": false
        },
        "strict": true
    }
}

注意，这类样本不是让模型学习“天气知识”，而是学习“如何从用户话里抽取北京和 today，并写成合法调用”。

JSONL 训练样本展开版：真实训练文件通常是一行一条

{
    "messages": [
        {
            "role": "user",
            "content": "帮我查一下北京今天的天气"
        },
        {
            "role": "assistant",
            "tool_calls": [
                {
                    "id": "call_001",
                    "type": "function",
                    "function": {
                        "name": "get_weather",
                        "arguments": "{\"city\":\"北京\",\"date\":\"today\"}"
                    }
                }
            ]
        },
        {
            "role": "tool",
            "tool_call_id": "call_001",
            "content": "北京今天晴，最高温 31℃，最低温 22℃"
        },
        {
            "role": "assistant",
            "content": "北京今天晴，最高温 31℃，最低温 22℃，适合外出，但中午注意防晒。"
        }
    ]
}

四、训练数据要覆盖哪些场景？

只训练“正常调一个工具”的样本是不够的。真实业务里，用户问题可能要并行查多个城市，也可能不需要工具，还可能遇到工具超时、参数缺失、权限不足。

训练数据的多样性，决定了模型上线后的稳定性。缺什么场景，就会在哪里翻车。

这里有一个很常见的坑：训练集里全是调用工具的正例，模型就会形成“见问题就调工具”的惯性。结果用户问“1+1 等于几”，它也去调计算器；用户让它总结一段文字，它也想找工具。这不是模型聪明，而是训练数据把它教偏了。

五、训练数据从哪里来？

Function Call 训练数据通常有三类来源：人工标注、强模型蒸馏、真实业务日志。

人工标注质量最高，但贵；强模型蒸馏成本低、量大，但可能把老师模型的错误也传下来；真实日志最贴近业务，但必须脱敏、过滤和人工抽检。

一个工程上更稳的做法是：先用人工标注做一批高质量种子样本，再用强模型按模板扩充，然后用规则校验、工具执行校验、人工抽检和离线评估清洗一遍。不要把模型生成的数据原封不动拿去训练。

六、阶段二：RLHF / RLAIF，教模型“该不该调”

SFT 解决“会不会调”的问题，但不一定解决“该不该调”的问题。

比如“北京今天下雨吗？”需要实时天气，应该调工具；“1+1 等于几？”直接回答就行；“帮我总结这段话”通常也不需要工具。这个边界感很难只靠固定答案学好，所以需要偏好对齐。

RLHF 的做法是：对同一个问题生成多个候选回答，让人类标注员排序；再用这些排序训练奖励模型；最后用强化学习让主模型更倾向于高分行为。RLAIF 则把一部分人类评委换成更强的 AI 评委，降低成本，但要警惕 AI 评委自己的偏见。

可以把 RLHF 理解成“教练打分”。SFT 是告诉你动作怎么做，RLHF 是告诉你什么时候这样做才合适。

七、研究界怎么做：Self-Instruct、Toolformer、LoRA 微调

研究里有几条常见路线。Toolformer 尝试让模型用少量示例自监督地学会什么时候调用 API、传什么参数、如何利用工具结果。GPT4Tools 则用强模型生成指令数据，再通过 LoRA 让开源模型学会使用多模态工具。

工程平台里也有类似思路：先用合成数据生成工具调用样本，再转成 OpenAI chat 格式或对应模型的 chat template，最后用 LoRA/SFT 训练，并做调用准确率评估。

八、上线前必须做数据和格式校验

Function Call 训练最怕“脏数据进入训练集”。一条错误样本不只是错一次，它会让模型把错误模式记进参数里。

最低限度要做三类校验：第一，JSON 能否解析；第二，工具名是否存在；第三，参数是否符合 schema。更严格的场景还要校验参数来源，避免模型凭空编造参数。

Python：训练样本 tool_calls 校验示例

import json
from jsonschema import validate, ValidationError

TOOLS = {
"get_weather": {
"type": "object",
"properties": {
"city": {"type": "string"},
"date": {"type": "string"}
},
"required": ["city", "date"],
"additionalProperties": False
}
}

def validate_tool_call(tool_call: dict) -> list[str]:
errors = []

name = tool_call["function"]["name"]
raw_args = tool_call["function"]["arguments"]

if name not in TOOLS:
errors.append(f"unknown tool: {name}")
return errors

try:
args = json.loads(raw_args)
except json.JSONDecodeError:
errors.append("arguments is not valid JSON")
return errors

try:
validate(instance=args, schema=TOOLS[name])
except ValidationError as e:
errors.append(f"schema error: {e.message}")

return errors

如果你做的是企业内部系统，还要增加权限校验：比如退款、改价、删除数据这类高风险工具，训练样本里必须包含确认、拒绝、越权拦截、参数缺失追问等场景。

九、怎么评估训练有没有效果？

评估 Function Call 不能只看最终回答像不像。最终回答可能写得很漂亮，但工具名选错、参数填错、该拒绝却调用了，这些都属于严重问题。

更靠谱的评估方式是把调用过程拆开看：工具选择、参数提取、schema 合法、并行/串行调用、拒调能力、失败恢复、最终回答。

BFCL 这类 benchmark 的价值就在于，它把 Function Calling 从“看起来会用工具”拆成了可评估的能力，包括单轮、多轮、并行、串行、拒调、状态变化等。企业自己落地时，也应该做自己的小型评测集，而不是只依赖通用排行榜。

十、常见翻车点：不是模型不行，是训练没教到

Function Call 的很多线上问题，都能回到训练数据或工具 schema 上找原因。比如工具名过于相似、参数描述不清楚、拒调样本太少、失败样本缺失、多轮链路没覆盖。

一个实用经验是：不要只收集成功样本，更要收集失败样本。因为线上真正决定系统稳定性的，往往不是“正常路径能不能跑通”，而是“异常路径能不能兜住”。

十一、面试时怎么回答？

如果想回答得更工程化，可以再补一句：训练完还不算结束，线上还要做 schema 校验、工具白名单、权限控制、调用日志、失败回流和离线评估。Function Call 的可靠性，最终是模型训练和工程护栏共同决定的。

结尾：工具调用能力，是“训练 + 评估 + 工程约束”的结果

Function Call 看起来像是模型自己会调用工具，其实底层是一个完整训练体系。

预训练让模型理解语言和代码，但不保证稳定输出 tool_calls。

SFT 通过标准样本教会模型工具调用格式和流程。

RLHF/RLAIF 通过偏好信号教会模型“该调才调”。

数据质量、schema 设计、异常样本、评估体系，决定上线后的可靠性。

所以，真正靠谱的 Function Call，不是“给模型几个工具就完事”，而是让模型在大量高质量样本里学会动作格式，在偏好对齐里学会边界，在工程系统里受到校验和保护。