微调后的模型做Agent工具调用总跑偏，是数据问题还是训练参数没调对？

八成是数据里缺多轮负样本，模型压根没见过“传错参数”该长啥样，光调rank救不回来。

这问题我太有同感了，之前做类似项目也卡在这。我后来发现主要是缺负样本，尤其是那种“上一步工具结果是None”或者“工具名拼错”的对抗样本，模型没学过怎么拒绝就容易瞎编。LoRA参数我倒觉得影响没那么大，rank32、alpha64基本够用，但多轮上下文长度和注意力衰减才是关键，你可以试试把历史轮次的loss权重调低点，让模型更专注当前指令。

另外我还有个猜测，是不是你的数据里工具调用的格式太统一了，模型没学会区分“参数来自用户”还是“参数来自上一步结果”？建议在数据里混入一些需要从对话历史里提取参数，而不是直接复用上一步返回值的例子，哪怕数量不多，效果会明显不一样。

这问题我太熟了，之前搞类似的项目也栽在过这儿。你观察到的把上一个tool结果当参数传，其实更像是模型学会了“引用上文”的模式，但没学会“区分当前该用哪个函数”，所以负样本确实得加，专门构造一些“上轮结果跟本轮无关”的干扰项。不过LoRA的rank也别忽视，8或者16在这种多轮任务上容易欠拟合，我后来调到32才明显稳下来。另外你可以试试在训练时把多轮对话拆成更细的turn-level样本，而不是整段丢进去，模型对“当前输入”的敏感度会高很多。

说实话我也踩过类似的坑，折腾了大半个月才缓过来。你这情况我倾向于数据问题占比更大，特别是多轮里“工具结果回传”这种状态流转的样本，如果负样本或者边界case不够，模型很容易学会“偷懒”——直接把上一轮的输出塞进下一轮参数里。LoRA的rank和alpha我试过8/16和16/32，说实话对这类错误影响没那么立竿见影，反而数据里如果混入了一些“工具调用失败后该怎么纠偏”的样本，效果会明显改善。另外你可以检查一下是不是把多轮对话的history截断得太短，Llama-3-8B的窗口虽然够用，但指令跟随的稳定性在长上下文里会打折，尤其当system prompt里工具描述太多时，注意力会被稀释。我自己最后是往数据里加了大概10%的“错误恢复”样本，比如模型先调了A工具，但A返回异常，然后人工标注里让它改调B工具，这种转折样例对抑制幻觉很有帮助。训练参数我倒是没怎么大动，就是learning rate从2e-4降到1e-4，然后多训了一个epoch，感觉更稳一点。你试试看能不能从数据里找出几个典型的“记忆混乱”case，单独拉出来做数据增强，比调参可能更快见效。

说实话我觉得这大概率不是LoRA参数的问题，rank和alpha的影响远没你想的那么大，更可能是数据里缺少多轮纠错的负样本。我之前也踩过类似的坑，后来在数据里专门加了一些“上一步结果无效需要重新调用”或者“工具不存在”的对话轨迹，效果立刻好了很多。另外你可以试试在推理时把tool结果拼进历史消息时加个显式的分隔标记，让模型更清楚哪些是observation哪些是user输入，8B模型对格式边界特别敏感。如果还不行，那确实得怀疑基座模型的多轮跟踪上限了，Llama-3-8B在复杂状态追踪上本来就不算强项。

我最近也在搞类似的东西，用的Qwen系列，情况跟你几乎一模一样。单轮准确率能到90%以上，一进多轮就原形毕露，尤其爱把上一轮tool的输出拼进下一轮的query里。我后来把训练数据里专门加了那种“故意给错参数”的负样本，比如让模型看到错误的tool call格式然后强制纠正，效果确实有提升，但没根治。我觉得LoRA的rank和alpha反而没那么关键，我试过8到64的rank，差异不大，真正影响大的是基座模型本身对多轮上下文的压缩能力，Llama-3-8B这块确实偏弱，尤其tool call需要模型同时跟踪“当前意图”和“历史状态”两个东西，8B的注意力头可能根本忙不过来。你可以试试把每轮对话的system提示里显式加上“上一轮工具返回结果已存入变量，本次调用禁止引用该变量”，或者干脆把多轮历史截断成最近两轮，别让它看太长的上下文，有时候信息越多它越容易乱。另外检查下你的训练数据里有没有“连续两次调用同一个工具但参数不同”的样本，这种模式模型特别容易学岔。

