JEV能做什么？一文带你搞懂JEV

摸鱼小队长 内容创作者 2026-09-25 64 阅读

先说结论

  • JEV 是 TypeSafe 的旗舰模型，属于“System One”模型：输入文本，返回 choice / score / noul 这类可直接被代码处理的结构化答案，不生成自然语言回复。
  • 它目前只吃文本；官方明确图像、音频、视频不支持。
  • 它适合高频、需要结构化输出、需要概率或置信度来做门控的场景，例如分类路由、重排、护栏、实体抽取；不适合生成、解释理由、替代确定性规则引擎。
  • 官方定价为 $42 每十亿 input tokens（官方数据）；按短文本评分任务推算，单次成本可以低到十万分之几美元级别（自己推算，见后文）。
  • 三类问题字段不一样：choice 返回 choice/probabilities/confidence，score 返回 score/legend/probabilities/confidence，noul 只返回一个 0~1 的 noul 值，没有 confidence。

先看 JEV 是什么：不是聊天模型

TypeSafe 把 JEV 定义成一个“System One model”。官方 System One 文档写了这样一句：

System One models do not write replies, produce code, or generate explanations of their reasoning.

按我的理解，JEV 更像一个部署在软件流程里的语义判断组件：你给它一个状态（state），问一系列判断题/选择题/评分题，它返回可解析的 typed answer。它和聊天模型的关键区别是输出形状固定，不给你一段话让你再解析。

官方 Primitives 页面把这种交互概括成三类“问题”：Choice、Score、Noul。官方给出的返回字段表是：

Type What it answers Returns
Choice Which of these options? choice, probabilities, confidence
Score Which level? score, legend, probabilities, confidence
Noul Is this true? noul (0 to 1)

这段话对我的意义是：在写代码前必须先想清楚问题的答案形状。想“哪个选项”就用 Choice；想“落在连续谱的哪个等级”就用 Score；想“是/否但需要概率”就用 Noul。不要反过来用。

能做的五类：逐一对应官方出处

1. 分类与路由：Choice

官方 Primitives 文档在解释 Choice 时给了一个例子：“Which team should handle this ticket?” 原文说 Choice fits when “the answer is one of a known set of options with no order between them”，比如路由到 billing、technical、account。返回字段里 choice 是选中的选项，probabilities 给出各选项概率，confidence 给置信度。这是路由场景最直接的用法。

在use-case map里，官方又把这种能力扩展到了 Customer support：“Classify incoming tickets by issue, product area, and customer intent… Route cases to the right team, queue, or automated workflow.” 这里体现的是分类后接路由。

2. 打分与排序：Score / Noul

官方 Re-ranking cookbook给了一个具体任务：用 BM25 从法律语料里召回到 30 条候选，再用 JEV 对每个 query-candidate 对打分重排。它演示的做法是用一个 Noul 问题 “Is this candidate the cited case?”，拿返回的 noul 值当分数排序。官方 cookbook 伪代码里有这样一段，我照抄字段形状：

question = Noul(
    instructions="Is this candidate the cited case?",
    criteria=NoulCriteria(
        true="The candidate states the specific rule the query cites.",
        false="The candidate is only on a similar topic.",
    ),
)
response = client.system_one(
    state={"query": query, "candidate": candidate},
    questions={"is_cited_source": question},
)
# 官方 cookbook 示例返回的字段：noul 值，范围 0~1
response.answers["is_cited_source"].noul  # -> 0.87

这个例子里 noul 只返回一个数值，没有 confidence 字段。官方当时的数据是：仅 BM25 时 top-1 准确率 5%，top-10 准确率 38%；加 JEV 重排后 top-1 升到 18%，top-10 升到 62%。这组是官方 cookbook 数据。

如果你想打分有更明确的等级标尺，可以用 Score。官方 Guardrails cookbook里把危害严重程度当作一个 Score 问题，criteria 用有序数组从“No harm”到更严重的程度。这正是 Score 的典型用途。官方 Primitives 文档对 criteria 的描述是：“an ordered list of levels for a Score”，说明它从低到高排列，不要在代码里写成无序选项。

3. 是/否判断与护栏：Noul

Guardrails cookbook 的场景是：在一个 LLM 应用前后各放一层 JEV 检查，输入输出都过一遍。官方文档说用一组 Noul 问题来检测越狱、提示注入、危险请求等，再用一个 Score 问题评估危害程度。原文是：“A battery of Noul questions hands you the probability that each hazard holds, and a Score question rates how much harm complying would do.” 但注意 Noul 官方返回表里只写 noul (0 to 1)，没有单独 confidence。这个 noul 本身可以理解为概率估计。所以我建议把 noul 值当作概率或分数来设门控，而不是去读一个不存在的 confidence 字段。

4. 结构化抽取：date extraction / entity alignment 类 cookbook

官方 Cookbooks 目录中列有 Extraction 和 Classification 类别，其中包含 Knowledge graph entity alignment 等条目。不过我在当前打开的一手页面中没有读到这些 cookbook 的完整正文，所以本节只能按导航标题和 use-case map 中的说法来理解。use-case map 里写了“Identify entities and relationships across papers to build research knowledge graphs”，以及“Extract probabilistic features from natural-language data”。这些方向属于结构化抽取：把自然语言变成有概率/分数标注的字段或关系，而不是生成一段回答。

5. 字段级验证与升级：sde_cascade

