键盘边修行

这个我也遇到过，Cursor默认会把它认为“相关”的文件都纳入上下文，你那个Hook它可能觉得有优化空间就顺手改了。我的做法是在.cursorrules里明确写清楚：只允许修改当前打开的文件，其他文件一律只读参考。另外提问的时候加一句“不要改动已有Hook的任何逻辑和类型”，基本上就能管住它了。

loss跳到3.5再降回来，八成是长文本截断把对话截半了，模型在硬猜答案，梯度自然炸。试试按token长度分桶采样，或者把超过1500的样本单独拎出来切分，别直接截。两张4090跑7B LoRA，batch size 2确实紧，可以开gradient checkpointing加flash attention，能挤出不少显存。lr 2e-4对LoRA偏高，降到1e-4甚至5e-5试试，warmup

5万条数据、max length 2048，一个epoch 10小时其实不算离谱，但确实偏慢。你检查下dataloader的num_workers是不是设太低了，还有gradient checkpointing有没有开，这两个影响挺大的。另外3090不支持bf16原生加速，试试fp16混合精度，有时候能快不少。QLoRA主要省显存，速度不一定更快，你显存够的话没必要换。

3个epoch对几千条数据来说确实有点多了，尤其是LoRA这种低秩适配，很容易在后期把模型往训练集分布上拽，重复生成很多时候就是过拟合的一个典型信号。你可以先看看训练loss曲线，如果第2个epoch之后还在明显下降但验证集已经不动甚至变差，那基本就是过拟合了。学习率5e-5对LoRA来说不算特别离谱，但配合3个epoch就容易出问题，我一般会先降到1e-4以下再试，同时把epoch压到1到2之间

微调模型在MCP里被系统提示词带偏了吧，先试试把服务端的system prompt去掉再对比下输出。

我们之前也踩过这个坑，后来在检索前加了一层query改写，用LLM把“他们的毛利率”补全成“A公司毛利率”，只拿改写后的query去检索，历史对话不直接进检索器。历史上下文单独做摘要压缩，每轮只保留跟当前问题相关的实体和意图，塞给生成模型时控制在一定token内。这样指代能保住，检索相关性也不会被稀释。你可以试试把“改写”和“检索”解耦，别让历史query直接参与向量匹配。

这俩其实是两个层面的问题，但真要说的话，我会先看检索有没有把该给的段落召回来。如果Top5里压根没有能回答问题的内容，那提示词再花也白搭；但你这个例子里明显是召回了相关内容，只是模型没用好，那改Prompt当然立竿见影。我自己踩过的坑是，chunk切得太碎时，光调提示词让模型“综合判断”，它反而会硬编，最后不如先把chunk_size调大、把噪声压下去。所以别二选一，先拿十几个bad case看是

试试把temperature调到0，7B指令跟随确实容易自作主张。

是不是MCP客户端超时设太短了，vLLM排队那会儿它早放弃了，先调大timeout试试。

这问题太真实了，我最近也在折腾类似的事。你提到的AGENTS.md其实方向对，但Claude对它的读取权重可能没你想的那么高——我发现它更像“参考”而不是“强制”，尤其对话一长，新指令和旧约束冲突时，它总倾向照顾最近的上下文。我自己试过最有效的办法是，每过10轮左右，把当前项目里所有硬性约束（包括代码风格、禁止项）手动粘贴到一个新对话开头，然后附上一句“基于以上规则，继续重构XX文件”，等于强制给

这思路挺有意思，但MCP的上下文跟训练序列长度压根不是一回事，爆显存大概率是工具调用日志和tokenizer双份开销，建议直接把微调拆成独立进程跑。

光靠prompt不够，检索到的chunk本身要带来源标识，让模型引用时带上编号，翻车率能降不少。

我之前跑7B也遇到过类似情况，24G看着大但LoRA的显存大头其实在激活值和优化器状态上，seq_len砍半只降2G挺正常的。你试试gradient_checkpointing有没有开，这个能省不少，再配合8bit优化器，基本能把峰值压到15G左右。另外target_modules如果像q,k,v,o,gate,up,down全选了，计算图也会变大，可以先只选q和v试试。

确实，工具定义全塞进上下文，模型选择负担直接翻倍，我之前挂5个就开始犯迷糊了。 生产环境我一般控制在3个以内，优先保核心链路，其他走懒加载或者拆Agent方案。

说实话你这情况我太熟了，4090跑7B fp16看着够用，但一旦把max_position_embeddings拉长或者开个稍大点的beam search，显存就跟你玩心跳。我试过一圈下来，觉得最稳的还是把模型切成int8加静态KV cache，别迷信4bit，int8的退化在代码任务上小很多，配合vLLM的--kv-cache-dtype fp8（虽然现在只支持部分模型）能省出不少。另外你试试把

这问题我也踩过坑，开源模型对“隐含约束”的敏感度确实不如闭源那几家。你可以试试把异常处理直接写进函数签名里，比如“定义函数fetch_title(url)，内部用try包裹requests.get，超时设5秒，except分别捕获Timeout和HTTPError并返回None”，比笼统说“处理异常”要稳得多。另外，让模型先输出一个代码骨架，再让你确认，分两步走，漏函数的情况会少很多。你用的温度参

说实话我之前也踩过这个坑，bge-m3在短文本检索上还行，但长文档尤其是中文段落一多，语义压缩就很严重，OpenAI的向量维度更高，对上下文的理解确实更细腻。 不过我觉得你的流程大概率也有优化空间，比如chunk切分不能只看字数，得按语义边界来，标题和段落摘要单独建索引会好很多。 另外FAISS的索引参数（比如nlist和nprobe）调过没？有时候召回差不是模型问题，是近邻搜索太粗糙了。

负样本太随机是大问题，法律文本相似度高，换hard negatives试试，温度也调低点看看。

单卡T4跑bge-large确实有点吃力，我们之前也遇到过类似情况，后来把batch size调到4、输入长度限制在512才勉强能用。不过说实话，如果真的卡在长文本召回上，问题可能不只是embedding本身，分块策略对中文文档的影响也很大，你可以试试先按章节切再按语义重叠20%来切，text2vec的短板会缓解不少。至于多路召回加rerank，延迟肯定翻倍，尤其如果两路结果集都取top50再合并

几百万条pgvector还真能打，先上这个省心，等真扛不住再迁Qdrant也不迟，K8s上它比Milvus轻太多了。