MCP微调后总把工具参数填错，是数据问题还是模型架构该换？

这问题我太熟了，之前用7B调function calling也卡在这。参数类型错乱大概率不是架构问题，而是数据里负样本太少，模型根本没学会“错长什么样”。建议你抽500条人工构造些类型错误、漏字段的坏case混进去，比单纯堆好数据管用。另外Qwen的function calling版可能更适合你，原生模型对严格schema的约束力确实弱。

大概率是数据里负样本太少，模型没见过错例自然学不会纠错，建议先构造点类型错误的反例试试。

我之前也遇到过类似情况，2万条数据对7B来说确实少了点，而且真实日志里大概率存在参数类型的隐性偏差，负样本不足模型就学不到边界。你可以试着把数据里那些错误调用案例也保留下来，甚至主动构造一些混淆样本，让模型学会拒绝或纠正，而不是只学正确路径。另外Qwen2.5-7B的指令跟随在复杂JSON嵌套上确实会飘，但直接换更大的模型成本高，建议先试试把MCP的schema拆得更细，每个工具单独定义参数类型并给死格式模板，可能比换模型更有效。

说实话我觉得你这情况大概率不是模型架构的问题，7B做严格schema约束本来就吃力，尤其MCP那套动态工具定义对指令跟随要求太高了。我之前用类似规模模型也踩过坑，后来是把工具参数转成JSON Schema再强制走grammar decoding，效果比纯靠微调稳定很多。另外你那2万条日志里，负样本和边界case占比多少？如果都是正常调用，模型根本学不会“不该填什么”，建议刻意混一些错例进去。换大模型肯定有改善，但先试试约束解码，成本低多了。

我之前也踩过类似的坑，调完loss降得漂亮，一上真实请求就现原形。个人感觉你这情况大概率不是7B模型扛不住，而是数据分布和训练策略的问题——2万条日志看起来不少，但如果工具调用路径太集中，模型对低频但格式特殊的参数组合根本没学会。我试过把每条日志里的参数schema做成json结构一起喂进去，而不是只给文本形式的调用记录，效果会明显好一些，相当于让模型在生成时能“看”到类型定义。另外，你提到负样本不够，这个方向我认同，可以尝试在数据里刻意混入一些错误类型和缺失字段的样本，然后让模型学会拒绝或者修正，而不是每次都硬生成。关于换模型，我觉得如果业务对格式要求极其严格，上function calling专用模型会省心很多，但7B调好了也不是不行，关键是得把输出层约束住，比如用grammar-based decoding或者logit bias去限制token候选集合，比纯靠prompt稳定得多。还有个细节，MCP返回的schema里如果enum或nullable字段很多，模型很容易懵，建议清洗数据时把这些边角情况单独抽出来做针对性增强。你可以先看看出错集中在哪几个API上，大概率是那几个工具的schema特别复杂，单独给它们多配些few-shot样本试试。

说实话我觉得你这大概率不是模型架构的锅，7B做严格schema约束本来就吃力，但你也别急着换大模型。我之前用Qwen2.5-7B调类似场景，发现loss降得快不代表学到了正确的格式逻辑，反而可能是在死记硬背训练集里的常见模式，一旦遇到参数组合稍微偏一点就原形毕露。你2万条真实日志听着不少，但拆到十几个API上，每个工具平均也就一千多条样本，而且真实日志里大概率成功调用和失败调用的比例是失衡的，负样本少得可怜，模型根本没机会见过“错误长什么样”自然就乱填。建议你先做个数据诊断，看每个必填参数在训练集里的覆盖情况，有没有某些类型组合完全没出现过。另外MCP返回的tool schema本身很关键，你要是只在system prompt里用自然语言描述格式，模型根本没把schema当硬约束，试试把JSON Schema直接拼到每条用户消息后面，让模型在生成时更贴近上下文。我试过在解码阶段加一个简单的规则校验，比如正则检查必填key，不合法就强制重新采样，效果比纯靠模型自觉稳定得多，成本也低。至于换function calling专用模型，比如Qwen的FunctionCalling版本，确实对参数类型更敏感，但你的MCP工具如果动态性很强，专用模型未必覆盖得好，还是先在小模型上把数据增强和约束解码玩明白，再考虑升级。

