谷歌首席科学家离职前最后一次对话：我低估了AI，也看清了创业者的唯一生路

编译 | 宇琪

策划 | Tina

一年前，Google 首席科学家 Jeff Dean 在 AI Ascent 2025 峰会上预测：到 2026 年，可能出现能够全天候工作、能力接近初级软件工程师的 AI 系统。

一年后，也就是 6 天前，他在一期 YC 访谈中承认，自己低估了 AI 的进展速度。模型处理复杂任务的能力，增长得远比他当时预想的更快。那么，在 Jeff Dean 看来，AI 接下来还会以多快的速度向前推进？创业公司又该如何在通用模型不断扩张能力边界的时代生存下来？

今天凌晨，这期访谈又有了不同的分量。Jeff Dean 宣布，明天将是自己在 Google 的最后一天。效力 Google 27 年后，这位被誉为硅谷“程序员中的程序员”、深度参与 Google 系统架构和 AI 技术建设的传奇工程师，将与长期合作伙伴 Sanjay Ghemawat、Oriol Vinyals 和 Quoc Le 共同创立 Discovery Loop，一家聚焦机器学习、科学和工程前沿研究的公益性公司。Google 将作为创始投资方和云计算合作伙伴继续与他们合作。

据 WIRED 披露，这个创业想法其实只是几周前才浮出水面。为了挽留这支核心团队，Alphabet CEO Sundar Pichai 还曾在多次会面中试图说服他们“别摘工牌”。但最终，几人还是决定离开大公司体系，去换取一家初创公司才有的乐趣、速度和自由。

Jeff Dean 在告别信中写道，自己见证了 Google 从一家只有 25 人的公司，成长为拥有 19 万多名员工的科技巨头。如今，Google 已有 13 款产品的用户规模超过 10 亿。从搜索、邮件、翻译和视频，到大规模计算、自动驾驶和 AI 系统，他参与建设的技术几乎贯穿了 Google 的整个发展历程。

而促使他们离开的一个重要原因，也恰恰是大公司难以摆脱的惯性。正如 Oriol Vinyals 所说，在大型组织内部，要推动任何激进变化，都必须先克服层层阻力；他们想做点不一样的东西。颇有意思的是，迄今为止，这家新公司甚至还没来得及招人、租办公室，至于谁来当 CEO，团队内部短暂停顿后，大家把目光投向了 Jeff Dean——“我想应该是我吧。”他说。

因此，这期发布于 Jeff Dean 离职前夕的访谈，也像是他站在职业生涯转折点上，对 AI 下一阶段的一次集中判断。节目中，他与 YC 合伙人 Diana Hu 讨论了 AI 从“模型为中心”转向“上下文工程”的范式变化、推理硬件正在出现的巨大机会，以及创业者如何在通用模型越来越强、越来越多应用可能被模型直接吞并的时代，找到真正值得坚守的生存空间。

本文基于该访谈视频整理，经 InfoQ 编辑。

太长不看版

Q：去年你说到 2026 年会出现能力接近初级工程师的 AI。一年过去了，这个预测打脸了吗？

A：相当准确，但我低估了一件事：模型处理越来越复杂任务的能力，增长速度比我预想的快得多。而且这种能力正在溢出到编码之外的领域，基于 Agent 的系统开始真正崭露头角。

Q：对 2027 年的大胆预测是什么？

A：深度学习系统将实现全自动的问题分解和自动化实验循环：把问题拆成子问题，自动跑实验，整合结果，得到一个改进后的系统。而且这不只适用于机器学习，任何有可衡量目标的科学和工程领域都能用上。

Q：2001 年 Google 把搜索索引装进内存，2026 年那个“装进内存”的时刻是什么？

A：高性能、低能耗的专用推理硬件。推理是让 Agent 系统触达更多人的关键，专用硬件能带来 50 倍延迟改善和 30-80 倍能效提升。当年省掉的是磁盘寻址的物理延迟，今天省掉的是通用计算的多余步骤。但这次赌注更高，因为 Agent 需要的是成千上万次连续推理，每一次延迟都在累积。

Q：人们现在对 AI 最大的误解是什么？

