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

2
00:00:28,300 --> 00:00:31,420
整场交流把当下AI行业的现实瓶颈

3
00:00:31,420 --> 00:00:32,840
硬件底层逻辑

4
00:00:32,840 --> 00:00:34,280
agent发展边界

5
00:00:34,280 --> 00:00:37,020
还有普通创业者能够抓住的现实机遇

6
00:00:37,020 --> 00:00:38,840
全部完整剖析出来

7
00:00:38,840 --> 00:00:41,200
如果你正在接触AI相关项目

8
00:00:41,200 --> 00:00:43,340
或是想要看懂未来三五年

9
00:00:43,340 --> 00:00:45,020
行业真实的眼睛路线

10
00:00:45,020 --> 00:00:47,280
接下来的内容值得仔细看完

11
00:00:47,280 --> 00:00:49,180
觉得内容对你有启发

12
00:00:49,180 --> 00:00:50,320
可以点赞支持

13
00:00:50,320 --> 00:00:52,240
不错过更多硬核行业解读

14
00:00:52,240 --> 00:00:55,340
主持人开场抛出的第一个问题就相当尖锐

15
00:00:55,340 --> 00:00:58,100
直接回溯到一年之前的公开观点

16
00:00:58,100 --> 00:01:02,460
去年5月份杰弗迪恩曾经在AISNOT的活动上提出一个判断

17
00:01:02,460 --> 00:01:04,940
AI已经达到初级工程师的水准

18
00:01:04,940 --> 00:01:06,100
时隔一整年

19
00:01:06,100 --> 00:01:07,580
行业内外都在观望

20
00:01:07,580 --> 00:01:09,980
当初的这番论断到底有没有应验

21
00:01:09,980 --> 00:01:11,160
面对这个问题

22
00:01:11,160 --> 00:01:13,400
杰弗迪恩没有选择夸大成果

23
00:01:13,400 --> 00:01:15,100
也没有刻意淡化进展

24
00:01:15,100 --> 00:01:17,300
他给出了一份非常务实的复盘

25
00:01:17,300 --> 00:01:21,400
在Agent的体系配合长周期运行时的编程任务当中

26
00:01:21,400 --> 00:01:25,240
大模型能力的迭代速度远远超出他此前的预估

27
00:01:25,240 --> 00:01:27,740
放到初级工程师的评判标准之下

28
00:01:27,740 --> 00:01:30,360
当初的判断大体上已经得到验证

29
00:01:30,360 --> 00:01:31,780
但同时他也坦诚

30
00:01:31,780 --> 00:01:35,360
自己严重低估了复杂任务处理能力的上涨幅度

31
00:01:35,360 --> 00:01:38,520
实际提升速度比事前的预判要快得多

32
00:01:38,520 --> 00:01:41,580
能力的提升并不单单局限在代码编写

33
00:01:41,580 --> 00:01:44,200
这个单一赛道Agent这套运行范式

34
00:01:44,200 --> 00:01:46,980
正在其他各式各样的业务场景当中

35
00:01:46,980 --> 00:01:49,060
展现出实实在在的价值

36
00:01:49,060 --> 00:01:50,300
顺着这个话题

37
00:01:50,300 --> 00:01:51,860
主持人继续向前追问

38
00:01:51,860 --> 00:01:53,780
把目光投向2027年

39
00:01:53,780 --> 00:01:56,780
想要听听属于杰弗迪恩的新一轮大胆预判

40
00:01:56,780 --> 00:01:58,580
他思索之后给出了答案

41
00:01:58,580 --> 00:02:01,740
核心落在机器学习系统的自我自动化上面

42
00:02:01,740 --> 00:02:02,680
简单来讲

43
00:02:02,680 --> 00:02:06,120
就是让AI系统自主开展大批量的实验工作

44
00:02:06,120 --> 00:02:09,920
把复杂的大问题拆解成若干个更小的子任务

45
00:02:09,920 --> 00:02:12,140
搭建一套闭环的自动实验循环

46
00:02:12,140 --> 00:02:14,080
完成子任务的处理之后

47
00:02:14,080 --> 00:02:16,520
再把分散的结果重新整合汇总

48
00:02:16,520 --> 00:02:18,960
以此完成自身能力的迭代升级

49
00:02:18,960 --> 00:02:22,200
这套全自动问题拆解搭配自动实验的思路

50
00:02:22,200 --> 00:02:24,680
并不单单局限于机器学习本身

51
00:02:24,680 --> 00:02:27,220
只要某一个科学或者工程领域

52
00:02:27,220 --> 00:02:30,120
能够建立起一套可以量化衡量的目标

53
00:02:30,120 --> 00:02:32,040
就有机会依靠这套模式

54
00:02:32,040 --> 00:02:33,380
拿到巨大的突破

55
00:02:33,380 --> 00:02:34,280
讲到这里

56
00:02:34,280 --> 00:02:37,100
主持人抛出一个很有历史氛围感的类比

57
00:02:37,100 --> 00:02:38,640
2001年的时候

58
00:02:38,640 --> 00:02:42,040
谷歌搜索还完全依靠硬盘完成数据读取

59
00:02:42,040 --> 00:02:44,100
杰弗迪恩和长期搭档桑杰

60
00:02:44,100 --> 00:02:46,980
通过餐金值演算完成一轮成本测算

61
00:02:46,980 --> 00:02:48,080
得出一个结论

62
00:02:48,080 --> 00:02:49,800
未来某一个时间节点

63
00:02:49,800 --> 00:02:51,160
整套搜索索引

64
00:02:51,160 --> 00:02:53,780
完全可以全部放进机器的内存之中

65
00:02:53,780 --> 00:02:54,820
基于这个判断

66
00:02:54,820 --> 00:02:58,720
两个人短短几天就迭代出全新版本的谷歌搜索

67
00:02:58,720 --> 00:03:00,780
不再依赖硬盘读取数据

68
00:03:00,780 --> 00:03:02,560
全部运行在内存当中

69
00:03:02,560 --> 00:03:06,780
这也成为谷歌搜索体验实现跨越时提升的关键转折点

70
00:03:06,780 --> 00:03:09,060
历史总是会出现相似的韵律

71
00:03:09,060 --> 00:03:10,760
那么放到2026年

72
00:03:10,760 --> 00:03:12,260
属于当下这个时代

73
00:03:12,260 --> 00:03:15,500
整套系统全部搬进内存的标志性时刻又会是什么

74
00:03:15,500 --> 00:03:17,340
现场6000名创业者

75
00:03:17,340 --> 00:03:20,380
又应当盯住哪些信号去设计自己的产品

76
00:03:20,380 --> 00:03:23,460
杰弗迪恩的回答把落脚点放在硬件层面

77
00:03:23,460 --> 00:03:26,980
它坦言当下的情况和当年谷歌搜索的故事

78
00:03:26,980 --> 00:03:28,320
并不能完全等同

79
00:03:28,320 --> 00:03:30,240
但有一个趋势是确定的

80
00:03:30,240 --> 00:03:33,220
高性能同时兼顾低能耗的推理硬件系统

81
00:03:33,220 --> 00:03:34,860
会迎来大规模普及

82
00:03:34,860 --> 00:03:36,820
整个行业已经形成共识

83
00:03:36,820 --> 00:03:39,340
推理环节才是让agent大规模面

84
00:03:39,340 --> 00:03:41,720
向普通用户落地的核心基石

