最近,硅谷出了一个非常特别的模型,叫做JEFF。他发布以后,很快就在开发者圈里刷屏。但如果只看网上的随便信息,很容易产生两个误解。第一个误解是,JEFF又是一个准备去挑战CHIGBT Cloud的全能模型。另一个误解就是,他不就是一个普通的分类器吗?为什么突然有这么多人讨论?所以,今天这期内容,我把整个JEFF的来龙去脉都梳理一遍。然后想从八个方面给大家去讲清楚。第一个,JEFF到底是什么?第二个,他开源了没有?第三个,能不能写的?
第四个,为什么突然就火了?第五个,他的优势在哪里?第六个,这条技术路线到底成不成立?第七个,开发者现在想用它来去做什么?第八个,如果你想试一试,又该怎么去上手?首先,如果理解JEFF可以从我经常推荐的一本书讲起,就是丹尼尔·卡尼曼的《思考快与曼》。书里,他把人的思考方式分成了两套系统。系统一负责去快速判断,看到前面有东西飞过来,我们可能就本能的会躲开,看到一个人的表情,我们就能很快的判断他是不是生气了。而系统二负责的是慢,
做一道复杂的数学题,分析一份商业计划,或者权衡一个重要的决定,都需要去投入更多的注意。过去几年,大模型的发展其实主要都在不断的加强系统,模型要学会去理解复杂问题,展开推理,量用工具,然后生成一段完整的答案。而TypeSafe提出的问题就是,一个AI系统里的每一步都需要这样的认证思考吗?很多时候程序需要的其实不是一篇文章,而是一个判断,这个就是JEFF出现的原因。TypeSafe把它叫做System-1 Model,也就是这个屏幕上写的。
这个名字呢,就借鉴了思考快一慢的概念,但更多的是一种产品的类比,它并不是说复现了人的直觉,而是专门去处理那些范围明确,需要快速完成判断的任务。你可以把JEFF理解成一个专门去给程序使用的决策模型。穿透大模型,接受一段文字,然后继续去生成文字。那JEFF呢,接受一段材料和几个体型定义好的问题,返回的是选项,是分数,以及相应的概率。比如说,用户发来一句话,我买的东西一个星期还没到,现在不想要了。
去写回复,而是需要搞清楚几件事情。这个用户是在查物流,还是在准备退款。情绪是不是激烈,要不要去转给人工客服?JEFF呢,会从开发者给定的选项里面去做选择,并且告诉程序每一个答案有多大概率,那程序拿到结果以后,就可以继续执行对应的流程。所以,有一句话就可以很直观的去概括它了。CHATGPT负责写答案,JEFF负责去做判断。OK,那第二个问题,JEFF开源了没有?目前是没有的。Type Safe呢,没有公开JEFF的模型权重,
和核心实现,开发者呢,主要还是通过云端API去调用它。所以它和LAMA这一类可以去下载权重自己部署的开源模型,不是一回事。它更像是一种模型服务,你把材料和问题发给它,它把决策结果反回来。那第三问题,就是它能不能去携代码。首先,它不能替你去写Python,不能生成网页,也不能帮你写邮件或者营销文案。更准确的讲,它就没有自由文本生成这个能力。但呢,这不代表它和编程没有关系。一个编程agent在执行任务的时候,可能要不断的判断下一步该对,
读哪个文件,该掉用哪个工具,测试是不是通过,要不要继续修改。那Jeff不能生成代码,但可以去参与这些流程里的选择。所以他不是一个写代码的人,更像是站在流程里面去做不断分流的人。这也能解释他为什么就突然火起来。你看过去大家评价一个新的模型,习惯会看他会不会写代码,数学能力有多强,推理链到底有多长。而Jeff反过来去做了另一件事情,他主动放弃自由的文本生成,只优化判断,优化选择,优化打分。
他正好击中了agent正在遇到的一个现实问题。我们经常会看到一个agent最后生成了一份报告,好像他只完成了一次任务,但这个过程中他可能做了成千上百次的选择。比如说这条搜索结果有没有用,这两份资料是不是在重复表达同一个观点,现在的信息够不够,下一步应该掉用工具,还是开始去写作,这段结论有没有证据的支持。如果每一个小判断都需要去掉用一次非常强的通用大模型,延迟和成本会一层层累积。更麻烦的是,大模型明明只需要返回一个选项,但可能会顺手的减法,但他正好击
写一段解释或者输出一个不完全符合要求的json。那jef呢,试图就是把这些小的判断单独拿出来解决。所以这么一看下来,其实我们就知道了,他第一个优势就是快。按照type safe公开的信息,jef处理一次决策通常需要70-500毫秒。对于浏览器的操作、实时审核、agent路由这类连续决策任务,这个差别会直接影响到产品体验了。好,第二个优势呢,就是便宜。官方价格大约是每百万输入的token是4.2美分啊。
单次调用省下来的钱可能没那么明显,但当系统每天都需要完成几万次几十万次判断时,成本差距就会无限的被放大。第三个优势就是输出稳定。如果开发者只给出了5个候选选项,他就只会在这5个选项里返回结果,不会突然说创造出第6个答案,也不需要程序再从一段自然语言里面去提取结论。但这里一定要区分两件事情,输出格式稳定不等于判断是一定正确的。jef不会在格式上去胡乱发挥,但他在这些什么情况下,就是说,如果开发者只给出了5个候选项,他
完全可能在合法选项里面去选错,所谓不产生自由闻闻幻觉,解决的是接口问题,不是准确性的问题。第4个优势就是它会返回概率。普通分类器往往只告诉你答案是什么,那jef希望去把置信程度也交给程序,这样系统就可以设计不同的策略,把握很高,而且操作风险很低,可以自动执行。把握一般,那就交给更强的大模型做复合,把握太低的,或者涉及到退款付款,商库这类高风险动作的,就转给人工。
另外,jef还可以读取一次材料,同时回答多个相互独立的问题。还是前面的客服消息,他可以同时判断用户意图,情绪,紧急程度,和是否需要人工介入,不用反复的去读取一段上下文。
OK,那这条路线到底对还是不对?其实我的理解,在他适合的任务里面,这条路线肯定是成立的,大原模型通常要采用自回归生成,他需要一个token,接着一个token生成答案。这个机制呢,给予了他协作,编程和开放式推理的能力,但如果程序只需要一个不而直,或者一个没举项,
完整走一遍文本生成的流程,确实比较重。而jef把输出空间提前的限制住,不再去生成任意文字,而是直接围绕候选答案去计算概率,他失去了自由表达能力,也因此换来了更低的延迟,更低的成本,和更容易被代码处理的结果。
但他也不是所谓问题的答案,如果任务需要长链条推理,需要精确计算,需要理解复杂的日期关系,或者需要模型给出完整理由,jef都不是合适选择。
他的官方文档也明确提出,他在算术记住日期比较多部推理,以及包含大量无关信息的任务上存在短板,他同样可能也会受到提示词注入的影响。所以讨论这条路线的时候,我觉得不能问jef和cloud更聪明,他们解决的就不是同一种问题。
cloud和gbt擅长的是开放式任务,传统分类模型适合类别长期固定,数据充足,可以专门训练的任务,那jef想占据的,其实中间那一层,问题由开发者临时定义,但输出必须限制在明确的类型和选项里。
这一层以前经常交给大模型,现在终于有人开始为他单独去设计模型了。另外开发者也已经在尝试把jef放进不少的场景里面了,想客服系统,来判断用户意图,把消息转到查询订单,退款,投诉,或者人工客服。
其他系统可以用他先来判断检查回来的资料到底是不是相关的,先过滤掉无关内容,再把剩下的材料交给大模型。
内容平台也可以用他来做垃圾信息,辱骂内容,风险文本的前置判断。agent可以用他来选择下一步调用哪个工具,或者决定任务,是不是已经完整。
Blozer Use 社区还做了一个jef ultrafast浏览器agent。jef负责从网页元素去选择该点击的按钮和输入框,只有遇到真实需要填写的文字的时候,才去调用生成模型。
他们的结果呢,一次疏离室到伦敦的航班搜索演示,只用了7.1秒。
Type Safe自己也演示过让jef去玩Doom。输入不是游戏画面,而是血量、敌人位置、弹药数量等已经整理好的游戏状态。jef不断从有限动作中去做选择,实现每秒的多次决策。
这些案例表面上差别很大,但他们其实有个共同点,任务边界清楚,后选动作明确,请求频率很高,而且程序不需要一段漂亮的文字,只需要知道下一步到底该做什么。
这个才是jef真正适合的位置。
如果你想自己上手,流程其实也不复杂,可以直接去用Type Safe提供的Pregground和API,也可以通过VSL AI Gateway或者CloudFair去调用。
一次请求里主要可以放两个东西,一份是State,也就是模型做判断需要看到的材料,另一份是Questions,也就是你希望他回答了。
也就是你希望他回答了问题,候选选项,或者评分范围。
jef读完State以后,会返回每个问题的答案和概率,你的程序再根据概率去决定下一个动作。
不过真正困难的地方,往往不是API的接通,而是去把你的问题给定义清楚。
还是那句话,我买的东西一个星期没到,现在不想要了。
如果选项只有物流的延迟和申请退款,知道单选题本身就设计得太好。
物流延迟是原因,申请退款是诉求,它们可以同时成立。
模型不会提开发者修复一套混乱的业务标准,给他的信息不完整,问题不明确,或者选项互相重叠,速度再快也没有用。
所以比较稳妥的使用方法就是先选择一个范围很小,答案比较清楚的任务。
哪一批已经有人工处理过的历史数据,让jef在旁边运行,暂时不要参加真实操作。
观察他在哪些任务上稳定、智信度和真实正确率是不是匹配,再根据风险设定自动通过,模型复合和人工处理的预知。
低风险,高频,可设销的动作,可以更积极地去做状况。
而退款,资金,权限和删除数据这些操作,仍然去保留代码规则和人工审批。
所以我认为,jef真正有意思的地方,不只是说把原本的一次调查做便宜了。
他可能让原本因为成本太高而没有发生的判断,开始大量出现。
当然更多判断不一定自动带来更好的结果,如果标准本身就错了,系统值在更快更便宜的重复错误。
但我始终认为jef至少提出了一个很值得观察的方向。
未来的软件未必需要一个模型包办所有事情,复杂推理可以交给强模型,内容生成交给生成模型,范围明确的小判断,再去交给jef这一类的决策模型,再配合代码规则和人工审核。
不是每一道题,都需要一皮A篇作文,有些时候程序员真正需要的只是一个足够快,带着概率,可以立刻执行的答案。