A：大家都觉得 Agent 就是跑一两个小时的临时任务，但配合足够强的底层模型，你可以让 Agent 连续跑上几天甚至几周。

Q：那张催生 TPU 的餐巾纸数学，到底算出了什么？

A：2013 年语音识别效果暴增，我们算了笔账：如果每个用户每天对着手机说三分钟话，用 CPU 根本撑不住，于是造了 TPU。几年后 Transformer 横空出世时，它恰好成了根基。

Q：AI 时代的延迟数字清单，最该记住哪个数？

A：做一次计算消耗约一皮焦耳，但把数据搬进处理器的那一小段路，能耗是它的 1000 倍。这个差距决定了你必须做 batching，把很多样本拼在一起处理，把成本摊成“一千倍除以 batch size”。

Q：创始人该怎么选要做的领域？

A：拿当前最强的通用模型去测你想做的领域，如果模型成功率在 0% 或 1%，那是好信号；如果在 20%，那是危险信号，说明能力已经萌芽，下一代模型很快会覆盖。

Q：当 Agent 写完所有代码，什么技能变得稀缺？

A：品味，知道该让你的 Agent 去解决什么问题。一是靠解决过大量问题的经验，二是写下你觉得未来 12 个月可能重要的十件事，一年后回来复盘哪些真的变重要了，三是做疯狂的思想实验，比如“如果晶体管每天出错 20 次而不是每一百万年一次，系统该怎么设计？”

高性能、低能耗的推理硬件革命

Diana：去年 5 月在 AI Ascent 大会上，你说到 2026 年左右，可能会出现能够全天候工作、能力接近初级工程师的 AI 系统，现在我们离这个预测有多近？

Jeff：我觉得模型在处理基于 Agent 的长时间运行编码任务方面进步非常大。现在看起来很明显，它们确实已经相当有能力了，取决于你对“初级工程师”的精确定义，这个预测现在看来相当准确。

Diana：那你当时低估了什么？

Jeff：我认为处理越来越复杂任务的能力，其增长速度比我预想的要快得多。而且，在编码之外的领域，这些基于 Agent 的系统也开始真正崭露头角，我认为这将是未来一个重要的趋势。

Diana：你觉得 2027 年版的预测会是什么？

Jeff：我认为你会看到更多机器学习系统自身的自动化。具体来说，就是让机器学习系统通过运行大量实验来提升自己的能力，把问题分解成子问题，在紧密的自动实验循环中运行这些子问题，然后把结果整合起来，从这种全自动的问题分解和自动化实验中得到一个改进后的系统。而且这不仅适用于机器学习，也适用于科学和工程的其他领域。基本上任何有可衡量目标的事情，如今都能取得很大进展。

Diana：2001 年，Google 搜索还是跑在硬盘上的。你和 Sanjay 算了一笔账，意识到在某个时间点，整个搜索索引终于能装进所有运行中计算机的内存里。你们做出了那个激进的决定，基本上在几天之内就和 Sanjay 一起把一套全新的、基于内存而非硬盘的搜索版本推到了生产环境，正是这件事让 Google 成为了今天的 Google。

历史总是在重演，那么在 2026 年的当下，那个“能装进内存了”的时刻是什么？在座所有人都应该思考和设计的那个转折点在哪里？

Jeff：情况有些不同，但我想说的是，你会看到越来越多高性能、低能耗的推理硬件系统出现。因为现在大家都意识到，推理是让这些 Agent 系统触达更多人的关键。延迟真的很重要，而硬件的专门化是让你在能效和延迟上都优于 GPU 或 CPU 这类通用计算设备的核心途径。

Diana：所以你的意思是我们也许不用再等待了？

Jeff：没错，想象一下，如果延迟能改善 50 倍，你能做些什么？

Diana：在座大约 6000 人，他们脑子里关于 AI 的哪个假设，其实已经是错的了？

Jeff：我想可能是人们还没有充分意识到，Agent 系统能跑多久的潜力。大家总觉得 Agent 就是跑一个小时、两个小时的临时任务。但事实上，在某些问题领域，配合足够强大的底层模型，你可以让这些 Agent 连续跑上几天甚至几周，真正去解决那些复杂的、长期的问题。这绝不仅仅是“多等一会儿”的区别，而是质变。

