面试官问：Function Call 的训练数据怎么构建？

摘要

1) 一句话总结 本文系统阐述了Agent中Function Call训练数据的构建方法，涵盖训练目标、样本结构、数据来源、配比规模及微调策略，旨在解决通用大模型在实际业务工具调用中的不稳定性。

2) 核心要点

训练目标：不仅是让模型调用正确工具，还需培养工具选择、参数绑定（解析模糊/隐式信息）、格式化（严格遵循JSON/Schema）以及多轮上下文补全这四种能力。
样本结构：完整的数据集应包含正样本（标准调用场景）、负样本（闲聊或需澄清的混合意图，不调用工具）和难例（需CoT推理、多轮记忆、模糊地名/日期解析等）。
数据来源：主要分为四类：合成数据（低资源场景占比可达70%以上）、真实对话日志、规则生成的边界样本，以及由调用失败场景反向加入的Badcase驱动样本。
比例控制：通用配比为正样本60%、难例30%、负样本10%；随着系统成熟，难例比例应逐渐提高。
数据规模：简单业务需几千条，中等复杂度（如航旅、电商）需1–5万条，企业级多轮Agent需10万条以上。
训练方式：轻量级训练通常采用LoRA/Adapter（成本低、迭代快）；复杂或强流程场景采用重训（SFT + DPO/ORPO）以惩罚错误行为并增强可控性。
实战效果：通过系统性训练闭环，可将工具调用准确率从62%提升至94%，JSON结构错误下降80%，参数缺失错误降至个位数。

3) 风险与不足（原文提及）

生产环境失控风险：若仅依赖模型的“自然能力”而不进行训练，系统在生产环境中极易出现选错工具、函数名拼错、参数解析错误、忽略工具直接回答或产生幻觉等Badcase。
格式化错误风险：模型即使选对了工具，也常出现JSON拼接错误（如缺引号、少括号、值类型错误），导致调用失败。
混合意图处理风险：在面对用户混合意图或模糊输入时，若缺乏负样本训练，模型容易跳过澄清步骤直接错误地调用工具。

正文

大家好，我是吴师兄。

在 Agent 相关的面试题里，有一道极其关键、但很多人答不好的问题：“你们的 Function Call 是怎么训练的？训练数据怎么构建的？”

为什么面试官喜欢问这题？因为真实落地的 Agent 系统，一定绕不开训练数据。如果没有自己的数据集，就只能依赖模型的“自然能力”，但自然能力只在 Demo 里好看，一上生产就会乱跑。

反过来，一个工程师如果能讲清楚：为什么需要训练？用什么样的数据？怎么构建？怎么迭代？怎么评估？那么基本可以确定：他不是玩概念，而是真的做过项目。

这一篇，我们就按照实际工程体系，把这道题拆开说清楚。

一、为什么 Function Call 需要训练？

原因一句话就能讲明白：“通用大模型不会天然理解你的业务工具。”

例如你给模型 6 个函数：search_flights、book_flight、search_hotels、book_hotel、get_weather、get_user_profile。看起来很清晰，但对模型来说，它不知道你系统的默认逻辑，也不知道你业务的最佳流程。

所以没有经过训练的模型会出现各种行为：

选错工具
函数名拼错
参数格式不对
数字/日期解析错误
忽略工具，直接用自然语言回答
幻觉生成 Tool Call
多轮信息缺失

这些都是生产系统里最常见的 Badcase。因此，Function Call 想稳定，必须加训练数据来“打磨模型的习惯”。

二、训练数据的目标是什么？

很多人以为任务叫“Function Call”，目标就只有一个：“让模型调用正确的工具。”但这并不完整。

一个真实的 Function Call 训练集，通常要同时教给模型 4 种能力：

工具选择能力（Tool Selection） 模型要学会：什么场景选什么工具，什么场景不选工具。
参数绑定能力（Argument Filling） 能正确解析用户自然语言里的参数，例如：时间（“明天”→“本周六”）、城市（“魔都”→上海）、数字（“三天”→3），以及隐式信息（用户偏好、历史记忆）。
格式化能力（JSON / Schema） 很多模型“工具选对了”，但 JSON 拼错了（缺引号、少括号、值类型错误等）。训练集要让它习惯按 Schema 生成。
多轮上下文能力（Multi-turn） 例如：
- Turn 1：“想去北京玩几天。”
- Turn 2：“下周一出发。”
- Turn 3：“帮我查机票。” 训练集必须告诉模型：如何利用记忆和上下文补全参数。

三、Function Call 的训练数据应该长什么样？

这一部分是“决胜分区”。能讲清楚训练样本的结构，就是“做过”和“没做过”的分界线。一般包括三个部分：

① 正样本（Positive Examples） 告诉模型：“遇到这种 Query，你应该这么调用工具。”覆盖常规场景。

User: 帮我查一下明天从上海到北京的机票。
Assistant:
{
  "tool": "search_flights",
  "args": {
    "origin": "上海",
    "destination": "北京",
    "date": "2023-10-30"
  }
}

② 负样本（Negative Examples） 告诉模型：“这种不能使用工具，或者你之前的行为是错的。”

闲聊场景： 用户问“北京最近冷吗？”，负样本要标注 Assistant 不给工具调用，直接回答“北京未来三天的天气较冷…”。
混合意图场景： 用户问“给我来一份天气订票。”，负样本应该告诉模型，这类混合意图需要先澄清，不能直接调用任何工具。

③ 难例（Hard Cases） 这是训练数据中最关键的一部分。包含：

需要 CoT 推理才能找到参数
需要多轮记忆才能补全信息
用户输入模糊，需要澄清
错误示例 → 正确修正示例
JSON 类型容易错的样本
模糊地名、口语表达、方言

