Jev vs LLM：决策模型在哪些场景更有优势，哪些场景不是

这不是一个"谁更好、谁更差"的问题

Jev 和 LLM 回答的是不同的问题。Jev 回答的是哪一个、多少，或者有多可能；LLM 回答的是应该写什么。

	Jev	生成式 LLM
输出	带类型的答案，每个选项附带概率，并有一个置信度值	文本，可选地约束为 JSON schema
计费基础	仅输入 token；输出免费	输入 + 输出 token
延迟形态	一次前向传播；多个问题基于同一状态并行展开	token 顺序生成；推理模型还会增加一次漫长的隐藏推理
置信度	一个经过校准、可用于设定阈值的数值	通常没有，或只是一句自我陈述
Schema	由构造保证匹配	一直匹配，直到模型自己决定不匹配
可接受的输入	仅文本和结构化状态，不支持图像	文本；多模态模型还支持图像
胜出场景	窄口径、大批量的判断	生成、推理、解释、算术

一旦你不再需要输出文本，账本就变了。一个分类形态的任务，如果每个条目都要产出二十个 token 的散文文本，那它就是在为每一个条目的这些 token 永久付费。

准确率问题：用真实数字说话

营销式对比通常拿某家厂商最爱的基准去比另一家表现最差的基准。我们找到的最有价值的已发表测试是 Emil Lindfors 的抢先体验文章 An early-access test of TypeSafe's Jev，测试对象是挪威 2022 年关于鲑鱼养殖资源租税听证会的 24 份意见。

他先用 Claude Fable 5.1 通过两轮独立标注为所有内容打标签，然后通过 OpenRouter 将 Jev 1.13 与 DeepSeek V4.1 Flash 对比——同一个提示词中提出相同问题，输出 JSON，分别开启和关闭推理各跑一次。

任务	Jev 1.13	DeepSeek，关闭推理	DeepSeek，开启推理
立场，4 个选项	24 份中 20 份	24 份中 20 份	24 份中 22 份
受访者类型，6 个选项	23 份中 21 份	23 份中 22 份	23 份中 23 份
论点，192 项是/否	0.86	0.89	0.88
实质内容，精确等级	24 份中 19 份	24 份中 14 份	24 份中 14 份

这张表有两点值得读出来。第一，作者明确指出，这些数字是与一个前沿模型标签的一致率，而非正确率——当参考标签错误而 Jev 正确时，Jev 仍会被记为错误。在 24 份文档的规模下，立场数字的 95% 区间约为 ±15 个百分点，因此在立场和论点上三列实质相同。第二，唯一明确的胜出在有序列 Score 上，19 对 14：这正是这一原语做它被设计来做的事，也是纯文本答案根本给不出的结果。

任何基于这一证据宣称决策模型在类别上比 LLM 更准确的人，都是在过度解读一个 24 份文档的样本。有趣的论断是那个更窄的论断。

成本问题

同一测试给出了每 1,000 份文档的成本：

	Jev 1.13	DeepSeek，关闭推理	DeepSeek，开启推理
每 1,000 份文档成本	$0.22	$1.31	$3.08
中位延迟	0.32 s	2.7 s	26 s
最慢请求	1.3 s	17.9 s	250 s

约为两种 LLM 配置的六分之一和十四分之一，中位延迟约为其八分之一和八十分之一。作者自己对原因的总结：放弃文本生成正是价格能降这么多的原因，而那些推理 token 只换来了 24 份中多 2 个立场标签，代价是十倍的延迟。

这只是一个工作负载、一种语言、一天的数据。你的数字会不同——单是分词器效率就会让数字变化。同一篇文章测得 Jev 的分词器在挪威语上约为 每 token 2.06 个字符，而英语通常可假定约为每 token 4 个字符，这把可用的状态预算从大约 120,000 个字符削减到约 64,000 个。

校准才是真正的差异所在

这一部分决定你能否实现自动化。一个准确率 86%、并且知道自己错在哪 14% 的模型，与一个准确率 88%、但对所有事听起来同样确定的模型，是不同的工具。

来自同一次运行，在 192 项论点判断上：

Jev 声明的概率	判断数量	参考标签一致
0.0 – 0.1	14	0%
0.1 – 0.3	56	4%
0.3 – 0.7	41	34%
0.7 – 0.9	38	97%
0.9 – 1.0	43	98%

