模型按月更新后，企业最容易犯的错误，是把一次性选型报告当成长期结论。模型能力、价格、接口表现和服务条款都可能变化，原本稳定的业务流程也可能因输出风格或工具调用行为改变而失效。因此，持续复评的核心不是每月重新“看榜单”，而是用固定测试资产、固定指标和固定决策门槛，判断模型是否仍然适配业务。
先固定评测基线
复评首先要冻结一套可重复使用的业务测试集。测试题应覆盖真实业务题、边界难题和对抗题，并保留标准答案、评分要点以及历史输出。真实业务题检验日常可用性，边界题观察长文本、多轮上下文和复杂指令下的稳定性，对抗题则用于检查提示词注入、诱导性提问和敏感内容处理能力。
公开榜单只能用于观察市场趋势，不能替代企业自测。每次复评都应保持相同的题目、评分规则和盲测流程，同时记录模型版本、调用成本、响应延迟、任务完成率、事实错误和幻觉表现。只有这样，才能区分模型本身发生变化，还是测试条件发生了变化。
把复评变成变更管理
持续复评不应只看综合分数，而应关注业务风险是否越过门槛。客服和知识问答应重点观察幻觉与指令遵循，研发场景关注代码生成和工程上下文理解，智能体场景则要检查多步任务能否稳定完成。高风险指标应设置一票否决条件，不能用低成本或高平均分抵消严重错误。
模型更新后，可先在灰度流量中运行，保留原模型作为对照，并完整保存输入、输出和日志。若准确率、时效、成本或合规表现出现明显变化，就暂停扩大流量，回到私有测试集复核。复评周期可以按月触发，但不必每次都重做完整选型：日常采用核心测试集快速检查，出现版本、价格、接口或业务变化时，再启动完整POC与决策矩阵。
真正成熟的机制，还应明确谁负责发起复评、谁负责业务评分、谁批准切换，以及何时允许回滚。这样，模型更新就不再是供应商通知后的被动应对，而会变成一项可审计、可比较、可回退的企业级运行流程。