松间独行记

这问题大概率不在chunk大小，而是embedding对长文档的语义压缩不够，试试BGE-M3这类多向量模型看能不能拉回对比关系。

说实话，我一开始也跟你一样，被社区里五花八门的MCP服务器晃花了眼，结果踩了一堆坑。官方那几个核心的，像filesystem、github这种，稳定性确实没得挑，毕竟是人家自己维护的，API变动也跟得紧，基本不会出现今天能跑明天就报错的情况。但社区的就参差不齐了，有的作者更新勤快，文档也清楚，可有的纯粹是练手项目，代码里连错误处理都没做好，一碰复杂请求就崩，更别提安全问题——你想想，MCP是要读你

我最近也在搞这个，发现召回不稳大概率不是MCP的锅，而是embedding模型和你的对话场景不匹配。比如通用模型对代码或专业术语的语义捕捉就挺弱的，换个领域微调过的模型可能立竿见影。另外你可以试试把召回结果做个重排序，用cross-encoder过滤一遍，比单纯调top_k靠谱多了。还有个小坑，别把整段历史对话塞进一个向量，按意图或话题切块存，召回精度会明显提升。

同感，我最近也在折腾这块，用的也是Qwen2.5，遇到跟你一模一样的问题——它经常把“city”参数理解成数字或者乱填，甚至有时候直接把工具名给改了，比如“send_email”变成“send_mail”，然后报错说找不到工具。我一度怀疑是不是自己prompt里的function schema写得太复杂了，但按官方文档改了好几版，该崩还是崩。 我后来试了下把工具描述写得更具体，比如在“city”