WEBVTT

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

00:00:27.580 --> 00:00:28.980
简单来说

00:00:28.980 --> 00:00:31.900
今天我们已经习以为常的这件事

00:00:31.900 --> 00:00:34.020
就是你对AI说一句话

00:00:34.020 --> 00:00:35.860
它能够理解你想干什么

00:00:35.860 --> 00:00:38.120
然后按照你的要求回答

00:00:38.120 --> 00:00:40.180
它就是这个早期参与

00:00:40.180 --> 00:00:42.720
把这条路线做出来的人之一

00:00:42.720 --> 00:00:45.100
不过参与创造ChatGPT

00:00:45.100 --> 00:00:46.300
是它自己的表述

00:00:46.300 --> 00:00:48.220
并不是OpenAI给它的

00:00:48.220 --> 00:00:50.500
ChatGPT联合发明人头衔

00:00:50.500 --> 00:00:53.740
但是ChatGPT出现以后

00:00:53.740 --> 00:00:55.780
它反而开始怀疑一件事了

00:00:55.780 --> 00:00:58.680
就是模型已经越来越会说话了

00:00:58.680 --> 00:01:01.880
那为什么我们期待中的大规模自动化

00:01:01.880 --> 00:01:04.040
却没有以同样的速度发生呢

00:01:04.040 --> 00:01:05.800
于是过去两年

00:01:05.800 --> 00:01:08.520
阿尔梅达一直在隐身做另一件东西

00:01:08.520 --> 00:01:09.620
直到这几天

00:01:09.620 --> 00:01:11.900
他和自己的公司TypeSafe AI

00:01:11.900 --> 00:01:13.340
才把它公开出来

00:01:13.340 --> 00:01:15.100
这个模型叫Jeff

00:01:15.100 --> 00:01:16.380
你知道吗

00:01:16.380 --> 00:01:19.060
TypeSafe给出的数字非常夸张

00:01:19.060 --> 00:01:21.720
说它20到200倍更快

00:01:21.720 --> 00:01:23.620
40到400倍更便宜

00:01:23.620 --> 00:01:25.560
不过我看到这里的时候

00:01:25.560 --> 00:01:28.700
真正让我觉得有意思的还不是这些数字

00:01:28.700 --> 00:01:31.860
而是Jav做了一件非常反常识的事情

00:01:31.860 --> 00:01:33.720
就是他不会说话

00:01:33.720 --> 00:01:34.740
真的不会

00:01:34.740 --> 00:01:37.060
Jav他不跟你聊天

00:01:37.060 --> 00:01:37.920
不写文章

00:01:37.920 --> 00:01:39.820
也不生成自由文本

00:01:39.820 --> 00:01:40.960
你把一段对话

00:01:40.960 --> 00:01:42.500
一个agent的当前的状态

00:01:42.500 --> 00:01:44.420
或者一堆数据交给他

00:01:44.420 --> 00:01:45.260
然后问他

00:01:45.260 --> 00:01:46.680
这个请求安全吗

00:01:46.680 --> 00:01:48.960
下一步应该调用哪个工具呢

00:01:48.960 --> 00:01:50.820
这几个方案选哪一个呢

00:01:50.820 --> 00:01:51.900
这之后

00:01:51.900 --> 00:01:53.900
Jav不会先写一段分析

00:01:53.900 --> 00:01:56.240
也不需要慢慢吐出一串杰森

00:01:56.240 --> 00:01:57.980
他会直接给你决定

00:01:57.980 --> 00:02:00.540
以及他对这个决定有多大把握

00:02:00.540 --> 00:02:02.380
欢迎回到All Insight

00:02:02.380 --> 00:02:04.200
在继续今天的视频之前

00:02:04.200 --> 00:02:06.840
我想先感谢一直支持这个频道的朋友

00:02:06.840 --> 00:02:09.640
我知道还有不少观看我视频的朋友

00:02:09.640 --> 00:02:10.860
还没有订阅我的频道

00:02:10.860 --> 00:02:13.740
那如果你觉得我的内容对你有所帮助

00:02:13.740 --> 00:02:15.800
欢迎点赞分享和订阅

00:02:15.800 --> 00:02:17.480
也可以加入频道会员

00:02:17.480 --> 00:02:19.440
每个月一杯咖啡的钱

00:02:19.440 --> 00:02:20.960
不仅是对我的支持

00:02:20.960 --> 00:02:26.620
也会帮助我继续制作更多关于AI和未来技术方向的深度内容

00:02:26.620 --> 00:02:29.340
好的 接下来我们进入今天的主题

00:02:29.340 --> 00:02:33.260
这件事听起来好像只是少生成了一些文字

00:02:33.260 --> 00:02:35.320
但放到今天的agent里面

00:02:35.320 --> 00:02:38.080
你会发现问题其实没有那么简单

00:02:38.080 --> 00:02:42.600
现在一个agent每走一步可能都要做很多判断

00:02:42.600 --> 00:02:45.180
比如下一步该调用哪个工具

00:02:45.180 --> 00:02:47.260
这个结果能不能相信

00:02:47.260 --> 00:02:48.580
要不要继续

00:02:48.580 --> 00:02:50.680
需不需要升级到更强的模型

00:02:50.680 --> 00:02:53.600
很多时候我们真正需要的

