Jev 官方 AI primer：训练目标、版本边界与未披露清单

先说结论

1. 官方文档明确，Jev/System One 不是通用聊天模型：它不生成回复文本，不生成推理解释，只返回受限决策和概率分布。
2. 官方训练路径叫 RLCD，目标是让概率按结果校准；校准是“群体统计”层面的事，不是对单个答案的保证。
3. 官方已公布版本号 jev-1.13.0、输入侧价格、速率限制、上下文长度等；但参数规模、训练数据构成、训练算力、推理硬件、是否蒸馏自某个基座模型，截至写作时均未披露。
4. 官方在 jaggedness 页自述 jev-1.13 有不少“锯齿边缘”，尤其不擅长数学、计数、日期比较和间接推理；生产环境必须在自己的任务分布上分层评测。
5. 我的推断：从训练目标、输出契约和“同一套权重服务所有账号”看，它更像一个专门训练的小型判断模型，而不是拿通用 LLM 包一层；这只是基于公开信息的合理推断，不是官方结论。

官方公开了什么：一个输出概率决策的模型

官方 AI primer 的起点并不是“怎么把模型训得更会聊天”，而是明确换了一种目标。官方写道，大多数 AI 产品围绕模型与人对话展开，但 TypeSafe 押注的是：“large-scale automation will be dominated by AI-to-AI and AI-to-software interactions”，也就是大规模自动化主要发生在机器与机器、机器与软件之间。这个判断直接改变了他们对“模型应该输出什么”的定义。

官方把这种思路称为 Machine Native Intelligence。按官方原文，它指具备软件式属性的 AI：

AI with software-like properties such as structure, reliability, observability, testability, speed, consistency, and low cost.

这句话里的 7 个属性——结构性、可靠性、可观测性、可测试性、速度、一致性、低成本——基本可以理解为官方对 Jev 这类模型的验收维度。官方还进一步给出判断：“Our expectation is that large-scale AI automation will be closer to 99% machine-to-machine interactions and 1% human interaction.”【官方数据/官方表述】

这也解释了为什么官方不把“生成流畅文本”作为目标。官方原文说得比较直接：

The model does not generate text. It returns decisions and probabilities.

在 System One 页面，这个定位被继续收紧。System One 模型会评估一个 state，然后返回类型化答案和概率；它“understands natural-language input”，但不像 LLM 那样回话。官方原文写明：

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

目前 Jev 只接受文本输入，可以处理字符串、JSON 对象和文本数组；图像、音频、视频尚不支持。这个输入边界是官方逐字写明的：“Jev currently accepts text input only. It evaluates strings, JSON objects, and arrays of text. Images, audio, and video are not supported (yet).”

概率校准方面，官方 AI primer 给出的是群体频率解释，而不是单次保证。官方示例写的是：在一个校准良好的模型中，被分配到 0.2 概率的结果大约有 20% 发生，被分配到 0.8 的结果大约有 80% 发生，被分配到 1.0 的结果则 100% 发生。官方同时强调，这些比率描述的是“groups of predictions, not a guarantee about any single answer”。这一点容易被误读：校准不是给单次判断上保险，而是让软件在批量调用中可以使用不确定性。

训练路径方面，官方把 RLHF、RLVR 和 RLCD 并列成三种 post-training 路线。官方称 RLHF 训练了 InstructGPT 和 ChatGPT，目标是让人更偏好；RLVR 可以训出数学推理更强但更慢、更贵的模型；而 RLCD 训练的是“calibrated decisions”，返回决策和校准概率。官方对 RLHF 的批评也很明确：偏好优化可能奖励谄媚和听起来自信的幻觉，并导致 mode dropping。官方结论是，人类偏好和机器可信任度是两个不同的优化目标。这里的“可信任度”不是指模型道德上更可信，而是指它的输出能被软件直接检查、组合和门控。

关于命名，System One 页面说，名称来自 Daniel Kahneman 在《Thinking, Fast and Slow》中普及的概念：System 1 快而直觉，System 2 慢而审慎。官方在这里强调的是“fast, focused judgments”，而不是让模型承担完整推理链。

官方为什么这样做：机器原生智能