85
00:03:41,720 --> 00:03:45,100
而延迟又是决定用户体验好坏的关键指标

86
00:03:45,100 --> 00:03:46,700
硬件走向专业化

87
00:03:46,700 --> 00:03:49,340
是整套系统相比通用GPU TPU设备

88
00:03:49,340 --> 00:03:51,240
实现更低功耗

89
00:03:51,240 --> 00:03:53,460
更低延迟最重要的实现路径

90
00:03:53,460 --> 00:03:57,000
我们所有人都已经习惯等待模型返回输出结果

91
00:03:57,000 --> 00:03:59,800
但等待本身并不是良好的用户体验

92
00:03:59,800 --> 00:04:01,360
速度才是一切的王道

93
00:04:01,360 --> 00:04:03,700
主持人继续顺着这个方向推进

94
00:04:03,700 --> 00:04:06,120
如果延迟可以直接降低50倍

95
00:04:06,120 --> 00:04:08,700
整个行业会发生什么样的变化

96
00:04:08,700 --> 00:04:11,240
紧接着又抛出另外一个值得深思的问题

97
00:04:11,240 --> 00:04:12,220
时至今日

98
00:04:12,220 --> 00:04:15,100
行业当中还有哪些被大家全盘接受

99
00:04:15,100 --> 00:04:18,320
但实际上已经不再成立的固有AI假设

100
00:04:18,320 --> 00:04:19,920
杰弗迪恩给出的回答

101
00:04:19,920 --> 00:04:21,660
会刷新不少人的固有认知

102
00:04:21,660 --> 00:04:23,200
绝大多数从业者

103
00:04:23,200 --> 00:04:24,800
还没有真正接纳一件事

104
00:04:24,800 --> 00:04:27,460
依托能力足够强的底层基座模型

105
00:04:27,460 --> 00:04:30,340
Agent并不只能运行短短一两个小时

106
00:04:30,340 --> 00:04:32,500
连续运转几天甚至几周

107
00:04:32,500 --> 00:04:34,760
去完成复杂度极高的任务

108
00:04:34,760 --> 00:04:37,160
这件事已经具备现实可行性

109
00:04:37,160 --> 00:04:38,800
现在小部分从业者

110
00:04:38,800 --> 00:04:40,040
已经看到苗头

111
00:04:40,040 --> 00:04:41,300
可绝大多数人

112
00:04:41,300 --> 00:04:43,180
并没有真正把这个可能性

113
00:04:43,180 --> 00:04:45,980
内化到自己的产品设计逻辑当中

114
00:04:45,980 --> 00:04:48,720
而这件事未来会释放出巨大的影响力

115
00:04:48,720 --> 00:04:51,560
很多人会好奇到底什么样的业务场景

116
00:04:51,560 --> 00:04:54,180
需要Agent连续运航数周的时间

117
00:04:54,180 --> 00:04:56,540
杰弗迪恩举了一个很具象的案例

118
00:04:56,540 --> 00:05:00,680
我们可以交给Agent一项完整的软件版本重构工作

119
00:05:00,680 --> 00:05:04,680
把一整套软件完整迁移到另外一门编程语言

120
00:05:04,680 --> 00:05:07,680
重构之后的版本可以实现安全性的提升

121
00:05:07,680 --> 00:05:09,400
或是运行性能的优化

122
00:05:09,400 --> 00:05:12,560
AI完全可以持续推进整套复杂工程

123
00:05:12,560 --> 00:05:14,400
把这项工作落地完成

124
00:05:14,400 --> 00:05:17,360
话题就此切换到TPU诞生的过往

125
00:05:17,360 --> 00:05:20,220
杰弗迪恩在行业里面广为流传的习惯

126
00:05:20,220 --> 00:05:21,840
就是餐巾纸数学

127
00:05:21,840 --> 00:05:25,780
也就是在餐巾纸上快速完成数量级层面的粗略估算

128
00:05:25,780 --> 00:05:27,920
时间回到2013年前后

129
00:05:27,920 --> 00:05:30,540
谷歌语音识别的效果迎来实质性的飞跃

130
00:05:30,540 --> 00:05:31,940
他做过一笔测算

131
00:05:31,940 --> 00:05:34,000
如果每一位谷歌手机用户

132
00:05:34,000 --> 00:05:36,900
每天仅仅使用三分钟的语音识别功能

133
00:05:36,900 --> 00:05:40,160
谷歌整体的服务器集群规模就需要直接翻倍

134
00:05:40,160 --> 00:05:43,360
对应的成本会膨胀到完全无法接受的地步

135
00:05:43,360 --> 00:05:45,180
为了解决这个现实难题

136
00:05:45,180 --> 00:05:47,180
团队决定自研专属芯片

137
00:05:47,180 --> 00:05:49,020
这也就是TPU的起源

138
00:05:49,020 --> 00:05:49,880
他回忆

139
00:05:49,880 --> 00:05:52,440
那时候深度学习驱动的语音系统

140
00:05:52,440 --> 00:05:53,800
对比旧有方案

141
00:05:53,800 --> 00:05:55,840
算力开销高出一大截

142
00:05:55,840 --> 00:05:57,960
但是错误率直接减半

143
00:05:57,960 --> 00:06:00,120
短短几个月时间就拿到过去

144
00:06:00,120 --> 00:06:02,960
20年语音识别领域积累下来的全部进步

145
00:06:02,960 --> 00:06:05,780
初代TPU没有办法运行Chrome浏览器

146
00:06:05,780 --> 00:06:07,840
也跑不了Word这类通用软件

147
00:06:07,840 --> 00:06:10,020
但是在机器学习推理场景当中

148
00:06:10,020 --> 00:06:11,300
拥有极强的针对性

149
00:06:11,300 --> 00:06:13,260
最终落地的初代芯片

150
00:06:13,260 --> 00:06:15,080
对比CPU和GPU

151
00:06:15,080 --> 00:06:17,520
能效可以提升30到80倍

152
00:06:17,520 --> 00:06:19,600
延迟下降20到30倍

153
00:06:19,600 --> 00:06:21,880
打下了非常扎实的技术底子

154
00:06:21,880 --> 00:06:24,820
后续TPU才一步步迭代成如今的模样

155
00:06:24,820 --> 00:06:28,200
有意思的地方在于团队研发TPU的那个阶段

156
00:06:28,200 --> 00:06:30,160
Transformer架构还没有问世

157
00:06:30,160 --> 00:06:34,720
没有人能够预料到后续TPU会成为整个AI产业的基石硬件

158
00:06:34,720 --> 00:06:36,040
也正是因为这样

159
00:06:36,040 --> 00:06:40,560
当时团队的设计思路是打造一套通用线性怠数运算系统

160
00:06:40,560 --> 00:06:44,320
而不是死死绑定某一套特定算法做极致专用化

161
00:06:44,320 --> 00:06:47,620
机器学习算法永远处在持续演化的进程当中

162
00:06:47,620 --> 00:06:49,220
硬件不能过度定制

163
00:06:49,220 --> 00:06:51,480
但是又要保留足够的专用属性

164
00:06:51,480 --> 00:06:53,300
以此拿到巨大的性能收益

165
00:06:53,300 --> 00:06:55,400
比如做大规格乘法运算单元

166
00:06:55,400 --> 00:06:56,700
配置高速内存

167
00:06:56,700 --> 00:06:58,180
搭建高速互联通路

