11月6日，谷歌在开发者文档的更新日志中写明：对已弃用的嵌入模型 gemini-embedding-2-preview 发出的请求，自动改由正式版模型处理。官方说明里称接口格式、计价方式和向量空间都保持不变，已存向量无需重建索引。
把镜头拉远一点，这不是孤例。此前一家代码托管平台把自己的编程助手一次性切换到六个新模型；9月，另一家模型厂商的轻量版型号也被第三方技术观察者记录到静默替换。加上这次，近几个月已有三起同类事件。共同点很一致：旧型号字符串照常工作，请求不报错，返回的却已经不是原来的模型。
一、为什么静默替换危险
很多系统对此毫无感知，原因在于替换发生在服务端。调用方看到的是正常响应，只有输出内容或计价在悄悄变化。对嵌入检索这类场景，风险尤其隐蔽：如果向量空间真的变了，库里的旧向量与新增量就不再同处一个空间，检索质量缓慢下滑，但程序不会抛出任何异常。
还有一点常被忽略。谷歌同期宣布了一批范围更大的迁移：12月1日起，2.5系列两个型号的请求将改路由到新一代模型，官方迁移说明里明确列出了函数调用、采样参数、思考控制方式等多处接口差异。这份清单恰恰说明，自动路由与完全兼容是两件事，前者只保证请求能通，不保证行为一致。
二、三道可以落地的防线
第一道是固定版本。配置中写死完整的型号字符串，不用 latest、preview 这类会漂移的别名；收到弃用通知后主动排期切换，不依赖服务端跳转长期运行。
第二道是调用留痕。记录每次响应里的实际模型字段与版本号，定期留存抽样输入和输出。当服务商宣称什么都没变时，日志是对账的唯一凭据，也是事后排查哪些批次受影响的关键线索。
第三道是比对输出。替换发生后，用固定的一组测试用例重跑并对比结果；向量模型则抽取二三十条存量文档重新计算向量，与旧向量逐条算相似度，得分接近满分才可确认索引不受影响。这一步官方不会替你做，声称兼容也代替不了实测。
三、把防线写进上线清单
三道防线的成本都不高，多数是一次性的接入工作，兜住的却是整条下游链路的质量。多家厂商接连采用自动路由，说明换一个型号字符串就能长期不变的假设已经不成立，替换本身不可怕，可怕的是发生了而无人察觉。
值得回头检查的只有一个问题：你的系统里，记录实际服务模型是哪个的那行日志，现在存在吗？