Diana：那你实际跑过哪些跑了几个星期的任务？你让 Agent 去解决什么？

Jeff：比如，你可以让 Agent 去实现一个全新版本的软件，用不同的编程语言重写，可能具备更好的安全性或性能特性。它真的能认真地去完成这件事，而且完成得相当靠谱。

TPU 的起源

Diana：大家一直都知道你特别擅长“餐巾纸数学”。有个关于你的故事是，2013 年谷歌的语音识别刚上线时，你做了个估算：如果每个谷歌用户每天用手机对着语音识别系统说三分钟话，整个服务器的规模就得翻倍，那成本高得吓人。于是你构建了一个定制芯片，那就是 TPU 的起源故事。

Jeff：当时的情况是，我们训练的基于深度学习的语音模型，效果开始变得非常好，但计算开销比老的语音系统贵得多，不过它把错误率砍掉了一半。这相当于把语音识别领域 20 年的进步，浓缩在几个月里就实现了，我们只是调整了一下模型、稍微扩大规模、拿到更好的数据。于是我们开始担心：如果语音识别效果大幅提升，人们的使用频率也会大幅上升。

所以那个粗略计算实际上就是关于：如果人们开始更频繁地使用语音识别，用来口述邮件、对着手机说话，会发生什么？算完之后我们发现，当时用 CPU 跑根本撑不住，于是我们造出了 TPU，一种专门为低精度稠密线性代数设计的芯片，而这正是今天几乎所有机器学习算法的核心。

虽然除了算线性代数，它啥也干不了，不能运行 Chrome 和 Word，但这对机器学习推理来说无所谓。几年后这颗芯片问世，能效比同时代的 CPU 和 GPU 高出 30 到 80 倍，延迟也低了 20 到 30 倍。

Diana：你当时肯定没法预料到，TPU 会在后来 Transformer 架构横空出世时变得如此根基性，毕竟 Transformer 是 TPU 发明之后好几年才出现的。

Jeff：这恰恰是我们当初把它做成一个通用线性代数系统的原因。我们知道机器学习算法还在演化，不能过度特化，但又要特化到能获得巨大的性能收益。所以我们做了很大的乘法单元、高速内存、高速互联，后来的 TPU 还能把成百上千颗芯片高效地协同到同一个问题上。就这样一代一代迭代，一直做到今天。

Diana：如果有谁想当未来的创始人，应该算一道什么样的“餐巾纸数学”，才能造出像 TPU 一样有影响力的东西？

Jeff：我觉得，去想想你在思考的领域里看到了什么问题、什么瓶颈，然后问自己：有没有一种非常不同的思考方式，能让解决方案带来一个数量级甚至两个数量级的提升？有时候你只是眯着眼看一个问题，不被“这个问题今天是怎么解决的”锚定住，而是从第一性原理出发去思考你会怎么解决它，你就能冒出一些被人根本没想到的真正的好点子。

AI 时代的“延迟数字”清单

Diana：你多年前写过一份非常著名的清单，叫《每个工程师都应该知道的延迟数字》，里面列了各种系统操作的耗时：缓存未命中要多久、磁盘寻道要多久、一个网络包从加州传到荷兰要多久……这份清单后来成了无数分布式系统工程师的圣经。现在，是时候更新 AI 版的了。

Jeff：如果看今天 AI 系统里什么最重要，你首先得知道加速器上主内存到片上内存、再到乘法单元之间的带宽是多少，你得知道做一次乘法运算要消耗多少能量，你还得知道芯片之间的互联带宽是多少，以及在这个带宽下你能连多少颗芯片。再往大了说，当你需要跟 10000 颗芯片通信而不是 500 颗的时候，网络带宽会衰减到什么程度。这些数字才是真正决定你怎么思考问题的底层约束，它们直接决定了你会用什么样的思路去解决什么样的问题。

Diana：你说过，现在衡量一切的标尺变成了能量。做一次计算或数学运算大概消耗一皮焦耳，但移动数据、做数据 I/O 的能耗是它的 1000 倍。

Jeff：没错。就是从加速器上的 HBM 把数据搬进处理器、让它真正能算得上的那一小段路，能耗就差了三个数量级。