00:02:53.600 --> 00:02:55.920
其实只是一个是或者不是

00:02:55.920 --> 00:02:57.400
ABC选哪个

00:02:57.400 --> 00:02:59.500
但今天最常见的做法

00:02:59.500 --> 00:03:02.460
是把整个上下文交给一个大语言模型

00:03:02.460 --> 00:03:05.700
让它先生成文字或者结构化输出

00:03:05.700 --> 00:03:08.500
然后程序再从这些输出里

00:03:08.500 --> 00:03:10.160
拿出最后那个决定

00:03:10.160 --> 00:03:13.980
所以阿尔梅达这次实际上是在问

00:03:13.980 --> 00:03:16.980
如果软件真正需要的只是一个决定

00:03:16.980 --> 00:03:19.980
那为什么一定要让AI先说一段话呢

00:03:19.980 --> 00:03:21.500
Jav发布以后

00:03:21.500 --> 00:03:25.140
X上很快出现了两种不同的声音

00:03:25.140 --> 00:03:26.760
第一种反应非常直接

00:03:26.760 --> 00:03:29.000
就是等等这不就是分类器吗

00:03:29.000 --> 00:03:31.660
独立AI研究者Alexis Gallagher就说

00:03:31.660 --> 00:03:33.260
他觉得Jav很酷

00:03:33.260 --> 00:03:36.140
但更有意思的是大家对Jav的反应

00:03:36.140 --> 00:03:39.320
因为这似乎说明很多人已经忘了

00:03:39.320 --> 00:03:42.420
锦编码器分类器已经存在很多年了

00:03:42.420 --> 00:03:43.900
而且一直很好用

00:03:43.900 --> 00:03:46.020
像Modern Bird这样的模型

00:03:46.020 --> 00:03:49.840
本来就可以快速和廉价的完成结构化判断

00:03:49.840 --> 00:03:51.540
Jav也许更好

00:03:51.540 --> 00:03:54.560
而且不需要针对每一个任务重新训练

00:03:54.560 --> 00:03:56.960
但这个类别本身并不新

00:03:56.960 --> 00:04:01.400
另一边XBOM的AI研究员Lan Butler马上反驳说

00:04:01.400 --> 00:04:04.000
问题恰恰就在不需要重新训练

00:04:04.000 --> 00:04:06.820
如果今天突然给你一个非常奇怪

00:04:06.820 --> 00:04:09.220
而且类别又特别多的决策任务

00:04:09.220 --> 00:04:11.060
你手里甚至还没有数据集

00:04:11.060 --> 00:04:13.380
那传统分类器怎么办

00:04:13.380 --> 00:04:16.900
而Jav的卖点就是直接用自然语言告诉他

00:04:16.900 --> 00:04:18.200
现在要判断什么

00:04:18.200 --> 00:04:19.840
更有意思的是

00:04:19.840 --> 00:04:21.500
已经有人不吵了

00:04:21.500 --> 00:04:24.460
他们直接把Jab塞进agent里面开始跑

00:04:24.460 --> 00:04:26.600
有人拿它做模型路由

00:04:26.600 --> 00:04:29.480
让Jab决定什么时候该用便宜模型

00:04:29.480 --> 00:04:31.620
什么时候升级到更强的模型

00:04:31.620 --> 00:04:34.860
还有人拿它做Computer Use的下一步决策

00:04:34.860 --> 00:04:36.780
还有一个叫Observed开发者

00:04:36.780 --> 00:04:40.060
测试了一整晚跑了500多次API

00:04:40.060 --> 00:04:42.240
总共才花了大约3美分

00:04:42.240 --> 00:04:44.640
一次同时多问20个问题

00:04:44.640 --> 00:04:47.340
延迟也只增加了47毫秒

00:04:47.340 --> 00:04:51.780
他还抓住了一次针对他自己agent的假审批注入

00:04:51.780 --> 00:04:54.860
然后他发现Jeff有一次打错了

00:04:54.860 --> 00:04:58.220
而Jeff给那个错误答案给出的信心是1.00

00:04:58.220 --> 00:04:59.920
这就有意思了

00:04:59.920 --> 00:05:03.160
一边是这不就是我们用了很多年的分类器吗

00:05:03.160 --> 00:05:08.180
而另一边却已经有人开始把他塞进agent的决策循环

00:05:08.180 --> 00:05:10.700
官方说他的概率经过较准

00:05:10.700 --> 00:05:13.380
但在真实测试里却已经出现了

00:05:13.380 --> 00:05:16.060
答错了但信心百分之百的情况

00:05:16.060 --> 00:05:20.020
所以这期视频我真正想弄清楚的

00:05:20.020 --> 00:05:22.360
不是Jav到底有没有快200倍

00:05:22.360 --> 00:05:25.740
而是说一个参与创造ChattGPT的人

00:05:25.740 --> 00:05:27.940
在模型越来越会说话之后

00:05:27.940 --> 00:05:29.760
为什么会花两年的时间

00:05:29.760 --> 00:05:31.960
重新做一个不会说话的AI呢

00:05:31.960 --> 00:05:35.220
以及他是不是碰到了今天A成的系统里

00:05:35.220 --> 00:05:36.680
一个更有意思的问题

