模型评测、灰度与版本迁移

小白：先定义“好”

从真实业务抽取成功、边界和失败样本，去除敏感信息后组成固定评测集。为每条样本写清可判定的期望：事实答案、JSON schema、引用、工具参数、图像主体、转写文本或拒绝策略。没有判定标准，就无法区分模型升级和随机波动。

Copy{"case_id":"support-042","input_version":"v3","model":"<PINNED_ID>","expected":{"schema_valid":true,"must_include":["退款条件"]},"metrics":["quality","latency_ms","cost"]}

建立当前基线

记录精确模型 ID、系统提示、参数、工具 schema、检索版本和输入摘要。至少重复运行随机任务，得到成功率、格式通过率、p50/p95 延迟、错误率和成本分布。对图片、音频、视频使用人工盲评或任务指标，不能只凭审美挑一张结果。

比较候选模型

先做离线同集对比，单独标记安全、工具、长上下文与多语言回归。候选通过阈值后再影子流量或小比例灰度；不要让实验请求执行真实付款或外部写操作。模型名相同但渠道不同也应重新评测，因为协议映射、区域与版本可能变化。

生命周期与迁移

区分 stable、preview、open weights 和 legacy。为 preview 准备退出路径；为 legacy 记录官方公告、停止服务日、替代型号和迁移负责人。可移动别名与固定快照拥有不同风险。迁移前核对端点、字段、流事件、工具调用、token 计数和内容安全，不要只替换 model 字符串。

灰度、回滚与观察

按租户或稳定哈希分流，保留旧模型作为回滚目标。观察质量代理指标、人工投诉、p95/p99、429/5xx、流中断、usage 和单位任务成本。达到停止阈值立即回滚；完成灰度后仍保留一段双版本对账期。

专家持续评测

把评测与提示版本、路由配置和价格快照放入变更门禁。新增高频失败样本但避免只对测试集过拟合。对代理任务记录每一步工具决策和副作用；对 RAG 分离召回、重排和生成指标。所有评测结果要可复现、可审计，并能回答“哪次变更导致了哪类回归”。