Diana：这个差距其实在悄悄决定哪些产品能做出来、哪些算法路线能走通。既然数据移动这么贵，如果创始人来找你，说自己遇到了“模型问题”，但实际上本质是能源问题或数据 I/O 问题。你怎么分辨这两者？

Jeff：你刚才提到的这个一千倍差异，其实塑造了机器学习里大量的决策。如果没有这一千倍的差距，你根本不需要做 batching。但现实是你必须把很多样本、很多 token 拼在一起处理，才能摊薄数据移动的成本，不是付出一千倍的代价，而是付出“一千倍除以 batch size”的能耗。而对低延迟场景来说，batching 并不友好。所以这些硬件层面的能耗考量，深刻影响着我们构建上层系统时的每一个决策。

Diana：一个很具体的例子就是训练模型的方式，把数据集分批、跑 epoch，很多人以为这是模型问题，但实际上这本质上是个系统的数据 I/O 问题，对吧？

Jeff：对，你必须组装 batch 才能让硬件跑出更高效率。理想情况下你恨不得用 batch size 等于 1 来训练，但那样效率太差了，所以现在大家都用很大的 batch。

Diana：我听说你有个习惯：消失一段时间，然后带着一个绝妙方案回来。那有没有可能你花上几周时间，把 batch size 等于 1 的训练彻底搞定？

Jeff：说实话，我最近更多在想推理这件事。推理是个很有意思的问题，因为你确实想要极低延迟，训练倒不一定需要那么低的延迟，而推理恰恰是 batching 最不好使的领域。核心就是尽量把数据搬运降到最低，然后去想极低精度的运算，也许不需要支持那么多不同种类的精度格式。如果你对需要哪种精度有很好的答案，那就直接把它固化进硬件里，别的都不用管。

Diana：我想起一位著名计算机科学家跟我说过的一个核心类比：整个 AI 过程本质上是一个巨大的压缩问题。因为要让数据有损压缩、再把它恢复出来，你基本上得先真正理解它。

Jeff：对，如果你真正理解数据，就应该能把它压缩得非常好。

Diana：Transformer 架构恰恰就是被验证为特别好用的一种压缩方式。

Jeff：这得归功于我的同事们。

上下文工程是下一个前沿

Diana：过去我们谈 AI 进步，往往就是指模型本身变得更好。但最近几年越来越明显的是，不只是模型规模、参数数量或数据量，而是检索、工具调用、记忆、Agent 工具这些外围能力，这些东西正在汇聚成人们所说的“上下文工程”。

Jeff：模型其实只是整个系统里的一块拼图。你要做的，是构建一个能解决真正有趣问题的完整系统，这个系统需要一个知道怎么用各种工具的模型，知道怎么检索相关信息，也许还保留着过去解决类似问题时检索过的历史信息，然后把这些信息放进模型的上下文里。

上下文工程的美妙之处在于，这些信息对模型来说是极其清晰的。不像训练数据那样，几万亿个 token 搅在一起，融成几千亿参数的浓汤，什么都糊在一起，模型直接看到的上下文，远比那些模糊的训练数据要明确得多。

接下来还要理解有哪些工具可用、哪些工具能帮模型解决当前这个阶段的问题、怎么把一个复杂问题拆解成一系列工具调用、甚至尝试多种路径看看哪条走得通、然后评估效果，这就是复杂 Agent 和多 Agent 系统的编排，它会变得越来越重要。

Diana：怎么才能成为上下文工程的高手？

Jeff：最好的方式就是直接用这些模型、Harness 和工具去解决实际问题。用着用着，你会看到模型在哪些地方失败了。然后你会发现，你往往不需要调整模型参数，那是外部很难做到的事，而是通过写更好的提示词、设计更清晰的上下文，就能让模型表现得更好。

Diana：能不能给我们举个你自己做上下文工程的例子？你写过哪些 skills，或者配过哪些工具，让你的工作流发生了巨大的变化？

Jeff：就拿我和 Sanjay 几周前一起做的事来说吧，我们经常要做一些非常底层库的性能优化工作。Google 内部有一套微基准测试库，你可以用它来测量不同操作耗时多久，比如从数据结构里弹出一个元素需要多少纳秒。这些数据结构可能跑在 Google 数百万个进程上，所以确保它们的高性能其实非常重要。