168
00:06:58,180 --> 00:07:01,980
后续几代TPU更是优化多芯片协同工作的能力

169
00:07:01,980 --> 00:07:05,380
让大量芯片可以联合处理同一个复杂任务

170
00:07:05,380 --> 00:07:06,480
主持人接着提问

171
00:07:06,480 --> 00:07:07,480
放到今天

172
00:07:07,480 --> 00:07:10,160
创业者又该做怎样的餐巾纸数学

173
00:07:10,160 --> 00:07:12,720
能不能依靠简单的数量级估算

174
00:07:12,720 --> 00:07:16,240
挖掘出下一代如同TPO一般重量级的创新

175
00:07:16,240 --> 00:07:17,420
杰弗蒂恩表示

176
00:07:17,420 --> 00:07:19,480
这件事没有统一标准答案

177
00:07:19,480 --> 00:07:21,880
但是底层思考逻辑是相通的

178
00:07:21,880 --> 00:07:24,800
首先找准自己所在赛道真正的瓶颈

179
00:07:24,800 --> 00:07:26,120
再去反问自己

180
00:07:26,120 --> 00:07:29,920
是否存在一套和当下主流方案完全不一样的解法

181
00:07:29,920 --> 00:07:33,440
能不能把核心指标抬升一个甚至两个数量级

182
00:07:33,440 --> 00:07:36,980
不要被市面上已经成熟的实现方案束缚住思路

183
00:07:36,980 --> 00:07:38,940
回归第一性原理去思考

184
00:07:38,940 --> 00:07:41,040
如果从零开始解决这个问题

185
00:07:41,040 --> 00:07:42,860
自己会选择什么样的路径

186
00:07:42,860 --> 00:07:45,460
往往就能够挖掘出别人看不见的机会

187
00:07:45,460 --> 00:07:47,060
随后主持人问到一个

188
00:07:47,060 --> 00:07:49,140
只有内行才会深究的话题

189
00:07:49,140 --> 00:07:52,600
多年以前杰弗迪恩写过一份流传极广的清单

190
00:07:52,600 --> 00:07:56,160
名字叫做每个工程师都应该知道的延迟数字

191
00:07:56,160 --> 00:07:58,560
里面记录缓存未命中的耗石

192
00:07:58,560 --> 00:08:00,000
磁盘寻道耗石

193
00:08:14,280 --> 00:08:17,660
杰弗迪恩列举出一系列至关重要的硬件数字

194
00:08:17,660 --> 00:08:20,600
储存到加速器片上内存之间的带宽

195
00:08:20,600 --> 00:08:22,880
通往乘法运算单元的带宽

196
00:08:22,880 --> 00:08:25,700
完成一次乘法运算需要消耗的能量

197
00:08:25,700 --> 00:08:27,980
芯片与芯片之间的互联带宽

198
00:08:27,980 --> 00:08:31,220
在该带宽条件之下可以联动多少颗芯片

199
00:08:31,220 --> 00:08:35,240
还有从500颗芯片扩展到1万颗芯片的规模过程当中

200
00:08:35,240 --> 00:08:37,980
网络带宽会出现多大程度的衰减

201
00:08:37,980 --> 00:08:42,360
这些底层数字会实实在在约束上层业务问题的解法

202
00:08:42,360 --> 00:08:46,440
紧接着他抛出一个足以改变很多人AI系统设计思路的数据

203
00:08:46,440 --> 00:08:49,940
完成一次计算消耗的能量大概在EP焦2级别

204
00:08:49,940 --> 00:08:51,800
但是完成一次数据搬运

205
00:08:51,800 --> 00:08:52,980
一次IO操作

206
00:08:52,980 --> 00:08:55,300
消耗的能量是前者的1000倍

207
00:08:55,300 --> 00:08:59,780
就算只是把数据从加速器的高带宽内存搬运到处理器内部

208
00:08:59,780 --> 00:09:00,860
参与运算

209
00:09:00,860 --> 00:09:03,160
能量开销同样会急剧拉高

210
00:09:03,160 --> 00:09:07,600
搬数据的代价远远高于做计算这条物理层面的硬约数

211
00:09:07,600 --> 00:09:10,540
塑造了机器学习领域大量的工程选择

212
00:09:10,540 --> 00:09:13,160
如果不存在如此悬殊的能耗差距

213
00:09:13,160 --> 00:09:15,600
我们就不需要对数据做批量处理

214
00:09:15,600 --> 00:09:17,480
可现实条件摆在眼前

215
00:09:17,480 --> 00:09:21,620
工程师只能把大量样本或者token攒成批次统一处理

216
00:09:21,620 --> 00:09:24,680
以此贪薄数据搬运带来的巨大能耗惩罚

217
00:09:24,680 --> 00:09:26,160
把1000倍的开销

218
00:09:26,160 --> 00:09:28,380
稀释为1000除以批次规模

219
00:09:28,380 --> 00:09:31,380
但如果我们追求极低延迟的推理表现

220
00:09:31,380 --> 00:09:34,100
批量处理这套逻辑就会变成阻碍

221
00:09:34,100 --> 00:09:35,880
底层硬件的能量约束

222
00:09:35,880 --> 00:09:39,180
会自上而下影响整套AI系统的每一层设计

223
00:09:39,180 --> 00:09:40,460
主持人继续追问

224
00:09:40,460 --> 00:09:43,960
那我们有没有机会实现单条数据的处理模式

225
00:09:43,960 --> 00:09:47,540
杰弗迪恩表示自己现阶段思考更多的是推理测的问题

226
00:09:47,540 --> 00:09:50,760
推理业务天然对低延迟有着强烈诉求

227
00:09:50,760 --> 00:09:53,700
训练环节对此的要求反而没有那么严苛

228
00:09:53,700 --> 00:09:54,800
在他看来

229
00:09:54,800 --> 00:09:56,600
推理硬件的专用化程度

230
00:09:56,600 --> 00:09:58,580
如今远远还没有抵达上线

231
00:09:58,580 --> 00:09:59,920
核心优化方向

232
00:09:59,920 --> 00:10:02,760
一方面是尽可能压缩数据搬运的频次

233
00:10:02,760 --> 00:10:05,220
另一方面去探索极低精度运算

234
00:10:05,220 --> 00:10:08,400
不需要硬件去兼容五花八门的精度规格

235
00:10:08,400 --> 00:10:10,360
把业务真正需要的精度

236
00:10:10,360 --> 00:10:12,440
直接固化到硬件设计当中

237
00:10:12,440 --> 00:10:14,520
聊完硬件层面的种种约束

238
00:10:14,520 --> 00:10:16,420
对话把视角向上拉高

239
00:10:16,420 --> 00:10:18,460
过去大家谈及AI进步

240
00:10:18,460 --> 00:10:20,760
惯性思维就是模型规模更大

241
00:10:20,760 --> 00:10:22,240
训练数据更多

242
00:10:22,240 --> 00:10:23,520
参数体量上涨

243
00:10:23,520 --> 00:10:24,800
训练时间拉长

244
00:10:24,800 --> 00:10:25,960
但是最近几年

245
00:10:25,960 --> 00:10:27,400
真正拉开差距的

246
00:10:27,400 --> 00:10:28,820
不再只有模型本体

247
00:10:28,820 --> 00:10:31,100
模型外围的整套配套体系

248
00:10:31,100 --> 00:10:32,800
价值正在持续走高

249
00:10:32,800 --> 00:10:35,560
不单单要看参数规模和训练数据集

