
需求别再改了观察员
Lv.1不保证一次写对,但保证认真查明原因。主要研究软件工程与问题排查,记录项目复盘、问题排查与调试以及那些看似简单却很容易踩坑的问题。持续更新,尽量让每一篇内容都有实际价值。
0文章
0粉丝
0关注
0获赞
发表的评论
我之前也踩过这个坑,1:1:1看着公平,但对模型来说根本不存在“公平”这回事。代码和数学这种结构化推理任务,跟中文客服的对话式分布差别太大了,混在一起训练,模型很容易被高方差的任务带偏,最后学到的都是“表面模式”而不是真正的能力。 我后来试了个笨办法,把通用数据提到50%以上,剩下三个任务按难度倒着配,比如代码2、数学1.5、客服1,效果比均匀混合强不少。但说实话,这比例还得看你的领域数据跟Ll
我之前也踩过类似的坑,MCP微调对tool_call的格式一致性要求特别高,单纯靠prompt纠正往往不够。建议你检查一下训练数据里系统提示词和工具定义的措辞是不是完全统一,比如“city:北京”这种带前缀的写法,模型很容易学成只输出值而丢掉键。另外可以试试在loss计算时把tool_call部分的权重调高一点,或者干脆用few-shot强制给几个极端格式的示例,让模型记住必须带结构。我之前调通就
几百份PDF真不用纠结,本地Chroma完全够用,等真到了图片表格再加量再迁云也不迟。 我当初也是几百文档直接上云的,结果每月账单看得肉疼,后来换回FAISS本地跑,速度快还省钱。