八成是数据里缺多轮负样本，模型压根没见过错误恢复的路径，光调rank救不回来。

说实话你这个情况我太熟了，之前用7B模型做多轮tool calling的时候也卡了快一个月。我后来排查下来，发现LoRA参数反而是次要的，真正坑人的是负样本的缺失——模型根本没学过“什么时候不该调用工具”或者“该把当前轮用户意图跟历史工具结果区分开”这种边界情况，所以它只能靠瞎猜。你试试在数据里混入一些“工具结果无用，直接回答用户”的样本，或者故意构造几轮“上一个工具结果跟当前问题无关”的对话，让模型学会忽略历史噪音。另外rank和alpha我建议先别动，8B模型用16/32这种常规配置就够，问题多半不在容量上。还有个很隐蔽的点：你确认一下多轮数据里每个turn的assistant消息是否都带了完整的tool_call_id引用？有些开源数据格式里这个字段容易漏，模型一旦看不到明确的对应关系，就会自己脑补参数来源。最后如果还不行，可以试试把system prompt里工具描述改成更强调“严格基于当前user query选择工具”的措辞，虽然你说prompt没问题，但有时候模型就是会被长上下文里的历史干扰带跑偏。

说实话我觉得这三方面都有点关系，但最核心的坑大概率在数据上。几千条单轮对话里，如果多轮轨迹的负样本覆盖不够，模型根本没见过“上一步输出不该作为参数”这种情况，它就只能靠猜。我上次做类似任务时，专门构造了二十来种“工具返回错误格式”和“重复调用同一工具”的样本，效果直接好了不少。

另外你查下LoRA的target_modules是不是只挂了q和v，有时候把k和o也加上会让多轮状态保持得更稳。rank和alpha其实没那么敏感，8和16就够用了，除非你数据量特别大。

还有个小技巧，推理时把system prompt里显式加上“每个工具调用的参数只来自用户当前消息或系统状态”，这样能稍微约束一下生成方向。基座模型8B的多轮能力确实有上限，但你这问题听着更像数据分布没调平。

数据里多塞点“上轮结果不可用/工具不存在”的负样本试试，比调rank见效快。

这问题我踩过一模一样的坑，最后查出来是负样本太少。多轮调用出错时模型根本没见过“该拒绝调用”或“工具返回异常”的例子，你试着在数据里混入20%的失败恢复对话，让它学会从错误状态跳出来，比调rank管用多了。另外8B底座做长上下文工具调用确实吃力，建议先砍掉两轮以上的复杂链路，用few-shot硬扛。

多轮跑偏我遇到过类似的，大概率不是rank和alpha的锅，你这情况更像数据里缺了“纠错”样本。LoRA微调时如果只给正向例子，模型会把工具调用学成机械的“接龙”，上一个输出自然就成了下一个输入。建议你专门构造一些“错误工具名+正确重试”的对话，或者把多轮里工具结果的摘要和参数分开标注，让模型学会区分“记忆”和“当前指令”。另外llama-3-8B本身多轮指令跟随就一般，实在不行可以试试把system prompt里加上“仅根据最近一次用户输入决定工具”的硬约束，我这边加了这个之后明显好一些。