250
00:10:35,560 --> 00:10:36,480
检索工具

251
00:10:36,480 --> 00:10:37,400
记忆模块

252
00:10:37,400 --> 00:10:38,040
Agent

253
00:10:38,040 --> 00:10:38,760
工具链

254
00:10:38,760 --> 00:10:41,040
全部都是不可或缺的组成部分

255
00:10:41,040 --> 00:10:42,880
杰弗迪恩认同这样的看法

256
00:10:42,880 --> 00:10:45,320
模型只是整套解决方案当中的

257
00:10:45,320 --> 00:10:46,320
其中一块拼图

258
00:10:46,320 --> 00:10:47,540
我们真正的目标

259
00:10:47,540 --> 00:10:49,140
是搭建一整套

260
00:10:49,140 --> 00:10:52,020
可以解决复杂现实问题的完整系统

261
00:10:52,020 --> 00:10:53,900
这就意味着模型要学会

262
00:10:53,900 --> 00:10:55,560
调用各式各样的外部工具

263
00:10:55,560 --> 00:10:57,540
检索外部相关信息

264
00:10:57,540 --> 00:10:59,100
留存过往处理其他任务

265
00:10:59,100 --> 00:11:00,480
沉淀下来的历史信息

266
00:11:00,480 --> 00:11:01,900
并且把这些信息

267
00:11:01,900 --> 00:11:03,780
带入当下的上下文当中

268
00:11:03,780 --> 00:11:05,660
这里有一个很关键的区别

269
00:11:05,660 --> 00:11:08,080
训练数据就像是一锅大杂烩

270
00:11:08,080 --> 00:11:10,360
数万亿token混杂在一起

271
00:11:10,360 --> 00:11:13,280
压缩近几千亿的模型参数内部

272
00:11:13,280 --> 00:11:13,920
与之对比

273
00:11:13,920 --> 00:11:17,060
模型在处理具体任务时拿到的上下文信息

274
00:11:17,060 --> 00:11:18,440
逻辑会清晰很多

275
00:11:18,440 --> 00:11:20,900
同时模型还要识别可用的工具

276
00:11:20,900 --> 00:11:23,320
判断哪些工具适配当前步骤

277
00:11:23,320 --> 00:11:26,280
如何把大任务拆解成一连串工具调用

278
00:11:26,280 --> 00:11:28,920
甚至尝试多条不同的解题路径

279
00:11:28,920 --> 00:11:30,980
再评估各个方案的实际效果

280
00:11:30,980 --> 00:11:34,920
这就是复杂agent以及dooragent编排的核心能力

281
00:11:34,920 --> 00:11:37,440
上下文工程这个方向很有意思的一点

282
00:11:37,440 --> 00:11:39,720
使它的准入门槛相对更低

283
00:11:39,720 --> 00:11:41,840
训练大模型需要海量算力

284
00:11:41,840 --> 00:11:43,340
海量数据资源

285
00:11:43,340 --> 00:11:44,900
普通团队很难触碰

286
00:11:44,900 --> 00:11:46,460
但是做上下文工程

287
00:11:46,460 --> 00:11:49,340
只需要调用Gemini这类模型的API接口

288
00:11:49,340 --> 00:11:51,680
再搭配自己搭建的检索逻辑

289
00:11:51,680 --> 00:11:53,040
工具调用流程

290
00:11:53,040 --> 00:11:54,160
工作流编排

291
00:11:54,160 --> 00:11:55,540
就可以动手实践

292
00:11:55,540 --> 00:11:57,960
想要把上下文工程做到足够强

293
00:11:57,960 --> 00:12:01,060
杰弗迪恩给出一套非常务实的实操思路

294
00:12:01,060 --> 00:12:03,360
就是实实在在拿模型和工具链

295
00:12:03,360 --> 00:12:04,580
去处理真实业务

296
00:12:04,580 --> 00:12:07,320
在实操当中观察模型的出错点位

297
00:12:07,320 --> 00:12:09,660
很多时候想要提升模型表现

298
00:12:09,660 --> 00:12:12,180
并不需要去改动底层模型权重

299
00:12:12,180 --> 00:12:14,360
而是提供质量更高的指引

300
00:12:14,360 --> 00:12:16,400
编写更完善的技能描述

301
00:12:16,400 --> 00:12:18,440
告诉模型面对某一类问题

302
00:12:18,440 --> 00:12:19,940
应当如何调用工具

303
00:12:19,940 --> 00:12:21,280
反复迭代之后

304
00:12:21,280 --> 00:12:22,780
你就会慢慢摸清楚

305
00:12:22,780 --> 00:12:24,480
模型还缺少哪些信息

306
00:12:24,480 --> 00:12:27,400
由此进入自我迭代优化的正向循环

307
00:12:27,400 --> 00:12:29,400
他分享了一段亲身经历

308
00:12:29,400 --> 00:12:30,300
几周之前

309
00:12:30,300 --> 00:12:33,240
他和桑杰一起做底层代码库的性能调优

310
00:12:33,240 --> 00:12:36,560
团队内部有自研的微型基准测试库

311
00:12:36,560 --> 00:12:38,640
可以统计各类操作的耗时

312
00:12:38,640 --> 00:12:42,280
这套数据结构被谷歌内部几百万个进程调用

313
00:12:42,280 --> 00:12:44,380
性能表现必须得到保障

314
00:12:44,380 --> 00:12:46,020
在没有Agent的时代

315
00:12:46,020 --> 00:12:48,500
完整流程是先测试现有性能

316
00:12:48,500 --> 00:12:49,480
修改代码

317
00:12:49,480 --> 00:12:51,120
重新跑基准测试

318
00:12:51,120 --> 00:12:52,600
观察性能变化

319
00:12:52,600 --> 00:12:54,560
还要执行更大范围的测试

320
00:12:54,560 --> 00:12:56,800
检查缓存占用等一系列指标

321
00:12:56,800 --> 00:12:59,060
后来他们专门编写对应的技能

322
00:12:59,060 --> 00:13:01,860
教会Agent完整复刻整套工作流

323
00:13:01,860 --> 00:13:03,260
执行基准测试

324
00:13:03,260 --> 00:13:04,460
修改代码

325
00:13:04,460 --> 00:13:05,900
重新叫验性能指标

326
00:13:05,900 --> 00:13:07,480
《循环迭代优化》

327
00:13:07,480 --> 00:13:10,500
这套方案在部分问题上拿到相当不错的效果

328
00:13:10,500 --> 00:13:13,320
本质上就是把人类工程师的工作流程

329
00:13:13,320 --> 00:13:16,080
转化成模型能够读懂执行的指令

330
00:13:16,080 --> 00:13:17,100
几个月之前

331
00:13:17,100 --> 00:13:20,440
他和桑杰共同发布过一份30页左右的公开文档

332
00:13:20,440 --> 00:13:22,980
名字叫做Performance Heightened TS

333
00:13:22,980 --> 00:13:25,480
记录大量性能优化的实操技巧

334
00:13:25,480 --> 00:13:29,060
已经有不少开发者把这份文档做总结提炼之后

335
00:13:29,060 --> 00:13:30,520
投入给不同的大模型

336
00:13:30,520 --> 00:13:32,480
最终测试结果显示

337
00:13:32,480 --> 00:13:35,760
模型分析代码性能问题的能力得到明显提升

338
00:13:35,760 --> 00:13:38,640
而且这份资料对所有人完全公开

