解决方案增长记

参数名被改写这个太典型了，模型是在“理解”你的schema而不是“复制”它，训练数据里如果order_id和orderId混着出现过，它就会自己发挥。建议把工具定义在system里固定死，同时检查下推理时的prompt和训练模板是不是完全一致，差一个空格都可能让模型行为漂移。另外88%验证准确率虚高很正常，验证集和真实请求的分布差太多，简单场景反而容易触发模型走“闲聊”路径，可以专门补一些不该调工

多步工具调用出错，很多时候不是LangChain编排的问题，而是模型在中间步骤没拿到足够明确的“状态”。可以试试把每一步的工具返回结果显式塞回prompt里，别让它自己脑补上下文。另外few-shot示例最好覆盖那种“参数依赖上一步结果”的场景，普通示例帮助不大。调低temperature治标不治本，关键还是拆步骤、加中间校验，每步输出都做个schema检查再往下走。

同感，我一般给GPT拆步骤，给Claude直接说目标加约束，效果差挺多。

200tokens等20多秒确实不太对劲，4090跑4bit的8B不该这么慢。先确认下有没有装FlashAttention，vLLM默认走xformers，换FA2之后prefill能快不少。另外batch size=1本身就吃不满GPU，延迟敏感场景可以试试开流式输出，体感会好很多。GPTQ换AWQ在4090上差别不大，倒是可以看看是不是max_model_len设太大导致KV cache预分配

先加个reranker试试，bge-reranker对假相关过滤挺管用的。

每10步才调一次超参，请求量确实不大，但MCP回调如果跑在主线程里，哪怕只是短暂拿一下GIL，也可能把CUDA kernel launch的节奏打乱。我建议先确认回调是不是同步阻塞在训练循环里，可以试试把MCP通信放到独立进程，通过共享内存或队列传超参，避免跟DataLoader的worker抢锁。另外用torch.profiler抓一段trace看看step耗时具体卡在哪，是CPU等待还是GPU

在prompt里直接给个示例代码，说“照这个风格写，别加注释”，比单纯说“不要注释”管用多了。

刚入门，这个对我帮助很大。

写得挺好，建议补充一些性能数据。

我之前也遇到过类似问题，后来换了方案。

刚入门，这个对我帮助很大。

我之前也遇到过类似问题，后来换了方案。

这个思路不错，收藏了。

有没有更详细的教程推荐？

写得挺好，建议补充一些性能数据。

几千页PDF切太细容易丢上下文，跨章节问题建议先换bge-m3试试，中文场景比3-small靠谱不少。

这种时好时坏的情况我也碰到过，大概率不是单一原因，数据和参数两边都得查。两万条对话听起来不少，但得看分布，如果商品信息类的样本占比太低，模型根本没学会稳定引用，那它就会靠猜，猜对了像模像样，猜错了就纯编。名字编错这个特别典型，通常是训练数据里人名出现频率低又缺乏明确约束，LoRA秩设太小的话模型压根没记住这些长尾细节。你可以先把r调大一点试试，比如从8提到32，同时看loss曲线是不是早早就平了，

我最近也踩过这个坑，感觉问题出在“角色设定”本身自带一层语义空间，模型会顺着这个角色的语气和知识范围去补全内容。你给“资深客服主管”这个身份，它就会自动脑补主管该有的“洞察力”，于是把一些没发生但“合理”的客诉细节也写进去。反而是你那个极简指令，把输出约束收窄了，模型没有太多自由发挥的余地。我试过在角色后面加一句“只基于对话原文，不添加任何外部信息”，效果会好一些，但不如直接删掉角色干净。可能角色

AWQ 4bit权重大概就是7G出头，你看到11G我猜是vLLM默认的gpu_memory_utilization=0.9把大部分显存预留给KV cache了，权重本身没那么大。并发一上来OOM主要就是KV cache不够分，2K上下文加4并发，按Qwen2-7B的GQA配置算下来其实挺吃显存的，40G看着多但vLLM会预分配。可以试试调低gpu_memory_utilization到0.8左右，

你这个情况我踩过差不多的坑，合同类文档特别容易这样。512加50重叠对条款这种结构化文本其实偏粗了，一个chunk里塞了好几条不相关的内容，embedding再强也救不回来，因为向量被平均掉了。但你说的“整个合同开头排前面”更像是另一个问题——开头那种总则、定义部分往往和很多query都有弱相关，模型容易把它当万能答案，这时候光调chunk没用，得靠rerank压一压。BM25那块关键词重合拉高不