微调后的模型做Agent工具调用，总是乱选函数怎么办？

数据量太少是关键，几百条覆盖不了多样场景，建议至少上千条并加入负样本。

感觉问题可能出在数据质量上，几百条样本对工具调用来说确实少了点，而且如果格式不统一或者负样本（比如用户说“闹钟”但故意不匹配）太少，模型容易混淆。我自己试过用Qwen2.5-7B，其实7B做tool calling是够用的，但LoRA微调时得特别注意函数描述的多样性，比如同一种功能用不同方式写进instruction里。另外可以检查下训练数据里有没有把工具名称和参数类型对齐，比如“闹钟”对应的时间参数是不是都用的ISO格式，不然模型容易乱填。

几百条数据确实少了点，LoRA对工具调用的边界案例覆盖不够，建议先试试在训练数据里多塞些故意混淆的例子。

说实话，你这个情况我在做类似项目的时候也踩过坑，几百条数据其实不太够，特别是工具调用这种需要模型精确理解意图和参数结构的任务。我觉得问题可能不光是数据量，而是数据分布的问题——你是不是每条数据里工具描述都写得太长或者太相似了？我试过把工具描述精简成关键词+示例，反而模型选得更准。另外7B模型做结构化输出其实够用，但Lora微调时容易让模型“记住”训练集里的模式，导致它把“闹钟”和“天气”这种高频词混淆，你可以试试在训练数据里故意加一些“用户说闹钟但实际意图是查时间”这种干扰样本。还有个小技巧，就是输出格式不要用JSON，改成一个固定的模板字符串，比如“工具名|参数1=值1|参数2=值2”，模型对这种线性结构的学习效率比嵌套JSON高不少。如果你还没试过，建议把工具调用拆成两步：先让模型输出意图分类，再根据分类生成参数，这样准确率能提一截。

几百条数据确实有点少，而且LoRA微调对工具调用的结构化对齐能力其实偏弱，7B本身做复杂tool calling是没问题的，关键是数据里要让模型学会“先理解意图再映射函数”，而不是死记硬背。建议你试试把训练数据里的工具描述改成统一格式，每个函数都加上清晰的输入输出示例，同时用随机打乱工具列表的方式让模型学会根据语义选择，而不是靠位置记忆。另外可以看看是不是prompt里把工具定义放在了system角色里，有些微调后的模型对system角色的遵循度反而变差了。

这个我太有同感了，我之前用7B模型做工具调用也踩过类似的坑。问题大概率不在模型大小，而是微调数据和输出格式的设计。关键点在于：模型需要学会“先理解意图，再匹配工具”，而不是直接跳转到函数名。你训练数据里的对话，有没有把工具描述和调用逻辑拆成更细的步骤？比如，每条数据最好都包含“用户意图分析-工具选择依据-参数填充”这样的隐式推理链，而不是只给输入输出对。另外，Lora微调时如果只让模型记住工具名和参数格式，它很容易在模糊指令下随机关联——比如“闹钟”和“时间”两个词同时出现，就可能被误导去查天气。我试过的一个有效改进是：在prompt里加上“先输出一个简短的推理过程”的指令，哪怕微调时也加入这种思维链数据，准确率能提不少。你整理的那几百条数据，能确保覆盖“相似但不同工具”的边界情况吗？比如“设闹钟”和“查天气”都涉及时间参数，数据里得有正反例来区分。

几百条数据对tool calling来说确实少了点，模型容易把函数意图和参数填法搞混。我试过在数据里多造一些“混淆样本”，比如把“设闹钟”和“查天气”的句式故意写得相近，然后标注清楚，效果会好不少。另外7B模型做结构化输出其实够用，但Lora微调时建议把工具描述和函数签名一起放进输入，别只靠prompt硬给权重。你检查过测试集里有没有类似错误？说不定是数据分布偏了。

几百条数据太少了，LoRA微调在这种结构化任务上很容易过拟合，建议试试几千条高质量数据+加一些负样本。

几百条数据确实有点少了，LoRA微调对这种结构化输出特别吃数据质量和多样性。我之前试过把函数调用的few-shot示例直接怼进system prompt里，比单靠微调管用，你可以先试试这个。另外检查下是不是训练时把函数名和参数描述写得太含糊了，模型可能根本没学会区分语义边界，不一定是7B的锅，我拿4B模型好好调也能做到七成以上准确率。

几百条数据微调7B做tool calling确实有点勉强，结构化输出对模型推理能力要求挺高的，数据量不够很容易学偏。你试试把每个工具调用拆成多轮对话样本，加上用户拒绝或纠正的场景，让模型学会从错误里修正选择。另外Qwen官方有专门做function calling的版本，直接拿来用比微调靠谱，或者用带tool calling模板的基座模型，效果会好很多。

几百条数据太少了，LoRA微调7B做工具调用容易过拟合，建议直接上Qwen的函数调用模板或换72B。

数据质量比数量重要，检查下你的tool schema是不是和训练时一致，格式乱八成是这里的问题。

说实话几百条数据做工具调用微调确实太少了，LoRA对这种结构化输出的约束力有限，模型很容易把函数名和参数当成闲聊内容处理。你可以试试把工具定义直接写进system prompt里，用few-shot示例把每个函数的调用格式固定死，比微调管用。另外检查下训练数据里是不是存在歧义，比如“设置闹钟”和“查天气”的意图边界有没有在对话里拉开。7B做简单tool calling其实够用，但前提是任务范围别太宽，先把函数数量砍到三五个内试试。

