微调后的模型做Agent任务，总乱调用工具怎么办？

说实话这问题我太有共鸣了，之前用Qwen调Agent也翻过同样的车，loss低到0.3照样在真实环境里编工具名。我觉得不只是数据规范的问题，LoRA微调在8B这种规模上很容易把工具调用学成“记忆性触发”，而不是“条件性推理”，训练集里工具名出现频率高了，模型就把它们当成必选项了。你可以试试在数据里混入一些“不调用任何工具直接回答”的样本，比如用户问常识问题，或者请求模糊到不需要工具，让模型学会判断什么时候该停手。另外检查一下你的system prompt是不是把工具清单列得太“显眼”了，有时候模型会照着最近出现的名词瞎猜，你可以在工具描述里加一些“仅当明确需要实时数据时使用”的限定词。还有个小技巧，把工具调用的输出格式改成JSON schema严格校验，解析失败直接重试，至少能拦掉一部分幻觉调用。最后想问你一下，你的2000条数据里，有没有覆盖“工具调用失败”或者“工具返回空结果”的情况？如果没有的话，模型可能压根没学会处理异常路径，这也会让它乱来。

看到你说损失很低但实际调用乱来，我第一反应是LoRA微调2000条数据可能把模型“惯坏”了，它只是死记硬背了训练集里的工具名和参数格式，根本没学会“什么时候该拒绝调用”。我之前用7B模型做类似任务也踩过这坑，后来发现加一个显式的“无工具可用”动作到动作空间里，比单纯约束指令模板有效得多——比如让模型在不确定时输出一个固定的“no_action”标记，再配合一个规则层兜底，能挡掉不少幻觉调用。

另外你说工具名称不规范，这个确实值得深挖。我试过把工具描述改成统一的“动词+名词”格式（比如“search_web”而不是“搜索”或“web_search”），并且把每个工具的输入输出样例直接写进系统提示词里，效果比单纯改训练数据要好。不过更关键的是，你微调时有没有让模型接触“拒绝”场景？比如故意给一些无法用现有工具回答的问题，让模型学会输出“无法处理”，而不是硬编一个工具名。

还有就是温度参数和采样策略，这种任务上温度调到0.3以下会稳很多，不然模型容易在推理时发散。另外建议看看你数据里工具调用的分布，是不是某些工具出现次数太少，导致模型对它们的记忆不牢，反而倾向于生成那些高频出现的工具名。我试过把训练数据里的工具调用序列做去重和均衡，确实减少了乱调用的情况。

最后提个疑问，你的2000条数据都是单轮还是多轮对话？如果纯单轮，模型可能没学会跟踪上下文，真实任务里用户一句话带多个意图它就乱套了。可以试着把一些多轮历史对话也加进去，让模型学会基于已有信息判断“该不该调用”“调用哪个”。调参方向可以先试这些，不一定需要换模型底座。

这个我太有同感了，LoRA微调后工具调用“幻觉”特别常见，尤其是8B这种小模型。我猜你训练集里可能全是正向调用样例，但缺了“不该调用时”的负样本，模型根本没学会拒绝。建议在数据里加点干扰项，比如用户问题含糊时就只回复文本，另外工具名一定要加特殊标记符，类似格式，让它把调用当成一种结构生成任务而不是自由发挥。

说实话这个现象太典型了，LoRA微调在工具调用场景下最大的问题就是“学得太死”——模型记住的是训练集里工具的“字形”，而不是“功能语义”。我怀疑你那2000条数据里工具名重复度太高，导致模型把“工具名”当成了生成文本的一部分去模仿，而不是真正理解了“该用哪个工具解决什么任务”。
我之前做类似项目时也踩过这坑，后来发现光靠微调是不够的，必须把工具描述写成结构化格式塞进system prompt里，比如“工具列表：天气查询（参数：城市）”，让模型在推理时先做一步“工具选择”再生成调用，相当于把自由发挥的空间压缩掉。
还有个思路：你可以故意在数据里加入一些“不该调用工具”的负样本，比如用户问“今天几号”，正确答案应该是直接回答而不是调计算器，这样模型才能学会“拒绝”。
另外，Llama-3-8B本身工具调用能力就偏弱，建议试试在推理时把temperature调到0.1以下，或者用约束解码强制输出格式，能极大减少编造工具名的概率。
你训练时有没有做“多轮对话中的工具调用”数据？如果每轮都是独立调用，模型可能没建立“上下文里已经调用过某工具”的意识，这也会导致乱来。
最后想问下，你评估时的指标是什么？如果只看了loss，那确实说明不了泛化能力，建议直接跑20个真实任务数一下“错误调用率”，再针对性调数据配比。

这问题我也踩过坑，LoRA微调容易让模型死记工具名，建议在数据里混入20%的“拒绝调用”样本试试。

训练时故意给些无关查询，教它回“无可用工具”，不然模型真会瞎编。

