Jev 精讲

我们一直像用锤子一样对待所有AI问题，甚至简单的决策也不例外。而Jev能在毫秒级时间内处理这些决策，成本仅为零头。让我们深入了解其工作原理及适用场景。

TypeSafe AI 于2026年9月15日发布了Jev，这款模型既无法对话、编写代码，也无法生成哪怕一段有用的文本，却引发了异常强烈的反响。

而这种局限性正是其核心价值所在。

大多数软件并不需要另一个聊天机器人。它们需要的是处理成千上万个微小判断，例如：这个工单是否紧急？哪个模型应该处理这个请求？这条shell命令是否危险？这段检索到的文本能否回答问题？

团队通常将每个判断都发送给通用大语言模型。模型逐token生成答案，应用程序解析结果、验证格式，并在格式错误时重试。虽然可行，但对于仅有五种可能答案的决策而言，这种做法既缓慢又昂贵。

Jev正是专为这类决策而生。TypeSafe称之为“一型模型“：输入非结构化状态，输出带类型标识的答案及概率。

让我们解析这一定义的内涵、适用场景，并指出营销宣传中需要保持克制的地方。

首先理解Jev要解决的问题

自工具调用和结构化输出功能出现后，大语言模型与软件的集成变得简单得多。

工具调用让模型能以可预测格式请求函数调用。结构化输出使其能返回符合模式的JSON数据。两者都消除了大量脆弱的解析环节。

但底层模型仍然是生成式的。即使答案仅为“计费“这样的单个词，它仍按顺序生成token。你需要为输入付费，等待生成过程，且输出部分往往需要支付更高费用。

现在将其置于代理循环中：

python while not done: action = llm(context) result = run_tool(action) context += result

模型可能需要反复调用以选择工具、判断结果、检测风险、判断任务完成状态，并选择下一个模型。单次代理运行可能包含许多需要判断但无需生成文本的调用。

Jev正是瞄准这些调用场景。

其核心主张很简单：当代码已知所有可能答案时，语言生成就是错误的接口。

Jev究竟是什么

最精简准确的描述是：语义决策引擎。

你向Jev发送两样东西：

• 状态：描述当前情况的文本或JSON数据。
• 问题：你希望基于该状态做出的决策。

每个问题都预先声明答案的格式。Jev支持三种基础类型：

• 选择：从你定义的列表中选择一个选项，并返回每个选项的概率。
• 评分：将输入置于你定义的有序量表上，如“低“、“中”、“高”。
• 诺尔：回答是/否问题，返回为真的概率。

诺尔是TypeSafe对布尔型原语的特殊命名。其特殊命名的重要性不如输出结果（一个0到1之间的数字，你的程序可直接使用）。

{
  "model": "jev-latest",
  "state": "部署失败两次，客户正在看到500错误。",
  "questions": {
    "urgent": {
      "type": "noul",
      "instructions": "是否需要立即关注？"
    },
    "owner": {
      "type": "choice",
      "instructions": "应由哪个团队处理？",
      "criteria": {
        "engineering": "产品故障和宕机",
        "billing": "费用、账单和退款",
        "sales": "定价和新账户"
      }
    }
  }
}

响应包含紧急概率和三个团队的概率分布。没有需要解读的段落，模型也不会虚构第四个团队。

你的程序始终保持控制权：

if urgent > 0.9 and owner == "engineering":
    page_on_call()
elif confidence < 0.6:
    send_to_human_review()
else:
    add_to_queue(owner)

这就是为什么人们常称Jev为“智能switch语句“。这种说法虽显轻蔑，却准确抓住了设计的实用核心。普通代码负责分支逻辑，模型提供普通代码无法可靠计算的模糊判断。

与大语言模型的重要区别

传统大语言模型和Jev都能分类工单，但它们通过不同方式达成答案，在系统不同部分发挥作用。

TypeSafe表示Jev可并行评估请求中的所有问题。这改变了工作流设计方式——无需提问、等待、再决定下一个问题，你可以在一次请求中就同一状态的所有独立问题提问，让代码直接使用所需答案。

