背景
我负责的一个数据平台，核心链路之一是用大模型对法律文书（案件公告、裁定书等）做结构化解析——从非标准格式的文书中抽出「案件信息」等数据字段，供下游检索和业务系统使用。
解析引擎用的是 Moonshot（Kimi）v1 系列接口，走的是商业合同，已稳定运行约两年。链路上还有一套按 token 长度动态选档的机制：短文书走 8K，长文书升到 32K / 128K，返回被截断时自动升级模型重试。
事故
2026-08-31，Moonshot v1 系列模型下线。值得注意的是下线的方式：官方渠道发文，没有邮件，也没有合同层面的正式通知。对依赖它的系统来说，结果就是文书解析开始静默失败——而我们在 4 天后的日常监测中才发现，此时存量 2000+ 条文书解析失败。
响应是双线并行的：商务线与厂商沟通合同事宜，技术线紧急适配新模型 kimi-k2.6。
选型：三个候选，一道排除题
v1 下线时，Moonshot 线上可用的接替模型有三个：
| 候选 | 评估结论 |
|---|---|
kimi-k2.7-code | 编码专用模型，与文书解析场景不匹配，直接排除 |
kimi-k3 | 通用能力最强，但在我们的解析场景实测中，正确率相比 k2.6 并没有明显提升，价格却更贵 |
kimi-k2.6 | 解析正确率与 k3 实测持平，价格更低 |
最终选择 kimi-k2.6。这里的判断标准值得单独说：结构化提取任务选模型，以场景实测正确率为准，而不是模型榜单上的能力排名——不为用不上的能力溢价买单。
迁移：不是改一行模型名
动手前的预期是「换个 model 字符串」。实际提交是 4 个文件、93 行变更，踩了三层完全不同性质的坑：
第一层：参数语义变了。 max_tokens 更名为 max_completion_tokens；需要显式关闭思维链输出（thinking: disabled），并禁用工具选择（避免过多消耗无效 token）；temperature / top_p 在新模型上是否还有意义也要重新评估。
第二层：输出行为漂移。这是最隐蔽的一层。即使显式指定了 response_format: json_object，kimi-k2.6 仍会返回被 Markdown 代码块包裹的内容，甚至混入说明性文字。旧代码直接解析原始字符串，在新模型上稳定抛异常。
第三层：资源档位重排。v1 时代 8K / 32K / 128K 三档动态选档的逻辑，在只有一个目标模型的世界里整体失效。上下文预算重新计算，maxTokens 从 50000 调整到 32768——这一项如果沿用旧值，请求会直接被服务端拒绝。
解析层加固：永远不要相信 LLM 的输出格式
针对第二层，解析入口加了一道防线：
- 剥离首尾的 Markdown 代码块标记；
- 剥离后仍不以大括号或方括号开头时，截取第一个大括号（或方括号）到最后一个之间的内容兜底；
- 解析成功才落库，且落库的是重新序列化的规范化 JSON——保证下游拿到的永远是干净数据。
数据修复
2000+ 条失败文书通过人工筛选、批量重新提取完成修复。得益于落库前的解析加固，重跑写入的数据与新解析的数据格式完全一致，下游无感知。
结果
发现问题的当天，完成了模型替换、测试与上线。最终结果有三点：
- 解析成功率不降反升——新模型的能力确实强于 v1；
- 成本几乎持平——v1 的商业合同包含数据保护条款、定价更高；k2.6 单价虽更贵，但对比原商业合同总价基本持平；
- 数据合规成为新的跟进项——当前走公开 API，其数据使用条款与商业合同不同，是否补签商业合同正与厂商商务沟通中。
经验
- 供应商锁定是商务 + 技术的双重风险。技术上，把模型调用收敛在一个 service 层——这次只改 4 个文件，就是因为这条线一直干净；商务上，合同里要写清模型生命周期通知义务与过渡期条款，这次的教训是「发文即下线」。
- 发现比修复更贵。修复、测试、上线只用了 2 小时，发现问题却用了四天。LLM 链路必须有失败率监控与告警，不能依赖日常巡检——这是本文最大的教训，没有之一。
- API 兼容 ≠ 行为兼容。参数名可以对着文档改，输出格式漂移只能靠真实调用暴露。迁移第一步应该是拿生产样本做冒烟验证，而不是全量切换。
- 失败任务要可重放。不必追求全自动，但「解析失败不落库、落库即可重放」的设计，让 2000+ 条文书的修复成为一次批量操作而不是一场灾难。
- 数据合规是独立工作流。公开 API 与商业合同在数据使用上的差异，要与技术迁移分开评估——先保业务连续，合规条款跟进，但必须跟进。
遗留
v1 时代的动态选档逻辑目前整段注释着，等后续补齐多档位模型时恢复或重写；商业合同的补签在商务沟通中。迁移完成不等于债还清了，写下来比忘掉强。