说实话这种情况我在7B上见太多了，参数类型错乱更像是输出分布没被约束住，光靠prompt很难根治。你可以试试在解码阶段加一个基于JSON schema的强制校验，或者用grammar sampling把输出空间锁死，比换模型省钱多了。

另外2万条数据对十几个API来说有点紧张，特别是冷门工具可能就几百条样本，模型根本没学够。我会优先把日志里那些“调用失败但参数格式正确”的样本也挑出来做负例，让模型学会区分格式错误和逻辑错误。

换大模型或者专门的function calling模型肯定会有改善，但我怀疑你换个Qwen2.5-14B，哪怕不微调，光靠tool calling的预训练能力都比7B微调后稳。如果预算有限，还是先盯数据分布和输出约束吧。

说实话你这情况我也踩过类似的坑，2万条日志看起来不少，但MCP工具参数这种结构化约束，模型其实是在学“格式”而不是学“语义”，纯文本loss降得快不代表它真把类型规则内化了。我个人感觉数据问题可能更大一些，你清洗的时候有没有专门保留那些调用失败或者被后端拒掉的日志？负样本太稀缺的话，模型根本没见过“错长什么样”，自然就瞎填。另外可以试试把参数schema直接拼到每个样本的输入里，而不是只放在system prompt，让模型在生成时“看着”类型定义去输出，效果会稳很多。至于换模型，7B确实在严格JSON输出上比较吃力，尤其当工具数量多、参数嵌套深的时候，注意力容易漂；Qwen本身有function calling的专门版本，如果条件允许，建议直接对比一下同数据下的表现，省得自己调结构。不过也别急着上大模型，先检查下你的采样温度是不是太高了，这类任务温度调到0.1甚至0，加上重复惩罚，有时候比换架构管用。

说实话我觉得你这个问题大概率出在数据上，2万条日志看着不少，但MCP这种多工具场景下参数分布可能很不均匀，模型对低频类型的约束就没学扎实。可以试试把错误类型的样本专门挑出来做负样本增强，或者用规则在训练时强制对齐JSON schema，比换模型性价比高。当然7B在这种严格格式任务上确实吃力，但先别急着上大模型，我见过类似项目用Qwen的function calling版本加一些带错例的SFT，效果提升就挺明显的。

巧了，我之前用7B做类似tool calling也踩过这坑，后来发现把日志里的成功样本按参数类型分组，再人为构造些边界case混进训练集，比单纯堆epoch管用。另外你试过把工具schema改成JSON Schema格式直接写进模型输入吗？Qwen对结构化的schema理解比自然语言描述强不少。换大模型肯定能缓解，但成本涨好几倍，我建议先排查下是不是训练时把参数顺序打乱导致模型学到错误关联。

数据里得加故意填错的负样本，不然模型学不会边界，跟架构关系不大。

2万条对7B够用了，但loss降得快不代表约束学到位了，试试把错误输出当反例硬训进去。

说实话我觉得你这情况大概率不是模型架构的问题，7B做严格JSON schema约束确实吃力，但2万条数据3个epoch对这类任务来说也偏少了，loss降得快不代表它真学会了类型约束，可能只是记住了常见pattern。我之前用类似规模数据微调过工具调用，发现一个关键点是日志里成功样本占绝大多数，模型会倾向复制高频格式，但一旦遇到参数组合稍微变一下就直接崩。你可以先检查一下训练数据里有没有刻意构造类型错误的反例，比如把字符串和数组混合的样本，或者缺字段的负样本，没有的话模型根本不知道“错”长什么样。另外MCP工具返回的schema本身如果很复杂，7B的注意力容易在长上下文中丢失对必填字段的跟踪，我试过把每个工具的schema精简成短描述再拼到user消息里，比放在system prompt里效果好很多。换更大模型或者用专门function calling的比如Qwen2.5-FC版，确实会更稳，但成本也上去了，建议你先从数据扰动和上下文结构下手，说不定不用换架构就能缓解。还有个疑问，你清洗日志时有没有过滤掉那些因为用户乱输入导致工具参数本来就残缺的调用？这类噪声很容易让模型学歪。

