大模型新版本上线：评估、灰度与风险控制实践

一、为什么模型升级需要工程化流程

模型升级看似只是把一个模型标识替换成另一个，实际影响远不止于此。同一段提示词在新版本上，输出格式可能变化，回答长度可能增加，拒答边界可能移动，响应延迟和单次调用成本也可能改变。这些变化在通用基准里往往不可见，却会直接影响下游解析程序、用户体验和账单。

因此，升级前需要回答三个问题：新版本在我们的业务数据上表现如何；上线过程中如何控制影响范围；出现问题时如何快速恢复。下面按照”评测、解耦、灰度、监控回滚、安全”的顺序展开。

二、升级前：建立面向业务的评测体系

2.1 构建评测集

评测集应来自真实流量，而不是人工编写的几条样例。推荐按以下四类抽样：

• 高频请求：占线上流量最大的任务类型，决定体验的基本盘。
• 长尾请求：调用次数少但结构复杂的任务，例如超长输入或多条件约束。
• 边界请求：接近安全策略或业务规则边界的输入，用于观察拒答与误拒。
• 失败历史：过去出现过错误或被用户投诉的案例，确保同类问题不再复现。

每条样本需要有明确的评分依据。能用规则判断的（如 JSON 是否合法、字段是否齐全）优先用规则；语义类任务可以由人工标注一部分，再用标注结果校准自动评分器。

2.2 拆分评测指标

单一的”准确率”无法反映升级的全部影响。建议至少拆分为以下维度：

• 任务质量：按业务定义的正确性评分。
• 格式遵从率：输出能否被下游程序直接解析。
• 拒答率与误拒率：分别统计合理拒答和不该拒答却拒答的比例。
• 延迟：分别记录 P50 与 P95，尾部延迟对用户感知影响更大。
• 单次成本：按输入与输出的计费单元折算，结合平均长度估算。

2.3 新旧版本对比的方法

对比时应保证条件一致：相同输入、相同系统提示词、相同的采样参数。由于生成结果存在随机性，同一条样本建议重复运行三次以上，观察分数的波动范围。如果新版本的平均分更高，但方差明显变大，说明它在某些输入上更不稳定，这比平均分更值得关注。

下面是一个简化的评测框架示例，其中评分函数由业务方自行实现：

import statistics
from dataclasses import dataclass
@dataclass
class Case:
    prompt: str
    rule_id: str  # 指向业务定义的评分规则
def run_suite(call_model, cases, score, runs=3):
    report = []
    for case in cases:
        scores = [score(call_model(case.prompt), case) for _ in range(runs)]
        report.append({
            "rule": case.rule_id,
            "mean": statistics.mean(scores),
            "spread": max(scores) - min(scores),
        })
    return report

2.4 正确看待公开基准

公开基准分数可以作为参考，但有几个局限需要注意。其一，测试题可能已经进入训练数据，分数会偏高。其二，基准的任务分布通常与业务分布不一致，例如基准偏重数学推理，而业务偏重信息抽取。其三，单一分数无法体现成本、延迟和稳定性。因此，公开分数只能用来筛选候选版本，最终决策应以业务评测集为准。

三、升级中：用别名与配置解耦模型版本

3.1 避免在业务代码中硬编码模型名

如果模型标识散落在各个服务的代码里，每次升级都要改代码、走完整发布流程，回滚也很慢。更好的做法是引入一层路由配置，业务代码只引用逻辑名称，由配置决定实际使用的版本。

model_routes:
  ticket-summary:
    primary: "model-v2-stable"
    fallback: "model-v1-stable"
    rollout_percent: 5
    prompt_version: "ticket-sum-v7"

这样做有三个好处：版本切换只需修改配置；提示词与模型版本可以分别管理；出现故障时，可以立即切回备用版本。

3.2 提示词版本化

提示词是业务逻辑的一部分，应与代码一样纳入版本管理。每次升级模型时，应同时确认提示词是否需要调整。有时新版本对同一提示词的理解已经变化，需要在提示词中收紧输出格式约束，而不是盲目沿用旧提示词。

四、灰度发布与放量策略

4.1 分阶段推进

建议按照以下阶段逐步放量，每个阶段设置明确的通过条件：

