键盘边修行

试试把AdamW的eps从默认1e-8改成1e-6，后期NaN经常是它导致的。

这个循环我太熟了，基本每个用Claude写代码的人都经历过。我的经验是，问题往往不在于prompt写得够不够详细，而在于你把“写代码”和“验证代码”这两件事混在一轮对话里了。它第一版漏边界条件很正常，因为你的需求描述里通常只覆盖了happy path，那些边界是你脑子里默认的、但没写出来的。我现在会先让它把函数签名、输入输出约束、异常情况用注释列出来，我确认没问题了再让它填实现，这样第一版质量能高

这个问题的核心其实不是上下文窗口不够，而是你让LLM直接吃原始召回结果，缺少中间那层筛选。生产环境里比较常见的做法是两阶段检索：先用embedding召回比较大的候选集，比如15到20条，然后用一个cross-encoder或者LLM做rerank，把真正相关的top 3到5条挑出来再拼。这样既控制了输入长度，召回质量往往比直接截断还好。你说滑动窗口切断关键信息，本质上是切分粒度的问题，可以考虑按

5000条数据对7B模型来说其实不算多，格式抖动很可能是训练里“工具名”和“参数边界”这两类token没学扎实。我一般会在数据里加一些故意带噪声的负样本，让模型学会纠正而不是死记硬背。工程上更靠谱的做法是解析前先做正则清洗，再把工具名映射到候选集做模糊匹配，兜底比指望模型100%听话省心多了。

6GB跑7B确实挺极限的，我之前也折腾过类似配置。你可以试试用llama.cpp或者ExLlamaV2这类专门做量化的框架，比bitsandbytes省显存还快不少。另外把模型分片加载，配合accelerate的device_map和offload，能缓解OOM但速度会慢。torch.compile对推理提升有限，别抱太大期望。

3060 12G这个卡其实挺尴尬的，显存够跑7B量化但上下文一长就爆，换14B量化后速度直接腰斩不说，效果还不一定比7B好多少。我自己试过Qwen2.5-14B的Q4，在3060上推理大概每秒十几个token，多轮工具调用场景下延迟明显拖后腿，而且量化对意图识别的精度损失在复杂指令上挺致命的。你提到的embedding和LLM分开部署是个好思路，embedding模型一般很小，像bge-m3也就2

我也踩过这个坑，512字硬切对接口文档来说基本是灾难级别的。你问“某个接口怎么调用”，答案可能就藏在一段代码示例或者参数说明里，硬切之后上下文直接断了，embedding出来的向量语义是残缺的，召回自然跑偏。bge-large-zh本身中文检索能力不差，问题多半不在模型上，先别急着换。可以试试按标题层级或者段落做递归切分，接口文档尤其适合按“接口名+说明+参数+示例”这种结构来切，再带一点over

vLLM fp16 OOM太正常了，24G塞8B模型还得留KV cache，不够分。你可以试试AWQ 4bit量化，vLLM原生支持，精度掉得不多，并发也比int8好不少。多卡的话vLLM有tensor parallel，启动参数加个tensor-parallel-size就行，代码基本不用动，但两张4090显存加起来也就48G，不如直接上A6000省心。CPU offload那速度你肯定忍不了，

拼回对话历史的时候有没有把工具返回的 tensor 也顺手存进去了？我踩过这个坑，history 里只要挂着带梯度的中间结果，显存就一路涨。建议每轮结束把 history 里的张量 detach 掉，或者干脆只存文本再重新 encode。另外 KV cache 没手动清也会累积，可以用 torch.cuda.empty_cache() 看着点。

这个现象其实挺典型的，loss降不代表模型学到了你想让它学的东西。二分类里如果模型发现全猜“正向”就能把loss压到某个水平，它就会偷懒走这条捷径，尤其你样本还是5.5:4.5这种轻微不均衡，模型很容易偏向多数类。你先把推理时的输出打出来看看，是生成了别的词还是只吐“正向”两个字，这能区分是分类头问题还是生成格式没对齐。 prompt模板确实可能有问题，“评论：xxx 情感：”这种写法模型不一定

几十万条用numpy暴力算其实也能扛，但QPS一上来就顶不住了，单请求几百毫秒乘个并发直接炸。我实测百万级用HNSW延迟能压到个位数毫秒，召回率调好参数基本没啥损失，瓶颈更多在内存和构建时间上。过滤这块确实要注意，Milvus这种支持标量过滤还行，纯FAISS就得自己先筛再搜，容易把召回搞崩。建议先拿faiss的IndexHNSWFlat跑个benchmark，几十万条几分钟就能出结果，比纠结强。

512字符硬切确实容易把代码块和上下文拆开，问超时配置召回参数说明太典型了。技术手册建议先按标题层级切，代码块和表格尽量整块保留，别让它们被截断。可以试试用unstructured或者markdown的header切分，再对超长段落做二次切分。另外检索时加个rerank，能过滤不少这种关键词撞车但不相关的片段。

我之前也踩过这个坑，256确实太碎了，一句话被腰斩是常事。后来改成按标题层级切，再在每块前面拼上章节路径，检索命中率明显好很多。语义分割听着美好，但几百页手册跑起来又慢又容易切歪，不太划算。你可以试试小块检索、大块喂给模型，或者加个相邻块合并的后处理，能救回不少漏掉的关键信息。

双卡4090跑70B确实尴尬，48G连FP16的门都摸不到，量化到4bit是必然选择。但AWQ对代码任务真不太友好，我试过Qwen和Llama的AWQ版本，写代码逻辑错得离谱，后来换GPTQ-Int4稍微好点但也有限。建议你试试vLLM加GPTQ，配置比TensorRT简单不少，吞吐能上来。真要写代码辅助，32B左右的模型配vLLM反而更稳，70B量化后那个质量下滑真不值当。

这个我也遇到过，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直接参与向量匹配。