(这是"AI 可见性测量"系列第五篇。前情:我开源了一套测量品牌在 AI 引擎里可见性的工具(Python + Java 两版),并在第三篇里记录了六次"如果全自动就翻车、被人审拦下来"的瞬间。这一篇,是第七、八、九次拦截——以及一个更罕见的发现:我亲眼看着一个引擎换了一代模型,行为就从"凭记忆回答"变成了"真联网检索"。全过程 14 天。)
10 月 31 日:它不联网
测量的方法之一,是给每个引擎挂上官方的联网搜索工具(web_search),然后问它"现在最好的扫地机是什么"。
智谱的 glm-4-flash 给了我一份 2023 年的答案:开口就是 "As of my last update",头名推荐 iRobot Roomba s9+——一台 2022 年的机器。响应里也没有任何搜索结果字段。
我写了个探针脚本验证,结论:这个模型不执行联网工具,它在用训练记忆答题。于是我把它标记为"记忆层"引擎,和真联网的 deepseek"搜索层"分开——这套"双层模型"后来成了报告的方法论框架。
11 月 2 日:它联网了
我给智谱账户充了值,把引擎升到新出的 glm-5.3-flash,重新跑探针。
这次它返回了搜索引用,回答的是当前在售的型号。grounded: true。
同一个厂商,同一个工具参数,间隔 14 天,两代模型——一个从记忆答题,一个真联网。 我把引擎的层级标签从 memory 翻成了 search,并且在配置里注释了翻转的原因和两次探针的日期。
这件事本身平平无奇(新模型能力更强,理所应当)。有意思的是接下来三个"差点得出错误结论"的瞬间。
拦截七:引擎配置的 bug,伪装成了引擎行为
升级当天,智谱接口连续返回 400。当时最省事的解释是:"新模型不支持这个工具参数"——如果就这么写了,这代模型就会被错标成"不支持联网"。
真因藏在框架深处:Spring Boot 把 YAML 里的列表绑定进 Map<String, Object> 时,会把 list 变成索引 map——[{type:"web_search"}] 变成了 {"0":{type:"web_search"}}。引擎收到的 tools 参数是畸形的,400 是它应得的。
Python 版没这个问题(Python 的 YAML 库天然出 list),所以只有 Java 版中招。修复 + 一个真实走 Spring Binder 的回归测试,提交。
教训:测量系统里,"引擎不支持 X" 和 "你的请求是坏的" 是同一现象的两种解释,不验证就分不清。
拦截八:模型名陷阱
修好绑定,换上媒体广泛报道的 "deepseek-v4.1-flash"——400。API 实际接受的名字是 deepseek-flash。
搜索引擎告诉你的模型名,不如一次真实调用。我们所有引擎的模型名现在都带着"验证日期"注释。
拦截九:审查的对象不是代码,是归因
修复提交之后,我在代码注释里写了一句:"glm-4-flash 的记忆层判定是在畸形请求下测出的,存疑。"——十分钟后再看,这句话是错的。
畸形请求 bug 只存在于 Java 版,而 10 月 31 日的探针是 Python 版跑的,请求体从来是正确的。glm-4-flash 是在收到合法请求的情况下,依然选择用记忆回答。
于是结论反转成更干净的形式:
glm-4-flash + 正确请求 → 记忆层(10-31 验证)
glm-5.3-flash + 正确请求 → 搜索层(11-02 验证)
层翻转 = 模型代际效应,与 bug 无关
我把那句错误注释撤掉、写了修正 commit。这次拦截最微妙:代码没错,测试没错,错的是我对"谁受 bug 影响"的推断。 人审拦的不只是坏代码,更多时候是坏归因。
这件事为什么值得写
- AI 的演进速度第一次变成我个人数据里的一格。 新闻里"模型又升级了"是标题;在一个带日期的测量系统里,它是一条可以复现的时间线:某引擎的记忆层,存活了 14 天。
- "记忆层"可能是个正在灭绝的物种。 新一代模型普遍真联网,意味着"训练语料里的品牌存量"这个维度正在被"实时检索"吞噬。做 AI 可见性的人,要么跟上这个变化,要么测的是上个时代。
- 九次拦截,没有一次是 AI 自己拦下来的。 自我评估的 agent 能发现畸形请求导致的 400,但不会发现"归因错了"——归因审查需要知道 Python 版上周做过什么,这个上下文只在我这里。
给做 AI 工程的朋友三条
- 任何"模型行为"结论都要带三要素:哪个模型、哪个日期、哪个请求体。 缺一个,结论就不可复现。(我们自己的 JSONL 记录还没存模型名,已列进 v1.1——写此文时我检查了一遍,确实没有,别学我。)
- 引擎/模型版本要作为测量变量被记录,而不是当环境常量。
- 跨实现的交叉验证是归因错误的解药。 Python 版的存在,让"bug 影响范围"可以被精确切分。
工具开源(双语言,数据格式互通):geo-visibility(Python) · geo-visibility-mcp(Java/Spring MCP server)。想聊测量方法论的,评论区见。
声明:项目使用公开 API 与公开信息,不涉及本人雇主的数据与系统。
