1
00:00:00,000 --> 00:00:27,580
9月15日迪奥哥·阿尔梅达在X上发了一条帖子。第一句话就很抓人。他说,参与创造XGP之后,我一直在问自己,为什么这些已经超过人类水平的聊天模型,没有带来AGI呢?这个问题从他嘴里说出来,确实有点特别。阿尔梅达是Intract GPT的作者之一,也参与过GPT4的RLHF和指令遵循的相关工作。

2
00:00:27,580 --> 00:00:28,980
简单来说

3
00:00:28,980 --> 00:00:31,900
今天我们已经习以为常的这件事

4
00:00:31,900 --> 00:00:34,020
就是你对AI说一句话

5
00:00:34,020 --> 00:00:35,860
它能够理解你想干什么

6
00:00:35,860 --> 00:00:38,120
然后按照你的要求回答

7
00:00:38,120 --> 00:00:40,180
它就是这个早期参与

8
00:00:40,180 --> 00:00:42,720
把这条路线做出来的人之一

9
00:00:42,720 --> 00:00:45,100
不过参与创造ChatGPT

10
00:00:45,100 --> 00:00:46,300
是它自己的表述

11
00:00:46,300 --> 00:00:48,220
并不是OpenAI给它的

12
00:00:48,220 --> 00:00:50,500
ChatGPT联合发明人头衔

13
00:00:50,500 --> 00:00:53,740
但是ChatGPT出现以后

14
00:00:53,740 --> 00:00:55,780
它反而开始怀疑一件事了

15
00:00:55,780 --> 00:00:58,680
就是模型已经越来越会说话了

16
00:00:58,680 --> 00:01:01,880
那为什么我们期待中的大规模自动化

17
00:01:01,880 --> 00:01:04,040
却没有以同样的速度发生呢

18
00:01:04,040 --> 00:01:05,800
于是过去两年

19
00:01:05,800 --> 00:01:08,520
阿尔梅达一直在隐身做另一件东西

20
00:01:08,520 --> 00:01:09,620
直到这几天

21
00:01:09,620 --> 00:01:11,900
他和自己的公司TypeSafe AI

22
00:01:11,900 --> 00:01:13,340
才把它公开出来

23
00:01:13,340 --> 00:01:15,100
这个模型叫Jeff

24
00:01:15,100 --> 00:01:16,380
你知道吗

25
00:01:16,380 --> 00:01:19,060
TypeSafe给出的数字非常夸张

26
00:01:19,060 --> 00:01:21,720
说它20到200倍更快

27
00:01:21,720 --> 00:01:23,620
40到400倍更便宜

28
00:01:23,620 --> 00:01:25,560
不过我看到这里的时候

29
00:01:25,560 --> 00:01:28,700
真正让我觉得有意思的还不是这些数字

30
00:01:28,700 --> 00:01:31,860
而是Jav做了一件非常反常识的事情

31
00:01:31,860 --> 00:01:33,720
就是他不会说话

32
00:01:33,720 --> 00:01:34,740
真的不会

33
00:01:34,740 --> 00:01:37,060
Jav他不跟你聊天

34
00:01:37,060 --> 00:01:37,920
不写文章

35
00:01:37,920 --> 00:01:39,820
也不生成自由文本

36
00:01:39,820 --> 00:01:40,960
你把一段对话

37
00:01:40,960 --> 00:01:42,500
一个agent的当前的状态

38
00:01:42,500 --> 00:01:44,420
或者一堆数据交给他

39
00:01:44,420 --> 00:01:45,260
然后问他

40
00:01:45,260 --> 00:01:46,680
这个请求安全吗

41
00:01:46,680 --> 00:01:48,960
下一步应该调用哪个工具呢

42
00:01:48,960 --> 00:01:50,820
这几个方案选哪一个呢

43
00:01:50,820 --> 00:01:51,900
这之后

44
00:01:51,900 --> 00:01:53,900
Jav不会先写一段分析

45
00:01:53,900 --> 00:01:56,240
也不需要慢慢吐出一串杰森

46
00:01:56,240 --> 00:01:57,980
他会直接给你决定

47
00:01:57,980 --> 00:02:00,540
以及他对这个决定有多大把握

48
00:02:00,540 --> 00:02:02,380
欢迎回到All Insight

49
00:02:02,380 --> 00:02:04,200
在继续今天的视频之前

50
00:02:04,200 --> 00:02:06,840
我想先感谢一直支持这个频道的朋友

51
00:02:06,840 --> 00:02:09,640
我知道还有不少观看我视频的朋友

52
00:02:09,640 --> 00:02:10,860
还没有订阅我的频道

53
00:02:10,860 --> 00:02:13,740
那如果你觉得我的内容对你有所帮助

54
00:02:13,740 --> 00:02:15,800
欢迎点赞分享和订阅

55
00:02:15,800 --> 00:02:17,480
也可以加入频道会员

56
00:02:17,480 --> 00:02:19,440
每个月一杯咖啡的钱

57
00:02:19,440 --> 00:02:20,960
不仅是对我的支持

58
00:02:20,960 --> 00:02:26,620
也会帮助我继续制作更多关于AI和未来技术方向的深度内容

59
00:02:26,620 --> 00:02:29,340
好的 接下来我们进入今天的主题

60
00:02:29,340 --> 00:02:33,260
这件事听起来好像只是少生成了一些文字

61
00:02:33,260 --> 00:02:35,320
但放到今天的agent里面

62
00:02:35,320 --> 00:02:38,080
你会发现问题其实没有那么简单

63
00:02:38,080 --> 00:02:42,600
现在一个agent每走一步可能都要做很多判断