官方并不试图把 Jev 包装成全能引擎。相反，AI primer 里有一个小标题叫“Building prod, not God”，意思是它服务于生产系统里需要被代码检查、执行和组合的窄决策，而不是追求一个什么都能做的模型。官方原文说得更直白：

That shifts the design target from responses that feel good to read toward outputs that behave predictably inside software.

也就是说，官方把设计目标从“读起来像人的回复”转向了“在软件里行为可预测”。这个转变可以解释后面很多看似“能力退化”的设计：不要生成解释、只返回结构化结果、概率必须可阈值化、同版本模型行为要稳定。

我的理解是，这一定位对工程角度的最大好处在于可观测性和可测试性。文本生成结果很难做严格断言，但一个 Choice、Score 或 Noul 的返回值可以被记录、比较、统计、回放。不过这是我对官方目标的延伸理解，不是官方原话。

Models 页给的版本、价格和字段

官方 Models 页 是版本口径最集中的一页。当前模型名为 Jev 1.13，版本化 ID 为 jev-1.13.0。下面是官方页面给出的数据【官方数据，来源：Models 页】：

• 输入价格：$42 / Btok，即每十亿 token 42 美元；$0.042 / Mtok。
• 输出 token：免费。官方原文为 “Output tokens are free.”
• Rate limits：250,000 tokens per second；1,200 requests per minute。
• Context length：64k tokens per request；其中 state 加最长 question 为 32k tokens。
• 输入类型：仅文本，支持 string、JSON object 或文本数组。

官方还说明了别名机制。jev-latest 指向 jev-1.13.0，是当前稳定正式版；jev-preview 目前也指向同一个版本。别名会随新版本发布而移动，所以官方提醒：如果你已经针对某个版本调过 confidence 阈值，应该 pin 住版本化 ID，而不是继续使用别名。官方原文是：

If you have tuned confidence thresholds against a specific version, pin that version’s ID instead of the alias and move to the new one on your own schedule.

这一点对工程非常关键：一旦用了 jev-latest，模型行为可能在没有改代码的情况下发生变化。好在响应里的 model 字段会报告实际回答请求的版本化 ID。也就是说，你可以用这个字段做版本漂移监控。下面是一种工程上的做法：

# 示意：用响应里的 model 字段记录实际回答版本
# 官方 Models 页写明，response 的 model 字段报告 versioned ID
resp = client.system_one(state=state, questions=questions)
answered_model = resp.model  # 例如 "jev-1.13.0"

if answered_model != PINNED_MODEL:
    logging.warning("model version drifted: %s", answered_model)

这段代码是版本监控的一种实践写法，不是官方 SDK 示例。不要把“用 model 字段做监控”说成官方强制要求；官方只是公开了这个字段和别名会漂移的事实。

官方自述的短板：jaggedness 对工程的含义

Model jaggedness 页面非常值得上线前读一遍。官方不回避 jev-1.13 的问题，开头就写 “Jev isn’t perfect. Here are some jagged edges we are aware of with jev-1.13.”

官方列出的主要失败模式包括：字面阅读、数学和数字、日期和时间比较、间接推理、充满无关细节的大 state、对抗性内容、互相矛盾的指令和 criteria、需要维护常识结构不变量的任务，以及本应由生成模型承担的生成任务。其中，数学和计数的部分被官方强调得最多。官方原文直接说：

Jev is not a calculator. We strongly recommend implementing any mathematical logic in code.

计数也不被官方认为可靠。官方给出的替代方案是：不要问模型“有多少个 X”，而是用代码遍历候选，每个候选项问一个 Noul，最后在代码里求和。官方页面给出了一段示例，我按同样逻辑改写为下面这个较短版本：

# 官方 jaggedness 页示例的简化版：计数不交给模型，逐个判断再在代码中计数
from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13.0")
YES = 0.5  # 阈值视业务而定

