你在廉价模型上测试,却在昂贵模型上部署
在你的代码库中的某个地方,有一个配置文件,在 test 配置下写着类似 model: small-and-cheap,而在 production 下写着 model: frontier。当有人添加这一行时,感觉是很负责任的做法 —— 为什么要为了每天运行 20 次的 CI 任务去消耗 frontier 模型的 token 呢?但那一行代码悄无声息地废除了一项你的团队十五年来一直在不假思索遵循的规则:你测试的环境应该表现得和你上线的环境一致。
“十二要素应用宣言”(Twelve-factor methodology)称之为开发环境与生产环境等同(dev/prod parity),我们在这方面已经做得非常出色,以至于我们开始忽略它的存在。Docker 为我们提供了位级一致的运行时环境。基础设施即代码(Infrastructure-as-code)为我们提供了完全一致的拓扑结构。然后,我们在请求路径中间加入了一个语言模型,重新引入了我们花了十年时间才弥合的差距 —— 只不过这一次,产生差异的组件不再是数据库版本。而是系统中负责做决策的部分。
模型不是 依赖项 —— 它是环境
当你的预发(staging)数据库是 Postgres 15 而生产环境是 Postgres 16 时,你会感到一点担心。但当你的测试套件在运行一个小模型而生产环境运行的是 frontier 模型时,你应该更加担心,因为这其中的区别不仅仅是查询规划中的极端情况。它是你系统产生的每一个输出的分布都完全不同。
两个在基准测试(benchmark)中分数相差无几的模型,在关键的流量表现上可能会有巨大差异:它们如何处理歧义、拒绝回答的频率、是否将 JSON 包裹在 markdown 代码块中,以及针对同一个任务会进行多少次工具调用。跨模型提示词迁移(cross-model prompt-transfer)的研究一再发现同样的结果 —— 在模型家族之间,以及在编码、代理(agentic)和规划任务中,都存在迁移差距,因为你对提示词进行的每一次微调,都隐式地编码了某个特定模型的解释风格。你的提示词并没有趋向于“正确”。它们趋向于那个特定的模型。
这就是为什么在你的心理“十二要素”清单中,“模型”应该属于环境列,而不是依赖列。依赖项有版本和变更日志。而环境是你的软件所表现出的行为的先决条件。更换了环境,你积累的每一个绿色对勾(测试通过)都只是一个你已不再运行的系统的证据。
不匹配的两个方向,以及为什么两者都有害
团队通常会在两个方向上划分层级,每个方向都有其独特的失败特征。
在廉价模型上测试,在昂贵模型上上线。 这是最常见的一种:为了控制支出,CI、本地开发和合并前的评估(evals)都在小模型上运行;而生产环境使用 frontier 模型,因为用户理应得到最好的。这种失败模式很微妙,因为生产环境的模型更好 —— 所以团队假设这种差距只会对他们有利。但事实并非如此,原因有二。
首先,“更好”在行为表现上并非单调递增。Frontier 推理模型会更字面地理解指令,更轻易地拒绝回答,并且会暴露出小模型可能会忽略的边缘情况。一个因为廉价模型忽略了歧义而奏效的提示词,在昂贵模型对其言听计从时,表现可能会完全不同。其次,你的评估完全不再衡量生产环境。廉价层级上的绿色评估结果只说明廉价层级仍然工作。但并没有人部署廉价层级。
在昂贵模型上测试,在廉价模型上上线。 镜像情况:提示词是针对 frontier 模型开发和演示的,然后为了节省成本,生产环境将大部分流量导向小模型。这里的失败是能力断崖(capability cliff),而不是行为漂移。小模型对工具的调用不足 —— 它们可以很好地执行工具调用,但无法识别自己何时需要调用。演示之所以成功,是因为 frontier 模型用推理弥补了模糊的工具描述;而小模型需要描述非常明确,由于在发布前没有人运行过真实的生产路径,所以没人发现这一点。
这两个方向都有一个共同的根源:层级划分是出于财务直觉(“不要浪费 token”),而从未从工程直觉(“这会对我的测试有效性产生什么影响?”)的角度重新审视。
你的评估套件在你并不运行的模型上亮起了绿灯
这个问题代价最高昂的版本隐藏在评估流水线(evaluation pipelines)中。团队在评估上投入巨大 —— 精选的数据集、针对旧 bug 的回归案例、拦截质量阈值以下部署的 CI 门禁。然后,为了让流水线的成本在可承受范围内,他们将所有这些都指向了廉价层级。
想想这个门禁现在在证明什么。一个更改了提示词的拉取请求(PR)在小模型上进行测试。如果通过了,它就会被合并,更改后的提示词进入生产环境 —— 而在那里,是由一个不同的模型来解释它。评估门禁已经变成了一种仪式:它产生了一种回归覆盖的错觉,而测量的却是一个并不承载流量的系统。更糟糕的是,它会产生误导。
- https://12factor.net/dev-prod-parity
- https://cloud.google.com/transform/from-the-twelve-to-sixteen-factor-app
- https://arxiv.org/html/2512.01420v1
- https://hamel.dev/blog/posts/evals-faq/
- https://www.braintrust.dev/articles/llm-evaluation-guide
- https://mikulskibartosz.name/shadow-deployment-vs-canary-release
- https://towardsdatascience.com/how-to-choose-between-small-and-frontier-models/
- https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/migrating-to-gpt-5-x-without-breaking-gpt-4-a-practical-backward-compatible-play/4522936
