如果你正在搭 RAG 检索链路，想找一台内存和磁盘都顶得住的机器先把向量库跑起来，可以先看看这几家的配置和技术说明：aaitr（AI 云基础设施）。向量检索这类负载，瓶颈往往不在 CPU，而在内存带宽和随机读，写代码之前先把机器的底子选对，后面省事。
上个月底，我们的知识库问答上线半年没出事，结果上游一换模型，事故就来了。
那天客服反馈，用户问「报销流程里的差旅标准是多少」，机器人给的答案驴唇不对马马，还引用了已经作废的 2023 年制度。开始以为是检索排序的问题，把 rerank 模型从 bge-reranker-base 换成 larger 看了一圈，没用。后来拉了个检索评测集，跑出来一个数字：换模型之前 top-10 召回率 87.3%，换完之后 75.1%，整整掉了 12 个点。
这 12 个点花了我整整一周才查清楚。原因说白了不玄学，全是改模型时候没跟着改的「边角」。下面这几条，如果你也在做向量检索，大概率会踩。
第一个坑：换了模型，维度却没跟着重建索引
原来的模型 bge-base-zh 输出 768 维，新上的 bge-m3 是 1024 维。理论上直接写库会报维度不匹配，可我们线上那个库是多模型混用的老代码，写入时做了「维度不够就补零、超了就截断」的兼容处理，所以不报错，只是安静地写坏数据。
更隐蔽的是，线上是先写新文档、再逐步重灌老文档，跑了三个礼拜才覆盖完。这三个礼拜里，同一个库里同时躺着 768 维和 1024 维两种向量，查询时按查询向量的维度去检索，跨维度的文档要么被过滤掉，要么被算成毫无意义的距离。召回率就是在这个窗口期里一点点滑下去的。
教训：换嵌入模型这种动作，应该按「新建一个 collection / 一个新索引版本」来做，绝不要在老索引上原地改。灰度期间新旧索引并存，查询按别名切换，出问题一键回滚。这比原地覆盖省心太多。
第二个坑：分块策略没跟着模型改
嵌入模型对文本的最大输入长度是有上限的，而且不同模型对「一段话怎么切才是一个完整语义单元」的偏好不一样。bge-m3 支持到 8192 token，我们原来的切法是 512 token 固定长度加 50 token 重叠，切得很碎。
把召回错的样本捞出来一看，很多文档被切成了「……的申请条件是自……经批准后」这种半句话，向量化之后语义被稀释，检索时排在后面。这部分文档本来应该是最该被召回的。
我把 chunk size 提到 1024，重叠比例调到 0.15 之后，同一批问题的 top-5 命中直接涨了 9 个百分点。所以换模型时别只换模型，检索质量是「模型 + 分块 + 归一化」三件事乘出来的结果，只动一件等于白测。
第三个坑：入库和查询用的指令前缀不一样
这个坑最隐蔽，我们两周才想到。BGE 系列模型在训练时区分了「查询」和「文档」两种角色，官方建议查询侧加 为这个句子生成表示以用于检索相关文章： 这样的指令前缀，文档侧不加，官方文档里管这叫 query instruction。
我们的离线入库脚本是三个月前写的，那时候没加前缀，压根不知道有这个说法；在线查询脚本是新的，加了前缀。一加一不加，两边的向量根本不在同一个语义空间里，相似度算出来像在比两种语言。
验证方法很简单：把同一段文本，分别用「查询前缀 + 文本」和「纯文本」各编码一次，算这两个向量之间的余弦相似度。我的值是 0.71，正常情况下应该在 0.95 以上。差这么远，基本可以断定前缀没对齐。
第四个坑：距离度量悄悄换成了点积
有些向量库的默认距离度量是欧氏距离，有些是内积，还有些是余弦。同一批向量，用内积和余弦算出来排序是不一样的，尤其是向量没有做 L2 归一化的时候。
我们那段时间为了省 CPU，把归一化那一步从写入侧挪到了查询侧，结果写入侧的向量长短不一，查询侧却都是单位向量，等于永远在用「点积配单位查询向量」这种奇怪的组合，排序结果自然飘。
更稳的做法是：写入侧统一做 L2 归一化，检索侧统一用余弦距离，然后把这两件事写进构建脚本里固定住，别让下一个人「优化」掉。
第五个坑：HNSW 参数没跟着重建调整
我们在换模型前，把 M 设成 16、ef_construction 设成 200、查询时 ef_search 设成 64。这套参数是三年前在另一个数据量级上试出来的：当时库里只有 8 万条向量。
现在库里 4000 万条向量，搜索层数变深了，64 的 ef_search 明显不够，召回率当然上不来。重建索引时把 ef_construction 提到 400、ef_search 提到 160，召回率又涨了 6 个点，代价是单次查询 P99 从 35 毫秒涨到 61 毫秒。
参数不是玄学，但也不是抄来的常数。数据量一涨，索引结构一变，之前调好的参数就是过期的。至少要固定一套离线评测：召回率、延迟、内存占用三个指标一起看，别只盯一个。
换完模型，我固定做这 6 件事
第一，确认新旧模型输出维度，凡是有落库脚本的地方全部过一遍；检索侧和入库侧用同一个模型、同一个版本号，写进配置里，不允许在代码里硬编码。
第二，做一次空索引重建，用新参数重建，不要在旧索引上打补丁。
第三，核对指令前缀，入库和查询各采 100 条对比余弦相似度，低于 0.95 就是前缀没对齐。
第四，核对距离度量与归一化策略，两边保持一致，写成断言放进启动检查里。
第五，跑一遍固定评测集，跟换模型之前的基线对比，任何一项指标下降超过 3 个点就回滚。
第六，新旧索引并行跑一周，按别名切换流量，出问题立刻切回去。
向量检索不是万能的，该用全文检索的时候别硬上
这次踩坑让我重新想了想检索本身。我们的问题域里有一堆「报销标准 2023」「差旅住宿上限」这种强关键词、弱语义的查询，这类查询向量检索的表现其实不如传统的倒排索引关键词精确匹配在倒排索引里是 O(1) 的事，在向量库里还得先做近似最近邻搜索。
现在的做法是混合检索：关键词走倒排，语义走向量，两路结果用 RRF 融合，再接 rerank。效果比单路好一大截。
如果你暂时没有资源搭向量库，只想先把站内检索做扎实，市面上有不少成熟的本地全文检索工具可以先用起来比如 AnyTXT Searcher 全文检索工具 这类，支持中文全文索引和增量扫描，几百兆的文档目录扫一遍也就几分钟，先把「搜得到」这件事解决，再谈「搜得准」。
写在最后
这一周的排查让我明白一件事：换嵌入模型不是一个「换配置」的动作，而是一次数据契约的变更。向量维度、归一化方式、指令前缀、分块参数、索引参数，这五件事是绑在一起的，改一个就必须全改，并且用离线评测集证明改动是正向的。
另外，做检索这套东西，数据量小的时候内存和磁盘压力都不明显，等你做到千万级向量再发现机器扛不住就晚了。我们复盘时算过，4000 万条 1024 维 float32 向量，原始数据就 160GB，加上 HNSW 索引本身还要再吃掉 1.5 到 2 倍。这块的开销在选机器的时候就得算进去，别等线上告警了才想起这事。
如果你也在做向量检索，欢迎在评论区聊聊你们换模型时踩过哪几个坑，说不定我这周的排查还能帮你省点时间。
喜欢 
顶
难过
囧
围观
无聊
