Provider 行为指纹：模型切换中的隐性损耗

当成本飙升、模型下线通知或竞争对手的基准测试迫使你更换 Provider 时，工程团队通常会在能力基准测试上评估候选模型，并将其视为迁移计划的全部。这个过程大约能捕获一半的问题。另一半并非能力问题，而是行为问题：那些不可见的格式习惯、拒绝模式、序列化怪癖以及输出约定——你的生产代码在数月迭代中已悄悄将其内化。

能力基准告诉你新模型能否完成任务。行为指纹告诉你你的代码库能否承受这次替换。

行为指纹的构成

每个模型都通过训练数据、RLHF 信号和宪法约束形成了自己的行为指纹。这一指纹涵盖了数十种不会出现在 MMLU 分数中的微观行为：

结构化输出可靠性。 两个模型都可以声称支持 JSON，但其实际契约却有本质区别。一个使用约束解码——一种在生成时屏蔽无效 Token 的有限状态机，以近 100% 的可靠性产出符合 schema 的输出。另一个通过工具调用机制实现结构化输出，此时 schema 对模型而言只是一个提示，而非对采样器的约束。第二种方法会导致 14–20% 的响应在 JSON 对象前插入对话性文字，或将对象用 schema 未要求的 Markdown 围栏包裹。两个模型都"支持 JSON"，但只有一个是你的下游解析器可以依赖的。

拒绝语气与触发阈值。 不同团队训练的模型对安全响应的校准方式不同。一个模型拒绝边界请求时只给出简短解释并提供替代方案；另一个拒绝时会用多段文字说明为何该请求有问题；第三个则会照做，但每句话都夹杂大量警示语。这些不是正确性差异——衡量可回答问题准确率的基准根本无法发现它们——但当你的面向用户文案预设了某种回复长度，或你的后处理会过滤"I cannot"前缀时，它们会立刻暴露出来。

空白字符、Markdown 与列表约定。 有些模型即使你没有要求也会默认使用项目符号。有些会在本该是纯文本的散文中大量使用 **粗体**。有些在段落之间多插入一个换行。有些使用牛津逗号，有些不用。对于渲染 Markdown 的聊天界面，这些只是风格偏好；但对于期望纯净文本的模板渲染器来说，它们是无声的失败。

引号风格与转义行为。 各模型在 JSON 字符串值内是否使用"弯引号"还是"直引号"、是否不必要地转义撇号、如何处理属性值内的嵌套引号等方面存在差异。这些差异能通过 JSON.parse() 而不报错，同时破坏下游的字符串比较。

上下文退化曲线。 上下文腐化——随着上下文窗口填满，指令遵循能力的退化——在不同 Provider 之间并非均匀发生。对生产部署的分析显示，退化通常在 50k–150k Token 处开始，与模型的理论最大值无关。但退化的形态——哪些指令最先失去显著性，以及质量下降的陡峭程度——在 Provider 之间差异足够大，以至于一个依赖 80k 位置指令的系统，即使两个模型声称上下文窗口大小相同，在切换 Provider 后也可能悄悄退化。

为什么能力基准无法发现这些问题

标准迁移检查表会在核心任务分布上评估新模型——跑 200 个样本，比较分数，在某个阈值处宣告成功。这对它所衡量的内容有效，但它无法衡量：

• 新模型在边缘案例上的拒绝率是否与你的重试逻辑所预期的一致
• 在 p95 延迟下它输出的 JSON 是否仍能通过 schema 验证
• 其输出中的格式约定是否与前端团队基于上一个模型输出构建的模板渲染层兼容
• 它使用的措辞模式是否符合你的内容审核过滤器所训练依据的风格指南

这些都是行为契约。在大多数代码库中，它们从未被写下来。它们随着时间推移逐渐积累——工程师做出一个个小决策（"这个清理步骤处理模型的格式怪癖"），这些决策变成了隐形基础设施。能力基准无法找到它们，因为它们不是以断言形式存储的，而是以解析代码、重试策略和后处理管道中的隐性假设存在的。

加载中…