5 篇博文 含有标签「migration」

第一次痛苦的智能体记忆（agent-memory）迁移总是教会我们同一个教训：存在两个模式（schema），而你只迁移了其中一个。存储层没问题 —— 每一行都已重写，每个键（key）都是新的形态，回填（backfill）作业也记录了成功。但智能体还是坏了。它继续向 user.preferences.theme 写入，却检索不到任何内容，然后从上下文中煞有介事地合成一个默认值，就好像这个键从未存在过一样。迁移操作手册显示一切正常。用户却报告记忆过时。

这种不对称是结构性的。一个依赖于重命名列的传统服务会收到硬错误，然后你进行修复。而一个依赖于重命名记忆键的智能体则会遇到软缺失，并围绕它进行胡编乱造。模式存在于两个地方 —— 你的存储和模型的上下文 —— 而你只能通过 SQL 脚本迁移其中的一个。

Protobuf 在二十年前通过规范化“仅限增加”的准则解决了这类问题的一个变体：字段是永恒的，数字是永恒的，网络类型永远不变，删除被弃用（deprecation）所取代。这一准则是智能体记忆的一个良好起点，但有一个额外的约束使其变得更加困难。Protobuf 接收者在设计上会忽略未知字段。智能体则不会。

当你的团队决定从 Claude 3.5 Sonnet 升级到 Claude 3.7，或者从 OpenAI 迁移到自托管的 Llama 部署时，直觉通常是将其视为一次库升级：更改 API 密钥，更新模型名称字符串，进行快速的健全性检查，然后发布。这种直觉是错误的，那些遵循这一做法的团队会在第二周的凌晨 2 点发现原因——当时客服代理开始以完全不同的格式生成响应：技术上有效，语义上却是灾难性的。

切换 LLM 提供商或模型版本在结构上与数据库模式迁移（database schema migration）完全相同。两者都涉及更改系统中应用其余部分具有隐式契约的行为。两者可能在第一天看起来没问题，但在第十天发生灾难性的失败。两者都需要双重运行（dual-running）、金丝雀发布（canary deployment）、回滚标准和迁移方案（migration playbook）——而不是修改配置后发一条 Slack 消息。

你接手了一个基于 GPT-4-turbo 构建的 AI 功能。该模型即将被弃用。你的经理希望通过切换到更新、更廉价的模型来降低成本。你快速跑了一遍测试，指标看起来还过得去，于是就上线了——结果一周后，核心用例的准确率下降了 22%。支持工单不断攀升。你现在面对的是一场危机式迁移，而非有计划的操作。

这就是模型可移植性税：每当你将应用逻辑与某个特定基础模型紧耦合时，就会累积的隐性工程成本。每个团队都在为此买单，大多数人直到账单到来时才意识到数字有多大。

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

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

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

每一个交付 LLM 驱动功能的团队最终都会进行同样的对话：“如果我们需要更换供应商怎么办？”标准的回答——“我们只需要换一下 API 密钥”——揭示了对耦合实际存在位置的危险误解。在实践中，尝试进行供应商迁移的团队会发现，API 端点是他们最不需要担心的问题。真正的锁定隐藏在七个不同的耦合点中，每一个都能将一次“快速更换”变成一个耗时一个季度的项目。

迁移费用通常会消耗原始开发时间的 20–50%。那些将模型切换视为即插即用的企业团队，往往在面对损坏的输出、激增的 Token 成本以及需要数周才能诊断出的推理质量变化时束手无策。在需要迁移之前，了解这些耦合点在哪里，是受控过渡与紧急应对之间的本质区别。