解决方案增长记

几千页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那块关键词重合拉高不

这个问题我也踩过坑，而且我觉得跟量化关系不大，更多是注意力在长上下文里被稀释了。你说的“风格一致但偶尔失忆”特别典型，因为模型看到的东西越多，每个token能分到的注意力权重就越平均，反而对具体变量名、已定义函数的强约束就弱了。我试过在prompt里加一句“只允许使用以下已定义的函数和变量”，再附一个精简的符号表，效果比硬塞整个文件好不少。后来我干脆改成两段式：先让模型读一遍项目结构生成一个接口摘

max_length 2048 确实是个大坑，我一开始也栽在这上面，7B模型在3090上跑LoRA，光KV cache就能吃掉不少显存，尤其是序列长的时候。你可以先试试把max_length降到512或者768，看看能不能稳住，很多时候OOM不是训练本身的问题，而是数据预处理阶段就把显存撑爆了。另外transformers 4.31那个版本对LLaMA的attention实现有些地方确实不太省显存

我一般把prompt当接口文档写，明确输入输出格式比堆角色设定管用。

我之前也踩过一模一样的坑，500太碎、1500太糊，最后发现根本不存在一个万能数字。我的经验是先看文档结构，技术PDF如果有明确的章节和小标题，就按语义边界切，别硬套固定字数，LangChain里用RecursiveCharacterTextSplitter配合自定义分隔符会好很多。再就是chunk大小其实跟embedding模型关系很大，比如bge这类中文模型对512token左右比较敏感，你塞

Llama3 原版中文底子确实一般，尤其是法律这种专业领域，它预训练里中文占比本来就低，你拿它做中文 SFT 相当于让一个老外背法条，能背但表达会很怪。重复句子和蹦英文基本就是模型在中文生成上没对齐好，不是单纯数据量的问题。我自己试过用 llama3 做中文任务，同样的数据换 qwen2 或者 yi-1.5，效果肉眼可见地好一截，建议你先别死磕 llama3，换个中文底座可能一周就出结果了。当然数

我也遇到过同样的情况，感觉AI对“改需求”特别不敏感，尤其是涉及变量名和上下文的时候，它经常自己脑补一套新逻辑。后来我学乖了，每次只让它改一个点，改完马上跑测试，别攒着一起改。另外可以把原始代码和需求用注释标清楚，让它基于现有代码改，别重新生成。迭代场景下确实不如一次性脚本顺，但配合小步验证还是能用的。

500条确实少了点，多轮工具调用很吃数据，建议先堆到两三千条再调参。

我最近也踩过类似的坑，Prompt里塞太多约束，模型反而像被绑住手脚，注意力全花在满足格式和防幻觉上了，真正该去上下文里找答案的劲儿就弱了。后来我把指令拆成两层，系统层只留最核心的“基于给定内容回答”，格式要求放到最后单独说，中间那段留白，召回反而稳了不少。还有个感受是，RAG里检索质量才是大头，Prompt再细也救不回一堆不相关的片段，我现在会先盯chunk切分和rerank的分数，确认召回没问

我一般用500左右起步，再按文档结构微调，比如按标题层级切，代码块单独处理。overlap设个10%-20%就够，太大反而冗余拖慢召回。其实可以上LlamaIndex的语义切分试试，比纯按token靠谱。另外召回不准不一定是chunk的锅，embedding模型和查询改写也得一起看。

我也遇到过类似情况，Qwen2.5-Coder确实有点“mock依赖症”，感觉它训练时见到的测试代码里mock比例太高了。后来我把提示词拆开写，明确说“除非有外部HTTP调用，否则一律用真实依赖”，效果好了不少。温度0.2其实偏低了，试试调到0.4到0.6，生成风格会灵活一点。DeepSeek-Coder在这块更倾向写轻量级集成测试，但生成速度慢一些，看你更在意哪头。

几百条数据跑3个epoch，这个量级确实很容易过拟合，尤其客服问答这种句式高度重复的场景，模型会直接记住模板而不是学会泛化。1e-4的学习率对LoRA来说偏高了，我一般从2e-4或者1e-4开始试，但会配合warmup和cosine衰减，不然前期梯度太猛很容易把基座能力冲垮。r=8其实不算大，但alpha=16相当于scale=2，如果数据少，这个放大系数会让LoRA权重过度主导输出，建议降到al

我最近也在折腾这块，实际感受是单纯靠向量相似度做记忆检索确实容易翻车。你遇到的那个“刚才说的那个方案”就是典型问题，embedding抓的是语义相近，但抓不住对话里的指代关系和时序逻辑，所以经常召回一堆语义相关但上下文对不上的内容。我现在是把记忆分成两层，短期用滑动窗口留着最近几轮原文，长期才丢进向量库，而且写入前会做一轮摘要压缩，把“那个方案”这种指代先解析成具体实体再存。检索的时候也不只看向量

我之前也动过这个念头，后来放弃了，主要是觉得MCP的设计初衷就不是干这个的。它的tool调用更像是一个请求-响应模型，适合短平快的操作，训练这种跑一小时起步的任务挂上去，超时基本是必然的，而且据我所知目前没有标准的心跳保活机制，客户端那边大概率等不到结果就断了。参数大小这块我也踩过坑，传几百条样本的JSON就明显感觉吃力了，虽然协议本身没写死上限，但实际受限于传输层和客户端实现，大批量数据走too

你那个 `torch.cuda.set_device(local_rank)` 放的位置很关键，得在 `init_process_group` 之前调用，不然 NCCL 初始化时用的还是默认设备。另外确认下 `LOCAL_RANK` 是不是被 torchrun 正确传进来了，有时候环境变量没透传就会全挤在卡0上。我之前也踩过这个坑，后来在 init 前打印一下 local_rank 和 curre

7B跑多步工具调用确实容易崩，我上个月也踩过类似的坑。后来发现不光是模型大小的问题，Ollama默认的推理后端对并发请求处理得比较糙，Agent每步都要重新加载上下文，延迟累加起来很容易超时。你可以先试试把工具调用的中间结果做缓存，别每次都让模型从头推理。另外Qwen2.5-7B本身没专门做function calling微调，格式稍微偏一点就卡住，换成14B的instruct版本会稳不少，但显存