00:05:36.680 --> 00:05:40.480
就是我们真的需要让大模型来做每一个决定吗

00:05:40.480 --> 00:05:43.400
那么一个不生成自由文本的AI

00:05:43.400 --> 00:05:45.240
到底是怎么工作的呢

00:05:45.240 --> 00:05:48.300
TypeSafe对Jav的描述其实很简洁

00:05:48.300 --> 00:05:49.980
翻译过来的意思就是

00:05:49.980 --> 00:05:51.580
输入可以很复杂

00:05:51.580 --> 00:05:54.580
但输出不再是一串自由生成的文字

00:05:54.580 --> 00:05:58.040
而是提前定义好类型的概率决策

00:05:58.040 --> 00:06:01.520
比如一个客服agent的正在处理退款请求

00:06:01.520 --> 00:06:03.960
你可以把完整的对话记录

00:06:03.960 --> 00:06:05.220
用户账户状态

00:06:05.220 --> 00:06:07.960
以及最近的付款记录一起交给Jav

00:06:07.960 --> 00:06:09.140
然后同时问他

00:06:09.140 --> 00:06:11.680
用户现在是不是在要求退款呢

00:06:11.680 --> 00:06:13.320
有没有欺诈风险呢

00:06:13.320 --> 00:06:14.760
需不需要转人工呢

00:06:14.760 --> 00:06:16.460
如果要继续处理

00:06:16.460 --> 00:06:18.620
下一步应该执行哪个动作呢

00:06:18.620 --> 00:06:22.660
当然普通大模型也能回答这些问题

00:06:22.660 --> 00:06:24.760
但它通常还是要生成

00:06:24.760 --> 00:06:27.140
哪怕最后输出的是JESN

00:06:27.140 --> 00:06:29.780
本质上也是一个Token接一个Token的

00:06:29.780 --> 00:06:31.320
把字符串写出来

00:06:31.320 --> 00:06:33.460
但JESN走的是另一条路

00:06:33.460 --> 00:06:36.260
他把这些问题直接变成了几个

00:06:36.260 --> 00:06:37.820
类型确定的决策

00:06:37.820 --> 00:06:40.360
而且可以一次并行回答

00:06:40.360 --> 00:06:43.020
TypeSafe目前把这种输出

00:06:43.020 --> 00:06:45.020
分成三种基本形式

00:06:45.020 --> 00:06:46.340
第一种叫Nual

00:06:46.340 --> 00:06:48.420
它处理是不是这一类的判断

00:06:48.420 --> 00:06:51.300
比如这个请求有没有越狱风险

00:06:51.300 --> 00:06:53.100
那么它返回的就不是一句

00:06:53.100 --> 00:06:53.980
我认为没有

00:06:53.980 --> 00:06:56.500
而是说这个判断对应的概率

00:06:56.500 --> 00:06:58.000
第二种叫Choice

00:06:58.000 --> 00:07:01.640
也就是从提前给定的选项里做选择

00:07:01.640 --> 00:07:04.060
比如一个Agent手里有八个工具

00:07:04.060 --> 00:07:05.800
现在应该调用哪一个呢

00:07:05.800 --> 00:07:08.400
Jive直接在这八个选项里做判断

00:07:08.400 --> 00:07:10.080
并给出相应的概率

00:07:10.080 --> 00:07:11.600
第三种叫Score

00:07:11.600 --> 00:07:13.580
用来处理打分和排序

00:07:13.580 --> 00:07:15.960
比如一个任务的优先级有多高

00:07:15.960 --> 00:07:18.260
或者一个结果有多值得信任

00:07:33.246 --> 00:07:35.546
JF在开始计算之前

00:07:35.546 --> 00:07:38.766
输出空间就已经被软件定义好了

00:07:38.766 --> 00:07:40.146
它可以判断

00:07:40.146 --> 00:07:43.046
但它不能临场发明一个新的答案

00:07:43.046 --> 00:07:45.126
这里还有一个很容易被忽略的区别

00:07:45.126 --> 00:07:49.126
就是这些判断不一定要一个接一个的做

00:07:49.126 --> 00:07:51.526
Type-Safe官方展示的Workflow

00:07:51.526 --> 00:07:54.406
本身就会把一个复杂的软件状态

00:07:54.406 --> 00:07:56.066
拆成很多独立的问题

00:07:56.066 --> 00:07:57.926
然后一次并行询问

00:07:57.926 --> 00:08:00.306
比如他们公开的客服工作流

00:08:00.306 --> 00:08:03.286
第一步就会同时读取用户意图

00:08:03.286 --> 00:08:07.406
情绪紧急程度以及欺诈风险等多个信号

00:08:07.406 --> 00:08:09.126
在后面的代码决定

00:08:09.126 --> 00:08:13.126
退款冻结银行卡转人工还是继续处理

00:08:13.126 --> 00:08:17.546
这时候我们再回头看TypeSafe给这种模型起的名字

00:08:17.546 --> 00:08:19.346
就比较容易理解了

00:08:19.346 --> 00:08:21.286
他们叫它System-1 Module

00:08:21.286 --> 00:08:26.246
这个名字来自丹尼尔·卡尼曼对System-1和System-2的区别

00:08:26.246 --> 00:08:30.646
他认为System-1负责快速和直觉式的判断

