--- id: "CxXgV54KzpQ" title: "Jeff Dean：AI 时代构建者的 1% 法则" channel: "Y Combinator" host: ["Diana Hu"] guests: ["Jeff Dean"] date: "2026-07-30" updated: "2026-08-07" duration: "57:07" duration_seconds: 3427 source_type: "youtube" youtube: "https://www.youtube.com/watch?v=CxXgV54KzpQ" canonical: "https://pod-exp.pages.dev/CxXgV54KzpQ/" transcript_jsonl: "https://pod-exp.pages.dev/CxXgV54KzpQ/transcript.jsonl" language: "zh-CN" translation: true translated_from: "en" timestamp_precision: "block" topics: ["人工智能","AI 智能体","AI 基础设施","创业与经营"] series: ["AI 研究前沿","AI 基础设施"] --- # Jeff Dean：AI 时代构建者的 1% 法则 > 中文译文，由英文原音字幕翻译整理，不是官方逐字稿；引用原话请核对英文原视频。说话人标签由整理者依上下文标注，带「未确认 / 未标注 / 不确定」等字样的标签不可靠。时间戳一般为块级（所在时间块的起点），不是逐句时间；正文自带 [hh:mm:ss] 的段落除外。 **内容提要：** Jeff Dean 从“AI 已经接近初级工程师”谈到 2027 年更重要的变化：模型会把问题拆成子问题、自动做实验、评估结果并改进自身。围绕 TPU、延迟数字、能耗与数据搬运，他解释为什么 AI 既是模型问题，也是系统与能源问题；围绕 context engineering、skills 和长时运行 agent，他给出如何让模型更可靠的具体方法。对创业者，他提出著名的“0%/1% 而非 20%”判断：优先寻找通用模型几乎做不到、但你拥有专有数据、专门模型或独特产品形态的领域，并持续训练自己选择问题的“品味”。 ## [0:09] AI 模型已经是初级工程师了吗？ · YouTube **Diana Hu：** 好，我们开始吧，Jeff？ **Jeff Dean：** 好啊，听起来不错。 **Diana Hu：** Jeff，欢迎你，也再次非常感谢你来。尤其是我刚好感冒了，还是谢谢你愿意来。 **Jeff Dean：** 我恐怕也已经把嗓子弄哑了。我平常说话不是这个声音，不过我们尽量把它完成吧。 **Diana Hu：** 你做过 MapReduce、Bigtable、TensorFlow、TPU、Gemini。光讲这些我们就能聊一整个小时，但我很喜欢的一点是，你到现在还会公开做大胆预测。去年——对，2025 年 5 月，在 AI Ascent 上，你说 AI 已经到了“初级工程师”的水平。现在大约过了一年，这个判断实现到什么程度了？ **Jeff Dean：** 我觉得模型在基于 agent、持续更长时间的编程任务上进步很大。现在看起来，它们确实已经相当有能力了。当然，这取决于你到底怎样定义“初级工程师”，但以我的判断，那句话现在看起来相当准确。 **Diana Hu：** 那个预测里，你低估了什么？ **Jeff Dean：** 我低估了它们处理越来越复杂任务的能力增长速度。我原先没有想到会这么快。另外，不只是在编程领域，这些 agent-based 系统也开始在其他领域表现得非常亮眼。我觉得这会成为未来一个很重要的趋势。 ## [1:44] 会自我改进的 AI 系统 · YouTube **Diana Hu：** 那再给我们一个大胆预测吧。（轻哼）你觉得“2027 年版”的预测是什么？ **Jeff Dean：** 我觉得我们会看到越来越多“机器学习系统本身的自动化”。也就是说，让 ML 系统通过大量实验来提高自己的能力：把问题拆成子问题，让这些子问题进入非常紧密的自动实验循环，收集结果，再把结果组合起来，得到一个改进后的系统。也就是把“问题分解 + 自动实验”这整套流程高度自动化。我觉得这会非常令人兴奋。 **Jeff Dean：** 而且我认为这不只适用于机器学习，也适用于科学和工程的其他领域。基本上，只要某个问题有可度量的目标，现在就有机会通过这种方式取得很大进展。 ## [2:40] 让 Google 搜索变快的“全索引进内存”时刻 · YouTube **Diana Hu：** 我们往历史倒一点。很久以前，2001 年左右，Google 搜索还在硬盘上运行。 **Jeff Dean：** 对。 **Diana Hu：** 你和 Sanjay 做了一遍计算，意识到某个时刻，整个搜索索引终于可以装进当时所有机器加起来的 RAM 里。你们由此做了一个很激进的改变：几天内就把一个新的、主要在内存而不是硬盘上工作的搜索版本推到了生产环境。这也是 Google 搜索后来变得那么快的重要原因。 **Diana Hu：** 历史经常换一种方式重演。到了 2026 年，今天有没有一个类似“它终于能装进内存了”的时刻，是现场所有人应该注意、应该围绕它重新设计系统的？ **Jeff Dean：** 情况有点不同，但我觉得我们会看到越来越多高性能、低能耗的推理硬件。大家越来越意识到，推理才是让这些 agent-based 系统能够服务更多人的关键；延迟也非常重要。通过硬件专用化，你可以比更通用的计算设备——源字幕这里举的是 GPU 或 TPU 一类设备——获得更高能效、更低延迟。 **Diana Hu：** 因为现场所有人都习惯了等模型回复。（清嗓） **Jeff Dean：** 等待一点都不好玩。 **Diana Hu：** 所以你是在说：如果我们以后根本不用等呢？ **Jeff Dean：** 对。想象一下，如果一个系统的延迟能改善大约 50 倍，你能用它做什么。 ## [4:38] Agent 会连续运行数天甚至数周 · YouTube **Diana Hu：** 这个想法很有意思。那现场大约 6,000 人可能共同相信、但其实已经不成立的一条 AI 假设是什么？ **Jeff Dean：** 这是个好问题。我觉得很多人还没有真正意识到：agent-based 系统可以运行多长时间。它们不只是对一个问题工作一两个小时；在某些问题域里，只要底层模型足够强，它们可以持续运行几天甚至几周，完成很复杂的任务。已经有人开始看到一点苗头了，但我不认为大家真的把这件事内化了。我觉得它会是一个非常大的变化。 **Diana Hu：** 你实际让 agent 连续跑过几周的任务，有什么具体例子？你到底让它们解决什么？ **Jeff Dean：** 比如，你可以让 agent 去把一套软件完整地重新实现成另一种编程语言，希望新版本拥有更好的安全属性，或者更好的性能属性。然后它们可以真正离开一段很长的时间，把这类工作相当认真地做下去。 ## [5:58] 催生 TPU 的餐巾纸计算 · YouTube **Diana Hu：** 很酷。你还有一件特别出名的事：很会做“餐巾纸计算”，也就是快速做数量级估算。2013 年左右，Google 的语音识别开始真正有效。有个故事说，你算了一下：如果每个 Google 用户每天只对手机说话、使用语音识别 3 分钟，所需服务器量就会大到几乎要把 Google 的服务器 fleet 翻一倍；仅仅为了语音识别就会非常昂贵。 **Jeff Dean：** 对。 **Diana Hu：** 所以你们没有继续按原方案堆服务器，而是做了一块定制芯片，这就是 TPU 的起点。 **Jeff Dean：** 是。我们当时已经看到基于深度学习的语音模型带来很好的质量提升。它们相较旧语音系统计算成本更高，但错误率大约减半——几个月里，靠调整模型、扩大一点规模、拿到更好的数据，效果相当于过去大约 20 年语音识别的进步。 **Jeff Dean：** 然后我们开始担心：如果语音识别真的好用很多，人们就会用得更多。那次 back-of-the-envelope calculation 本质上就是在问：如果大家开始更多地用语音识别写邮件、对手机说话，会发生什么？最后我们意识到，继续跑在当时的 CPU 上不是一个好答案，需要更好的办法。 **Jeff Dean：** 所以我们做了 TPU。它本质上高度专门化于低精度的稠密线性代数，而这恰好处在几乎所有现代机器学习算法的核心。你可以做一块芯片，它擅长低精度稠密线性代数，除此之外几乎什么都不会——它跑不了 Chrome，也跑不了 Word——但对机器学习推理极其有用。几年后，那一代芯片相对于当时的 CPU 和 GPU，能效大约高 30 到 80 倍，延迟也低很多，大约改善 20 到 30 倍。 **Diana Hu：** 这很惊人。现在 TPU 已经成了如此基础的设施。当初你不可能预见到后来会出现 Transformer，而 Transformer 是在 TPU 之后才被发明的。 **Jeff Dean：** 这正是为什么我们当时做的是一个相对通用的线性代数系统——TPU 本质上就是这个。我们知道 ML 算法还在演进，所以不应该过度专用化；但又要专门化到足以得到巨大的性能收益。我们可以做非常大的乘法单元，可以有高速内存，可以做高速互连。后来的 TPU 还可以让很多很多芯片高效地共同处理同一个问题。这些年我们已经做了很多代，并不断把规模和性能往上推。 ## [9:20] 如何寻找数量级突破 · YouTube **Diana Hu：** 这个餐巾纸计算太厉害了。 **Jeff Dean：** 餐巾纸很好用。（笑） **Diana Hu：** 那么，现场每个想成为未来创始人的人，今晚应该做什么样的“餐巾纸计算”，才有可能发现像 TPU 一样重要的东西？ **Jeff Dean：** 这总是很难直接回答。不过我会先想：你现在看到的问题是什么？瓶颈是什么？有没有一种完全不同的解法，可以让性能、能力或者你关心的指标提高一个数量级，甚至两个数量级？ **Jeff Dean：** 有时候，你需要眯起眼重新看问题，不要被“今天大家就是这样解决的”锚定。试着从第一性原理问：如果从头开始，我会怎样解决它？这样往往会冒出一些很好的想法，而且它们未必是别人正在想的方向。 ## [10:25] AI 工程师新的“延迟数字” · YouTube **Diana Hu：** 这是个很好的建议。（清嗓）很多年前，你写过一份非常著名的“Latency Numbers Every Programmer Should Know”，里面是各种系统工程数字，比如 cache miss 要多久、磁盘 seek 要多久、一个网络包从加州到荷兰要多久。它几乎成了很多分布式系统工程师贴在墙上的“圣经”。如果今天把它更新成 2026 年 AI 版，应该包含哪些数字？ **Jeff Dean：** 如果看今天 AI 系统真正重要的东西，我会想知道：加速器的主存到片上内存的带宽是多少；片上内存到乘法单元之类计算单元的带宽是多少；一次乘法到底耗多少能量；芯片之间的互连带宽是多少；在这个带宽下可以连多少芯片。 **Jeff Dean：** 再往更大规模走，你还应该知道：当你不再和 500 块芯片通信，而是要和 10,000 块芯片通信时，网络带宽会怎样掉下来。这些都是非常重要的数字。它们会直接改变你思考某一类问题应该怎样解。 **Diana Hu：** 我还听你提过一个很有意思的转变：现在几乎所有东西最后都可以用“能量”来衡量。 **Jeff Dean：** 对。 **Diana Hu：** 你举过一个数量级：做一次计算，大约是 1 pico 这个量级；但搬运数据、做数据 I/O，代价可以高大约 1,000 倍。 **Jeff Dean：** 对。仅仅是把数据从加速器上的 HBM 搬进处理器，让它真的可以被计算，就要付出这个代价。 ## [12:33] 为什么 AI 本质上也是能源问题 · YouTube **Diana Hu：** 这个差距其实悄悄决定了哪些产品可行、AI 算法怎样构造。创始人经常把哪些问题叫做“模型问题”，但其实它们更像能源问题或数据 I/O 问题？ **Jeff Dean：** 你刚才说的那个“搬数据比真正做计算大约贵 1,000 倍”的能耗差距，就是一个非常重要的例子，它塑造了机器学习系统的很多方面。如果没有这个 1,000 倍差距，很多时候你根本不需要 batching。 **Jeff Dean：** 但现实里你必须把很多样本、或者很多 token 一起组成 batch，用更多计算去摊薄那次数据搬运的成本。这样你付的就不是完整的 1,000 倍，而更像是“1,000 除以 batch size”的能耗代价。可问题是，如果你追求极低延迟，batching 又不理想。因此，硬件里这些能量相关的约束，会一路影响到我们构建更高层系统时的决定。 **Diana Hu：** 一个很具体的例子就是模型训练。大家习惯了把数据集分 batch、跑 epoch。很多人可能以为这是模型本身的设计问题，但本质上它其实是系统和数据 I/O 问题，对吧？ **Jeff Dean：** 对。你要组成 batch，才能让硬件运行得更高效。理想状态下，也许你会想做 batch size = 1 的训练，但从效率上看并不好，所以现在大家会使用相当大的 batch。 **Diana Hu：** 你不是很有名的一件事，就是可能出去度个长周末或者一周，然后回来给出一个很漂亮的系统解法吗？有没有可能某次 Jeff 消失两周，回来就把 batch size = 1 的训练解决了？ **Jeff Dean：** 我最近想得更多的是推理。推理很有意思，因为你确实想要极低延迟；训练则不一定需要那么低的延迟。我觉得相较今天，我们还有很多空间去做更专门的推理硬件。 **Diana Hu：** 具体有哪些推理方向让你特别感兴趣？ **Jeff Dean：** 一是尽量减少数据搬运；二是考虑极低精度运算；三是如果你已经非常确定需要什么精度，也许根本不必支持很多很多不同精度，而是只把你真正需要的精度做进硬件，其他都不做。 **Diana Hu：** 这让我想到一个类比：有位著名计算机科学家说，整个 AI 的过程其实像一个巨大的压缩问题。因为要把数据有损压缩、之后又能够恢复出有用的信息，你其实必须理解它。 **Jeff Dean：** 对。如果你真的理解数据，你应该能把它压得非常好。 **Diana Hu：** 而 Transformer 架构就是目前证明相当有效的一种方式。 **Jeff Dean：** 对，目前看起来确实相当有效。 **Jeff Dean：** 我的同事们干得不错。（笑） ## [16:11] Context Engineering 是下一条前沿 · YouTube **Diana Hu：** 我们把镜头拉远一点。过去说 AI 进步，往往等于“模型变好了”：更多数据、更大的参数。但过去一年左右，越来越多进步来自模型周围的一整套东西——retrieval、tools、memory、agent tools——这些现在常被合称为 context engineering，对吧？ **Jeff Dean：** 我觉得模型只是整个系统里的一部分。真正的目标是构建一个可以解决非常有意思问题的总体系统。这个系统里的模型要会使用工具，可能会检索相关信息，可能保留过去解决问题时检索过的信息历史，再把这些内容放进当前模型的 context。 **Jeff Dean：** 这有一个很大的好处：context 里的信息对模型非常清楚。相比之下，训练数据是数万亿 token 被搅在一起，最后进入数千亿、甚至数万亿参数的一锅“汤”里。那种信息没有“这个问题此刻直接放进上下文里的信息”那么清楚。 **Jeff Dean：** 接下来，模型还需要理解有哪些工具可用；下一阶段应该用什么工具；怎样把一个问题分解成一串 tool calls；是否应该同时尝试多条路径，然后评估哪条有效。这就是复杂 agent 系统、多 agent 系统的 orchestration。我觉得它会越来越重要，而且现在正是非常令人兴奋的时候。 **Diana Hu：** 这个方向有趣的一点是，现场几乎每个人都能做。以前训练模型需要惊人的资源、GPU 和数据；但 context engineering 不一样，你有 Gemini 之类模型的 API，就能自己做 retrieval、tool calls 等等。那大家怎样才能真正变得擅长 context engineering？ **Jeff Dean：** 一个很好的办法就是直接拿这些模型、harness 和工具去解决真实问题，然后观察它在哪里失败。很多时候，你无法从外部直接改模型参数，但你可以给模型更好的指导原则，可以给它写 skills，让它知道某类问题应该怎样使用不同工具。 **Jeff Dean：** 这样做下去，你会进入一种“让整个解题 setup 自我改进”的循环。你会越来越清楚：为了让模型更有能力，它真正还需要什么额外信息。 ## [19:46] 让 AI 学会像 Jeff Dean 一样做性能优化的 Skill · YouTube **Diana Hu：** 你能不能举一个自己做过的 context engineering 例子？比如你写过什么 skill、什么工具，真的显著改变了工作流？ **Jeff Dean：** 几周前，我和 Sanjay 在做一些很底层 library 的性能改进。Google 内部有一套我们写的 microbenchmark library，可以测不同操作要多久，比如填充某个数据结构要多久。有些数据结构会在 Google 数百万个进程上使用，所以把它们做得高性能其实很重要。 **Jeff Dean：** 没有 agent 系统的时候，典型流程是：先跑你关心的 benchmark，测当前性能；然后改代码，希望性能提高；再跑 benchmark，看哪里变快；也许再跑一套更广的 benchmark；再看看 cache footprint 等等。 **Jeff Dean：** 我们后来写了一个 skill，基本上把人会采取的这些步骤、以及不同情况下该以什么顺序采取这些步骤，教给模型。这样模型就能自己做一个循环：测 benchmark → 修改代码 → 再测性能改进 → 继续迭代。对一些问题来说，这个方法效果相当好。它本质上没有什么神秘的，就是把“我们作为人会怎么做”用模型可以使用的形式交给模型。 **Diana Hu：** 这太夸张了。所以如果别人拿到这个 skill，他就能像 Jeff Dean 一样做性能优化？这听起来值无限的钱。 **Jeff Dean：** 其实我们几个月前已经公开了一份文档，叫 *Performance Hints*。那是一份我和 Sanjay 写的、大概 30 页的文档，讲各种性能优化技巧。已经有人把它整理成摘要交给不同模型，发现模型确实会因此更擅长推理代码里的性能问题。 **Diana Hu：** 所以大家听到了：拿这份 *Performance Hints*，就能让自己的模型更像 Jeff Dean 一样优化代码。 **Jeff Dean：** 对，而且它完全免费、公开可用，大家都应该试试。 **Diana Hu：** 很酷。 ## [22:13] 为什么长时运行 Agent 会失控 · YouTube **Diana Hu：** 说到 agent，现场应该几乎每个人都造过一个。大家也都看过 agent 到第 30、40 步突然跑偏：前 10 步可能很好，到第 50 步就开始摇摇欲坠。今天真正的约束是什么？context？evaluator？还是因为这是一个近似 open-loop 的系统，错误会不断累积？ **Jeff Dean：** 我们当然希望 agent 能运行非常长的时间，因为只有这样它们才能解决越来越复杂的问题。但你说得对，今天它们有时在和工具交互 10 次左右之后就会停止正常工作。 **Jeff Dean：** 一个原因是，模型可能正在尝试自己并没有太多经验的事情。它在一批分布上训练过，但只要稍微偏离它熟悉的数据分布，就和多数机器学习模型一样，性能会开始下降。你离它的“舒适区”越远，越容易出问题。 **Jeff Dean：** 有几种办法。第一，给模型 skills 和 hints，让它尽量留在自己知道怎么走的“灯光更亮的路径”上。第二，构建 multi-agent 系统，让多个 agent 尝试不同解法，再用另一个模型或另一个 agent 去评估哪些路线看起来最有希望。 **Jeff Dean：** 这相当于在可能解法的空间里做搜索：保留更有希望的路线，丢掉那些不工作、或者已经跑偏的路线。更一般地说，就是在 inference time 花额外 compute 去搜索可能的解法。这样可以显著提高长时 agent flow 的性能和可靠性。 **Diana Hu：** 你们内部具体怎样实现这种工作流？ **Jeff Dean：** 我们有 harness，也有一整套 skills，尤其是在 Google 内部开发环境里。我们会让 agent 学会使用内部的编码工具、code review 工具、性能测量工具、日志抓取工具等等。 **Jeff Dean：** 即使基础模型并没有在“Google 工程师究竟怎样从某个专有系统拉日志”这件事上受过训练，只要 skill definition 写得对，它也能学会正确地做。这样就能提高 agent 的实用性。 ## [25:23] 小团队还能在哪里赢过 Google · YouTube **Diana Hu：** 接下来聊聊创业公司还能赢在哪里。Google 从处理器到产品都在做 co-design。像 Google 这样的公司会继续在哪些层面投入、持续复利？反过来，一个两三人的团队还可以在哪些地方赢？ **Jeff Dean：** Google、Gemini 模型以及我们的硬件基础设施，目标当然是构建非常通用、几乎什么都能做的模型。但恰恰因为目标这么通用，我们不一定会把大量注意力放到每一个具体垂直领域。 **Jeff Dean：** 某个小团队如果能为特定领域做出设计非常好的产品界面，再配上一组 skills、一个模型，甚至一个专门模型，而这个领域又不在通用模型最擅长的能力组合里，就可能拥有明显优势。你可以在自己真正热爱的垂直领域里，把东西做得非常好用、准确率很高、质量很高。两三个人在一个房间里，就可能靠这种专注获得优势。 **Jeff Dean：** 不过我也要提醒大家：通用模型正在越来越多的事情上变好。所以你得问，这个优势是否持久？前沿模型会不会在未来 6 个月或 12 个月里就把它吃掉？还是说这是它们两三年都做不到的事？选择问题时，你必须把这个时间尺度算进去。 **Diana Hu：** 那创始人怎样判断应该选什么问题？ **Jeff Dean：** 第一，也是最重要的一条：选一个你自己非常兴奋、真的想构建、而且你认为对世界有用的东西。只要满足这一点，你就已经远远好过每天醒来都觉得“我其实不太想做这个”，或者造出来的东西对世界、对大多数人都没什么用。 **Jeff Dean：** 第二，看当前更通用的模型在这个问题域到底能做什么。你可以直接测试：它做得好吗？如果它完全失败，那通常是个好信号。如果它已经能做一部分，只是做得还不够好，反而未必是好信号——那可能意味着能力已经开始出现在模型里，只要再加训练数据、扩大模型规模，或者做其他改进，它很可能很快就会变强。 **Jeff Dean：** 如果通用模型在一个任务上已经能做到 20%，那可能不是好信号；我会找它只成功 0% 或 1% 的问题。 **Diana Hu：** 这种问题怎么找？它们本质上是训练集之外的 out-of-distribution 问题吗？具体什么样的问题形态最合适？ **Jeff Dean：** 有一种情况是，你做的产品能够访问通用模型本身拿不到的特殊数据。比如你帮助用户整理他们自己的全部个人信息，通用模型天然不一定能看到这些数据。那你的产品一下子就对重要数据拥有了可见性，这会带来很大的优势。 ## [29:24] 专有数据与专门模型的两条路 · YouTube **Jeff Dean：** 另一种情况是某个问题本身极其困难，但你能拿到正确的训练数据，于是可以训练一个比通用模型更专门的模型。这个 niche model 未必需要很多 compute，训练成本也可能负担得起，但它在特定问题上可以做到很高的准确率。这种东西可以成为解决“通用模型目前做不好”的重要问题的一个非常好的 building block。 **Diana Hu：** 这听起来基本有两条路。第一条有点好笑：Google 已经在“组织全世界的信息”。 **Jeff Dean：** 对，这部分大概覆盖得挺好了。（笑） **Diana Hu：** 但“组织你自己的个人信息”仍然是开放的，这就很有意思。 **Jeff Dean：** 对。 **Diana Hu：** 第二条就是你说的某些领域的专门模型。能不能举几个具体领域？ **Jeff Dean：** 看我同事们做的 AlphaFold 就是一个很好的例子。它是非常特定的蛋白质折叠模型，而且非常成功。突然之间，你有了一个惊人的工具，可以非常有效地回答关于蛋白质及其结构的问题。但它不是通用模型，而是高度专门的模型。 **Jeff Dean：** 还有其他领域也可能适合这种方式，比如材料科学、芯片设计等等。你可以利用一个准确率非常高但很 niche 的模型，去做今天仍然很难的事。 ## [31:19] 如何成为 AI-native 创始人 · YouTube **Diana Hu：** 假设大家已经找到了类似 AlphaFold 这种形态的问题。下一步，怎样成为真正的 AI-native founder？你以前说过，管理一支 50 个、甚至 100 个 agent 的 fleet，关键在于写出非常好、非常清晰的 design doc 或 spec。大家怎样才能学会？ **Jeff Dean：** 当你和“虚拟 agent”协作时，如果能非常清楚地说明自己究竟想要什么，你会成功得多。你越清楚，agent 就越有明确的指导原则、规则和目标轮廓。反过来，如果你几乎没有写清楚，它只能自己猜你的意思，而它猜出来的东西经常和你脑子里想的不同。 **Jeff Dean：** 我们从计算机科学一开始就告诉学生：真正写软件之前，先明确你写的软件到底要完成什么。今天 agent-based 系统已经可以帮你把代码写出来，但“明确说明你要什么”反而变得更重要了。过去你把任务交给一个非常聪明的人类，对方可能有很多背景信息，也可以追问；agent 有时也能追问，但清晰的 specification 仍然非常重要。 **Jeff Dean：** 一个今天 coding agent 做得特别好的例子，是把软件从一种语言翻译到另一种语言。原因是这个任务天然有一份极其详细的 specification——原软件本身就完整描述了系统应该做什么。 **Jeff Dean：** 比如你有一个 Python 实现，想得到一个 Go 实现。模型可以把 Python 里的测试也拿过去，确保 Go 版本通过；把测试翻译成 Go；比较两个实现的行为差异，直到差异消失。它之所以能做得这么好，很大程度上就是因为 spec 太清楚了。 **Diana Hu：** 假设以后每个创始人都能同时运行几百个 agent，代码也全部由 agent 写。那什么会变成真正稀缺的能力？ **Jeff Dean：** 是“品味”——你究竟让 agent 去做什么。对我这种研究背景的人来说，这一直是研究的核心。研究者可以掌握所有工具、所有技术，但很多时候真正的战斗是：你要把时间花在哪一个问题上？ **Jeff Dean：** 如果你选对问题并把它解决了，这远胜过把一个很无聊的问题研究得无比漂亮。那种“应该做什么”的高层判断非常重要，而且我并不确定模型会特别擅长这一点。未来会是人来掌舵，让大量 AI-assisted computation 更快完成伟大的事情；但“你到底想让模型做什么”仍然是最需要你自己关注的核心。 **Diana Hu：** 现在大家都在谈 agent coding 时代的 taste。可“品味”听起来很玄，它到底怎样变得具体？ ## [35:20] “品味”怎样变得可训练 · YouTube **Jeff Dean：** 这确实很难。很多时候，“品味”根本没有一个可直接度量的 objective。我觉得一部分来自经验：你过去解决过很多不同问题，就会逐渐知道什么样的问题未来可能有意思；也会知道哪些东西只差一点点就能靠已有方法拼起来实现，以及为了达到某种近乎“魔法”、或者真正非常有用的效果，还缺哪些开放问题。 **Jeff Dean：** 还有一个办法，是给自己制造更多训练样本。你可以把自己认为“未来 12 个月会变重要”的很多东西都写下来。你也许只会选其中一个真正去做，但 12 个月之后再回来检查：哪些判断真的重要了？哪些东西已经被世界上的其他人做出来了？哪些仍然没人做？ **Jeff Dean：** 这种回看会给你自己的“品味生成器”更多样本。我觉得这是一项很重要的能力。 **Diana Hu：** 我们之前还聊过第三种方法：做非常疯狂的 thought experiment。 ## [36:37] 主动质疑最大的系统假设 · YouTube **Jeff Dean：** 对，这也是一种很好的方式。有时候，不要把“几乎所有人都认为理所当然的东西”真的当成理所当然。 **Jeff Dean：** 前几天我和同事就在做一个很疯狂的思想实验。过去大约 60 年，整个硅芯片设计与制造行业都在努力把晶体管做得越来越小、错误率越来越低。一个隐含假设是：同一种设计制造出来的每一块芯片，都应该和其他芯片行为一致。 **Diana Hu：** 也就是说，你不想看到任何 bit flip。 **Jeff Dean：** 对，不希望任何 bit 翻转。所以系统里有很多 error margin，今天内存也会用 ECC。但有意思的是，在宏观的大规模分布式系统里，我们并不要求每个部件永远可靠。我们会用“不可靠的部件”构建“可靠的分布式文件系统”：单个磁盘可以坏，但数据不能丢。 **Jeff Dean：** 所以我们在更高一层做机制。比如把同一份数据放三份，分散在三台不同机器、三个不同机架里。这样某个 rack switch、机器或者磁盘坏掉，你仍然有数据。我们也会用 Reed-Solomon 一类编码技术。 **Jeff Dean：** 但在晶体管这一极端微观尺度上，我们似乎没有把这种思维推到同样激进的程度。一个有意思的 thought experiment 是：如果你故意用那种一天可能发生 20 次错误的晶体管来造系统，会发生什么？ **Diana Hu：** 天啊。 **Jeff Dean：** 对，不是“每一百万年才错一次”，而是“一天错 20 次”。那会是一个完全不同的 design point，也许会让制造方法发生非常有意思的变化。比如如果你要把信号从这里送到那里，而晶体管非常不可靠，你可能会采用完全不同的信号传输方式；你也许会沿多条冗余路径同时发送，确保至少有一条能到达。 **Jeff Dean：** 我觉得这是一组很有意思的思想实验。我不是说我们现在就应该真的去这样造芯片；我的意思是，你应该偶尔主动质疑这些假设。当然，这类思想实验经常最后不成立，因为过去 50 年我们用某种方法而不是另一种方法，往往确实有很好的理由。但每隔一段时间重新检查它们，仍然很有价值。 **Diana Hu：** 这太疯狂了，而且听起来越来越像 neuromorphic computing、像人脑、像自然本身工作的方式。 **Jeff Dean：** 没错。人脑里的信号从一个地方传到另一个地方，其实并没有特别可靠。所以当某个信息真的很重要，大脑里往往有多条路径，让它能够到达目标。 **Diana Hu：** 你职业生涯里有没有一个类似例子：你真的把某个大家默认的疯狂假设扔掉，结果造出了一个重要系统？ **Jeff Dean：** TPU 就是一个例子：在那个问题域还没有像今天这么重要之前，我们就相信“可以针对一个相对 niche 的问题域做专门硬件”。另外，MapReduce 的起源也是一个很好的例子。 ## [40:37] MapReduce 如何从抽象问题中诞生 · YouTube **Jeff Dean：** 我和 Sanjay 以及其他一些同事，做过 Google 爬虫与索引系统的很多代实现。我们写了大量手工并行化的代码，也放了很多 checkpointing，确保程序跑在 100 台、甚至 1,000 台机器上时，即便其中有机器死掉，系统仍然可靠。 **Jeff Dean：** 问题是，这些并行化、容错代码会和你真正想完成的那件简单事情混在一起。比如你其实只是想扫描所有网页内容，然后得到一个“URL → 这个网页是什么语言、页面文本是什么”的映射；结果真正的业务逻辑反而被大量并行化与可靠性代码淹没。 **Jeff Dean：** 我们想起了自己在函数式语言方面受过的训练，于是换一个角度看这些问题，发展出了 MapReduce 这个抽象。上层只暴露问题本身的 map/reduce 形式；下层 library 则负责 checkpointing、可靠性等所有机制。这样所有系统都可以在这个底层之上构建。 **Jeff Dean：** 最后，它成了 Google 处理超大规模计算的一种非常成功、稳健而可靠的方式。这个 thought experiment 的核心就是：如果我们换个角度看，能不能发现很多问题其实都能塞进同一个抽象里？ **Diana Hu：** 很厉害。所以正是这种思想实验，最终带你们做出了 MapReduce。 ## [42:08] AI 构建更好的 AI · YouTube **Jeff Dean：** 对。 **Diana Hu：** 回到你最近很感兴趣的定制硬件。现在 AlphaChip 可以做芯片布局，AlphaEvolve 会提出候选解、评估它们，并保留有效的解。听起来，你们正在把这些系统组合起来，开始构建“会构建 AI 的 AI”。 **Jeff Dean：** 更一般地说，这就是科学方法的基本循环：提出一个实验，准备运行实验所需的东西，执行并评估实验，然后拿到结果。现在越来越多问题可以把这整套循环自动化，而且不是只跑几个实验，而是跑很多很多实验；最关键的是把这个循环的 latency 压得非常低。 **Jeff Dean：** 这会让我们能更快推进很多科学、工程和机器学习问题，包括模型设计本身，也包括芯片设计这类工程任务。 **Jeff Dean：** 如果你有一个 orchestration framework，可以接收很高层的目标，把它拆成很多子问题；每个子问题又交给一个自动实验循环去搜索最佳解；最后 orchestration framework 再把这些子问题的解组合成更高层问题的整体解，那会非常有影响力。我觉得它会加速机器学习、科学和工程的进展。 **Diana Hu：** 这听起来尤其适合那些 evaluator 很好、甚至接近 formal verification 的领域，因为系统可以不断自我改进。 **Jeff Dean：** 对。不过很多时候，你还需要把 evaluator 本身做得快很多。 **Jeff Dean：** 举个例子。大概十年前，我的同事做过量子化学问题：给定某种分子构型，你想知道它的性质。你可以运行计算量非常大的 density functional theory simulator，但一次模拟可能要整整一个晚上，才告诉你一个候选的答案。 **Jeff Dean：** 他们把大量这种昂贵模拟的输入分子构型和输出结果收集起来，用它们训练了一个对模拟器的神经网络近似。于是你得到一个新的 validation device：不再需要跑一整晚，而且速度大约快了 300,000 倍。 **Diana Hu：** 哇。 **Jeff Dean：** 而且它和完整模拟器几乎一样准确。这会完全改变你做科学的方式。假设你有 1,000 万个候选要筛选，以前这可能是一个耗时 6 个月、还要到处凑 compute 的项目；现在也许你去吃个午饭，它就筛完了。 **Jeff Dean：** 我觉得很多领域都还有空间去做更快的 validation model，可能是 learned validation model，用非常快的方式给你接近真实答案的近似。这会改变你怎样设计实验循环，也会改变你能以多快速度跑完一轮循环。 ## [46:10] 递归改进、蒸馏与被拒稿 · YouTube **Diana Hu：** 这种“被极度加速的科学方法”，你最希望它先解决哪些问题？ **Jeff Dean：** 机器学习本身显然就是一个。我们能不能让模型通过大量实验递归地自我改进？今天大型研究团队改进模型，通常是人先想出一些点子，跑一批小规模实验；如果小实验表现好，就挑最有希望的扩大规模；再评估结果，最后把不同结果整合进一份新的模型 recipe。 **Jeff Dean：** 我看不出有什么根本障碍，阻止我们把这个过程做成更自动的循环。模型自己可以决定探索什么；人也许只在最高层轻轻推一把，比如说“为什么不试试包含某个机制的新架构”。然后模型就去跑大量实验，看看哪些有效，再以更快速度把成功的东西纳入下一版。最终，你真正想优化的是“每单位 compute 投入能产生多少 discovery”。 **Diana Hu：** 很酷。回到现场。你们以后无论创业还是开始职业生涯，都会收集很多拒绝。Jeff，你也被拒过。2014 年，你和 Geoffrey Hinton、Oriol Vinyals 做了关于 distillation 的工作：用一个大 teacher model 去训练一个更小、更高效、参数更少、推理更便宜的模型；现在这已经是整个行业都在用的技巧。 **Diana Hu：** 但那篇工作当时被一个会议拒了。 **Jeff Dean：** 对。我其实并不怪 program committee。论文往往会拿到三份 review，其中一位 reviewer 可能看完后说——这次对方就说了——“不太可能产生重大影响”。 **Diana Hu：** “不太可能产生重大影响。” **Jeff Dean：** 但我们写那篇工作的时候，认为它解决的是一个非常重要的问题。因为我们迫切需要把大型模型的能力变成更便宜、仍然很有能力的小模型，这样才能把模型服务给更多人，覆盖语音、视觉等很多不同领域。 **Jeff Dean：** reviewer 当时可能没有这类经验，也许没有在思考大规模 AI service，而更关心它是不是某种“基础性推进”。所以论文偶尔被拒就被拒了，没什么。我们把它放到 arXiv 上，大家去读、去用，一切都挺好。 **Jeff Dean：** 而且今天我们确实会用类似方法，从更大规模的 Pro 模型得到 Flash 模型。这也是为什么 Gemini 的 Flash 模型相对于自己的体量和速度，可以这么有能力。 **Diana Hu：** 它们在自己这个模型尺寸级别的 benchmark 上，确实是最好的模型之一。所以一个教训就是：哪怕被拒了，也继续做。 **Jeff Dean：** 对，这就是我会从这个故事里“蒸馏（distill）”出来的教训。（笑） ## [50:03] 如果 25 岁的 Jeff Dean 来到今天 · YouTube **Diana Hu：** 你 1999 年加入 Google 时，它大概还是一家 20 人的 startup。假设把当年那个年轻的 Jeff Dean 传送到今天——拥有你现在这些技能，但又回到 25 岁——你会去 frontier lab，还是自己创业？ **Jeff Dean：** （笑）我突然觉得自己很有活力、很年轻了。 **Jeff Dean：** 很难说。这是一个非常个人化的选择，取决于你究竟想把时间花在哪里。对我来说，几个最重要的问题是：你要做的是不是自己真的在乎的事？你和一群自己喜欢共事的人一起推进它，最后如果真的把它解决了，会不会以某种积极方式改变世界？ **Jeff Dean：** 也许你做出的服务能帮助生物化学家；也许影响更广，能帮助程序员，或者帮助互联网上的所有消费者。你应该努力让自己的工作对世界产生正面影响，和你喜欢的人一起工作，同时认真投入、尽自己最大努力。 **Jeff Dean：** 至于你提的 frontier lab 和“一两个、两三个好朋友一起创业”的取舍，它们是很不同的体验。在成熟的大组织里，你有结构，有很多懂得你不知道的东西的出色同事，也有很多有趣问题；而且已经有一个巨大的平台，让你的工作可以影响世界上很多人。 **Jeff Dean：** 在很小的 startup 里，你必须对某个问题真正有热情，而且风险会更高。你得赌自己能把那个问题做成，还要把整个事业一点点长起来。但如果成功，它也可能带来极大的回报和满足感。 **Jeff Dean：** 所以最后还是个人选择。但无论走哪条路，我至少会问自己：如果我做这个问题，而且最好的可能结果真的发生了，世界会不会因此明显变好？如果世界最后只会说“嗯，挺酷的，不过也就那样”，那就不太值得你把时间花在上面。 **Diana Hu：** 那我们再谈谈另一条路：和自己真的喜欢的人组成小团队。你带过很多工程师，也造过非常大的系统。怎样找到聪明的人、怎样和他们一起工作，才能把团队的潜力发挥出来？ **Jeff Dean：** 你当然要找在团队所需领域拥有真正好技能的人，无论是在公司内部组队，还是一起创业。但你也应该找那些“你真的很喜欢和他待在一起”的人，因为大家会一起花很多时间解决非常困难的问题。 ## [54:05] 小团队、工具带与值得解决的问题 · YouTube **Jeff Dean：** 我喜欢低 ego、真正是 team player、并且技能和我互补的人。我一直觉得，小团队最好玩的状态就是：别人知道我不知道的东西，而我也有他们没那么擅长的技能。这样大家可以共同造出任何一个人单独都未必能完成的东西。 **Jeff Dean：** 更重要的是，在合作过程中，每个人都会学到新知识、新技能。你可以把自己的工程或研究职业生涯想象成一条装满技术的 tool belt；你应该一直往里面加新工具。因为你永远不知道未来某个问题恰好需要“这四个专门工具”，而不是你原来手里的那三个。工具越多，你未来遇到的问题就越可能在自己的可解范围内。 **Diana Hu：** 最后一个问题。现场也许有一个人、或者几个人，未来会做出像 MapReduce、TPU、distillation 一样重要的东西。你希望他们去解决什么问题？ **Jeff Dean：** 世界上有很多有意思的问题，我随便列几个，这绝对不是完整清单。首先，我对新的硬件方法很兴奋——刚才那个关于不可靠晶体管的 thought experiment 就是一个提示；更高效的推理硬件也很重要。 **Jeff Dean：** 我也觉得，机器学习可能还存在和今天完全不同、数据效率高得多的算法。今天的大规模模型，可能看到的训练数据量是一个人到 18 岁为止所接触数据的 1,000 倍左右；但一个 18 岁的人类在很多事情上仍然更好，在另一些事情上也至少能和这些看过远多得多数据的前沿模型相当。 **Jeff Dean：** 所以，能不能做出数据效率高得多的系统？能不能持续学习，并且从自己的行动里继续学习？continual learning 很有意思；multi-agent interaction 也很有意思。 **Jeff Dean：** 还有一些看起来不那么“纯技术”的问题也很值得做。比如，能不能让世界上的人有更好的公共讨论、更文明的对话？能不能根据人的兴趣，帮助他们遇到世界上那些“其实彼此应该认识”的人？我觉得这些也都非常有意思。 **Jeff Dean：** 世界上还有很多很酷的事情。我们都应该努力，让更酷的事情发生。 **Diana Hu：** 太好了。非常感谢你，Jeff Dean。今天就到这里。 **Jeff Dean：** 谢谢，也感谢大家。