items = ["typesafe", "apple", "california", "banana"]
result = client.system_one(
    {"items": items},
    {
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)
count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

这里有两个点容易被误解。第一，“每个候选项各发一个问题”是官方 jaggedness 页给出的替代做法，不是通用万能模式；它适合官方示例里的计数场景。第二，阈值 0.5 是官方示例里出现的值，但它不是一个普适阈值；不同任务、不同成本结构应该自己重设。

官方在 Models 页还提到，Jev 会一次读取 state，并行评估所有 questions。这意味着对于同一批 state 上的多个原子判断，通常不应拆成大量串行往返。这是官方页面写明的行为，但对具体业务是否都适合批量发，仍要自己测试。

对工程来说，更重要的不是记住每一项 jaggedness 细节，而是接受一个事实：模型能力在任务分布上是不均匀的。官方在 jaggedness 页面给的是已知短板列表，但没有替你定义“你的业务是否踩中这些短板”。所以我的判断是：上线前应在自己的任务分布上做分层评测，至少按“是否涉及数字/日期/计数/间接推理/长 state/对抗样本”等维度拆开看准确率和 confidence 分布，而不是只盯一个整体准确率。分层评测是自己的实践建议，不是官方文档列出的正式流程。

未披露清单

以下是截至写作时，在官方 AI primer、System One、Models、Model jaggedness、Confidence 页面中没有看到的信息：

• 参数规模：未披露。官方只说由 RLCD 训练，同一套权重服务所有账号，没有给出参数数量。
• 训练数据构成：未披露。官方只说 English 是主要训练语言，其他语言包括 CJK 处理得不够好；没有给出语料来源、配比、去重方案。
• 是否蒸馏自某个基座模型：未披露。官方没有说 Jev 是否从某 LLM 蒸馏而来。
• 训练算力：未披露。没有 GPU 卡数、训练时长、训练框架或能耗数据。
• 推理硬件：未披露。官方只说 rate limits 可能随“large GPU deals”到位而动态调整，但没有具体硬件型号或集群规模。
• 输出计费口径：官方 Models 页写的是输入 token 计费、输出 token 免费。这可以视为已披露为免费，但官方没有给出输出侧独立价格表，也不会承诺免费策略长期不变。不能把这个 policy 外推为永久承诺。

这些不是“推理出来应该是多少”，而是“未能核实”。不要用任何论坛数字去填这些空。

我的推断与依据

第一个推断：Jev 更像专门训练的小型判断模型，而不是把通用 LLM 包一层。
【我的推断，非官方结论】
依据有三点：第一，官方 AI primer 把 RLCD 作为与 RLHF、RLVR 并列的 post-training 路径，而不是把某个 chat 模型加 adapter；第二，System One 页面给出的是完全不同的输出契约——不生成文本、不解释推理、只返回决策和概率；第三，Models 页明确说 Jev 不用客户数据微调或 LoRA 适配，“the same weights serve every account”。这些信息加在一起，让我倾向于认为它不是“LLM 套壳”。但参数规模未披露，所以“小型”只能算合理猜测，不能写成官方结论。

第二个推断：Jev 更适合低间接层级、明确 criteria 的判断，不适合需要计算或深层推理的任务。
【我的推断，非官方结论】
依据是官方 jaggedness 页列出的 failure modes。官方已经说明它在数学、日期比较、间接推理上不可靠，那就意味着工程上应该把这些部分移出模型边界，交给代码。这个判断可以指导架构：模型负责语义判断，计算和约束校验放在代码里。

第三个实践建议：版本治理上，不要长期依赖 jev-latest。
【工程做法，不是官方推荐流程】
官方 Models 页写了别名会漂移，响应会带实际版本 ID。因此，如果系统已经基于某个版本调好阈值，最好 pin 住 jev-1.13.0，同时记录响应里的 model 字段，以便发现版本漂移后重新回归。具体怎么监控、怎么告警，是团队自行落地的事。

这次没核实的

• 官方 AI primer 页面提到的 “TypeSafe manifesto” 的具体内容未能核实；来源正文只给了一句话，没有附上全文。
• Confidence 页面提到未来会补一篇专门讨论 confidence 计算方式的 cookbook，但截至写作时未核实该 cookbook 是否已发布。
• Models 页提到 rate limits 会随 GPU 供应动态调整，后续稳定值和新的企业限制未能核实。
• jev-preview 何时与 jev-latest 分离、何时出现 preview build，未能核实。
• 官方未公开的参数规模、训练数据、训练算力、推理硬件、是否蒸馏等信息，均未能核实具体数值。

参考来源

• 官方 AI primer（训练目标与方法论）
• 官方 System One
• 官方 Models 页
• 官方 Model jaggedness
• 官方 Confidence