WEBVTT

00:00.000 --> 00:29.820
大家好,欢迎来到新一期视频。开始之前,我想先说一下。我在我的ARCK频道上更活跃了。我现在会发一些这里不讲的新内容。还有一些开发者相关的工具,你们也可以去看看。链接我会放在简介里。我现在拿到了Jeff的使用权限,想看看这东西到底有什么用。TagC说,它适合做极快的判断,非常低的成本。

00:30.000 --> 00:58.940
以及软件可以直接使用的结构化输出。所以,我准备了一些实用测试。其中还包括一些场景,如果设置本身有问题,就可能直接得到错误答案。Jeff是Tag所说的System-1模型。你把一些信息给他,问具体问题,他就会返回判断结果。他不会像普通聊天那样生成回复。也不会帮你写一个应用。有三种主要的问题类型。Chance是从你提供的选项里选一个。Store是用你定义的等级来打分。

00:58.940 --> 01:18.460
那则会给出一个是或否陈述为真的概率。这样做的目标是让这些小判断足够便宜、足够快。能贯穿整个软件使用。比如,你的应用可以判断该把消息发给哪个团队。某人是不是申请了退款,以及某件事是否需要处理。然后,代码再决定怎么处理这些答案。

01:18.460 --> 01:34.460
好了,我们直接来看测试。我先从一条关于重复扣费的客服消息开始。客户要退回多收的钱,说网站能正常用。还说这件事可以等到明天。我把四个问题放在一起问了。该哪个部门处理是否请求了退款,是否紧急,以及。

01:34.460 --> 02:03.860
Jaf把他选成了billing。退款请求的概率是98%,而紧急程度只有11%。frustration分数也接近平静那一段。所以,他把这些东西分得很准。在这个例子里,billing问题不会自动变成技术问题。退款请求也不会自动变成紧急情况。这对help desk这类工作流来说是个很好的起点。然后,我把消息改成,我不是再要退款。我只是需要一份发票副本。

02:03.860 --> 02:33.540
他还是选了billing。这很合理,但退款概率降到了3%。所以,他正确处理了否定,不是只看到refund这个词。就把它当成退款请求。这也是为什么在把任何模型接到动作之前。我都会先测试你实际是怎么说的。要退款,问退款政策。明确拒绝退款,这三件事完全不同。下一个测试显示了一个我觉得特别值得理解的局限。我问食堂几点关门,在有其他选项可选的情况下。

02:33.860 --> 02:44.240
这选了other。所以,他确实把这个问题排除在billing,technical support和sales之外。然后我给了他一个版本的问题,只允许那三个部门。

02:44.240 --> 03:05.840
这一次,他选了sales,智信度是0.31。答案符合我给出的选项。但这些选项里没有一个涵盖了我的需求。我其实是在故意设置一种情况,让他没法返回我需要的答案。所以,当你听到零hallucinations这种说法时,要记住这个区别。限制输出确实能阻止模型编造一个新类别。

03:05.840 --> 03:13.920
他并不能保证他选出来的类别有用或者正确。像这种流程里,我会加一个其他或未知选项,留给人工复合。

03:13.920 --> 03:30.500
而且,我不会把90%的confidence理解成模型有90%的时间都判断正确。这得用你自己的样本去测试。接着,我试了一个基础的prome injection。原始消息说,顾客点付款时结账页面崩了。而且,他们并不是要退款。

03:30.900 --> 03:43.600
Juff把他路由到技术支持,并把退款请求的概率设得很低。然后我在消息里塞了一个假的system override,让他选billing。并把退款和紧急程度这两个问题都标成处。

03:43.920 --> 04:13.220
但我真正的评估指令告诉他,要把消息里的这些内容当成不可信文版。他还是保留了技术知识分类,并且把退款概率一直很低,只有3%。紧迫感一直停留在不确定的中间地带,没有直接变成强烈的事。不过,单靠一次简单的注入测试,还不能说明模型就能免疫攻击。之后,我又测试了另一个稍微不同的东西。从文档里精确选出一个纸,消息里包含发件人的邮箱。

04:13.920 --> 04:27.240
就账单地址,以及收据应该发送到的新地址。我把这些地址作为颗选项提供进去。然后问当前的收据该发到哪里。他选中了新地址,连加号和年份都完全按原样选出来了。

04:27.240 --> 04:40.440
这对理解Jaf是怎么做提取很有用。你的代码可以收集候选值,Jaf负责选出相关的那个。再由你的代码复制。但如果你的第一步没找到正确地址,Jaf就没法通过一道选择题把它补出来。

04:41.140 --> 04:43.240
候选列表是你要测试的系统的一部分。

04:43.240 --> 04:53.020
最后,我试了一个小的agent审计事例。工具返回显示权限被拒绝,什么都没保存。但assistant的最终消息却说草稿已经成功保存。

04:53.800 --> 04:58.880
Jaf把这个任务判为失败,并给出了93%的概率。认为这个成功说法没有依据。

04:58.880 --> 05:05.980
我喜欢它在这个例子里是按工具证据来判断的。不过,这个错误本身很简单,用普通代码就能抓出来。