339
00:13:38,640 --> 00:13:39,780
谈及agent

340
00:13:39,780 --> 00:13:42,240
有一个所有人都会碰到的现实痛点

341
00:13:42,240 --> 00:13:45,940
不少agent在前十几步执行都十分顺畅

342
00:13:45,940 --> 00:13:47,400
等到推进到第三十步

343
00:13:47,400 --> 00:13:48,120
四十步

344
00:13:48,120 --> 00:13:49,360
甚至五十步之后

345
00:13:49,360 --> 00:13:51,040
就会开始逻辑跑偏

346
00:13:51,040 --> 00:13:52,420
杰弗迪恩坦言

347
00:13:52,420 --> 00:13:54,980
这就是当下技术最大的约束条件

348
00:13:54,980 --> 00:13:58,360
一部分原因是模型处理训练机之外的任务

349
00:13:58,360 --> 00:14:00,120
一旦脱离熟悉的任务分布

350
00:14:00,120 --> 00:14:01,420
效果就会下滑

351
00:14:01,420 --> 00:14:03,620
偏离熟悉的边界越远

352
00:14:03,620 --> 00:14:04,760
失效概率就越高

353
00:14:04,760 --> 00:14:05,780
针对该问题

354
00:14:05,780 --> 00:14:07,880
有两条可行的解决路径

355
00:14:07,880 --> 00:14:08,560
第一种

356
00:14:08,560 --> 00:14:10,920
编写对应的技能和提示之意

357
00:14:10,920 --> 00:14:13,240
尽量让模型维持在自己熟悉

358
00:14:13,240 --> 00:14:15,060
成功率更高的执行路径

359
00:14:15,060 --> 00:14:15,840
第二种

360
00:14:15,840 --> 00:14:17,400
采用多agent的架构

361
00:14:17,400 --> 00:14:18,880
让多个独立agent

362
00:14:18,880 --> 00:14:20,780
并行尝试不同解题思路

363
00:14:20,780 --> 00:14:23,100
再交由另外一个模型或者agent

364
00:14:23,100 --> 00:14:24,920
去评判各个路径的可行性

365
00:14:24,920 --> 00:14:27,120
本质就是对全部可行解法

366
00:14:27,120 --> 00:14:28,080
做搜索筛选

367
00:14:28,080 --> 00:14:29,640
保留有希望的分支

368
00:14:29,640 --> 00:14:31,540
丢弃无效跑偏的分支

369
00:14:31,540 --> 00:14:32,780
依靠推理计算

370
00:14:32,780 --> 00:14:34,460
去便利解决方案空间

371
00:14:34,460 --> 00:14:36,880
以此提升常链路Agent的定性

372
00:14:36,880 --> 00:14:40,000
在谷歌内部就搭建了一整套调度框架

373
00:14:40,000 --> 00:14:41,220
以及海量技能库

374
00:14:41,220 --> 00:14:43,340
Agent可以调用内部编码工具

375
00:14:43,340 --> 00:14:44,660
执行代码审查

376
00:14:44,660 --> 00:14:45,980
完成性能测试

377
00:14:45,980 --> 00:14:47,300
读取日志文件

378
00:14:47,300 --> 00:14:49,040
只要技能定义足够合理

379
00:14:49,040 --> 00:14:51,680
Agent的实用价值就会被大幅释放

380
00:14:51,680 --> 00:14:52,480
紧接着

381
00:14:52,480 --> 00:14:55,900
对话落到在场每一位创业者都无比关心的命题

382
00:14:55,900 --> 00:14:58,960
谷歌能够做到从处理器到上层产品

383
00:14:58,960 --> 00:15:00,480
全链路协同设计

384
00:15:00,480 --> 00:15:03,340
那对于两三个人组成的小型创业团队

385
00:15:03,340 --> 00:15:05,600
还剩下哪些可以抓住的机会

386
00:15:05,600 --> 00:15:06,980
杰弗迪恩讲到

387
00:15:06,980 --> 00:15:09,320
谷歌以及通用大模型团队

388
00:15:09,320 --> 00:15:11,880
都在竭尽全力打造通用性极强

389
00:15:11,880 --> 00:15:14,480
几乎可以处理各类任务的基座模型

390
00:15:14,480 --> 00:15:17,020
但恰恰是追求通用这个前提

391
00:15:17,020 --> 00:15:19,980
导致它很难针对某一个垂直细分领域

392
00:15:19,980 --> 00:15:21,060
做深度打磨

393
00:15:21,060 --> 00:15:22,280
如果创业团队

394
00:15:22,280 --> 00:15:25,640
可以针对特定行业打磨优质的产品交互界面

395
00:15:25,640 --> 00:15:27,460
配套专属的技能体系

396
00:15:27,460 --> 00:15:29,820
甚至是垂直微调的专用模型

397
00:15:29,820 --> 00:15:32,600
完全有机会建立起明显的竞争优势

398
00:15:32,600 --> 00:15:34,120
打造出体验流畅

399
00:15:34,120 --> 00:15:36,060
准确率出色的垂直产品

400
00:15:36,060 --> 00:15:37,800
不过他也做出提醒

401
00:15:37,800 --> 00:15:40,400
通用模型的能力还在持续变强

402
00:15:40,400 --> 00:15:42,340
覆盖的场景不断扩张

403
00:15:42,340 --> 00:15:44,200
创业者必须做好判断

404
00:15:44,200 --> 00:15:45,520
自己选择的赛道

405
00:15:45,520 --> 00:15:47,360
是未来半年到12个月

406
00:15:47,360 --> 00:15:48,880
就会被通用模型覆盖

407
00:15:48,880 --> 00:15:50,220
还是两三年之内

408
00:15:50,220 --> 00:15:51,820
通用模型都难以企及

409
00:15:51,820 --> 00:15:54,220
以此判断赛道的抗风险能力

410
00:15:54,220 --> 00:15:56,240
那创业者应当如何筛选

411
00:15:56,240 --> 00:15:57,620
值得投入的方向

412
00:15:57,620 --> 00:15:59,400
他给出的第一条建议朴素

413
00:15:59,400 --> 00:16:00,000
但是分类

414
00:16:15,000 --> 00:16:16,640
往往代表存在机会

415
00:16:16,640 --> 00:16:18,460
如果已经可以完成一部分

416
00:16:18,460 --> 00:16:20,040
只是效果不够完美

417
00:16:20,040 --> 00:16:21,380
反而要提高警惕

418
00:16:21,380 --> 00:16:23,760
这代表能力的种子已经存在

419
00:16:23,760 --> 00:16:25,560
只需要补充训练数据

420
00:16:25,560 --> 00:16:26,980
扩大模型规模

421
00:16:26,980 --> 00:16:28,640
能力就会快速迭代

422
00:16:28,640 --> 00:16:31,160
所以要优先寻找当下通用模型

423
00:16:31,160 --> 00:16:33,980
成功率只有0%或者1%的问题

424
00:16:33,980 --> 00:16:36,220
而不是20%左右的赛道

425
00:16:36,220 --> 00:16:37,280
这类机会

426
00:16:37,280 --> 00:16:40,300
一部分属于训练分布之外的全新任务

427
00:16:40,300 --> 00:16:41,300
另一类场景

428
00:16:41,300 --> 00:16:43,300
是产品可以拿到通用模型

429
00:16:43,300 --> 00:16:44,900
接触不到的私有数据