我们写了一个 skill，教模型如何按特定顺序做一系列操作：先跑微基准测试测量当前性能，然后做代码修改，再重新跑基准测试验证改进效果，接着测量缓存占用，然后继续迭代。这样它就能做自我改进，实际上只是我们把作为人类会使用的方法以模型能用的形式给了它。

Diana：也就是说，你们有一个 skill，如果别人拿到了，就能像 Jeff Dean 一样做性能优化？全世界都会疯抢这个东西，对某些人来说它值无限的钱。

Jeff：其实我们几个月前发布了一份文档，叫《Performance Hints》，是 Sanjay 和我写的。那是一份大约 30 页的文档，涵盖了各种性能优化的技巧。已经有人把它做了摘要喂给各种模型，结果发现模型在推理代码性能问题上的能力确实变强了。

Diana：在座各位可能都在构建 Agent，也都见过自己的 Agent 在第 30 步或第 40 步突然跑偏。你觉得今天的瓶颈是什么？是上下文评估器，还是因为这是个开环系统、错误不断累积？

Jeff：我们当然希望 Agent 能长时间运行，因为这样才能解决越来越复杂的问题。但正如你观察到的，它们有时在十次工具交互之后就不工作了。有时候是因为模型在尝试做它缺乏经验的事情，模型一旦偏离训练分布，性能就会像大多数机器学习模型一样急剧下降，离舒适区越远，失败的概率就越高。

有几种应对办法：一是给模型提供 skill 和提示，让它尽量走在熟悉的明亮路径上；二是采用多 Agent 系统，让多个 Agent 尝试不同方案，再用另一个模型或 Agent 去评估哪些方案有前景。这本质上是用推理时计算来搜索可能的解决方案空间，能大幅提升长时运行 Agent 流程的可靠性和性能。

Diana：你们内部是怎么实现这种工作流的？

Jeff：我们有各种 harness，还有一整套 skill。

尤其是在 Google 内部开发环境里，我们写了 skill 让 Agent 学会使用内部工具，代码审查、性能测量、拉取日志文件。这些 skill 让基础模型即使没被训练过我们专有系统的用法，也能通过正确的 skill 定义把活干好。

初创公司如何打败谷歌

Diana：Google 的独特之处在于，你们从处理器到产品全栈协同设计。哪些层是 Google 会持续深耕、不断积累优势的？哪些地方是两三个人的小团队依然能打赢的？

Jeff：显然 Google 和 Gemini 模型以及硬件基础设施，我们追求的是构建能做几乎所有事情的通用模型。但在很多情况下，这意味着我们无法在特定领域投入太多注意力。一个精心设计的界面，搭配一个模型和一组 skill，或者一个不在通用模型体系里的专用模型，反而可能拥有显著优势，因为你可以为真正热爱的领域打造出令人愉悦、高精度、高质量的产品，我觉得这正是两三个人做他们真正兴奋的东西时能获得优势的地方。

通用模型的能力确实在越来越广的范围内变强。所以你必须想清楚：你现在做的东西，是能长期成立的，还是说前沿模型在未来 6 个月或 12 个月内就会做得比你好？又或者是他们两三年内都做不到的事？这个时间窗口的判断，是你决定做什么时最需要权衡的东西。

Diana：那具体怎么判断呢？创始人该怎么推理哪些领域值得做？

Jeff：最重要的事情是选择一件你超级兴奋、想要去构建、并且你认为对世界有用的东西。其次，拿当前最强的通用模型去测试你想做的那个问题域。你先看看现在的模型在这个领域表现如何，如果它们完全做不了，那大概率是个好信号。如果它们已经能做一部分了，但做得不太好，那可能是个危险信号。因为这说明这个能力已经开始出现在模型里了，随着更多训练数据、更大规模的模型，它很可能变得更好。所以你要找的是模型成功率在 0% 或 1% 的领域，而不是 20% 的领域。

Diana：那这些 0% 的领域怎么找？它们是不是本质上就是训练集之外的东西？什么样的问题形态符合这个标准？

