Jev 现在也是在几天内火爆了全网，颇有曾经“龙虾”突然爆火时的感觉。

在 TypeSafe AI 创始人 Diogo Almeida 的宣传中，他们已经秘密研发这个方向两年，而 Jev 在大众视野里，也确实宛如突然出现一般。

据 TypeSafe AI 官方公布的数据，在他们的测试场景中，Jev 最高实现了 193.6 倍的速度提升和 444.6 倍的成本降低。

当然，这两个数字属于官方测试中的高收益场景，不过 Jev 本身确实走了一条和传统大模型很不一样的路线。

那么先简单理解一下，Jev 到底是什么？

Jev 是什么？

Jev 跟我们平时使用的 LLM 有明显区别。

传统大模型主要负责生成内容，你可以让它回答问题、写文章、写代码。但 Jev 基本不负责这些事情，它主要负责判断。

所以我觉得可以把 Jev 粗略理解成一个神经网络版、语义版的 if / switch。

比如收到一条用户评论：

我的支付失败了。

现在需要判断应该交给哪个部门处理，候选项有账单、宣传、技术和其它。

Jev 做的就是根据这段文本判断它更符合哪个选项，不同于普通大模型一样生成一大段“根据用户描述，我认为应该交给……”之类的回答。

对于程序来说，这种输出其实更加直接，因为程序真正需要的往往也不是一段自然语言，而只想知道：接下来到底走哪个分支。

相信大家也体会过向模型提出问题, 结果模型侃侃而谈输出一大堆话, 而你只用看最后的那一句总结。

Jev 官方把这种模式称为 smart if-statements，也就是“智能 if 判断”。

而 Jev 目前主要有三种输出类型：Choice、Score 和 Noul。

State

不过在说这三种类型之前，需要先说一下 state。

state 可以简单理解成：你交给 Jev 判断的当前信息或者上下文。

比如：

"state": "客户表示：连续三天无法连接支付系统，影响营业，希望立即处理。"

它可以是一句话，也可以是一段日志、一条工单或者 Agent 当前的一些运行状态。

Jev 根据这个 state，再去回答你后面定义的问题。

Choice

首先是 Choice。

Choice 很好理解，就是从多个提前规定好的选项中进行选择。

比如：

"department": {
  "type": "choice",
  "instructions": "应该由哪个团队处理这条反馈？",
  "criteria": {
    "technical": "故障、报错或集成问题",
    "billing": "账单、付款或订阅问题",
    "sales": "价格、购买或商务咨询"
  }
}

这里我们提前告诉 Jev，一共有 technical、billing 和 sales 三种可能，同时告诉它每个选项代表什么。

相比普通 LLM，这样做有个很明显的好处：输出空间是提前确定好的。

普通大模型可能突然告诉你“建议转交财务部门”，但你的系统里可能根本没有“财务部门”这个类型，还需要自己做额外解析。

Jev 的 Choice 则不会突然创造一个新的选项。

当然，这不代表它一定判断正确。比如真实应该是 technical，它依然可能判断成 billing。只是它至少会老老实实从规定好的类型里选择。

Score

接着是 Score。

Score 主要用来判断程度。

比如我们想知道：

这个客户现在有多不满？

就可以定义：

"frustration": {
  "type": "score",
  "instructions": "客户表现出的不满程度如何？",
  "criteria": [
    "平静陈述",
    "有所不满",
    "明显愤怒"
  ]
}

这种方式很适合风险程度、紧急程度、用户意向、投诉严重程度之类的判断。

所以 Choice 可以理解成：

它属于哪一种？

Score 则更接近：

它到了什么程度？

Noul

最后是 Noul。

Noul 可以简单理解成一个带概率的 Yes / No 判断。

比如：

"urgent": {
  "type": "noul",
  "instructions": "这条反馈表达了紧急处理需求"
}

它不会简单返回 true 或者 false，返回的一个概率。

比如结果是 0.96，就代表模型非常倾向于认为这条反馈需要紧急处理；如果只有 0.53，说明判断并没有那么确定。

这里就可以根据自己的业务需求设置阈值。

比如超过 0.9 自动进入紧急流程，低于这个数继续普通处理，或者交给人工判断。