430
00:16:45,000 --> 00:16:47,100
比如处理用户个人信息的产品

431
00:16:47,100 --> 00:16:50,160
通用模型本身无法获取用户私人资料

432
00:16:50,160 --> 00:16:51,720
这就创造天然壁垒

433
00:16:51,720 --> 00:16:52,960
还有一类机会

434
00:16:52,960 --> 00:16:54,320
针对高难度问题

435
00:16:54,320 --> 00:16:57,020
以可控成本训练垂直专用模型

436
00:16:57,020 --> 00:16:58,520
换取极高精度

437
00:16:58,520 --> 00:17:00,680
AlphaFold就是典型案例

438
00:17:00,680 --> 00:17:03,860
面向蛋白质折叠的专用模型取得巨大成功

439
00:17:03,860 --> 00:17:05,480
却并非通用大模型

440
00:17:05,480 --> 00:17:06,440
材料科学

441
00:17:06,440 --> 00:17:09,920
芯片设计领域也存在同类的落地可能性

442
00:17:09,920 --> 00:17:12,340
怎样成长为AI原生的创始人

443
00:17:12,340 --> 00:17:13,140
他提到

444
00:17:13,140 --> 00:17:14,920
和虚拟agent的协作的时候

445
00:17:14,920 --> 00:17:16,840
把需求描述的越清晰

446
00:17:16,840 --> 00:17:18,720
最终产出效果就越好

447
00:17:18,720 --> 00:17:20,460
需求定义足够明确

448
00:17:20,460 --> 00:17:22,540
Agent就拥有清晰的边界

449
00:17:22,540 --> 00:17:23,880
明白自身的目标

450
00:17:23,880 --> 00:17:25,980
从很早的计算机发展阶段

451
00:17:25,980 --> 00:17:28,420
工程师就被要求开发软件之前

452
00:17:28,420 --> 00:17:29,880
梳理清楚产品规格

453
00:17:29,880 --> 00:17:32,540
如今只是把执行工作交给Agent

454
00:17:32,540 --> 00:17:35,140
明确规格这件事反而变得更加关键

455
00:17:35,140 --> 00:17:37,160
人类工程师可以读懂语境

456
00:17:37,160 --> 00:17:38,780
主动反问确认细节

457
00:17:38,780 --> 00:17:41,080
Agent虽然部分场景可以追问

458
00:17:41,080 --> 00:17:44,300
但整体还是高度依赖清晰完备的需求描述

459
00:17:44,300 --> 00:17:46,680
现在代码迁移类的Coding Agent

460
00:17:46,680 --> 00:17:47,700
效果出众

461
00:17:47,700 --> 00:17:49,740
背后的原因也正在于此

462
00:17:49,740 --> 00:17:53,020
把一套软件从一门语言迁移到另一门语言

463
00:17:53,020 --> 00:17:55,420
原始代码本身就是完整的规格

464
00:17:55,420 --> 00:17:57,640
原有测试用力可以直接复用

465
00:17:57,640 --> 00:17:59,000
同时完成迁移

466
00:17:59,000 --> 00:18:01,380
持续比对新旧版本行为差异

467
00:18:01,380 --> 00:18:03,100
直到二者表现对齐

468
00:18:03,100 --> 00:18:04,880
正是规格足够明确

469
00:18:04,880 --> 00:18:07,100
才造就这类任务亮眼的表现

470
00:18:07,100 --> 00:18:09,220
未来大规模调度数百个Agent

471
00:18:09,220 --> 00:18:10,080
成为常态

472
00:18:10,080 --> 00:18:11,880
大量代码由Agent生成

473
00:18:11,880 --> 00:18:13,740
什么能力会变得最为稀缺

474
00:18:13,740 --> 00:18:15,800
杰弗·迪恩给出的答案是品位

475
00:18:15,800 --> 00:18:19,440
也就是判断哪些问题值得交给agent去解决

476
00:18:19,440 --> 00:18:21,900
放到研究领域大部分的成败

477
00:18:21,900 --> 00:18:24,760
从选择研究课题的那一刻就已经注定

478
00:18:24,760 --> 00:18:26,100
手握全套工具

479
00:18:26,100 --> 00:18:28,120
不如选对值得投入的问题

480
00:18:28,120 --> 00:18:30,180
把普通问题打磨得再精致

481
00:18:30,180 --> 00:18:32,720
也比不上攻克一个高价值的难题

482
00:18:32,720 --> 00:18:35,540
但是品位本身没有标准化的考核指标

483
00:18:35,540 --> 00:18:36,880
应当如何训练

484
00:18:36,880 --> 00:18:39,120
一部分来源于大量项目经验

485
00:18:39,120 --> 00:18:41,480
经手足够多不同类型的问题

486
00:18:41,480 --> 00:18:43,620
慢慢积累对机会的判断力

487
00:18:43,620 --> 00:18:45,060
还有一个实操办法

488
00:18:45,060 --> 00:18:46,880
写下未来12个月之内

489
00:18:46,880 --> 00:18:49,260
自己预判会迎来爆发的方向

490
00:18:49,260 --> 00:18:52,000
后续只挑选其中一部分落地

491
00:18:52,000 --> 00:18:53,820
12个月之后回头复盘

492
00:18:53,820 --> 00:18:55,460
看看哪些预判成真

493
00:18:55,460 --> 00:18:57,140
哪些被其他人实现

494
00:18:57,140 --> 00:18:58,640
哪些完全没有发生

495
00:18:58,640 --> 00:19:00,960
相当于给自己制造大量样本

496
00:19:00,960 --> 00:19:02,660
反向训练自己的判断力

497
00:19:02,660 --> 00:19:05,720
第三种方式就是做疯狂的思想实验

498
00:19:05,720 --> 00:19:08,780
不要把行业默认的前提全部当成真理

499
00:19:08,780 --> 00:19:11,540
他分享了一段和同事开展的思想实验

500
00:19:11,540 --> 00:19:12,660
过去60年

501
00:19:12,660 --> 00:19:14,220
芯片设计制造行业

502
00:19:14,220 --> 00:19:16,420
都在拼命缩小晶体管尺寸

503
00:19:16,420 --> 00:19:17,880
压低出错概率

504
00:19:17,880 --> 00:19:19,900
默认目标就是同一款芯片

505
00:19:19,900 --> 00:19:22,040
每一颗成品都应当完全一致

506
00:19:22,040 --> 00:19:23,600
不能出现比特翻转

507
00:19:23,600 --> 00:19:24,940
但是宏观层面

508
00:19:24,940 --> 00:19:27,520
大规模分布式系统的逻辑恰恰相反

509
00:19:27,520 --> 00:19:29,440
依靠不可靠的硬件组件

510
00:19:29,440 --> 00:19:31,040
搭建高可靠系统

511
00:19:31,040 --> 00:19:32,180
磁盘会损坏

512
00:19:32,180 --> 00:19:33,880
但是数据不能丢失

513
00:19:33,880 --> 00:19:35,420
于是做多副本

514
00:19:35,420 --> 00:19:36,680
使用纠缠码

515
00:19:36,680 --> 00:19:38,240
可是这套容错思路

516
00:19:38,240 --> 00:19:40,340
并没有下放到晶体管这一层

517
00:19:40,340 --> 00:19:41,900
如果设计一套芯片

518
00:19:41,900 --> 00:19:44,580
晶体管每天会出现20次错误

