DeepSeek-V4-Pro 更新​

DeepSeek-V4-Pro 更新​

模型版本换了，API没动，但我线上出了问题

8月13日凌晨DeepSeek V4 Pro上线，模型版本更新为deepseek-v4-pro-0813。API调用方式完全不变，我还是传deepseek-v4-pro，结果下午三点线上监控报了个警。

我不是那种每次模型更新就慌的人。V2到V3那次我没特意改代码，V3到V4那次也是。这次我甚至没打算看release note——API没变，模型名没变，理论上不该出问题。

事实证明我想多了。

下午三点十二分，监控面板上我的知识库问答系统的错误率从平时的0.3%跳到了2.1%。报警规则是我上个月设的，超过1.5%就触发。我第一反应是数据库连接池爆了，之前有过一次类似的情况，表现差不多。

查了五分钟日志，错误集中在一个字段。我让模型输出的JSON里有个confidence字段，平时返回数字，比如0.87、0.92。V4 Pro上线后，一部分请求返回的是字符串，high、medium这种。反序列化直接抛异常。

有意思的是，不是所有请求都这样。80%的case正常返回数字，20%变成了字符串。同一个prompt模板，同一个参数设置，输出格式就是不一致。

我当时判断，这是V4 Pro增强Agent能力带来的副作用。release note里提到了Agent增强，但没说具体改了什么。我的prompt里有step-by-step reasoning的指令，V4 Pro可能把这个当成Agent任务来处理，导致输出格式漂移。

当时有两个方案。方案A是加容错，confidence字段同时接受数字和字符串。方案B是改prompt，把输出JSON格式这个指令写得更死。

我选了方案A，因为快，半小时能上线。事后看选错了。

方案A上线后错误率降到0.5%，但没过两天又报警了。这次不是confidence字段，是另一个字段summary的长度突然变长。我数据库里那个字段设的是varchar(500)，V4 Pro输出的summary有几次超过了500字符。

我又加了一次处理，截断超长内容。但心里开始犯嘀咕，这玩意儿没完没了。每次模型更新都会有新的字段漂移，靠容错兜底迟早兜不住。

周三晚上我花了两个小时搭了个回归测试框架。思路很简单：维护一组固定的prompt和对应的预期输出schema，每次模型版本更新后，自动跑一遍这组prompt，对比输出是否匹配schema。不匹配的就标红，人工review。

框架搭好后，我拿deepseek-v4-pro-0813版本跑了一遍，测试集是80个case，覆盖了我线上所有主要的prompt模板。结果：12个case输出格式有变化，占15%。

这12个case里，6个是JSON字段类型变了——数字变字符串、数组变对象；4个是字段长度超出预期；2个是新增了没在schema里的字段。

我把这些case全部修复后重新部署，现在跑了四天，错误率稳定在0.2%，比之前还低。

说实话，这件事让我对API不变等于兼容这个假设彻底死心了。模型厂商更新版本时，API签名确实没变，但模型行为变了。这不是bug，是特性。DeepSeek V4 Pro的定价确实便宜，API成本只有GPT-5.4 Pro的1/8，原定价的1/4，但我现在觉得，便宜的钱省下来了，贵的是维护成本。

我的回归测试框架现在每周跑一次，不只在模型更新时跑。因为DeepSeek的模型可能随时更新，就像8月13日那次，凌晨更新，我早上还在睡。

框架的核心逻辑是固定prompt集合、调用API、解析输出、与预期schema比对、记录差异、输出报告。我用Python配合pytest写的，跑80个case大概4分钟。每次有差异，框架生成一个diff报告，标出哪些字段变了、怎么变的。schema定义部分我用的jsonschema库，挺方便的。

这个框架我还没整理到能开放的程度，主要是schema定义依赖具体业务，通用性不强。但思路是通的，有同样困扰的人可以参考。

我还有个疑问想问大家，你们有没有遇到过模型版本更新后输出格式漂移的情况？还是说你们的调用方式跟我不同，没碰到过？如果碰到过，你们是怎么处理的——加容错、改prompt，还是像我一样搭回归测试？我想知道有没有更优雅的方案，毕竟现在这套框架每周要跑一次，也挺耗资源的。

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。