小白LinuxLab

7B模型确实对few-shot挺敏感的，示例多了反而容易过拟合到具体话术上。我试过把示例精简到每类一个，而且故意用跟真实数据不同风格的句子，效果反而好一些。你温度0.1太低了，意图分类可以稍微调到0.3左右，让模型别死抠字面匹配。另外可以试试把分类逻辑写进指令里，示例只作为格式参考，别让它当成标准答案去套。

我也踩过这个坑，后来发现与其堆设定，不如把任务拆细。比如生成注释这事，先让模型只判断函数功能，再单独生成参数说明，最后拼起来，稳定性高很多。few-shot也别贪多，挑两三个边界case比塞十个正常例子管用。另外温度调低点试试，有时候效果忽好忽坏就是采样随机性在作怪。

这种情况我太熟了，Cursor 改代码“越改越崩”很多时候真不是 prompt 的锅，而是上下文管理的问题。你让它改一个函数，它会把整个文件重新读一遍，然后基于自己理解重写，原来那些能跑的边界逻辑就被它顺手“优化”掉了。我的做法是改之前先把要动的函数单独选中，用 Cmd+K 的 inline edit，只让它在这个选区里操作，别让它碰全文件。另外重试和异常处理这种横切逻辑，最好你自己先写好骨架，比

你这情况挺典型的，3090跑7B并发10个OOM不奇怪，Qwen2.5-7B的KV cache在4096长度下每个请求大概要1G多，10个并发就顶满了。建议先把max-model-len降到2048试试，再把max-num-seqs卡在6-8，gpu-memory-utilization可以提到0.92左右。block-size一般不用动，16就挺好，它主要影响显存碎片不是总量。24G卡上7B稳定

Qwen2.5的隐藏层输出确实不是拿来当embedding用的，它没经过对比学习训练，语义空间对检索任务并不友好，最后一层还偏生成方向。你检索时好时坏很正常，跟归一化和池化关系不大，换mean pooling也救不了多少。建议直接上bge-m3或者gte-large这类专门做检索的模型，几百兆就能跑，跟Qwen2.5搭着用效果差挺多的。

训练和推理的prompt格式最好别差太多，但可以加点小变化增强鲁棒性。我试过在训练时随机去掉一些模板词，效果确实比死守一个模板好。不过系统提示词也得配合着写，别全指望模型自己扛。多轮对话建议拼进去，不然模型真会“失忆”，尤其客服场景里上下文太重要了。

几十万条数据加8核16G的单机，Qdrant确实更合适，Milvus那套依赖etcd、MinIO、Pulsar的架构跑起来内存就先吃紧了，demo阶段没必要给自己找麻烦。我之前用Qdrant单机docker跑过类似的量级，内存占用大概几个G，检索延迟也很稳，基本开箱即用。不过有几点得提前想清楚，Qdrant的filter和payload索引设计跟Milvus思路不太一样，如果后面要做复杂的元数据过

试过用XML标签分块，反而更稳，长prompt没结构真容易乱。

schema漂移这事太常见了，我现在是写了个适配层，每个server配一个normalizer把返回值统一成内部结构，虽然有点土但胜在稳。zod校验MCP这边还没看到官方方案，不过你可以自己包一层，解析前先过一遍schema，炸了就走fallback。几MB的日志千万别直接怼回上下文，让工具写临时文件再返回路径，不然token分分钟爆掉。

我也有过这情况，后来发现指令超过三四条就开始互相打架，不如就留最核心那一两句管用。

7B确实吃力，换3B配RAG基本够用，函数调用建议直接用API兜底省心。

你这种情况八成是validation或者log里还在建计算图，比如验证阶段忘了加torch.no_grad()，或者把loss存进list里累计着。我之前也遇到过显存慢慢涨，最后发现是tensorboard把带图的loss给写进去了。建议先跑几个iter就打印memory_summary，看allocated和reserved哪个在飙，基本能定位是缓存还是真泄漏。另外DeepLabV3+的ASPP

重排一定要加，bge检索完接个rerank模型效果立竿见影。切片试试按语义分段，别硬切。

工具调用记录确实得单独结构化存，别混在对话历史里，不然模型很容易把参数张冠李戴。我们现在的做法是每轮只带最近几轮原文，再加一份结构化的任务状态（比如当前订单、用户偏好），摘要只用来压缩闲聊部分。关键状态走RAG或者干脆放个状态机里，比硬塞prompt靠谱多了。可以看看LangGraph那套checkpointer思路，状态和消息分开管会清爽很多。

加“输出JSON”反而乱套，大概率是格式约束和任务指令在抢注意力，模型顾此失彼了。我现在习惯把prompt拆成固定几块：角色、任务、约束、输出schema，每块用分隔符隔开，比一股脑堆在一起稳不少。长上下文可以试试把代码分块喂，先让模型标出可疑片段再单独审查，不然它容易漏细节。另外Anthropic那篇讲XML标签组织上下文的文档挺值得翻翻，比很多教程实在。

我之前也踩过差不多的坑，远程HTTP工具比本地工具难搞多了，模型经常把参数拼成自然语言塞进去。你这个60%成功率，我第一反应是数据分布问题：官方样例里的工具描述和参数schema太“干净”了，跟你真实接的Jira字段、CI返回结构差很多。建议你把真实MCP请求的tool call轨迹捞出来，尤其是失败案例，重新构造训练样本，LoRA rank也可以拉到16试试。system prompt里把每个远

显存跳变很像中间激活被context挂住了，试试torch.cuda.empty_cache()手动清一下看看还跳不跳。

我最近也踩过这个坑，后来干脆不纠结固定长度了，改成按语义切：先用句号/换行粗切，再合并到300-600 token左右，代码块和公式单独成块。bge-large-zh对512 token以内还挺友好，超了确实会被截断。判断好坏我一般看hit@5和回答里有没有引对原文，比盯着chunk大小靠谱。

权重0.5/0.5这个拍脑袋的调法我也踩过坑，后来发现稀疏和稠密根本不在一个量纲上，BM25的分数动辄十几二十分，bge的余弦相似度就零点几，直接加权等于让BM25单方面碾压，专有名词是召回了但排序全乱，长片段往前挤大概就是这个原因。可以先把两路分数各自做min-max归一化或者用RRF做排名融合，比硬调权重稳得多，RRF还省得你去纠结具体数值。查询改写我觉得值得先上，尤其人事政策里口语化问法和文

推理时记得torch.no_grad()包住，不然计算图一直堆着不释放，显存肯定爆炸。