几百条数据确实不太够，LoRA微调对这种结构化输出很容易过拟合到训练集上。我之前试过把工具描述改成更明确的“触发条件”加“示例”格式，效果比单纯加大权重好很多。另外你可以试试few-shot，在prompt里固定放两三个不同场景的正确调用示例，让模型照着格式走。7B做tool calling其实够用，但你的训练数据里如果天气和闹钟这类例子比例不均衡，模型就会学偏。

说实话我觉得你这几百条数据本身可能就是最大瓶颈，tool calling这种任务对数据多样性要求特别高，函数名、参数顺序、用户意图的排列组合稍微一变模型就懵了。我试过类似场景，光靠LoRA微调小模型做结构化输出确实容易翻车，7B在指令跟随和函数选择上的边界比想象中要明显，尤其当工具数量超过五个的时候。你可以先检查一下训练数据里是不是存在“天气”和“闹钟”这类高频函数互相干扰的情况，比如某些样本里用户表述含糊但标注却带倾向性，模型会学到错误关联。另一个思路是别让模型直接输出函数名，改成先让模型生成自然语言的“意图候选列表”，再套一层规则匹配到具体API，这样容错率高很多。还有个小技巧，把函数描述写得更像“触发条件”而不是“功能说明”，比如明确写“仅当用户提到时间+动作时才选闹钟”，实测比加大权重有用。如果条件允许，试试把Qwen换成同尺寸的function calling专用模型，或者用GPT-4o-mini做蒸馏教师，生成几百条高质量伪数据来扩充训练集，效果可能立竿见影。最后别忽略推理时的temperature设置，tool calling任务我一般调到0.1以下，能明显减少随机乱选的情况。

几百条数据太少了，先试试用GPT-4批量生成高质量指令数据，比调prompt靠谱。

7B微调做tool calling确实吃力，建议换Qwen2.5-72B或者直接上function calling特化模型。

说实话我觉得问题大概率不在模型大小，7B做tool calling完全够用，关键还是你训练数据的构造方式。你几百条对话里，函数选择的分布是不是均匀？如果查天气的例子占了一半，模型当然容易形成路径依赖，一看到时间相关的词就往天气API上靠。我建议你先把训练样本里每个工具的调用次数拉平，甚至故意多塞一些容易混淆的边界case，比如“明天早上8点叫我”这种带时间但必须选闹钟的。

另外你提到参数填得乱，这往往是数据里function schema的表述和推理时用的prompt不一致导致的。你微调时是怎么把工具定义写进对话的？是纯文本描述还是JSON格式？如果训练时格式和推理时不完全一样，模型学到的映射就废了。我试过把工具定义放在系统消息里，并且每次只给当前可用的几个函数，效果比一股脑全塞进去好很多。

还有一个可能是你Lora的rank和alpha设置太小，模型没真正学会结构化输出的约束。你试过把rank调到64甚至128，然后多训几个epoch看loss是否还在降吗？我之前用Qwen2.5-3B做类似任务，调高rank后准确率直接从58%蹦到79%。另外，你可以在推理时加一个强制约束，比如用正则过滤掉不匹配函数名的输出，或者用grammar-based sampling，这能兜底很多乱选的情况。

最后想问下，你训练数据里有没有包含拒绝调用的样本？比如用户说“随便聊聊”时模型应该不调用任何工具。如果没有这种负样本，模型会倾向于对所有输入都硬套一个函数，那自然容易选错。我自己的经验是，负样本比例至少要到20%，模型才懂得区分什么时候该动手，什么时候该闭嘴。

几百条数据确实有点少，LoRA微调对这种结构化输出特别敏感，数据里函数调用的样本分布稍微不均模型就会学偏。你可以先检查一下是不是某个工具在训练集里占比太高，导致模型有先入为主的倾向。另外建议试试把工具描述改成更明确的“当用户提到闹钟时，必须调用set_alarm”这种指令式表述，比单纯加权重管用。7B做tool calling其实够用，但需要配合约束解码，比如用grammar或json schema强制输出格式，能大幅减少乱选参数的问题。

几百条数据确实有点少，而且LoRA微调对结构化输出的约束力本来就不强，我试过类似方案，效果也很飘。建议你检查下训练样本里是不是函数名和参数长得太像了，比如天气和闹钟都带时间字段，模型容易混淆。可以试试把工具描述改成更极端的对比句式，或者在推理时加一层规则校验，先过滤掉明显不合理的候选函数。另外7B做这个确实吃力，但也不是完全不行，你可以看看Qwen官方的function calling模板，按那个格式重新整理数据，比自定义格式靠谱得多。

几百条数据确实有点少了，LoRA在这种低资源下很容易让模型把“调用工具”和“具体函数名”的关联学歪，尤其Qwen对函数选择本身就很敏感。你试过把每个工具的描述里加上“当用户提到闹钟时使用此函数”这种强引导吗？另外可以看看是不是数据里查询天气的样本占比太高，导致模型有偏向性。如果方便的话，建议直接用Qwen官方的tool calling模板再生成一批合成数据，把格式对齐到它预训练时见过的样子，效果可能比微调更稳。

说实话几百条数据微调7B做tool calling确实有点少，函数选择这种结构化任务对数据多样性要求很高，你试试把训练样本里故意混入一些相似指令但对应不同函数的case，比如设闹钟和查天气的边界场景。另外你Lora的rank和alpha调过没？我之前用4和32效果比默认好不少。如果数据实在扩不了，建议直接用现成的function calling模型做底座，7B硬调这个确实容易翻车。