企业级向量库应用札记

system prompt不一致绝对是首要排查点，本地没加线上加了，模型行为差异会很大。另外vLLM和transformers的sampling默认实现确实有细微差别，建议把线上temperature设成0先跑一批对比输出。TP=4本身不直接影响质量，但FP16在多卡通信下偶尔会有数值不稳定，可以试试bf16。乱码那个更像是tokenizer或stop token配置的问题，查下线上有没有截断异常

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

学到了，感谢分享！

这个思路不错，收藏了。

学到了，感谢分享！

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

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

这个思路不错，收藏了。

这个思路不错，收藏了。

几十万条Qdrant单机就够用了，部署也省心，元数据过滤挺顺手的。

这个问题的根源大概率不在LangChain本身，而是检索环节出了岔子。“报销流程是什么”和“发票怎么贴”语义差异其实挺大的，如果你的embedding模型对口语化表达不够敏感，召回结果可能完全不一样。我之前也踩过类似的坑，后来发现把检索和生成拆开单独调试特别有用——先看检索出来的top_k文档到底是不是相关的，如果这一步就不对，后面prompt怎么写都白搭。LangChain确实抽象层多，但它帮你

换框架不如先上结构化输出约束，让他按schema吐JSON，比调prompt稳多了。

这个卡住的问题我太有共鸣了，之前用AgentExecutor跑多Agent也是类似情况，任务一多就开始互相等。后来发现根因往往不在LangChain本身，而是AgentExecutor默认是同步阻塞的执行模型，每个Agent跑完才轮到下一个，你想要的并行其实它压根没给你真正做。再加上规划Agent和执行Agent共享上下文或者工具时，很容易出现状态竞争，重复执行同一个子任务基本就是这么来的。我的建

我前段时间搞遥感分割也踩过几乎一样的坑，Dice从0.92掉到0.85，细长目标断得跟虚线似的。fp16大概率是元凶，UNet++里SE那层做全局池化再sigmoid，值域压得很小，fp16尾数位不够直接把小响应抹掉了，你试试把SE和最后的sigmoid输出层强制keep fp32，其他层fp16，通常能救回一大半。opset 11转出来掉得比12狠，是因为11对某些插值和reshape的算子导出

我一般会先用一两句话把核心约束单独写出来，比如“必须用pathlib，不要用os.path”，然后再说背景需求。另外把输入输出示例直接贴上去特别管用，模型对着例子写比听描述靠谱多了。顺序上我习惯把硬性要求放最后再重复一遍，感觉比放开头更稳。

MCP服务器默认只传最近几轮，试试在客户端配置里把上下文窗口调大，或者中间加个摘要层。

我之前也卡过这个，后来发现是Cursor读的是配置文件里的command字段，得把`python`换成绝对路径，比如`/usr/bin/python3`，不然它启动的可能是另一个环境。另外你的server.py里如果用了`if __name__ == "__main__":`记得确认mcp.run确实被调到了，我之前缩进错了导致根本没跑起来。还有个坑是Cursor的MCP面板有时候不会自动刷新，改

我们也在搞类似的，不过没硬套MCP那套context，而是把它当个调度层用，底层还是自己维护dataset config和tensor spec。多模态那块确实坑，MCP原生结构处理图像token和文本token对齐挺别扭的，后来我们干脆把图像特征单独抽出来挂在context的metadata里。感觉轻量适配比复刻一套靠谱，不然维护成本太高了。

光靠prompt确实不靠谱，我一般会加个二次校验，让模型先判断文档能不能回答再生成。

我也遇到过类似情况，切分粒度确实影响很大，但你这个更像是query和doc的语义粒度没对齐。用户问的是操作步骤，而召回片段是概述性语句，bge对这种细粒度意图区分确实一般。建议试试按标题层级切，把操作步骤单独成块，再加个bge-reranker做精排，效果会明显不少。换模型的话可以看看m3e-base或者gte-large-zh，对中文技术文档更友好一些。