00:08:30.646 --> 00:08:33.946
System-2才负责缓慢和复杂的推理

00:08:33.946 --> 00:08:38.806
那Type-C想做的不是让Jeff取代所有大语言模型

00:08:38.806 --> 00:08:44.206
而是把软件系统里大量这种快速判断单独抽出来

00:08:44.206 --> 00:08:47.386
阿尔梅达后来把这个速度说得更直接

00:08:47.386 --> 00:08:50.726
他说他们把今天几条不同的训练路线

00:08:50.726 --> 00:08:52.906
看成是在解决不同的问题

00:08:52.906 --> 00:08:56.646
像RLVR就更适合可以验证答案的

00:08:56.646 --> 00:08:58.046
Resonings和Proves

00:08:58.046 --> 00:09:02.926
而他们希望RLCD去解决的是自动控制

00:09:02.926 --> 00:09:04.986
也就是让模型的决定

00:09:04.986 --> 00:09:07.766
真正能够被软件直接使用

00:09:07.766 --> 00:09:09.366
这也是为什么Type-Safe

00:09:09.366 --> 00:09:11.626
一直把Jeff的典型用途写成

00:09:11.626 --> 00:09:15.346
分类 路由 打分 提取和分支判断

00:09:15.346 --> 00:09:17.606
他们甚至用了一个狠形象的说法

00:09:17.606 --> 00:09:19.326
是聪明的一笔句

00:09:19.326 --> 00:09:21.146
听到这里

00:09:21.146 --> 00:09:23.506
Jav好像已经也没有那么神秘了

00:09:23.506 --> 00:09:26.666
他不是一个被砍掉聊天界面的GPT

00:09:26.666 --> 00:09:29.346
也不是为了写出更好的答案

00:09:29.346 --> 00:09:31.906
而是他想把做决定本身

00:09:31.906 --> 00:09:34.146
从语言生成里单独拆出来

00:09:34.146 --> 00:09:37.726
变成软件可以直接调语的一种智能原语

00:09:37.726 --> 00:09:41.406
但是这也就回到了开场那个质疑

00:09:41.406 --> 00:09:43.346
就是这不就是分类器吗

00:09:43.346 --> 00:09:45.906
以太坊基军会AI的负责人

00:09:45.906 --> 00:09:48.326
David Krapis的说法就更直接了

00:09:48.326 --> 00:09:52.006
他认为把Jav和通用ML放在一起比较

00:09:52.006 --> 00:09:53.306
很容易产生误导

00:09:53.306 --> 00:09:56.326
因为Jav根本不生成自由文本

00:09:56.326 --> 00:09:57.666
从功能上看

00:09:57.666 --> 00:10:00.066
它更接近一个非常聪明的工具

00:10:00.066 --> 00:10:01.306
或者一个分类器

00:10:01.306 --> 00:10:05.526
而不是GPT Cloud这种通用模型的直接竞争者

00:10:05.526 --> 00:10:07.346
有人继续往下拆

00:10:07.346 --> 00:10:10.466
Robert世文透客把Jav的几个卖点

00:10:10.466 --> 00:10:11.926
一条一条列了出来

00:10:11.926 --> 00:10:14.086
像是类型受限的输出

00:10:14.086 --> 00:10:16.546
我们已经可以用受限解码做

00:10:16.546 --> 00:10:19.026
概率可以从LogProps里面拿

00:10:19.026 --> 00:10:22.466
概率校准也早就有Temperature Scaling

00:10:22.466 --> 00:10:23.686
什么时候放行

00:10:23.686 --> 00:10:24.626
什么时候升级

00:10:24.626 --> 00:10:27.806
本来就可以在应用代表里面写Threathood

00:10:27.806 --> 00:10:31.066
所以他最后的评价其实很有意思

00:10:31.066 --> 00:10:33.566
他认为这些统计学上的零件

00:10:33.566 --> 00:10:36.166
没有哪一个是突然从天上掉下来的

00:10:36.166 --> 00:10:41.306
真正可能不同的是TypeSafe把校准放进了训练目标

00:10:41.306 --> 00:10:44.966
然后让API从一开始返回的就是Decision

00:10:44.966 --> 00:10:48.186
而不是一段等待程序再次解析的文字

00:10:48.186 --> 00:10:49.146
换句话说

00:10:49.146 --> 00:10:52.306
就不是发明了一堆从来没有存在过的零件

00:10:52.306 --> 00:10:54.546
而是少兵了几层东西

00:10:54.546 --> 00:10:56.746
这时候Jav就不是分类器吗

00:10:56.746 --> 00:10:59.146
这个问题就开始变得没那么简单了

00:10:59.146 --> 00:11:02.006
因为TypeSafe真正想挑战的

00:11:02.006 --> 00:11:04.866
并不是传统分类器做不到的分类

00:11:04.866 --> 00:11:06.426
而是它的使用方式

00:11:06.426 --> 00:11:09.766
假设你今天做一个金融agent

00:11:09.766 --> 00:11:11.366
你只需要判断的是

00:11:11.366 --> 00:11:13.626
这笔交易有没有欺诈风险

00:11:13.626 --> 00:11:17.166
那你当然可以收集数据标注样本

