专访Jev发明者:把工作流程掌握在程序里,只在需要理解和判断的地方嵌入AI
4 小时前 / 阅读约15分钟
来源:36kr
TypeSafe发布首个大型可编程模型Jev,旨在成为软件直接调用的智能基础设施,优化“每美元智能”。Jev围绕程序使用设计,采用RLCD训练方法,强调可靠性而非确定性,未来将探索更多智能形态。

AI已经能解决数学领域极其困难的问题,却仍然很难自动化大量基础工作。

在美国AI初创公司TypeSafe创始人兼CEO迪奥戈·阿尔梅达(Diogo Almeida)看来,问题可能并不在AI“不够聪明”,而在于过去的模型从一开始就没有为真正的软件世界设计。

Jev就是他给出的答案。这是TypeSafe发布的首个大型可编程模型,被定义为“系统一模型”(System One Model)。它不以聊天为中心,也不把基准分数作为主要目标,而是试图让模型直接成为软件的一部分。它优化的核心指标只有一个:每美元智能。

Jev发布后,社交媒体上铺天盖地都是它的名字,Discord社区一夜涌入十万人,发布视频播放量突破3800万次。

阿尔梅达此前曾参与OpenAI指令跟随模型的构建。离开OpenAI后,他花了两年多时间寻找另一个问题的答案:为什么一个已经足够聪明的AI,依然很难可靠地进入真实工作流。

在Jev发布几天后,他接受了科技播客主持人swyx的专访。

整场访谈中,阿尔梅达反复强调几件事:

第一,AI现在最大的缺口可能不是能力,而是可靠性。模型能够回答复杂问题,但当它真正进入软件后台,偶尔拒答、输出漂移或者行为不可预测,都可能让整个系统失效。

第二,TypeSafe不想把AI做成“更像人”的聊天对象,而是想把它做成软件可以直接调用的智能基础设施。在阿尔梅达看来,AI应该更像数据库,而不是同事。

第三,RLCD(基于代码反馈的强化学习)代表了TypeSafe对模型训练方向的一次重新定义。RLHF(基于人类反馈的强化学习)优化的是“人类喜欢什么”,RLVR(基于可验证奖励的强化学习)更多围绕可验证任务展开,而RLCD的目标是让模型在程序环路中可靠工作。

第四,可靠性不等于确定性。同样的输入永远得到完全相同的输出,并不一定是最重要的事情。对于真实软件,更重要的是相似的问题能够得到相似的结果。

第五,未来的软件可能不再把AI当成一个大模型调用,而是把任务拆成大量更小、更容易验证的智能决策。状态、指令和标准都可以结构化,模型则被放到软件真正需要智能的位置。

阿尔梅达甚至认为,如果只给他10亿美元,他也不会选择从零开始预训练一个大模型。他更愿意把资源投入数据、后训练和新的智能形态。

以下为访谈实录精炼版:

01 为代码而生的“系统一模型”

问:你为什么会开始做TypeSafe和Jev?

阿尔梅达:我一直在想一个问题:AI为什么已经能解决数学领域的千禧年大奖难题,却仍然无法自动化很多基础工作?我后来意识到,缺的可能不是更强的自动化引擎,而是把AI接入真实经济工作的“插头”。

我在OpenAI参与指令跟随模型时,就发现模型虽然擅长“指令进、文本出”,但大量价值最终仍停留在文案生成等场景。于是我开始思考,如果AI要成为基础设施,真正的消费者会是谁?我的答案是代码。这也是我们后来做Jev的原因。

问:为那些不了解的人,用一句话定义,什么是Jev?

阿尔梅达:Jev可以被定义为“机器原生、系统一、大型、可编程模型”,核心目标是让代码成为模型的直接消费者。

注所谓的系统一模型是快速、直接、可靠的模型,做程序里的小决策,输出能被代码直接消费。系统二模型是慢速、长推理链的模型,擅长数学和复杂推理,但脆弱、参差、贵。Diogo 的核心观点是:行业过度关注系统二推理模型,但真正能自动化经济价值工作的是系统一。

与用于互联网文本补全的预训练模型、主要解决指令跟随的RLHF模型不同,Jev从一开始就围绕程序使用来设计,从模型内部到外部接口都针对软件进行了优化。我们真正关注的指标是“每美元智能”,成本和速度当然重要,但最终用户付费购买的还是智能。

Jev希望在这一指标上走到前沿,我们相信真正好的模型,用户一旦用上,很快就能感受到它是否真的有用。

02 RLHF的毒药:模式坍缩如何摧毁校准

问:你一直批评RLHF,它最大的问题是什么?

阿尔梅达:我认为最大的问题是它容易让模型变得过于保守,也就是所谓的“模式坍缩”。模型为了尽量避免犯错,会慢慢放弃那些少见但可能有价值的答案,只选择最安全、最容易得到奖励的结果。这样一来,模型看起来更稳定了,但实际上失去了很多探索空间。

问:这和杨立昆(Yann LeCun)的观点有什么关系?