64
00:02:42,600 --> 00:02:45,180
比如下一步该调用哪个工具

65
00:02:45,180 --> 00:02:47,260
这个结果能不能相信

66
00:02:47,260 --> 00:02:48,580
要不要继续

67
00:02:48,580 --> 00:02:50,680
需不需要升级到更强的模型

68
00:02:50,680 --> 00:02:53,600
很多时候我们真正需要的

69
00:02:53,600 --> 00:02:55,920
其实只是一个是或者不是

70
00:02:55,920 --> 00:02:57,400
ABC选哪个

71
00:02:57,400 --> 00:02:59,500
但今天最常见的做法

72
00:02:59,500 --> 00:03:02,460
是把整个上下文交给一个大语言模型

73
00:03:02,460 --> 00:03:05,700
让它先生成文字或者结构化输出

74
00:03:05,700 --> 00:03:08,500
然后程序再从这些输出里

75
00:03:08,500 --> 00:03:10,160
拿出最后那个决定

76
00:03:10,160 --> 00:03:13,980
所以阿尔梅达这次实际上是在问

77
00:03:13,980 --> 00:03:16,980
如果软件真正需要的只是一个决定

78
00:03:16,980 --> 00:03:19,980
那为什么一定要让AI先说一段话呢

79
00:03:19,980 --> 00:03:21,500
Jav发布以后

80
00:03:21,500 --> 00:03:25,140
X上很快出现了两种不同的声音

81
00:03:25,140 --> 00:03:26,760
第一种反应非常直接

82
00:03:26,760 --> 00:03:29,000
就是等等这不就是分类器吗

83
00:03:29,000 --> 00:03:31,660
独立AI研究者Alexis Gallagher就说

84
00:03:31,660 --> 00:03:33,260
他觉得Jav很酷

85
00:03:33,260 --> 00:03:36,140
但更有意思的是大家对Jav的反应

86
00:03:36,140 --> 00:03:39,320
因为这似乎说明很多人已经忘了

87
00:03:39,320 --> 00:03:42,420
锦编码器分类器已经存在很多年了

88
00:03:42,420 --> 00:03:43,900
而且一直很好用

89
00:03:43,900 --> 00:03:46,020
像Modern Bird这样的模型

90
00:03:46,020 --> 00:03:49,840
本来就可以快速和廉价的完成结构化判断

91
00:03:49,840 --> 00:03:51,540
Jav也许更好

92
00:03:51,540 --> 00:03:54,560
而且不需要针对每一个任务重新训练

93
00:03:54,560 --> 00:03:56,960
但这个类别本身并不新

94
00:03:56,960 --> 00:04:01,400
另一边XBOM的AI研究员Lan Butler马上反驳说

95
00:04:01,400 --> 00:04:04,000
问题恰恰就在不需要重新训练

96
00:04:04,000 --> 00:04:06,820
如果今天突然给你一个非常奇怪

97
00:04:06,820 --> 00:04:09,220
而且类别又特别多的决策任务

98
00:04:09,220 --> 00:04:11,060
你手里甚至还没有数据集

99
00:04:11,060 --> 00:04:13,380
那传统分类器怎么办

100
00:04:13,380 --> 00:04:16,900
而Jav的卖点就是直接用自然语言告诉他

101
00:04:16,900 --> 00:04:18,200
现在要判断什么

102
00:04:18,200 --> 00:04:19,840
更有意思的是

103
00:04:19,840 --> 00:04:21,500
已经有人不吵了

104
00:04:21,500 --> 00:04:24,460
他们直接把Jab塞进agent里面开始跑

105
00:04:24,460 --> 00:04:26,600
有人拿它做模型路由

106
00:04:26,600 --> 00:04:29,480
让Jab决定什么时候该用便宜模型

107
00:04:29,480 --> 00:04:31,620
什么时候升级到更强的模型

108
00:04:31,620 --> 00:04:34,860
还有人拿它做Computer Use的下一步决策

109
00:04:34,860 --> 00:04:36,780
还有一个叫Observed开发者

110
00:04:36,780 --> 00:04:40,060
测试了一整晚跑了500多次API

111
00:04:40,060 --> 00:04:42,240
总共才花了大约3美分

112
00:04:42,240 --> 00:04:44,640
一次同时多问20个问题

113
00:04:44,640 --> 00:04:47,340
延迟也只增加了47毫秒

114
00:04:47,340 --> 00:04:51,780
他还抓住了一次针对他自己agent的假审批注入

115
00:04:51,780 --> 00:04:54,860
然后他发现Jeff有一次打错了

116
00:04:54,860 --> 00:04:58,220
而Jeff给那个错误答案给出的信心是1.00

117
00:04:58,220 --> 00:04:59,920
这就有意思了

118
00:04:59,920 --> 00:05:03,160
一边是这不就是我们用了很多年的分类器吗

119
00:05:03,160 --> 00:05:08,180
而另一边却已经有人开始把他塞进agent的决策循环

120
00:05:08,180 --> 00:05:10,700
官方说他的概率经过较准

121
00:05:10,700 --> 00:05:13,380
但在真实测试里却已经出现了

122
00:05:13,380 --> 00:05:16,060
答错了但信心百分之百的情况

123
00:05:16,060 --> 00:05:20,020
所以这期视频我真正想弄清楚的

124
00:05:20,020 --> 00:05:22,360
不是Jav到底有没有快200倍

125
00:05:22,360 --> 00:05:25,740
而是说一个参与创造ChattGPT的人

126
00:05:25,740 --> 00:05:27,940
在模型越来越会说话之后

127
00:05:27,940 --> 00:05:29,760
为什么会花两年的时间