说到这个我太有同感了，之前用7B模型跑agent也是这德行，训练时loss跟假的一样，一上真实环境就开始编工具名，感觉模型根本是在“背答案”而不是“理解规则”。我觉得问题可能出在你那2000条数据的构造方式上，如果每条样本里工具名都写得很死，比如永远叫“search”或“calculator”，那模型自然会觉得工具是固定的列表，而不是从上下文里动态推断的。建议你试试在数据里混入一些“工具不存在”或者“应该拒绝调用”的负样本，让模型学会说“我没有这个功能”或者直接给用户反馈，而不是硬编一个API出来。另外，LoRA微调对这种结构化指令的泛化确实不太行，你可以考虑在推理时把工具列表动态拼进system prompt里，并且明确告诉模型“只能使用以下工具，不要创造新工具”，这样至少能挡住一部分幻觉。我那时候还试过在解码的时候加一个简单的规则过滤，把输出里出现的工具名跟当前允许的工具列表比对，不一致就重新采样，效果立竿见影，虽然有点笨但很实用。调参的话，或许可以试着降低temperature到0.1以下，让输出更保守，不然模型太“有创造力”了。

这问题我调过，大概率是数据里没加“不会就拒绝”的样本，模型只会硬编。

我之前用7B模型也踩过这个坑，LoRA微调2000条工具调用数据，损失看着很低，但一上真实环境就原形毕露。后来发现一个关键问题，模型在训练时是把工具名当成了生成文本的一部分，而不是真正理解了“该不该用”这个边界。你提到“拒绝调用”的能力，这个其实很重要，很多时候模型不是不会调工具，而是不知道什么时候该停手。我试过在数据里加入大量“不需要工具”的样本，明确标注输出就是直接回答，效果会好很多。另外你可以在系统提示词里加一层硬性约束，比如“只有用户明确请求时才能调用工具，否则直接回答”，这比单纯依赖微调更可控。还有个小技巧，把工具描述写得极其具体，包括参数类型和返回值格式，模型就不太容易编造不存在的API，因为它的生成分布会被限制住。你那个“天气预报API”的幻觉，很可能是训练数据里工具列表太单一，模型没见过“工具不存在”的反例，所以它倾向于生成一个看起来合理的名字。建议你往数据里混入20%左右的“工具不可用”场景，让模型学会说“我无法获取实时信息”，而不是强行调用。调参的话，可以试试降低temperature到0.1以下，减少随机性，同时加大重复惩罚，这能压住它胡编工具名的问题。你要是方便的话，可以贴一下你数据构造的格式，我怀疑你的工具调用标签和普通文本回复的区分度不够，模型没学到两者在语义上的切换边界。

我之前也踩过这个坑，LoRA微调小模型做Agent特别容易过拟合到训练集的工具名上。建议你检查下数据里是不是所有工具调用都有明确的“无工具可用”样本，模型没见过拒绝路径自然就乱编。另外试试在系统提示里把工具列表和格式约束写死，比靠微调学规矩稳得多。

这问题太典型了，感觉是工具名没做白名单约束，试试在system prompt里硬性规定可用工具列表。

数据里加几条“不调用任何工具”的负样本，让模型学会拒绝，比光堆正样本管用。

这大概率是数据里缺了“拒答”样本，得混入一些不该调工具的场景让模型学会闭嘴。

建议在模板里把工具名写成固定枚举值，再加点随机干扰项，逼它做选择而不是生成。

我之前用7B模型也踩过这坑，LoRA微调数据太少时模型容易把工具名当生成任务来瞎编。后来发现把“不调用工具”也当成一种action加进训练集，效果会稳很多。另外你试试在system prompt里把可用工具列表写成json格式，每次推理前强制解析一遍，对不存在的工具直接返回错误提示，比单纯靠模型自觉靠谱。调参方面，把temperature降到0.1以下，top_p也收紧点，能明显减少乱编的概率。

我之前也踩过类似的坑，LoRA微调后模型对工具名的记忆其实挺脆弱的，尤其训练集里工具调用模式太单一的话，它就容易把“调用工具”本身当成一种惯性输出。你可以试着在数据里混入一些“不该调用工具”的样本，比如用户问闲聊话题时强制让它直接回答，这样模型才能学会边界感。另外，工具描述最好在system prompt里再强调一遍，并且把不存在的工具名故意加个“不可用”前缀，可能比单纯改数据更直接。你现在测试时，temperature是不是设太高了？降到0.1左右可能也会减少幻觉式的自由发挥。

这问题我也踩过坑，大概率是数据里没教它“不知道就说不”，建议混些拒绝调用样本进去试试。

遇到过类似的，LoRA微调确实容易让模型把工具调用学成“生成式幻觉”，尤其是数据里工具名如果出现一次错误写法，模型就会放大这个模式。建议你检查下训练数据里有没有混入“不存在的工具”作为负样本，或者干脆在system prompt里强约束“只能使用给定列表中的工具”，同时把温度调低到0.1以下试试，我这么改之后乱调用的情况少了很多。另外也可以考虑在微调数据里加一些“无法回答就拒绝调用”的样本，让模型学会说“我不确定该用什么工具”，而不是硬编一个出来。