阿尔梅达:我非常相信杨立昆,他的很多观点都很准确。他有一张著名的图,说明语言模型生成的内容越长,出错的概率通常越高。但我认为,实际情况没有这么简单。模型为了避免犯错,会变得越来越自信或越来越保守,最终把自己的判断空间压缩掉。这也是为什么我认为,直接把主要用于生成文本的模型拿去做复杂决策并不是一个好的方案。

03 RLCD:移除环路中的人类

问:RLCD是什么?它和RLHF、RLVR有什么区别?

阿尔梅达:RLCD不是为了听起来酷而创造的术语,它代表的是我们新的“北极星”。RLHF的目标是让模型更好地理解人类指令、给出人类喜欢的回答,RLVR则更多用于那些可以通过程序自动验证的任务。RLCD则是让模型能够可靠地工作在程序环路中。过去是“人在环路里”,程序只是辅助工具。我们希望把人从环路中移出去,让程序真正进入环路。

问:你把TypeSafe定位为数据实验室而不是模型实验室?

阿尔梅达:我们一直非常重视数据。模型能力最终离不开数据,而数据本身复杂得难以想象,可靠性也来自数据。2024年图灵奖得主理查德·萨顿(Richard Sutton)曾说过,大致来说,算法最终会胜过计算。我则更相信,数据比计算更重要。真正困难的,是选择正确的任务,并找到正确的方向。

如果回头看LLM的发展,我认为已经出现了几次重要的方向变化:RLHF、RLVR,现在轮到我们提出的RLCD。我们不会在用户数据上训练模型,因为真实世界的数据存在大量偏见和分布问题。我们更关心的是多年以后AI会变成什么样。我们的目标,是让模型成为一种通用基础设施,深入软件堆栈中那些今天甚至还无法想象的地方。

问:为什么数据如此重要?

阿尔梅达:你很难提前想象数据能改变多少东西。我们的数据团队一直在研究模型最核心的能力。他们会找出模型在哪些地方表现不稳定,再针对这些问题一点点处理,不只是解决某一个具体案例,而是找到背后的通用规律。这件事需要大量智能,所以我们一直在招聘数据方面的人才。

问:如果现在给你10亿美元,你会怎么投入?会从零开始训练一个大模型吗?

阿尔梅达:不会。如果只有10亿美元,我不会选择从零开始预训练一个大模型。我会把更多资源投入数据、后训练,以及新的智能形态。

今天从零训练一个基础模型需要非常庞大的计算资源,而且很多公司都在做类似的事情。我更感兴趣的是,在已有基础上继续探索模型还能变成什么,以及如何通过数据和训练方法,让智能真正进入软件和现实工作流。

这也是为什么我们把大量精力放在数据和后训练上。真正重要的不是简单地把模型做得更大,而是找到新的方式,让模型变得更有用、更可靠。

04 不追公共基准,也不靠拒答保证安全

问:你为什么反对公共基准?

阿尔梅达:因为公共基准非常容易被“刷分”。即使出题的人努力避免,模型开发者仍然可能找到各种办法针对测试进行优化。过去,每个实验室都会有人专门收集类似MMLU的数据,让模型在某个基准上看起来更强。这样做本质上还是在针对考试准备,只是多了一层包装。

我相信长期来看,真正的信任来自实际使用。把模型放进真实工作流,用真实任务测试它,然后自己感受它到底好不好。我们真正关心的是不断提高可靠性,而不是把一个公开分数做得更高。

其实我们一年半前就可以发布Jev,但那意味着我们必须接受一些自己并不满意的东西。融资的时候,也有人要求我们拿出基准成绩,但我们坚持认为这不是我们想走的路。有些原则确定之后,就应该坚持。

问:你也不做传统意义上的安全对齐,不做拒答,为什么?

阿尔梅达:我不反对安全原则,但我认为,安全对齐和用户需求有时并不一致。对聊天机器人来说,拒答可能没有太大问题。人遇到一个拒绝回答的聊天机器人,还可以继续对话。但如果AI是一个软件依赖,运行在后台,一旦它突然拒绝执行,依赖它的其他程序可能就会直接出问题。

但对软件工程师来说,这是无法接受的。我认为,智能更像数据库,而不是一个需要和你讨论价值观的同事。数据库不会判断自己提供的数据会不会被“错误地使用”,它只是提供数据。如果我们把太多道德判断直接写进智能本身,就会把智能拆得越来越碎。每增加一层针对特定情况的限制,模型就可能失去一部分通用能力。

问:Jev的API里有choice、score、no三个原语,这些概念是怎么来的?

阿尔梅达:我们为这些概念讨论了很久。“no”来自伯努利概率,它可以理解成一种连续的“是或否”。我们甚至想过把它叫作“pool party”,但没有人同意。这些概念故意没有直接对应传统编程里的类型。比如score不是一个普通的整数,no也不是简单的布尔值。它们和传统类型很接近,但又不完全一样。我们更看重的是把模型真正能做什么表达清楚,而不是让它看起来像开发者已经熟悉的东西。

ba b

问:它们具体怎么对应编程概念?

阿尔梅达:choice最接近程序里的switch,可以理解为从几个选项中选择一个;no对应if判断;score则更接近排序或者设置阈值。这一直是我们的愿景:未来还会有更多这样的类型,它们都可以直接对应某种编程原语。