每一步的方向都是对的，而模型在两端都略显欠自信——TypeSafe 自己的目标是：被赋予 0.8 的结果应在约 80% 的情况下发生，而中间分箱落在 34%，而非约 50%。

这张表的实用版本就是一个阈值。按最高概率切分选择类问题：

	最高概率 ≥ 0.9	低于 0.9
立场	15 份中 14 份一致	9 份中 6 份一致
受访者类型	20 份中 20 份一致	3 份中 1 份一致

这就是运行模式：接受有把握的多数，把其余的上抛升级处理。 TypeSafe 自己的 SEC 文件 cookbook 报告，在英语中 30 份里有 27 份在 0.9 或以上时是正确；挪威语那次得到的是 15 份中 14 份。

这个对比是单向的。开启推理时，DeepSeek 把 192 个论点答案中的 84 个标到 0.9 以上——而在 0.7–0.9 区间，它的标签与参考一致的时间只有 48%。一个置信度未经校准的模型不能用作闸门，无论它的答案有多好。

什么情况下 LLM 仍是正确选择

• 生成。 Jev 不会写摘要、回复或 commit message。TypeSafe 自己的文档把生成任务交给生成式模型。
• 推理与多跳问题。 TypeSafe 将间接表达列为已知弱项：带双重否定或需要多跳的问题会损失准确率。
• 算术、日期和计数。 已被记录为不可靠，而且被计数的对象越大，误差越大。把它们留在代码里。
• 图像和音频。 Jev 仅支持文本。在 TypeSafe's Jev Can't See. I Made It Guess What I Drew Anyway 中，Bartosz Mikulski 把 400 幅草图转换成 SVG 坐标字符串，让 Jev 说出它们的名字。它明显超过了十分之一的随机基线，但输给了 Claude Sonnet 5，并且对超过一半的图都回答了 "airplane"。同样的内容编码为 base64 后则只落在随机水平——这提醒我们，一个读数字的文本模型是把数字当文本读的。
• 任何需要解释的场景。 "你为什么把这个标成那样" 不是概率能回答的问题。

TypeSafe 的创始人在 LLM 这一侧提出了一个相关论点，值得了解，因为它正好反驳了一种常见的变通做法：在发布帖中，他主张 OpenAI 风格结构化输出所用的那种受约束解码会让模型变笨，因为屏蔽无效 token 并不等于模型对这些 token 不困惑。请把这当作厂商立场而非定论——但它确实意味着"直接从廉价模型里强行逼出 JSON"并不自动等同于一个带类型的答案。

有效的组合模式

那篇挪威测试文章中最有用的结论是：这个选择不是非此即彼。作者自己的项目对三类工作用了三个模型：

工作	模型	原因
48 个需谨慎处理的参考标签	Fable 5.1	文档少、涉及判断取舍、成本无关紧要
每份文档、每个问题	Jev	低成本、快速，并且会说明自己何时不确定
对不确定的那三分之一给出第二意见	DeepSeek 或人工	更慢也更贵，所以只用在需要的地方

今天你就能用一把 OpenAI 兼容的 key 跑出这种形态：用低成本档做第一遍，只在第一遍无法定论的情况下才用更强的档：

1. 用能过你这条线的最便宜档做第一遍。 gpt-5.6-luna 为每 1M token $0.022 / $0.134，或 glm-5.3-flash 为 $0.105 / $0.35，或 deepseek-flash 为 $0.15 / $0.60。
2. 在提示词中把决策约束到封闭集合内，并同时要求给出置信度分数。把这个分数当作提示，而不是校准过的概率——这正是决策模型能填补、而提示工程填补不了的缺口。
3. 只把低于阈值的部分上抛升级。 gpt-5.6-sol 从 $0.297 / $1.781 起，覆盖 19 条路由；或 gemini-3.8-flash 从 $0.20 / $1.00 起，覆盖 7 条。
4. 把算术、日期和计数留在你自己的代码里，两个档都如此。这样更便宜，而且是对的。
5. 在放量之前先测你自己的一致率。 五十个手工标注的条目告诉你的信息，比任何基准表格都多，包括这一张。

这种模式的经济学，正是"路由"作为一个品类存在的理由：几乎所有的量都落在第一遍上，而几乎所有的质量都来自上抛那一档。你只需要对无法分类的少数使用第二档。

