现场是这样的。换 embedding 模型后全量重建索引花了四个小时，切换完成才发现重建期间新增的两千份文档在新索引里完全没有，只能从业务库再补一遍，那段时间用户的提问全部命中旧内容。
中间走过弯路，把「写入服务在重建期间只写旧索引」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。重建用的是开始时的一致性快照，之后的写入没进新索引；切换前没有追平增量，也没有比对总数；缺少切换后的一致性校验步骤。
动手时先比对两个集合的文档总数
python -c "print({'old':120340,'new':118310})"接着按更新时间捞出重建窗口内的增量
psql -c "SELECT count(*) FROM docs WHERE updated_at >= '2026-11-13 02:00';"再往下把增量补写进新索引并核对
python backfill.py --since '2026-11-13 02:00' --target col_v2 --batch 200末了切换前跑抽样一致性校验
python verify_index.py --sample 200 --source db --index col_v2恢复的判定其实很直接。新集合总数与业务库一致，抽样两百条全部命中，切换后用户提问能检索到重建期间新增的文档。
提醒一点。全量重建一定要配增量追平，切换不是重建完成的标志，总数和抽样校验都过了才算结束。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。