你们的 Function Call 是怎么训练的？训练数据怎么构建

1️⃣ 考察意图

面试官想看的不是“我用了SFT”这种概念复述，而是你对Function Call训练全流程的工程化理解：从数据构造的“脏活”到训练策略的“取舍”。刁钻点在于：通用模型天生不懂业务工具（如“查询库存”的API签名），训练必须解决工具选择、参数绑定、格式化输出、多轮上下文四个子问题。答好了能展示你从零构建Agent训练pipeline的硬实力，包括合成数据、难例挖掘、LoRA/SFT+DPO的实战经验。

2️⃣ 标准答

Function Call训练的核心是让模型从“文本生成”转向“结构化工具调用”。我分数据构建和训练方法两部分讲。

数据构建：正样本、负样本、难例三足鼎立

正样本：覆盖工具选择、参数绑定、格式化输出。
工具选择：用户说“查天气”，模型需输出get_weather，而非search_flight。
参数绑定：用户说“北京明天”，模型需输出{"location": "北京", "date": "2024-12-20"}。
格式化输出：强制JSON格式，如{"tool": "get_weather", "args": {...}}。
多轮上下文：用户先问“北京天气”，再问“上海呢？”，模型需继承get_weather工具并更新参数。
来源：合成数据（用GPT-4或规则生成，如随机组合工具和参数）、真实日志（清洗后标注）。
坑：合成数据易“假完美”，比如参数值全合法，但真实场景有缺失或错误（如用户说“明天”但日期未指定）。解法：在合成时注入噪声，如随机删除参数或添加无关字段。
负样本：防止模型乱调用。
类型1：工具不存在时，模型应输出“无法处理”而非瞎编。
类型2：参数错误时（如get_weather要求location，用户没给），模型应反问而非猜测。
来源：从真实日志中提取失败案例，或规则生成（如工具名拼错、参数类型不匹配）。
比例：正负样本比建议3:1到5:1，负样本太少模型会过度自信。
难例：提升鲁棒性。
类型1：工具名相似（如get_weather vs get_weather_forecast），模型需区分。
类型2：参数歧义（如“北京”可以是城市或公司名），需结合上下文。
类型3：多工具协同（如先查天气再订机票），模型需输出多步调用。
来源：用规则生成相似工具对，或从badcase中挖掘（如模型混淆了search_flight和book_flight）。
规模：总样本量建议10万-50万条，其中难例占20%-30%。

训练方法：LoRA轻训 vs SFT+DPO重训

LoRA轻训：适合快速迭代。
在基座模型（如Qwen2.5-7B）上加LoRA adapter，rank=8-16，只训练attention层。
数据量：5万-10万条正样本+负样本，训练1-2个epoch。
Trade-off：轻量但泛化差，对未见过的工具（如新API）表现弱。
实战坑：LoRA可能过拟合到工具名，导致模型对相似工具（如get_weather和get_weather_forecast）混淆。解法：在数据中增加工具名变体（如缩写、同义词）。
SFT+DPO重训：适合生产级Agent。
先SFT：用全量数据（正+负+难例）微调模型，学习工具调用格式。
再DPO：用偏好对（正确调用 vs 错误调用）优化，提升工具选择准确率。
数据量：SFT用10万-50万条，DPO用5万-10万对。
Trade-off：成本高（需要多轮训练和人工标注偏好），但泛化强，能处理未见工具（如通过工具描述推理）。
实战坑：DPO偏好对难构造，比如“正确调用”和“错误调用”边界模糊（如参数顺序不同但结果相同）。解法：用规则自动生成偏好对，如正确参数绑定 vs 错误参数类型。

总结：数据是瓶颈，训练是手段。正负难三样本缺一不可，LoRA适合原型，SFT+DPO适合上线。规模参考：10万条数据+LoRA可达到90%工具选择准确率，50万条+SFT+DPO可到95%+。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从数据构建和训练方法两个层面回答。数据层面，正样本覆盖工具选择和参数绑定，负样本防止乱调用，难例提升鲁棒性，比例建议3:1:0.5。训练层面，LoRA轻训适合快速迭代，SFT+DPO重训适合生产级Agent。总结一句：Function Call训练的核心是数据质量，正负难三样本缺一不可，训练策略根据业务场景取舍。”

4️⃣ 高频追问 & 应对

追问 1：你提到合成数据，怎么保证合成数据不泄露或过拟合？

合成数据确实有风险。解法：1）用规则生成而非大模型生成，比如随机组合工具名和参数，避免模型学到GPT-4的“话术”。2）注入噪声，如随机删除参数、添加无关字段，模拟真实用户行为。3）用真实日志做验证集，监控合成数据与真实分布的KL散度，如果偏差大则调整规则。4）数据去重，防止同一模式重复出现导致过拟合。

追问 2：如果工具数量从10个扩展到1000个，训练策略怎么调整？

工具扩展后，全量训练成本太高。解法：1）用工具描述代替工具名，让模型通过语义理解调用，而非记忆。2）训练时只采样部分工具（如每个batch随机选50个），避免模型过拟合到特定工具。3）引入检索增强，先用BM25或DPR从1000个工具中召回Top-10，再让模型选择，降低分类难度。4）DPO偏好对更关键，因为工具多时模型容易混淆相似工具。

追问 3：你的模型在调用时参数顺序错了，但结果正确，这算正确还是错误？

算正确，但需要区分。解法：1）在训练数据中，参数顺序统一为JSON键值对，不依赖顺序。2）在评估时，用结构匹配（如JSON键值对匹配）而非字符串匹配。3）如果模型输出顺序与训练数据不一致，但键值对正确，则视为正确。4）如果模型输出多余参数（如加了无关字段），则视为错误，需要负样本强化。

5️⃣ 避坑 · 常见错误答法

❌ 说“我用GPT-4生成所有训练数据，然后直接SFT” → ✅ 正确切入：合成数据需要注入噪声和难例，否则模型过拟合到GPT-4的“完美”模式，真实场景泛化差。
❌ 说“正样本就够了，负样本不重要” → ✅ 正确切入：负样本防止模型乱调用，比如用户问“查天气”，模型输出search_flight，这是常见badcase，必须用负样本抑制。
❌ 说“训练数据越多越好，10万条不够” → ✅ 正确切入：数据质量比数量重要，5万条高质量正负难样本比50万条纯正样本效果好，因为模型需要学会“拒绝”而非“全猜”。

6️⃣ 简历呼应

如果你有RAG项目：从“工具检索”角度切入，强调Function Call类似RAG中的工具选择，用BM25或DPR做召回，再用模型做排序。数据构建可复用RAG的难例挖掘经验。
如果你只做过传统NLP：用“序列标注”类比，Function Call是结构化输出，类似NER中的实体识别，但输出是JSON。训练数据构造可借鉴CRF的标签设计，正样本对应BIO标签，负样本对应O标签。
如果你是校招无项目：聚焦论文复现，比如复现Toolformer或Gorilla的合成数据方法，用开源模型（如Qwen2.5-7B）做LoRA微调，并记录准确率提升。强调对数据构造和训练策略的理解。
Toolformer: Language Models Can Teach Themselves to Use Tools
Gorilla: Large Language Model Connected with Massive APIs
Qwen2.5 Technical Report (Function Calling章节)
LoRA: Low-Rank Adaptation of Large Language Models
DPO: Direct Preference Optimization for Language Models

—— 本场面试完 ——