灯下点灯记

本质区别就是MCP把工具调用从“你说了算”变成“大家商量好”，生态统一才是它最大的价值。 刚需场景得等Agent数量上来，工具多了你才知道手写协议多痛苦。

几百万的量级真不用纠结，pgvector如果你们查询模式不复杂，直接上最省事，少维护一套系统。HNSW参数别死磕，先用默认的，把efConstruction和M调大点，等上线了观察召回率和延迟再微调，比纸上谈兵靠谱多了。等真到了千万级以上或者要复杂过滤，再考虑迁Qdrant也不迟，Milvus那套运维成本小团队真扛不住。

说实话我也折腾过一阵子，后来发现问题往往不在模型本身，而是chunk切得太粗或者检索召回太烂。你可以试试把embedding模型换大一号，或者对query做改写，效果立竿见影。另外7B模型对上下文利用能力有限，最好把检索到的文档压缩成更精炼的摘要再喂进去，别一股脑全塞。

这个问题大概率不是距离计算失效，而是embedding本身在数据量大了之后区分度不够，尤其内部文档术语密集，语义空间重叠度高。建议先试试把chunk切小一点，比如从500降到200，同时加大重叠，让每个片段更聚焦，召回质量会明显改善。混合检索确实值得加，BM25能补上关键词精确匹配的短板，尤其对专有名词和编号这类embedding不敏感的内容，用LangChain的EnsembleRetrieve

说实话你这组搭配我基本都试过，感觉问题不一定出在模型本身，而是召回和生成之间的“接口”没对齐。bge的向量空间和Qwen的注意力分布其实挺匹配的，但漏细节很可能是top_k设太小了，我一般到5以上才会缓解，尤其本地知识库句子密度高的时候。反过来text2vec+ChatGLM容易跑题，我怀疑是text2vec对长文本的语义压缩太狠，导致检索回来的chunk本身就不够聚焦，这时候调分块策略比换生成模

同感，这个Top-K调参真的是个玄学问题，我自己的项目里也踩过类似的坑。你提到K=5时召回不相关，K=20时噪声大，其实本质上是embedding本身区分度不够，加上Milvus默认的L2或余弦距离对语义相似性的捕捉比较粗糙。我觉得首先得确认一下，你这个text2vec-base-chinese在你们那个文档领域里效果如何？我之前换过BAAI的bge-large-zh-v1.5，感觉对中文长文档的