需求起源：为什么我们动了换 embedding 的念头

某金融知识库项目原使用 text-embedding-ada-002，在测试 DeepSeek-V4 的 128k 长文本嵌入能力时发现： - 技术债：旧索引存在短文本截断导致的上下文丢失（平均 256 tokens 截断） - 业务诉求：需要支持合同条款级语义匹配（需保留 8k+ tokens 上下文） - 性能瓶颈：旧模型处理长文档时 GPU 显存溢出率达 17%

第一阶段：天真的混搭实验

直接部署新模型服务端，在查询时对同一问题并行生成两种 embedding： 1. 旧模型向量走现有 Milvus 索引 2. 新模型向量实时生成后降维到相同维度

踩坑记录： - 召回率陷阱：混合 top-k 结果时，新旧模型 score 分布差异导致新模型结果被压制 - 性能惩罚：双倍 GPU 计算使 P99 延迟从 78ms 飙升至 210ms - 业务投诉：风控部门发现相同查询在不同时段返回结果不一致 - 向量空间分析显示：专业术语相似度下降幅度（Δ0.22）远大于通用词汇（Δ0.08）

第二阶段：全量重建的黑暗森林

离线重建方案选型

方案	耗时	存储成本	回滚风险	关键约束
全量新建索引	42h	2.3TB	需双写期	要求停机维护窗口
增量更新	无法实施	-	新旧向量不共线	需特征空间对齐
别名切换	18h	1.2TB（临时）	需版本化存储	依赖数据库快照功能

选择别名切换方案的关键操作： 1. 使用 DeepSeek-V4 embedding 生成新向量时开启 truncation_strategy=right 2. 新旧索引并行写入时设置 consistency_level=Session 3. 通过 alter alias 原子切换时触发 503 熔断 4. 建立文档版本映射表记录每个 chunk 的 embedding 版本

工程细节： - 向量生成采用 batch_size=32 时显存利用率最优 - 为缓解写入压力，将 Milvus 的 auto_flush_interval 从 1s 调整为 5s - 使用 Kubernetes 的 PriorityClass 确保重建任务不被在线查询抢占资源

上线后观测

• 召回质量：hit@5 提升 34%（人工评估集），专业术语匹配准确率提升 51%
• 成本变化：
• 存储成本 +18%（因保留双版本索引）
• 推理成本 -22%（得益于 DeepSeek-V4 的 FP16 优化）
• 网络传输量减少 15%（新模型维度从 1536 降至 1024）
• 意外收获：rerank.CrossEncoder 层效果提升 19%，推测因新 embedding 的语义空间更连续

何时可以不用重建？检查清单

1. ✅ 新旧模型训练目标相似（同为通用 vs 同为领域专用）
2. ✅ 下游任务仅需相对排序（无需绝对值阈值）
3. ✅ 能接受 recall@k 波动 ≤15%
4. ❌ 涉及安全敏感的场景（如反欺诈）
5. ❌ 使用静态阈值过滤（如 cosine_similarity > 0.8）

边界案例： - 法律条款检索允许 12% 的召回波动 - 客户画像匹配要求严格版本一致性

血的教训：那些没写在文档里的事

• 版本快照必须保留旧模型 docker image，ES 的 _source 字段存原始文本不足够
• 测试集需要包含「新旧模型分歧案例」，我们后来补充了 200 组对抗样本
• 监控项新增「embedding 版本漂移告警」，基于 query 日志抽样重算
• 发现 PyTorch 的 nn.functional.normalize 在不同版本间有数值误差

延伸思考：被忽略的离线评估

大多数团队只关注上线后的 A/B test，但我们在重建前用 annoy 做了小规模向量空间分析：

# 新旧模型向量相似度热力图
import seaborn as sns
sns.heatmap(
    cosine_similarity(old_vecs[:1000], new_vecs[:1000]),
    annot=False, vmin=0.3, vmax=0.7
)

发现金融术语簇的相似度普遍低于娱乐新闻（0.48 vs 0.62），这解释了为何混搭方案在专业场景失效。

操作手册：安全迁移五步法

1. 预评估阶段：
2. 用 t-SNE 可视化新旧向量空间重叠度
3. 对核心业务查询做人工标注对比
4. 并行运行期：
5. 实施双写但禁用新索引查询
6. 每日校验两个索引的 top-k 重叠率
7. 切换验证期：
8. 按流量百分比逐步放量
9. 实时对比新旧版本的召回差异
10. 监控强化期：
11. 设置 embedding 版本标记透传
12. 对关键查询强制版本回源校验
13. 清理期：
14. 保留旧索引 30 天可查询
15. 建立版本回滚的自动化剧本