爱折腾的测试人手记

查下验证阶段有没有加no_grad，我之前就是忘了这个，显存一路飙到爆。

这个现象我遇到过，大概率是训练数据里assistant回复的开头太喜欢复述问题了，模型学到了“先重复再回答”的模式。你可以翻几条训练样本看看，是不是不少答案都以“根据您提到的…”开头。建议把这类冗余前缀裁掉重训，或者在推理时加一句system prompt明确要求直接作答。另外5000条里如果长问题占比低，模型对长输入的鲁棒性也会差一些。

我也踩过这坑，后来把“没答案就拒答”改成“先列相关段落再判断”，反而准多了。

protobuf版本冲突确实挺烦的，我之前也踩过类似的坑。你可以试试用uv或者poetry给MCP单独建个虚拟环境，把它的依赖跟主项目隔离开，比docker轻量多了。另外TypeScript SDK那边可以看下package.json里有没有把protobuf锁死，有时候两个SDK共用proto定义会互相干扰。实在不行就用subprocess调CLI模式，绕开Python依赖这块，我最后就是这么干

试试把上一步结果直接塞进子Prompt里当输入，别让它自己记。ReAct不一定必须，但状态传递得显式做。

2000条确实少了点，LoRA容易过拟合反而把通用能力带偏，试试掺点通用数据或者降降学习率？

角色设定真不是心理安慰，我实测能稳住输出风格，但示例别超三个，多了反而干扰。

top_k调小点，或者加个rerank，把碎片按语义拼回去试试。

几万条文档Qdrant足够，比Milvus轻量还好维护，召回也不差。

stdio挂多了确实容易卡，我生产只留3个高频的，其余按需加载，SSE反而稳一些。

几千个切片Chroma确实够用，但metadata过滤这块我踩过坑，复杂条件基本得自己在应用层补逻辑，挺别扭的。我后来换Qdrant了，docker一条命令起来，过滤和多租户支持比Chroma强不少，迁移成本也不高。几十万条这个量级Milvus其实有点重，除非你后面要上千万或者要分布式，不然Qdrant或LanceDB更省心。真担心扩容的话，趁数据少早点换，比后期迁移舒服多了。

这个问题其实挺典型的，我前段时间也踩过类似的坑。MCP的prompt模板说白了就是个字符串拼接器，它没有类型系统的概念，你把base64和JSON混在一起塞进去，模型看到的就只是一大坨token，它当然分不清哪部分是"数据"哪部分是"内容"。我的做法是在server端就把多模态结果拆成两部分返回，图片走MCP的image content block，JSON走text block，别自己拼成一个字

7B做Agent确实有点勉强，尤其function calling这种需要严格结构化输出的任务。我之前用Qwen2.5-7B也遇到过类似情况，后来发现关键不在temperature，而是prompt里工具描述的格式和few-shot示例够不够清晰。你可以试试把工具定义写得更死板一点，再塞两三个调用示例进去，比调参数管用。另外量化到4bit的话指令遵循能力会掉不少，有条件跑fp16或8bit会稳很多

两个都用过一阵，Milvus功能确实全，但部署那套依赖太重了，etcd、MinIO、Pulsar一堆组件，小团队维护起来真心累。Qdrant就轻量多了，Rust写的单二进制跑起来很爽，过滤查询也顺手，不过生态和文档相比还是薄一点。我们最后选了Qdrant，主要是图省心，你们数据量大概什么级别？上亿的话可能还得再掂量掂量。

检索召回不行，先别怪框架，换个问法就挂多半是embedding没匹配上，建议先查召回结果再调别的。

FP16掉点太正常了，尤其分割这种对边界敏感的活。你试试把SE模块单独标成FP32跑，或者用polygraphy逐层比对一下，大概率是某个attention分支的数值溢出。那个nbDims==4的报错基本就是opset12对动态shape支持有坑，退回11或者手动固定维度能绕过去。小目标断裂的话，检查下TensorRT有没有把resize插值算子优化成最近邻了，这个在遥感细线上特别致命。

财报这种数字密集的文档，切片时最好带上表头或章节标题，不然embedding根本分不清是哪季度的数。

Cursor的Chat模式确实容易丢上下文，它每次回复会重新理解需求，不是真的“记住”你之前定义了啥。我一般会在提问时把相关代码块贴进去，再加一句“沿用上面的变量名，别改名”。另外可以试试Composer模式，它对你项目里的文件感知更强，改起来不容易乱起名。养成手动指定变量名的习惯后，基本就没再遇到NameError了。

两张4090跑6B其实挺宽裕的，建议先上vLLM试试，它那个PagedAttention不用你手动调太细，默认参数就能跑，gpu-memory-utilization设0.85左右两张卡各分一半就行。FastChat并发上来确实顶不住，我们之前也是这问题才换的。量化的话AWQ比int8体感好一些，速度大概能快个三四成，精度掉得不算明显，知识库问答场景基本够用。

说实话模板变量多这事我测过，替换本身消耗几乎可以忽略，真正吃时间的是后续把拼好的长文本塞给模型那一步，协议传输那点开销跟模型推理比根本不算啥。我倒是建议你关注下变量值本身是不是每次都得从外部拉取，比如从数据库或者API取，那才是延迟大头。另外我踩过坑的是条件拼接逻辑写太复杂容易出错，不如拆成几个小模板按需选，维护起来反而省心。 --- 变量替换这活儿基本都在客户端本地干的，MCP服务器只负责把