据该公司报告，端到端延迟在70至500毫秒之间，价格为每百万输入token 0.042美元，输出免费。其主要声称达到比可比大语言模型工作流快约200倍、便宜约400倍的效果。

这些巨大倍数来自TypeSafe自身的工作流评估，且处于比较的有利端。应将其视为上限而非每个应用的保证。其核心优势仍然可信：Jev通过设计避免了长推理链和生成式输出，专为有界决策场景打造。

为何概率很重要

带类型答案只解决了问题的一半。

假设Jev将工单路由至计费部门。所选标签仅显示获胜者，而概率分布能显示竞争的激烈程度。

{
  "choice": "billing",
  "probabilities": {
    "billing": 0.52,
    "technical": 0.46,
    "sales": 0.02
  },
  "confidence": 0.18
}

自动路由该工单将是轻率之举。计费部门虽胜出但优势微弱。低置信度答案应触发不同分支。

这为开发者提供了实用模式：

• 高置信度：在后果较小时自动执行。
• 中置信度：请求确认或调用更强模型。
• 低置信度：转交人工或收集更多信息。

阈值应设置在代码中，便于审查和调整。仪表板标签可能容忍较弱预测，但删除数据的命令应要求更高标准。

TypeSafe采用校准决策强化学习训练Jev。其目标是让置信度在多次预测中反映准确率。若模型对一组答案给出90%概率，其中约90%应确实正确。

关于幻觉的声明需精确理解

TypeSafe称Jev不会产生幻觉。该表述仅在严格定义下成立。

Jev无法返回模式外的选项。若你定义了“计费“、“技术“和“销售“选项，响应不会虚构“法务”。它也不会在期望标签处生成格式错误的文本。

但它可能自信地选择错误的合法选项。

类型安全防止无效格式，但不保证判断正确。这一区分至关重要，因为符合模式的错误仍可能将款项退还错误客户、错误路由事件或批准危险命令。

更准确的表述是：“Jev不会破坏声明的输出格式，但仍可能判断错误”。

Jev在代理中的定位

Jev与大语言模型配合使用时效果最佳，而非取代后者。

大语言模型处理需要语言能力或深度推理的工作，负责规划、撰写、解释和使用工具。Jev则处理围绕这些工作的频繁决策。

三种部署方式尤为出色：

模型路由

简单查询无需与架构评审相同的模型。Jev可评估请求并选择最有可能完成任务的最低成本模型。

route = jev.choice(
    state=user_request,
    options={
        "fast": "查询、提取和小型本地编辑",
        "powerful": "架构设计、歧义处理和高风险任务",
    },
)

model = fast_model if route == "fast" else powerful_model

路由器不回答请求，而是决定哪个模型应该回答。

工具风险控制

在代理执行shell命令前，Jev可将其分类为“只读“、“可逆“或“破坏性”。独立问题可检查其是否删除文件、修改Git历史、涉及生产环境或影响代码库。

高置信度的只读操作可继续执行。破坏性或不确定操作可暂停等待人工批准。LangChain的Jev集成通过中间件在执行前检查工具调用，正是应用了这一模式。

验证与监督

代理可能声称任务完成，但测试仍然失败。Jev可检查状态并回答有界问题：测试是否通过？代理是否在重复相同操作？输出是否符合策略？该结果是否需要复核？

它不会替代现有的硬性测试，而是在规则依赖语义时增加语义检查。

Jev当前可解决的问题

最佳用例共享三个特征：你可以命名所有可能答案、谨慎的人类可快速判断输入、决策发生频率足够高以使延迟或成本值得关注。

支持与运维

• 分类意图、紧急程度、所属部门、垃圾信息及客户情绪。
• 通过系列小型检查路由退款和策略例外。
• 在人工阅读前按语义严重性对日志和事件排序。

单次请求可就同一工单提出所有问题，代码随后将答案组合成公司实际路由策略。

搜索与检索

• 根据文本是否回答查询对检索段落重排序。
• 检查引用是否支持某个主张。
• 在将上下文发送给昂贵大语言模型前过滤无关片段。

