多模型路由切换后为什么答案风格漂移：能力矩阵、提示词版本与验收样本

线上客服机器人最近出现了一个很难凭肉眼排查的反常情况：同一条用户提问，上午返回三段简短回答，下午就变成了长篇说明，甚至原本格式化的步骤列表直接变成了流水账式的散文。所有请求日志看起来都正常，HTTP 状态码全是 200，真正发生变化的是模型路由命中了另一组模型与提示词的组合。

这里提到的“风格”不是模糊的审美偏好，而是可落地验收的输出契约：开头是否先点核心信息、列表最多允许几项、代码块格式是否保留、语气是否允许使用第一人称、回答总长度有没有超出产品上限。把这些约定梳理成标准样本和校验断言，路由切换才不会变成毫无记录的盲测式A/B尝试。

先把漂移拆成四个可观察变量

同一输入得到不同答案时，先不要把全部责任推给模型本身。至少要记录下面四个核心变量：

这个拆分非常实用。比如模型版本完全没有变动，但路由服务为了降低延迟自动切换了另一组提示词；或者提示词本身没有改动，fallback 选用的模型上下文上限更小，最终输出只保留了最核心的结论。如果日志里只笼统写“model=gateway”，后续几乎不可能还原当时的现场情况。

能力矩阵解决的是路由资格，不是文风一致

候选模型列表不应该只维护一套“强弱排序”的规则。对实际产品有用的是能力矩阵：每个候选模型在任务类型、上下文规模、工具调用、结构化响应、延迟和成本维度上的明确边界。厂商公开文档通常会区分稳定版、预览版和会被后台热切换的 latest 别名，生产环境的路由逻辑要把这些状态按不同风险等级做记录，而不是只存一个对外展示的名称。

type ModelCapability struct {
    Name             string
    Stable           bool
    ContextLimit     int
    SupportsTools   bool
    SupportsSchema  bool
    P95LatencyMs    int
}

func choose(candidates []ModelCapability, needTools, needSchema bool) (ModelCapability, error) {
    for _, m := range candidates {
        if m.Stable && m.ContextLimit >= 16000 &&
            (!needTools || m.SupportsTools) &&
            (!needSchema || m.SupportsSchema) {
            return m, nil
        }
    }
    return ModelCapability{}, errors.New("no compatible model")
}

上面的函数只做第一层筛选：它可以排除能力完全不匹配的候选模型，却没法保证不同模型返回的回答有完全一致的段落节奏。路由结果还要绑定指定的 prompt_version，同时把选择该模型的原因写进请求日志里。如果业务场景只能用 latest 这类动态别名，至少要在响应元数据里保存当时实际命中的模型标识，方便后续问题回放。

用同一提示词回放，先判断是模型差异还是模板差异

排查时准备一组小而稳定的验收样本，比临时拿一条线上问题试更可靠。我通常用 12 条：4 条事实问答、3 条多步骤任务、2 条需要拒答的边界问题、2 条长上下文问题、1 条要求固定 JSON 的接口样本。每条样本有自己的 sample_id，输入和关键断言都固定。

{
  "sample_id": "faq-steps-03",
  "input_sha256": "固定输入的摘要",
  "assertions": {
    "has_conclusion_first": true,
    "max_bullets": 5,
    "must_include": ["回滚", "验证"],
    "max_chars": 900
  }
}

问题回放第一轮只替换模型，保持 prompt_version、采样参数和输入内容完全不变；第二轮只替换 prompt_version；第三轮才调整 temperature 或者最大输出上限。每一轮都要保存原始响应和断言校验结果。这样就算两套模型的能力边界不同，也能明确判断是“模型本身没法满足输出约束”，还是“模型能力足够但没有按提示词模板生成对应内容”。

提示词版本要和路由配置同一批次发布

一个很常见的坑是路由配置单独放在配置中心，提示词模板却由业务应用包携带。灰度切换流量的时候，配置中心先把10%的流量导向新模型，业务应用实例还可能在使用旧版本的提示词模板，最终表现看起来像模型风格不稳定，本质上是两者的组合排列范围被意外扩大了。

