WEBVTT

00:00:00.000 --> 00:00:28.300
你有没有想过,真正定义AI下一阶段走向的,未必是那些轰轰烈烈对外举办的大模型发布会。而是少数行业元老在创业社群内部的深度对话。很多足以改变后续行业走向的核心观点,最先都是诞生在,这类小规模交流现场,没有华丽的宣传包装。全部是几十年工程实践沉淀下来的硬核思考。前不久,谷歌的杰弗迪恩就在YC创业学校完成了一场信息密度极高的圆桌对话。

00:00:28.300 --> 00:00:31.420
整场交流把当下AI行业的现实瓶颈

00:00:31.420 --> 00:00:32.840
硬件底层逻辑

00:00:32.840 --> 00:00:34.280
agent发展边界

00:00:34.280 --> 00:00:37.020
还有普通创业者能够抓住的现实机遇

00:00:37.020 --> 00:00:38.840
全部完整剖析出来

00:00:38.840 --> 00:00:41.200
如果你正在接触AI相关项目

00:00:41.200 --> 00:00:43.340
或是想要看懂未来三五年

00:00:43.340 --> 00:00:45.020
行业真实的眼睛路线

00:00:45.020 --> 00:00:47.280
接下来的内容值得仔细看完

00:00:47.280 --> 00:00:49.180
觉得内容对你有启发

00:00:49.180 --> 00:00:50.320
可以点赞支持

00:00:50.320 --> 00:00:52.240
不错过更多硬核行业解读

00:00:52.240 --> 00:00:55.340
主持人开场抛出的第一个问题就相当尖锐

00:00:55.340 --> 00:00:58.100
直接回溯到一年之前的公开观点

00:00:58.100 --> 00:01:02.460
去年5月份杰弗迪恩曾经在AISNOT的活动上提出一个判断

00:01:02.460 --> 00:01:04.940
AI已经达到初级工程师的水准

00:01:04.940 --> 00:01:06.100
时隔一整年

00:01:06.100 --> 00:01:07.580
行业内外都在观望

00:01:07.580 --> 00:01:09.980
当初的这番论断到底有没有应验

00:01:09.980 --> 00:01:11.160
面对这个问题

00:01:11.160 --> 00:01:13.400
杰弗迪恩没有选择夸大成果

00:01:13.400 --> 00:01:15.100
也没有刻意淡化进展

00:01:15.100 --> 00:01:17.300
他给出了一份非常务实的复盘

00:01:17.300 --> 00:01:21.400
在Agent的体系配合长周期运行时的编程任务当中

00:01:21.400 --> 00:01:25.240
大模型能力的迭代速度远远超出他此前的预估

00:01:25.240 --> 00:01:27.740
放到初级工程师的评判标准之下

00:01:27.740 --> 00:01:30.360
当初的判断大体上已经得到验证

00:01:30.360 --> 00:01:31.780
但同时他也坦诚

00:01:31.780 --> 00:01:35.360
自己严重低估了复杂任务处理能力的上涨幅度

00:01:35.360 --> 00:01:38.520
实际提升速度比事前的预判要快得多

00:01:38.520 --> 00:01:41.580
能力的提升并不单单局限在代码编写

00:01:41.580 --> 00:01:44.200
这个单一赛道Agent这套运行范式

00:01:44.200 --> 00:01:46.980
正在其他各式各样的业务场景当中

00:01:46.980 --> 00:01:49.060
展现出实实在在的价值

00:01:49.060 --> 00:01:50.300
顺着这个话题

00:01:50.300 --> 00:01:51.860
主持人继续向前追问

00:01:51.860 --> 00:01:53.780
把目光投向2027年

00:01:53.780 --> 00:01:56.780
想要听听属于杰弗迪恩的新一轮大胆预判

00:01:56.780 --> 00:01:58.580
他思索之后给出了答案

00:01:58.580 --> 00:02:01.740
核心落在机器学习系统的自我自动化上面

00:02:01.740 --> 00:02:02.680
简单来讲

00:02:02.680 --> 00:02:06.120
就是让AI系统自主开展大批量的实验工作

00:02:06.120 --> 00:02:09.920
把复杂的大问题拆解成若干个更小的子任务

00:02:09.920 --> 00:02:12.140
搭建一套闭环的自动实验循环

00:02:12.140 --> 00:02:14.080
完成子任务的处理之后

00:02:14.080 --> 00:02:16.520
再把分散的结果重新整合汇总

00:02:16.520 --> 00:02:18.960
以此完成自身能力的迭代升级

00:02:18.960 --> 00:02:22.200
这套全自动问题拆解搭配自动实验的思路

00:02:22.200 --> 00:02:24.680
并不单单局限于机器学习本身

00:02:24.680 --> 00:02:27.220
只要某一个科学或者工程领域

00:02:27.220 --> 00:02:30.120
能够建立起一套可以量化衡量的目标

00:02:30.120 --> 00:02:32.040
就有机会依靠这套模式

00:02:32.040 --> 00:02:33.380
拿到巨大的突破

00:02:33.380 --> 00:02:34.280
讲到这里

00:02:34.280 --> 00:02:37.100
主持人抛出一个很有历史氛围感的类比

00:02:37.100 --> 00:02:38.640
2001年的时候

00:02:38.640 --> 00:02:42.040
谷歌搜索还完全依靠硬盘完成数据读取

00:02:42.040 --> 00:02:44.100
杰弗迪恩和长期搭档桑杰

00:02:44.100 --> 00:02:46.980
通过餐金值演算完成一轮成本测算

00:02:46.980 --> 00:02:48.080
得出一个结论

00:02:48.080 --> 00:02:49.800
未来某一个时间节点

00:02:49.800 --> 00:02:51.160
整套搜索索引

00:02:51.160 --> 00:02:53.780
完全可以全部放进机器的内存之中

00:02:53.780 --> 00:02:54.820
基于这个判断

00:02:54.820 --> 00:02:58.720
两个人短短几天就迭代出全新版本的谷歌搜索

00:02:58.720 --> 00:03:00.780
不再依赖硬盘读取数据

00:03:00.780 --> 00:03:02.560
全部运行在内存当中

00:03:02.560 --> 00:03:06.780
这也成为谷歌搜索体验实现跨越时提升的关键转折点

00:03:06.780 --> 00:03:09.060
历史总是会出现相似的韵律

00:03:09.060 --> 00:03:10.760
那么放到2026年

00:03:10.760 --> 00:03:12.260
属于当下这个时代

00:03:12.260 --> 00:03:15.500
整套系统全部搬进内存的标志性时刻又会是什么

00:03:15.500 --> 00:03:17.340
现场6000名创业者

00:03:17.340 --> 00:03:20.380
又应当盯住哪些信号去设计自己的产品

00:03:20.380 --> 00:03:23.460
杰弗迪恩的回答把落脚点放在硬件层面

00:03:23.460 --> 00:03:26.980
它坦言当下的情况和当年谷歌搜索的故事

00:03:26.980 --> 00:03:28.320
并不能完全等同