Jeff：有时候是因为你做的产品能接触到某种特定类型的数据，而底层通用模型接触不到。比如你做一个帮用户整理个人信息的工具，模型本身没有权限访问用户的个人数据。也可能是一些极其困难的问题，如果你得到了正确的训练数据，你可以训练一个比通用模型更专门的模型，而且你实际上可以以非常经济的方式做到这一点，训练一个针对特定问题的细分模型不需要那么多算力。

Diana：这么看其实有两条路。第一条路有点微妙，你们谷歌的口号是“组织全球的信息”，那个领域基本已经被覆盖了，但“组织个人自己的信息”这个方向还完全开放着。而第二条路，你刚才提到某些领域的专用模型，能具体讲讲是哪些领域吗？

Jeff：你看我同事们在 AlphaFold 上的工作，那是一个专门针对蛋白质折叠的模型，非常成功，真正把那个领域处理得非常好。它不是一个通用模型，而是一个非常专门的模型。在其他领域，比如材料科学、芯片设计，这种思路也能发挥巨大作用，你可以用高度精确但小众的模型，去做今天很难做的事情。

当 Agent 写完所有代码，稀缺技能变成了“品味”

Diana：你过去说过，管理一群 Agent 的关键在于写出清晰的设计文档或 Spec。人们如何擅长这个？

Jeff：当你与 Agent 合作时，你越清楚你想要什么，Agent 就会有越多的指导方针和规则，以及它试图完成的目标的概要。而如果你没有指定太多东西，Agent 就不得不推断你的意思。在很多情况下，它可能推断出与你想象不同的东西。所以我们从一开始就告诉计算机科学家，在编写软件之前先明确说明你正在编写的软件试图完成什么。现在，指定你想要什么的重要性上升了。因为以前，你会把它交给一个非常聪明的人，他可能有上下文或者可以问你后续问题。虽然 Agent 有时也能做到这一点，但清晰的 Spec 是个好主意。

举个例子：一个效果非常好的编码 Agent 的用法是，你可以让今天的模型把软件从一种计算机语言翻译成另一种语言，效果非常好，因为在那种情况下你实际上有一个极其详细的 Spec，你有整个软件来说明系统应该做什么。所以如果你有一个 Python 实现的东西，你想要一个 Go 实现，这是当今模型似乎非常擅长的事情。因为它可以拿 Python 中的所有测试，确保它们在 Go 版本中通过，把测试翻译成 Go，比较两个实现之间的行为差异直到没有差异，并且非常高效，因为那个 Spec 太清晰了。

Diana：假设每个人都学会了同时跑几百个 Agent，所有代码都由 Agent 写完了，那什么技能会变得稀缺？

Jeff：我认为是真正出色的品味，知道该让你的 Agent 去解决什么问题，这才是研究问题的核心。

一个研究者可以拥有所有工具和技术，但大部分战斗在于：你要把时间花在哪个问题上？如果你选对了问题并且成功解决了它，那远比你把一个无聊的问题执行得漂漂亮亮要好得多。这种“该做什么”的高层智慧，我认为极其重要，而模型不太可能在这方面变得很擅长。所以，未来会是人来掌舵大量的 AI 辅助计算，去完成伟大的事情。但“你希望你的模型做什么”这个本质，才是你真正应该专注的事情。

Diana：在这个 Agent 编程的时代，品味这个词被频繁提及。但它听起来太玄学了，怎么把它变得具体？怎么培养品味？

Jeff：这确实是个难题，品味在很多情况下没有一个可衡量的客观标准。我觉得一部分来自经验，过去解决过大量不同的问题，会教会你什么样的问题在未来可能有趣，或者什么样的事情通过拼接之前的方法可能刚好能实现。另一个方法是：写下你觉得未来 12 个月可能重要的一堆事情。也许你挑了其中一个去做，但 12 个月后回来评估：其他那些事情里，哪些真的变得重要了？哪些被世界上其他人做出来了？哪些还没有人碰？这能为你自己的品味培养提供大量样本。

Diana：我觉得还有第三种方式，我们之前聊到的，做非常疯狂的思想实验。

