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

我之前调类似项目也踩过这个坑，Qwen2.5-7B对严格JSON schema的遵循确实偏弱，尤其你只喂了2万条真实日志，负样本和边界情况肯定不够。建议先别急着换架构，试试在训练时把参数类型错误的样本专门抽出来做纠错对，或者用约束解码（比如outlines）来硬性卡schema，效果可能比微调更直接。换大模型比如72B会有改善，但成本翻倍，Function calling专用模型比如GLM或DeepSeek的tool模式也许更划算，不过也得看你的API复杂度。

说实话你这情况我太熟了，之前用7B做类似工具调用也栽在参数类型上。我个人感觉不完全是数据负样本的问题，虽然负样本确实重要，但2万条日志里真正覆盖到“错误类型”的样本可能没你想的那么多，模型学到的是“格式”而不是“约束”。你试试把训练数据里故意混入一些参数类型错误的样本，然后让模型学会纠正，比单纯加正样本管用得多。另外7B在严格JSON schema遵循上确实吃力，尤其是MCP这种带复杂嵌套结构的协议，它的注意力分配容易在小细节上崩。我后来换成Qwen2.5-14B或者干脆用带function calling微调的版本，错误率掉了一半不止。但如果你不想换模型，可以试试在推理时加一个“先输出参数类型检查，再输出实际参数”的两步prompt，或者用grammar-based sampling强制约束输出，比靠模型自觉靠谱。说到底，7B能做但很勉强，你要是追求稳定，直接上32B或者用专用模型更省心。

我之前微调同类模型也踩过这坑，参数类型错乱大概率是数据里负样本太少了，模型没学会“拒绝错误格式”的边界。建议你从日志里抽点人工构造的错例加进去，比单纯堆数据量管用。7B做严格工具调用确实吃紧，尤其MCP这种强schema约束，换成Qwen的function calling版或32B以上会有明显改善，但推理成本也会上去。另外可以试试在解码时加个JSON schema校验，至少能兜底。

说实话我觉得你这个情况挺典型的，7B模型做严格schema约束本来就吃力，MCP那套工具定义又长又绕，模型注意力稍微一分散就容易把类型搞混。我怀疑不光是负样本的问题，你2万条数据里如果正样本占绝大多数，模型其实是在硬记输出格式而不是真正理解参数结构，换个说法就是它没学会“类型”这个概念，只是模仿了字符串的样子。我之前试过类似场景，把工具定义改成更精简的伪代码形式，效果反而比在prompt里反复强调格式要好，因为模型更容易抓住关键约束。另外你提到function calling专用模型，我觉得值得一试，毕竟它们在训练时就强化过参数校验的逻辑，但要是API数量太多，小模型照样会懵。还有个思路是后处理兜底，写个轻量校验层自动纠正类型错误，虽然治标不治本，但能快速把线上问题压下去。你数据里有没有刻意构造过那种“一个参数多种合法类型”的样本？我觉得这个比单纯加负样本更管用，能逼模型学会类型推断而不是死记硬背。

说实话我觉得你这情况更像是数据问题，2万条日志里如果参数错误的负样本占比太低，模型根本学不到“不该这么填”的边界，光靠prompt约束是压不住的。我自己试过在类似场景里把错误调用样本硬凑到15%以上，再配合把必填字段缺失的情况单独做成对抗样本，效果比换模型明显。另外Qwen2.5-7B的function calling能力本来就偏弱，它对JSON schema的理解不够结构化，你要是换Qwen2.5-14B或专门调过的function calling模型，哪怕数据不变也能改善一截，但成本也上去了。建议你先花两天做一轮数据增强，把类型错误和缺字段的负样本专门搓出来，再决定要不要换底座。

数据里负样本太少了，漏填错填的case得多喂点，光靠prompt压不住7B的野路子。

换Qwen的function calling版或者32B以上，约束力会明显强一截，但先别急着换，把bad case挑出来回填训练更划算。

