过拟合的组织：当你的 AI 团队模型专业知识成为负担时

你最优秀的 AI 工程师能凭记忆背诵 Claude 的 XML 格式偏好。他们知道 Claude Opus 拒绝泛化隐式指令，知道少样本示例（few-shot examples）实际上会损害 o1 系列模型的性能，还知道在某些地区，Azure OpenAI 相比直接 API 会增加额外的 8 到 12 秒延迟。这种专业知识花了数月时间积累。它也代表了当今 AI 工程中最被低估的风险之一。

当供应商弃用某个模型或悄然改变行为时，这些知识并不会随之迁移。它会消失。那些围绕单一模型系列构建系统以及组织能力的团队，往往会以惨痛的方式发现这一点。

专业知识如何演变成锁定

特定于模型的知识在悄无声息中增长，并迅速累积。一名工程师花一周时间从特定模型中获取可靠的结构化输出。他们发布了一份内部文档。另一名工程师在此基础上进行开发。第三名工程师又叠加了更多针对特定模型的提示词微调（prompt tuning）。在六个月内，“这个模型在 XML 标签下表现良好”这种知识已经渗透到产品的架构中，以至于没有人能轻易将其剥离。

这与任何技术锁定（lock-in）的动态是一样的——它是渐进发生的，每个单独的决定看起来都是合理的，但总和却变成了限制。

这种模式会加速，因为特定于模型的技巧能带来真正的短期收益。Claude 比 GPT-4o 更字面地理解约束条件；学习编写利用这一特性的提示词能让你在今天获得更可靠的输出。针对特定模型调整的少样本示例可以显著提高一致性。知道模型在超过特定上下文窗口长度后性能会显著下降，可以让你避免昂贵的质量故障。这些都是合法且有价值的优化。

问题在于，几乎没有一种是可以移植的。当 GPT-4o 的退役迫使团队在 2025 年转向 o1 或 GPT-4.1 时，团队发现增加更多的少样本示例——这在 GPT-4 上是可靠的性能提升手段——实际上损害了 o1-preview 和 o1-mini 的输出质量。模型的推理架构改变了，团队花费数月完善的提示词优化反而变得起反作用。

账单到期时

过去两年产生了一系列异常密集的强制迁移。2024 年，OpenAI 弃用了 gpt-4-32k 和 gpt-4-vision-preview。Claude 2、2.1 和 Sonnet 3 全都在 2024 年 11 月下线。2025 年，o1-preview、o1-mini、gpt-4.5-preview 以及多个音频/实时变体接连被弃用。Google Gemini 在 2025 年底到 2026 年初的三个月窗口内，停用了两个活跃模型和一个 Pro Preview 版。

GPT-4o 本身也将于 2026 年 3 月 31 日开始从 API 中退役。

在这些模型之上构建系统的团队面临着同样的抉择：现在支付迁移成本，或者等到截止日期被迫处理时支付更高的成本。对于许多团队来说，真正的成本出现在他们未曾预料的地方：

• 提示词退化：针对已退役模型优化的提示词无法迁移。团队报告称，在转向下一代推理模型时，不得不重建和重新评估 30%–60% 的提示词库。
• 迁移过程中的行为漂移：“等效”的替代模型表现并不等效。GPT-4o 和 o1 拥有根本不同的推理架构。Claude 3 Sonnet 和 Claude 3.5 Sonnet 处理上下文的方式也不同。迁移假设了并不存在的等效性。
• 评估基础设施失效：围绕特定模型输出风格构建评估体系的团队，无法使用这些评估来验证替代模型。他们需要新的基准真相（ground truth）。
• 双重计费：迁移期间重叠的供应商合同——在维持旧模型的同时迁移到新模型——通常会导致总成本达到预期切换节省费用的 2 到 3 倍。

一项真实的成本分析发现，手动按模型路由请求与自动按提示词路由之间存在 333,000 美元的年成本缺口。这个差距代表了团队由于惯性忠于单一模型而白白流失的利益。

沉淀下来的技能——以及随风而逝的技能

特定于模型的专业知识分为两类。第一类会像旧硬件一样贬值。第二类会像优秀的抽象一样产生复利。

半衰期短的技能：

• 特定于模型的措辞和表述技巧（“Claude 对 X 表述的反应更好”）
• 针对特定模型训练分布调整的少样本示例库
• 针对特定模型怪癖的权宜之计（Token 限制、上下文处理、工具调用格式）
• 供应商 API 习惯（Azure 与直接 API、Beta 版 Header 惯例、流传输协议）

跨供应商累积的技能：

• 评估设计——知道如何衡量一个系统是否真正有效
• 行为规范——独立于任何模型定义什么是成功
• 不确定性建模——理解模型何时以及为何可能出错，并设计处理这些情况的系统
• 提示词架构——不依赖于单一模型指令遵循行为的模块化、可链接结构
• 可观测性——监控模型更新过程中的漂移、延迟、成本和输出质量
• 成本与延迟权衡的推理——理解哪些任务值得使用昂贵模型，哪些不值得