00:03:28.320 --> 00:03:30.240
但有一个趋势是确定的

00:03:30.240 --> 00:03:33.220
高性能同时兼顾低能耗的推理硬件系统

00:03:33.220 --> 00:03:34.860
会迎来大规模普及

00:03:34.860 --> 00:03:36.820
整个行业已经形成共识

00:03:36.820 --> 00:03:39.340
推理环节才是让agent大规模面

00:03:39.340 --> 00:03:41.720
向普通用户落地的核心基石

00:03:41.720 --> 00:03:45.100
而延迟又是决定用户体验好坏的关键指标

00:03:45.100 --> 00:03:46.700
硬件走向专业化

00:03:46.700 --> 00:03:49.340
是整套系统相比通用GPU TPU设备

00:03:49.340 --> 00:03:51.240
实现更低功耗

00:03:51.240 --> 00:03:53.460
更低延迟最重要的实现路径

00:03:53.460 --> 00:03:57.000
我们所有人都已经习惯等待模型返回输出结果

00:03:57.000 --> 00:03:59.800
但等待本身并不是良好的用户体验

00:03:59.800 --> 00:04:01.360
速度才是一切的王道

00:04:01.360 --> 00:04:03.700
主持人继续顺着这个方向推进

00:04:03.700 --> 00:04:06.120
如果延迟可以直接降低50倍

00:04:06.120 --> 00:04:08.700
整个行业会发生什么样的变化

00:04:08.700 --> 00:04:11.240
紧接着又抛出另外一个值得深思的问题

00:04:11.240 --> 00:04:12.220
时至今日

00:04:12.220 --> 00:04:15.100
行业当中还有哪些被大家全盘接受

00:04:15.100 --> 00:04:18.320
但实际上已经不再成立的固有AI假设

00:04:18.320 --> 00:04:19.920
杰弗迪恩给出的回答

00:04:19.920 --> 00:04:21.660
会刷新不少人的固有认知

00:04:21.660 --> 00:04:23.200
绝大多数从业者

00:04:23.200 --> 00:04:24.800
还没有真正接纳一件事

00:04:24.800 --> 00:04:27.460
依托能力足够强的底层基座模型

00:04:27.460 --> 00:04:30.340
Agent并不只能运行短短一两个小时

00:04:30.340 --> 00:04:32.500
连续运转几天甚至几周

00:04:32.500 --> 00:04:34.760
去完成复杂度极高的任务

00:04:34.760 --> 00:04:37.160
这件事已经具备现实可行性

00:04:37.160 --> 00:04:38.800
现在小部分从业者

00:04:38.800 --> 00:04:40.040
已经看到苗头

00:04:40.040 --> 00:04:41.300
可绝大多数人

00:04:41.300 --> 00:04:43.180
并没有真正把这个可能性

00:04:43.180 --> 00:04:45.980
内化到自己的产品设计逻辑当中

00:04:45.980 --> 00:04:48.720
而这件事未来会释放出巨大的影响力

00:04:48.720 --> 00:04:51.560
很多人会好奇到底什么样的业务场景

00:04:51.560 --> 00:04:54.180
需要Agent连续运航数周的时间

00:04:54.180 --> 00:04:56.540
杰弗迪恩举了一个很具象的案例

00:04:56.540 --> 00:05:00.680
我们可以交给Agent一项完整的软件版本重构工作

00:05:00.680 --> 00:05:04.680
把一整套软件完整迁移到另外一门编程语言

00:05:04.680 --> 00:05:07.680
重构之后的版本可以实现安全性的提升

00:05:07.680 --> 00:05:09.400
或是运行性能的优化

00:05:09.400 --> 00:05:12.560
AI完全可以持续推进整套复杂工程

00:05:12.560 --> 00:05:14.400
把这项工作落地完成

00:05:14.400 --> 00:05:17.360
话题就此切换到TPU诞生的过往

00:05:17.360 --> 00:05:20.220
杰弗迪恩在行业里面广为流传的习惯

00:05:20.220 --> 00:05:21.840
就是餐巾纸数学

00:05:21.840 --> 00:05:25.780
也就是在餐巾纸上快速完成数量级层面的粗略估算

00:05:25.780 --> 00:05:27.920
时间回到2013年前后

00:05:27.920 --> 00:05:30.540
谷歌语音识别的效果迎来实质性的飞跃

00:05:30.540 --> 00:05:31.940
他做过一笔测算

00:05:31.940 --> 00:05:34.000
如果每一位谷歌手机用户

00:05:34.000 --> 00:05:36.900
每天仅仅使用三分钟的语音识别功能

00:05:36.900 --> 00:05:40.160
谷歌整体的服务器集群规模就需要直接翻倍

00:05:40.160 --> 00:05:43.360
对应的成本会膨胀到完全无法接受的地步

00:05:43.360 --> 00:05:45.180
为了解决这个现实难题

00:05:45.180 --> 00:05:47.180
团队决定自研专属芯片

00:05:47.180 --> 00:05:49.020
这也就是TPU的起源

00:05:49.020 --> 00:05:49.880
他回忆

00:05:49.880 --> 00:05:52.440
那时候深度学习驱动的语音系统

00:05:52.440 --> 00:05:53.800
对比旧有方案

00:05:53.800 --> 00:05:55.840
算力开销高出一大截

00:05:55.840 --> 00:05:57.960
但是错误率直接减半

00:05:57.960 --> 00:06:00.120
短短几个月时间就拿到过去

00:06:00.120 --> 00:06:02.960
20年语音识别领域积累下来的全部进步

00:06:02.960 --> 00:06:05.780
初代TPU没有办法运行Chrome浏览器

00:06:05.780 --> 00:06:07.840
也跑不了Word这类通用软件

00:06:07.840 --> 00:06:10.020
但是在机器学习推理场景当中

00:06:10.020 --> 00:06:11.300
拥有极强的针对性

00:06:11.300 --> 00:06:13.260
最终落地的初代芯片

00:06:13.260 --> 00:06:15.080
对比CPU和GPU

00:06:15.080 --> 00:06:17.520
能效可以提升30到80倍

00:06:17.520 --> 00:06:19.600
延迟下降20到30倍

00:06:19.600 --> 00:06:21.880
打下了非常扎实的技术底子

00:06:21.880 --> 00:06:24.820
后续TPU才一步步迭代成如今的模样

00:06:24.820 --> 00:06:28.200
有意思的地方在于团队研发TPU的那个阶段

00:06:28.200 --> 00:06:30.160
Transformer架构还没有问世

00:06:30.160 --> 00:06:34.720
没有人能够预料到后续TPU会成为整个AI产业的基石硬件

00:06:34.720 --> 00:06:36.040
也正是因为这样

00:06:36.040 --> 00:06:40.560
当时团队的设计思路是打造一套通用线性怠数运算系统

00:06:40.560 --> 00:06:44.320
而不是死死绑定某一套特定算法做极致专用化

00:06:44.320 --> 00:06:47.620
机器学习算法永远处在持续演化的进程当中

00:06:47.620 --> 00:06:49.220
硬件不能过度定制

