最近在折腾MCP(Model Context Protocol),给Claude接上了自家向量库(用的Milvus)。本来想着RAG效果能起飞,结果检索出来的top5结果一堆不相关的,甚至不如我之前直接调Python SDK写死embedding的效果。排查了一圈,发现MCP工具调用时,query的embedding生成似乎走的是服务器端默认的模型,跟我入库时用的bge-large-zh不一致。但MCP server配置里好像没找到能指定embedding模型的参数?还是说需要自己在工具函数里手动处理向量化?求大佬指点一下,有没有比较标准的做法,或者踩过类似坑的兄弟说说怎么解决的。
楼主
2026-08-15
MCP接入向量数据库后,RAG检索结果反而变差了,是哪里没配对吗?
请 登录 后发表回复
全部回复
共 63 条
2楼
27天前
这个坑我也踩过,MCP本身不负责embedding,它只是把工具暴露给模型,向量化那步完全看你server怎么实现的。你八成是用了官方示例里默认的embedding函数,那玩意儿跟bge根本不是一个空间,检索能不崩吗。建议直接在MCP tool里写死用bge-large-zh编码query,入库和查询必须同一个模型,别指望配置参数能解决。
3楼
26天前
这个坑我也踩过,MCP server默认那套embedding确实跟你离线入库的模型对不上,两套向量空间都不一样,检索出来的东西自然驴唇不对马嘴。我当时是在工具函数里直接把query的向量化接回自己那套bge,server端只负责传原始文本,别让它碰embedding。另外也检查下Milvus的metric_type和索引参数,有时候是距离度量跟入库时没对齐,不全是模型的问题。
4楼
23天前
这个问题基本可以确定是embedding模型不一致导致的,Milvus里存的向量和查询时生成的向量根本不在一个语义空间,top5能对上才怪。MCP server本身确实不管embedding,它只是转发工具调用,向量化这一步得你自己在工具函数里做,或者干脆把query丢给跟入库时同一个bge-large-zh去编码。我之前也踩过,接的是Qdrant,后来直接在server端封装了一个encode函数统一走bge,检索立马正常了。建议你把入库和查询的向量化逻辑抽成一个公共模块,别再依赖任何默认模型。