Jeff：哦对，那是另一个好方法。有时候，不要把所有大多数人视为理所当然的事情当作理所当然。比如我前几天跟同事们做了一个疯狂的思想实验：60 年来，整个硅芯片设计和制造行业做了大量工作，把晶体管做得越来越小、错误率越来越低。因为我们的假设是，每一颗制造的芯片都应该和另一颗完全一致，你不希望任何 bit 翻转。但在宏观尺度上，我们构建大规模分布式系统时并不做这个假设，我们用不可靠的部件构建可靠的分布式文件系统。单个磁盘可能坏，但你的数据应该是安全的。那么一个有趣的思想实验是：如果你试图用每天可能出 20 次错的晶体管来构建系统，而不是每一百万年才出一次错，会发生什么？ 那会是一个非常不同的设计点，可能会在制造端带来非常有趣的可能性。

Diana：太疯狂了，这开始跟神经形态计算或者人脑的工作方式产生共鸣了。

Jeff：完全正确。大脑中的信号从一个地方传到另一个地方并不是特别可靠。所以在大脑里，当有真正重要的信息需要传递时，会有多条通路来确保信息能到达。

Diana：有没有一个你抛弃的疯狂假设，最终真的构建出了一个有影响力的系统？

Jeff：TPU 就是一个好例子，在一个问题领域看起来还没有今天这么重要的时候，就为它专门定制硬件。

MapReduce 的起源是另一个好例子。我和 Sanjay 以及一些同事之前写过很多手写并行化的代码，做了大量 checkpoint 来确保在几百台或几千台机器上运行时足够健壮。但那些代码往往和你要做的简单事情混在一起，比如“我想看看所有网页的内容，然后计算 URL 到页面语言的映射”，却被大量并行化和可靠性代码淹没了。我们想起了函数式编程的训练，意识到可以眯着眼看这些问题，抽象出 MapReduce 这个抽象层，把 checkpoint 和可靠性机制都放到底层库里，所有东西都构建在它之上。

所以，从那个“如果我们眯着眼看，能不能找到大量适合这个抽象的问题”的思想实验里，诞生了 MapReduce。

用 AI 构建更好的 AI

Diana：现在 AlphaChip 在布局芯片，AlphaEvolve 在提出解决方案、评估并保留有效的方案，看起来你正在构建一套能够自我复合的系统——AI 在构建 AI。

Jeff：更广泛地说，这其实是科学方法的基础：提出实验、实现实验、评估实验、获得结果。现在有越来越多的问题域，可以不只是跑几个实验，而是跑大量实验，因为你能够自动化这个循环，让循环的延迟变得极低，这会让我们能够处理科学、工程、机器学习、模型设计本身，以及芯片设计等工程任务中的大量不同问题域。如果你能自动化这些，并且有一个编排框架，能把高层目标分解成子问题，每个子问题都是自动化的探索循环，然后编排框架再把子问题的解决方案整合成整体方案，这将产生巨大的影响，会加速机器学习、加速科学、加速工程。

Diana：听起来很多领域，只要有好的评估器，或者能被形式化验证的领域，都适合 AI 自我改进。

Jeff：对，很多时候你的评估器需要变得更快。举个例子，我的同事们大约十年前在量子化学领域做了一些工作，你想了解某个分子的性质，可以生成一个分子构型，然后想知道它有什么性质，你可以跑一个计算量非常大的密度泛函理论模拟器，那可能需要一整晚的计算才能给出一个答案。

但我的同事们做的是：拿大量模拟运行的输出，输入的分子构型和昂贵模拟器的输出，然后训练一个神经近似器来替代模拟器。他们做出了一个比原模拟器快 30 万倍、精度几乎一样的验证设备。

这完全改变了你做科学的方式，你可以在吃午饭的时间里筛选 1000 万个候选，而不是花六个月去凑够计算资源跑完所有模拟。在很多领域，更快的验证模型，有巨大的空间。

Diana：那你特别期待这个超速科学方法解决哪些领域的问题？

Jeff：显然机器学习本身就是一个。能不能有一个模型，通过跑大量实验来自我改进？今天大型研究团队改进模型的方式是：人们想出一些想法，跑一批小规模实验，看哪些有效，然后把最有希望的放大规模，评估，整合成新的配方。