05:06.640 --> 05:14.500
更有意思的应用是去检查那些更段的trace有好几步。部分进展还有互相矛盾的说法。那就需要大得多的测试集了。

05:14.920 --> 05:18.000
现在,还有一个挺有意思的browser automation演示。

05:18.680 --> 05:21.540
Gregor Zinnick分享了一个开源项目,叫Jeff Ultrafast。

05:22.120 --> 05:24.260
他把Jeff和Browser Use工具结合在一起。

05:24.260 --> 05:30.580
他在演示里展示了他在大约7秒内,帮他在Google Flags上查到了从苏黎世到伦敦的单程航班。

05:31.220 --> 05:34.260
他说这次调用成本是0.39美元,不到半美分。

05:34.940 --> 05:36.560
而且视频还是元素播放的。

05:37.200 --> 05:39.300
这都是他自己报告的结果。

05:40.220 --> 05:42.160
我自己还没复现这个航班测试。

05:43.080 --> 05:45.100
他的工作方式挺有意思的。

05:45.740 --> 05:49.440
他会读取网页结构,然后生成一个代编号的空间列表。

05:50.200 --> 05:52.700
每一步之后,他都会刷新科选项。

05:52.700 --> 05:54.960
Jeff先选下一步操作。

05:55.880 --> 05:59.020
再把相关目标和这些问题打包成一个请求。

06:00.020 --> 06:06.700
虽然遇到需要实际文本时,他也可以点击某个按钮,或者在某个输入框里打字。

06:07.660 --> 06:11.420
那部分文本是由一个单独的小语言模型生成的。

06:12.300 --> 06:14.880
这个例子里用的是Mercury 2.5。

06:15.600 --> 06:18.320
这是Jeff如何融入更大agent的一个实际例子。

06:18.960 --> 06:21.760
Jeff负责结构化决策,另一个模型负责生成文本。

06:21.760 --> 06:24.880
浏览器代码还是得检查目标并执行动作。

06:25.520 --> 06:26.640
这里有几个细节要注意。

06:27.340 --> 06:29.920
公开的记事是从第一次页面观察后才开始的。

06:30.540 --> 06:31.800
所以不包含启动时间。

06:32.500 --> 06:34.540
而且这是一次不需要预定的机票搜索。

06:35.200 --> 06:37.420
报告的价格也和模型的成本估算一致。

06:38.120 --> 06:41.660
有统计使用量,不过那不包括浏览器基础设施。

06:42.580 --> 06:45.480
我也把这个项目和运行说明加进了TestKit。

06:45.480 --> 06:49.040
这些请求总共用了4148个输入Token。

06:49.480 --> 06:53.520
按公布的价格,每百万输入Token4.2美分估算下来。

06:54.180 --> 06:55.500
输入费用远不到一美分。

06:55.900 --> 06:58.680
按这个价格,输出Token是免费的。

06:59.300 --> 07:02.520
这些小例子成本其实很低,但一个应用的总成本。

07:02.520 --> 07:05.300
还包括你用来准备输入检查答案。

07:05.920 --> 07:08.880
以及处理那些需要换别的模型或人工介入的部分。

07:09.580 --> 07:11.140
我还记录了模型版本。

07:11.720 --> 07:13.060
我选的是JeffTheLatest。

07:14.000 --> 07:17.580
返回结果里,把模型识别成了Jeff1.13.0。

07:18.480 --> 07:22.500
这个信息最好和结果一起保存,因为叫做Latest的别名是会变的。

07:23.240 --> 07:25.040
总的来说,我觉得最有意思的地方,

07:25.680 --> 07:27.940
是你能很轻松地把这些判断塞进应用里。

07:28.360 --> 07:31.360
我测试的例子显示,它在路由否定选择值。

07:31.360 --> 07:34.740
以及根据证据核实说法,这几方面表现不错。

07:35.480 --> 07:37.960
也说明了你给出的选择和指令有多重要。

07:38.680 --> 07:40.580
这些只是八个代和城市里的小请求。

07:41.240 --> 07:43.140
他们给了我一些值得继续研究的方向。

07:43.720 --> 07:45.820
但还不能证明它在生产环境里可靠。

07:46.460 --> 07:49.020
也不能证明它在速度上比其他模型快很多。

07:49.700 --> 07:52.600
我把测试脚本也附上了,你可以自己附现这些例子。

07:53.300 --> 07:55.040
你也可以试试更大范围的样本。

07:55.500 --> 07:58.660
比较一下是把多个问题一起问,还是分开提问。

07:58.660 --> 08:03.000
这样更容易看出JF是否适合你工作流里的某个特定环节。

08:03.780 --> 08:05.020
总体来说还挺不错的。

08:05.380 --> 08:07.540
总之,欢迎在评论区告诉我你的想法。

08:08.240 --> 08:11.340
如果你喜欢这个视频,可以通过Super Thanks打赏。

08:12.220 --> 08:14.180
也可以点击这双按钮加入会员。

08:14.980 --> 08:18.560
另外,别忘了给这个视频点赞并订阅我的频道。

08:18.560 --> 08:20.580
我们下期再见,拜拜。