大模型供应商更新了模型版本，效果突然变差，怎么提前发现？
面试怎么回答
外部模型是会变化的上游依赖，变化可能来自别名自动指向新版本、旧版本下线、供应商的服务端调整或切换部署。预防上生产环境固定明确的版本号而不是 latest，记录每个场景用的版本，关注发布和下线计划。提前发现靠主动评测：新版本发布时用自己的评测集对比，每天或每周用冒烟集巡检线上模型，即使版本号不变也能发现服务端变化，迁移时先小流量金丝雀。线上按模型版本拆分监控工具调用成功率、格式错误率、拒答率、输出长度、负评率和抽样准确率。迁移按场景逐步进行，必要时调整提示词，保留回退能力并记录。再通过模型网关接入、准备备用模型降低对单一模型的依赖。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
某天开始，智能问数的 SQL 准确率掉了 8 个点，团队什么都没改。查了一圈发现，调用的是模型的「最新版本」别名，供应商在背后更新了模型。面试官问这题，想看你怎么管理外部模型这种不受自己控制的依赖。
问题的本质
外部模型是一个会变化的上游依赖，就像数仓里上游业务系统改了字段。模型变化可能来自：
- 使用了「latest」之类的别名，供应商升级后自动指向新版本；
- 固定版本到期下线，被迫迁移；
- 供应商对同一版本做了服务端调整（比如安全策略、推理配置）；
- 切换了不同的部署区域或服务商。
预防：固定版本
- 生产环境使用明确的模型版本号，而不是别名；
- 记录每个应用、每个场景使用的模型版本；
- 关注供应商的版本发布和下线计划，提前规划迁移。
提前发现：主动评测
- 新版本发布时：用自己的评测集对新版本做完整评测，和当前版本对比；
- 定时巡检：每天或每周用一组固定的评测集（冒烟集）调用线上使用的模型，监控分数的变化。即使版本号没变，也能发现服务端的变化；
- 金丝雀：迁移到新版本时，先在小流量上运行，对比关键指标。
线上监控
即使做了上面的工作，仍然需要线上的指标作为最后一道防线：
- 工具调用成功率、格式错误率、拒答率、平均输出长度的突变；
- 用户反馈的负评率、重问率；
- 抽样评估的准确率；
- 这些指标按模型版本拆分，出现异常时能快速判断是否和模型有关。
迁移到新版本
新版本不一定直接替换：
- 评测发现部分场景退化，需要调整提示词，因为不同版本对提示词的响应方式可能不同；
- 迁移按场景逐步进行，保留回退到旧版本的能力（在旧版本下线之前）；
- 每次迁移形成记录：变化了什么、评测结果、调整了什么。
降低对单一模型的依赖
- 通过模型网关统一接入，切换模型只需要改配置；
- 核心场景准备备用模型并定期评测，保持可切换状态。