兔子偶尔重构日记

5k条垂直数据全量跑3个epoch，掉通用能力太正常了，模型基本被你的领域数据带偏了。rank=8其实不算小，问题更可能出在数据配比上，建议掺20%-30%的通用指令数据进去，能明显缓解。另外1e-4对LoRA来说有点激进，试试降到2e-5或者1e-5，epoch控制在1-2之间。我自己微调Qwen2.5的时候也遇到过类似情况，加了通用数据后写代码能力就稳多了。

这个问题我也踩过坑，感觉核心原因可能不是模型注意力丢失，而是你给的示例本身在结构上太像“参考资料”而不是“输出模板”。模型看到多段代码时，往往会把它当成背景知识去理解，而不是当成必须逐条对齐的格式约束。你可以试试把示例改成“输入→输出”的配对形式，比如给一小段原始数据，再给对应的目标脚本片段，这样它更容易把示例当成任务映射而不是泛泛的风格参考。另外三段示例如果彼此差异不大，模型可能自动合并成一段，

延期几个月大概率不是单纯工程节奏问题，MoE训练到那个规模，loss spike一旦出现基本就是连锁反应，路由坍塌和专家负载失衡经常一起来。你说的低质量长尾样本导致梯度爆炸我信，但更怀疑是优化器在超大批量下对异常梯度的鲁棒性不够，换数据配比未必能根治。谷歌敢临门叫停，说明评估侧发现了系统性问题，不是小修小补能糊弄过去的。

我也遇到过，后来发现根因是上下文太长时模型会“重写”自己的指令，尤其工具调用那块。我现在的做法是把系统prompt拆成不可变的核心规则和可变的会话状态，核心规则每次请求都重新拼接，不依赖模型记住。另外用子代理隔离确实有用，主agent只负责路由，不让它碰规则文件。你可以试试在工具层加个校验，prompt被改了直接拒绝执行，比单纯靠约束靠谱。

FP16掉点太正常了，尤其暗部和小目标，量化误差直接就把低响应区域淹没了。我之前也是DeepLab系，最后是ONNX转TRT时把敏感层（比如最后几个卷积和上采样）强制保留FP32，mIoU基本能拉回来。你可以先用polygraphy逐层比对一下ONNX和TRT的输出差异，定位到底哪几层炸了。另外trtexec默认的校准和精度策略不一定适合分割任务，别偷懒。

7B模型在MCP上跑的话，其实得先看你手头卡的数量和单卡显存。如果8卡80G这种配置，DDP其实也能塞得下，毕竟7B参数加优化器状态和梯度，全量复制一份大概也就百来G，摊到每张卡上压力不算大。但如果你卡比较少，比如4张甚至2张，或者想开更大的batch size，那FSDP的优势就出来了，它把参数、梯度、优化器状态都切片，显存占用能降不少。不过FSDP的通信开销确实比DDP高，尤其是all-gat

7B做多步推理确实容易丢链，试试把工具调用拆成单步，每步只让它选一个API。

光靠Prompt不够，得在检索后加个重排或相似度阈值过滤，把低分的chunk直接扔掉再喂给模型。

V100跑4bit的7B确实有点勉强，主要是KV cache吃显存，上下文一长就炸。我之前用TGI配AWQ量化，开paged attention能稳住，但16G卡也就撑到3k上下文左右。真要稳还得上24G的3090/4090，或者双卡切分。vLLM对GPTQ支持一般，AWQ更顺，建议换量化格式再试。