嵌入向量擅长查找语义相关文本，Jev则能做出更精细的判断：特定段落是否对该问题有用。

质量与安全

• 筛选提示词中的越狱或注入攻击。
• 对照策略或评分标准检查生成内容。
• 在执行前标记高风险代码更改或工具调用。

这些检查应与确定性控制并行。语义分类器适用于模糊风险，而权限、沙箱和测试则执行软件可精确验证的规则。

大规模分类

• 标注文档、研究论文、产品列表或客户消息。
• 将自由文本转化为传统机器学习模型的特征。
• 用相同评分标准对大型语料库中的每个项目评分。

这正是低成本调用优势超越基准数字的场景。原本因成本过高而无法对每个条目运行的判断，可融入常规数据流程。

实时界面

• 从已知页面元素中选择下一个浏览器操作。
• 在用户写作时评估语气或清晰度。
• 从结构化游戏或模拟器状态中选择操作。

Jev目前仅支持文本，因此这些系统需先将环境转换为文本或JSON。它无法查看屏幕或通过像素操作游戏。

Jev不适用的情况

一旦答案空间不再已知，Jev的价值就会降低。

• 无法撰写回复、总结文档、生成代码或解释推理过程。
• 在算术、计数、日期比较或精确字符串操作方面不可靠，应将这些操作保留在代码中。
• 当决策需要多个隐藏推理步骤时效果不佳，应将判断拆分为更小问题或使用推理模型。
• 无法直接提取未知值，应先找到候选值再让Jev选择。
• 无关上下文可能降低准确率，仅发送决策所需状态。
• 闭源权重、早期访问、仅限文本输入及有限的独立校准数据，使其尚不适合盲目信任。

更简单的规则是：如果确定性代码已正确解决问题，请保留代码。普通的if语句比任何模型都更快、更便宜、更易测试。

如何使用Jev而不引入新故障模式

廉价模型若因错误导致重试、人工审核或生产事故，总成本可能依然高昂。应评估整体工作流而非token单价。

合理的推广步骤如下：

• 选择一个答案明确的有界低风险决策。
• 在调用模型前编写评分标准，定义每个选项的归属。
• 收集具有预期答案的代表性案例，包括模糊和对抗性场景。
• 在影子模式下将Jev与现有工作流并行运行，不改变实际行为。
• 绘制准确率与置信度关系图，根据数据设置阈值。
• 首先自动化最安全的分支，对不确定案例保留人工或更强模型。
• 固定或记录模型版本、问题、标准和阈值，确保变更可基于相同评估集重放。

问题属于程序的一部分，应像对待代码一样管理：版本控制、审查，并在模型或评分标准变更时测试。

真正的转变

Jev的价值不在于写作能力超越大语言模型——它拒绝写作。

它的贡献是塑造了形如软件的模型接口：固定答案类型、显式不确定性、并行提问和代码控制的分支。

这使其成为生成模型的实用伙伴。大语言模型生成计划、解释或代码，而Jev负责路由请求、控制高风险操作、检查结果，并在不确定性较高时决定升级。

即便未来有其他模型替代Jev，这一更广泛的理念依然重要。我们多年来一直要求生成模型通过文本执行各类智能任务，但许多生产系统需要的不是更多文字，而是普通软件能安全使用的小型快速判断。

这正是Jev试图构建的品类。

入门建议

不要一开始就围绕Jev重建代理。先找出一个当前需要缓慢大语言调用或正则表达式频繁失效的决策。

为Jev提供最小必要状态，定义可能答案，并将其概率与当前结果并行记录。让它先证明自己能胜任一个分支，再交出整个工作流。

最实用的心智模型依然最简单：→ Jev在普通if语句理解数值但无法把握含义的地方增加判断力。

资源与延伸阅读

• TypeSafe AI：一型模型与Jev介绍
• LangChain：使用Jev构建测试框架
• Flavio Copes：Jev深度解析

希望你喜欢这次分享。

下次再见。

干杯！:)