00:06:49.220 --> 00:06:51.480
但是又要保留足够的专用属性

00:06:51.480 --> 00:06:53.300
以此拿到巨大的性能收益

00:06:53.300 --> 00:06:55.400
比如做大规格乘法运算单元

00:06:55.400 --> 00:06:56.700
配置高速内存

00:06:56.700 --> 00:06:58.180
搭建高速互联通路

00:06:58.180 --> 00:07:01.980
后续几代TPU更是优化多芯片协同工作的能力

00:07:01.980 --> 00:07:05.380
让大量芯片可以联合处理同一个复杂任务

00:07:05.380 --> 00:07:06.480
主持人接着提问

00:07:06.480 --> 00:07:07.480
放到今天

00:07:07.480 --> 00:07:10.160
创业者又该做怎样的餐巾纸数学

00:07:10.160 --> 00:07:12.720
能不能依靠简单的数量级估算

00:07:12.720 --> 00:07:16.240
挖掘出下一代如同TPO一般重量级的创新

00:07:16.240 --> 00:07:17.420
杰弗蒂恩表示

00:07:17.420 --> 00:07:19.480
这件事没有统一标准答案

00:07:19.480 --> 00:07:21.880
但是底层思考逻辑是相通的

00:07:21.880 --> 00:07:24.800
首先找准自己所在赛道真正的瓶颈

00:07:24.800 --> 00:07:26.120
再去反问自己

00:07:26.120 --> 00:07:29.920
是否存在一套和当下主流方案完全不一样的解法

00:07:29.920 --> 00:07:33.440
能不能把核心指标抬升一个甚至两个数量级

00:07:33.440 --> 00:07:36.980
不要被市面上已经成熟的实现方案束缚住思路

00:07:36.980 --> 00:07:38.940
回归第一性原理去思考

00:07:38.940 --> 00:07:41.040
如果从零开始解决这个问题

00:07:41.040 --> 00:07:42.860
自己会选择什么样的路径

00:07:42.860 --> 00:07:45.460
往往就能够挖掘出别人看不见的机会

00:07:45.460 --> 00:07:47.060
随后主持人问到一个

00:07:47.060 --> 00:07:49.140
只有内行才会深究的话题

00:07:49.140 --> 00:07:52.600
多年以前杰弗迪恩写过一份流传极广的清单

00:07:52.600 --> 00:07:56.160
名字叫做每个工程师都应该知道的延迟数字

00:07:56.160 --> 00:07:58.560
里面记录缓存未命中的耗石

00:07:58.560 --> 00:08:00.000
磁盘寻道耗石

00:08:14.280 --> 00:08:17.660
杰弗迪恩列举出一系列至关重要的硬件数字

00:08:17.660 --> 00:08:20.600
储存到加速器片上内存之间的带宽

00:08:20.600 --> 00:08:22.880
通往乘法运算单元的带宽

00:08:22.880 --> 00:08:25.700
完成一次乘法运算需要消耗的能量

00:08:25.700 --> 00:08:27.980
芯片与芯片之间的互联带宽

00:08:27.980 --> 00:08:31.220
在该带宽条件之下可以联动多少颗芯片

00:08:31.220 --> 00:08:35.240
还有从500颗芯片扩展到1万颗芯片的规模过程当中

00:08:35.240 --> 00:08:37.980
网络带宽会出现多大程度的衰减

00:08:37.980 --> 00:08:42.360
这些底层数字会实实在在约束上层业务问题的解法

00:08:42.360 --> 00:08:46.440
紧接着他抛出一个足以改变很多人AI系统设计思路的数据

00:08:46.440 --> 00:08:49.940
完成一次计算消耗的能量大概在EP焦2级别

00:08:49.940 --> 00:08:51.800
但是完成一次数据搬运

00:08:51.800 --> 00:08:52.980
一次IO操作

00:08:52.980 --> 00:08:55.300
消耗的能量是前者的1000倍

00:08:55.300 --> 00:08:59.780
就算只是把数据从加速器的高带宽内存搬运到处理器内部

00:08:59.780 --> 00:09:00.860
参与运算

00:09:00.860 --> 00:09:03.160
能量开销同样会急剧拉高

00:09:03.160 --> 00:09:07.600
搬数据的代价远远高于做计算这条物理层面的硬约数

00:09:07.600 --> 00:09:10.540
塑造了机器学习领域大量的工程选择

00:09:10.540 --> 00:09:13.160
如果不存在如此悬殊的能耗差距

00:09:13.160 --> 00:09:15.600
我们就不需要对数据做批量处理

00:09:15.600 --> 00:09:17.480
可现实条件摆在眼前

00:09:17.480 --> 00:09:21.620
工程师只能把大量样本或者token攒成批次统一处理

00:09:21.620 --> 00:09:24.680
以此贪薄数据搬运带来的巨大能耗惩罚

00:09:24.680 --> 00:09:26.160
把1000倍的开销

00:09:26.160 --> 00:09:28.380
稀释为1000除以批次规模

00:09:28.380 --> 00:09:31.380
但如果我们追求极低延迟的推理表现

00:09:31.380 --> 00:09:34.100
批量处理这套逻辑就会变成阻碍

00:09:34.100 --> 00:09:35.880
底层硬件的能量约束

00:09:35.880 --> 00:09:39.180
会自上而下影响整套AI系统的每一层设计

00:09:39.180 --> 00:09:40.460
主持人继续追问

00:09:40.460 --> 00:09:43.960
那我们有没有机会实现单条数据的处理模式

00:09:43.960 --> 00:09:47.540
杰弗迪恩表示自己现阶段思考更多的是推理测的问题

00:09:47.540 --> 00:09:50.760
推理业务天然对低延迟有着强烈诉求

00:09:50.760 --> 00:09:53.700
训练环节对此的要求反而没有那么严苛

00:09:53.700 --> 00:09:54.800
在他看来

00:09:54.800 --> 00:09:56.600
推理硬件的专用化程度

00:09:56.600 --> 00:09:58.580
如今远远还没有抵达上线

00:09:58.580 --> 00:09:59.920
核心优化方向

00:09:59.920 --> 00:10:02.760
一方面是尽可能压缩数据搬运的频次

00:10:02.760 --> 00:10:05.220
另一方面去探索极低精度运算

00:10:05.220 --> 00:10:08.400
不需要硬件去兼容五花八门的精度规格

00:10:08.400 --> 00:10:10.360
把业务真正需要的精度

00:10:10.360 --> 00:10:12.440
直接固化到硬件设计当中

00:10:12.440 --> 00:10:14.520
聊完硬件层面的种种约束

00:10:14.520 --> 00:10:16.420
对话把视角向上拉高

00:10:16.420 --> 00:10:18.460
过去大家谈及AI进步

00:10:18.460 --> 00:10:20.760
惯性思维就是模型规模更大

00:10:20.760 --> 00:10:22.240
训练数据更多

00:10:22.240 --> 00:10:23.520
参数体量上涨

00:10:23.520 --> 00:10:24.800
训练时间拉长

00:10:24.800 --> 00:10:25.960
但是最近几年