这种多轮“记忆混乱”大概率不是LoRA参数的问题，rank和alpha影响的是拟合能力，不是推理逻辑。我怀疑你数据里缺了那种“工具返回结果需要被忽略或暂存”的负样本，模型没学会区分“该用上轮结果”和“该重新查询”。另外可以试试在训练时把多轮对话截断成不同长度的片段，强制它学局部上下文，不然模型容易偷懒直接抓最近的历史。如果还不行，换个7B或13B的指令微调版本底座可能会好点，8B这个档位多轮一致性确实看运气。

八成是负样本不够，多轮里得塞点“工具返回异常”和“该拒绝调用”的例子进去。

我之前也踩过类似的坑，最后发现不是LoRA参数的问题，而是数据里“多轮工具状态转换”的样本太少了。你单轮准不代表模型学会了“维护工具调用历史”这个能力，它可能只是记住了“看到某个query就输出某个工具”的表层映射。建议你专门构造一些“上一个工具返回结果需要被引用”的样本，比如第一轮查天气，第二轮问“那明天呢”，这种显式的多轮依赖数据，比单纯堆几千条独立对话有用得多。另外rank和alpha我试过8/16和16/32，差别真不大，除非你数据量特别小，否则别优先怀疑超参。还有个细节，你推理时虽然temperature降了，但top_p呢？有时候top_p不改，模型在长序列生成时还是会飘。最后，Llama-3-8B本身的多轮跟踪能力确实一般，如果数据补完了还不行，换Qwen2.5-7B或者Mistral-Nemo试试，我换基座后这种幻觉直接少了一半。

这问题我也踩过坑，多轮跑偏八成不是rank的问题，LoRA那点参数对记忆影响真不大。我建议你先去翻翻训练数据里连续两轮以上的样本占比，如果太少，模型压根学不会“上一步结果该放哪”。另外可以试着在数据里故意加一些“工具不存在”的负样本，让它学会拒绝而不是硬编。实在不行就考虑换Qwen或者带原生agent能力的底座，8B的Llama在多轮指令跟随上确实有点吃力。

这问题我太懂了，之前做类似项目也卡在过这。你温度都0.1了还乱编工具名，大概率不是采样的问题，更像是LoRA没学到“什么时候该停”的边界。建议你翻翻训练数据里有没有那种“工具返回结果后应该直接回答”的正例，不然模型会默认所有上下文都得继续调工具。另外rank可以试试16或32，alpha跟着调大点，我这边之前就是数据里缺了这种转折样本，补上后多轮稳定性明显好多了。基座模型本身对8B来说确实有点吃力，但先别换模型，把负样本加够再观察下。

说实话我之前也踩过类似的坑，最后发现不是rank和alpha的问题，是数据里缺了那种“工具返回结果后需要重新规划”的中间步骤样本。你可以试着在训练数据里多塞一些故意传错参数、然后模型纠正回来的负样本，让模型学会区分上一轮输出和当前轮该用的参数。

另外Llama-3-8B本身对复杂多轮状态跟踪确实有点吃力，我后来加了一层显式的对话历史摘要作为额外输入，效果比单纯调LoRA参数明显很多。你那个“编工具名”的情况，大概率是模型在瞎猜，不是参数问题，建议先看看是不是训练时工具列表的表示方式太长了，导致注意力被稀释。

说实话我之前用7B模型也踩过这个坑，后来发现光加负样本不够，得把多轮对话里的工具调用历史也拼进训练数据，让模型学会区分“上轮输出”和“当前输入”。LoRA参数倒是其次，rank设16、alpha翻倍试过，效果不如直接在数据里塞几十条“故意传错参数”的样本。另外你试试推理时把最近的tool result明确标记成assistant的临时记忆，而不是塞进user消息里，这招对我挺管用。

说实话你这情况我上周刚踩完坑，最后查出来是负样本太少，模型根本没学会“什么时候不该传参”。LoRA的rank和alpha影响真没你想的那么大，8和16基本够用，关键还是数据里得多塞些工具调用失败的例子。另外可以试试在system prompt里明确写一句“如果上一个输出不是有效工具结果，必须重新调用工具”，有时候比调参管用。