00:11:17.166 --> 00:11:18.726
训练一个专门的分类器

00:11:18.726 --> 00:11:20.486
如果业务一直不变

00:11:20.486 --> 00:11:23.226
这就可能比调用GF更便宜更快

00:11:23.226 --> 00:11:24.366
甚至更可靠

00:11:24.366 --> 00:11:28.206
但现实里的agent很少永远只问同一个问题

00:11:28.206 --> 00:11:30.346
今天你要判断的是欺诈

00:11:30.346 --> 00:11:33.086
明天可能增加是否需要人工复合

00:11:33.086 --> 00:11:34.826
后天可能又增加

00:11:34.826 --> 00:11:36.906
应该交给哪个风险团队

00:11:36.906 --> 00:11:38.026
换一个产品

00:11:38.026 --> 00:11:42.006
问题标签和业务规则可能全部都变了

00:11:42.006 --> 00:11:43.866
如果每增加一种判断

00:11:43.866 --> 00:11:45.486
都要重新积累数据

00:11:45.486 --> 00:11:47.046
训练和部署一个模型

00:11:47.046 --> 00:11:49.206
那传统分类器的成本

00:11:49.206 --> 00:11:51.066
就开始从推理阶段

00:11:51.066 --> 00:11:53.526
转移到了开发和维护阶段

00:11:53.526 --> 00:11:55.046
而Jeff想做的是把

00:11:55.046 --> 00:11:58.566
大语言模型最有价值的一部分能力保留下来

00:11:58.566 --> 00:12:01.306
就是你可以直接用自然语言告诉模型

00:12:01.306 --> 00:12:02.866
现在要判断什么

00:12:02.866 --> 00:12:06.546
那我们目前还没有看到

00:12:06.546 --> 00:12:08.926
Jeff和一个认真微调过的

00:12:08.926 --> 00:12:09.786
Martin Burrton

00:12:09.786 --> 00:12:11.826
专门的小型分类器

00:12:11.826 --> 00:12:15.086
或者一个使用受限解码的小语言模型

00:12:15.086 --> 00:12:19.026
在同样任务同样数据同样准确率要求下

00:12:19.026 --> 00:12:21.586
做一次真正公平的正面对比

00:12:21.586 --> 00:12:24.026
TypeSafe真正需要证明的是

00:12:24.026 --> 00:12:25.746
当任务不断变化

00:12:25.746 --> 00:12:28.766
而你又不想每次重新训练一个模型的时候

00:12:28.766 --> 00:12:32.466
Jab能不能同时保住分类器的速度和成本

00:12:32.466 --> 00:12:35.886
又同时保住大模型那种拿自然语言

00:12:35.886 --> 00:12:38.186
就能直接定义新任务的灵活性

00:12:38.186 --> 00:12:40.126
而这还只是第一层

00:12:40.126 --> 00:12:42.826
因为Type Save对Jav最大胆的主张

00:12:42.826 --> 00:12:45.006
其实不是快也不是便宜

00:12:45.006 --> 00:12:47.166
甚至不是自然语言可编程

00:12:47.166 --> 00:12:48.606
而是他认为

00:12:48.606 --> 00:12:50.766
Jav不只会给你一个决定

00:12:50.766 --> 00:12:54.486
他还知道自己这个决定到底有多可靠

00:12:54.486 --> 00:12:56.666
这就进入了整个Jav的故事里

00:12:56.666 --> 00:12:59.126
最关键也是目前最神秘的一块

00:12:59.126 --> 00:13:00.206
RLCD

00:13:00.206 --> 00:13:04.146
前面讲到Jav会给每一个决策附上概率

00:13:04.146 --> 00:13:05.926
但这里真正重要的

00:13:05.926 --> 00:13:09.526
不是他能不能输出一个0.73或者0.91

00:13:09.526 --> 00:13:13.126
而是说这些数字到底有没有统计意义

00:13:13.126 --> 00:13:15.606
这就是RLCD想解决的问题

00:13:15.606 --> 00:13:19.306
它的全称是校准决策强化学习

00:13:19.306 --> 00:13:20.286
所谓校准

00:13:20.286 --> 00:13:22.806
我们可以先用一个很简单的例子来理解

00:13:22.806 --> 00:13:26.446
就是如果一个模型做了很多次判断

00:13:26.446 --> 00:13:30.806
我们把它所有认为有70%把握的判断放在一起

00:13:30.806 --> 00:13:33.046
那么一个校准的好的模型

00:13:33.046 --> 00:13:36.766
长期来看应该有大约70%是正确的

00:13:36.766 --> 00:13:39.806
他说90%就应该接近90%

00:13:39.806 --> 00:13:42.406
说50%就真的意味着

00:13:42.406 --> 00:13:44.866
这件事差不多只有一半的把握

00:13:44.866 --> 00:13:47.246
这和准确率其实是两回事

00:13:47.246 --> 00:13:50.846
一个模型完全可能总体准确率很高

00:13:50.846 --> 00:13:53.406
但他根本不知道自己什么时候会错

00:13:53.406 --> 00:13:57.306
而另一个模型也许平均准确率没有高出多少

00:13:57.306 --> 00:13:59.306
但他在容易出错的时候

00:13:59.306 --> 00:14:01.486
真的会把自己的概率降下来

