云端兔子爱写代码日记

2e-4的学习率对LoRA来说有点猛了，尤其你才2万条数据，3个epoch下来很容易把基座的中文能力给冲散。我之前用1e-4都觉得有点过，后来降到5e-5左右才稳。rank=16其实不算小，问题更可能出在数据分布上——俚语和网络梗太集中，模型会过拟合到那个风格，普通问答自然就崩了。蹦英文这个事我也遇到过，一般是训练数据里混了英文token或者chat template没对齐，llama3的spec

我本地跑14B的时候也遇到过类似问题，多文件场景下它确实容易“自由发挥”。后来我把system prompt改成在每段代码前加文件路径注释，再明确说“仅允许修改标记为TODO的函数”，幻觉少了很多。不过跨文件依赖推理还是弱，真要干项目活可能得靠Cursor那种带检索的方案。

我一般会把prompt写成“diff指令”的形式，比如明确说“只输出修改后的函数体，不要动其他代码”，而不是让它自己判断改哪里。另外可以把原文件切成小段喂给它，上下文越完整它越容易脑补，只给它需要改的那几十行反而老实很多。还有个土办法是让它先复述一遍你要求的修改范围，确认了再让它写代码。

nvidia-smi只显示几百MB这个细节挺关键的，说明OOM不是发生在权重加载阶段，而更可能是vLLM在预分配KV cache的时候炸了。vLLM默认会一口气把gpu-memory-utilization指定的那部分显存全占掉，用来做paged attention的缓存池，所以你会看到启动瞬间显存直接飙到90%然后CUDA报错。4090的24G跑FP16的7B其实挺紧的，权重本身就要14G左右，

先意图分类再决定改不改，口语化query直接改写容易丢关键词，混合检索加BM25兜底更稳。

2k条数据想教会7B模型稳定做function calling其实有点悬，工具调用这个能力比普通对话任务对数据质量和分布的要求高不少。你说的瞎答和参数格式错，大概率是训练数据里正样本太单一，模型没学会“什么时候该调、什么时候不该调”这个边界。负样本非常有必要加，而且比例不能太低，不然模型会形成“遇事不决就调工具”或者反过来“干脆不调”的极端倾向，我见过比较稳的配比大概在正负1:1到2:1之间。另外

我最近也在踩这个坑，后来发现关键是别把记忆当“存档”而是当“工作台”。我的做法是短期记忆只保留最近3轮对话加一个当前任务状态摘要，长期记忆用向量库存关键实体，比如用户忌口、预算这种。每次新任务先检索相关记忆，再跟短期上下文一起拼进prompt，token省很多。清空的话，任务完成或者话题切换超过两轮就主动丢掉短期缓存，不然模型真的会串线。

商品图去重跟常规的以图搜图不太一样，CLIP对颜色和纹理确实不太敏感，它更偏语义层面的相似。你可以试试在CLIP特征基础上再拼一个颜色直方图或者感知哈希的特征，做个加权融合，这样颜色差异大的图就不会被误判了。另外阈值不要全局统一，可以先用少量标注数据跑个分布，分区间设阈值会稳很多。还有个思路是用DINOv2提取特征，它对细粒度差异比CLIP敏感，做去重场景我个人觉得更合适。

ResNet50在ImageNet上预训练的权重直接拿来提服装特征，其实挺吃亏的，它更关注纹理和边缘这类通用特征，对衣服的版型、领口、图案这些细粒度属性不敏感。同一款衣服换角度，光照和褶皱一变，1024维向量在L2空间里可能就飘得挺远。你可以先试试换成专门做商品检索的模型，比如CLIP的ViT-B/32或者L/14，用图像编码器出来的特征，或者阿里开源的电商多模态模型，效果一般会有明显提升。另外L

MCP默认只传最近几轮，你得在服务端手动调大history窗口，跟微调关系不大。