可以把每一次路由决策固化成这样的记录：

{
  "route_name": "support-answer",
  "model_id": "provider-model-stable",
  "prompt_version": "support-v7",
  "parameter_profile": "balanced-v2",
  "sample_id": "faq-steps-03",
  "result": "pass"
}

发布新版本时先把这四项的组合锁定，再逐步扩大流量比例。不要在同一个灰度窗口里同时升级模型、重写 system prompt 还要改输出长度限制，否则后续指标变差时根本没法定位是哪一项改动带来的影响。出现明显的风格漂移时，最快的回退单位也应该是“路由 + 模板 + 参数”的整套组合，而不是只回退模型名称配置。

把风格验收写成产品边界，而不是主观评分

“感觉回答更啰嗦”这类主观判断没法做自动回归。可以把它拆解成几条轻量的可落地断言：

• 结构：首段必须包含核心结论；步骤类问题必须输出编号列表。
• 长度：普通问答输出不超过900个中文字符，超长上下文场景允许单独配置档位。
• 安全：触发拒答条件时不能输出内部工具参数或者虚构的来源信息。
• 事实：固定实体、版本号和字段名必须来自输入内容或者可信的底层资料。
• 接口：面向机器消费的字段严格通过JSON Schema校验，面向人读的摘要不能代替字段校验逻辑。

JSON Schema 的作用是验证实例是否满足结构约束，没法单独保证语言风格符合预期；同理，模型厂商声明“支持结构化输出”也不等于业务需要的字段永远非空。把“字段存在”“枚举值合法”和“文本长度合规”分开验收，出现失败时才能准确判断是直接重试、切换下一个候选模型还是流转到人工处理流程。

灰度期间看差异率，不只看成功率

HTTP 成功率只能说明请求链路走完了，完全不能代表返回的答案满足产品约定。建议把每个样本的断言结果聚合成几项可观测指标：结构通过率、关键事实覆盖率、回答超长率、拒答准确率和 P95 延迟。新路由先跑完离线回放校验，再接小比例真实流量；真实流量对比阶段只拿同一类用户的同类型任务做参照，不要把不同问题的分布混在同一张平均统计表里。

当结构通过率下降但整体延迟有所改善时，不要立刻用调低温度参数的方式掩盖问题。先拉取失败样本看集中命中了哪条断言：如果是列表数量不符合要求，大概率是模板版本出了问题；如果是核心字段缺失，可能是模型的结构化能力不足或者走到了错误的拒答分支；如果只是措辞上的细微差异，就应该更新验收规则的可接受范围，而不是强行把所有输出都压缩成一句话。

常见问题：路由和验收怎么落地

只保留模型名，不保存实际版本可以吗？

不建议这么做。至少要保存实际命中的模型标识、路由选择原因和当时的配置快照；如果使用会动态变化的别名，后续问题回放时需要拿到当时真正命中的模型版本信息。

把 temperature 调成 0 就不会漂移了吗？

不会。调低温度只能减少部分采样带来的随机波动，没法解决提示词版本不同、模型能力边界不同或者 fallback 组合不同带来的风格差异问题。

验收样本应该越多越好吗？

优先覆盖边界场景，再逐步增加样本总量。12条能覆盖所有主要任务类型的样本，通常比几百条没有明确断言规则的随机问题更容易定位差异。

模型换代时最小回归动作是什么？

锁定同一输入、提示词、采样参数和路由配置，分别跑旧模型与新模型，保存完整原始响应，对比结构、事实、长度、拒答结果和延迟五类指标的差异。

结语：把“风格”变成可回放的组合

多模型路由的价值是让系统可以在能力、延迟和成本之间做动态平衡，但选择逻辑越灵活，越需要留下可追溯的解释证据。能力矩阵负责筛掉能力不匹配的候选，提示词版本负责固定表达边界，验收样本负责把“看起来不一样”转化为可以自动回归的明确差异。三者和路由记录绑定之后，模型切换就不再是冒险式改配置，变成可灰度、可回退、可复查的常规工程变更。