2026 年 10 月 31 日，OpenAI 原有 Evals 平台中的既有评测进入只读阶段，并计划于 11 月 30 日关闭相关仪表盘和 API。与此同时，OpenAI 已公布多批模型退役时间：部分 GPT-4 系列模型计划于 2027 年 1 月 14 日停止服务，GPT-5.3-Codex、GPT-5.1 等模型也有明确的后续下线日期。
供应商提前通知、给出推荐替代模型，已经为迁移留下了窗口。但对企业而言，最容易被低估的问题是：接口还能调用，不等于业务仍按原来的方式运行。
同一段提示词、同一组工具、同一份知识库，换到新模型后可能产生不同的拒答边界、工具选择、输出结构、语言风格、响应时间和成本。对于内容辅助，这可能只是体验变化；对于报价审核、客户回复、工单分派或合规检查，它可能直接改变业务结果。
因此，模型退役不应只进入开发团队的升级清单，还应成为企业 AI 的常规经营事件。
推荐替代模型，不等于业务等价模型
传统软件依赖升级时，团队通常验证接口、字段和异常码是否兼容。生成式 AI 多了一层不确定性：即使 API 参数完全兼容，模型行为也可能不同。
例如，一个新模型可能总体能力更强，却在企业的特定任务上出现这些变化：
供应商所说的“推荐替代”，通常意味着产品路线上的迁移方向，不代表它已经满足某家企业的业务验收标准。真正的兼容性，必须由企业用自己的场景和失败成本证明。
- 更倾向补充解释，导致下游系统无法解析原有格式；
- 更谨慎地拒绝边界问题，造成正常业务无法继续；
- 更积极地调用工具，增加费用或触发不必要动作；
- 对模糊信息作出不同假设，改变分类与路由结果；
- 在中文专业术语、内部缩写或长文档提取上表现不同；
- 响应更快或更便宜，但人工返工比例上升。
不要从“新模型准确率更高”开始验收
模型迁移最常见的误区，是先跑一个综合准确率，再决定是否切换。综合分数能够发现明显退化，却很容易掩盖少量但高影响的错误。
企业更适合从业务决策反向建立迁移验收：
OpenAI 的官方评测指南也明确指出，模型输出具有随机性，传统软件测试不足以覆盖 AI 架构；评测尤其适合在升级或尝试新模型时验证系统行为。这里的重点不是一定使用哪一套评测产品，而是评测数据、判定规则和历史结果必须由企业持续掌握。
- 验收维度：应回答的问题
- 任务成功：新模型是否完成了用户真正需要的结果，而非只生成合理文本？
- 关键错误：哪些错误会造成损失、投诉、违规或不可逆操作？发生率是否上升？
- 边界行为：信息不足、互相冲突、超出权限时，是否会暂停并请求人工处理？
- 工具行为：是否选择正确工具、传入正确参数，并遵守调用顺序与次数限制？
- 输出契约：结构化字段、引用、语言、格式是否仍能被下游稳定消费？
- 人工成本：审核、修正和解释需要多少时间？是否把模型节省转成了人工返工？
- 运行指标：延迟、令牌、失败重试与每个成功任务的总成本如何变化？
迁移测试集不应只是“精选好问题”
许多团队的测试集来自演示阶段：问题清晰、资料完整、答案已知。这类样本适合证明系统能工作，却无法证明它在真实环境中不会失控。
一套可用于模型迁移的测试资产，至少应包含四类样本：
同时，测试集需要保留必要的版本信息：输入数据、提示词、工具定义、知识库快照、业务规则和期望结果。如果只保存问题和模型答案，半年后很难判断差异来自模型、数据、提示词还是业务规则变化。
NIST 的 AI 风险管理框架把测试、评估、验证与确认放在整个生命周期中，并要求对预训练模型等第三方资源进行持续监控。其 2026 年发布的部署后监测研究也提醒，受模型随机性和动态输入影响，生产系统可能出现受控测试中未暴露的行为。因此，迁移前的离线评测只能决定“是否可以开始试运行”，不能替代上线后的持续观察。
- 高频正常任务：代表大多数真实用量，用于确认基本能力与效率；
- 业务边界任务：信息缺失、需求模糊、规则冲突、权限不足，验证系统是否正确升级；
- 历史失败样本：来自投诉、人工纠正、事故和近失误，防止旧问题重新出现；
- 高影响低频任务：虽然很少发生，但一旦错误会造成显著损失。
企业需要双轨运行，而不是选一个周末直接切换
对重要业务，合理的迁移过程不应是把模型名称改掉、跑通接口、一次性上线，而应分阶段比较：
第一阶段：影子评测
新旧模型接收相同的生产输入，但新模型结果不进入业务。团队比较关键错误、工具调用、成本和延迟，先发现系统性差异。
第二阶段：受控放量
只把低风险任务或少量流量交给新模型，并保留人工复核。此时重点不是追求放量速度，而是确认离线评测与真实业务表现一致。
第三阶段：可回退切换
扩大流量前，确认模型路由可配置、提示词和工具版本可回滚、旧模型在可用期内仍能接管，并明确触发回退的阈值。
第四阶段：退役旧路径
新模型稳定后，清理旧模型权限、密钥、专用提示词和无用监控，同时保留评测结果与迁移决策记录。否则，表面完成了升级，系统里仍残留无人维护的旧路径。
这种双轨运行会增加短期成本，却能把模型切换从一次押注变成一组可观察、可中止的决策。
评测资产必须与单一供应商解耦
本次 OpenAI Evals 平台进入退役流程，本身也提供了一个重要提醒：企业不仅要考虑模型可替换，还要考虑评测基础设施可迁移。
至少应确保以下资产可以独立导出和复现：
如果企业的评测只能在某个供应商控制台中运行、历史结果无法完整带走，那么更换评测工具时就可能失去质量基线；没有基线，模型迁移只能重新依赖主观试用。
平台可以外购，质量标准不能外包。真正属于企业的 AI 资产，不只是提示词和知识库，还包括“我们如何证明这个系统可用”的证据体系。
- 代表性测试数据及其来源、脱敏和使用权限；
- 评分规则、人工标注规范和可接受阈值；
- 提示词、模型参数、工具与知识版本；
- 每次评测的原始输出、评分和失败分类；
- 与实际业务结果关联的反馈数据；
- 迁移批准人、例外项与遗留风险。
把下线日期变成日常运营指标
企业可以从一张简单的模型依赖清单开始，为每个生产用例记录：当前模型与版本、供应商状态、已知下线日期、业务负责人、替代候选、评测集覆盖率、预计迁移周期和回退方案。
随后设置三个时间点：
预览模型的通知期可能更短。OpenAI 官方文档指出，一般可用模型通常至少提前六个月通知，某些专用变体至少三个月，而预览模型可能只有约两周。因此，承担关键业务的系统不应依赖“到期前再迁移”，也不应在缺少快速替换能力时把预览模型作为唯一生产路径。
企业 AI 的可靠性，不是选中一个永远不变的最佳模型。模型会升级、改名、涨价、改变行为，也会退出服务。真正可靠的系统，是在这些变化发生时，企业仍然能回答：哪些业务会受影响，新模型是否通过验收，何时可以切换，失败后怎样退回。
能调用最新模型，只代表企业跟上了技术；能在旧模型退役时保持业务不变，才代表企业建立了生产能力。
- 距下线 120 天：确认影响范围、负责人和候选模型；
- 距下线 90 天：完成离线评测与差异分析；
- 距下线 60 天：开始受控放量，给修复和回退留下余量。
