更新是持续发生的
厂商常在不改模型标识的情况下更新权重、后训练数据与默认参数，接口不变但行为会漂移。所以要跟踪的不是公告，而是「标识 → 行为快照 → 回归结论」这条链：把固定评测集、固定提示词与固定参数打包成可重复的快照，按固定节奏复测并留档。公告只是提示信号，快照才是事实来源。
基本信息
| 跟踪对象 | 权重更新、后训练调整、默认参数变更、端点位增减、下线计划 |
|---|---|
| 信息源 | 官方变更日志、API 响应中的版本字段、SDK 发布说明 |
| 复测节奏 | 月度例行 + 任一变更触发即时复测 |
| 记录字段 | 模型标识、快照日期、评测集版本、结论、影响范围 |
| 责任分工 | 一人固定负责台账，避免到期无人复测 |
| 产出物 | 一份可检索的变更台账与每次复测的差异结论 |
典型使用场景
- 建立变更台账：把每次行为变化与日期、结论绑定，事后可追溯
- 例行回归：每月跑一次核心集，先发现漂移再谈原因
- 静默升级发现：用户反馈变差时，用快照对比确认是否厂商侧变化
- 下线与弃用预警：提前把替代模型纳入回归清单
- 文档同步：示例、提示词与默认参数随模型变化一起更新
- 成本复核：结合用量分布确认行为变化是否带来单位成本上升
跟踪项与可观察信号
| 跟踪项 | 可观察信号 | 处置 |
|---|---|---|
| 输出长度分布 | 平均与分位长度突然整体偏移 | 在快照记录中标注，复核提示词是否仍适配 |
| 格式合法率 | 同一提示词下 JSON 解析失败率上升 | 先核对是否新增了字段或包裹文本 |
| 重复度 | 同一输入多次运行的一致率下降或上升 | 调整采样参数前先确认基线 |
| 拒答倾向 | 边界请求的拒答率变化 | 复核使用政策与提示词合规表述 |
| 版本字段 | 响应中携带的版本标识发生变更 | 记录新标识并触发一次完整回归 |
| 延迟与超时 | 首字节时间或超时率台阶式变化 | 排查端点位、网关与并发配置 |
版本台账条目
版本台账条目
# 台账一条 = 一次可回溯的行为观测
model_id: 供应商/模型别名
observed_alias_ver: 2026-10-17 的响应版本字段 # 别名背后的实际版本
snapshot: 2026-10-17 14:20
suite_ver: core-v3 # 评测集版本，改题必须升版本
prompt_ver: v7
params: temperature=0, top_p=1, max_tokens=2048
result: 132/150 通过 # 与上期 135/150 对比
changed_cases: [case-013, case-047] # 只列变化项
action: 复核提示词，暂不回滚路由
owner: 平台组行为指纹可以用低成本方式建立：固定输入重复若干次，记录输出长度分布、解析成功率与关键字段取值；这些统计量对参数与权重变化都很敏感，比肉眼读一两条输出可靠得多。
SDK 版本与模型标识要分开记。很多「模型变差」其实是 SDK 改了默认超时、重试策略或流式解析，把两类变化混在一行记录里会导致归因错误。
静默升级不一定有公告，只依赖邮件或发布页跟踪必然漏掉变化；同时厂商保留调整与下线旧版本的权力，锁定标识不等于永久可用，需并行准备迁移方案。