这问题挺常见的，7B模型指令跟随确实没那么稳，光靠prompt硬压效果有限。我之前用SGLang的regex约束解码搞过类似需求，直接强制输出符合JSON schema，基本告别```json和注释了。不过得注意约束太死有时候会让模型在复杂嵌套结构上卡住，建议先拿简单schema试水。另外你温度0.1其实可以再降，但根本解法还是上约束解码。

我们生产上用的Qdrant，几百万向量单机跑得挺稳，主要看中它Rust写的性能好，过滤条件也灵活。Chroma做demo确实爽，但真上生产建议别碰，之前同事踩过坑，数据量一大查询就拉胯。想平滑扩展的话Qdrant有分布式版，不过说实话百万级单机加好点的SSD基本够用了，别过度设计。Milvus功能确实全但运维成本摆在那，小团队养不起。

5000条全是内部评审记录，通用能力不掉才怪。我一般会掺30%左右的通用代码指令数据，比如CodeAlpaca那类，比例再根据验证集调。工具误触发的问题更像是prompt模板没把工具边界写清楚，可以试试在system prompt里明确“只有涉及代码质量分析才调用静态检查”，再补一些负样本。LoRA的话rank别太高，对通用能力冲击会小一些。

固定500字符切块对PDF和Word这种结构差异大的文档确实太粗暴了，表格和页眉页脚混进去基本是必然的。我之前也踩过这坑，后来改成按标题层级切、段落优先，表格单独抽出来处理，召回质量提升挺明显。BM25加向量混合检索值得试，尤其报销流程这种关键词明确的query，BM25能兜住不少向量漏掉的东西。不过更关键的还是先把分块洗干净，不然top_k调多大都是在垃圾里捞。

确实是这样，微调后模型会强烈依赖训练时的模板，你换成别的格式相当于分布外了，掉点很正常。我一般做法是训练时就故意混几种模板，比如“用户：”“问：”“Q:”都掺一些，比例别太偏就行。另外prompt结尾的“客服：”这种引导词也挺关键，最好别省。你要是只想用一种格式，那就测试时严格对齐，别偷懒。

12G显存跑8B的fp16确实不够，光权重就16G左右了，爆显存很正常。4-bit量化能跑但慢，大概率是你没开GPU offload或者offload层数设少了，纯CPU推理那肯定十几秒起步。中文效果方面4-bit一般掉点有限，Q4_K_M算是比较均衡的选择，真在意质量可以试Q5_K_M，显存吃紧就Q4_K_S。Ollama和LM Studio我都用过，Ollama命令行省心、模型拉取方便，LM

我踩过一样的坑，光靠prompt强调顺序确实不太稳，模型一偷懒就跳步。后来在每步输出里强制加一个结构化字段，比如让Agent先吐 `{“extracted”: …}`，再往下走，跳步就露馅了。合同审核这种场景建议还是上LangGraph或自己写状态机，prompt只负责单步质量，流程交给外部控制靠谱得多。

hit rate 0.85其实不算低了，问题更可能出在生成阶段没把噪声过滤掉。top10里只要混进两三段语义相近但实际无关的内容，7b模型很容易被带偏，引用错文档基本就是这个原因。建议先试试top5加cross-encoder重排，bge-reranker-v2-m3性价比挺高的，比直接换大模型划算。另外prompt里明确要求"只依据给定片段回答，找不到就说不知道"会稳很多，qwen2.5-7b对

分库这个思路本身没问题，问题出在你让LLM凭空选库。我试过比较稳的做法是给每个库配一段元数据描述，同时把路由做成两阶段：先用query改写提取出实体和时间范围，再用轻量分类模型或关键词规则粗筛，最后才让LLM在候选库里做二选一。打平到一个库靠向量硬匹配也不是不行，但财报和新闻语义空间差太远，召回容易被稀释，建议加个source字段再配合metadata过滤。

我也踩过这个坑，后来发现alpha其实不用死磕2:1的比例。你可以把alpha理解成一个缩放系数，r=8的时候alpha从8试到32都跑一遍，看验证集loss什么时候开始翘。7B模型做领域问答，r=8到16一般够用了，数据集小的话r再小点更稳。OOM不一定是r的锅，gradient checkpointing没开或者batch size太大都可能导致，先把显存优化打开再谈调参。

我用的GPTQ 4bit，13B单卡24G稳稳的，精度掉得没想象中多，可以试试。