2万条日志3个epoch大概率过拟合了，试试加点参数类型错误的负样本，再做点schema约束解码。

参数类型老出错，可能训练数据里正样本太单一了，试试加点类型纠错的对比样本？

2万条数据跑3个epoch确实有点猛，loss降太快反而容易过拟合到表面模式，参数类型这种硬约束它根本没学扎实。我建议先把epoch降到1，然后在训练数据里加一些故意写错参数格式的负样本，让模型学会区分对错。另外Qwen2.5-7B做工具调用本身够用，但MCP这种结构化输出最好配合constrained decoding，光靠prompt和微调很难保证100%不出错。

我们之前也踩过这个坑，2万条日志里大部分都是成功调用，模型根本没机会学“填错长什么样”。你可以在训练集里掺一些故意写错参数的负样本，让它学会区分边界。另外MCP这种结构化输出，光靠loss降没用，得看token级别的准确率，建议单独盯一下参数字段的生成。7B确实偏小，但先别急着换，把数据配比和约束解码调一调可能就够用了。

这种参数类型填错的问题，我觉得八成不是模型架构的锅，7B做工具调用其实够用了。你loss降得快反而可能是个信号，说明模型在死记训练数据里的调用模式，但没真正学到参数schema的约束关系。真实日志清洗后2万条，里面大概率存在大量重复或相似的调用，负样本几乎为零，模型没见过“填错会被惩罚”的场景。我在类似项目里试过，光靠system prompt和few-shot确实不稳定，因为推理时模型对格式的注意力会被语义理解稀释掉。后来我们做了一件事，把每个API的参数schema单独抽出来，构造了一批故意填错字段类型和漏字段的负例，配上纠正后的正例一起训，效果提升很明显。另外可以试试在输出层加个轻量的校验后处理，比如用json schema做一次解析失败就重试，成本低但能兜住不少低级错误。换更大的模型肯定有帮助，但如果你数据构造方式不改，14B甚至32B一样会犯类型错，只是频率低一点而已。

2万条日志微调7B确实容易出这问题，参数类型错和漏字段多半是数据里正样本太单一，模型没学到“边界”。试试加点构造的负样本，比如故意把字段填错再纠正，让它学会自我校验。换大模型或专用function calling模型会稳一些，但根子还是在数据分布和约束解码上，可以先用outlines或者guidance把JSON schema卡死再推理看看。

2万条数据3个epoch有点猛了，参数格式错多半是过拟合加约束没学好，7B其实够用，试试加schema校验的负样本再降下学习率。

参数填错这事我也踩过坑，2万条日志3个epoch loss降得快，恰恰说明模型可能只是记住了格式模板，没真正学会参数约束。你数据里如果负样本少，模型没见过"填错被纠正"的信号，推理时自然容易放飞。我之前用类似规模的数据微调，发现漏必填字段很多时候是训练时把多轮对话截断了，工具调用和返回结果没对齐，模型学了个半吊子。换个角度想，7B做严格结构化输出确实有点吃力，但更关键的是解码策略，你试试加constrained decoding或者用outlines这类库卡住JSON schema，比换模型见效快。function calling专用模型像Hermes或者xLAM确实在参数类型上稳不少，但代价是通用能力会掉，看你能不能接受。另外MCP协议本身对参数描述挺细的，检查下你的schema有没有写清楚类型和required，有时候模型错是因为接口文档太模糊。要真换模型，建议先拿14B试，别直接上72B，性价比不一定划算。