向量索引重建策略：召回率下降时别只调参数

向量索引重建策略召回率下降时别只调参数一、向量索引会老化向量数据库上线后很多团队只关注查询延迟和召回率却忽略索引维护。数据持续写入、删除、更新向量分布会变化索引结构也可能逐渐偏离最初构建时的状态。召回率下降时只调ef_search或nprobe可能只是加重查询成本。向量索引需要重建策略而不是一次构建永久使用。二、监控索引健康度flowchart TD A[向量集合] -- B[新增比例] A -- C[删除比例] A -- D[分布漂移] A -- E[召回评测] A -- F[查询延迟]索引健康度可以从新增数据占比、删除墓碑比例、向量分布漂移、召回评测和延迟变化共同判断。单看延迟可能发现得太晚。vector_index_health: inserted_ratio_since_build: 0.25 deleted_ratio: 0.08 recall_drop_threshold: 0.02 latency_p99_threshold_ms: 120阈值要按业务容忍度设定不能照搬默认值。三、召回评测要稳定重建索引前后要有固定评测集。评测集应覆盖热门查询、长尾查询、新增数据和边界样本。否则重建后看起来召回提升可能只是样本选择变了。def recall_at_k(expected, actual, k): return len(set(expected[:k]) set(actual[:k])) / k还要保留精确搜索结果作为参考。近似索引评测如果没有 baseline就无法判断损失来自索引还是来自 embedding 本身。四、重建要可灰度向量索引重建通常成本不低不能直接替换线上索引。更稳的做法是旁路构建新索引完成后双读对比再灰度切流。rebuild_plan: build_side_index: true dual_read_compare: true traffic_shift: [1, 5, 20, 50, 100] rollback_to_old_index: true双读期间要比较召回、延迟、超时率和资源消耗。新索引召回更好但内存翻倍也未必能接受。最后索引重建还要绑定 embedding 版本。模型升级后向量空间变化旧索引参数可能不再合适。把索引版本、数据版本和 embedding 版本一起记录排查才不会混乱。重建频率也不能只靠固定周期。每天重建可能浪费资源一个月不重建又可能让召回持续下降。更稳的方式是事件触发新增比例超过阈值、删除比例过高、召回评测下降、embedding 模型升级任一条件满足再进入重建流程。rebuild_trigger: inserted_ratio: 0.2 deleted_ratio: 0.1 recall_drop: 0.02 embedding_version_changed: true还要考虑多租户差异。大租户的数据分布变化更快可能需要独立索引或更频繁重建小租户共享索引则要避免被少数异常数据拖动整体策略。最后重建任务本身要限流。后台构建如果抢占 CPU、内存或磁盘 IO会让线上查询变慢。维护任务也必须有资源预算。重建完成后还要保留旧索引一段时间。新索引灰度期间如果发现召回异常或资源超预算可以快速切回旧索引避免重新构建拖慢恢复。五、总结向量索引重建策略要监控新增、删除、分布漂移、召回评测和延迟并通过旁路构建与灰度切流降低风险。召回率下降时别只调参数。索引维护本身就是生产能力。