训练数据里得混点“不该调用”的负样本，教它学会说“我不会”。工具名也建议统一带前缀，让模型更好分辨。

这情况八成是数据里工具名太乱，再加点“拒绝调用”的样本试试，LoRA调太狠也容易飘。

这问题太典型了，LoRA微调很容易把工具调用学成“条件反射”而不是“理解意图”。我怀疑你2000条数据里可能全是“必须调用工具”的正样本，模型压根没见过“不该调用”的情况，所以它不会拒绝。建议你往数据里掺一些“用户问题本身就能回答”的样本，强制模型输出“无需工具”或者直接给答案，把拒绝能力也训进去。另外工具名最好是固定枚举格式，别用自然语言描述，减少它自由发挥的空间。

这个问题我太有同感了，之前用Qwen做类似的事也翻过车。我觉得你那个“编造工具名”的现象，大概率不是LoRA没学好，而是模型在生成时把工具调用当成了纯文本续写，压根没建立起“工具名是受约束的枚举值”这个概念。我当时的解法是，在数据构造里刻意混入一些“不该调用工具”的样本，比如用户问个跟工具无关的闲聊，就强制模型输出“无需调用”，这样它才慢慢学会“拒绝”这个动作，比单纯堆正例管用得多。

另外你提到损失降得很低，这个其实有点迷惑性，因为LoRA微调在训练集上过拟合太容易了，但一到开放生成，它对工具名的概率分布还是太散。我建议你检查一下是不是system prompt和训练数据里的格式完全一致，包括标点、换行、特殊标记符，差一个空格都可能导致推理时行为漂移。还有个小技巧，可以在解码时把温度调到0.1以下，或者直接用贪心搜索，能显著减少它“灵机一动”编新工具名的情况。

至于“天气预报API”这种幻觉，我觉得不完全是指令模板的问题，更像是模型对“工具描述”和“实际可用工具列表”之间的映射关系没学好。你可以试试在每次生成前，把当前可用的工具名和描述动态拼进上下文里，并且在损失计算时对工具名部分加高权重，或者干脆用PEFT那种方式冻结底座只改注意力层，效果可能会更稳。我这边后来还加了一层规则兜底，就是解析出工具名后跟白名单比对，不匹配就直接拒绝，虽然土但确实能救急。你那个2000条数据，如果正负比例失调，建议先均衡到1比1试试看。

我之前用7B模型也踩过这个坑，训练loss低不代表模型真的学会了“何时不调用工具”。建议你在数据里多塞一些不该调用工具的场景，比如用户问闲聊问题，答案直接是普通回复，让它学会“拒绝”。另外工具名别用那种看起来很像真实API的，比如“天气预报API”这种，换成“get_weather”这种明显内部命名的，模型就没法瞎编了。还有可以试试在系统提示里强制加一句“只能使用给定的工具列表”，有时候比调参管用。

这种情况大概率是数据构造的问题，你2000条里是不是没有覆盖“工具不可用”的负样本？模型只会模仿调用动作，但没学会判断工具是否存在。可以试着把工具名改成随机字符串，如果模型还是乱调，那就不是名称规范问题，而是它根本没理解工具调用的边界条件。另外检查一下LoRA的训练目标，是不是只学了生成工具名，没学生成“不调用”的token路径。

我之前微调8B做代码生成也遇到过类似，后来发现是数据里工具调用的格式太单一了。你最好把每个工具都配上几种不同的写法，比如同一个搜索功能，既要有“search(query)”也要有“查询(query)”，让模型真正理解语义而不是死记字符串。而且真实任务里用户的话术跟训练集差异大，模型一慌就开始乱编，建议加一点对抗样本，比如

这个现象太典型了，LoRA微调在工具调用任务上特别容易把模型带偏，因为低秩更新本质上是在压缩任务模式，但模型对“工具名”和“真实环境”之间的边界感很弱。我之前用Qwen-7B做类似实验也翻过车，后来发现关键不在损失值，而在你的训练数据里有没有刻意加入“负样本”——比如明确告诉模型“这个工具不存在，请拒绝调用”的例子。如果你2000条数据全是正例，模型自然会觉得回答任何请求都该硬凑一个工具名出来，这跟“拒绝能力”缺失完全是两码事。另外你可以检查一下推理时的system prompt，很多微调模型会把训练时的指令模板记得太死，一旦真实任务里出现模板外的措辞，它就开始瞎编工具名，这时候建议把工具列表直接塞进user消息里，而不是放在system里，实测能大幅减少幻觉。还有个小技巧，给工具描述加上“仅当用户明确提及相关需求时才调用”这类限定语，比单纯改数据更立竿见影。调参方面，LoRA的rank值太低（比如r=8）也容易导致工具调用的语义表征不充分，可以试试点r=16配合更高的学习率但更少步数。最后如果还不行，就在后处理逻辑里加一层白名单校验，反正真实环境里工具就是那几个，模型输出名对不上就直接拒绝执行，这不算作弊，是工程兜底。