关于 ChatGPT Web 降智的一条 91 人投票的经验性调研推论

*此推论仅适用于 Chat 模式，不适用于 Work 模式以及 Codex。

先交代一下背景。

网页版 ChatGPT 对话的事件流和响应中会带有一些跟模型相关的信息。

比如说在事件流中，

可以看到有一些字段，例如：

server_ste_metadata 下面的 model_slug，

resolved_model_slug，

v.message.metadata 下面的 model_slug，

default_model_slug，

以及响应中也有相似的字段：

这些字段值都指向某一个具体的模型名称。

虽然这些信息属于内部字段，OpenAI 对它们没有正式公开的官方定义，

但根据命名和经验推断，我们大概能得出一些信息：

比如 default_model_slug 大概率是默认模型的标识，

比如 resolved_model_slug 大概率是系统最终解析后实际采用的模型标识，

比如 server_ste_metadata.model_slug 大概率是某个服务端子模块记录下来的模型标识，

比如 assistant.metadata.model_slug （也就是 v.message.metadata.model_slug）大概率是助手消息被标记的模型标识。

又但是由于官方没有公开它们的含义，所以没有人能 100% 说明它们代表什么。

正常使用的情况下，这些字段的值应当一致。

那么问题来了，有的时候它就会出现不一致的情况。

于是基于 7 月份对社区案例的观察，以及我自己账号的一些实测，我个人对这些模型标识的置信度做了一下排序。

第一层级，显示路由层：

resolved_model_slug 、 server_ste_metadata.model_slug。

这两个光看名字就感觉更靠谱一些，一个是解析到的模型，一个是服务端返回的模型。

server_ste_metadata.model_slug 相对特殊一些，这个字段只有在实时的事件流里面能够找得到，而在响应中是没有的。也就意味着，只有当前跟模型对话时，才能看到这个字段。事后回去再看已经完成的对话，是找不到这个字段的。

第二层级，模型标签层：

assistant.metadata.model_slug 以及一些在网页元素中能看到的标记。

这个感觉上就是最终助手被声明的，或者说写在助手脸上的模型。

存在着一点我说我是什么的意味，所以虽然有明确的标识返回，但优先级不如上一层级。

第三层级，默认模型层：

也就是 default_model_slug。

这个个人观察下来，定义为不可信，因为总是出现在最前面，选择什么模型它就是什么模型。

看起来好像是表示着用户请求的模型是什么。

于是按照这个逻辑，8 月份的时候，我做了一个浏览器扩展，也就是这个：

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

我的帖子已经打上 开源推广 标签： 是
我的开源项目完整开源，无未开源部分： 是
我的开源项目已链接认可 LINUX DO 社区： 是
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

最近怒充 …

实际这个扩展背后的判断逻辑就是上面说的置信度，

捕获到第一层级优先，第二层级兜底，第三层级不参与判断。

但是 9 月中旬发现一些反馈的案例，开始出现一种现象。

有的人，比如我自己，表现一直还挺正常的，跟之前没什么变化，

实时请求的响应来源能正常捕获到 resolved_model_slug + server_ste_metadata.model_slug，而且表现一致。

但有的人，resolved_model_slug 这个响应字段消失了，同时反馈模型降智，并且还不止一起。

起初还以为是接口调整，正在灰度。但时间过去挺久了，我自己的依旧没有改变。

于是有理由推测，这个东西是降智的表现之一。

所以上周在 X 上做了个投票，有 91 个人参与，最近出来了调研的结果。

四选项对比的差异看起来不明显，转换一下，分成有这个字段和没有这个字段两组：

结论就是：

存在 resolved_model_slug 字段的朋友，80% 的比例没有发生降智。

而 resolved_model_slug 字段消失的朋友，77.8% 的比例发生了降智。

由此推断，resolved_model_slug 字段是否消失跟模型是否发生降智存在比较强的相关性。

并且在上一篇帖子的评论区，也有很多佬友的跟帖支持了这一说法。

所以，把这个结论分享给大家。

给各位做一个判断参考，也期待有大佬能在这个基础上得出更准确的结论。

考虑到上面调研结果虽然倾向表现很明显，但是毕竟不是 100%，依旧有 20% 朋友的 resolved_model_slug 字段虽然消失，却并没有发生降智，但又没有办法保证每个人对于降智的判断是准确的，所以扩展插件上新增了一个标签，叫做”疑似降级“。

出现这个黄色的信号就表示有比较高的可能性是发生降智了。

另外还有一点需要注意一下，单纯的图片生成本来就是没有 resolved_model_slug 字段的，但为了保持扩展的稳定性，没有单独针对生图的情况进行识别并排除。

所以如果你使用这个扩展的话，在通过网页聊天生成图片的时候遇到这个黄色警示，可以自行判断一下，如果 GPT-image-2.5 图片生成结果表现正常，那就没有问题。

再补充下说 Work 模式。

Work 模式无法通过以上的方法进行辨别。

因为 Work 模式根本就没有 resolved_model_slug 、server_ste_metadata.model_slug 这些字段。

Work 模式除了开始的请求默认模型标识之外，只有 metadata.model_slug 。

所以不要使用上述浏览器扩展去分析网页端的 Work 模式。

上一篇帖子我也有分析，实际上降级的逻辑大多是先命中账号，然后基于账号进行风控。

所以单独判断网页版的 Work 模式是否发生降智这件事本身意义不大，因为它基本上跟 Codex 是一致的，如果要排查，直接按照 Codex 的排查方案去排查就可以了。

扩展上也添加了提示，如果识别到 -wm（work mode）后缀的模型会显示为白色的”无法判断“提示。

另外，原则上大部分网页版和 Codex 的降智命中的应该都是”疑似账号共享“这一个问题，解决方案就是表现出这个账号只有你一个人在使用。同时依旧是建议先把活跃会话的设备全部踢掉，然后重登。

踢设备这个方案就类似于”遇事不决先重启“，是个万应锭。一些其他的莫名其妙的 bug，官方文档也是推荐先做这个自助操作。

寄了但又没有完全寄。
总之就是正常使用 Codex 的时候，突然任务中断。
[image]
更换设备以后，依旧是同样的问题。
[image]
继而又发现所有设备网页版都挂了。
[image]
排查了一下代理节点发现没问题，同一个节点的北美豆包能正常访问。
然后又刷了 OpenAI Status 和社交网络，发现风平浪静。
退出账号重登，发现还是老样子。退出账号，切换了一个免…