官方在 Cookbooks 目录里有一篇专门的 SDE cascade：它演示的是两段式结构化抽取级联（先用便宜的小模型抽取、再用 TypeSafe 的 primitive 做逐字段验证、只有验证不过才升级到更强的推理模型）。官方页面里给出的两档价格是 mini 档 $0.75/$4.50 与 reasoning 档 $5.00/$30.00（每百万输入/输出 token，官方数据），并注明后者约为前者的 7 倍单价。这就是”字段级验证 + 按验证信号升级”的官方做法；具体怎么算账我在另一篇里做过完整推演，这里只点出它的定位：它是成本控制模式，不是新的模型能力。

不能做的五类

1. 不生成文本

官方 System One 文档：“System One models … returns typed decisions and probabilities rather than generated text.” 这意味着你不可能让 JEV 写邮件、写总结、写对话。

2. 不写代码

同一出处说它不 produce code。所以不要把它当编程助手。

3. 不解释理由

官方同一句说它不 generate explanations of their reasoning。你拿到的只是答案和概率/置信度，没有“因为……所以……”的自然语言理由。如果需要审计到规则，这就不够。

4. 不处理图像/音频/视频

官方 System One 文档写得很明确：

Jev currently accepts text input only. It evaluates strings, JSON objects, and arrays of text. Images, audio, and video are not supported (yet).

所以多模态输入场景直接排除。

5. 不替代检索、权限或规则引擎

这点严格说是从官方定位推导来的工程判断，不是官方有一句话直接这样说。官方把 JEV 描述为语义决策组件，它不索引文档、不做 access control、不执行确定性规则。用它替代检索或规则引擎会既慢又不可审计。官方 use-case map 强调 code owns control flow，TypeSafe handles semantic decisions，说明它应该嵌在代码里做判断，而不是当数据库或权限系统用。

官方 use-case map 给的方向

官方 use-case map开头就说这是用来 brainstorm 的：“Use this map to brainstorm where TypeSafe could fit in your industry.” 也就是说这些不是成品产品，而是官方建议的方向。它给的主要几个类别引原句如下：

  • AI Automation Software：“Code owns control flow (not markdown files) while TypeSafe handles the semantic decisions and language understanding.”
  • Real-time applications：“Frontier intelligence at real-time speeds (150ms) means AI can make decisions faster than human perception.”
  • AI Map Reduce over Big Data：“100x cheaper means you can process giant datasets.” 以及 “Search for relevant information over giant corpuses, classify giant agent traces, and extract features to make predictions.”
  • Universal Verification：“Verify the input prompt, extractions, reasoning traces, tool calls, or inputs of any other AI.”
  • Harness Engineering：“Use Jev queries to make your harness smarter – model routing, semantic context retrieval, LLM error detection and guardrails, reasoning trace classification at lightspeed and a fraction of the cost.”

这些方向给我一个信号：官方把 JEV 定位成 AI 基础设施里的“判断积木”，不是最终用户产品。实际落地都要你自己写代码组合。

成本直觉：官方 $42 每十亿 input tokens

官方首页在 pricing 部分写了：

Jev.Cost $42 Per Billion input tokens.

这是官方数据。注意是“input tokens”，而且是每十亿。为了有个数量级概念，我做一次推算（自己推算，非官方）：假设一个典型的 query-candidate 打分请求 state 约 150 tokens，包含 query、候选文本和问题指令。按 $42 / 1e9 tokens，单次成本约为 $0.0000063。如果 rerank cookbook 那样 40 个查询 × 30 个候选 = 1200 次请求，总成本约 $0.0076。这个数字只是为了说明“短文本打分非常便宜”，实际成本随输入长度和模型版本变化。

官方首页还写了 “238x Lower input price than Claude Fable 5.1”，但这个对比基准我未能核实；它可能是官方营销对比，不能直接当基准。所以我这里只用 $42 这个确凿定价。

你需要它吗：三问决策树

我的判断清单是：

先问三个问题：

  1. 判断频次高吗？ 如果只是偶尔给一段文字分个类，用通用 LLM 或人工看一眼就行；如果每天要跑几十万次，JEV 的固定输出和低成本才有意义。
  2. 需要结构化输出吗？ 如果你的下游代码需要直接拿字段做路由/排序/门控，而不是拿一段话再解析，那么 JEV 合适。
  3. 需要不确定度吗？ 如果你希望“高置信直接过，低置信转人工”，那就需要 confidence 或 noul 这样的数值；否则一个确定性规则可能更可审计。

反例：

  • 低频任务：每月十几条，没必要接入。
  • 需要审计到规则：比如合规团队要求“必须能追溯到明确规则”，要选规则引擎，而不是概率模型。
  • 需要解释理由：用户或监管要求“为什么这么判”，JEV 不生成解释，你只能看到概率，得另搭解释层。

这次没核实的

  • date extraction / entity alignment 两篇 cookbook 的字段级细节：官方 Cookbooks 目录里确实有这两篇（本文已在能力方向里引用其页面链接），但它们的示例数值与完整 API 写法我没有逐项展开，需要照抄代码请直接看官方页面。
  • 官方首页的 238x lower input price、193.6x Faster、444.6x Cheaper、150ms、100x cheaper 等数字：来自官方页面，但未提供测量条件和对比基线，我按官方宣传标注，不当作严谨基准。
  • 成本推算中的 token 假设：150 tokens 是我自己的假设，不是官方数据。实际成本需按真实输入长度和所选模型重新计算。

参考来源

# 知识# 观点

评论区

0 条评论

登录后可评论。

摸鱼小队长 64 阅读