输入也一样。状态、指令、判断标准,都可以作为结构化JSON对象传给模型,由程序决定把它们放在哪里,而不是全部塞进一个模板里。如果你还在大量依赖模板和系统消息,其实还是在用过去的方式思考AI。

05 怎么用Jev:把问题拆到足够小

问:开发者应该怎么用Jev?有什么具体建议?

阿尔梅达:把问题拆解成最小的语义单元。与其一次提出一个非常复杂的问题,不如提出很多独立的小问题,让每一个问题都容易评估。

系统消息有点像一个巨大的全局变量:你把所有指令一次性放进去,然后希望模型永远记住每一条要求。我认为这种方式本身就很奇怪。更好的方式,是把状态、指令和判断标准都作为结构化数据传给模型,由程序决定它们应该出现在哪里。

问:为什么不直接把所有东西放在一起问?

阿尔梅达:我自己做过基准测试。把所有内容塞进一个系统提示里,让模型一次性生成一个大答案,相比把任务拆成一百个独立问题,不仅更慢、更贵,效果也更差,而且非常笨重。更重要的是,这种方式很难真正依赖。

如果我们的模型不能稳定地在后台运行,我会非常失望。拆解任务之后,你可以检查每一步到底有没有正确执行。如果某一步出了问题,也能很快定位。这其实就是把AI变成一种可以测试的软件组件,而不是只能靠上下文“记住”事情。

问:能举个具体例子吗?

阿尔梅达:比如拒答。你可以直接问模型:“我现在应该拒答吗?”这是一个比较简单的问题,模型通常能处理得不错。但更好的方法,是把各种需要拒答的情况拆成很多独立的问题,让程序明确告诉模型需要判断什么。

如果你发现某种情况模型没有正确处理,就把这个情况单独加进去,设置阈值,并把它保存成一个测试用例。以后每次更新模型,都可以重新测试。这样,软件就不会因为一次上下文变化而“忘记”这个问题。这就是我所说的“没有ML的ML”:你仍然在使用机器学习,但整个系统的行为已经变得可以测试、可以验证。

06 可靠性与编码智能体的未来

问:你说的可靠性具体指什么?和确定性是一回事吗?

阿尔梅达:可靠性是一个很宽泛的概念。只要AI还不能自动完成一件事情,背后通常就存在某种可靠性问题。确定性指的是同样的输入得到同样的输出。我认为这对一些单元测试有用,但它不是我们最看重的目标。

我们更看重鲁棒性,也就是输入发生一些变化,只要意思基本相同,模型仍然应该给出相近的结果。比如我们会在提示里加入不同的UUID或者随机字符串,然后看模型能不能对这些本质相同的问题给出相近的答案。

确定性可以换来一些成本上的好处,但它可能会牺牲一部分智能。我们的目标一直是处在“每美元智能”的前沿。如果有人能证明确定性真的非常有价值,而且GPU也不再稀缺,我们当然可以考虑。但目前来看,这可能意味着用更高的成本换取更少的智能。

问:Jev发布后,人们主要拿它做什么?

阿尔梅达:我们从第一性原理出发,梳理了几类用例。

第一类是“暗数据”,也就是大公司积累的大量数据。这些数据本来很有价值,但过去用LLM分析成本太高,只能被闲置。对数据科学家来说,这是一个巨大的机会。

第二类是编码智能体,也是目前最大的商业应用之一。很多编码智能体过去都是围绕单一模型设计的,而Jev给了它们另一种选择。

还有一类是实时智能,也就是需要AI直接参与程序运行、同时不断验证结果的场景。因为Jev的调用成本更低,这些任务可以进行更多并行验证。

此外还有计算机使用。我们现场演示过,利用Jev通过语音操作整台电脑。

问:模型发布之后还会不断变化吗?

阿尔梅达:我们不会在模型部署之后偷偷改变它。但我们会比传统模型提供商更快推出新模型。我们也不会承诺一个模型长期保持不变,因为还有很多地方可以改进。

不同版本之间的变化,有时甚至比同一个模型连续调用两次产生的差异还小。但当模型从“有些地方参差不齐”变成“真的很好用”时,差异就会非常明显。我们并不是完全没有评估体系。我们有自己的内部测试,只是不希望把它变成一场“刷分游戏”。最重要的是求真。我们到底做出了多聪明的模型,这是最重要的问题之一。

问:你怎么看Jev现在的位置?下一步会做什么?下一次发布会很快到来吗?

阿尔梅达:Jev甚至不应该被看作我们的第一击。它更像一个低调的研究预览。我们认为,机器原生智能还有很多可能性。未来会出现一些现在看起来非常疯狂的东西。另外,下次发布会比很多人想象得更快。

问:TypeSafe最终想成为什么?

阿尔梅达:Jev只是其中的一部分。我把它比作TCP。TCP只是整个互联网协议栈中的一层,而我们后面还有很多层要做。至于TypeSafe能不能成为“智能领域的AWS”,我会尽我所能确保这件事发生。

特约编译金鹿对本文亦有贡献