编译 | 宇琪
策划 | 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 编辑。
太长不看版
元股证券:ygzq.hkQ：去年你说到 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 交互也很有趣。创造让人们更好地对话的方式，帮助世界各地的人们根据兴趣认识彼此，这些都可能很有意思。世界上有很多酷的事情，我们都应该去努力让更酷的事情发生。
多空新闻网提示：本文来自互联网，不代表本网站观点。