128
00:05:29,760 --> 00:05:31,960
重新做一个不会说话的AI呢

129
00:05:31,960 --> 00:05:35,220
以及他是不是碰到了今天A成的系统里

130
00:05:35,220 --> 00:05:36,680
一个更有意思的问题

131
00:05:36,680 --> 00:05:40,480
就是我们真的需要让大模型来做每一个决定吗

132
00:05:40,480 --> 00:05:43,400
那么一个不生成自由文本的AI

133
00:05:43,400 --> 00:05:45,240
到底是怎么工作的呢

134
00:05:45,240 --> 00:05:48,300
TypeSafe对Jav的描述其实很简洁

135
00:05:48,300 --> 00:05:49,980
翻译过来的意思就是

136
00:05:49,980 --> 00:05:51,580
输入可以很复杂

137
00:05:51,580 --> 00:05:54,580
但输出不再是一串自由生成的文字

138
00:05:54,580 --> 00:05:58,040
而是提前定义好类型的概率决策

139
00:05:58,040 --> 00:06:01,520
比如一个客服agent的正在处理退款请求

140
00:06:01,520 --> 00:06:03,960
你可以把完整的对话记录

141
00:06:03,960 --> 00:06:05,220
用户账户状态

142
00:06:05,220 --> 00:06:07,960
以及最近的付款记录一起交给Jav

143
00:06:07,960 --> 00:06:09,140
然后同时问他

144
00:06:09,140 --> 00:06:11,680
用户现在是不是在要求退款呢

145
00:06:11,680 --> 00:06:13,320
有没有欺诈风险呢

146
00:06:13,320 --> 00:06:14,760
需不需要转人工呢

147
00:06:14,760 --> 00:06:16,460
如果要继续处理

148
00:06:16,460 --> 00:06:18,620
下一步应该执行哪个动作呢

149
00:06:18,620 --> 00:06:22,660
当然普通大模型也能回答这些问题

150
00:06:22,660 --> 00:06:24,760
但它通常还是要生成

151
00:06:24,760 --> 00:06:27,140
哪怕最后输出的是JESN

152
00:06:27,140 --> 00:06:29,780
本质上也是一个Token接一个Token的

153
00:06:29,780 --> 00:06:31,320
把字符串写出来

154
00:06:31,320 --> 00:06:33,460
但JESN走的是另一条路

155
00:06:33,460 --> 00:06:36,260
他把这些问题直接变成了几个

156
00:06:36,260 --> 00:06:37,820
类型确定的决策

157
00:06:37,820 --> 00:06:40,360
而且可以一次并行回答

158
00:06:40,360 --> 00:06:43,020
TypeSafe目前把这种输出

159
00:06:43,020 --> 00:06:45,020
分成三种基本形式

160
00:06:45,020 --> 00:06:46,340
第一种叫Nual

161
00:06:46,340 --> 00:06:48,420
它处理是不是这一类的判断

162
00:06:48,420 --> 00:06:51,300
比如这个请求有没有越狱风险

163
00:06:51,300 --> 00:06:53,100
那么它返回的就不是一句

164
00:06:53,100 --> 00:06:53,980
我认为没有

165
00:06:53,980 --> 00:06:56,500
而是说这个判断对应的概率

166
00:06:56,500 --> 00:06:58,000
第二种叫Choice

167
00:06:58,000 --> 00:07:01,640
也就是从提前给定的选项里做选择

168
00:07:01,640 --> 00:07:04,060
比如一个Agent手里有八个工具

169
00:07:04,060 --> 00:07:05,800
现在应该调用哪一个呢

170
00:07:05,800 --> 00:07:08,400
Jive直接在这八个选项里做判断

171
00:07:08,400 --> 00:07:10,080
并给出相应的概率

172
00:07:10,080 --> 00:07:11,600
第三种叫Score

173
00:07:11,600 --> 00:07:13,580
用来处理打分和排序

174
00:07:13,580 --> 00:07:15,960
比如一个任务的优先级有多高

175
00:07:15,960 --> 00:07:18,260
或者一个结果有多值得信任

176
00:07:33,246 --> 00:07:35,546
JF在开始计算之前

177
00:07:35,546 --> 00:07:38,766
输出空间就已经被软件定义好了

178
00:07:38,766 --> 00:07:40,146
它可以判断

179
00:07:40,146 --> 00:07:43,046
但它不能临场发明一个新的答案

180
00:07:43,046 --> 00:07:45,126
这里还有一个很容易被忽略的区别

181
00:07:45,126 --> 00:07:49,126
就是这些判断不一定要一个接一个的做

182
00:07:49,126 --> 00:07:51,526
Type-Safe官方展示的Workflow

183
00:07:51,526 --> 00:07:54,406
本身就会把一个复杂的软件状态

184
00:07:54,406 --> 00:07:56,066
拆成很多独立的问题

185
00:07:56,066 --> 00:07:57,926
然后一次并行询问

186
00:07:57,926 --> 00:08:00,306
比如他们公开的客服工作流

187
00:08:00,306 --> 00:08:03,286
第一步就会同时读取用户意图

188
00:08:03,286 --> 00:08:07,406
情绪紧急程度以及欺诈风险等多个信号

189
00:08:07,406 --> 00:08:09,126
在后面的代码决定

190
00:08:09,126 --> 00:08:13,126
退款冻结银行卡转人工还是继续处理

191
00:08:13,126 --> 00:08:17,546
这时候我们再回头看TypeSafe给这种模型起的名字

192
00:08:17,546 --> 00:08:19,346
就比较容易理解了

193
00:08:19,346 --> 00:08:21,286
他们叫它System-1 Module