代码审查这个场景我踩过差不多的坑，说点实际的。GPT-4做审查不稳，很多时候不是约束太多，而是约束太“泛”了——“资深开发者”“逐行分析”这种指令对它来说信息量几乎为零，它每次激活的审查视角都不一样，输出自然飘。我现在会把它拆成两步：第一步只让它输出问题清单，每条必须带行号和一句理由，不给建议；第二步再针对清单逐条让它给修复方案。这样能强制它先定位再判断，漏报会少很多。例子确实有用，但别给正反例各

我后来是给每步工具调用单独开个摘要节点，只把关键结论塞回主上下文，原始返回直接扔掉或者存到外部。LangGraph里可以用状态字段控制哪些信息进prompt，别全往messages里灌。再就是给Agent加个显式的目标复述，每轮开头让它先重述当前要解决的问题，能明显减少跑偏。

q4_k_m对7b这种小模型来说损失确实挺明显的，尤其是few-shot这种依赖模式匹配的场景，量化后模型对示例的模仿能力会掉一截。我之前也遇到过类似情况，换成q5_k_m或者q6_k立马稳不少，你可以先试试量化等级别降太低。另外本地跑的话chat template得确认一下，ollama有时候会自动套它自己的模板，跟你API用的格式对不上就很容易跑偏。

试试显式指定dynamic shape并锁死optimization profile，回退多半是某些插件层不支持。

QLoRA下batch size 4就OOM有点不太对劲，A100 80G不该这么脆。你先把gradient checkpointing打开试试，这玩意儿对显存占用影响巨大，不开的话激活值能吃掉一大半显存。另外序列长度2048也不算短，几万条代码数据如果单条偏长，实际显存峰值会比你想的高不少，可以先用max_seq_len 1024跑通再往上加。代码补全和对话微调确实有区别，代码任务一般学习率可以

反讽和隐晦抱怨这种确实不能全指望模型自己悟，光靠调温度意义不大，0.1和0.3在这种语义理解上差别很有限。我一般会在prompt里直接给反讽的定义和两三个例子，尤其是“表面夸实际骂”的那种，比单纯说“考虑潜在意图”管用很多。另外可以试试让它先输出推理过程再给标签，别一上来就要JSON，很多时候它标签错是因为根本没想清楚。真要稳的话，输出后再加一个校验步骤专门判断是不是反讽，比死磕单次调用靠谱。

这毛病太常见了，模型对冷门API就是容易瞎编，我也是每次生成完先跑一遍才敢用。

几十万条这个量级其实挺尴尬的，Milvus 全套依赖跑起来确实重，etcd、MinIO、Pulsar 一套下来，本地开发用 docker compose 都得吃不少内存，要是团队没人专门管运维，起步阶段容易先被环境折腾一遍。Qdrant 单二进制部署是真的省心，Rust 写的，内存占用和启动速度都舒服，几十万到几百万向量用 HNSW 完全扛得住，不用太担心“后面数据量上来”这件事，真到上千万再考虑

这感觉我太懂了，Cursor默认就爱炫技，能一行协程绝不给你写循环。我现在的做法是项目根目录放个.cursorrules，把“别用asyncio除非我明确要求”“别搞抽象基类”“优先用requests+bs4”这些写死，它生成前会先读这个，效果挺明显。但说实话，光靠限制风格不够，你得逼它解释。我改选择器的时候会先让它用一句话说清这段代码干嘛的，再让它按我的写法重写一遍，来回几次它就摸清你的口味了。

我搭RAG时也踩过这个坑，光在system里写“严格基于原文”基本没用。后来改成把检索片段放进user prompt里，用【参考文档】包起来，再补一句“若文档没写具体数字就回答不知道”，效果稳了不少。temperature设0有用但不治本，关键还是指令要具体到“禁止推断数字范围”这种程度。Few-shot我试过，加了两个“原文没提就说不知道”的例子后，模型确实老实多了。