00:10:25.960 --> 00:10:27.400
真正拉开差距的

00:10:27.400 --> 00:10:28.820
不再只有模型本体

00:10:28.820 --> 00:10:31.100
模型外围的整套配套体系

00:10:31.100 --> 00:10:32.800
价值正在持续走高

00:10:32.800 --> 00:10:35.560
不单单要看参数规模和训练数据集

00:10:35.560 --> 00:10:36.480
检索工具

00:10:36.480 --> 00:10:37.400
记忆模块

00:10:37.400 --> 00:10:38.040
Agent

00:10:38.040 --> 00:10:38.760
工具链

00:10:38.760 --> 00:10:41.040
全部都是不可或缺的组成部分

00:10:41.040 --> 00:10:42.880
杰弗迪恩认同这样的看法

00:10:42.880 --> 00:10:45.320
模型只是整套解决方案当中的

00:10:45.320 --> 00:10:46.320
其中一块拼图

00:10:46.320 --> 00:10:47.540
我们真正的目标

00:10:47.540 --> 00:10:49.140
是搭建一整套

00:10:49.140 --> 00:10:52.020
可以解决复杂现实问题的完整系统

00:10:52.020 --> 00:10:53.900
这就意味着模型要学会

00:10:53.900 --> 00:10:55.560
调用各式各样的外部工具

00:10:55.560 --> 00:10:57.540
检索外部相关信息

00:10:57.540 --> 00:10:59.100
留存过往处理其他任务

00:10:59.100 --> 00:11:00.480
沉淀下来的历史信息

00:11:00.480 --> 00:11:01.900
并且把这些信息

00:11:01.900 --> 00:11:03.780
带入当下的上下文当中

00:11:03.780 --> 00:11:05.660
这里有一个很关键的区别

00:11:05.660 --> 00:11:08.080
训练数据就像是一锅大杂烩

00:11:08.080 --> 00:11:10.360
数万亿token混杂在一起

00:11:10.360 --> 00:11:13.280
压缩近几千亿的模型参数内部

00:11:13.280 --> 00:11:13.920
与之对比

00:11:13.920 --> 00:11:17.060
模型在处理具体任务时拿到的上下文信息

00:11:17.060 --> 00:11:18.440
逻辑会清晰很多

00:11:18.440 --> 00:11:20.900
同时模型还要识别可用的工具

00:11:20.900 --> 00:11:23.320
判断哪些工具适配当前步骤

00:11:23.320 --> 00:11:26.280
如何把大任务拆解成一连串工具调用

00:11:26.280 --> 00:11:28.920
甚至尝试多条不同的解题路径

00:11:28.920 --> 00:11:30.980
再评估各个方案的实际效果

00:11:30.980 --> 00:11:34.920
这就是复杂agent以及dooragent编排的核心能力

00:11:34.920 --> 00:11:37.440
上下文工程这个方向很有意思的一点

00:11:37.440 --> 00:11:39.720
使它的准入门槛相对更低

00:11:39.720 --> 00:11:41.840
训练大模型需要海量算力

00:11:41.840 --> 00:11:43.340
海量数据资源

00:11:43.340 --> 00:11:44.900
普通团队很难触碰

00:11:44.900 --> 00:11:46.460
但是做上下文工程

00:11:46.460 --> 00:11:49.340
只需要调用Gemini这类模型的API接口

00:11:49.340 --> 00:11:51.680
再搭配自己搭建的检索逻辑

00:11:51.680 --> 00:11:53.040
工具调用流程

00:11:53.040 --> 00:11:54.160
工作流编排

00:11:54.160 --> 00:11:55.540
就可以动手实践

00:11:55.540 --> 00:11:57.960
想要把上下文工程做到足够强

00:11:57.960 --> 00:12:01.060
杰弗迪恩给出一套非常务实的实操思路

00:12:01.060 --> 00:12:03.360
就是实实在在拿模型和工具链

00:12:03.360 --> 00:12:04.580
去处理真实业务

00:12:04.580 --> 00:12:07.320
在实操当中观察模型的出错点位

00:12:07.320 --> 00:12:09.660
很多时候想要提升模型表现

00:12:09.660 --> 00:12:12.180
并不需要去改动底层模型权重

00:12:12.180 --> 00:12:14.360
而是提供质量更高的指引

00:12:14.360 --> 00:12:16.400
编写更完善的技能描述

00:12:16.400 --> 00:12:18.440
告诉模型面对某一类问题

00:12:18.440 --> 00:12:19.940
应当如何调用工具

00:12:19.940 --> 00:12:21.280
反复迭代之后

00:12:21.280 --> 00:12:22.780
你就会慢慢摸清楚

00:12:22.780 --> 00:12:24.480
模型还缺少哪些信息

00:12:24.480 --> 00:12:27.400
由此进入自我迭代优化的正向循环

00:12:27.400 --> 00:12:29.400
他分享了一段亲身经历

00:12:29.400 --> 00:12:30.300
几周之前

00:12:30.300 --> 00:12:33.240
他和桑杰一起做底层代码库的性能调优

00:12:33.240 --> 00:12:36.560
团队内部有自研的微型基准测试库

00:12:36.560 --> 00:12:38.640
可以统计各类操作的耗时

00:12:38.640 --> 00:12:42.280
这套数据结构被谷歌内部几百万个进程调用

00:12:42.280 --> 00:12:44.380
性能表现必须得到保障

00:12:44.380 --> 00:12:46.020
在没有Agent的时代

00:12:46.020 --> 00:12:48.500
完整流程是先测试现有性能

00:12:48.500 --> 00:12:49.480
修改代码

00:12:49.480 --> 00:12:51.120
重新跑基准测试

00:12:51.120 --> 00:12:52.600
观察性能变化

00:12:52.600 --> 00:12:54.560
还要执行更大范围的测试

00:12:54.560 --> 00:12:56.800
检查缓存占用等一系列指标

00:12:56.800 --> 00:12:59.060
后来他们专门编写对应的技能

00:12:59.060 --> 00:13:01.860
教会Agent完整复刻整套工作流

00:13:01.860 --> 00:13:03.260
执行基准测试

00:13:03.260 --> 00:13:04.460
修改代码

00:13:04.460 --> 00:13:05.900
重新叫验性能指标

00:13:05.900 --> 00:13:07.480
《循环迭代优化》

00:13:07.480 --> 00:13:10.500
这套方案在部分问题上拿到相当不错的效果

00:13:10.500 --> 00:13:13.320
本质上就是把人类工程师的工作流程

00:13:13.320 --> 00:13:16.080
转化成模型能够读懂执行的指令

00:13:16.080 --> 00:13:17.100
几个月之前

00:13:17.100 --> 00:13:20.440
他和桑杰共同发布过一份30页左右的公开文档

00:13:20.440 --> 00:13:22.980
名字叫做Performance Heightened TS

00:13:22.980 --> 00:13:25.480
记录大量性能优化的实操技巧

00:13:25.480 --> 00:13:29.060
已经有不少开发者把这份文档做总结提炼之后