194
00:08:21,286 --> 00:08:26,246
这个名字来自丹尼尔·卡尼曼对System-1和System-2的区别

195
00:08:26,246 --> 00:08:30,646
他认为System-1负责快速和直觉式的判断

196
00:08:30,646 --> 00:08:33,946
System-2才负责缓慢和复杂的推理

197
00:08:33,946 --> 00:08:38,806
那Type-C想做的不是让Jeff取代所有大语言模型

198
00:08:38,806 --> 00:08:44,206
而是把软件系统里大量这种快速判断单独抽出来

199
00:08:44,206 --> 00:08:47,386
阿尔梅达后来把这个速度说得更直接

200
00:08:47,386 --> 00:08:50,726
他说他们把今天几条不同的训练路线

201
00:08:50,726 --> 00:08:52,906
看成是在解决不同的问题

202
00:08:52,906 --> 00:08:56,646
像RLVR就更适合可以验证答案的

203
00:08:56,646 --> 00:08:58,046
Resonings和Proves

204
00:08:58,046 --> 00:09:02,926
而他们希望RLCD去解决的是自动控制

205
00:09:02,926 --> 00:09:04,986
也就是让模型的决定

206
00:09:04,986 --> 00:09:07,766
真正能够被软件直接使用

207
00:09:07,766 --> 00:09:09,366
这也是为什么Type-Safe

208
00:09:09,366 --> 00:09:11,626
一直把Jeff的典型用途写成

209
00:09:11,626 --> 00:09:15,346
分类 路由 打分 提取和分支判断

210
00:09:15,346 --> 00:09:17,606
他们甚至用了一个狠形象的说法

211
00:09:17,606 --> 00:09:19,326
是聪明的一笔句

212
00:09:19,326 --> 00:09:21,146
听到这里

213
00:09:21,146 --> 00:09:23,506
Jav好像已经也没有那么神秘了

214
00:09:23,506 --> 00:09:26,666
他不是一个被砍掉聊天界面的GPT

215
00:09:26,666 --> 00:09:29,346
也不是为了写出更好的答案

216
00:09:29,346 --> 00:09:31,906
而是他想把做决定本身

217
00:09:31,906 --> 00:09:34,146
从语言生成里单独拆出来

218
00:09:34,146 --> 00:09:37,726
变成软件可以直接调语的一种智能原语

219
00:09:37,726 --> 00:09:41,406
但是这也就回到了开场那个质疑

220
00:09:41,406 --> 00:09:43,346
就是这不就是分类器吗

221
00:09:43,346 --> 00:09:45,906
以太坊基军会AI的负责人

222
00:09:45,906 --> 00:09:48,326
David Krapis的说法就更直接了

223
00:09:48,326 --> 00:09:52,006
他认为把Jav和通用ML放在一起比较

224
00:09:52,006 --> 00:09:53,306
很容易产生误导

225
00:09:53,306 --> 00:09:56,326
因为Jav根本不生成自由文本

226
00:09:56,326 --> 00:09:57,666
从功能上看

227
00:09:57,666 --> 00:10:00,066
它更接近一个非常聪明的工具

228
00:10:00,066 --> 00:10:01,306
或者一个分类器

229
00:10:01,306 --> 00:10:05,526
而不是GPT Cloud这种通用模型的直接竞争者

230
00:10:05,526 --> 00:10:07,346
有人继续往下拆

231
00:10:07,346 --> 00:10:10,466
Robert世文透客把Jav的几个卖点

232
00:10:10,466 --> 00:10:11,926
一条一条列了出来

233
00:10:11,926 --> 00:10:14,086
像是类型受限的输出

234
00:10:14,086 --> 00:10:16,546
我们已经可以用受限解码做

235
00:10:16,546 --> 00:10:19,026
概率可以从LogProps里面拿

236
00:10:19,026 --> 00:10:22,466
概率校准也早就有Temperature Scaling

237
00:10:22,466 --> 00:10:23,686
什么时候放行

238
00:10:23,686 --> 00:10:24,626
什么时候升级

239
00:10:24,626 --> 00:10:27,806
本来就可以在应用代表里面写Threathood

240
00:10:27,806 --> 00:10:31,066
所以他最后的评价其实很有意思

241
00:10:31,066 --> 00:10:33,566
他认为这些统计学上的零件

242
00:10:33,566 --> 00:10:36,166
没有哪一个是突然从天上掉下来的

243
00:10:36,166 --> 00:10:41,306
真正可能不同的是TypeSafe把校准放进了训练目标

244
00:10:41,306 --> 00:10:44,966
然后让API从一开始返回的就是Decision

245
00:10:44,966 --> 00:10:48,186
而不是一段等待程序再次解析的文字

246
00:10:48,186 --> 00:10:49,146
换句话说

247
00:10:49,146 --> 00:10:52,306
就不是发明了一堆从来没有存在过的零件

248
00:10:52,306 --> 00:10:54,546
而是少兵了几层东西

249
00:10:54,546 --> 00:10:56,746
这时候Jav就不是分类器吗

250
00:10:56,746 --> 00:10:59,146
这个问题就开始变得没那么简单了

251
00:10:59,146 --> 00:11:02,006
因为TypeSafe真正想挑战的

252
00:11:02,006 --> 00:11:04,866
并不是传统分类器做不到的分类

253
00:11:04,866 --> 00:11:06,426
而是它的使用方式

254
00:11:06,426 --> 00:11:09,766
假设你今天做一个金融agent

255
00:11:09,766 --> 00:11:11,366
你只需要判断的是

256
00:11:11,366 --> 00:11:13,626
这笔交易有没有欺诈风险

