隔壁云原生玩家手记

之前也踩过类似的坑，MCP 拉起的子进程默认不会继承 torchrun 那套环境变量，RANK、LOCAL_RANK、MASTER_ADDR 这些得自己在 tool 的启动逻辑里显式注入，或者干脆套一层 torchrun 的 launcher 脚本。我们实验室现在是让 MCP 只负责调度和资源分配，真正跑训练还是走 torchrun --nnodes 那套，两边通过一个中间脚本对接，稳一点。你那个

我踩过一模一样的坑，后来发现是改写把原始query里的关键实体给丢了，尤其是内部知识库那些专有名词，模型一“简化”就给你换成泛词了。建议先别急着调embedding，把改写前后的query都跑一遍检索，对比下召回的top5文档差在哪，大概率能看出问题。另外bge-small对短query其实挺敏感的，改写后句子变长反而稀释了关键词权重，可以试试让改写只做同义扩展别做精简。

我现在的做法是在MCP server那层加了个依赖白名单校验，AI生成的代码里只要出现不在白名单里的包版本就直接拦下来重写，比在prompt里约束靠谱多了。requirements.txt二次校验也得做，但光靠它容易漏，因为AI经常绕开直接pip install。另外建议把项目的pyproject.toml或者锁文件也喂进MCP上下文里，让它有个明确的版本锚点，比只写约束规则管用。

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

学到了，感谢分享！

可以试试Qwen2.5-32B或者14B，中间档在Agent任务上通常比7B稳不少，尤其是工具调用格式这块，7B确实容易飘。我之前用14B跑类似流程，配合few-shot示例和结构化输出约束，准确率能拉回来一大截。另外你LangGraph里可以把意图识别和参数生成拆开，用小模型做路由、大模型只处理关键步骤，整体延迟会好很多。

我一般会先把两次检索结果按产品去重合并，再让模型只做填空式对比，漏项能少很多。

2e-4确实偏大，LoRA一般1e-4以内，学太猛把原模型能力冲掉了。数据量够的话换Qwen更省心。

这坑我去年踩过一模一样的，先说结论：你现在的幻觉变多，大概率不是重排本身的锅，而是重排把那些“语义相似但事实不对应”的段落排上来了，模型拿到这种上下文反而更容易张冠李戴。bge这类稠密向量对口语化query确实吃力，尤其是“违约金咋算”这种，它匹配的是语义相近而不是关键词命中，Top20里只有2-3条有用太正常了。我建议先别急着微调embedding，那个成本高且见效慢，优先上混合检索，BM25对

这个问题我也踩过坑，光靠prompt确实不太靠谱，模型有时候就是不听。后来我的做法是给每个Agent单独绑定可用的工具集，写代码的Agent干脆不给它搜索工具，物理上就杜绝了重复调用。另外可以在Agent之间传一个共享的state，记录哪些步骤已经做过了，下一个Agent接手前先检查一下。职责边界最好用代码约束，别指望prompt能管住它。

ResNet50直接拿来用不行，换CLIP或微调过的模型，再试试cosine距离，L2对归一化向量才等价。

我也遇到过，4o特爱加戏，后来直接写“只改这列，别动其他，不要异常处理”就老实了。

10万张图用2048维原始特征直接怼L2，召回60%其实不算意外，ResNet50最后那层pooling输出对整体语义是敏感的，但对“相似图片”这种偏细节和局部结构的任务，判别力往往不够集中。你可以先确认一下评估口径，是拿top1算的召回还是topK，如果top1只有60%，那top10、top50可能已经很高了，问题不一定是库本身。另外L2在未归一化的高维特征上容易被向量模长带偏，试试先做L2归

几百万条其实不算大，Qdrant单机扛生产完全没问题，我们线上跑了一年多挺稳的。Milvus那套etcd+minio+pulsar的架构，小团队维护起来真挺劝退的，除非你们有专门的运维。HNSW调参别太纠结，m从16起步，efConstruction给100到200，先跑通再微调，别一上来就抠参数把自己绕进去。真赶时间的话，Qdrant几行代码就能起服务，先上线再慢慢优化，比纠结选哪个强。

我之前也踩过这个坑，直接拿Q-A对去微调效果很一般，因为模型根本没学到query和doc之间的语义匹配关系。后来改成构造三元组（query,正例doc,负例doc），正负比大概1:3到1:5比较稳，负例最好用BM25召回但没被标注为相关的那些，这种hard negative对排序提升特别明显。另外别一上来就全量微调，先冻结底层只调顶层一两层试试，不然小数据集很容易过拟合。

我之前也踩过这个坑，handshake failed 十有八九不是模型本身的问题，而是 MCP server 和客户端之间的协议版本对不上。你可以先看下两边各自的 protocol version，有时候客户端默认走的是最新版，而 server 镜像里的依赖还停在旧版，这种情况下调 context_window 和 tools 完全没用，因为它压根没走到那一步就挂了。 Docker 那块也值得查

7B全参数都不止24G，3090单卡本来就紧，你还要算激活值，batch=4不炸才怪。LoRA虽然省了优化器状态，但模型本身还是要加载的，建议先试试4bit加gradient checkpointing，把batch降到1，梯度累积开大点。另外Trainer默认会开混合精度，但你要是没显式设fp16，它可能反而多占内存，检查下training_args里bf16/fp16是不是没开。两张卡别急着张

你这配置跑单轮没问题，但多工具调用本质是长上下文+并发推理，7B塞6G本来就很极限，试试vLLM的continuous batching或者把max-seq-len砍到2K。

说实话你这个现象我太熟了，双路3090跑7B GPTQ结果一秒两三个token，基本可以断定不是显存容量的问题，而是数据在PCIe和显存之间来回倒腾的通信瓶颈。vLLM虽然优化得好，但双卡场景下tensor_parallel如果没配好，反而会引入额外的张量同步开销，尤其你模型才13GB，单卡都塞得下，根本没必要上TP，试试把tensor_parallel设成1，让数据只走单卡，说不定立刻就有惊喜。

说实话你这个情况我也踩过坑，尤其多轮对话里，模型一旦被用户口语带偏，角色设定就容易崩。我后来试了个笨但有效的办法：把角色约束和“当前任务”拆成两层，System Message只放固定人设和底线规则，比如“你是客服小助手，只回答订单相关，其他问题统一引导回主线”，然后把每轮用户输入前都动态拼一段“当前用户说：xxx，请你基于订单数据回复”，相当于用User Message里的上下文强拉注意力，比在