Function Call 的训练数据怎么构建

Function Call 的训练数据怎么构建

P1 · llm_training

🏷 标签：function_calling, training_data, data_generation, synthetic_data

1️⃣ 考察意图

面试官想考察你对 LLM 工具调用能力的数据驱动理解，而非单纯背诵 API 格式。这是系统设计 + 工程取舍型问题，刁钻点在于：数据构建不是“写个 prompt 让 GPT 生成”那么简单，需要平衡多样性、质量、覆盖度和负例设计。答好了能展示你对 SFT 数据全流程的掌控力，包括合成策略、过滤机制、以及如何避免模型“学会调用但不会拒绝”。

2️⃣ 标准答

Function Call 训练数据的构建，核心目标是让模型学会何时调用、调用哪个函数、参数怎么填、以及调用失败后怎么恢复。我把它拆成四个阶段：

• 阶段一：真实日志挖掘（黄金数据）从线上用户交互日志中提取工具调用样本。关键点：只取用户明确触发的调用（如“帮我订机票”），过滤掉模型猜测或幻觉产生的调用。
• 坑：日志里常混入“用户说‘我不需要’但模型仍调用”的负例，必须人工标注或规则过滤（如用户后续否定词检测）。
• 工程取舍：真实数据质量高但量少，只能作为种子集，不能依赖它覆盖所有场景。 阶段二：模板化生成（覆盖参数边界）
• 定义函数 schema（如 get_weather(location, date)），用模板生成查询变体。例如：正常查询：“北京明天天气如何？” → location=“北京”, date=“2025-03-21”
• 边界参数：“查询未来 30 天的天气” → 触发参数长度限制或日期越界
• 缺失参数：“查天气” → 模型需反问“哪个城市？” 工具：用 Jinja2 模板引擎 + 随机参数组合，生成 10 万级样本。注意：参数值需从真实数据库采样（如城市列表），避免模型学到“北京”是唯一合法值。阶段三：大模型合成 + 自洽性过滤（核心方法）
• 用 GPT-4 或 Claude 3.5 作为“教师模型”，给定函数 schema 和用户意图，生成调用结果。但直接生成会引入幻觉，必须加自洽性检查：对同一查询，让教师模型生成 3 次调用
• 检查 3 次结果是否一致（函数名、参数值完全匹配）
• 只保留 3 次一致的样本，丢弃不一致的（如 location=“北京” vs location=“Beijing”）
• 论文参考：Self-Instruct 的变体，但这里用“多轮采样一致性”替代人工筛选。
• 坑：教师模型可能生成“正确但无意义”的调用（如 get_weather(location=“null”)），需加规则过滤：参数值不能是占位符、空字符串、或明显错误值（如日期为 1900-01-01）。 阶段四：负例设计（关键差异化）
• 模型必须学会不调用或拒绝调用。负例包括：无关查询：用户说“讲个笑话”，但函数只有天气和日历 → 模型应输出 no_call 或自然语言回复
• 参数错误：用户说“查北京天气”，但函数要求 city 而非 location → 模型应拒绝或反问
• 多轮依赖：用户先问“北京天气”，再问“上海呢？” → 第二轮需复用上一轮上下文，但函数参数不能直接继承 负例比例：建议正负比 3:1，太多负例会让模型过于保守，太少则容易幻觉调用。最终数据管道：真实日志（5%）→ 模板生成（20%）→ 大模型合成（60%）→ 负例（15%）。总数据量 50-100 万条，覆盖 100+ 函数 schema。验证阶段：用 held-out 测试集（人工标注 500 条）评估调用准确率和拒绝率，目标：调用准确率 >95%，拒绝率 >90%。

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

“这个问题我从数据来源、合成策略、负例设计三个层面回答。第一，用真实日志做种子集，保证基础质量；第二，用模板+大模型合成覆盖参数边界和多样性，并通过自洽性检查过滤幻觉；第三，设计负例让模型学会拒绝和错误恢复。总结一句：Function Call 训练数据的核心不是量，而是正负例平衡和参数覆盖度。”

4️⃣ 高频追问 & 应对

追问 1：你提到自洽性检查，但 3 次采样一致性太低怎么办？比如只有 60% 的样本通过检查。

应对策略：这是常见问题。原因通常是教师模型对参数格式理解不一致（如 date 写为 “2025-03-21” vs “March 21, 2025”）。解法：在检查前做参数标准化——对日期、地点等字段用统一格式（如 ISO 8601 日期、城市代码）。如果通过率仍低（<70%），说明函数 schema 定义模糊，需要简化参数名或增加枚举值。工程上，我通常接受 70-80% 的通过率，丢弃 20-30% 的样本是合理的 trade-off，因为保留低质量样本会污染模型。

追问 2：负例怎么确保模型不会学到“所有查询都拒绝”？

应对策略：关键在于负例的分布设计。不要把负例集中在“无关查询”上，要混合“部分匹配”的负例。例如：用户说“查北京天气”，但函数参数是 city 而非 location——模型应拒绝，但拒绝后需给出正确参数提示。训练时，负例的 loss 权重可以降低到正例的 0.5 倍，避免模型过度偏向拒绝。另外，在验证集上监控“假阳性拒绝率”（即本应调用但模型拒绝的比率），目标 <5%。

追问 3：如果只有 10 个函数，数据量需要多少？

应对策略：10 个函数属于小规模场景，数据量可以降到 5-10 万条。但关键不是量，而是每个函数的参数组合覆盖。例如，get_weather 有 3 个参数（location, date, unit），每个参数 5 个值，组合就是 125 种。建议用模板生成覆盖 80% 的组合，再补 20% 的边界值（如空值、超长字符串）。小规模场景下，人工标注 200-500 条高质量种子数据比大模型合成更有效。

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

• ❌ “直接用 GPT-4 生成 100 万条数据，然后训练。” → ✅ 必须加自洽性检查和负例设计，否则模型会学到“永远调用”或“参数格式混乱”。
• ❌ “负例就是随机替换参数值，比如把 location=“北京” 改成 location=“上海”。” → ✅ 负例需要语义合理性，比如“查北京天气”但函数参数是 city，模型应拒绝而非错误调用。随机替换会让模型学到“参数值可以乱填”。

6️⃣ 简历呼应

• 如果你有 RAG 项目：从“工具调用 vs 检索”的相似性切入，强调数据构建中“参数覆盖度”类似于 RAG 中的“文档分块策略”，都需要枚举边界情况。
• 如果你只做过传统 NLP：类比“序列标注数据构建”，Function Call 的 no_call 负例类似于 NER 中的“O 标签”，需要平衡正负样本比例，避免模型过拟合。
• 如果你是校招无项目：聚焦论文复现，提到读过《Toolformer》和《Gorilla》的数据构建方法，并自己用 GPT-4 合成过 1000 条天气函数调用数据，验证了自洽性检查的有效性。

7️⃣ 延伸阅读

• 《Toolformer: Language Models Can Teach Themselves to Use Tools》（2023）
• 《Gorilla: Large Language Model Connected with Massive APIs》（2023）
• 《Self-Instruct: Aligning Language Models with Self-Generated Instructions》（2022）
• 《APIBank: A Benchmark for Tool-Augmented LLMs》（2023）
• 《ToolBench: An Open Platform for Training, Serving, and Evaluating LLMs with Tool Use》（2024）