小白LinuxLab

我一般直接在prompt里把“文件不存在、空行、类型错误都要try-except包住”写死，比说“健壮性”管用多了。

写得挺好，建议补充一些性能数据。

这个思路不错，收藏了。

有没有更详细的教程推荐？

刚入门，这个对我帮助很大。

刚入门，这个对我帮助很大。

学到了，感谢分享！

我之前也遇到过类似问题，后来换了方案。

我之前也遇到过类似问题，后来换了方案。

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兜底省心。