2 篇博文 含有标签「model-migration」

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

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

每个生产环境中的 LLM 系统都会面临模型迁移。供应商发布了新版本。你需要降低成本。竞争对手提供了更好的延迟。监管要求需要更换供应商。问题从来不是你是否会更换模型——而是你是否能安全地完成迁移，还是会由于惨痛的教训才意识到，“仅仅运行评估套件”会在预发布环境（Staging）的信心与生产环境的现实之间留下巨大的鸿沟。

大多数团队将模型迁移视为库升级：更换依赖项、运行测试、然后发布。这对于确定性软件有效。但对于概率性系统，这种方式会遭遇灾难性的失败。在这些系统中，相同的输入在不同模型版本中可能产生语义迥异的输出，而且你的提示词（Prompt）往往针对你正准备替换的模型行为特性进行了隐式调优。