Jeff Dean 离职谷歌后首谈:Gemini Coding 短板与新公司 Discovery Loop
Jeff Dean 在斯坦福访谈中首度公开反思 TensorFlow 两大失误、Gemini 早期 Coding 短板,…
在斯坦福 2026 Frontier & Pioneer Symposium 上,离开谷歌后的 Jeff Dean 首次接受长访谈,坦率回顾了 Gemini 的开发得失、TensorFlow 的设计遗憾,并首次系统介绍了自己新创立的 Discovery Loop 公司所押注的方向。以下按议题整理核心观点。
Gemini 早期 Coding 能力为何掉队
Jeff Dean 回忆,Gemini 是 Google 内部 DeepMind、Google Brain 等多支团队研究成果汇合的产物。当时他与 Oriol Vinyals 联合牵头,刻意从一开始就让模型具备多模态能力,包含文本、代码、图像、视频、音频,甚至在训练数据中放入少量 LiDAR 数据,让模型「感知」到这种模态的存在。
他承认,多模态一体化是正确决定,但「把 Coding 能力做到惊艳」这件事被重视得偏晚。Dean 认为,Coding 是衡量模型推理能力的关键指标——写代码天然要求一步步分解问题、逐个解决子问题,模型 Coding 能力提升后,往往会迁移到大量非 Coding 任务上,这也成为 Gemini 后续追赶的重点方向。
TensorFlow 的两个「明显失误」
回看 TensorFlow 的设计,Jeff Dean 点名了两个今天会重新考虑的决策:
- 未在初期引入 Eager Execution:这种动态执行模式后来在 PyTorch 和 JAX 中变得流行,TensorFlow 后续才补上,但 Dean 认为一开始就提供这一抽象对用户体验更友好。
contrib子目录的设计:当初为方便外部贡献者,开设了contrib收纳各类辅助库和实现,结果演变成「同一件事可能有十种做法」,让开发者无所适从。Dean 表示,若重来一次,会让核心保持精简,把这些扩展放在核心之外的外部库中。
他同时强调,TensorFlow 整体上帮助了大量开发者真正入门机器学习,这一历史价值不应被抹杀。
为何离开谷歌:10 人小团队的极致聚焦
谈及创业原因,Jeff Dean 表示自己仍然感激在谷歌 27 年的经历与资源,但他指出,当前的云基础设施让一个很小的团队也能直接调用大规模机器学习算力,无需自建底层。Discovery Loop 团队仅约 10 人,集中于 Palo Alto 一处办公室,目标高度一致——专注于科学与工程自动化。
这种「轻微干扰被绕过去」的状态,被 Dean 视为小公司最令人兴奋的地方。他坦言这件事留在谷歌内部或许也能做,但大公司的资源噪声难以避免。
新公司 Discovery Loop:让一个模型拥有「20 个博士」
Discovery Loop 的核心愿景是把机器学习、科学与工程自动化,缩短科学发现的迭代周期。具体路线包括:
- 以模型自动化覆盖模型开发的整套环节:训练数据选择、Eval 体系设计、模型架构选择等,让每个环节都形成持续优化的 Loop。
- 让单个模型具备多个领域接近 PhD 级别的能力,能够识别复杂问题中的关键子问题,再调度 Agent / Multi-Agent 系统并行求解。
- 通过工具链把一轮实验的耗时从过去的一天甚至一周压缩到一分钟或一小时,并行运行成千上万次实验,从反馈中筛选下一批实验方向。
Dean 强调,团队希望同时提升「实验速度」与「实验质量」,如果这两件事持续推进,结果将「令人惊叹」。
递归自我改进与网络安全双刃剑
Jeff Dean 认为,用 ML 改进 ML 已有多年实践,例如联合创始人 Quoc Le 早年的 Neural Architecture Search,以及由此衍生的 Evolved Transformer,通过进化算法重组 Transformer 组件,最终架构效率比标准 Transformer 高约 30%。Discovery Loop 希望把这种思路扩展到模型开发的全链路。
在网络安全方面,他直言:当前的模型已经能够完成高水平人类网络攻击者做到的事情,甚至更进一步。同时,模型也可能发现人类防御工程师难以察觉的漏洞。Dean 认为这是一个值得警惕的问题,单靠技术手段并不足够,最终需要法律、监管等非技术方式共同界定「希望模型做与不希望模型做的事情」。
研究方法:扫 10 篇论文的摘要,而不是精读 1 篇
关于如何判断研究方向是否值得长期投入,Jeff Dean 分享了几条原则:
- 与其精读一篇论文,不如快速浏览 10 篇甚至 100 篇摘要,积累「什么事情正在变得可行」的判断点。
- 真正值得做的问题是「需要新方法、但已经开始变得可行」的——可能一做就是五年。太早(20 年无突破)或太易(路径已明、两年内完成)的问题都不适合。
- 善用「数量级估算」:通过第一性原理与工程经验快速估算方案可行性,区分「100 年」与「10 秒」量级的差异。
- 多尝试可能失败的方向,因为总会有一些成功。
