考察点
这道题出自快手大模型岗二面，明显偏算法侧，面试官想确认你理解 FC 能力背后的训练管线，而不只是会用 API。三个子问题环环相扣：能力怎么训出来、为什么 SFT 不够还要 RL、蒸馏数据有什么风险。能把「SFT 学格式、RL 学对错」这条线讲透，再带出数据工程细节，就是高分答案。追问常往负样本构造、评测 benchmark、奖励设计走。
参考答案
训练管线：先 SFT 学格式，再 RL 学判断
FC 能力的源头是工具调用轨迹数据。一条典型样本长这样：用户 query + 当前可用工具的 schema 列表作为输入，输出是模型的完整行为序列——思考、发起 tool_call、接收工具返回的 observation、基于结果继续思考或给出最终回答。多轮交互的任务就是多轮轨迹串起来训练。
SFT 阶段做两件事：一是教会模型调用格式，tool_call 通常用专门的 special token 包裹，模型学到「在合适的位置停下来，输出一段合法 JSON」；二是教会基本决策，样本里包含大量「该调」的正例和「不该调、直接回答」的对照例，模型模仿出初步的判断边界。Gorilla、ToolLLM 这些早期工作基本就是这个路数，开源社区的 xLAM、Qwen 的 FC 能力也沿用类似管线。
为什么不能只靠堆 SFT 样本
三个原因。第一，SFT 的监督信号是 token 级的：它只保证模型的输出长得像正确答案，不知道这次调用「对不对」。一次调用是否正确，取决于执行结果——参数填对了 API 才返回成功，这是序列级、结果级的信号，模仿学习拿不到。第二，边界行为难覆盖：「可调可不调」的灰色地带、参数该从上下文哪句话里取，这些判断靠枚举样本永远覆盖不全，模型需要在探索中被奖励塑形。第三，SFT 有 exposure bias，训练时每一步都看着正确历史，推理时一步走错后面就崩。
RL 阶段（RLHF 或更适合的 RLVR）补上的正是这个：把「工具调用是否执行成功、最终结果是否正确」作为可验证奖励——这类奖励可以程序化判定，不需要人标。策略更新后，过触发（没事乱调）和欠触发（该调不调）都会被惩罚，泛化性明显好过纯 SFT。这也是推理模型时代的标准做法，DeepSeek-R1 类方法证明可验证奖励对结构化行为塑形非常有效。
蒸馏造数据的风险与缓解
实务里大量 FC 训练数据是用强模型（GPT-4 级别）蒸馏生成的，这条路有三个明坑：
- 幻觉工具被当成正样本。教师模型可能编造不存在的 API 或参数，直接混入训练集，学生模型就学了一身幻觉调用。缓解：所有样本的工具名和参数必须过 schema 自动校验，对不上的直接丢弃。
- 执行结果是编的。教师模型生成轨迹时，observation 也是它想象的，「调用成功」的假象会让学生学到错误的因果。缓解：沙箱真实执行——把每条轨迹的 tool_call 在真实或仿真环境里跑一遍，只保留执行成功且结果合理的轨迹，这是成本最高但最有效的一道过滤。
- 模式同质化。蒸馏数据集中在常见调用模式，长尾工具和复杂多轮轨迹稀缺，学生模型遇到非常规组合就露怯。缓解：多样性采样（温度、工具组合随机化）、主动构造长尾场景、人工抽检困难样本。
一句话收口：SFT 让模型「会调」，RL 让模型「调对」，而数据质量的天花板取决于执行校验做得多狠。
可能的追问
- 负样本怎么构造？ 答：三类都要——不该调而调（直接能答的问题配工具）、参数错误（类型错、值幻觉）、格式破坏；负样本在 SFT 里做对照、在 RL 里体现为负奖励。
- FC 能力怎么评测？ 答：业界常用 BFCL（Berkeley Function Calling Leaderboard），覆盖单轮、多轮、并行、无关性检测；自建集要包含业务长尾工具和对抗性的「不该调」case。
- RL 阶段奖励怎么设计？ 答：分层——格式合法给基础分，schema 校验通过加分，沙箱执行成功加分，最终结果对答案加分；全程对幻觉函数名重罚。