00:13:29.060 --> 00:13:30.520
投入给不同的大模型

00:13:30.520 --> 00:13:32.480
最终测试结果显示

00:13:32.480 --> 00:13:35.760
模型分析代码性能问题的能力得到明显提升

00:13:35.760 --> 00:13:38.640
而且这份资料对所有人完全公开

00:13:38.640 --> 00:13:39.780
谈及agent

00:13:39.780 --> 00:13:42.240
有一个所有人都会碰到的现实痛点

00:13:42.240 --> 00:13:45.940
不少agent在前十几步执行都十分顺畅

00:13:45.940 --> 00:13:47.400
等到推进到第三十步

00:13:47.400 --> 00:13:48.120
四十步

00:13:48.120 --> 00:13:49.360
甚至五十步之后

00:13:49.360 --> 00:13:51.040
就会开始逻辑跑偏

00:13:51.040 --> 00:13:52.420
杰弗迪恩坦言

00:13:52.420 --> 00:13:54.980
这就是当下技术最大的约束条件

00:13:54.980 --> 00:13:58.360
一部分原因是模型处理训练机之外的任务

00:13:58.360 --> 00:14:00.120
一旦脱离熟悉的任务分布

00:14:00.120 --> 00:14:01.420
效果就会下滑

00:14:01.420 --> 00:14:03.620
偏离熟悉的边界越远

00:14:03.620 --> 00:14:04.760
失效概率就越高

00:14:04.760 --> 00:14:05.780
针对该问题

00:14:05.780 --> 00:14:07.880
有两条可行的解决路径

00:14:07.880 --> 00:14:08.560
第一种

00:14:08.560 --> 00:14:10.920
编写对应的技能和提示之意

00:14:10.920 --> 00:14:13.240
尽量让模型维持在自己熟悉

00:14:13.240 --> 00:14:15.060
成功率更高的执行路径

00:14:15.060 --> 00:14:15.840
第二种

00:14:15.840 --> 00:14:17.400
采用多agent的架构

00:14:17.400 --> 00:14:18.880
让多个独立agent

00:14:18.880 --> 00:14:20.780
并行尝试不同解题思路

00:14:20.780 --> 00:14:23.100
再交由另外一个模型或者agent

00:14:23.100 --> 00:14:24.920
去评判各个路径的可行性

00:14:24.920 --> 00:14:27.120
本质就是对全部可行解法

00:14:27.120 --> 00:14:28.080
做搜索筛选

00:14:28.080 --> 00:14:29.640
保留有希望的分支

00:14:29.640 --> 00:14:31.540
丢弃无效跑偏的分支

00:14:31.540 --> 00:14:32.780
依靠推理计算

00:14:32.780 --> 00:14:34.460
去便利解决方案空间

00:14:34.460 --> 00:14:36.880
以此提升常链路Agent的定性

00:14:36.880 --> 00:14:40.000
在谷歌内部就搭建了一整套调度框架

00:14:40.000 --> 00:14:41.220
以及海量技能库

00:14:41.220 --> 00:14:43.340
Agent可以调用内部编码工具

00:14:43.340 --> 00:14:44.660
执行代码审查

00:14:44.660 --> 00:14:45.980
完成性能测试

00:14:45.980 --> 00:14:47.300
读取日志文件

00:14:47.300 --> 00:14:49.040
只要技能定义足够合理

00:14:49.040 --> 00:14:51.680
Agent的实用价值就会被大幅释放

00:14:51.680 --> 00:14:52.480
紧接着

00:14:52.480 --> 00:14:55.900
对话落到在场每一位创业者都无比关心的命题

00:14:55.900 --> 00:14:58.960
谷歌能够做到从处理器到上层产品

00:14:58.960 --> 00:15:00.480
全链路协同设计

00:15:00.480 --> 00:15:03.340
那对于两三个人组成的小型创业团队

00:15:03.340 --> 00:15:05.600
还剩下哪些可以抓住的机会

00:15:05.600 --> 00:15:06.980
杰弗迪恩讲到

00:15:06.980 --> 00:15:09.320
谷歌以及通用大模型团队

00:15:09.320 --> 00:15:11.880
都在竭尽全力打造通用性极强

00:15:11.880 --> 00:15:14.480
几乎可以处理各类任务的基座模型

00:15:14.480 --> 00:15:17.020
但恰恰是追求通用这个前提

00:15:17.020 --> 00:15:19.980
导致它很难针对某一个垂直细分领域

00:15:19.980 --> 00:15:21.060
做深度打磨

00:15:21.060 --> 00:15:22.280
如果创业团队

00:15:22.280 --> 00:15:25.640
可以针对特定行业打磨优质的产品交互界面

00:15:25.640 --> 00:15:27.460
配套专属的技能体系

00:15:27.460 --> 00:15:29.820
甚至是垂直微调的专用模型

00:15:29.820 --> 00:15:32.600
完全有机会建立起明显的竞争优势

00:15:32.600 --> 00:15:34.120
打造出体验流畅

00:15:34.120 --> 00:15:36.060
准确率出色的垂直产品

00:15:36.060 --> 00:15:37.800
不过他也做出提醒

00:15:37.800 --> 00:15:40.400
通用模型的能力还在持续变强

00:15:40.400 --> 00:15:42.340
覆盖的场景不断扩张

00:15:42.340 --> 00:15:44.200
创业者必须做好判断

00:15:44.200 --> 00:15:45.520
自己选择的赛道

00:15:45.520 --> 00:15:47.360
是未来半年到12个月

00:15:47.360 --> 00:15:48.880
就会被通用模型覆盖

00:15:48.880 --> 00:15:50.220
还是两三年之内

00:15:50.220 --> 00:15:51.820
通用模型都难以企及

00:15:51.820 --> 00:15:54.220
以此判断赛道的抗风险能力

00:15:54.220 --> 00:15:56.240
那创业者应当如何筛选

00:15:56.240 --> 00:15:57.620
值得投入的方向

00:15:57.620 --> 00:15:59.400
他给出的第一条建议朴素

00:15:59.400 --> 00:16:00.000
但是分类

00:16:15.000 --> 00:16:16.640
往往代表存在机会

00:16:16.640 --> 00:16:18.460
如果已经可以完成一部分

00:16:18.460 --> 00:16:20.040
只是效果不够完美

00:16:20.040 --> 00:16:21.380
反而要提高警惕

00:16:21.380 --> 00:16:23.760
这代表能力的种子已经存在

00:16:23.760 --> 00:16:25.560
只需要补充训练数据

00:16:25.560 --> 00:16:26.980
扩大模型规模

00:16:26.980 --> 00:16:28.640
能力就会快速迭代

00:16:28.640 --> 00:16:31.160
所以要优先寻找当下通用模型

00:16:31.160 --> 00:16:33.980
成功率只有0%或者1%的问题

00:16:33.980 --> 00:16:36.220
而不是20%左右的赛道

00:16:36.220 --> 00:16:37.280
这类机会

00:16:37.280 --> 00:16:40.300
一部分属于训练分布之外的全新任务