257
00:11:13,626 --> 00:11:17,166
那你当然可以收集数据标注样本

258
00:11:17,166 --> 00:11:18,726
训练一个专门的分类器

259
00:11:18,726 --> 00:11:20,486
如果业务一直不变

260
00:11:20,486 --> 00:11:23,226
这就可能比调用GF更便宜更快

261
00:11:23,226 --> 00:11:24,366
甚至更可靠

262
00:11:24,366 --> 00:11:28,206
但现实里的agent很少永远只问同一个问题

263
00:11:28,206 --> 00:11:30,346
今天你要判断的是欺诈

264
00:11:30,346 --> 00:11:33,086
明天可能增加是否需要人工复合

265
00:11:33,086 --> 00:11:34,826
后天可能又增加

266
00:11:34,826 --> 00:11:36,906
应该交给哪个风险团队

267
00:11:36,906 --> 00:11:38,026
换一个产品

268
00:11:38,026 --> 00:11:42,006
问题标签和业务规则可能全部都变了

269
00:11:42,006 --> 00:11:43,866
如果每增加一种判断

270
00:11:43,866 --> 00:11:45,486
都要重新积累数据

271
00:11:45,486 --> 00:11:47,046
训练和部署一个模型

272
00:11:47,046 --> 00:11:49,206
那传统分类器的成本

273
00:11:49,206 --> 00:11:51,066
就开始从推理阶段

274
00:11:51,066 --> 00:11:53,526
转移到了开发和维护阶段

275
00:11:53,526 --> 00:11:55,046
而Jeff想做的是把

276
00:11:55,046 --> 00:11:58,566
大语言模型最有价值的一部分能力保留下来

277
00:11:58,566 --> 00:12:01,306
就是你可以直接用自然语言告诉模型

278
00:12:01,306 --> 00:12:02,866
现在要判断什么

279
00:12:02,866 --> 00:12:06,546
那我们目前还没有看到

280
00:12:06,546 --> 00:12:08,926
Jeff和一个认真微调过的

281
00:12:08,926 --> 00:12:09,786
Martin Burrton

282
00:12:09,786 --> 00:12:11,826
专门的小型分类器

283
00:12:11,826 --> 00:12:15,086
或者一个使用受限解码的小语言模型

284
00:12:15,086 --> 00:12:19,026
在同样任务同样数据同样准确率要求下

285
00:12:19,026 --> 00:12:21,586
做一次真正公平的正面对比

286
00:12:21,586 --> 00:12:24,026
TypeSafe真正需要证明的是

287
00:12:24,026 --> 00:12:25,746
当任务不断变化

288
00:12:25,746 --> 00:12:28,766
而你又不想每次重新训练一个模型的时候

289
00:12:28,766 --> 00:12:32,466
Jab能不能同时保住分类器的速度和成本

290
00:12:32,466 --> 00:12:35,886
又同时保住大模型那种拿自然语言

291
00:12:35,886 --> 00:12:38,186
就能直接定义新任务的灵活性

292
00:12:38,186 --> 00:12:40,126
而这还只是第一层

293
00:12:40,126 --> 00:12:42,826
因为Type Save对Jav最大胆的主张

294
00:12:42,826 --> 00:12:45,006
其实不是快也不是便宜

295
00:12:45,006 --> 00:12:47,166
甚至不是自然语言可编程

296
00:12:47,166 --> 00:12:48,606
而是他认为

297
00:12:48,606 --> 00:12:50,766
Jav不只会给你一个决定

298
00:12:50,766 --> 00:12:54,486
他还知道自己这个决定到底有多可靠

299
00:12:54,486 --> 00:12:56,666
这就进入了整个Jav的故事里

300
00:12:56,666 --> 00:12:59,126
最关键也是目前最神秘的一块

301
00:12:59,126 --> 00:13:00,206
RLCD

302
00:13:00,206 --> 00:13:04,146
前面讲到Jav会给每一个决策附上概率

303
00:13:04,146 --> 00:13:05,926
但这里真正重要的

304
00:13:05,926 --> 00:13:09,526
不是他能不能输出一个0.73或者0.91

305
00:13:09,526 --> 00:13:13,126
而是说这些数字到底有没有统计意义

306
00:13:13,126 --> 00:13:15,606
这就是RLCD想解决的问题

307
00:13:15,606 --> 00:13:19,306
它的全称是校准决策强化学习

308
00:13:19,306 --> 00:13:20,286
所谓校准

309
00:13:20,286 --> 00:13:22,806
我们可以先用一个很简单的例子来理解

310
00:13:22,806 --> 00:13:26,446
就是如果一个模型做了很多次判断

311
00:13:26,446 --> 00:13:30,806
我们把它所有认为有70%把握的判断放在一起

312
00:13:30,806 --> 00:13:33,046
那么一个校准的好的模型

313
00:13:33,046 --> 00:13:36,766
长期来看应该有大约70%是正确的

314
00:13:36,766 --> 00:13:39,806
他说90%就应该接近90%

315
00:13:39,806 --> 00:13:42,406
说50%就真的意味着

316
00:13:42,406 --> 00:13:44,866
这件事差不多只有一半的把握

317
00:13:44,866 --> 00:13:47,246
这和准确率其实是两回事

318
00:13:47,246 --> 00:13:50,846
一个模型完全可能总体准确率很高

319
00:13:50,846 --> 00:13:53,406
但他根本不知道自己什么时候会错

320
00:13:53,406 --> 00:13:57,306
而另一个模型也许平均准确率没有高出多少

321
00:13:57,306 --> 00:13:59,306
但他在容易出错的时候

322
00:13:59,306 --> 00:14:01,486
真的会把自己的概率降下来

