深夜后端随想

样本数量不是关键，质量才是。20个例子塞进去，模型注意力被稀释了，反而干扰判断。建议只留5个最典型的，而且每个例子的“退货”和“退款”边界要特别清晰，最好带上用户原话的完整语气。 温度调0确实更稳，但如果你发现分类偶尔卡在两个标签之间，可以试试0.1而不是0.2，这个区间对意图识别来说够用了。system还是user里放例子，我测下来差别不大，但system里放格式说明更稳定。 还有个坑你可能

试试把检索结果按相关度重排，再在每段前面加个序号让模型逐条引用，长文档里效果提升挺明显的。

几万条数据真不用纠结，Chroma完全够用，等量级上来了再换不迟。

这问题太典型了，我之前用别的模型搞审查也这样。光靠system prompt确实没用，模型缺乏对项目历史的感知，我后来是把关键业务模块的README和几个核心pr的描述塞进知识库，误报率才降下来。但别全塞，挑那些有特殊逻辑的，不然上下文太长反而影响判断。另外可以试试在审查规则里加白名单，把特定文件或模式排除掉，比如兼容旧接口的类直接跳过复杂度检查。 --- 我试下来最管用的是给Agent喂一个

说实话4-bit量化对7B这种小模型影响挺大的，尤其长文本任务里信息密度一高，量化误差会被放大。建议你先用FP16跑跑看，如果效果明显变好那就是量化的问题。另外Qwen2.5对指令里的“动作词”特别敏感，比如“总结”换成“提取要点并分条列出来”，输出结构会稳很多，你可以试试把任务拆成两步写。

多智能体确实比单Agent稳，但通信开销这块儿我踩过坑，之前试过类似的框架，Agent间传JSON格式不统一直接给我整崩溃了。Navos 2.0如果真能靠状态机把中间结果规范化，那确实挺实用，不过DAG调度在动态任务里容易卡死，官方文档没细说有点慌。钛动签OpenAI算是把模型下限托住了，接下来就看他们怎么把工作流编排做出差异化，别到时候又是一堆API壳子。 --- 说实话，多Agent最怕的

FP16掉2个点对分割任务偏多，建议先查下BN层和resize的算子是不是被TensorRT优化出问题了。

试试父子chunk吧，父块给上下文，子块做检索，比单纯rerank治本多了。

说实话2000条对话做客服场景确实少了点，客服问答这种任务对领域覆盖度要求很高，LoRA本身参数量小，如果数据分布太窄，微调后容易过拟合到训练集上，反而把base模型原有的泛化能力覆盖掉了。建议先拿原模型跑一下zero-shot看看baseline，另外可以考虑把rank调到16-32，学习率降到1e-4以下，还有Q和V同时微调可能偏保守，试试加个O-projection或者只调Q。数据量如果能扩