重建知识索引时，很多团队脑子里默认还是传统离线作业的画面：新版本先在后台慢慢跑，等跑完后一键切过去。可只要 AI agent 已经进入真实业务，这件事就再也不是一个单纯的夜间任务。因为索引不是静态内容仓库，它直接影响回答依据、权限边界、freshness proof、支持复盘和客户解释。你切的不是一组向量，而是一套线上知识世界。
也正因为如此，reindex 和 re-embedding 最危险的时刻，往往不是作业没跑完，而是“看起来差不多可以切了”。这时最容易发生的不是服务完全不可用，而是一种更难排的半故障：新索引召回更准，但 ACL projection 还没完全同步；embedding 已经切新了，shadow 对照却还不够；支持台开始收到新旧版本混杂的证据包，团队却没法快速解释某次 run 究竟消费的是哪一套索引宇宙。
所以 reindex migration 不该被当成一次性数据刷新，而应该被当成 Knowledge Plane 的正式发布。它需要 build、shadow、gate、cutover、rollback 和 retirement 这些生产系统才有的节奏。没有这套节奏，索引升级就很容易在最不该混沌的时候把知识层重新打回实验态。
建议配合 AI agent Chunking Policy 与 Embedding Version Set、AI agent Corpus Freshness SLA、AI agent Shadow Mode 和 AI agent Workflow Change Management 一起看。
先给结论：重建索引不是“跑完再切”，而是一个带可见状态的迁移流程
| 阶段 | 这时系统应该能回答什么 | 默认动作 |
|---|---|---|
| build | 新索引是否可构建、可验证 | 后台构建，不给线上读 |
| shadow | 新索引和旧索引结果差多少 | 对照读，不接管用户答案 |
| gated-live | 哪个 cohort 可以先切 | 小流量切换，可快速回滚 |
| full-live | 旧索引是否可以冻结 | 全量接管，旧索引只保留回放和审计窗口 |
| retire | 旧索引什么时候能正式退出 | 清理与归档，不再让新 run 读到 |
这张表的价值在于，它把“差不多能用了”的模糊直觉，变成了一个可以被系统、支持和治理流程共同消费的迁移状态机。只要这层状态缺失，团队就会不可避免地在某个周五下午说出那句危险的话：先切一点看看。
Backfill 真正要追的，不只是完成率，而是“可切读路径所需的完整条件”
很多迁移看板上最醒目的数字都是回填百分比，这当然重要，但它并不足以说明线上何时可切。一个新 index set 之所以能接管线上，至少还取决于：
| 条件 | 为什么不能省 |
|---|---|
| source coverage 完整 | 否则新索引只覆盖一部分世界 |
| ACL projection 就绪 | 否则切过去等于把权限边界一起冒险 |
| freshness metadata 对齐 | 否则 runtime 无法判断证据是否有时效证明 |
| shadow diff 达标 | 否则团队对新旧差异没有可解释信心 |
只用 backfill 百分比做 cutover 门槛，本质上还是在用离线作业思维看线上迁移。真正成熟的门槛一定是多维的，因为用户感知到的不是“你回填了多少”，而是“为什么今天这次回答和昨天不同”。
Shadow read 最值钱的，不是证明新索引更好，而是证明你知道它为什么不一样
很多团队做 shadow，只看 aggregate 指标：命中率、top-k 变化、人工评分提升。更有区分力的做法，是强制把 shadow 差异按类别拆开。至少要能回答：
- 哪些差异来自 chunking policy 变化
- 哪些差异来自 embedding 空间变化
- 哪些差异只是 freshness 或 ACL 过滤不同
- 哪些差异会改变高风险问题的最终判断
因为对 Knowledge Plane 来说，“新索引更强”本身不够。你还必须证明：它的变化是可解释的、可归因的、可在支持与审计层被说清楚的。否则 shadow 只是在给切换积累一种模糊的信心，而不是建立真正的切换条件。
失败案例：新索引上线后召回质量看起来更好了，但一部分高敏文档因为 ACL projection 还没完成被错误暴露进候选集
某团队给法务与采购知识库做重建，新的 chunking 和 embedding 在离线指标上都明显更优。团队做了一周 shadow read 后，看到整体回答质量上升，决定小流量切一部分租户。结果上线第二天，支持就收到异常：某些原本只该给管理层看的高敏说明，被普通角色在候选摘要里间接消费到了。
问题不在新 embedding，而在迁移门槛定义错了。团队把“召回质量差异达标”当成了 cutover 核心门槛，却没有把 ACL projection completion 放在同等地位。也就是说，新索引在内容层已经可读，在权限层却还没准备好。那次事故后，他们把切换条件改成更硬的组合门槛：没有 ACL、freshness 和 shadow diff 三者同时达标，就只能停在 shadow-readable，而不允许任何 cohort 进入 gated-live。
这类教训非常典型。因为它提醒团队：知识索引不是单独的检索设施，它承载的是完整的 Knowledge Plane 语义，任何一层没对齐都不配接线上流量。
Rollout 设计要围绕 cohort，而不是围绕“索引是不是整体更强”
再好的新索引，也不应该直接对全量问题一起切。更稳的做法通常是按 cohort 迁移：
| cohort 维度 | 为什么有用 |
|---|---|
| source class | 先切低风险、低敏、规则稳定的来源 |
| task type | 先切解释型、低实时性问题 |
| tenant risk | 先切内部、试点或低影响租户 |
| support readiness | 先切支持可快速解释差异的那一批场景 |
这种做法并不是更慢，而是让每一波切换都能积累“下一波能不能继续切”的证据。如果 cohort 切分消失，团队就很容易把所有差异混在一起看，最后既不敢继续，也说不清应该回滚哪一部分。
真正可用的 rollback，不是“把新索引关掉”，而是让旧索引还能稳定接住当前流量和解释需求
很多平台会说支持回滚，但回滚设计停在了一句“切回旧索引”。对 Knowledge Plane 来说，这远远不够。真正的 rollback 至少要保证：
- 旧索引还保留完整可读窗口，而不是已经被清理到只剩冷备份
- runtime 知道当前 run 用的是哪套 index set，避免回滚后解释混乱
- support 和 audit 可以分别查看切换前后的证据差异
- 新索引产生的 shadow / diff 数据不会在回滚后直接消失，方便继续复盘
没有这些条件，所谓回滚更像是“把入口拨回去”，而不是把知识层的可解释性和运行连续性一起接住。
如果你现在只能先补一层，先把 reindex migration 做成一个正式的 rollout 状态机
很多团队会先想着更快的 backfill、更便宜的向量重建。这当然重要，但更值得先补的是迁移状态机本身。因为只要 build、shadow、gated-live、full-live、retire 这些状态还没被写清，团队就一定会在压力下跳步骤，而索引迁移最怕的就是“看起来差不多”这种模糊时刻。
AI agent 的 Knowledge Plane 真正成熟，不是因为你有能力一直重建索引，而是因为你能在重建索引时，始终知道自己现在处于哪一阶段、为什么能切、为什么还不能切，以及切错了怎么稳稳退回去。把这件事做成制度，重建才不会每次都像一次冒险。
Checklist
- reindex 是否被建模成 build、shadow、gated-live、full-live、retire 的显式状态机
- cutover 门槛是否同时包含 backfill、ACL、freshness 和 shadow diff，而不只看回填完成率
- shadow read 是否能解释差异来源，而不仅仅给出一个总体提升数字
- rollout 是否按 source、task、tenant 或 support readiness 做 cohort 切分
- rollback 是否能同时保留旧索引可读性和新旧差异可解释性
- support 和 audit 是否能查看某次 run 实际消费的是哪套 index set
延伸阅读：