323
00:14:01,486 --> 00:14:03,406
对于聊天机器人来说

324
00:14:03,406 --> 00:14:05,666
这个区别可能没有那么明显

325
00:14:05,666 --> 00:14:07,206
但对于agent来说

326
00:14:07,206 --> 00:14:08,966
这就直接决定了一件事

327
00:14:08,966 --> 00:14:12,526
就是这个概率能不能拿来控制系统

328
00:14:12,526 --> 00:14:14,266
比如一个agent正在决定

329
00:14:14,266 --> 00:14:16,266
要不要自动批准退款

330
00:14:16,266 --> 00:14:18,106
债务判断可以批准

331
00:14:18,106 --> 00:14:20,066
概率99.8%

332
00:14:20,066 --> 00:14:22,406
如果经过大量测试之后

333
00:14:22,406 --> 00:14:25,666
你真的知道这种99.8%值得性

334
00:14:25,666 --> 00:14:28,346
那么harness就可以设置一个预值

335
00:14:28,346 --> 00:14:30,506
超过这个概率自动执行

336
00:14:30,506 --> 00:14:32,786
但如果只有70%

337
00:14:32,786 --> 00:14:35,166
就升级给更强更贵的模型

338
00:14:35,166 --> 00:14:38,506
如果再低一点就交给人工或者verify

339
00:14:38,506 --> 00:14:43,066
这个时候CoundEfence就不再是给人看的一个装饰数字

340
00:14:43,066 --> 00:14:46,646
它变成了Agent的内部的一种控制信号

341
00:14:46,646 --> 00:14:48,566
就是什么时候继续

342
00:14:48,566 --> 00:14:49,606
什么时候升级

343
00:14:49,606 --> 00:14:50,766
什么时候验证

344
00:14:50,766 --> 00:14:52,066
什么时候停下来

345
00:14:52,066 --> 00:14:55,106
前面那个满分信心却答错的例子

346
00:14:55,106 --> 00:14:56,706
追问的也正是这件事

347
00:14:56,706 --> 00:14:59,866
就是这些概率究竟有多可信呢

348
00:14:59,866 --> 00:15:03,406
而RLCD真正生成改变的是另一件事

349
00:15:03,406 --> 00:15:05,666
就是从训练阶段开始

350
00:15:05,666 --> 00:15:08,966
就让模型学习一个决定应该有多确定

351
00:15:08,966 --> 00:15:12,446
让概率本身也成为训练目标的一部分

352
00:15:12,892 --> 00:15:23,892
但是,我目前還沒有看到TypeSafe公開完整的論文,具體的訓練流程和損失函數,也沒有足夠完整的第三方校準基準。

353
00:15:23,892 --> 00:15:28,552
所以RLCD是否真的比现有校准方法更好

354
00:15:28,552 --> 00:15:30,952
这一部分还要等更多的证据

355
00:15:30,952 --> 00:15:33,752
这里也刚好可以解释TypeSafe另一个

356
00:15:33,752 --> 00:15:35,472
很容易让人误解的说法

357
00:15:35,472 --> 00:15:38,212
就是Jav不能产生幻觉

358
00:15:38,212 --> 00:15:42,852
如果你只允许Jav在批准和拒绝之间选择

359
00:15:42,852 --> 00:15:45,252
他确实不可能突然回答

360
00:15:45,252 --> 00:15:48,332
也许也不会捏造第三个不存在的函数

361
00:15:48,332 --> 00:15:51,012
更不会生成一段格式错误程序

362
00:15:51,012 --> 00:15:52,572
根本解析不了的Jason

363
00:15:52,572 --> 00:15:55,472
它的输出空间在计算之前

364
00:15:55,472 --> 00:15:58,072
就已经被系统类型限制好了

365
00:15:58,072 --> 00:16:01,132
但是它完全可能选择批准

366
00:16:01,132 --> 00:16:03,252
而正确答案其实是拒绝

367
00:16:03,252 --> 00:16:05,012
所以更准确的说

368
00:16:05,012 --> 00:16:07,572
Jav解决的是一种非常具体的幻觉

369
00:16:07,572 --> 00:16:09,892
它不会生成类型之外的答案

370
00:16:09,892 --> 00:16:13,252
但仍然可能在合法答案里面选错

371
00:16:13,252 --> 00:16:14,872
不过呢

372
00:16:14,872 --> 00:16:18,412
真正决定Jav能不能进入高风险自动化流程的

373
00:16:18,412 --> 00:16:19,672
还是后一个问题

374
00:16:19,672 --> 00:16:21,292
就是它选错的时候

375
00:16:21,292 --> 00:16:22,812
自己到底知不知道

376
00:16:22,812 --> 00:16:24,652
这也是为什么我觉得

377
00:16:24,652 --> 00:16:28,792
RLCD反而比Jav那个200倍更快的数字

378
00:16:28,792 --> 00:16:29,632
更值得关注

379
00:16:29,632 --> 00:16:32,572
如果一个模型只是快而且便宜

380
00:16:32,572 --> 00:16:35,232
我们其实已经有很多办法可以做到了

381
00:16:35,232 --> 00:16:39,272
但如果它能在保持这种速度和成本的同时

382
00:16:39,272 --> 00:16:43,612
给软件提供一个真正可信的不确定性信号

383
00:16:43,612 --> 00:16:46,552
那它在A层里面的位置就完全不一样了

384
00:16:46,552 --> 00:16:49,332
当然接下来还有一个跟现实的问题

385
00:16:49,332 --> 00:16:53,932
就是这些概率决策究竟能省下多少时间和成本呢

