RAG Embedding 迁移方案：双索引、版本切换与可回滚的向量升级

升级 embedding 模型往往带来更高维度、更好的多语言能力或更低成本，但它也会改变向量空间。旧查询向量与新文档向量不能混用，分块策略改变后历史引用可能失效。把迁移当作一次普通索引重建，容易在切换后才发现召回下降、延迟激增或部分文档根本没有新向量。

第一步是为向量和分块策略显式加版本。每条文档片段记录 embeddingModel、embeddingVersion、chunkingVersion、sourceHash、createdAt 与索引状态。查询也记录使用的版本。没有版本字段，就无法解释两个时间点为什么对同一问题返回完全不同的结果。

用双索引避免一次性赌注

迁移期间保留旧索引 A 和新索引 B。新写入先根据容量策略双写，历史数据异步回填 B；回填完成前，查询结果中要能识别缺失覆盖，而不是假装 B 已经完整。影子流量同时运行 A/B 检索，记录候选重叠、相关性标注、延迟和无结果率，但默认仍使用旧索引回答。

切换条件不应只有“回填 100%”。至少还应包括：关键领域的离线评估不下降、线上影子查询没有明显的零结果增长、权限过滤一致、尾延迟在预算内、引用页面仍能定位到正确原文。对于多租户系统，按租户或数据集分阶段切换，避免一个异常索引影响全部客户。

分块变化需要单独验证

很多迁移表面上是模型升级，实际效果主要来自 chunk 大小、重叠、标题注入和表格处理。将分块版本与 embedding 版本分开，才能判断改进来自哪里。迁移时选取长文、表格、代码、短 FAQ、多语言文档和频繁更新文档作为样本，检查片段是否保持可读语义，以及引用是否覆盖完整答案。

如果新分块让一段敏感文档和无关上下文拼接，权限过滤可能仍正确，但回答会变得难以解释。检索质量评估应同时包含相关性、上下文完整性、引用精度和拒答正确性，而不只是 top-k 相似度。

回滚必须是可执行条件

提前定义回滚阈值，例如关键查询集准确率下降超过 3%、无结果率翻倍、P95 延迟超过预算、权限异常数大于零或新索引健康检查失败。触发后将读路径切回 A，同时停止 B 的推广，但保留诊断数据。不要在事故中临时讨论“是否该回滚”，那会让模型和业务风险一起扩大。

回滚后需要区分索引服务故障、回填缺失、模型语义变化和分块问题。不同原因决定下一次实验是调整检索参数、修复数据管道还是更换模型。保留每次迁移的配置快照和评估报告，后续才能比较而不是凭记忆判断。

回填任务也要受资源和一致性约束

历史文档回填往往比模型调用本身更容易出事故。它会读取大量源文件、占用队列、写入索引并触发缓存失效。应按租户、数据集和时间窗口切片，给每个分片设置进度、失败重试、最大并发和校验哈希。不要只统计“已处理条数”，还要比较源文档数、成功写入数、跳过原因和新版本可查询数。

在双写期间，更新和删除事件必须同时作用于 A 与 B；否则回填完成时新索引可能已经落后于真实数据。为每个源文档保留最后事件序号或版本戳，只有索引版本不早于源版本才能标记完成。上线演练应包含回填中途更新、删除和 worker 重启，确认最终两套索引都收敛且不会把已删除内容重新写回。

查询参数也要随版本冻结

新旧 embedding 的相似度分布不同，旧索引上有效的距离阈值、top-k 和重排权重不应原样复制。为每个索引版本保存查询参数快照，并在离线集上单独校准。否则团队可能把模型升级后的召回下降误判成索引故障，实际只是仍在使用不合适的阈值。

切换后继续保留一段时间的双读诊断，尤其关注低分但被重排命中的结果。若新空间需要更高候选数才能达到同样效果，应把成本变化一并纳入发布决策。模型、分块、索引与参数共同构成一个检索版本，缺少任何一项都无法可靠回滚。

验收报告应同时列出覆盖率、质量、延迟和成本，避免只凭单一分数放行。

任何一项越过预设阈值，都应保持旧读路径并进入诊断，而非带病切流。

延伸阅读

• 向量索引重建
• Embedding 模型选择
• RAG 增量索引一致性