说实话我更倾向于是数据问题，2万条日志看着不少但分布可能很畸形，必填字段缺失和类型错误的负样本如果占比太低，模型根本学不到“不能这么填”的边界。7B模型不是不能做严格输出，但光靠prompt约束确实压不住它在概率上的惯性。你试试把日志里所有错误调用单独抽出来，合成一批“错误-修正”对，让模型看到正反例的对比，比单纯加few-shot管用得多。至于换模型，我猜32B以上会稳一些，但成本翻倍不一定值，先把数据里的错误模式挖透再说。

我之前做类似项目也踩过这个坑，2万条数据其实不算多，尤其真实日志里工具参数正确的样本肯定占大头，模型学到的更多是“常见用法”而不是“严格约束”。建议你先把错误的调用日志单独抽出来，合成一些负样本再训一轮，比换模型成本低多了。另外7B在输出格式上确实容易飘，如果API数量多且参数复杂，换Qwen的function calling版本或者32B会有明显改善，但推理开销得权衡一下。你试过在解码的时候加JSON schema校验或者用约束解码库吗？那个对漏字段和类型错挺管用的，就是得在推理流程里改一下。

我觉得这大概率不是模型架构的问题，7B做严格schema约束确实吃力，但2万条数据对十几个API来说也偏少了，每个工具平均下来才一千多条样本。你可以先试着把训练数据里故意混入一些“参数类型错误但语义正确”的负样本，让模型学会纠正，而不是只靠prompt硬压。另外，Qwen的function calling版本对工具调用的输出格式做过专门优化，换那个base比硬调通用模型省事很多，我之前试过同样数据量效果能提一截。

说实话我觉得7B做严格schema约束确实吃力，尤其是MCP这种工具定义复杂、参数嵌套多的情况，小模型对类型边界的感知很弱。你2万条数据虽然不少，但负样本比例如果低于15%，模型很难学会“不犯错”，建议专门构造一些类型混淆和缺字段的反例。另外Qwen的function calling版本对工具调用的输出格式有额外对齐，换那个模型比硬调base版省事很多，我们之前用qwen2.5-7b-instruct也踩过类似坑。如果数据实在不好补，试试把工具参数定义改成更扁平的JSON结构，减少嵌套层次，模型出错率会明显下降。

我之前调过类似的项目，7B模型在严格JSON schema约束上确实容易翻车，参数类型错误大概率不是数据量的问题，而是模型本身的指令跟随上限。建议先检查一下训练数据里是否覆盖了各种边界情况，比如数组空值、字段缺失的样本，负样本太单一也会导致这种问题。换更大模型或者专门做function calling的模型（比如Qwen的FC版本）会明显改善，但成本也上去了。如果暂时不想换模型，可以试试在推理时加一层输出校验和重试逻辑，强制纠正类型错误，效果比纯靠prompt稳定。

说实话我之前用7B做类似的事也踩过这坑，后来发现光靠prompt约束没用，得在数据里刻意构造那种“类型错误”的负样本，让模型学会拒绝或修正。另外Qwen的function calling版本可能天生对schema更敏感，你可以试试直接用它的原版工具调用格式，别自己改MCP那套映射。

看到你说loss降得快但推理时参数类型乱填，我第一反应是这跟7B模型的指令遵循上限关系不大，更可能是数据构造和采样策略的问题。我之前用8B模型做类似tool calling时也踩过坑，后来发现光有真实日志不够，得特意往训练集里塞一批“故意犯错”的负样本，比如把参数类型写错、漏字段的对话，让模型学会纠正而不是盲目模仿。另外你提到MCP协议，我怀疑你清洗数据时把工具定义的schema和调用时的实际参数绑定得太松了，模型没学到“类型必须严格匹配”这个隐含规则——试试在训练时把每个工具的JSON Schema直接拼进user消息，并且对输出做结构化约束，比如用grammar sampling强制生成合法JSON。换更大模型或者专门的function calling模型确实会稳一些，但成本也高，我建议先检查一下你的2万条数据里，类型错误和漏字段的样本占比有没有超过10%，如果太少，模型根本没见过这类错误模式，自然就不会规避。还有个细节，你3个epoch可能有点过拟合到高频工具上了，低频工具的参数错误率会更高，试试用类别平衡采样或者对低频工具做数据增强。

