JEV是什么？

早八人技术创作者 2026-09-23 49 阅读

先说结论

Jev 是 TypeSafe AI 的旗舰模型，也是官方所称的第一个 System One 模型；你发过去“状态 + 类型化问题”，拿回来代码可直接消费的结构化答案，它不生成自然语言文本。
与聊天模型根本不同：官方原话说 System One models “do not write replies, produce code, or generate explanations of their reasoning”；它返回 typed decisions and probabilities。
三种问法：choice 选一个选项；score 按有序等级打分；noul 回答是/否并返回 0~1 概率，noul 没有 confidence 字段。
关键事实卡：官方 API 端点 POST https://api.typesafe.ai/v1/systemone，模型名 jev-latest，定价 $42/十亿 input tokens，限流 250,000 tokens/秒与 1,200 请求/分（官方 models 页，动态调整）。
诚实边界：不聊天、不写代码、不解释理由，只吃文本（官方明确不支持图像/音频/视频）。

证据与过程

一、官方如何定义 Jev 和 System One 模型

官方 System One 概念页的第一句就写得很直接：

Jev is TypeSafe’s flagship model and the first System One model.

翻译过来：Jev 是 TypeSafe 的旗舰模型，也是第一个 System One 模型。这不算营销话术，而是官方文档对它的基础定位。同一页还给 System One 模型下了一个定义：

System One models are a class of AI models built to make fast, structured decisions that software can use directly. A System One model evaluates a state and returns typed answers and probabilities.

也就是说，它理解自然语言输入，但输出不是一段话，而是“类型化答案”和“概率”。这跟 LLM 的核心差异就在输出的消费方式上：LLM 生成的文本给人看，Jev 生成的字段给代码用。

二、它和聊天模型最根本的区别

官方在 System One 概念页用了一句非常像排除法的原话：

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

不写回复、不生成代码、不解释推理过程。这句话基本划掉了聊天模型最常做的三件事。它的价值不在“表达”，而在“判断”。你通过 primitives 定义可能的答案空间，它返回限定值域内的结构化结果。

官方甚至借用了丹尼尔·卡尼曼《思考，快与慢》中的 System 1 / System 2 命名逻辑。System 1 快而直觉，System 2 慢而审慎。Jev 这类 System One 模型强调的是快而聚焦的判断，不是慢推理。

三、三种问法：Choice / Score / Noul

官方 Primitives 页面把三种问题类型和返回字段都列清楚了。这里直接做一个简表，字段形状不要记错：

类型	回答什么	返回字段
Choice	哪一个选项？	`choice`, `probabilities`, `confidence`
Score	哪个等级？	`score`, `legend`, `probabilities`, `confidence`
Noul	是否成立？	`noul` (0 到 1)

三个特别容易踩坑的点：

Choice 的 criteria 是一个选项映射，比如 {"billing": "Payment or subscription issues", "technical": "Bugs or integration problems"}。
Score 的 criteria 是有序数组，从低到高。例如“冷静 → 沮丧但礼貌 → 非常愤怒”。
Noul 只返回一个 noul 值，范围 0~1。官方表格里没有 confidence，也没有 probabilities。如果你的代码里给 Noul 结果读 confidence，会直接读到空气。

下面是一个最小调用示例，改编自官方 Quick start：

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()
ticket = "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing."

response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

print(response.answers["department"].choice)
print(response.answers["frustration"].score)
print(response.answers["is_urgent"].noul)

官方 Quick start 示例中，三个输出分别对应 "technical"、1.0、1.0。这里的 noul 就是 0~1 的浮点数，没有任何额外字段。

四、关键事实卡：端点、模型名、价格、限流

以下是官方数据，来源为 Models 页面和官方首页。

项目	官方数据
API 端点	`POST https://api.typesafe.ai/v1/systemone`
模型名	`jev-latest` 是官方别名，当前指向 `jev-1.13.0`
定价	$42 / 十亿 input tokens；输出 token 免费（官方首页写 `$42 Per Billion input tokens`）
限流	250,000 tokens/秒，1,200 请求/分
上下文长度	64k tokens/请求；其中 state + 最长问题不超过 32k tokens
输入类型	纯文本；支持字符串、JSON 对象、文本数组；不支持图像/音频/视频

官方 Models 页明确写了：

Rate limits are adjusting dynamically. … the limits above can change without notice while we do.

所以限流数字是官方在某个时间点给出的值，但官方自己声明会动态调整。把它当成硬保证会踩坑。实际上线前，最好再用 GET /v1/models 或官方文档复核一次。

五、它不能做什么

边界很清晰，而且基本都来自官方原句。

第一，不聊天。官方首页直接用了“not chat”的表述，System One 模型不是对话模型。
第二，不生成回复、不写代码、不解释理由。上面已经引过原话。
第三，只吃文本。官方 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).

第四，不能通过微调来私有化定制。官方 Models 页面说明：

Jev is not fine-tuned or LoRA-adapted with customer data. It is trained with RLCD to return calibrated decisions, and the same weights serve every account.

也就是说，你能定制的是请求内容，而不是模型权重。领域知识要放进 state、instructions 和 criteria 里。

六、我的判断：你是否需要它？

官方首页提到，Jev 的用法是“Set the thresholds for when it acts autonomously and when it asks for review”。但具体阈值是多少、怎么验证，属于工程实现层面的事，不是官方文档写死的 API 参数。下面这张三问清单是我的判断，不是官方建议：

是否高频？
如果你只是偶尔需要做一次分类或判断，聊天模型完全可以覆盖。Jev 更适合每天有大量自动决策路径、且人工复核成本高的场景。官方没有给出硬性频率门槛，但我的可操作标准是：至少每天几千次自动判断，而且你不想为每一次都写 prompt 或调 LLM。
输出是否需要结构化？
如果你的下游是代码分支、数据库枚举字段、API 参数，需要稳定类型和固定值域，那么 Jev 的 typed outputs 有优势。如果输出只是给人看，聊天模型更灵活，没必要换。
是否需要不确定度？
官方文档说 System One 模型的答案包含 confidence，你可以在高置信时自动放行、低置信时升级到人工或推理模型。但如果你的流程只需要一个最终标签，不需要概率分数，那 confidence 字段也不会被用上。

三个问题都是“是”，才值得深入看 Jev。否则，它更可能是一个看起来便宜、但用不上的新组件。

这次没核实的

官方首页出现过 “193.6x Faster, 444.6x Cheaper” 和 “238x Lower input price than Claude Fable 5.1” 等对比性宣传数据，但其底层基准工作负载和公平性条件未能核实。
官方 Models 页说 CJK 脚本能处理但准确度不如英文，建议自己测试。本文未提供中文场景的实测数据。
限流数字虽然来自官方 Models 页，但官方声明会动态调整，发布后可能已经变化。
本文基于官方文档和 Quick start 示例写作，没有在真实业务中压测 Jev 的延迟和稳定性。

参考来源

# 知识 # 资讯

评论区

0 条评论

登录后可评论。