你敢信？82%的LLM应用迁移，是在旧模型已经关停后才动手的——不管项目大小，有没有过迁移经验，哪怕用了模型抽象层也没用。
这项研究扒了GitHub上2024到2026年的代码提交，从17703个非分叉仓库的22555次提交里，匹配到官方退役事件的有5139次。还找了两个独立程序员校验300个样本，一致性很高（kappa值0.89-0.95），最后给所有估算加权后得到了这个结论。
谁的模型先“退休”？通知时长差得远
三个头部厂商的退役通知时长，直接影响了开发者的反应时间。Anthropic给60-114天的通知，对应89%的迁移都是在模型关停后才做；OpenAI给的是一年，结果只有13%的迁移是事后补救。
更有意思的是，通知时长每翻一倍，开发者在模型关停后才迁移的概率就降了四分之三。说白了，给的时间越长，大家越有精力提前改代码，不用等到线上崩了才救火。
迁移有多麻烦？代码里藏着细节
94%的迁移应用，都是硬编码了旧模型的ID——这简直是埋了个定时炸弹。一旦模型退役，不用想，代码直接报错。
迁移的工作量也差得远：如果只是改提示词，平均加6行代码就搞定；但如果是用了微调模型，要改近700行。还有个意外发现：只有8%的迁移是换了大模型厂商，大部分还是换同一家的其他模型——换供应商比换版本，麻烦太多了。
开发者的痛点，其实是行业的盲点
这项研究给出的核心结论，对三个方向都有用：一是厂商的退役政策，像OpenAI给一年通知这种，确实能大幅降低事后迁移的比例；二是LLM产品的依赖风险评估，开发者不能只看模型效果，得把“模型会突然退役”算进去；三是行业需要更好的迁移工具，帮开发者少写冗余代码。
我自己用LLM做小工具时，也踩过硬编码模型ID的坑，当时是Anthropic的模型突然退役，临时改了半天才搞定。现在想想，要是当时把模型ID做成配置项，就不会这么慌了。
如果所有LLM应用都提前把模型ID改成可配置的，能不能把“关停后再迁移”的比例从82%压到10%以下？
素材来源：arXiv (LLM/多模态新论文) · AI情报、大模型、AI应用落地、AI政策与监管
查看报道原文
发表第一条评论吧