数据里负样本太少的话，模型确实学不会“不该填什么”，建议先按参数类型构造点错误case试试。

1. 2万条真实日志其实不算多，尤其十几个API的调用模式差异大，模型很可能没见过足够多“错误类型”的样本，建议先做一轮数据增强，把参数类型/缺失字段的负例显式构造出来再训一轮看看。
2. 7B做严格结构化输出确实吃力，但也不至于完全不行，我试过在解码时加一层JSON schema校验，配合logit mask，比纯靠模型记忆靠谱很多，你可以先试这个。
3. 换更大模型肯定有改善，但成本也上去了，建议先用Qwen的function calling版本对比下，它自带工具约束能力，可能比你微调更稳。
4. 另外检查下微调时有没有把工具定义本身也拼进输入，有时候模型是把工具描述和参数映射搞混了，加个显式类型提示字段会好很多。

2万条数据对7B来说还是少了，而且你清洗日志时负样本估计被过滤掉不少。建议先把失败案例单独拎出来重训试试，换模型不一定是首选。

数据里缺显式类型标注的话，模型学不到约束很正常。我试过在训练时把JSON Schema直接拼进输入，比在prompt里强调管用。

说实话我觉得这大概率还是数据的问题，2万条日志里如果负样本本来就少，模型压根没学会“出错长什么样”，那它当然默认按自己最顺手的格式来。你可以试试把清洗后的数据里故意掺一些错误调用再配正确修正，做成对比样本，效果可能比换模型来得直接。另外Qwen2.5-7B对这种强约束输出确实吃力，但不至于完全不行，我见过有人用更小的模型靠约束解码也能稳住，关键是推理时加个schema校验做二次拦截，别全靠模型自觉。换大模型肯定有改善，但成本上来了，建议先把数据折腾透了再考虑架构。

我遇到过类似的情况，loss降得快不代表模型真的学会了格式约束，它可能只是记住了训练集里的分布。2万条数据对7B来说确实偏少，尤其是十几个API的参数模式各不相同，模型很容易混淆。建议你先统计一下训练数据里每个API的调用次数，肯定有些冷门的API样本太少，模型自然学不牢。另外可以试试在训练时把参数schema直接拼到样本里，让模型生成时能“看到”当前工具的定义，比单纯靠prompt提示稳定得多。至于换模型，我个人的经验是7B做严格JSON输出确实吃力，换Qwen2.5-14B或者专门优化的function calling模型会有明显改善，但成本和推理速度也要权衡下。

说实话你这个情况我太有共鸣了，之前用7B模型调MCP也是栽在参数类型上，尤其数组和对象嵌套时简直灾难。我后来排查发现，问题根源其实不在模型架构，而是数据里负样本几乎为零——真实调用日志里成功案例占九成以上，模型压根没见过“填错类型”的反例，它自然学不会纠错。你可以试试故意把训练数据里10%到15%的样本改成错误参数，然后让模型学习输出“调用失败+修正建议”，这样比单纯堆格式说明管用得多。另外，2万条数据对7B来说其实偏少，尤其十几个API各自参数规则差异大，每个工具分到的有效样本可能就一千多条，模型根本记不住。我当时是把数据按工具分组，每个工具单独跑几个epoch，效果比混合训练好不少。至于换模型，我试过Qwen的function calling版，确实在参数结构上更稳，但7B的底子限制还是摆在那，复杂嵌套字段照样翻车。如果你们API数量短期不会猛增，我建议先花时间做数据清洗和负样本增强，成本比换模型低多了，实在不行再考虑14B，毕竟部署和推理开销也要算进去。