所以 Jev 负责的是给出判断，最终这个判断如何影响业务逻辑，还是由开发者自己控制。

实际调用其实就是 JSON

Jev 实际发送的包体就是 JSON，返回的同样也是 JSON。

比如前面几个判断完全可以放在同一次请求中：

{
  "model": "jev-latest",
  "state": "客户表示：连续三天无法连接支付系统，影响营业，希望立即处理。",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "应该由哪个团队处理这条反馈？",
      "criteria": {
        "technical": "故障、报错或集成问题",
        "billing": "账单、付款或订阅问题",
        "sales": "价格、购买或商务咨询"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "客户表现出的不满程度如何？",
      "criteria": [
        "平静陈述",
        "有所不满",
        "明显愤怒"
      ]
    },
    "urgent": {
      "type": "noul",
      "instructions": "这条反馈表达了紧急处理需求"
    }
  }
}

也就是说，一条用户反馈进来之后，可以同时判断应该交给哪个部门、用户有多不满、是不是紧急问题。

这种形式其实很符合程序本身的使用习惯。

Jev 为什么会这么快？

Jev 和普通 LLM 一个很大的区别就在这里。

传统 LLM 需要一个 Token 一个 Token 地生成回答，即使你最后只想知道“是还是不是”，它可能依然要经过完整的文本生成过程。

而 Jev 不需要生成一整段自然语言，它本身就是针对这种结构化判断设计的。

TypeSafe 还为 Jev 提出了一套叫 RLCD（Reinforcement Learning for Calibrated Decisions） 的训练方法，重点之一就是让模型给出的概率更有参考价值。

比如模型经常给某一类判断 0.9，理想情况下，这类判断长期来看确实应该拥有接近 90% 的正确率。

放进 Agent 里可能更有意思

我觉得 Jev 一个比较有意思的使用方向其实是 Agent。

现在很多 Agent 在执行过程中，会频繁调用大模型判断下一步应该使用哪个工具、是否继续执行、某个结果是否可信。

但其中很多判断本身其实并不复杂。

比如：

这一步应该使用搜索 Skill，还是数据库 Skill？

如果这种高频、结构明确的判断也全部交给大型 LLM，成本和延迟都会增加。

Jev 理论上就可以承担其中一部分工作，例如用 Choice 判断应该调用哪个 Skill，用 Noul 判断是否需要人工介入，再把真正复杂的代码生成、长文本理解和推理继续交给 LLM。

也就是说，Jev 负责一些快速判断，大模型负责真正复杂的工作。

甚至可以把它放进模型路由, 由它判断这条请求该交给便宜模型、中档模型还是高能力模型。让额度利用最大化。

至于实际效果到底怎么样，我还需要继续使用一段时间。等后面用得熟练一些，可能会再单独写一篇看看 Jev 放进 Agent 之后到底能起到什么有价值的作用。

另外，截至这篇文章发布时，TypeSafe 官方已经暂停了直接注册，目前只能先进入候补名单。

如果想更快拿到资格，可以顺手填写一下他们的问卷，或许优先级会高一些。

如果只是想先体验一下 Jev，也可以找支持 Jev 的第三方平台试用。

另外我自己也顺手 vibe 了一个 Jev 的可视化界面 ，也可以配置第三方上游来体验, 前面的一些截图展现也是来源于这个项目的：

https://github.com/Augustzero/Jev-Lab

最后

Jev 现在依然是一个非常新的模型。

它最终会像以前一些爆火的 AI 项目一样热度慢慢消失，还是会真正成为一种有价值的模型形态，目前还需要时间验证。

(这位老哥用 Jev 做了一个实时自动交易机器人, 已经亏了三万美元了)

但有一点我觉得比较明确：Jev 的定位确实非常清楚。

它的出现是为了专门处理一个更加具体的问题：

给它当前状态，让它帮程序做判断。

Choice、Score、Noul，最后依然回到我们平时最熟悉的 if 和 switch 中。

这可能是 Jev 最有意思的地方——AI 不一定什么事情都需要先生成一大段文字，有时候，程序真正想要的可能就只是一个判断结果。