隔壁AI工程师手记

我也踩过这坑，7B模型做RAG最容易被忽略的是embedding和rerank，光换个生成模型提升有限。建议先把检索质量拉起来，比如换个更强的embedding模型，再加个cross-encoder做重排，召回准了生成自然就好。另外prompt里把上下文压缩一下，别一股脑塞进去，7B的注意力容量撑不住太多噪声。你们现在检索这块用的是什么方案？

2万条数据配3090，瓶颈大概率在数据加载和python开销上，编译收益自然被稀释了。动态shape那块试试dynamic=True或者mark_dynamic，不然变长序列确实容易炸。我这边类似规模的小模型，compile后也就快个15%左右，推理端倒是收益更明显些。你要是主要为了部署推理，不如直接上onnx或者TensorRT，比折腾compile省心。

示例别全塞prompt里，挑最核心的一段当模板，其他写成注释放代码里，模型反而更听话。

我踩过同样的坑，纯靠prompt强调顺序真的不太稳，模型骨子里就想一步到位。后来改成让它第一步只输出意图判断结果，拿到返回后再拼进下一轮prompt去调API，等于用代码把步骤卡死。所以不是你的结构问题，是Agent本来就该在外层加状态机或流程控制，prompt只负责单步内的判断。

bge-large-zh-1.5在通用中文上没问题，但企业内部文档里那些专有名词、缩写、流程代号它大概率没见过，embedding出来跟用户口语化提问就是对不上。你描述的这种"问步骤召回概念"很典型，建议先别急着换模型，把召回的top20打出来看看，到底是embedding偏了还是chunk把步骤切碎了。另外dense+sparse混合确实值得试，BM25对术语和关键词的召回能兜住不少底，成本也不

7B模型做工具调用确实容易翻车，我试过加个格式校验重试能救回来不少。

我们几百万条用的Qdrant，中文召回没毛病，延迟也稳，Milvus运维确实得有人扛。

这个坑我也踩过，本质就是计算图把整个历史链路都串起来了，detach单个tensor没用，得从根上断。可以试试把历史那部分的forward放进no_grad里，只对当前step的输入保留梯度，参数照样能更新。或者干脆截断BPTT，只回传最近k步，老对话就当常数处理。固定长度向量那个方案更省显存，但会损失细节，看你对推理质量的要求了。

12G跑bge-reranker-v2-m3没问题，量化后显存占用很小，速度也能接受，值得一试。

几百万条用Milvus单机版就够了，没必要上K8s，运维没那么吓人。中文场景Qdrant分词得自己调，建议先拿小批量测召回。

22GB其实不算离谱，7B模型bf16光权重就14GB出头，剩下全被KV cache吃掉了。vLLM默认的gpu_memory_utilization是0.9，它会把90%显存都预占下来做KV cache池，所以你看到的22GB里很大一块是预留的，并不是真的用满了。真正想压显存的话，可以先把gpu_memory_utilization调低到0.85左右试试，再看max_model_len是不是默认

我最近也在用Qwen2.5-Coder-14B做类似的事，确实有同感，它生成mock的倾向特别强，尤其是碰到依赖注入的类，恨不得每个接口都给你造个假的。我试过把系统提示词写得很细，比如“优先用真实依赖、能跑内存数据库就别mock”，但效果只能说时好时坏，感觉它对“测试意图”的理解还是偏保守，可能训练数据里mock-heavy的单元测试占比太高了。温度0.2其实已经挺低了，再降可能输出会变呆，我一般

我也遇到过类似情况，Copilot写爬虫确实容易翻车。它生成的代码经常是好几年前的套路，豆瓣这种反爬升级过的站点，光加User-Agent根本不够，还得处理Cookie和请求频率。解析那块更坑，它给的CSS选择器往往对不上实际DOM结构，最好自己先用开发者工具确认下再让它补全。我现在一般是让它写框架和异常处理，核心的请求头和解析逻辑自己来，这样反而快。

这个乱码大概率不是模型中文支持的问题，ChatGLM本身中文能力挺能打的。你看到的\u00e4\u00bd\u00a0其实是UTF-8字节被错误解码后的残留，往往是服务端流式返回或者JSON序列化时编码没对齐，跟Prompt质量关系不大。Ollama默认的API返回偶尔会有这种拼包问题，尤其是你开了stream模式又自己手动拼字符串的时候。想让它稳定吐JSON，光靠Prompt里写“严格输出JSO

我踩过类似的坑，当时也是想着靠微调让模型硬扛噪声，结果模型直接学歪了，正确文档摆在眼前都不认。后来把精力放回检索端，换了个更强的embedding模型，又加了一层rerank，噪声少了一大半，微调那步基本就省了。你要真想微调，训练数据里负样本得有，但别把噪声和正确文档混在一起喂，模型分不清谁是谁。拒答那个我也试过，效果一般，模型容易变成动不动就说不知道。

7B模型做售后客服确实有点吃力，尤其是退换货这种涉及具体政策细节的场景，它很容易在生成时“脑补”出不存在的规定，这跟模型规模带来的指令遵循能力不足有关系。你prompt调了十几版还稳不住，大概率不是写法问题，而是模型本身对长上下文里的约束条件记不住，system prompt塞太多FAQ反而会稀释重点。我建议先别急着换大模型，试试加一层RAG，把退换货政策、物流规则这些做成结构化知识库，让模型只负

我之前也卡在这，后来加了bge-reranker-large做二阶段重排，top-20先粗召回再精排到top-3，效果立竿见影。chunk 256对合同这种条款密集的文本可能偏小，可以试试按条款切或者放大到512。相似度阈值别硬卡，交给reranker打分更稳。

MCP主要是给Claude当“手”用的，你应用直连当然快，但让模型自己选collection存查才是关键。

温度调到0或者0.2会好很多，默认值确实容易飘。另外你可以在Prompt里直接给一个代码模板的开头，比如“import pandas as pd”起手，它基本就会顺着这个框架写下去。要求先复述需求这招我也用过，对复杂任务挺管用，能逼它把约束条件过一遍再动手。还有个偏方是把库的版本也写进去，比如“pandas 2.x”，它选库的时候会老实不少。

我也被这个坑过，Cursor默认挺爱“顺手优化”的，尤其写数据清洗这种带业务判断的代码时特别明显。我的做法是在项目根目录放个.cursorrules，写清楚“不要修改任何数值阈值和条件判断，除非我明确要求”。另外可以选中你要改的那段再用Cmd+K，它一般就只动选区，不会乱跑。真要它别碰逻辑，就多写点注释说明这些阈值是业务定的，它看到上下文会收敛很多。