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

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

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

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

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

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

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

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

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

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

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

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

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

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

15
00:04:41,140 --> 00:04:43,240
候选列表是你要测试的系统的一部分。

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

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

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

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

20
00:05:14,920 --> 00:05:18,000
现在,还有一个挺有意思的browser automation演示。

21
00:05:18,680 --> 00:05:21,540
Gregor Zinnick分享了一个开源项目,叫Jeff Ultrafast。

22
00:05:22,120 --> 00:05:24,260
他把Jeff和Browser Use工具结合在一起。

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

24
00:05:31,220 --> 00:05:34,260
他说这次调用成本是0.39美元,不到半美分。

25
00:05:34,940 --> 00:05:36,560
而且视频还是元素播放的。

26
00:05:37,200 --> 00:05:39,300
这都是他自己报告的结果。

27
00:05:40,220 --> 00:05:42,160
我自己还没复现这个航班测试。

28
00:05:43,080 --> 00:05:45,100
他的工作方式挺有意思的。

29
00:05:45,740 --> 00:05:49,440
他会读取网页结构,然后生成一个代编号的空间列表。

30
00:05:50,200 --> 00:05:52,700
每一步之后,他都会刷新科选项。

31
00:05:52,700 --> 00:05:54,960
Jeff先选下一步操作。

32
00:05:55,880 --> 00:05:59,020
再把相关目标和这些问题打包成一个请求。

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

34
00:06:07,660 --> 00:06:11,420
那部分文本是由一个单独的小语言模型生成的。

35
00:06:12,300 --> 00:06:14,880
这个例子里用的是Mercury 2.5。

36
00:06:15,600 --> 00:06:18,320
这是Jeff如何融入更大agent的一个实际例子。

37
00:06:18,960 --> 00:06:21,760
Jeff负责结构化决策,另一个模型负责生成文本。

38
00:06:21,760 --> 00:06:24,880
浏览器代码还是得检查目标并执行动作。

39
00:06:25,520 --> 00:06:26,640
这里有几个细节要注意。

40
00:06:27,340 --> 00:06:29,920
公开的记事是从第一次页面观察后才开始的。

41
00:06:30,540 --> 00:06:31,800
所以不包含启动时间。

42
00:06:32,500 --> 00:06:34,540
而且这是一次不需要预定的机票搜索。

43
00:06:35,200 --> 00:06:37,420
报告的价格也和模型的成本估算一致。

44
00:06:38,120 --> 00:06:41,660
有统计使用量,不过那不包括浏览器基础设施。

45
00:06:42,580 --> 00:06:45,480
我也把这个项目和运行说明加进了TestKit。

46
00:06:45,480 --> 00:06:49,040
这些请求总共用了4148个输入Token。

47
00:06:49,480 --> 00:06:53,520
按公布的价格,每百万输入Token4.2美分估算下来。

48
00:06:54,180 --> 00:06:55,500
输入费用远不到一美分。

49
00:06:55,900 --> 00:06:58,680
按这个价格,输出Token是免费的。

50
00:06:59,300 --> 00:07:02,520
这些小例子成本其实很低,但一个应用的总成本。

51
00:07:02,520 --> 00:07:05,300
还包括你用来准备输入检查答案。

52
00:07:05,920 --> 00:07:08,880
以及处理那些需要换别的模型或人工介入的部分。

53
00:07:09,580 --> 00:07:11,140
我还记录了模型版本。

54
00:07:11,720 --> 00:07:13,060
我选的是JeffTheLatest。

55
00:07:14,000 --> 00:07:17,580
返回结果里,把模型识别成了Jeff1.13.0。

56
00:07:18,480 --> 00:07:22,500
这个信息最好和结果一起保存,因为叫做Latest的别名是会变的。

57
00:07:23,240 --> 00:07:25,040
总的来说,我觉得最有意思的地方,

58
00:07:25,680 --> 00:07:27,940
是你能很轻松地把这些判断塞进应用里。

59
00:07:28,360 --> 00:07:31,360
我测试的例子显示,它在路由否定选择值。

60
00:07:31,360 --> 00:07:34,740
以及根据证据核实说法,这几方面表现不错。

61
00:07:35,480 --> 00:07:37,960
也说明了你给出的选择和指令有多重要。

62
00:07:38,680 --> 00:07:40,580
这些只是八个代和城市里的小请求。

63
00:07:41,240 --> 00:07:43,140
他们给了我一些值得继续研究的方向。

64
00:07:43,720 --> 00:07:45,820
但还不能证明它在生产环境里可靠。

65
00:07:46,460 --> 00:07:49,020
也不能证明它在速度上比其他模型快很多。

66
00:07:49,700 --> 00:07:52,600
我把测试脚本也附上了,你可以自己附现这些例子。

67
00:07:53,300 --> 00:07:55,040
你也可以试试更大范围的样本。

68
00:07:55,500 --> 00:07:58,660
比较一下是把多个问题一起问,还是分开提问。

69
00:07:58,660 --> 00:08:03,000
这样更容易看出JF是否适合你工作流里的某个特定环节。

70
00:08:03,780 --> 00:08:05,020
总体来说还挺不错的。

71
00:08:05,380 --> 00:08:07,540
总之,欢迎在评论区告诉我你的想法。

72
00:08:08,240 --> 00:08:11,340
如果你喜欢这个视频,可以通过Super Thanks打赏。

73
00:08:12,220 --> 00:08:14,180
也可以点击这双按钮加入会员。

74
00:08:14,980 --> 00:08:18,560
另外,别忘了给这个视频点赞并订阅我的频道。

75
00:08:18,560 --> 00:08:20,580
我们下期再见,拜拜。