南窗点灯
Lv.1在快速变化的技术世界里慢慢积累，关注技术学习与数字生活，记录学习路径整理、踩坑过程复盘和真实实践中的思考；坚持先理解原理，再讨论工具。慢慢写，长期做，把有用的内容沉淀下来。
发表的评论
我也这样，Copilot写多了手写确实容易卡，现在每周逼自己裸写几道题找找感觉。
我前段时间用单卡A100 40G微调7B的LoRA也踩过类似的坑，序列长度1024、batch size一上去就炸，后来发现显存大头其实不在LoRA权重上，而是activations和优化器状态。LoRA虽然冻结了主干，但前向的中间激活值还是得存，序列一长就是平方级增长，这块用gradient checkpointing能省不少，你可以先试试这个，成本最低。DeepSpeed ZeRO-3确实能分
loss降了但生成乱码这情况我也碰到过，大概率不是单纯的数据量问题。你loss能降到0.9说明模型确实在拟合你的数据，但推理崩掉往往是因为训练和推理时的prompt模板不一致，LoRA对format特别敏感，如果训练时没带system prompt或者特殊token，推理时又加了一堆，模型就懵了。8000条医疗QA其实不算少，但医疗领域术语密集，rank=8可能容量偏小，尤其你max_length
检查下返回内容有没有混入日志输出，stdout被污染会导致客户端解析失败。
这种整句重复我之前也踩过，当时第一反应也是怀疑数据，后来发现根子往往在解码和训练配置的叠加效应上。你温度降到0.6有缓解但没根治，说明模型本身已经学到了某种“复读”倾向，光靠采样参数压不住。我建议先别急着动LoRA的rank和alpha，把epoch降到1到2试试，7B模型几千条数据跑3个epoch很容易过拟合，过拟合的典型表现之一就是输出退化、反复吐同样的片段。另外学习率5e-5对LoRA来说偏
我搭MCP Server时也纠结过，后来直接上PyTorch了，模型导出成TorchScript或者ONNX再挂上去，推理这块没掉过链子。官方示例偏TensorFlow可能只是历史原因，不代表非得换。要是你手里模型都是PyTorch训的，硬转TF反而容易踩坑，部署环境也不一定省事。MCP本身只管协议层，底层框架选顺手的就行，别被示例带偏。
试试查询改写，把“运费谁出”补成“退货的运费谁承担”再检索，会好很多。
光调chunk_size没用，先做文档结构解析，按标题层级切，配置步骤和错误码别拆散。
你这个情况八成是分块把条款的上下文切碎了，报销流程这种问题往往跨了好几个段落甚至章节。建议先做结构解析，按标题层级切，再把同一章节里的小块合并成父块，检索时用小块召回、父块返回。关键词兜底确实有用，但更值得试的是混合检索加rerank，bge-large对长尾条款本身就偏弱，光靠它排序很难压过那些泛泛的差旅费内容。
Agent多轮交互延迟高，先换SGLang跑AWQ量化，比vLLM稳不少，7B够用别缩。
这个现象我之前也踩过，大概率不是你的history没截断，而是vLLM的KV cache在OfflineBatch反复调用时没被及时回收。vLLM内部会按序列id缓存block，如果你每轮都把整段对话拼成新prompt再送进去，它会把每次调用当成独立请求，旧的block占着显存不放，几十轮下来就炸了。你可以先试试在每轮推理完手动调用一下llm的sleep或者清空scheduler cache的接口
我之前也踩过这个坑，ChatGLM3-6B做长文本rerank确实容易抓不住重点。后来换成先把长文档切块做段落级打分再聚合，效果比整篇塞进去好很多。或者你可以试试bge-reranker-v2-m3这类专门做排序的模型，比拿生成模型硬做精排稳定不少。另外query那边也可以做点改写或关键词抽取，不然长文本里噪声太多，模型很容易被带偏。
3:1太高了，模型肯定偷懒背答案。试试降到1:1，把检索片段拼进输入让它学会看。
长文档建议先按章节切块提取再汇总，或者用JSON模板强约束输出字段，效果会稳很多。
说实话这类非结构化文档解析，AI编程助手翻车太正常了，我试过类似场景，它擅长写通用逻辑，但一遇到扫描件OCR和跨页表格这种“脏活”，光靠提示词根本喂不饱它。建议你把解析拆成两步走：先用专门的文档解析库（比如PyMuPDF、pdfplumber）把结构和文本抽出来，再让AI只负责写切分策略，这样能大幅减少它自由发挥的空间。另外提示词里别给示例代码，直接给边界情况的输入输出对，让它照着修，比描述规则管
我们项目直接拆两个index，短期单独存，过期就归档进长期库，检索时先用短期再兜底长期，效果比混着强多了。
3060 12G跑ResNet50开32确实容易爆，混合精度加梯度累积直接解决，别怀疑代码。
显存没跑满但崩了，大概率是显存碎片化或者KV cache爆了，试试把max-model-len调小点。 用4bit量化加vLLM的continuous batching，7B跑agent完全够，问题多半在prompt模板把上下文撑爆了。
说实话rank的影响在指令数据比较充足的时候确实会被稀释掉，5万条代码生成任务对8B来说不算难，模型本身能力就够，微调更多是风格对齐。我之前试过rank=16和rank=64，最后BLEU就差0.3，倒是alpha调大容易过拟合。rsLoRA那种缩放方式在低rank下更稳，但你要是试到64了其实差别不大。建议直接跑个全参数微调对比一下，如果效果也就那样，那说明瓶颈不在PEFT配置上，可能得看看数据
我之前也踩过类似的坑，尤其是口语化追问一来，模型就自己“跑偏”了。后来我试了下把“你是客服”这类身份约束从System Message挪到每个User Message的末尾，比如加一句“基于上述订单信息直接回答”，效果确实稳了不少，你可以试试看。另外Negative Examples别堆太多，挑两个最典型的就够，多了反而干扰模型对主任务的判断。还有个问题想请教下，你Few-shot里的示例是单轮还