但没有任何真正的障碍阻止这变成一个更自动化的循环，模型自己决定探索什么，或者在高层次上由人轻轻推一下“为什么不试试包含这个的模型架构新想法”，然后它就跑大量实验，看哪些有效，以更快的速度整合。本质上，你要优化的是每单位计算输入的发现数量。

Diana：2014 年你和 Geoff Hinton、Oriol Vinyals 写了一篇关于蒸馏的论文，即用一个大模型训练一个更小、更高效的模型，现在这已经成为行业里每个人都在用的技巧，但这篇论文被 NeurIPS 拒了。

Jeff：对。我不怪程序委员会，因为很多时候一篇论文收到三份评审意见，有人看了一眼说“不太可能产生重大影响”。但当我们写这篇论文时，我们看到了这是一个超级重要的问题，因为我们知道从更大规模的模型做出更便宜、能力更强的模型，是我们迫切想做的事情，我们想在语音、视觉等许多领域，把模型服务给越来越多的人。

但有时候评审者可能没有那样的经验，他们可能不是在考虑大规模 AI 服务，而是在想“这是一个根本性的进展吗？”所以偶尔被拒也没关系。我们把它放上 arXiv，人们读它、用它，一切都好。

我们确实在用蒸馏技术做我们的 flash 模型，从更大规模的 pro 模型蒸馏出来，这就是为什么我们的 Gemini flash 模型在同等规模和速度下如此有竞争力。

Diana：你 1999 年加入 Google 时，它还只是个 20 人的初创公司。如果把年轻的 Jeff Dean 从那时传送到现在，以你的技能，你会怎么做？你会加入前沿实验室，还是创办一家公司？

Jeff：对我来说，最重要的问题是：你要做的这件事，是你真正在意的吗？如果你能和一群你喜欢共事的同事一起取得进展，这件事能以某种积极的方式改变世界吗？你应该努力的是：对世界产生积极的影响，和你喜欢的人一起工作，努力工作、做到最好。

至于加入前沿实验室还是创办一家两三个人的小公司，那是不同的体验。

在大机构里，有大量出色的同事，有大量有趣的问题，而且你已经有了一个平台可以让你的工作影响世界上很多人。

而作为一个小型初创公司，你必须有你充满热情的东西，而且承担这个特定问题的风险很大，但这也可以是非常有回报的。

无论你走哪条路，问自己：如果我解决这个问题，最好的结果发生了，世界会变得好很多吗？还是世界会说“哦，挺酷的，但无所谓”，这就不值得你花时间。

Diana：你一直是很多工程师的导师和管理者，也构建了庞大的系统。怎么和聪明人合作、怎么找到聪明人，有什么经验？

Jeff：你总是想找到在你需要的领域有真正出色技能的人，但你也想找到你乐于与之相处的人，因为你会花大量时间和他们一起解决非常困难的问题。你想要低自我、有团队精神、技能与你互补的人。

我总是觉得，在一个小团队里，别人知道我不知道的东西，而我也有一些别人不具备的技能，这超级有趣，因为你们在共同构建一个你们任何一个人都无法独立完成的东西。在这个过程中，你实际上获得了大量新知识、新技能，他们也一样。

你应该把自己的工程或研究职业生涯看作一条装满技术的工具带，你总想往上面加新工具，因为你永远不知道什么时候会遇到一个问题，添加更多工具使得你未来遇到的问题更有可能被你解决。

Diana：我相当确定在座有人最终会构建出像你做的 MapReduce、TPU、蒸馏等一样有影响力的东西，你希望他们在研究什么问题？

Jeff：我特别兴奋的是硬件的新方法，或者更高效的推理硬件。我认为可能有根本不同的机器学习算法，比我们今天用的方法数据效率高得多。今天的模型，它们看到的数据量可能是一个 18 岁的人能看到的一千倍。但一个 18 岁的人，在很多事情上比那些看到了更多数据的前沿模型持平甚至更好。

所以你能不能想出更数据高效的系统，能从自己的行为中持续学习？持续学习是一个非常有趣的方向，多 Agent 交互也很有趣。创造让人们更好地对话的方式，帮助世界各地的人们根据兴趣认识彼此，这些都可能很有意思。世界上有很多酷的事情，我们都应该去努力让更酷的事情发生。