00:14:01.486 --> 00:14:03.406
对于聊天机器人来说

00:14:03.406 --> 00:14:05.666
这个区别可能没有那么明显

00:14:05.666 --> 00:14:07.206
但对于agent来说

00:14:07.206 --> 00:14:08.966
这就直接决定了一件事

00:14:08.966 --> 00:14:12.526
就是这个概率能不能拿来控制系统

00:14:12.526 --> 00:14:14.266
比如一个agent正在决定

00:14:14.266 --> 00:14:16.266
要不要自动批准退款

00:14:16.266 --> 00:14:18.106
债务判断可以批准

00:14:18.106 --> 00:14:20.066
概率99.8%

00:14:20.066 --> 00:14:22.406
如果经过大量测试之后

00:14:22.406 --> 00:14:25.666
你真的知道这种99.8%值得性

00:14:25.666 --> 00:14:28.346
那么harness就可以设置一个预值

00:14:28.346 --> 00:14:30.506
超过这个概率自动执行

00:14:30.506 --> 00:14:32.786
但如果只有70%

00:14:32.786 --> 00:14:35.166
就升级给更强更贵的模型

00:14:35.166 --> 00:14:38.506
如果再低一点就交给人工或者verify

00:14:38.506 --> 00:14:43.066
这个时候CoundEfence就不再是给人看的一个装饰数字

00:14:43.066 --> 00:14:46.646
它变成了Agent的内部的一种控制信号

00:14:46.646 --> 00:14:48.566
就是什么时候继续

00:14:48.566 --> 00:14:49.606
什么时候升级

00:14:49.606 --> 00:14:50.766
什么时候验证

00:14:50.766 --> 00:14:52.066
什么时候停下来

00:14:52.066 --> 00:14:55.106
前面那个满分信心却答错的例子

00:14:55.106 --> 00:14:56.706
追问的也正是这件事

00:14:56.706 --> 00:14:59.866
就是这些概率究竟有多可信呢

00:14:59.866 --> 00:15:03.406
而RLCD真正生成改变的是另一件事

00:15:03.406 --> 00:15:05.666
就是从训练阶段开始

00:15:05.666 --> 00:15:08.966
就让模型学习一个决定应该有多确定

00:15:08.966 --> 00:15:12.446
让概率本身也成为训练目标的一部分

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

00:15:23.892 --> 00:15:28.552
所以RLCD是否真的比现有校准方法更好

00:15:28.552 --> 00:15:30.952
这一部分还要等更多的证据

00:15:30.952 --> 00:15:33.752
这里也刚好可以解释TypeSafe另一个

00:15:33.752 --> 00:15:35.472
很容易让人误解的说法

00:15:35.472 --> 00:15:38.212
就是Jav不能产生幻觉

00:15:38.212 --> 00:15:42.852
如果你只允许Jav在批准和拒绝之间选择

00:15:42.852 --> 00:15:45.252
他确实不可能突然回答

00:15:45.252 --> 00:15:48.332
也许也不会捏造第三个不存在的函数

00:15:48.332 --> 00:15:51.012
更不会生成一段格式错误程序

00:15:51.012 --> 00:15:52.572
根本解析不了的Jason

00:15:52.572 --> 00:15:55.472
它的输出空间在计算之前

00:15:55.472 --> 00:15:58.072
就已经被系统类型限制好了

00:15:58.072 --> 00:16:01.132
但是它完全可能选择批准

00:16:01.132 --> 00:16:03.252
而正确答案其实是拒绝

00:16:03.252 --> 00:16:05.012
所以更准确的说

00:16:05.012 --> 00:16:07.572
Jav解决的是一种非常具体的幻觉

00:16:07.572 --> 00:16:09.892
它不会生成类型之外的答案

00:16:09.892 --> 00:16:13.252
但仍然可能在合法答案里面选错

00:16:13.252 --> 00:16:14.872
不过呢

00:16:14.872 --> 00:16:18.412
真正决定Jav能不能进入高风险自动化流程的

00:16:18.412 --> 00:16:19.672
还是后一个问题

00:16:19.672 --> 00:16:21.292
就是它选错的时候

00:16:21.292 --> 00:16:22.812
自己到底知不知道

00:16:22.812 --> 00:16:24.652
这也是为什么我觉得

00:16:24.652 --> 00:16:28.792
RLCD反而比Jav那个200倍更快的数字

00:16:28.792 --> 00:16:29.632
更值得关注

00:16:29.632 --> 00:16:32.572
如果一个模型只是快而且便宜

00:16:32.572 --> 00:16:35.232
我们其实已经有很多办法可以做到了

00:16:35.232 --> 00:16:39.272
但如果它能在保持这种速度和成本的同时

00:16:39.272 --> 00:16:43.612
给软件提供一个真正可信的不确定性信号

00:16:43.612 --> 00:16:46.552
那它在A层里面的位置就完全不一样了

00:16:46.552 --> 00:16:49.332
当然接下来还有一个跟现实的问题

00:16:49.332 --> 00:16:53.932
就是这些概率决策究竟能省下多少时间和成本呢

00:16:53.932 --> 00:16:56.272
现在我们终于可以回到

00:16:56.272 --> 00:16:58.992
JF发布时最新眼球的那组数字