386
00:16:53,932 --> 00:16:56,272
现在我们终于可以回到

387
00:16:56,272 --> 00:16:58,992
JF发布时最新眼球的那组数字

388
00:16:58,992 --> 00:17:01,152
20到200倍更快

389
00:17:01,152 --> 00:17:03,492
40到400倍更便宜

390
00:17:03,492 --> 00:17:06,532
TypeSafe自己公布的Workflow Benchmark里面

391
00:17:06,532 --> 00:17:10,312
最高端的数字达到了193.6倍更快

392
00:17:10,312 --> 00:17:13,032
444.6倍更便宜

393
00:17:13,032 --> 00:17:15,452
这个数字第一眼看起来很离谱

394
00:17:15,452 --> 00:17:17,832
但离着JF前面的设计之后

395
00:17:17,832 --> 00:17:19,972
你会发现它其实并不神秘

396
00:17:19,972 --> 00:17:23,372
因为Jav和普通LM做计算的方式

397
00:17:23,372 --> 00:17:25,072
从一开始就不一样

398
00:17:25,072 --> 00:17:28,332
假设一个agent现在需要做20个判断

399
00:17:28,332 --> 00:17:30,652
比如用户是不是在退款

400
00:17:30,652 --> 00:17:32,112
有没有欺诈风险

401
00:17:32,112 --> 00:17:33,532
需不需要人工介入

402
00:17:33,532 --> 00:17:35,032
需要调用哪个工具

403
00:17:35,032 --> 00:17:37,252
结果要不要再验证一次

404
00:17:37,252 --> 00:17:40,372
阿尔梅达回应过一个很直接的问题

405
00:17:40,372 --> 00:17:43,072
就是为什么不干脆用受限解码呢

406
00:17:43,072 --> 00:17:44,312
他的回答是

407
00:17:44,312 --> 00:17:47,072
这层约束仍然叠在LM上

408
00:17:47,072 --> 00:17:49,332
字符串生成的开销还在

409
00:17:49,332 --> 00:17:51,592
他还提出了一更尖锐的判断

410
00:17:51,592 --> 00:17:54,172
就是模型本来就拿不准的时候

411
00:17:54,172 --> 00:17:56,552
再去限制他能选哪些输出

412
00:17:56,552 --> 00:17:58,152
反而会让模型变笨

413
00:17:58,152 --> 00:18:01,332
债务直接省掉了字符串生成这一步

414
00:18:01,332 --> 00:18:04,532
他不需要把决定翻译成一段语言

415
00:18:04,532 --> 00:18:07,532
再让软件把语言重新翻译成决定

416
00:18:07,532 --> 00:18:10,552
他的输出空间已经提前确定

417
00:18:10,552 --> 00:18:14,372
而且多个问题可以在同一次询问里并行计算

418
00:18:14,372 --> 00:18:16,872
TypeSafe公布的端到端延迟

419
00:18:16,872 --> 00:18:19,052
大约是70到500毫秒

420
00:18:19,052 --> 00:18:21,952
输入价格是每百万Token4.2美分

421
00:18:21,952 --> 00:18:24,032
输出则没有单独计费

422
00:18:24,032 --> 00:18:26,672
所以从物理账上看

423
00:18:26,672 --> 00:18:29,812
Jav比大元模型快很多便宜很多

424
00:18:29,812 --> 00:18:31,372
是完全说得通的

425
00:18:31,372 --> 00:18:33,952
但我们真正需要问的是另一件事

426
00:18:33,952 --> 00:18:37,292
就是他们比较的是不是同一种工作呢

427
00:18:37,292 --> 00:18:39,672
TypeSafe的Workflow Benchmark

428
00:18:39,672 --> 00:18:42,032
不是让Jav和GPT Cloud

429
00:18:42,032 --> 00:18:43,672
各自写一篇文章

430
00:18:43,672 --> 00:18:46,592
也不是让他们解决一道开放式的数学题

431
00:18:46,592 --> 00:18:51,372
而是专门选择软件自动化里面的System-1任务

432
00:18:51,372 --> 00:18:54,472
对照的是同样接入这套工作流的

433
00:18:54,472 --> 00:18:57,612
按要求返回结果化结果的通用LM

434
00:18:57,612 --> 00:18:59,252
比如处理一张发票

435
00:18:59,252 --> 00:19:01,832
系统真正需要的是这几个决定

436
00:19:01,832 --> 00:19:06,112
付款、赞款、要求补文件、送人工审批

437
00:19:06,112 --> 00:19:07,212
还是怀疑欺诈

438
00:19:07,212 --> 00:19:10,672
又比如一个客服agent完成了一轮任务

439
00:19:10,672 --> 00:19:15,172
系统要判断的是自动关闭、人工复合、优化复合

440
00:19:15,172 --> 00:19:17,612
还是直接通知值班人员

441
00:19:17,612 --> 00:19:22,272
这些任务天然就非常适合被拆成很多窄判断

442
00:19:22,272 --> 00:19:23,992
然后再用代码组合

443
00:19:23,992 --> 00:19:26,312
而这正好是Jav的主场

444
00:19:26,312 --> 00:19:30,132
TypeSave甚至在自己的发布文章里主动承认

445
00:19:30,132 --> 00:19:32,412
他们展示的side-by-side demo

446
00:19:32,412 --> 00:19:35,112
使用了比较短和比较密集的输入

447
00:19:35,112 --> 00:19:37,192
这会让Jav看起来更有优势

448
00:19:37,192 --> 00:19:40,592
193.6倍和444.6倍

449
00:19:40,592 --> 00:19:43,172
来自他们设计的工作流程评估