00:16:40.300 --> 00:16:41.300
另一类场景

00:16:41.300 --> 00:16:43.300
是产品可以拿到通用模型

00:16:43.300 --> 00:16:44.900
接触不到的私有数据

00:16:45.000 --> 00:16:47.100
比如处理用户个人信息的产品

00:16:47.100 --> 00:16:50.160
通用模型本身无法获取用户私人资料

00:16:50.160 --> 00:16:51.720
这就创造天然壁垒

00:16:51.720 --> 00:16:52.960
还有一类机会

00:16:52.960 --> 00:16:54.320
针对高难度问题

00:16:54.320 --> 00:16:57.020
以可控成本训练垂直专用模型

00:16:57.020 --> 00:16:58.520
换取极高精度

00:16:58.520 --> 00:17:00.680
AlphaFold就是典型案例

00:17:00.680 --> 00:17:03.860
面向蛋白质折叠的专用模型取得巨大成功

00:17:03.860 --> 00:17:05.480
却并非通用大模型

00:17:05.480 --> 00:17:06.440
材料科学

00:17:06.440 --> 00:17:09.920
芯片设计领域也存在同类的落地可能性

00:17:09.920 --> 00:17:12.340
怎样成长为AI原生的创始人

00:17:12.340 --> 00:17:13.140
他提到

00:17:13.140 --> 00:17:14.920
和虚拟agent的协作的时候

00:17:14.920 --> 00:17:16.840
把需求描述的越清晰

00:17:16.840 --> 00:17:18.720
最终产出效果就越好

00:17:18.720 --> 00:17:20.460
需求定义足够明确

00:17:20.460 --> 00:17:22.540
Agent就拥有清晰的边界

00:17:22.540 --> 00:17:23.880
明白自身的目标

00:17:23.880 --> 00:17:25.980
从很早的计算机发展阶段

00:17:25.980 --> 00:17:28.420
工程师就被要求开发软件之前

00:17:28.420 --> 00:17:29.880
梳理清楚产品规格

00:17:29.880 --> 00:17:32.540
如今只是把执行工作交给Agent

00:17:32.540 --> 00:17:35.140
明确规格这件事反而变得更加关键

00:17:35.140 --> 00:17:37.160
人类工程师可以读懂语境

00:17:37.160 --> 00:17:38.780
主动反问确认细节

00:17:38.780 --> 00:17:41.080
Agent虽然部分场景可以追问

00:17:41.080 --> 00:17:44.300
但整体还是高度依赖清晰完备的需求描述

00:17:44.300 --> 00:17:46.680
现在代码迁移类的Coding Agent

00:17:46.680 --> 00:17:47.700
效果出众

00:17:47.700 --> 00:17:49.740
背后的原因也正在于此

00:17:49.740 --> 00:17:53.020
把一套软件从一门语言迁移到另一门语言

00:17:53.020 --> 00:17:55.420
原始代码本身就是完整的规格

00:17:55.420 --> 00:17:57.640
原有测试用力可以直接复用

00:17:57.640 --> 00:17:59.000
同时完成迁移

00:17:59.000 --> 00:18:01.380
持续比对新旧版本行为差异

00:18:01.380 --> 00:18:03.100
直到二者表现对齐

00:18:03.100 --> 00:18:04.880
正是规格足够明确

00:18:04.880 --> 00:18:07.100
才造就这类任务亮眼的表现

00:18:07.100 --> 00:18:09.220
未来大规模调度数百个Agent

00:18:09.220 --> 00:18:10.080
成为常态

00:18:10.080 --> 00:18:11.880
大量代码由Agent生成

00:18:11.880 --> 00:18:13.740
什么能力会变得最为稀缺

00:18:13.740 --> 00:18:15.800
杰弗·迪恩给出的答案是品位

00:18:15.800 --> 00:18:19.440
也就是判断哪些问题值得交给agent去解决

00:18:19.440 --> 00:18:21.900
放到研究领域大部分的成败

00:18:21.900 --> 00:18:24.760
从选择研究课题的那一刻就已经注定

00:18:24.760 --> 00:18:26.100
手握全套工具

00:18:26.100 --> 00:18:28.120
不如选对值得投入的问题

00:18:28.120 --> 00:18:30.180
把普通问题打磨得再精致

00:18:30.180 --> 00:18:32.720
也比不上攻克一个高价值的难题

00:18:32.720 --> 00:18:35.540
但是品位本身没有标准化的考核指标

00:18:35.540 --> 00:18:36.880
应当如何训练

00:18:36.880 --> 00:18:39.120
一部分来源于大量项目经验

00:18:39.120 --> 00:18:41.480
经手足够多不同类型的问题

00:18:41.480 --> 00:18:43.620
慢慢积累对机会的判断力

00:18:43.620 --> 00:18:45.060
还有一个实操办法

00:18:45.060 --> 00:18:46.880
写下未来12个月之内

00:18:46.880 --> 00:18:49.260
自己预判会迎来爆发的方向

00:18:49.260 --> 00:18:52.000
后续只挑选其中一部分落地

00:18:52.000 --> 00:18:53.820
12个月之后回头复盘

00:18:53.820 --> 00:18:55.460
看看哪些预判成真

00:18:55.460 --> 00:18:57.140
哪些被其他人实现

00:18:57.140 --> 00:18:58.640
哪些完全没有发生

00:18:58.640 --> 00:19:00.960
相当于给自己制造大量样本

00:19:00.960 --> 00:19:02.660
反向训练自己的判断力

00:19:02.660 --> 00:19:05.720
第三种方式就是做疯狂的思想实验

00:19:05.720 --> 00:19:08.780
不要把行业默认的前提全部当成真理

00:19:08.780 --> 00:19:11.540
他分享了一段和同事开展的思想实验

00:19:11.540 --> 00:19:12.660
过去60年

00:19:12.660 --> 00:19:14.220
芯片设计制造行业

00:19:14.220 --> 00:19:16.420
都在拼命缩小晶体管尺寸

00:19:16.420 --> 00:19:17.880
压低出错概率

00:19:17.880 --> 00:19:19.900
默认目标就是同一款芯片

00:19:19.900 --> 00:19:22.040
每一颗成品都应当完全一致

00:19:22.040 --> 00:19:23.600
不能出现比特翻转

00:19:23.600 --> 00:19:24.940
但是宏观层面

00:19:24.940 --> 00:19:27.520
大规模分布式系统的逻辑恰恰相反

00:19:27.520 --> 00:19:29.440
依靠不可靠的硬件组件

00:19:29.440 --> 00:19:31.040
搭建高可靠系统

00:19:31.040 --> 00:19:32.180
磁盘会损坏

00:19:32.180 --> 00:19:33.880
但是数据不能丢失

00:19:33.880 --> 00:19:35.420
于是做多副本

00:19:35.420 --> 00:19:36.680
使用纠缠码

00:19:36.680 --> 00:19:38.240
可是这套容错思路

00:19:38.240 --> 00:19:40.340
并没有下放到晶体管这一层

00:19:40.340 --> 00:19:41.900
如果设计一套芯片

