从 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℃适合外出但中午注意防晒。}]}四、训练数据要覆盖哪些场景只训练“正常调一个工具”的样本是不够的。真实业务里用户问题可能要并行查多个城市也可能不需要工具还可能遇到工具超时、参数缺失、权限不足。训练数据的多样性决定了模型上线后的稳定性。缺什么场景就会在哪里翻车。这里有一个很常见的坑训练集里全是调用工具的正例模型就会形成“见问题就调工具”的惯性。结果用户问“11 等于几”它也去调计算器用户让它总结一段文字它也想找工具。这不是模型聪明而是训练数据把它教偏了。五、训练数据从哪里来Function Call 训练数据通常有三类来源人工标注、强模型蒸馏、真实业务日志。人工标注质量最高但贵强模型蒸馏成本低、量大但可能把老师模型的错误也传下来真实日志最贴近业务但必须脱敏、过滤和人工抽检。一个工程上更稳的做法是先用人工标注做一批高质量种子样本再用强模型按模板扩充然后用规则校验、工具执行校验、人工抽检和离线评估清洗一遍。不要把模型生成的数据原封不动拿去训练。六、阶段二RLHF / RLAIF教模型“该不该调”SFT 解决“会不会调”的问题但不一定解决“该不该调”的问题。比如“北京今天下雨吗”需要实时天气应该调工具“11 等于几”直接回答就行“帮我总结这段话”通常也不需要工具。这个边界感很难只靠固定答案学好所以需要偏好对齐。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 校验示例importjson from jsonschemaimportvalidate, 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[]nametool_call[function][name]raw_argstool_call[function][arguments]ifname notinTOOLS: errors.append(funknown tool: {name})returnerrors try: argsjson.loads(raw_args)except json.JSONDecodeError: errors.append(arguments is not valid JSON)returnerrors try: validate(instanceargs,schemaTOOLS[name])except ValidationError as e: errors.append(fschema error: {e.message})returnerrors如果你做的是企业内部系统还要增加权限校验比如退款、改价、删除数据这类高风险工具训练样本里必须包含确认、拒绝、越权拦截、参数缺失追问等场景。九、怎么评估训练有没有效果评估 Function Call 不能只看最终回答像不像。最终回答可能写得很漂亮但工具名选错、参数填错、该拒绝却调用了这些都属于严重问题。更靠谱的评估方式是把调用过程拆开看工具选择、参数提取、schema 合法、并行/串行调用、拒调能力、失败恢复、最终回答。BFCL 这类 benchmark 的价值就在于它把 Function Calling 从“看起来会用工具”拆成了可评估的能力包括单轮、多轮、并行、串行、拒调、状态变化等。企业自己落地时也应该做自己的小型评测集而不是只依赖通用排行榜。十、常见翻车点不是模型不行是训练没教到Function Call 的很多线上问题都能回到训练数据或工具 schema 上找原因。比如工具名过于相似、参数描述不清楚、拒调样本太少、失败样本缺失、多轮链路没覆盖。一个实用经验是不要只收集成功样本更要收集失败样本。因为线上真正决定系统稳定性的往往不是“正常路径能不能跑通”而是“异常路径能不能兜住”。十一、面试时怎么回答如果想回答得更工程化可以再补一句训练完还不算结束线上还要做 schema 校验、工具白名单、权限控制、调用日志、失败回流和离线评估。Function Call 的可靠性最终是模型训练和工程护栏共同决定的。结尾工具调用能力是“训练 评估 工程约束”的结果Function Call 看起来像是模型自己会调用工具其实底层是一个完整训练体系。预训练让模型理解语言和代码但不保证稳定输出 tool_calls。SFT 通过标准样本教会模型工具调用格式和流程。RLHF/RLAIF 通过偏好信号教会模型“该调才调”。数据质量、schema 设计、异常样本、评估体系决定上线后的可靠性。所以真正靠谱的 Function Call不是“给模型几个工具就完事”而是让模型在大量高质量样本里学会动作格式在偏好对齐里学会边界在工程系统里受到校验和保护。内容来源大模型的 Function Call 能力是怎么训练出来的
从 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℃适合外出但中午注意防晒。}]}四、训练数据要覆盖哪些场景只训练“正常调一个工具”的样本是不够的。真实业务里用户问题可能要并行查多个城市也可能不需要工具还可能遇到工具超时、参数缺失、权限不足。训练数据的多样性决定了模型上线后的稳定性。缺什么场景就会在哪里翻车。这里有一个很常见的坑训练集里全是调用工具的正例模型就会形成“见问题就调工具”的惯性。结果用户问“11 等于几”它也去调计算器用户让它总结一段文字它也想找工具。这不是模型聪明而是训练数据把它教偏了。五、训练数据从哪里来Function Call 训练数据通常有三类来源人工标注、强模型蒸馏、真实业务日志。人工标注质量最高但贵强模型蒸馏成本低、量大但可能把老师模型的错误也传下来真实日志最贴近业务但必须脱敏、过滤和人工抽检。一个工程上更稳的做法是先用人工标注做一批高质量种子样本再用强模型按模板扩充然后用规则校验、工具执行校验、人工抽检和离线评估清洗一遍。不要把模型生成的数据原封不动拿去训练。六、阶段二RLHF / RLAIF教模型“该不该调”SFT 解决“会不会调”的问题但不一定解决“该不该调”的问题。比如“北京今天下雨吗”需要实时天气应该调工具“11 等于几”直接回答就行“帮我总结这段话”通常也不需要工具。这个边界感很难只靠固定答案学好所以需要偏好对齐。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 校验示例importjson from jsonschemaimportvalidate, 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[]nametool_call[function][name]raw_argstool_call[function][arguments]ifname notinTOOLS: errors.append(funknown tool: {name})returnerrors try: argsjson.loads(raw_args)except json.JSONDecodeError: errors.append(arguments is not valid JSON)returnerrors try: validate(instanceargs,schemaTOOLS[name])except ValidationError as e: errors.append(fschema error: {e.message})returnerrors如果你做的是企业内部系统还要增加权限校验比如退款、改价、删除数据这类高风险工具训练样本里必须包含确认、拒绝、越权拦截、参数缺失追问等场景。九、怎么评估训练有没有效果评估 Function Call 不能只看最终回答像不像。最终回答可能写得很漂亮但工具名选错、参数填错、该拒绝却调用了这些都属于严重问题。更靠谱的评估方式是把调用过程拆开看工具选择、参数提取、schema 合法、并行/串行调用、拒调能力、失败恢复、最终回答。BFCL 这类 benchmark 的价值就在于它把 Function Calling 从“看起来会用工具”拆成了可评估的能力包括单轮、多轮、并行、串行、拒调、状态变化等。企业自己落地时也应该做自己的小型评测集而不是只依赖通用排行榜。十、常见翻车点不是模型不行是训练没教到Function Call 的很多线上问题都能回到训练数据或工具 schema 上找原因。比如工具名过于相似、参数描述不清楚、拒调样本太少、失败样本缺失、多轮链路没覆盖。一个实用经验是不要只收集成功样本更要收集失败样本。因为线上真正决定系统稳定性的往往不是“正常路径能不能跑通”而是“异常路径能不能兜住”。十一、面试时怎么回答如果想回答得更工程化可以再补一句训练完还不算结束线上还要做 schema 校验、工具白名单、权限控制、调用日志、失败回流和离线评估。Function Call 的可靠性最终是模型训练和工程护栏共同决定的。结尾工具调用能力是“训练 评估 工程约束”的结果Function Call 看起来像是模型自己会调用工具其实底层是一个完整训练体系。预训练让模型理解语言和代码但不保证稳定输出 tool_calls。SFT 通过标准样本教会模型工具调用格式和流程。RLHF/RLAIF 通过偏好信号教会模型“该调才调”。数据质量、schema 设计、异常样本、评估体系决定上线后的可靠性。所以真正靠谱的 Function Call不是“给模型几个工具就完事”而是让模型在大量高质量样本里学会动作格式在偏好对齐里学会边界在工程系统里受到校验和保护。内容来源大模型的 Function Call 能力是怎么训练出来的
)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
