朋友们大家好啊,我是金尘马。
先问大家一个问题:从处理的内容来看,我们平时接触的 AI 大模型,常见的有哪些类型?
可能大家最熟悉的就是文字、图片、音频和视频。这几年,各家厂商围绕这些方向不断竞争、迭代,能力越来越强,竞争也越来越激烈。
看多了这些更新,我一直在想:除了把已有的模型做得更强,还会不会出现一种新的模型形态?
最近,一个叫 Jev 的模型开始火爆全网。一开始我还在想:这是不是又是哪家公司出了一个新的大语言模型?
但深入了解之后,我发现,这个模型真的让人眼前一亮。
它背后的 TypeSafe AI 提出了一类叫作 System One Models 的模型,专门围绕软件里的判断任务来设计。Jev,就是他们推出的第一款公开模型。
前面说的文字、图片、音频、视频,是按处理的内容来分;这次,他们换了一个角度:把“做判断”这件事单独拿出来,围绕它设计模型。
我觉得,这个方向可能会对后续 AI 模型的发展和分工产生很深远的影响。
接下来,我就用一篇文章,给大家讲清楚到底什么是 Jev,它跟我们平时用的大语言模型有什么区别,又能用在哪些地方,以及怎么上手体验。
从画二维码的例子说起
怎么理解 Jev 呢?我们可以想象一下,假设你想生成一个二维码。
本来你可以用二维码生成工具直接生成,但是你请来了一位什么都能画的画家,让他一格一格地画出来。
当然,这个画家能力很强,他也能做这个事。但生成二维码,本身就有专门的工具。你只是想要一个能用的二维码,并没有要求他顺便画一幅风景画。