在 2024–2025 年弃用浪潮中幸存下来且表现最出色的团队，是那些核心产品逻辑与特定模型知识解耦的团队。并不是因为他们预见了弃用，而是因为无论如何，解耦都是一种稳健的工程实践。

构建模型可迁移的团队

组织层面的解决方案并非纯粹是技术性的，尽管技术变革确实有所帮助。团队需要结构和文化上的双重改变来保持可迁移性。

在不同模型间轮换工程师。 如果团队中只有一个人为 Gemini 编写过提示词（prompts），那么当 Google 调整策略时，你就会面临单点故障。有意识的轮换——即为新功能指派工程师处理他们不熟悉的模型——可以培养可迁移的直觉。编写过四种不同模型提示词的工程师会明白，特定于模型的知识是权宜之计，而非根本基础。

优先招聘具备可迁移技能的人才。 一位深刻理解评估（evaluation）设计并能对不确定性进行推理的工程师，在四分之三的迁移场景中都会胜过模型专家。面试时应侧重于考察精准定义 AI 行为、设计能捕捉回退（regressions）的评估方案以及推理失效模式的能力，而不是考察他们是否知道 Claude 更偏好哪种 XML 模式。

将提示词作为配置而非代码进行版本控制。 当特定于模型的提示词优化与应用逻辑一起嵌入源代码文件时，它们作为迁移界面的可见性就会消失。当它们作为配置进行版本管理时，你可以清楚地看到切换模型时需要更改哪些内容——并且可以追踪哪些优化是针对特定模型的，哪些是通用的。

固化架构决策，而非战术性补丁（tactical hacks）。 值得保留的知识是架构层面的：系统为何这样设计、权衡（trade-offs）是什么、存在哪些失效模式。而轮换掉的知识则是战术性的：特定模型在特定上下文长度下当下的表现如何。如果文档对这两者不加区分，团队将无法分辨哪些东西能在模型迁移中幸存，哪些不能。

抽象层作为组织保险

解决团队过度专业化和解决供应商锁定（vendor lock-in）的技术方案是一致的：即一个能将模型交互标准化的抽象层。

像 LiteLLM 这样的工具为 100 多个提供商提供了统一的接口，无论底层模型如何，其请求/响应处理都是一致的。使用 LiteLLM 接口的工程师不需要了解 Azure OpenAI 的流式传输协议或 Anthropic 的工具调用（tool-calling）架构——他们针对抽象层编写代码，而路由层处理提供商的具体细节。

这带来了第二个组织层面的好处：它降低了模型轮换的成本，使其真正可行。当切换模型需要修改几十个文件并更新定制的 API 代码时，工程师出于理性会避开它。而当只需要更改一个配置值时，他们才会真正去测试更廉价的模型是否能胜任某项工作。

同样的逻辑也适用于评估基础设施。一个设计良好的评估框架可以针对任何模型运行相同的测试套件——衡量的是实际行为与预期行为的差距，而不是将输出与参考模型的输出进行对比。那些针对固定模型输出构建评估体系的团队，在迁移过程中不得不废弃其测试基础设施。而那些衡量行为规范的评估团队则保留了这些资产。

例如，EleutherAI 的评估框架（evaluation harness）可以通过一个与分词（tokenization）无关的接口运行在任何模型上。关键洞察是：你的评估标准不应该知道正在评估的是哪个模型。如果它知道，那么你衡量的就是特定于模型的行为，而不是你的产品真正需要的行为。

无人预警的复合风险

同一个问题还有一个更微妙的版本：隐性行为漂移（silent behavioral drift）。即使没有停用通知，模型也会不断更新。OpenAI、Anthropic 和 Google 都会在没有明确版本说明的情况下推送权重更新、安全过滤器更改和解码参数调整。研究发现，嵌入重心漂移（embedding centroid drift）——一种你可以监控的信号——能在第一个用户投诉出现前的 11 天捕捉到语义降级。不监控这一点的团队只能通过用户投诉来发现问题。

最容易受到隐性漂移影响的团队也是对单一模型最专业化的团队。他们已经建立了关于模型行为的直觉，这意味着细微的变化往往被忽视，直到这种直觉彻底失效。定期进行跨模型比较的团队能更快发现漂移，因为这种比较会暴露单一模型团队无法察觉的行为差异。

应对措施

我们的目标并不是要避免培养模型专家——对特定模型行为的深度理解确实非常有用。目标是确保这种专业知识由个人掌握，而不是固化在组织依赖中。

一个拥有强大评估基础设施、不依赖供应商的抽象层以及接触过多种模型系列的工程师团队，在供应商停用模型、改变行为或被竞争对手超越时，能够迅速行动。而如果一个团队的架构、文档和制度化知识都假设使用单一模型系列，那么他们将被迫在最糟糕的时候——比如距离停用截止日期仅剩六个月，而更强大的竞争对手刚刚发布新产品时——偿还这些技术债。

一个“过拟合”的组织在分布偏移（distribution shifts）之前看起来都很能干。然后，它就会显得无能为力。修复方法与修复模型过拟合是一样的：增加正则化（regularization），增加多样性，并停止为单一评估标准进行过度优化。