创建 APIMaster 账号，从 $1 起充值按量付费额度，在控制台创建 key，并把 OpenAI 兼容客户端指向 https://apimaster.ai/v1，使用上文任一模型 ID。一把 key 即可覆盖 GPT、GLM、DeepSeek、Gemini 和 Claude 系列，所以上抛路径仍保持在同一套集成上。在把生产流量切过去之前，先用模型测试器验证一条路由。

FAQ

Jev 是语言模型吗？ 不是。TypeSafe 将其描述为一种结构化数据模型，创始人在发布帖中的原话是它"在技术上不是语言模型（它不生成语言）"。它读取文本并返回决策。

Jev 比 LLM 更准确吗？ 根据已发表的证据，没有可测量的优势。在一项 24 份文档的挪威语测试中，Jev 与 DeepSeek V4.1 Flash 在立场和论点问题上与参考标签的一致率相同。Jev 在其中一项有序量表任务上明显领先。

Jev 比 LLM 便宜吗？ 按任务算，是的——不是按输入 token 算。Jev 每 1M 输入 token 的 $0.042 在输入侧被 $0.022 的 gpt-5.6-luna 压过，但 Jev 完全不输出 token，而生成式模型的输出是要计费的。在已发表的工作负载中，这算下来是每 1,000 份文档 $0.22，而对手为 $1.31 和 $3.08。

什么是 "LLM as a judge"，它有何不同？ LLM-as-a-judge 指的是让生成式模型对某物打分或打标签，再从它的文本里读出答案。这方法可行，但你要为文本付费、要等 token 生成，而且拿回来的置信度不是校准过的概率。决策模型会把同样的判断作为一个可以设阈值的带类型答案返回。

我能不能干脆从廉价模型中强行逼出 JSON 输出？ 它能给你 schema，但给不了校准。受约束解码让输出可解析；它不会告诉你该怀疑哪些答案，而且 TypeSafe 主张，它可能因为屏蔽掉模型真正不确定的 token 而降低质量。

分类任务该用哪一个？ 如果你只做少量判断、准确率就是一切、而且你能人工复核，那么一个好的 LLM 就够了。如果你要做大量判断并且需要自动化，就用任何能返回可用置信信号的方案，并把不确定的那些上抛升级。

Jev 能处理非英语文本吗？ 可以，但有前提。TypeSafe 表示英语的准确率最高，包括 CJK 在内的其他语言也能处理，但效果并不相同。上文的挪威语测试发现它能正确读取扫描的议会会议记录，同时也测得分词器效率约为每 token 2.06 个字符——在围绕上下文上限做规划之前，值得先在你自己的语言上测一测。

Jev 能看图吗？ 不能。它仅支持文本。把图像转成文本再问 Jev，可能超过随机水平，但会明显输给真正能看图的模型。

Jev 在 APIMaster 上可用吗？ 尚未开售——Jev 正在 APIMaster 上做接入，等集成上线后本页会更新。这个对比中另一侧的模型现在就可以用。

第一遍该从哪个低成本模型开始？ 按每 1M token $0.022 / $0.134、覆盖 3 条路由来看，gpt-5.6-luna 是市场上最便宜的档——也是本文表格中输入和输出费率最低的。glm-5.3-flash 的 $0.105 / $0.35 和 deepseek-flash 的 $0.15 / $0.60 是往上的下一步。在放量承诺之前，先在你自己的数据上测。

资料来源与延伸阅读

• Emil Lindfors — An early-access test of TypeSafe's Jev — 24 份挪威语听证文档，Jev 对比开启与关闭推理的 DeepSeek V4.1 Flash，含逐任务一致率、校准分箱、成本与延迟
• Bartosz Mikulski — TypeSafe's Jev Can't See. I Made It Guess What I Drew Anyway — 400 幅草图转为坐标字符串、随机基线，以及与 Sonnet 5 的对比
• TypeSafe — Models — 模型 ID、$42/Btok 定价、速率限制、上下文预算与语言支持
• TypeSafe — Jev 1.13 jaggedness — 已发布的范围说明，涉及字面阅读、算术、日期、间接表达与生成
• TypeSafe — Introducing System One Models and Jev — 70–500ms 端到端数字与 40×–200× 的对比
• Hacker News 发布帖 — 创始人对 Jev 不是什么、受约束解码，以及输出为何免费的评论

第三方测试结果按作者发表时的原样转载；两位作者均未因撰写文章获得报酬，也未审阅本页。APIMaster 路由价格读取于 2026 年 9 月 20 日。Jev 在 APIMaster 上的接入正在进行中，本页将随进展更新。