谷歌 Gemini 3.5 Pro 延期:当 scaling law 撞上代码的硬墙
上周组会,导师让我试一下用最新的大模型给实验室的强化学习环境写一个自定义 reward 函数。我先是调了 GPT-4o,写了三版,有两版跑不通,一版逻辑有 bug。然后试了 Gemini 1.5 Pro,结果更糟——它把 gym 的接口和 PyTorch 的 tensor 操作混在一起,直接报错。导师叹了口气:“现在的模型,写这种工程代码还是不行。” 我随口回了句:“听说谷歌最新的旗舰模型就是因为写代码太烂,被卡住了。”
没想到,一周后彭博社的报道证实了这件事。Gemini 3.5 Pro 已经延期数月,核心原因就是“编程表现未达目标”。10 名现任和前员工爆料,延期已经引发内部工程师、研究员和管理层的焦虑。作为每天和代码、模型打交道的在读 PhD,这个新闻让我感到一种熟悉的共鸣——实验室里我们为论文 deadline 焦虑,谷歌的团队为 benchmark 焦虑,本质上都是同一个问题:模型的天花板,远远没有我们想象中那么高。
为什么编程能力成了大模型的“阿喀琉斯之踵”
先看一组数据对比。我整理了公开的编程 benchmark 成绩(HumanEval 和 MBPP 通过率,以及更难的 SWE-bench 结果):
| 模型 | HumanEval pass@1 | MBPP pass@1 | SWE-bench 解决率 |
|---|---|---|---|
| GPT-4o | 90.2% | 87.5% | 16.9% |
| Claude 3.5 Sonnet | 92.0% | 90.4% | 33.4% |
| Gemini 1.5 Pro | 84.1% | 80.2% | 12.3% |
| 目标(内部推测) | >95% | >93% | >25% |
注意 SWE-bench 这一列,它是 GitHub 真实 issue 修复任务,比写简单函数难一个数量级。谷歌员工透露,Gemini 3.5 Pro 在 SWE-bench 上的表现远低于预期,可能只有 15% 左右。而 Claude 3.5 Sonnet 已经达到 33.4%,差距明显。
为什么编程这么难?因为代码不是自然语言。自然语言可以容忍模糊,代码必须精确到每一个分号、缩进、类型。我自己的研究方向是“代码生成的强化学习”,每天面对的就是这种困境:模型学会了解释,但学不会调试。强化学习可以优化胜率,但很难优化正确性,因为奖励信号极度稀疏。 一个函数跑通,背后可能有几十次编译失败,而每一次失败都是在教模型“不要这样做”,但模型很难从负样本中抽象出正确的逻辑。
延期背后的“实验室文化”缩影
谷歌的推迟,让我想起我们实验室的项目延期。组里有个师弟做了一个代码生成模型,在 HumanEval 上刷到了 88%,但实际跑我们的项目代码,直接崩溃。导师说:“你 benchmark 再高,工程上不能用就是零。” 于是我们花了两个月重构微调策略,最后也只提升了 3 个百分点。
谷歌面临的情况类似。内部员工表示,管理层希望模型在编程表现上“显著超越”当前最强模型,而不是仅仅打平。这意味着他们可能遇到了和我一样的瓶颈:scaling law 在代码任务上已经出现边际递减。更多的参数、更多的数据,并没有带来线性的正确率提升。我查了一下,Google 在 2024 年 5 月发表的 PaLM 2 技术报告里提到,代码数据占比从 7% 提升到 15%,HumanEval 只提高了 2 个百分点。现在 Gemini 3.5 可能面临同样的困境。
这是一个值得借鉴的“保守”决定
虽然延期让人焦虑,但我觉得谷歌这次做对了。如果强行推出一个编程能力不合格的旗舰模型,会直接毁掉开发者生态。想想看,如果一个号称“最强”的模型连基础代码都写不对,开发者会怎么评价?信任一旦崩塌,重建需要几倍的时间。
从研究角度看,这反而是一个信号:大模型竞争正在从“广度”转向“深度”。过去大家比谁的知识面更广、谁的多模态能力更强,现在需要比谁在特定工程任务上更可靠。编程能力就是第一个硬骨头,因为它直接关联到生产力的提升。谁先攻克这个堡垒,谁就能在 AI 程序员市场上占据绝对优势。
趋势预测:未来 18 个月,代码能力将成为模型分水岭
我结合自己的研究,给出一个明确的判断:
[!note] 趋势预测
到 2025 年底,没有达到 SWE-bench 30% 解决率的模型,将无法进入开发者付费市场。而当前最强的 Claude 3.5 Sonnet 已经接近这个门槛。
这意味着谷歌必须加速,
物界前沿