00:19:41.900 --> 00:19:44.580
晶体管每天会出现20次错误

00:19:44.580 --> 00:19:46.920
而不是几百万年才出现一次故障

00:19:46.920 --> 00:19:48.940
整套系统会走向何方

00:19:48.940 --> 00:19:51.680
制造工艺或许会迎来全新可能性

00:19:51.680 --> 00:19:53.980
信号传输采用多条冗余通路

00:19:53.980 --> 00:19:56.280
保障至少一路信号可以送达

00:19:56.280 --> 00:19:59.500
这套逻辑和人脑神经信号传递十分相似

00:19:59.500 --> 00:20:02.220
大脑信号传输本身就不是绝对可靠

00:20:02.220 --> 00:20:05.220
重要信息就依靠多条通路同时传递

00:20:05.220 --> 00:20:08.020
它并不是说当下就要落地这套方案

00:20:08.020 --> 00:20:10.300
但是这类思想实验意义重大

00:20:10.300 --> 00:20:13.500
要定期重新审视所有人习以为常的预设

00:20:13.500 --> 00:20:15.120
回顾他的职业生涯

00:20:15.120 --> 00:20:19.100
TPU的诞生就是推翻固有假设之后接触的果实

00:20:19.100 --> 00:20:21.400
在问题还没有成为主流的时候

00:20:21.400 --> 00:20:23.720
思考小众场景的专用硬件

00:20:23.720 --> 00:20:25.420
MapReduce也是同理

00:20:25.420 --> 00:20:28.000
团队厌倦了手工编写大量并行

00:20:28.000 --> 00:20:29.840
容错相关的重复代码

00:20:29.840 --> 00:20:31.920
于是提出全新抽象框架

00:20:31.920 --> 00:20:34.340
上层只需要编写业务逻辑

00:20:34.340 --> 00:20:36.920
底层统一处理并行调度和容错

00:20:36.920 --> 00:20:40.040
最后成为谷歌大规模计算的核心底座

00:20:40.040 --> 00:20:41.640
而这一切的源头

00:20:41.640 --> 00:20:43.340
同样来自思想实验

00:20:43.340 --> 00:20:45.700
现在有Alpha Chip辅助芯片布局

00:20:45.700 --> 00:20:48.560
有Alpha UVO完成方案生成评估留存

00:20:48.560 --> 00:20:50.620
整套AI制造AI的体系

00:20:50.620 --> 00:20:51.900
正在逐步成型

00:20:51.900 --> 00:20:52.880
广义来讲

00:20:52.880 --> 00:20:55.320
这本质就是科学方法的自动化

00:20:55.320 --> 00:20:56.380
提出假设

00:20:56.380 --> 00:20:57.440
搭建环境

00:20:57.440 --> 00:20:58.360
执行实验

00:20:58.360 --> 00:20:59.380
评估结果

00:20:59.380 --> 00:21:01.040
循环往复推进迭代

00:21:01.040 --> 00:21:02.560
如今越来越多领域

00:21:02.560 --> 00:21:04.200
可以把这套闭环自动化

00:21:04.200 --> 00:21:06.100
一次性执行海量实验

00:21:06.100 --> 00:21:07.520
压缩循环延迟

00:21:07.520 --> 00:21:08.780
就变得格外关键

00:21:08.780 --> 00:21:11.620
前提是评估器本身要足够快速

00:21:11.620 --> 00:21:13.620
他举了一个十年之前的案例

00:21:13.620 --> 00:21:15.300
同事研究量子化学

00:21:15.300 --> 00:21:16.620
解析分子属性

00:21:16.620 --> 00:21:18.480
传统密度泛含理论模拟器

00:21:18.480 --> 00:21:20.060
跑一次就要耗费一整夜

00:21:20.060 --> 00:21:22.540
团队收集大量输入输出样本

00:21:22.540 --> 00:21:24.760
训练神经网络近似模拟器

00:21:24.760 --> 00:21:26.500
速度提升30万倍

00:21:26.500 --> 00:21:28.480
精度却几乎没有损失

00:21:28.480 --> 00:21:30.220
彻底改写科研模式

00:21:30.220 --> 00:21:32.320
从前筛选1000万候选分子

00:21:32.320 --> 00:21:34.040
要耗费6个月筹备算力

00:21:34.040 --> 00:21:35.580
现在一顿午饭的时间

00:21:35.580 --> 00:21:36.760
就可以完成筛选

00:21:36.760 --> 00:21:39.780
大量行业还有机会打造高速仿真模型

00:21:39.780 --> 00:21:40.720
一旦实现

00:21:40.720 --> 00:21:43.620
整个实验迭代周期就会被彻底重构

00:21:43.620 --> 00:21:45.140
它最看好的方向

00:21:45.140 --> 00:21:47.080
就是模型依靠大量实验

00:21:47.080 --> 00:21:48.900
实现地规式自我改进

00:21:48.900 --> 00:21:50.880
持续提升每一份算力

00:21:50.880 --> 00:21:52.300
可以产出的新发现

00:21:52.300 --> 00:21:53.900
对话推进到后半段

00:21:53.900 --> 00:21:55.460
谈及职业路上的挫折

00:21:55.460 --> 00:21:56.900
2014年杰弗蒂恩

00:21:56.900 --> 00:21:57.960
杰弗里辛顿

00:21:57.960 --> 00:21:59.400
奥里奥尔维尼亚尔斯

00:21:59.400 --> 00:22:01.400
联合发布知识蒸馏论文

00:22:01.400 --> 00:22:03.340
用大模型充当老师

00:22:03.340 --> 00:22:04.860
小模型充当学生

00:22:04.860 --> 00:22:06.120
得到体积更小

00:22:06.120 --> 00:22:07.000
成本更低

00:22:07.000 --> 00:22:08.600
同时效果优异的模型

00:22:08.600 --> 00:22:11.000
如今整个行业都在广泛使用

00:22:11.000 --> 00:22:13.700
但是这篇论文当年被NIPS聚稿

00:22:13.700 --> 00:22:15.000
评审的观点认为

00:22:15.000 --> 00:22:16.900
这项工作很难带来重大突破

00:22:16.900 --> 00:22:18.060
杰弗迪恩表示

00:22:18.060 --> 00:22:19.660
并不责怪评审委员会

00:22:19.660 --> 00:22:21.320
对方站在学术视角

00:22:21.320 --> 00:22:24.100
评判是否属于理论层面的重大突破

00:22:24.100 --> 00:22:26.980
而团队清楚这件事巨大的工程价值

00:22:26.980 --> 00:22:29.280
目标是降低模型服务成本

00:22:29.280 --> 00:22:30.680
扩大落地场景

00:22:30.680 --> 00:22:33.800
他们把论文上传到ARXV预印本平台

00:22:33.800 --> 00:22:35.580
行业从业者阅读之后

00:22:35.580 --> 00:22:36.640
大量落地使用

00:22:36.640 --> 00:22:38.800
Gemini当中的Flash系列模型