例如：

User: 帮我查一下后天魔都飞帝都的机票。
Assistant (tool_call):
{
  "tool": "search_flights",
  "args": {
    "origin": "上海",
    "destination": "北京",
    "date": "2023-10-31"
  }
}

这个样本用到了俗称识别、日期解析和参数抽取。这类样本越多，模型越稳。

四、训练数据从哪里来？

一般包括四类来源，面试时说这段可以直接加分：

合成数据（Synthetic Data）—— 最重要 用模板或 LLM 自动生成大量样本。比如组合“帮我查/查询/看一下…明天/后天…上海→北京…的航班”，形成成千上万条数据。对于低资源业务场景，合成数据占比可以达到 70% 以上。
真实对话日志（Real Logs） 如果系统已经上线，那么真实日志是最宝贵的训练源。它包含用户真实表达、大量隐式信息和歧义。尤其是 Badcase，整个训练集的灵魂就在这里。
规则生成的边界样本（Rule-based Hard Cases） 用于强化日期边界（跨月、模糊日期）、模糊表达（“明早”“后天晚上”）、用户错别字/不完整句子、Tool Schema 边界值、参数缺失与冲突。这些用 LLM 自动生成也可以。
Badcase 驱动（Error-driven）样本 每次模型调用失败，就把失败场景反向加入训练集。形成“数据闭环”。比如 Badcase 是 search_flights(date="tomorrow") 但 origin 缺失。那么训练集应该补一条：
- User: 明天飞北京的机票
- Assistant: 请问您从哪个城市出发？

五、训练集的规模与比例怎么控制？

比较通用的比例搭配：

正样本： 60%
难例： 30%
负样本： 10%

对成熟系统来说，难例比例会逐渐提高，因为边界错误会越来越多。样本规模一般取决于工具数量和业务复杂度：

简单业务： 几千条
中等复杂度（航旅、电商）： 1–5 万条
多轮 Agent（企业级助手）： 10 万条以上

你在面试中说出这个区间，基本属于“深度选手”了。

六、训练应该怎么做？

这部分面试官也会问，主要有两种路径：

轻训：LoRA / Adapter（最常见） 只在工具调用能力上做微调。训练快、成本低、效果稳定。适合少量工具、智能助手类 Agent 以及需要频繁迭代的项目。
重训：Supervised Fine-tuning + Preference Optimization 适合工具多、参数复杂、强流程型 Agent（比如金融类），以及需要严格避免幻觉的场景。一般会采用 SFT 学“正确行为”，结合 DPO / ORPO 惩罚错误行为，增强可控性。

七、面试官会很喜欢听的一段话（建议背诵）

“我们的 Function Call 训练集分三种：正样本、负样本和难例。正样本教模型工具的标准调用方式；难例覆盖用户模糊表达、多轮上下文、参数歧义；负样本用于告诉模型哪些场景不能调用工具。全部样本通过合成数据、真实日志和 Badcase 驱动构建，形成持续闭环。最终训练采用 LoRA，使模型在我们业务的工具使用上具备高度稳定性。”

这一段面试官听了就知道你不是“看文档的”，而是“做过工程的”。

八、结语与实战经验

Function Call 的训练不是“有没有做”，而是有没有体系、有没有闭环、有没有从错误中迭代出来的结果。没有训练的 Agent，只会在 Demo 里看起来很聪明；真正稳定的系统，背后一定是大量带标注的数据和不断优化的 Badcase 流水线。

在训练营的多个 Agent 实战项目里，我们用同样的方法做到了：

工具调用准确率从 62% 提升至 94%
JSON 结构错误下降 80%
参数缺失类错误下降到个位数
多轮对话成功率显著提升

这段时间，我陆续写了二十几篇关于 RAG（检索增强生成）的面试答题文章，阅读量和反馈都非常好。很多同学说，看完之后不仅知道“怎么答”，还知道“为什么这么答”，甚至能把思路直接用到自己的项目里。其实，这些文章并不是凭空写出来的，也不是简单整理网络资料，而是来自我在大模型训练营里的真实项目沉淀。

训练营里有多个从零到落地的实战项目：

企业培训问答 Agent（含多轮理解与记忆模块）
金融研报 RAG 系统（混合检索、重排序、多模态解析）
行业深研助手 DeepResearch（实时检索 + 知识沉淀链路）
深学 AI 学习助手（上下文结构化与生成链路可解释）

这些实战项目不是“照着文档做一遍”，而是带着同学一步步拆逻辑、跑代码、调权重、对指标，最终能说清楚“为什么这么设计、哪里容易踩坑、怎么迭代优化”。这些内容最终沉淀成内部的体系化笔记、方法论文档、Badcase 修复记录和面试表达模板。

所以你会看到：不是只讲概念，而是讲落地；不是只讲方案，而是讲取舍；不是只讲原理，而是告诉你面试官到底在听什么。

如果你正在准备大模型方向的求职，或希望真正把 RAG 从“知道”变成“能做、能讲、能复盘”，那大模型训练营可能会非常适合你。真正能拉开差距的，从来不是知识点，而是体系与思考方式。

在过去的几个月中，我们已经有超过 80 个同学（战绩真实可查）反馈拿到了心仪的 Offer，包含腾讯、阿里、字节、华为、快手、智谱、月之暗面、MiniMax、小红书等各家大厂，以及传统开发/0基础转行的同学在短时间内拿到了各类大中小厂的 Offer。如果你近期准备转向大模型、想拿下一个能讲清楚、能上简历的实战项目，这可能是你最值得的选择。

wsl-docs

探索