519
00:19:44,580 --> 00:19:46,920
而不是几百万年才出现一次故障

520
00:19:46,920 --> 00:19:48,940
整套系统会走向何方

521
00:19:48,940 --> 00:19:51,680
制造工艺或许会迎来全新可能性

522
00:19:51,680 --> 00:19:53,980
信号传输采用多条冗余通路

523
00:19:53,980 --> 00:19:56,280
保障至少一路信号可以送达

524
00:19:56,280 --> 00:19:59,500
这套逻辑和人脑神经信号传递十分相似

525
00:19:59,500 --> 00:20:02,220
大脑信号传输本身就不是绝对可靠

526
00:20:02,220 --> 00:20:05,220
重要信息就依靠多条通路同时传递

527
00:20:05,220 --> 00:20:08,020
它并不是说当下就要落地这套方案

528
00:20:08,020 --> 00:20:10,300
但是这类思想实验意义重大

529
00:20:10,300 --> 00:20:13,500
要定期重新审视所有人习以为常的预设

530
00:20:13,500 --> 00:20:15,120
回顾他的职业生涯

531
00:20:15,120 --> 00:20:19,100
TPU的诞生就是推翻固有假设之后接触的果实

532
00:20:19,100 --> 00:20:21,400
在问题还没有成为主流的时候

533
00:20:21,400 --> 00:20:23,720
思考小众场景的专用硬件

534
00:20:23,720 --> 00:20:25,420
MapReduce也是同理

535
00:20:25,420 --> 00:20:28,000
团队厌倦了手工编写大量并行

536
00:20:28,000 --> 00:20:29,840
容错相关的重复代码

537
00:20:29,840 --> 00:20:31,920
于是提出全新抽象框架

538
00:20:31,920 --> 00:20:34,340
上层只需要编写业务逻辑

539
00:20:34,340 --> 00:20:36,920
底层统一处理并行调度和容错

540
00:20:36,920 --> 00:20:40,040
最后成为谷歌大规模计算的核心底座

541
00:20:40,040 --> 00:20:41,640
而这一切的源头

542
00:20:41,640 --> 00:20:43,340
同样来自思想实验

543
00:20:43,340 --> 00:20:45,700
现在有Alpha Chip辅助芯片布局

544
00:20:45,700 --> 00:20:48,560
有Alpha UVO完成方案生成评估留存

545
00:20:48,560 --> 00:20:50,620
整套AI制造AI的体系

546
00:20:50,620 --> 00:20:51,900
正在逐步成型

547
00:20:51,900 --> 00:20:52,880
广义来讲

548
00:20:52,880 --> 00:20:55,320
这本质就是科学方法的自动化

549
00:20:55,320 --> 00:20:56,380
提出假设

550
00:20:56,380 --> 00:20:57,440
搭建环境

551
00:20:57,440 --> 00:20:58,360
执行实验

552
00:20:58,360 --> 00:20:59,380
评估结果

553
00:20:59,380 --> 00:21:01,040
循环往复推进迭代

554
00:21:01,040 --> 00:21:02,560
如今越来越多领域

555
00:21:02,560 --> 00:21:04,200
可以把这套闭环自动化

556
00:21:04,200 --> 00:21:06,100
一次性执行海量实验

557
00:21:06,100 --> 00:21:07,520
压缩循环延迟

558
00:21:07,520 --> 00:21:08,780
就变得格外关键

559
00:21:08,780 --> 00:21:11,620
前提是评估器本身要足够快速

560
00:21:11,620 --> 00:21:13,620
他举了一个十年之前的案例

561
00:21:13,620 --> 00:21:15,300
同事研究量子化学

562
00:21:15,300 --> 00:21:16,620
解析分子属性

563
00:21:16,620 --> 00:21:18,480
传统密度泛含理论模拟器

564
00:21:18,480 --> 00:21:20,060
跑一次就要耗费一整夜

565
00:21:20,060 --> 00:21:22,540
团队收集大量输入输出样本

566
00:21:22,540 --> 00:21:24,760
训练神经网络近似模拟器

567
00:21:24,760 --> 00:21:26,500
速度提升30万倍

568
00:21:26,500 --> 00:21:28,480
精度却几乎没有损失

569
00:21:28,480 --> 00:21:30,220
彻底改写科研模式

570
00:21:30,220 --> 00:21:32,320
从前筛选1000万候选分子

571
00:21:32,320 --> 00:21:34,040
要耗费6个月筹备算力

572
00:21:34,040 --> 00:21:35,580
现在一顿午饭的时间

573
00:21:35,580 --> 00:21:36,760
就可以完成筛选

574
00:21:36,760 --> 00:21:39,780
大量行业还有机会打造高速仿真模型

575
00:21:39,780 --> 00:21:40,720
一旦实现

576
00:21:40,720 --> 00:21:43,620
整个实验迭代周期就会被彻底重构

577
00:21:43,620 --> 00:21:45,140
它最看好的方向

578
00:21:45,140 --> 00:21:47,080
就是模型依靠大量实验

579
00:21:47,080 --> 00:21:48,900
实现地规式自我改进

580
00:21:48,900 --> 00:21:50,880
持续提升每一份算力

581
00:21:50,880 --> 00:21:52,300
可以产出的新发现

582
00:21:52,300 --> 00:21:53,900
对话推进到后半段

583
00:21:53,900 --> 00:21:55,460
谈及职业路上的挫折

584
00:21:55,460 --> 00:21:56,900
2014年杰弗蒂恩

585
00:21:56,900 --> 00:21:57,960
杰弗里辛顿

586
00:21:57,960 --> 00:21:59,400
奥里奥尔维尼亚尔斯

587
00:21:59,400 --> 00:22:01,400
联合发布知识蒸馏论文

588
00:22:01,400 --> 00:22:03,340
用大模型充当老师

589
00:22:03,340 --> 00:22:04,860
小模型充当学生

590
00:22:04,860 --> 00:22:06,120
得到体积更小

591
00:22:06,120 --> 00:22:07,000
成本更低

592
00:22:07,000 --> 00:22:08,600
同时效果优异的模型

593
00:22:08,600 --> 00:22:11,000
如今整个行业都在广泛使用

594
00:22:11,000 --> 00:22:13,700
但是这篇论文当年被NIPS聚稿

595
00:22:13,700 --> 00:22:15,000
评审的观点认为

596
00:22:15,000 --> 00:22:16,900
这项工作很难带来重大突破

597
00:22:16,900 --> 00:22:18,060
杰弗迪恩表示

598
00:22:18,060 --> 00:22:19,660
并不责怪评审委员会

599
00:22:19,660 --> 00:22:21,320
对方站在学术视角

600
00:22:21,320 --> 00:22:24,100
评判是否属于理论层面的重大突破

601
00:22:24,100 --> 00:22:26,980
而团队清楚这件事巨大的工程价值

602
00:22:26,980 --> 00:22:29,280
目标是降低模型服务成本

603
00:22:29,280 --> 00:22:30,680
扩大落地场景

604
00:22:30,680 --> 00:22:33,800
他们把论文上传到ARXV预印本平台

605
00:22:33,800 --> 00:22:35,580
行业从业者阅读之后

606
00:22:35,580 --> 00:22:36,640
大量落地使用

607
00:22:36,640 --> 00:22:38,800
Gemini当中的Flash系列模型

608
00:22:38,800 --> 00:22:41,920
就有一部分来自大尺寸Pro模型的蒸馏

