老程_Lab手记

这种情况我在7B级别的模型上踩过好几次，说白了不完全是模型指令遵循能力的问题，上下文拼接方式的影响可能比你想的更大。top3片段如果来自不同段落、彼此缺乏连贯性，模型很容易把它们当成“参考”而不是“依据”，尤其Qwen2.5-7B这种规模，长上下文里的关键信息一被稀释就开始自由发挥。你可以先做个对照实验：把top3换成top1，或者把正确片段单独喂进去，看它还编不编，这样能快速判断是检索拼接的锅还

能跑就行，但最好抽空把AI生成的复杂部分拆开看看，不然下次改需求真会抓瞎。

2e-4对Llama3微调有点猛了，先降到5e-5试试，还崩就查数据模板跟推理时是否一致。

这个问题我太有同感了，感觉边界条件就是目前AI写代码最大的短板。我的经验是，光靠一句"请考虑所有边界情况"基本没用，模型会敷衍你。后来我改成在prompt里直接列清单，比如明确规定"如果输入为空返回什么、遇到None怎么处理、数值超过某范围怎么办"，把边界场景一条条写死，命中率能高不少。另外我还会要求它每个函数都加类型检查和assert，哪怕写得啰嗦点，事后也省心。还有个思路是别让它一次写完，先让

中间层做用户映射其实够用，几十人并发不算高，加个缓存就行。MCP认证确实偏简单，建议看看有没有现成的OAuth桥接方案。

我也遇到过这个问题，说实话一开始也以为把规范塞进resource就万事大吉了，结果发现Claude根本不会乖乖去读。后来我才慢慢意识到，MCP里的resource更像是给模型提供了一种“可查阅”的能力，而不是“强制执行”的约束。你指望它每次写代码前都主动去翻规范，这本身就跟模型的工作方式有点拧巴。我现在更倾向于把最核心的几条规则直接塞进system prompt里，剩下的细节才丢到resource

我前段时间也卡在这个阶段，后来发现一个挺关键的点：prompt的效果其实跟你怎么定义“好答案”关系特别大。如果评估标准本身是模糊的，比如“简洁”“准确”，那模型只能猜，结果当然飘。我现在会先写一个可打分的rubric，比如答案必须包含哪几个要素、字数范围、能不能出现推测性措辞，然后再去调prompt，这样至少有个方向。另外思维链不是万能药，它更适合推理类任务，纯知识问答加它反而可能让模型绕远路甚至

双4090跑7B还OOM有点离谱，检查下是不是没开gradient_checkpointing？开了能省不少。

我之前也遇到过类似情况，chroma的默认HNSW参数挺保守的，ef_search调大点（比如从10到50）能捞回更多相关文档，但会慢一些。不过你这个case更像是embedding对“退款”和“积分”这种语义区分不够敏感，bge-large-zh换bge-m3或者试试加个关键词过滤兜底。还有个土办法，召回后加个cross-encoder重排，效果立竿见影就是费点算力。

85%其实不算低了，但卡在这里确实挺难受的。你有没有检查过chunk切分策略？我之前也遇到过类似情况，后来发现是chunk太大导致语义被稀释，改成按语义边界切分后召回直接涨了一截。另外bge-m3的输出维度是1024，Milvus建索引时metric_type和索引类型要匹配好，不然参数调了也白搭。

我踩过一模一样的坑，后来发现八成是Agent循环里历史对话没截断，每轮tool调用都往context里塞，max_model_len再大也扛不住。建议先把每轮messages长度打日志看看，是不是线性增长。另外vLLM的gpu_memory_utilization可以调低点，留些余量给KV cache，OOM不一定是模型本身的锅。定位的话，单独跑一次推理不带Agent逻辑，如果不卡就是循环写的问题

8-10 token/s确实不太正常，4090跑Q4_K_M的8B怎么也得30以上。先确认Ollama有没有真正吃到GPU，跑的时候看下nvidia-smi的显存占用和GPU利用率，如果显存没怎么涨就是跑在CPU上了。另外4090的功耗墙和驱动版本也会影响，可以试试更新驱动、关掉其他占显存的程序。vLLM对量化支持确实挑，AWQ格式相对稳一些，或者直接用llama.cpp手动指定ngl层数也比Ol

先别急着上rerank，查查切分时有没有把完整语义拦腰截断，512字符对中文常常不够用。

我之前也踩过这个坑，改写query不一定总有效。大模型改写容易把原始信息丢掉，尤其口语里那些隐含的上下文，改完反而变模糊了。你可以试试让改写保留原词，只做轻微扩展，别让它自由发挥。另外bge-small对短query本身还行，改写后如果变长变抽象，反而和文档的向量空间对不齐。建议先做个消融实验，对比改写前后top5的命中率，别一次改太多变量。

我们线上也踩过这个坑，compile和vLLM的CUDA graph基本是互斥的，强行一起用显存碎片问题很难绕开。后来干脆推理侧全走TensorRT-LLM，compile只留在训练和离线批量打分里用。动态batch场景下torch.compile的收益本来就不稳定，重编译开销经常把省下的那点时间又吃回去了。除非你的shape很固定、又能接受长预热，否则生产推理真没必要硬上。

传输层确实能换，我试过gRPC接MCP，格式对上就行。多卡负载这块Ray Serve能扛，不用自己写。

A100 40G跑6B模型并发5-6路就爆，大概率是KV cache没管好，不是模型权重的问题。Int4量化对权重有效，但并发时KV cache才是吃显存大头。建议试试vLLM，它的PagedAttention就是专门治这个的，配置没想象中难，照着官方example改个模型路径基本能跑。另外把max_model_len和gpu_memory_utilization调一下，别让它无限涨。

这现象太真实了，我猜你八成是把“约束”加成了“枷锁”。模型对“必须说不知道”这类强规则的理解其实很机械，你越强调边界它就越保守，宁可漏答也不冒险。我后来把prompt拆成“底线规则”和“推理提示”两层，底线只写防幻觉，推理提示给例子引导它怎么用上下文，效果反而稳了。你可以试试把那些步骤说明改成“如果上下文能支持推断，请给出合理推测”，别急着封死所有可能性。

试试把并发压测拆开看下是不是显存带宽瓶颈，7B单卡本来吞吐就有限，考虑下pipeline并行或者直接上量化+投机采样吧。

几百条数据对7B来说确实太少了，LoRA本身改动幅度就有限，数据量不够的话模型几乎学不到新分布。另外5e-4对LoRA不算高，但3个epoch可能还没充分收敛，你可以试试把epoch加到5-8，顺便看下训练集上的loss和输出是否拟合到位。还有个小技巧：推理时对比一下加载LoRA前后的logits差异，如果差异很小，多半是数据或超参问题，而不是prompt的锅。