1. 内部验证：研发与测试人员使用新版本，覆盖主要功能路径。
2. 影子流量：线上请求同时发送给新旧版本，只返回旧版本结果，比较两者差异。
3. 小比例灰度：例如 5% 的用户使用新版本，持续观察一到两个业务周期。
4. 分区域或分租户放量：先选择风险较低的租户，再扩展到全部用户。
5. 全量切换：确认各项指标稳定后，将旧版本保留为备用一段时间。

4.2 稳定分桶

灰度分流必须保证同一用户在一段时间内始终命中同一版本，否则体验会前后不一致，指标也难以归因。可以按用户标识做哈希分桶：

import hashlib
def in_canary(user_id: str, percent: int) -> bool:
    digest = hashlib.sha256(user_id.encode("utf-8")).hexdigest()
    bucket = int(digest[:8], 16) % 100
    return bucket < percent

该方法结果稳定，且不需要存储分桶记录。

4.3 设定放量门槛

每个阶段的门槛应事先约定，例如：格式遵从率不低于旧版本，P95 延迟增幅不超过 20%，用户投诉量没有明显上升。门槛数值应根据业务容忍度确定，这里的数字仅为示例。

五、监控与自动回滚

上线后需要持续观察的指标包括错误率、超时率、拒答率、格式失败率、单次成本和用户反馈。这些指标应在同一看板中按版本拆分展示，便于直接对比。

回滚条件应当写成明确的规则，避免依赖人工判断。下面是一种常见写法：

若 5 分钟错误率 > 基线 × 2，或 P95 延迟 > 基线 × 1.3，或格式失败率 > 1%，
则将流量比例回退到 0，并通知值班人员。

回滚前后都要进行演练。团队应定期在测试环境中模拟一次完整的切换与回退，确认配置生效时间、缓存失效时间和告警链路都符合预期。

六、成本与容量规划

6.1 计算单位请求成本

单次请求成本可以按如下方式估算：

单次成本 = 输入单元数 × 输入单价 + 输出单元数 × 输出单价

新版本即使单价不变，平均输出长度的变化也会改变总成本。因此，升级评估中应同时统计输入输出长度的分布，而不是只看单价。

6.2 控制上下文长度

上下文窗口变大，并不意味着每次请求都应该填满它。过长的输入会增加延迟和成本，也可能引入无关信息干扰回答。更稳妥的做法是只放入与任务相关的内容，必要时使用检索或摘要压缩历史记录。

6.3 容量与限流

峰值流量需要单独评估。建议为模型调用设置并发上限和排队机制，并对不同业务设置优先级，避免某一类请求占满资源。缓存也能降低重复请求的开销，适用于答案稳定、输入重复率高的场景。

七、安全、合规与隐私

7.1 按风险等级分配权限

不同能力的模型应按风险等级分配访问权限。例如，具备较强代码生成或外部操作能力的模型，只开放给经过审批的服务与人员。权限应遵循最小化原则，并定期复核。

7.2 输入输出审计

请求与响应应保留审计日志，同时要对敏感信息做脱敏处理，例如手机号、证件号和密钥。日志本身也要设置访问控制与保留期限，不能成为新的泄露来源。

7.3 个性化与长期记忆功能的数据边界

如果产品提供跨会话记忆功能，需要明确三件事：记住哪些内容，记忆保存多久，用户能否查看和删除。这些规则应写入产品说明，并在技术上落实为可验证的数据生命周期管理。

八、落地检查清单

• 评测集覆盖高频、长尾、边界和历史失败四类样本。
• 指标包括质量、格式、拒答、延迟和成本，并按版本拆分。
• 模型标识通过配置管理，业务代码不直接硬编码版本。
• 提示词与模型版本分别记录，可独立回滚。
• 灰度分流采用稳定分桶，并设定每阶段的通过门槛。
• 回滚条件写成规则，并定期演练。
• 成本估算同时考虑单价与输入输出长度分布。
• 权限按风险分级，日志做脱敏与访问控制。

模型升级的风险主要来自不可见的行为变化。通过业务化评测、配置化切换、分阶段放量和明确的回滚规则，团队可以把这些变化控制在可观测、可撤回的范围内。