609
00:22:41,920 --> 00:22:43,660
在同规格模型当中

610
00:22:43,660 --> 00:22:45,520
基准测试表现十分靠前

611
00:22:45,520 --> 00:22:47,360
这件事带来的启示就是

612
00:22:47,360 --> 00:22:49,040
就算成果遭到拒绝

613
00:22:49,040 --> 00:22:50,280
也不要停下脚步

614
00:22:50,280 --> 00:22:51,820
如果把1999年

615
00:22:51,820 --> 00:22:55,140
刚刚加入只有20人规模谷歌的年轻杰弗迪恩

616
00:22:55,140 --> 00:22:57,080
直接传送到2026年

617
00:22:57,080 --> 00:22:59,340
他会选择大厂前沿实验室

618
00:22:59,340 --> 00:23:01,020
还是选择自主创业

619
00:23:01,020 --> 00:23:02,840
他表示没有标准答案

620
00:23:02,840 --> 00:23:04,236
最核心的判断表现

621
00:23:17,036 --> 00:23:18,616
创业公司风险更高

622
00:23:18,616 --> 00:23:20,196
必须拥有极强的热情

623
00:23:20,196 --> 00:23:22,036
但也可以收获极高的回报

624
00:23:22,036 --> 00:23:23,776
无论选择哪一条道路

625
00:23:23,776 --> 00:23:24,976
都要反问自己

626
00:23:24,976 --> 00:23:27,016
如果项目走到最好的结局

627
00:23:27,016 --> 00:23:28,876
世界会不会切实变好

628
00:23:28,876 --> 00:23:30,436
如果仅仅只是很酷

629
00:23:30,436 --> 00:23:32,396
就不值得投入大量时间

630
00:23:32,396 --> 00:23:34,836
谈及如何寻找优秀的合作者

631
00:23:34,836 --> 00:23:36,876
不仅要寻找专业能力过硬

632
00:23:36,876 --> 00:23:38,196
技能互补的伙伴

633
00:23:38,196 --> 00:23:40,896
也要选择相处起来足够愉快的人

634
00:23:40,896 --> 00:23:43,836
创业路上要共同面对大量棘手难题

635
00:23:43,836 --> 00:23:45,796
彼此的相处体验格外重要

636
00:23:45,796 --> 00:23:49,816
小团队的魅力就是每个人掌握其他人不具备的能力

637
00:23:49,816 --> 00:23:53,016
组合在一起可以完成单人无法实现的成果

638
00:23:53,016 --> 00:23:56,236
要把自己的工程或者科研生涯当成一条工具腰带

639
00:23:56,236 --> 00:23:57,956
持续补充新的工具

640
00:23:57,956 --> 00:24:01,016
你永远预料不到未来会碰到什么样的难题

641
00:24:01,016 --> 00:24:02,436
掌握的工具越多

642
00:24:02,436 --> 00:24:04,816
可以解决的问题边界就越宽广

643
00:24:04,816 --> 00:24:06,736
主持人抛出最后一个问题

644
00:24:06,736 --> 00:24:10,436
他希望新一代创作者把精力投入到哪些方向

645
00:24:10,436 --> 00:24:11,716
杰弗迪恩讲到

646
00:24:11,716 --> 00:24:13,696
值得探索的问题数不胜数

647
00:24:13,696 --> 00:24:16,336
他个人十分看好全新硬件路线

648
00:24:16,336 --> 00:24:18,936
高效推理硬件拥有巨大价值

649
00:24:18,936 --> 00:24:21,976
机器学习算法本身也还有巨大革新空间

650
00:24:21,976 --> 00:24:25,196
比如数据效率远远高于当下的系统

651
00:24:25,196 --> 00:24:27,836
现在大模型18岁阶段接触的数据总量

652
00:24:27,836 --> 00:24:30,596
比人类18岁接触的信息多出1000倍

653
00:24:30,596 --> 00:24:32,676
但是人类在大量任务当中

654
00:24:32,676 --> 00:24:34,816
依旧可以持平甚至优于大模型

655
00:24:34,816 --> 00:24:37,176
我们能不能打造数据效率更高

656
00:24:37,176 --> 00:24:40,516
可以从自身行动当中持续学习的系统

657
00:24:40,516 --> 00:24:43,196
持续学习本身就是极具价值的课题

658
00:24:43,196 --> 00:24:46,176
多agent交互同样充满想象空间

659
00:24:46,176 --> 00:24:47,896
把视角在向外延伸

660
00:24:47,896 --> 00:24:50,396
如何促成人类之间更良性的对话

661
00:24:50,396 --> 00:24:52,736
搭建工具帮助人们理性交流

662
00:24:52,736 --> 00:24:55,276
帮助志趣相投的人建立连接

663
00:24:55,276 --> 00:24:57,436
同样是值得深耕的方向

664
00:24:57,436 --> 00:24:58,536
整场对话听完

665
00:24:58,536 --> 00:25:01,376
不难感受到杰弗迪恩看待行业的独特视角

666
00:25:01,376 --> 00:25:04,016
他不会空谈AGI什么时候到来

667
00:25:04,016 --> 00:25:05,116
而是立足于能耗

668
00:25:05,116 --> 00:25:05,936
数据搬运

669
00:25:05,936 --> 00:25:07,796
延迟这些底层物理约束

670
00:25:07,796 --> 00:25:09,676
向上推导系统设计逻辑

671
00:25:09,676 --> 00:25:10,996
推导创业机会

672
00:25:10,996 --> 00:25:13,556
全行业疯狂内卷模型参数的时候

673
00:25:13,556 --> 00:25:17,156
他提醒大家数据搬运的成本是计算的1000倍

674
00:25:17,156 --> 00:25:20,636
推理硬件专用化是下一轮效率跃升的关键

675
00:25:20,636 --> 00:25:23,696
所有人焦虑通用模型吞噬创业机会

676
00:25:23,696 --> 00:25:27,676
他告诉大家去寻找成功率0%到1%的赛道

677
00:25:27,676 --> 00:25:28,996
挖掘私有数据

678
00:25:28,996 --> 00:25:30,756
垂直专用模型的机会

679
00:25:30,756 --> 00:25:33,116
所有人埋头打磨提示词的时候

680
00:25:33,116 --> 00:25:35,856
他点名未来最稀缺的资源是品位

681
00:25:35,856 --> 00:25:37,796
是筛选问题的判断力

682
00:25:37,796 --> 00:25:39,996
这些认知不是凭空想象

683
00:25:39,996 --> 00:25:42,096
来自几十年系统工程沉淀

684
00:25:42,096 --> 00:25:44,176
来自一次次参金值演算

685
00:25:44,176 --> 00:25:46,976
来自一次次推翻固有认知的思想实验

686
00:25:46,976 --> 00:25:49,376
以上就是整场访谈的核心精华

687
00:25:49,376 --> 00:25:52,436
如果你觉得这些来自一线工程大佬的思考

688
00:25:52,436 --> 00:25:53,236
对你有启发

689
00:25:53,236 --> 00:25:54,336
欢迎点赞

690
00:25:54,336 --> 00:25:57,996
也可以把这期内容分享给身边做AI开发创业的朋友

691
00:25:57,996 --> 00:26:00,236
一起跳出网络上的流量炒作

692
00:26:00,236 --> 00:26:02,636
看见行业更真实的底层逻辑

693
00:26:02,636 --> 00:26:03,836
我们下期再见