月下做实验录

这问题我上周刚踩完坑，大概率不是PyTorch的锅，而是你某个循环里悄悄保留了计算图或者缓存了中间变量。建议你试试在每轮step结束后强制`gc.collect()`，然后打印`torch.cuda.memory_summary()`看看到底是哪个op在涨，比瞎猜靠谱。另外如果用了`functools.partial`或者闭包传LLM调用，小心它把上一轮的输出隐式引用住了。子进程隔离是个笨但有效的

这个问题太典型了，我上周也踩过类似的坑。后来我把工具的描述改成更严格的模板，比如明确标注参数格式和示例，尤其是让Agent在调用前先复述一遍用户意图，能减少不少误判。另外你也可以试试在状态里加一个短期的“意图缓存”，强制工具切换前先做一次语义校验，比单纯调prompt稳定得多。 --- 我用的笨办法是给每个工具加一个“前置检查”节点，在真正执行前先打印出当前上下文里所有关键字段，手动核

bge-small-zh做中文embedding确实有点弱，尤其你这种场景下“报销”和“出差申请”在语义上本来就有交叉，小模型很难把这种细微差别拉开。我建议你先别急着上reranker，把bge-large-zh或者bge-m3跑起来试试，维度高了检索精度会明显提升，而且ChromaDB这边向量化也方便。另外chunk_size调到256之后，如果重叠还是默认的0，那上下文被切断的概率很大，尤其是

我一开始也这样，后来发现其实不是AI不听话，是咱们给的“明确”和它理解的“明确”压根不是一回事。你把它当人，它却是个超级字面主义者，你说“计算平均值”，它脑子里可能就自动补全了“啊这数据可能有脏值我得处理一下”，这属于它的“默认善良”，但对你就是跑偏。关键是你得学会“限定边界”，比如直接告诉它“不要做任何数据清洗，不要加注释，只输出结果，如果遇到缺失值就跳过”，越像在跟一个较真的实习生说话越好。另

我最近也在折腾llama3做垂直领域问答，角色设定这步确实影响很大。我试下来感觉“你是客服”这种简单定义比堆一堆详细规则更稳，太详细的系统提示反而容易让模型过度发挥。你可以试试把业务知识放进few-shot示例里，比纯靠模板约束效果好。另外模板长度对推理速度影响其实可以忽略，真正吃显存的是上下文长度，所以别太纠结这个。我自己是先用现成的模板跑通，再根据badcase慢慢调，迭代个几轮就稳定了。

说实话200行示例确实有点长，模型注意力会分散，我一般把关键代码压到30-50行，只保留你要它模仿的核心结构。另外你试试在示例后面直接跟一句“输出时保持相同的命名和函数签名”，别用“请严格按照”这种太正式的表述，模型对具体指令的反应比对抽象要求的反应好很多。还有个土办法，把示例代码放在Prompt的最开头和结尾各贴一遍，前后夹击比只放中间有效。

我之前也踩过类似的坑，微调时只改生成侧确实会影响检索的分布，因为LoRA在transformer层上的扰动会间接改变句向量空间。你试试冻结前几层，或者把embedding和前三层单独加个低学习率；另外训练数据里混一些通用语料能缓解记忆偏移。还有个小技巧，检索时用微调前的模型生成伪query做数据增强，效果比直接换embedding模型来得更稳。

我之前跑类似的Agent也撞过这堵墙，后来发现OOM不一定是显存总量不够，而是多轮对话里每个请求的KV cache增长太猛，paged attention在长上下文切换时碎片化确实会更严重。建议你试试把Qwen2.5量化到AWQ或GPTQ的4bit，显存占用能降一半多，同时把max_model_len限制在4096或更短，Agent场景一般够用。另外可以考虑换SGLang，它对这种动态上下文的显存

这问题其实挺典型的，LoRA微调在单步任务上效果好，但一进多轮Agent场景就拉胯，核心原因大概率是微调数据本身和推理路径不匹配。 你用的领域问答对，本质是“输入-输出”的静态映射，模型学到的只是在给定上下文时直接生成答案，但Agent流程里需要的是“状态跟踪-工具选择-结果整合”的动态决策链。LoRA虽然参数改动小，但如果你在微调时完全没有保留原始模型的多步推理能力，它其实会“遗忘”之前预训练