450
00:19:43,172 --> 00:19:46,472
他们认为这应该处在现实收益的高端

451
00:19:46,472 --> 00:19:51,192
而且这些workflow是公司自己模型能力团队的人做的

452
00:19:51,192 --> 00:19:53,012
所以他们也明确写了一句

453
00:19:53,012 --> 00:19:54,632
可能存在偏见

454
00:19:54,632 --> 00:19:56,432
这一点反而很重要

455
00:19:56,432 --> 00:20:00,552
因为他告诉我们200倍不是一个模型智力倍率

456
00:20:00,552 --> 00:20:01,992
他真正表达的是

457
00:20:01,992 --> 00:20:04,692
帮任务本来就是大量窄决策

458
00:20:04,692 --> 00:20:08,932
而你还让一个通用生成模型不断生成字符串的时候

459
00:20:08,932 --> 00:20:12,592
你可能正在为很多根本不需要的能力付钱

460
00:20:12,592 --> 00:20:14,952
TypeSafe的工作流程评估

461
00:20:14,952 --> 00:20:18,012
其实还暴露了另外一个很有意思的结果

462
00:20:18,012 --> 00:20:21,552
就是同一个模型把任务拆成workflow

463
00:20:21,552 --> 00:20:23,912
让代码负责确定性的规则

464
00:20:23,912 --> 00:20:27,612
让模型只负责那些真正需要判断的部分的话

465
00:20:27,612 --> 00:20:29,172
那么在这些测试里

466
00:20:29,172 --> 00:20:32,552
就比把整套规则塞进一个巨大pront里

467
00:20:32,552 --> 00:20:36,352
一次性解决更准确更快和更便宜

468
00:20:36,352 --> 00:20:39,592
所以这笔账不只是和模型本身有关

469
00:20:39,592 --> 00:20:41,412
也和任务怎么拆

470
00:20:41,412 --> 00:20:43,312
软件怎么调用它有关

471
00:20:43,312 --> 00:20:46,492
那如果把这个思路放进一个完整的agent

472
00:20:46,492 --> 00:20:48,472
分工又会变成什么样呢

473
00:20:48,472 --> 00:20:49,712
讲到这里

474
00:20:49,712 --> 00:20:51,672
我觉得Jab最有意思的地方

475
00:20:51,672 --> 00:20:53,532
已经不是Jab本身了

476
00:20:53,532 --> 00:20:56,152
而是一个真正长期运行的agent

477
00:20:56,152 --> 00:20:59,732
到底应该把多少事情交给同一个大模型呢

478
00:20:59,732 --> 00:21:02,852
一个agent可能连续工作几十分钟

479
00:21:02,852 --> 00:21:04,112
甚至几个小时

480
00:21:04,112 --> 00:21:06,892
中间经历几十几百个决策点

481
00:21:06,892 --> 00:21:09,072
真正需要复杂推理的

482
00:21:09,072 --> 00:21:10,472
也许只有其中几步

483
00:21:10,472 --> 00:21:11,972
剩下大量的工作

484
00:21:11,972 --> 00:21:14,552
其实只是判断走哪条路

485
00:21:14,552 --> 00:21:15,612
调用哪个工具

486
00:21:15,612 --> 00:21:17,252
这个结果能不能接受

487
00:21:17,252 --> 00:21:18,952
需不需要再检查一次

488
00:21:18,952 --> 00:21:21,552
而Jav指向的是另一种架构

489
00:21:21,552 --> 00:21:23,372
真正开放复杂

490
00:21:23,372 --> 00:21:25,492
需要理解模糊目标

491
00:21:25,492 --> 00:21:28,332
长程规划和深度推理的问题

492
00:21:28,332 --> 00:21:29,972
仍然交给前沿模型

493
00:21:29,972 --> 00:21:32,172
如果是确定性的规则

494
00:21:32,172 --> 00:21:33,712
比如金额超过多少

495
00:21:33,712 --> 00:21:35,192
必须人工审批的

496
00:21:35,192 --> 00:21:36,552
就直接交给代码

497
00:21:36,552 --> 00:21:40,472
如果是大量高频窄而不断变化的判断

498
00:21:40,472 --> 00:21:43,132
就可以交给像Jav这种决策模型

499
00:21:43,132 --> 00:21:46,392
结果是不是满足某个明确标准

500
00:21:46,392 --> 00:21:48,032
可以再交给Verify

501
00:21:48,032 --> 00:21:50,992
需要长期保存的信息进入Memory

502
00:21:50,992 --> 00:21:53,632
需要真正改变外部世界的动作

503
00:21:53,632 --> 00:21:54,672
就交给Tools

504
00:21:54,672 --> 00:21:57,132
最后真正重要的

505
00:21:57,132 --> 00:21:59,092
可能不再是其中某一个模型

506
00:21:59,092 --> 00:22:00,412
而是外面的Harness

507
00:22:00,412 --> 00:22:03,992
因为Harness决定谁在什么时候被调用

508
00:22:03,992 --> 00:22:05,992
什么结果可以直接通过

509
00:22:05,992 --> 00:22:07,792
什么结果必须升级

510
00:22:07,792 --> 00:22:10,112
什么任务值得花几十倍的成本

511
00:22:10,112 --> 00:22:11,792
去唤醒最强的模型

512
00:22:11,792 --> 00:22:15,172
当软件真正需要的只是一个决定

513
00:22:15,172 --> 00:22:18,352
我们为什么一定要让AI先开口说话呢

514
00:22:18,352 --> 00:22:19,672
这里是All Insight

515
00:22:19,672 --> 00:22:20,332
感谢收看

516
00:22:20,332 --> 00:22:21,192
我们下期再见