模型弃用就绪：在 90 天倒计时之前审计你的行为依赖

当 Anthropic 去年废弃一个 Claude 模型时，一家公司察觉到了——但这仅仅是因为下游解析器在生产环境中开始报错。罪魁祸首？新模型偶尔会将其 JSON 响应包裹在 Markdown 代码块中。旧模型从不这样做。没人记录过这一假设，也没人对此进行过测试。修复只花了一个下午；诊断却花了三天。

这种模式——无声的行为依赖在生产环境中“震耳欲聋”地崩盘——是模型迁移中典型的失败模式。你更新了模型 ID，跑了一个简单的冒烟测试（sanity check），然后发布。六周后，一些细微的问题出现了。你的 JSON 解析失败率提高了 0.6%。边缘情况下的拒绝率翻了一番。你的结构化提取漏掉了一个以前能可靠填充的字段。差异不在代码中——而在模型的行为中，而你从未为此编写过契约（contract）。

随着主要供应商现在的废弃周期缩短至 60–180 天，且模型发布的速度在加快，这已不再是一个理论上的担忧。这是一个周期性的运营挑战。以下是如何提前应对的方法。

“行为依赖”到底意味着什么

显性依赖很简单：你调用 gpt-4-turbo，然后换成 gpt-4o。搞定。隐性依赖才是问题所在。

考虑一下，除了模型回答问题的能力之外，生产系统实际上还依赖什么：

输出格式的一致性。你的解析代码假设没有 Markdown 包裹的 JSON。或者它假设模型在摘要中总是返回恰好两句话。或者它期望结构化提取中有一个特定的键名。这些假设很少被写下来；它们只是你一直在使用的模型所表现出来的特性。

拒绝行为。Claude 3 Opus 拒绝某些类别请求的比例与 Claude 3.5 Sonnet 不同。Llama 3.1 拒绝了 83% 的对抗性请求；GPT-4o 拒绝了约 4%。如果你的应用程序依赖模型优雅地处理用户输入中的边缘情况，拒绝阈值的差异可能会悄无声息地破坏用户流程。

幻觉率。不同模型的幻觉率差异巨大——而在利基科学、法律和医学话题上差距最大。在一个模型上能可靠结合上下文生成的答案，在另一个模型上可能就不行了。

模棱两可的语言模式（Hedging patterns）。GPT-4 大约有 3.3% 的答案含糊其辞；Claude 2 约为 2%。如果你在下游解析自然语言输出中的置信度信号，这些对冲短语（hedge phrases）的分布就很重要。

推理令牌的暴露。一些模型会在输出中暴露它们的思维链（chain-of-thought）推理；而另一些则不会。监测或记录推理痕迹的应用程序在这一点发生变化时会悄然失效。

这些行为都没有被模型供应商作为保证写入文档。它们是被观察到的行为——而这正是你的系统真正依赖的东西。

指纹识别测试套件

行为审计的目标不是测试新模型是否“更好”。它是为了回答一个更狭窄的问题：在对你的特定系统至关重要的方面，新模型的行为是否保持一致？

从构建一个“黄金数据集”开始：从过去 6–12 个月的真实生产流量中提取 50–200 个代表性的输入输出对。包括：

• 代表你最常见用例的正向路径（Happy-path）示例
• 以前出现过失败或意外行为的边缘案例
• 探测格式合规性（JSON schema、字段存在性、输出长度）的示例
• 以前触发过拒绝或对冲（hedging）的输入

在当前模型和候选模型上运行此数据集。从四个维度对输出进行评分：

格式合规性。输出是否符合预期的 schema？使用 JSON 校验器，而不是肉眼观察。对于下游代码以编程方式解析的任何字段，合规性必须达到 99% 以上。

语义准确性。在已知标准答案（ground truth）的情况下，新模型是否产生了正确答案？“LLM-as-judge”在这里非常有效——使用最强模型根据评分标准对候选输出进行评分。

行为指纹。新模型拒绝、对冲或未能完成任务的频率是多少？当你没有要求时，它将其输出包裹在 Markdown 中的频率是多少？跟踪这些行为的比例，而不仅仅是单个实例。

边缘案例处理。当你发送对抗性输入、格式错误的请求或无关的主题提示时会发生什么？新模型处理这些方式的差异可能会影响你的下游错误处理。

加载中…