00:16:58.992 --> 00:17:01.152
20到200倍更快

00:17:01.152 --> 00:17:03.492
40到400倍更便宜

00:17:03.492 --> 00:17:06.532
TypeSafe自己公布的Workflow Benchmark里面

00:17:06.532 --> 00:17:10.312
最高端的数字达到了193.6倍更快

00:17:10.312 --> 00:17:13.032
444.6倍更便宜

00:17:13.032 --> 00:17:15.452
这个数字第一眼看起来很离谱

00:17:15.452 --> 00:17:17.832
但离着JF前面的设计之后

00:17:17.832 --> 00:17:19.972
你会发现它其实并不神秘

00:17:19.972 --> 00:17:23.372
因为Jav和普通LM做计算的方式

00:17:23.372 --> 00:17:25.072
从一开始就不一样

00:17:25.072 --> 00:17:28.332
假设一个agent现在需要做20个判断

00:17:28.332 --> 00:17:30.652
比如用户是不是在退款

00:17:30.652 --> 00:17:32.112
有没有欺诈风险

00:17:32.112 --> 00:17:33.532
需不需要人工介入

00:17:33.532 --> 00:17:35.032
需要调用哪个工具

00:17:35.032 --> 00:17:37.252
结果要不要再验证一次

00:17:37.252 --> 00:17:40.372
阿尔梅达回应过一个很直接的问题

00:17:40.372 --> 00:17:43.072
就是为什么不干脆用受限解码呢

00:17:43.072 --> 00:17:44.312
他的回答是

00:17:44.312 --> 00:17:47.072
这层约束仍然叠在LM上

00:17:47.072 --> 00:17:49.332
字符串生成的开销还在

00:17:49.332 --> 00:17:51.592
他还提出了一更尖锐的判断

00:17:51.592 --> 00:17:54.172
就是模型本来就拿不准的时候

00:17:54.172 --> 00:17:56.552
再去限制他能选哪些输出

00:17:56.552 --> 00:17:58.152
反而会让模型变笨

00:17:58.152 --> 00:18:01.332
债务直接省掉了字符串生成这一步

00:18:01.332 --> 00:18:04.532
他不需要把决定翻译成一段语言

00:18:04.532 --> 00:18:07.532
再让软件把语言重新翻译成决定

00:18:07.532 --> 00:18:10.552
他的输出空间已经提前确定

00:18:10.552 --> 00:18:14.372
而且多个问题可以在同一次询问里并行计算

00:18:14.372 --> 00:18:16.872
TypeSafe公布的端到端延迟

00:18:16.872 --> 00:18:19.052
大约是70到500毫秒

00:18:19.052 --> 00:18:21.952
输入价格是每百万Token4.2美分

00:18:21.952 --> 00:18:24.032
输出则没有单独计费

00:18:24.032 --> 00:18:26.672
所以从物理账上看

00:18:26.672 --> 00:18:29.812
Jav比大元模型快很多便宜很多

00:18:29.812 --> 00:18:31.372
是完全说得通的

00:18:31.372 --> 00:18:33.952
但我们真正需要问的是另一件事

00:18:33.952 --> 00:18:37.292
就是他们比较的是不是同一种工作呢

00:18:37.292 --> 00:18:39.672
TypeSafe的Workflow Benchmark

00:18:39.672 --> 00:18:42.032
不是让Jav和GPT Cloud

00:18:42.032 --> 00:18:43.672
各自写一篇文章

00:18:43.672 --> 00:18:46.592
也不是让他们解决一道开放式的数学题

00:18:46.592 --> 00:18:51.372
而是专门选择软件自动化里面的System-1任务

00:18:51.372 --> 00:18:54.472
对照的是同样接入这套工作流的

00:18:54.472 --> 00:18:57.612
按要求返回结果化结果的通用LM

00:18:57.612 --> 00:18:59.252
比如处理一张发票

00:18:59.252 --> 00:19:01.832
系统真正需要的是这几个决定

00:19:01.832 --> 00:19:06.112
付款、赞款、要求补文件、送人工审批

00:19:06.112 --> 00:19:07.212
还是怀疑欺诈

00:19:07.212 --> 00:19:10.672
又比如一个客服agent完成了一轮任务

00:19:10.672 --> 00:19:15.172
系统要判断的是自动关闭、人工复合、优化复合

00:19:15.172 --> 00:19:17.612
还是直接通知值班人员

00:19:17.612 --> 00:19:22.272
这些任务天然就非常适合被拆成很多窄判断

00:19:22.272 --> 00:19:23.992
然后再用代码组合

00:19:23.992 --> 00:19:26.312
而这正好是Jav的主场

00:19:26.312 --> 00:19:30.132
TypeSave甚至在自己的发布文章里主动承认

00:19:30.132 --> 00:19:32.412
他们展示的side-by-side demo

00:19:32.412 --> 00:19:35.112
使用了比较短和比较密集的输入

00:19:35.112 --> 00:19:37.192
这会让Jav看起来更有优势

00:19:37.192 --> 00:19:40.592
193.6倍和444.6倍

00:19:40.592 --> 00:19:43.172
来自他们设计的工作流程评估

00:19:43.172 --> 00:19:46.472
他们认为这应该处在现实收益的高端

