把一家模型从系统里撤下来：盘点、替换与回归的顺序
一、退出比进入更需要清单
据公开报道，某地一个联邦部门要求相关机构从信息系统中移除某家企业的 AI 相关产品，并停止采购其产品与服务，模型由境外服务商托管的情形同样受限。政策本身不在本文讨论范围，我们也不做任何评价。对企业侧来说，这一类通知落到工程手里，只有一句话：把某一家从系统里拆出去。
难点在于进入和退出的工作量不是对称的。进入时只做一次选择，比价格、比效果、看接口，选定就接上。退出时要拆掉一整层依赖：谁在调它、经过几层转手才调到它、数据还在不在对方机器上、由它产出的东西还要不要继续用、换掉之后原来那些指标还成不成立。这一层里任何一格没盘出来，退出动作就会在中途卡住，而且往往是卡在最贵的地方。
顺序也不能反。常见的错法是先挑替代品，再回头找谁在用，结果替换方案定下来才发现某个流程依赖的是对方特有的能力，或者某批向量索引根本导不出来。正确的顺序是四张清单依次做完：依赖盘点、数据与托管位置、已生成产物存续、替换回归。
二、第一张清单：依赖盘点要按四个藏身处找
一家模型在系统里的存在形式通常分四类，只搜代码是不够的。
第一类是直接调用，应用代码里显式写了它的接口地址与模型名，这类最容易发现。第二类是经网关或框架间接调用：统一网关的路由表里配了一条转发规则，智能体框架的工具配置里填了默认模型，某个 SDK 的内部默认值就是它。这类调用的特征是业务代码里没有痕迹，出问题时没人知道是哪一段链路在用。第三类是被写进了非运行时的地方：提示词模板里固定了模型名，评测脚本的基线用它的输出算分，持续集成里有一次冒烟调用，运维的排障手册里抄了参数示例。这些位置平时不参与业务，一旦停摆会同时打断开发流程与验证流程。第四类最深，是离线蒸馏或微调出来的权重：用自己的小模型承接了它的输出做训练数据，或者教师模型生成的标注进了数据集。
盘点的做法是四路交叉，任何单路都会漏。一路从网关与代理日志按目标端点聚合，看哪些服务地址在长期被访问；一路从账单与密钥归属反查，每个账号名下的调用方列出来；一路在代码仓库全文检索接口域名、模型名与相关枚举常量；一路查配置中心、提示词库与工作流平台里的模板。四路取并集，再逐个确认调用方是否还在服役。
最容易漏的是人不在链路里的历史调用。定时任务、夜间批处理、别人离开前留下的一次性脚本、还没升级的旧版本客户端、封存的项目环境，这些都在跑，但没人对结果负责。判定它们是否算依赖的办法不是看负责人，而是看它今天有没有真实请求进来。
三、第二张与第三张清单：托管位置和已经生成的东西
数据与托管位置要回答的是东西在谁家机器上。送出去过的数据不能只算提示词，还包括上传过并留在对方存储里的文件、提交过用于微调的数据集、以及按条款留存在服务端的调用日志。然后是托管形态的资产：由同一家服务商托管的向量库、托管数据库、缓存与对象存储，这些和模型调用是两笔账，却经常被当成一件事处理，撤的时候才发现要迁移的是整套数据面。导出这件事必须提前问清三样：能导什么、多久能导完、导出后还是不是原格式。向量索引常常只能导出检索结果而不是原始向量，那就等于要重新嵌入一遍。
已生成产物的存续是第三张清单，它最容易被跳过，因为这些东西看起来已经在我手里了。三类要分开判。 embeddings 换模型即失效：不同模型的向量空间不可比，同一份语料重建后相似度分布会变，混合检索里那套分数阈值要重调，历史相似度查询的结果不可再作为依据。标注数据要区分用途：由该模型生成的标签如果进了训练集，要评估是否继续用于新模型训练、是否需要在数据集卡片里标注来源。合成样本按可再生程度排序：只用于一次性演示的可以作废；进了评测集的必须重建，而且重建要在换模型之前做，否则会拿新模型的输出当基线去测新模型。
重生成的优先级应当是：先保线上能跑的链路，再补评测基线，最后回填历史数据。反过来做会在中途失去判断依据。
四、第四张清单：替换回归的六步
替换不是选一个更便宜的接口，而是一次外部依赖更换，按变更来管。六步依次是：候选清单、金标评测集、容差线、离线并行评测、灰度、回退方案。
候选至少要两家，并且要按能力形态而非价格分档：有的任务只需要格式稳定的抽取，有的需要长上下文检索，把它们塞进同一个候选池会得出错误结论。金标评测集必须是自建的那一份，覆盖真实输入分布并按任务分桶，公共基准在这里没有用。容差线要在跑之前写成区间：哪类任务要求零回退、哪类允许在一定范围内波动、波动后由谁判定可以接受，全部提前定；事后凭感觉判断，只会变成拉锯。灰度顺序按风险排：离线评测通过，影子流量并跑一段，再按业务线切小流量，最后全量。回退方案要具体到密钥与配置是否还留着、判定回退的阈值、以及回退后必须在多长时间内出说明。
五、三条常被忽略的事
合同与支持。撤换之后，已经购买的许可、历史版本的调用权、技术支持与故障响应到什么日期为止，要逐条对回合同。停供不等于停服，很多纠纷出在这里：许可还在期内但通道被关，或者通道还能用却没了补丁与安全更新。
指标基线重算。换了模型，原先那些按模型表现定的指标口径立刻不可比。可行的处理是把指标名带上口径版本，旧口径停止更新并标注截止日期，新口径另起一条基线，中间不要接成一条曲线。否则半年后没人能解释那个跳变是业务变化还是换供应商造成的。
审计与对外说明。撤换要留一份能核对的记录：时点、依据、影响范围、当时的替代方案与验收结论。这份记录的价值不在写下的那一刻，而在下一次被问到时能够给出答案，而不是让工程师凭记忆复述。
六、核心交付物：四张清单、责任人与完成判据
| 清单 | 必须盘出的对象 | 责任人 | 完成判据 | 常见漏项 |
|---|---|---|---|---|
| 依赖盘点 | 四类调用位置与全部调用方标识 | 平台或网关负责人 | 四路来源取并集后逐个标注服役状态，无人认领的调用清零 | 定时任务与旧版客户端 |
| 数据与托管位置 | 外发数据、托管的索引与缓存、导出通道 | 数据负责人 | 每个存储位置有去向结论：迁回、重建或销毁，并留时间窗 | 只能导出检索结果而非原始向量 |
| 已生成产物存续 | 向量、标注、合成样本及其进入的评测与训练集 | 算法负责人 | 每类产物有保留或重生成结论，重生成排定顺序 | 拿新模型输出当基线测新模型 |
| 替换回归 | 候选、金标集、容差线、灰度与回退 | 业务负责人 | 离线并跑出结论，灰度阶段每档有验收人与放行记录 | 回退方案没留旧密钥与配置 |
四张清单做完，撤一家供应商的工作量就已经从估算变成一张能核对的表。我们内部把这张表当交付件用，洹拓科技给客户做类似评审时，只看一件事：四张表是不是都有责任人签字与完成判据，缺任一项，就不能对外说已经移除完成。