类比到 Jev 和大语言模型,也有类似的地方。
大语言模型能写文章、写代码,能陪你讨论一个复杂问题。你让它看一条评论,判断用户的态度,它当然也可以做。
但如果这次任务只需要一个选择,或者一个分数,那么就可以考虑:能不能专门围绕这种任务,做一个更快、更便宜、方便程序调用的模型?
Jev 做的就是这个方向。
它把自由生成文字的能力放下,专门处理那些答案范围明确的判断。 比如你提前给出「满意、不满意、褒贬混合、无法判断」四个选项,它就从里面选择,并给出各选项的概率。
就像生成二维码可以用专门的工具,这些只需要选项和分数的任务,也可以交给专门为它们设计的模型。按照官方介绍,Jev 对这类判断任务的优化,能降低响应时间和调用成本。
比如每天要筛选大量电商评论,每条评论都要判断用户态度、紧急程度和处理方式。这些判断如果能做得更快、更便宜,就能减少整套流程的等待时间和调用费用。程序拿到结果后,再继续分类或者转给人工处理。
Jev 的由来
那是谁做出了 Jev?又为什么会想到,专门做一个负责判断的模型?
Jev 背后的公司叫 TypeSafe AI,创始人 Diogo Almeida 曾在 OpenAI 参与聊天模型相关研究。
他关注的一个问题是:AI 已经这么会聊天了,为什么我们还不能很方便地把这些能力放进软件,让它自动完成更多事情?
软件很擅长执行明确规则。符合一个条件,就做一个动作。但现实里的很多判断,很难提前把规则写全。
就像看评论。哪些表达是在抱怨,哪些是在开玩笑,哪些表面上夸了一句,其实后面全是意见。你很难靠几条规则覆盖用户所有的说话方式。
TypeSafe 想把这种语义判断做成一个方便调用的组件。程序需要理解一段话、选择下一步的时候,就把这个小任务交给模型,拿到结果,再继续执行。
他们把这类模型叫作 System One,名字借用了《思考,快与慢》里的概念。你可以把它理解为偏向快速、直觉式判断的那一部分。
Jev 这个名字则来自经济学家 Jevons。团队想表达的期待也很直观:智能调用的成本越低,人们就越可能把它用到更多地方。
有些环节,以前觉得专门调用一次 AI 不划算。如果判断足够快、费用足够低,就值得重新考虑了。
Jev 跟大语言模型有什么区别?
想让软件更方便、更便宜地调用 AI 做判断,这个出发点很好理解。不过,现有的大语言模型也能做判断,也能按规定的格式返回结果,为什么还要专门做一个 Jev?
我们先看看大语言模型是怎么把判断结果交给程序的。
大语言模型可以做结构化输出,你可以理解为把答案放进事先约定好的格子里。比如这格填态度,那格填紧急程度,另一格填处理方式。程序收到之后,就知道每个位置代表什么。
你可能见过 JSON,就是这种结构化数据常见的表示形式。开发者可以让大语言模型按规定格式返回结果,并对输出加约束。
所以,只看最后返回的是一段文字还是一个 JSON,还看不出 Jev 和大语言模型的主要区别。
差别在于,模型是怎么把这个结果生成出来的。
普通生成式大语言模型通常需要逐个 token 生成答案。token 可以简单理解为模型处理文字时使用的小片段。即使你要求它输出一份格式固定的数据,它通常也要把这份结果逐步生成出来。
Jev 针对这种判断任务采用了专门的输出方式,可以并行给出多项判断及其概率。你对同一条评论提出几个问题,可以在一次请求里一起拿到结果。
这种输出方式的差异,就关系到我们前面说的速度和费用。软件每天可能要处理大量数据,每次判断虽然只是一小步,加起来的调用费用也不少。Agent 这种能调用工具、连续执行任务的 AI 助手,还需要反复判断下一步怎么走。响应够不够快、调用贵不贵,会直接影响这个软件怎么设计、运行成本有多高,以及用户用起来是否流畅。 有些环节原本因为太慢、太贵,只能省掉;现在就有机会把 AI 判断加进去。
还有输出格式的稳定性。我们规定它从几个选项里选,它就按照这个范围交出结果,方便外面的程序往下处理。
Jev 的三种新特性
这次 Jev 最核心的,就是下面这三个新特性。它们的设计思路很有意思,值得拿出来看一看。
先简单认识一下这三个特性。Choice 是做选择,从你给定的选项里选一个;Score 是打分,按照你设定的标准给出分数;Noul 是判断一句话成立的可能性,返回一个概率。
这里,我正好借用官方的 Playground,通过一个小演示,边实操边给大家展示这三个新特性到底怎么玩。
我们就拿电商评论的处理来举例。假设你在经营一家网店,每天都有顾客留下评论。你想知道大家对商品和服务满不满意,也需要从中找出要跟进的问题,判断该怎么处理、哪些要优先处理。
这次演示,我们就把下面这条评论交给 Jev:
东西挺好,就是快递等了十天,问客服也没人回。
围绕这条评论,我们分别用这三个特性来做判断,看看它会返回什么结果。
Choice:做选择
先问它,这条评论的整体态度是什么?
我们给出四个选项:满意、不满意、褒贬混合、无法判断。
它返回了「褒贬混合」。
这个结果很好理解。用户对商品本身有正面评价,但同时对物流和客服表达了不满。如果只允许选满意或者不满意,就会丢掉这条评论里的一部分意思。
同样,我们还可以问:这条评论下一步该怎么处理?
这次的选项换成了「转人工跟进、自动回复、无需回复」。同时告诉它一条处理规则:涉及仍未解决的服务投诉,需要人工跟进。
它选择了「转人工跟进」。
你会发现,选择题的内容可以变。选用户态度、选负责部门、选下一步动作,都可以用这种形式来问。选项由我们提前提供,Jev 负责结合材料和要求作判断。

Score:打分
然后我们问,这条评论有多紧急,需要多快跟进?
打分之前,要先把标准说清楚。这次设了三个等级:
- 0 分: 普通评价或简单咨询,没有未解决的投诉。
- 1 分: 有未解决的物流或服务投诉,但没有提到安全问题、重大损失或紧迫的截止时间。
- 2 分: 明确涉及安全问题、重大损失或紧迫的截止时间。
Jev 返回的是 1 分,也就是这套标准里的中等紧急程度。
分数和你提供的标准息息相关。 你也可以换成评价回复质量、信息相关性等其他标准,但得先告诉它,什么算好、什么算差。
它还可以给出落在两个等级之间的分数,不一定只能返回整数。

Noul:判断陈述是否成立
最后我们给它一个陈述:
用户在评论中明确提出了退款要求。
这类问题会返回一个 0 到 1 之间的概率,表示这个陈述成立的可能性。
这次返回的是 0.03,也就是 3%。
用户确实不满,但评论里没有明确说要退款。所以模型对「明确提出退款要求」这件事,给出了很低的概率。

把这次实际返回的结果放在一起看,就很清楚了:

这四个问题是一起提交的,一次拿到了全部结果。本次接口报告的模型评估时间,大约是 85 毫秒。
到这里,程序已经有了一组能直接使用的信息:评论属于哪种态度、要转给谁、优先级放在哪儿、有没有退款诉求。接下来就可以根据这些结果继续处理。
Jev 能用来做什么?
我们刚才只处理了一条评论。如果是一个电商平台,每天有大量评论进来,这种用法就可以继续往下展开。
首先,可以做统计。
哪些用户对商品满意,哪些用户在抱怨物流,哪些问题需要客服跟进。模型负责把评论里的意思判断出来,程序负责汇总数量、分类展示。
其次,可以先筛选一遍,决定哪些内容值得进一步处理。
普通评价进入统计,没有回应需求的就不用逐条回复。有未解决问题的转人工,适合自动回复的,再交给大语言模型结合相关信息写回复。
原本如果全都让较贵的通用大模型先看一遍,再去分类处理,第一轮就会产生不少调用费用。现在可以把这个前置筛选交给 Jev,把后续需要深入处理的部分留给大语言模型。
那用关键词筛选行不行?
也能做一部分,但关键词很容易漏掉语境。
比如这句话:
质量可真好,穿一天就开线了。
只匹配「质量好」,就很容易把它归到好评里。可我们看完整句话,就知道用户在讽刺。
Jev 的输入仍然可以是自然语言,它需要理解整段材料的意思。它的专用化主要体现在要解决哪类任务、怎样交出结果,不能把它理解成一个只会匹配关键词的工具。
而这些结果要变成动作,还需要外面的程序。
返回「转人工」,程序就把这条评论送进人工处理队列;返回「自动回复」,程序再调用大语言模型生成回复。这些动作由流程里的规则和工具来完成。
放到 Agent 里,这套组织模型调用、工具和执行流程的外部系统,我们常常会叫它 Harness,也就是平时说的那个「壳」。Jev 可以放进其中的判断位置,帮它选择下一步。
所以我觉得,Jev 和大语言模型其实是互补的关系,而不是互斥、不是有你没我的这种概念。
具体到分类、打分这些环节,可以用 Jev 把原来的大模型替换掉。到了后面,具体要写文案、写代码,或者做复杂的多步推理和思考时,还是由大语言模型来承担。
所以在一个系统里面,可以针对不同的环节,使用不同的模型来解决特定的问题,让这些不同能力的模型进行有机结合。

如何体验 Jev?
最直接的方式,就是打开 TypeSafe Playground。
登录后,把要分析的文字放进 State,也就是待判断的材料。再在 Questions 里设置问题,选好判断类型,填入选项或者评分标准,点击 Run,就能看到结果。
你可以直接拿前面那条评论来试,也可以换成一句满意的评价,再看看返回结果怎么变化。
如果想把它接进自己的软件,就通过 API 调用。
API 可以理解为,一个软件把能力开放出来,让另外一个软件也能来用。你从控制台获取 API Key,程序带着这个调用凭证,把材料和问题发给 Jev,收到结果以后,再根据结果往下执行。
官方还提供 SDK,就是把调用接口常用的功能封装成开发工具,方便开发者接入。
价格方面,官方公布的是每百万输入 token 0.042 美元,输出免费。输入包括你交给它的材料、问题和判断标准。前面说的海量评论筛选,就可以用这种按调用量付费的方式接进现有流程。
专用判断模型的未来
研究完 Jev,我真的有点眼前一亮的感觉:哎,早就应该有人这么干了,但一直没见到有人这么干。
我觉得这个思路和方向是对的。当下大家都在卷大模型的性能和能力,TypeSafe AI 开辟了一个新的赛道,专门针对结构化数据、概率判断,以及选择和决策这类场景,去做定制化的模型。
无论是成本还是速度,这对 Agent 都很友好。在某些场景下,等着大模型慢慢返回数据,这个过程确实太低效了。
我相信,这个思路后面各家厂商大概率都会跟进,去做面向 Agent 判断环节的专用模型。
一个 Agent 里面,可以有模型负责快速判断,有模型负责复杂思考、写文案和代码,再配合图片、音频、视频模型,一起完成任务。
当判断足够快、足够便宜,我们就有机会把它放到更多原先不值得调用 AI 的地方。 对我来说,这也是 Jev 这个方向最值得期待的部分。
金尘马|大厂程序员|30天X破万粉变现过万|持续分享 AI 搞钱、程序员转型、OPC 心得|联系方式见主页介绍:https://x.com/jinchenma_ai





