2 篇博文 含有标签「shadow-testing」

每一个交付过由大模型驱动的产品的团队都经历过同样的时刻：一个新的基础模型发布了，它拥有更好的基准测试结果、更低的成本，或者两者兼而有之——这时有人会问：“我们能直接把它换掉吗？”答案在预发布环境中总是肯定的，但在生产环境中往往是灾难性的。

“在新模型上能运行”与“在新模型上表现正确”之间的差距就是生产事故多发地。模型迁移之所以失败，不是因为新模型更差，而是因为迁移过程假设了本不存在的行为等效性。不同供应商的提示词格式规范各不相同。不同系列模型对系统提示词（System prompt）的解读也存在差异。旧模型能够优雅处理的边缘情况——通过你从未记录过的习得性怪癖——会变成回归问题暴露出来，而你的评估套件（eval suite）在设计之初并未考虑到这些。

每一个运行基于 LLM 的功能超过六个月的团队都曾面临过同样的时刻：更出色的模型发布了，当前的供应商涨价了，或者你依赖的模型收到了 90 天后停用的通知。你需要更换正在运行的生产系统底层的基座模型。大多数团队将其视为一次配置更改 —— 更新模型 ID，重新运行评估测试集，然后发布。接着，他们会花费接下来的两周时间来处理评估从未捕捉到的回归问题。

模型迁移问题与传统的软件升级有着本质的不同。当你更换数据库版本时，查询语义是被保留的。当你更换基座模型时，一切都会改变：输出分布会偏移，边缘案例的行为会分歧，而那些学会了依赖特定模型特性的下游系统会默默崩溃。这些故障模式是分布式的，而非二进制的，这意味着它们隐藏在评估测试集覆盖率最低的长尾部分。