00:22:38.800 --> 00:22:41.920
就有一部分来自大尺寸Pro模型的蒸馏

00:22:41.920 --> 00:22:43.660
在同规格模型当中

00:22:43.660 --> 00:22:45.520
基准测试表现十分靠前

00:22:45.520 --> 00:22:47.360
这件事带来的启示就是

00:22:47.360 --> 00:22:49.040
就算成果遭到拒绝

00:22:49.040 --> 00:22:50.280
也不要停下脚步

00:22:50.280 --> 00:22:51.820
如果把1999年

00:22:51.820 --> 00:22:55.140
刚刚加入只有20人规模谷歌的年轻杰弗迪恩

00:22:55.140 --> 00:22:57.080
直接传送到2026年

00:22:57.080 --> 00:22:59.340
他会选择大厂前沿实验室

00:22:59.340 --> 00:23:01.020
还是选择自主创业

00:23:01.020 --> 00:23:02.840
他表示没有标准答案

00:23:02.840 --> 00:23:04.236
最核心的判断表现

00:23:17.036 --> 00:23:18.616
创业公司风险更高

00:23:18.616 --> 00:23:20.196
必须拥有极强的热情

00:23:20.196 --> 00:23:22.036
但也可以收获极高的回报

00:23:22.036 --> 00:23:23.776
无论选择哪一条道路

00:23:23.776 --> 00:23:24.976
都要反问自己

00:23:24.976 --> 00:23:27.016
如果项目走到最好的结局

00:23:27.016 --> 00:23:28.876
世界会不会切实变好

00:23:28.876 --> 00:23:30.436
如果仅仅只是很酷

00:23:30.436 --> 00:23:32.396
就不值得投入大量时间

00:23:32.396 --> 00:23:34.836
谈及如何寻找优秀的合作者

00:23:34.836 --> 00:23:36.876
不仅要寻找专业能力过硬

00:23:36.876 --> 00:23:38.196
技能互补的伙伴

00:23:38.196 --> 00:23:40.896
也要选择相处起来足够愉快的人

00:23:40.896 --> 00:23:43.836
创业路上要共同面对大量棘手难题

00:23:43.836 --> 00:23:45.796
彼此的相处体验格外重要

00:23:45.796 --> 00:23:49.816
小团队的魅力就是每个人掌握其他人不具备的能力

00:23:49.816 --> 00:23:53.016
组合在一起可以完成单人无法实现的成果

00:23:53.016 --> 00:23:56.236
要把自己的工程或者科研生涯当成一条工具腰带

00:23:56.236 --> 00:23:57.956
持续补充新的工具

00:23:57.956 --> 00:24:01.016
你永远预料不到未来会碰到什么样的难题

00:24:01.016 --> 00:24:02.436
掌握的工具越多

00:24:02.436 --> 00:24:04.816
可以解决的问题边界就越宽广

00:24:04.816 --> 00:24:06.736
主持人抛出最后一个问题

00:24:06.736 --> 00:24:10.436
他希望新一代创作者把精力投入到哪些方向

00:24:10.436 --> 00:24:11.716
杰弗迪恩讲到

00:24:11.716 --> 00:24:13.696
值得探索的问题数不胜数

00:24:13.696 --> 00:24:16.336
他个人十分看好全新硬件路线

00:24:16.336 --> 00:24:18.936
高效推理硬件拥有巨大价值

00:24:18.936 --> 00:24:21.976
机器学习算法本身也还有巨大革新空间

00:24:21.976 --> 00:24:25.196
比如数据效率远远高于当下的系统

00:24:25.196 --> 00:24:27.836
现在大模型18岁阶段接触的数据总量

00:24:27.836 --> 00:24:30.596
比人类18岁接触的信息多出1000倍

00:24:30.596 --> 00:24:32.676
但是人类在大量任务当中

00:24:32.676 --> 00:24:34.816
依旧可以持平甚至优于大模型

00:24:34.816 --> 00:24:37.176
我们能不能打造数据效率更高

00:24:37.176 --> 00:24:40.516
可以从自身行动当中持续学习的系统

00:24:40.516 --> 00:24:43.196
持续学习本身就是极具价值的课题

00:24:43.196 --> 00:24:46.176
多agent交互同样充满想象空间

00:24:46.176 --> 00:24:47.896
把视角在向外延伸

00:24:47.896 --> 00:24:50.396
如何促成人类之间更良性的对话

00:24:50.396 --> 00:24:52.736
搭建工具帮助人们理性交流

00:24:52.736 --> 00:24:55.276
帮助志趣相投的人建立连接

00:24:55.276 --> 00:24:57.436
同样是值得深耕的方向

00:24:57.436 --> 00:24:58.536
整场对话听完

00:24:58.536 --> 00:25:01.376
不难感受到杰弗迪恩看待行业的独特视角

00:25:01.376 --> 00:25:04.016
他不会空谈AGI什么时候到来

00:25:04.016 --> 00:25:05.116
而是立足于能耗

00:25:05.116 --> 00:25:05.936
数据搬运

00:25:05.936 --> 00:25:07.796
延迟这些底层物理约束

00:25:07.796 --> 00:25:09.676
向上推导系统设计逻辑

00:25:09.676 --> 00:25:10.996
推导创业机会

00:25:10.996 --> 00:25:13.556
全行业疯狂内卷模型参数的时候

00:25:13.556 --> 00:25:17.156
他提醒大家数据搬运的成本是计算的1000倍

00:25:17.156 --> 00:25:20.636
推理硬件专用化是下一轮效率跃升的关键

00:25:20.636 --> 00:25:23.696
所有人焦虑通用模型吞噬创业机会

00:25:23.696 --> 00:25:27.676
他告诉大家去寻找成功率0%到1%的赛道

00:25:27.676 --> 00:25:28.996
挖掘私有数据

00:25:28.996 --> 00:25:30.756
垂直专用模型的机会

00:25:30.756 --> 00:25:33.116
所有人埋头打磨提示词的时候

00:25:33.116 --> 00:25:35.856
他点名未来最稀缺的资源是品位

00:25:35.856 --> 00:25:37.796
是筛选问题的判断力

00:25:37.796 --> 00:25:39.996
这些认知不是凭空想象

00:25:39.996 --> 00:25:42.096
来自几十年系统工程沉淀

00:25:42.096 --> 00:25:44.176
来自一次次参金值演算

00:25:44.176 --> 00:25:46.976
来自一次次推翻固有认知的思想实验

00:25:46.976 --> 00:25:49.376
以上就是整场访谈的核心精华

00:25:49.376 --> 00:25:52.436
如果你觉得这些来自一线工程大佬的思考

00:25:52.436 --> 00:25:53.236
对你有启发

00:25:53.236 --> 00:25:54.336
欢迎点赞

00:25:54.336 --> 00:25:57.996
也可以把这期内容分享给身边做AI开发创业的朋友

00:25:57.996 --> 00:26:00.236
一起跳出网络上的流量炒作

00:26:00.236 --> 00:26:02.636
看见行业更真实的底层逻辑

00:26:02.636 --> 00:26:03.836
我们下期再见