00:19:46.472 --> 00:19:51.192
而且这些workflow是公司自己模型能力团队的人做的

00:19:51.192 --> 00:19:53.012
所以他们也明确写了一句

00:19:53.012 --> 00:19:54.632
可能存在偏见

00:19:54.632 --> 00:19:56.432
这一点反而很重要

00:19:56.432 --> 00:20:00.552
因为他告诉我们200倍不是一个模型智力倍率

00:20:00.552 --> 00:20:01.992
他真正表达的是

00:20:01.992 --> 00:20:04.692
帮任务本来就是大量窄决策

00:20:04.692 --> 00:20:08.932
而你还让一个通用生成模型不断生成字符串的时候

00:20:08.932 --> 00:20:12.592
你可能正在为很多根本不需要的能力付钱

00:20:12.592 --> 00:20:14.952
TypeSafe的工作流程评估

00:20:14.952 --> 00:20:18.012
其实还暴露了另外一个很有意思的结果

00:20:18.012 --> 00:20:21.552
就是同一个模型把任务拆成workflow

00:20:21.552 --> 00:20:23.912
让代码负责确定性的规则

00:20:23.912 --> 00:20:27.612
让模型只负责那些真正需要判断的部分的话

00:20:27.612 --> 00:20:29.172
那么在这些测试里

00:20:29.172 --> 00:20:32.552
就比把整套规则塞进一个巨大pront里

00:20:32.552 --> 00:20:36.352
一次性解决更准确更快和更便宜

00:20:36.352 --> 00:20:39.592
所以这笔账不只是和模型本身有关

00:20:39.592 --> 00:20:41.412
也和任务怎么拆

00:20:41.412 --> 00:20:43.312
软件怎么调用它有关

00:20:43.312 --> 00:20:46.492
那如果把这个思路放进一个完整的agent

00:20:46.492 --> 00:20:48.472
分工又会变成什么样呢

00:20:48.472 --> 00:20:49.712
讲到这里

00:20:49.712 --> 00:20:51.672
我觉得Jab最有意思的地方

00:20:51.672 --> 00:20:53.532
已经不是Jab本身了

00:20:53.532 --> 00:20:56.152
而是一个真正长期运行的agent

00:20:56.152 --> 00:20:59.732
到底应该把多少事情交给同一个大模型呢

00:20:59.732 --> 00:21:02.852
一个agent可能连续工作几十分钟

00:21:02.852 --> 00:21:04.112
甚至几个小时

00:21:04.112 --> 00:21:06.892
中间经历几十几百个决策点

00:21:06.892 --> 00:21:09.072
真正需要复杂推理的

00:21:09.072 --> 00:21:10.472
也许只有其中几步

00:21:10.472 --> 00:21:11.972
剩下大量的工作

00:21:11.972 --> 00:21:14.552
其实只是判断走哪条路

00:21:14.552 --> 00:21:15.612
调用哪个工具

00:21:15.612 --> 00:21:17.252
这个结果能不能接受

00:21:17.252 --> 00:21:18.952
需不需要再检查一次

00:21:18.952 --> 00:21:21.552
而Jav指向的是另一种架构

00:21:21.552 --> 00:21:23.372
真正开放复杂

00:21:23.372 --> 00:21:25.492
需要理解模糊目标

00:21:25.492 --> 00:21:28.332
长程规划和深度推理的问题

00:21:28.332 --> 00:21:29.972
仍然交给前沿模型

00:21:29.972 --> 00:21:32.172
如果是确定性的规则

00:21:32.172 --> 00:21:33.712
比如金额超过多少

00:21:33.712 --> 00:21:35.192
必须人工审批的

00:21:35.192 --> 00:21:36.552
就直接交给代码

00:21:36.552 --> 00:21:40.472
如果是大量高频窄而不断变化的判断

00:21:40.472 --> 00:21:43.132
就可以交给像Jav这种决策模型

00:21:43.132 --> 00:21:46.392
结果是不是满足某个明确标准

00:21:46.392 --> 00:21:48.032
可以再交给Verify

00:21:48.032 --> 00:21:50.992
需要长期保存的信息进入Memory

00:21:50.992 --> 00:21:53.632
需要真正改变外部世界的动作

00:21:53.632 --> 00:21:54.672
就交给Tools

00:21:54.672 --> 00:21:57.132
最后真正重要的

00:21:57.132 --> 00:21:59.092
可能不再是其中某一个模型

00:21:59.092 --> 00:22:00.412
而是外面的Harness

00:22:00.412 --> 00:22:03.992
因为Harness决定谁在什么时候被调用

00:22:03.992 --> 00:22:05.992
什么结果可以直接通过

00:22:05.992 --> 00:22:07.792
什么结果必须升级

00:22:07.792 --> 00:22:10.112
什么任务值得花几十倍的成本

00:22:10.112 --> 00:22:11.792
去唤醒最强的模型

00:22:11.792 --> 00:22:15.172
当软件真正需要的只是一个决定

00:22:15.172 --> 00:22:18.352
我们为什么一定要让AI先开口说话呢

00:22:18.352 --> 00:22:19.672
这里是All Insight

00:22:19.672 --> 00:22:20.332
感谢收看

00:22:20.332 --> 00:22:21.192
我们下期再见