Jev’s Architecture Unmasked 揭秘 Jev 的架构

X is full of hot takes about Jev’s launch, and most miss the point entirely: “12 million views for a JSON classifier? Yeah, we’re in a bubble.” An ordinary LLM generates “90% confident” as text; its probability of producing those words does not establish a 90% probability of being right. Yet we build fraud screening, moderation, routing and risk assessment around precisely this pattern: paying for token-by-token generation, then treating an unvalidated confidence claim as a probability our software can act on.X 上充斥着关于 Jev 发布的热门评论，但大多数都完全抓不住重点：“一个 JSON 分类器竟然有 1200 万次观看？没错，我们正处于泡沫之中。”普通大语言模型（LLM）生成的文本中会包含“90% 的置信度”；其生成这些词的概率并不代表它有 90% 的正确概率。然而，我们却围绕这种模式来构建欺诈筛选、内容审核、路由和风险评估系统：支付逐个 token 生成的费用，然后将一个未经校验的置信度声称视为软件可以据此行动的概率。

Jev’s proposition is to retain the knowledge of a pretrained LLM while replacing generated confidence claims with decision probabilities read directly from its internal representations. Those probabilities are trained against outcomes. Give it shared state, questions, and allowed answers; it returns the distributions in parallel, without generating text.¹ For this whole class of applications, that addresses both problems: the reliability of the decision signal and the unnecessary computation spent producing it.Jev 的主张是保留预训练 LLM 的知识，同时用直接从其内部表示中读取的决策概率来取代生成的置信度声称。这些概率是针对实际结果进行训练的。只需向它提供共享状态、问题和允许的答案，它就能并行返回分布结果，而无需生成文本。对于这一整类应用，这解决了两个问题：决策信号的可靠性以及为生成该信号而耗费的不必要计算资源。

Theres just one problem, its not open weight, and TypeSafe refuses to share their research… So I will (try my best).只有一个问题，它不是开源权重的，且 TypeSafe 拒绝分享他们的研究……所以我将（尽我所能）尝试揭示它。

The evidence points toward a causal transformer (likely using sparse MoE) repurposed for decisions: shared-state encoding, isolated question branches, and direct probability readouts instead of text generation. After probing the TypeSafe API (looking for signatures in latency scaling under different context lengths, question reordering, etc.), scouring any public documentation and research with Astra, and looking for prior art, I think I have a fairly accurate model of how it works and its architecture.证据指向一个因果 Transformer（很可能使用了稀疏专家混合模型 MoE），它被重新用于决策任务：共享状态编码、独立的问题分支，以及直接读取概率输出而非生成文本。在探测 TypeSafe API（寻找不同上下文长度下的延迟缩放特征、问题重排序等）、用 Astra 搜寻所有公开文档和研究，并寻找现有技术后，我认为我已经对它的工作原理和架构建立了一个相当准确的模型。

The sparse backbone is the least certain part, but its particularly beneficial for this domain with less downsides than AR LLMs, so would be weird if it wasn’t . Shared computation and direct probability outputs are much better supported obviously. This is clearly all quite speculative, so I’ll try and be as clear as possible around what evidence was published by TypeSafe, what was observed in experiments, and whats inferred from them. Black box APIs make it shockingly easy to throw a blanket over the ghost and get a rough shape of what the architecture looks like.稀疏骨干网是最不确定的部分，但它对这一领域特别有利，且比自回归（AR）LLM 的缺点更少，如果不是这样才显得奇怪。共享计算和直接概率输出显然得到了更好的支持。这显然都是相当推测性的，所以我将尽量明确哪些证据是 TypeSafe 公布的，哪些是在实验中观察到的，哪些是从中推断出来的。黑盒 API 让给这个“幽灵”盖上一层布并勾勒出其架构的大致轮廓变得出奇地容易。

Why this design is useful¶为什么这种设计有用

Consider a schematic support-routing request. This illustrates the API’s structure; the example probabilities below are invented.考虑一个示意性的支持路由请求。这展示了 API 的结构；下方的示例概率是虚构的。

{
  "state": "My payouts have failed three times. The bank says everything is fine. Can someone please fix this?",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "payments": "Payout failures and payment processing",
        "account": "Login and account access",
        "other": "Something else"
      }
    },
    "escalate": {
      "type": "noul",
      "instructions": "Does this message require urgent human attention?"
    }
  }
}

A useful answer might assign payments 0.91 probability while assigning urgent escalation only 0.42. Those are different uncertainties. Software can route the ticket automatically while leaving escalation to a separate policy.一个有用的答案可能会给“付款”分配 0.91 的概率，而给“紧急升级”仅分配 0.42 的概率。这些是不确定性程度的不同。软件可以自动路由工单，同时将升级处理留给单独的策略。

A causal transformer already knows how to construct a representation of text from left to right. During ordinary language-model inference, it processes the prompt, predicts one token, feeds that token back in, and repeats. This builds on the decoder attention and output projection introduced in the original Transformer.³ But the prompt-processing stage has already produced a rich representation. If the task is to choose among three queues, we can attach a small function that maps that representation directly to three numbers.因果 Transformer 已经知道如何从左到右构建文本表示。在普通的语言模型推理过程中，它处理提示词，预测一个 token，将该 token 反馈回去，然后重复此过程。这建立在原始 Transformer 引入的解码器注意力和输出投影之上。但提示词处理阶段已经产生了丰富的表示。如果任务是在三个队列中进行选择，我们可以附加一个小型函数，将该表示直接映射为三个数字。

A detail here resolves much of the confusion about parallel answers: causal attention describes which positions can use which information, not the order in which input tokens must be executed. During prompt processing, or prefill, every input token is already known. The model can process their positions together within a layer while the attention mask blocks access to later positions; the layers still run sequentially. Autoregressive decoding adds another dependency: the next token does not exist until the previous prediction has been chosen. Our proposed model ends after prefill and the readout, so it avoids that token-by-token dependency.此处的一个细节解决了关于并行答案的大部分困惑：因果注意力描述的是哪些位置可以使用哪些信息，而不是输入 token 必须执行的顺序。在提示词处理或预填充（prefill）阶段，每个输入 token 都是已知的。模型可以在层内一起处理它们的位置，同时注意力掩码会阻止对后续位置的访问；各层仍然按顺序运行。自回归解码增加了另一种依赖：在选择前一个预测结果之前，下一个 token 不存在。我们提出的模型在预填充和读取后结束，因此避免了那种逐个 token 的依赖。

This changes the computational shape of the task. The output no longer needs a sequence of spelling decisions for "payments": 0.91. JSON formatting happens in ordinary application code. The neural network supplies the probabilities.这改变了任务的计算形态。输出不再需要一系列关于“付款”的拼写决策：0.91。JSON 格式化在普通的应用程序代码中完成，神经网络提供概率。

Now suppose the state is a lengthy incident report, and there are fifty questions. Most of the input is shared. A transformer stores intermediate information about processed tokens in its key–value cache, usually shortened to KV cache. In the proposed design, every question reads the same state cache. Each branch adds only its own instructions and answer options.现在假设状态是一份冗长的事故报告，并且有五十个问题。大部分输入是共享的。Transformer 通常将其关于已处理 token 的中间信息存储在键值缓存（KV cache）中。在拟议的设计中，每个问题都读取相同的状态缓存。每个分支只添加自己的指令和答案选项。

For a state of $S$ tokens and $Q$ questions, separate requests would process the state roughly $Q$ times. Sharing reduces the repeated state-token processing from $QS$ to $S$. The questions still have to attend to the state; that work does not disappear. But the model need not repeatedly reconstruct the state’s representations.对于 SSS 个 token 的状态和 QQQ 个问题，单独的请求将处理状态大约 QQQ 次。共享将重复的状态 token 处理从 Q×S 减少到 S。问题仍然必须关注状态；那部分工作不会消失。但模型不需要反复重建状态的表示。

Isolation also gives the interface a useful meaning. Asking whether the customer is angry should not change which queue receives the ticket. Both questions can inspect the same evidence without reading each other’s instructions. The branches have no computational dependency on one another, even when their answers are statistically related.隔离也赋予了接口有用的含义。询问客户是否愤怒不应改变工单进入哪个队列。两个问题可以在不阅读对方指令的情况下检查相同的证据。即使答案在统计上相关，这些分支在计算上也没有相互依赖关系。

Finally, probabilities make downstream policy explicit. If an unnecessary escalation costs one unit and a missed urgent case costs nine, a simplified decision rule escalates when $p(\text{urgent}) > 0.1$. That calculation is meaningful only to the extent the probabilities are reliable for this workflow. Training and evaluating the probability distribution therefore becomes part of the product, rather than a cosmetic confidence field.最后，概率使下游策略变得明确。如果一次不必要的升级成本为一个单位，而一次漏掉的紧急案例成本为九个单位，那么简化的决策规则会在 p(urgent) > 0.1 时进行升级。该计算只有在概率对该工作流可靠时才有意义。因此，训练和评估概率分布成为了产品的一部分，而不是一个装饰性的置信度字段。

None of this requires diffusion. Parallel classification has existed for decades. The interesting combination is a broadly capable transformer, shared contextual computation, a typed output interface, and training that rewards useful uncertainty.这一切都不需要扩散模型。并行分类已经存在了几十年。有趣的是将功能广泛的 Transformer、共享上下文计算、类型化输出接口以及奖励有用不确定性的训练结合在一起。

1. End inference with a readout¶1. 以读取层结束推理

The first component is the simplest: a prediction head instead of a decode loop.第一个组件最简单：使用预测头而不是解码循环。

Published evidence. TypeSafe’s launch announcement says: “Jev outputs all probabilities in parallel instead of autoregressively generating by token.” Its documentation exposes finite choices, yes/no decisions, and ordered scores. These are naturally represented by fixed numerical outputs.¹²已发布的证据。TypeSafe 的发布公告称：“Jev 并行输出所有概率，而不是自回归地按 token 生成。”其文档展示了有限的选择、是/否决策和排序分数。这些自然地由固定的数值输出表示。

Observed evidence. The API still reports an output_tokens field, which sounds like a record of generation. It isn’t one. For yes/no questions, the count fits exactly: 4 shared tokens, plus 15 per answer, plus the token length of each question’s identifier. TypeSafe’s documentation says that identifier “is not sent to the underlying model and is not used in inference.” A count that changes with text the model never sees is calculated after inference, from the serialised response. The returned values don’t affect it either: an answer of 0.0 costs the same as 0.01, although each digit otherwise counts as a token.²²⁴观察到的证据。API 仍然报告一个 output_tokens 字段，听起来像是生成的记录。但事实并非如此。对于是/否问题，计数完全吻合：4 个共享 token，每个答案 15 个，加上每个问题标识符的 token 长度。TypeSafe 的文档称该标识符“不会发送给底层模型，也不会用于推理”。一个随着模型从未见过的文本而变化的计数是在推理之后，从序列化响应中计算出来的。返回的值也不会影响它：0.0 的答案与 0.01 的成本相同，尽管每个数字在其他情况下都算作一个 token。

The tokenizer behind the count doesn’t match any of the 192 public tokenizers we tested. It does match Jev’s own input counter for ordinary text, differing only on long runs of whitespace and punctuation. output_tokens is a billing figure. It tells us nothing about whether Jev generates text, and wouldn’t measure that text even if it did. Latency doesn’t track that figure either: a question with 200 options (1,911 output tokens) returned as quickly as one with two, and server time grew only with input length.²⁴²⁵该计数背后的分词器与我们测试的 192 个公共分词器都不匹配。它确实与 Jev 自己用于普通文本的输入计数器匹配，仅在长段空白和标点符号上有所不同。output_tokens 是一个计费数字。它没有告诉我们 Jev 是否生成文本，即使它生成了，也不会测量该文本。延迟也不跟踪该数字：拥有 200 个选项（1,911 个输出 token）的问题返回速度与拥有两个选项的问题一样快，服务器时间仅随输入长度增加。

A 255-option response reported 2,714 output tokens.⁴ It would be a mistake to divide that number by request duration and call the result the model’s decoding speed. A server can serialize thousands of characters after a single model evaluation. The accounting field does not tell us how many neural decoding steps occurred.一个 255 个选项的响应报告了 2,714 个输出 token。将该数字除以请求持续时间并称之为模型的解码速度是错误的。服务器可以在单次模型评估后序列化数千个字符。该计费字段没有告诉我们发生了多少次神经解码步骤。

The proposed readout takes a final hidden vector $h$ and produces logits:拟议的读取层采用最终隐藏向量 h，并产生 logits：

$$z = Wh + b, \qquad p_i = \frac{e^{z_i}}{\sum_{j=1}^{K} e^{z_j}}.$$z = Wh + b, p_i = exp(z_i) / sum(exp(z_j))。

Here $K$ is the number of allowed answers. The matrix $W$ converts a representation into answer scores; softmax turns those scores into a distribution. For a yes/no decision, one scalar and a sigmoid would suffice.这里 K 是允许的答案数量。矩阵 W 将表示转换为答案分数；softmax 将这些分数转换为分布。对于是/否决策，一个标量和一个 sigmoid 函数就足够了。

The classes need not be fixed concepts such as “payments”. They can be option slots: first option, second option, third option. The branch supplies each slot’s meaning; application code maps its probability back to the caller’s option key. An ordered Score can similarly predict probabilities over levels and return their probability-weighted average. This supports new decisions without training a new head for each customer’s labels. A pointer-style scorer, compared in section 4, is the main alternative: it scores each option’s own representation instead of a numbered slot.这些类别不需要是诸如“付款”之类的固定概念。它们可以是选项槽：第一个选项、第二个选项、第三个选项。分支提供每个槽的含义；应用程序代码将其概率映射回调用者的选项键。有序分数（Score）同样可以预测各级别的概率并返回其概率加权平均值。这支持了新的决策，而无需为每个客户的标签训练一个新的头部。第 4 节中比较的指针式评分器是主要的替代方案：它对每个选项自身的表示进行评分，而不是针对编号槽。

This does not establish that Jev has a separately named classifier module. A language model’s vocabulary head is also a matrix followed by softmax. Selecting $K$ reserved label rows from that matrix can implement the same computation as a dedicated $K$-class head. The rows might be tied to input embeddings or trained independently; we cannot distinguish those arrangements here.这并不确定 Jev 有一个单独命名的分类器模块。语言模型的词汇表头也是一个矩阵，后跟 softmax。从该矩阵中选择 K 个保留标签行可以实现与专用 K 类头部相同的计算。这些行可能与输入嵌入绑定或独立训练；我们无法在此区分这些安排。

The important distinction is between reading out probabilities and generating text that describes probabilities. A generated “91%” is a token sequence. A classifier’s 0.91 is an entry in its predictive distribution. Either can be miscalibrated. Neither becomes trustworthy solely because of its format.重要的区别在于读取概率与生成描述概率的文本。生成的“91%”是一个 token 序列。分类器的 0.91 是其预测分布中的一个条目。两者都可能校准错误。它们都不会仅仅因为格式而变得值得信赖。

Constrained text decoding remains a possible way to build a similar interface, but TypeSafe explicitly describes a different output path. Its statement is stronger evidence than a latency argument. The evidence points to a direct numerical readout, one of the two designs compared in section 4. Reserved label tokens remain possible, although the fake-option test there weighs against them.受约束的文本解码仍然是构建类似接口的一种可能方式，但 TypeSafe 明确描述了不同的输出路径。其声明比延迟论点更有力。证据指向直接数值读取，即第 4 节中比较的两种设计之一。保留标签 token 仍然是可能的，尽管其中的虚假选项测试不支持它们。

2. Share the state, isolate the questions¶2. 共享状态，隔离问题

The next decision concerns where computation is reused.下一个决定涉及计算在何处被重用。

Observed evidence. Token accounting is exactly additive in the small controlled examples. One minimal yes/no question used 268 input tokens; two used 276. A request containing one yes/no question, one two-option Choice, and one two-level Score used 318, matching the sum of their measured contributions above the shared overhead. This fits a common prefix plus question suffixes, though accounting alone does not identify a computational graph.⁴观察到的证据。在小型受控示例中，token 计数是完全可加的。一个最小的是/否问题使用了 268 个输入 token；两个使用了 276 个。一个包含一个是/否问题、一个双选项选择和一个双级别分数的请求使用了 318 个，这与它们在共享开销之上的测量贡献之和相符。这符合公共前缀加上问题后缀的情况，尽管仅凭计数无法识别计算图。

A more informative experiment moves evidence between those regions. The state initially said:一个更具信息量的实验在这些区域之间移动证据。状态最初说：

The weather is nice today and the park is full of people.

A sibling question contained:一个兄弟问题包含：

The secret code for this request is ZEBRA-7741.
Is the weather described as nice?

The probe asked which code another question mentioned, with ZEBRA-7741, two distractors, and none as choices. With the secret in the sibling question, its reported probability was 0.00. Removing that sibling produced the same result. Putting the declaration in the state instead raised it to 0.90–0.92. These were five repeats per condition (visibility in the probe records).⁵探测询问另一个问题提到了什么代码，选项包括 ZEBRA-7741、两个干扰项和“无”。当秘密在兄弟问题中时，其报告的概率为 0.00。移除该兄弟问题产生了相同的结果。将声明放入状态中则将其提高到 0.90–0.92。这些是每个条件重复五次的结果（在探测记录中可见）。

This is a useful intervention: moving the declaration across an API boundary changes its effect. It supports behavioural isolation between questions and access to the shared state. It does not expose the exact attention mask. Separate model calls, a tree mask, or another mechanism that restricts information flow could produce the same result. The probe’s wording also asks about “another question” even in the state condition, so it is not a pristine test of literal instruction following.这是一个有用的干预：跨 API 边界移动声明会改变其效果。它支持问题之间的行为隔离以及对共享状态的访问。它没有暴露确切的注意力掩码。单独的模型调用、树状掩码或其他限制信息流的机制可能会产生相同的结果。探测的措辞即使在状态条件下也询问“另一个问题”，所以这不是对字面指令遵循的原始测试。

The serving measurements add another piece. Up to about 100 questions, server time barely changed. Beyond that it rose steadily, and token for token, question text cost roughly twice as much as state. That is consistent with computing the state once and batching the question work.⁶服务测量添加了另一部分。在多达 100 个问题的情况下，服务器时间几乎没有变化。超过这个数字后，它稳步上升，并且逐个 token 计算，问题文本的成本大约是状态的两倍。这与计算一次状态并批处理问题工作是一致的。

Longer stateone question一个问题更长的状态一个问题

More questionsshort state短状态更多问题短状态

These are server-reported upstream durations, not local laptop timings. They include whatever work and waiting the upstream service includes, and the service was shared with other users.这些是服务器报告的上游持续时间，而不是本地笔记本电脑的计时。它们包括上游服务包含的任何工作和等待，并且该服务与其他用户共享。

Jev enforces two limits. Each branch (the state plus one question) is capped at roughly 32,768 tokens, and the whole request at roughly 65,536. The request limit counts the state once: a 23k-token state with 5,000 questions fits within it. If each question processed its own copy of the state, that request would be over 100 million tokens. The pair fits a single packed sequence of up to 2¹⁶ tokens, holding the state once and every question after it, with each branch limited to a 2¹⁵ context window.²²Jev 强制执行两个限制。每个分支（状态加上一个问题）上限约为 32,768 个 token，整个请求上限约为 65,536 个。请求限制将状态计算一次：一个 23k token 的状态加上 5,000 个问题符合该限制。如果每个问题都处理自己的状态副本，该请求将超过 1 亿个 token。这对组合符合单个打包序列，最多 2^16 个 token，保存一次状态以及之后的所有问题，每个分支限制为 2^15 的上下文窗口。

A prefix KV cache with separate causal suffixes is the natural implementation. Hydragen describes efficient attention for sequences sharing a prefix; DeFT develops attention for tree-structured inference. These establish that the serving pattern is practical. They are prior art, not evidence that TypeSafe uses either library.⁷⁸具有单独因果后缀的前缀 KV 缓存是自然的实现。Hydragen 描述了针对共享前缀序列的高效注意力；DeFT 开发了针对树状结构推理的注意力。这些确立了服务模式是实用的。它们是现有技术，而不是 TypeSafe 使用任一库的证据。

This design also clarifies an apparent contradiction: isolated questions can still be evaluated together on the same accelerator. “Parallel” describes their scheduling and lack of answer dependencies. It need not mean one GPU per question.这种设计还澄清了一个明显的矛盾：隔离的问题仍然可以在同一个加速器上一起评估。“并行”描述了它们的调度和缺乏答案依赖性。它不一定意味着每个问题一个 GPU。

3. A causal backbone¶3. 因果骨干网

The experiments can’t tell a causal decoder from a bidirectional encoder: in both, the final decision can read the whole input. I assume a causal decoder anyway, for good reason. Jev’s breadth of knowledge (84.6% on MMLU-Pro) requires frontier-scale pretraining, every model at that scale is a causal decoder, and TypeSafe describes RLCD as post-training a pretrained language model. A bidirectional Jev would mean either a far weaker base or converting a decoder at extra cost, while giving up the shared-prefix caching that causal serving provides. That would be surprising, but it can’t be ruled out from the outside.¹²¹⁵实验无法区分因果解码器和双向编码器：在这两者中，最终决策都可以读取整个输入。无论如何，我假设是因果解码器，这是有充分理由的。Jev 的知识广度（MMLU-Pro 上 84.6%）需要前沿规模的预训练，该规模下的每个模型都是因果解码器，且 TypeSafe 将 RLCD 描述为预训练语言模型的后训练。双向 Jev 意味着要么基础模型弱得多，要么以额外成本转换解码器，同时放弃因果服务提供的共享前缀缓存。那将令人惊讶，但从外部无法排除。

Which pretrained model is unknown, and the tokenizer doesn’t reveal one. Jev’s token counts match none of the 192 public tokenizers we tested across 415 probes. It splits every digit individually and looks up whole chunks before merging: 8 as count as one token, but 16 count as four. Its vocabulary tracks OpenAI’s o200k closely, since every string Jev counts as a single token is also a single o200k token, yet digit splitting and several merges rule o200k itself out. The closest public match, Qwen, agrees on 348 of 415 probes. That rules out an unchanged public tokenizer, not a public base model: a replaced vocabulary, continued pretraining or distillation could each explain it, as could an API that counts tokens differently from the model.¹⁸预训练模型是什么尚不清楚，分词器也没有透露。Jev 的 token 计数与我们在 415 次探测中测试的 192 个公共分词器都不匹配。它单独拆分每个数字，并在合并前查找整个块：8 算作一个 token，但 16 算作四个。它的词汇表与 OpenAI 的 o200k 密切跟踪，因为 Jev 算作单个 token 的每个字符串也是一个单一的 o200k token，但数字拆分和几次合并排除了 o200k 本身。最接近的公共匹配项 Qwen 在 415 次探测中匹配了 348 次。这排除了未更改的公共分词器，而不是公共基础模型：替换的词汇表、继续预训练或蒸馏都可以解释它，计算 token 方式与模型不同的 API 也可以。

The experiments do show what the decision can read. I placed a reference card among a question’s options and asked Jev to pick the option whose condition the card satisfies. Here is one exact option set:实验确实显示了决策可以读取什么。我在一个问题的选项中放置了一张参考卡，并要求 Jev 选择参考卡条件满足的选项。这是一个确切的选项集：

alpha: Reference card: status = amber. Reference-only option.
       Never select this option.

beta: Select this option if the reference card's status is amber.

gamma: Select this option if the reference card's status is indigo.

The instruction was: “Read the reference card and select the one option whose condition is satisfied.” Changing the reference value to indigo switches the correct answer while leaving the selectable options unchanged.指令是：“阅读参考卡并选择条件满足的一个选项。”将参考值更改为靛蓝色会切换正确答案，同时保持可选选项不变。

I tested both values, all six option permutations, and a second template using route = east/west, with two repeats. A paired control put the reference in the shared state instead. That gave 48 option-reference trials and 48 state-reference controls.²⁰我测试了两个值、所有六种选项排列，以及使用 route = east/west 的第二个模板，重复两次。配对对照组将参考放在共享状态中。这产生了 48 次选项参考试验和 48 次状态参考对照。

Position of the reference option	Correct answers
First	12 / 16
Middle	11 / 16
Last	16 / 16
Reference moved into state	48 / 48

Jev can use information placed after the candidate descriptions. With the reference last, it selected the correct option in every trial, with mean correct-answer probability about 0.88.Jev 可以使用放置在候选描述之后的信息。当参考在最后时，它在每次试验中都选择了正确的选项，平均正确答案概率约为 0.88。

α Reference cardα 参考卡β · γβ · γ Candidate answersβ · γ 候选答案

Probability of the correct answer

OPTION ORDER00.51MEANCORRECT

Card first12/16 correct12/16 正确卡片在前12/16 正确

αβγ 0.500.50 6/86/8

αγβ 0.560.56 6/8

Card in the middle11/16 correct11/16 正确卡片在中间11/16 正确

βαγ 0.490.49 4/84/8

γαβ 0.56 7/87/8

Card last16/16 correct16/16 正确卡片在最后16/16 正确

βγα 0.890.89 8/88/8

γβα 0.870.87 8/8

Card in the shared state48/48 correct48/48 正确卡片在共享状态中48/48 正确

All 6 orders 1.001.00 48/4848/48

The value-switch control matters as much as the position. With the card last, changing only amber to indigo changes which earlier option wins, although those earlier descriptions and the state stay identical. A model that independently scores each option from its own text and the state, then merely normalises the scores, has no route for that fact to change the earlier options’ relative ranking. The results support a path through which options influence the joint decision.²⁰值切换对照与位置同样重要。当卡片在最后时，仅将琥珀色更改为靛蓝色会改变哪个较早的选项获胜，尽管那些较早的描述和状态保持不变。一个根据自身文本和状态独立对每个选项评分，然后仅仅归一化分数的模型，没有路径让该事实改变较早选项的相对排名。结果支持选项影响联合决策的路径。

This fits any readout computed after the whole list, including both designs compared in section 4, as well as a separate option-mixing stage. The remaining errors show position-sensitive processing on these two templates; they do not identify a unique cause.这适用于在整个列表之后计算的任何读取，包括第 4 节中比较的两种设计，以及单独的选项混合阶段。剩余的错误显示了在这两个模板上的位置敏感处理；它们没有识别出唯一的原因。

Diffusion is unnecessary for this computation, and nothing in these experiments requires iterative denoising. The defensible architectural inference is narrower: the answer computation has access to the full option list. The next experiment tests whether it actually uses that joint context.对于这种计算，扩散是不必要的，这些实验中没有任何内容需要迭代去噪。可辩护的架构推断更窄：答案计算可以访问完整的选项列表。下一个实验测试它是否实际上使用了该联合上下文。

4. Let the options interact before choosing¶4. 在选择前让选项交互

Within a question, the evidence points to a different information boundary: the alternatives are read together as an ordered list, followed by one decision position.在一个问题内，证据指向不同的信息边界：备选项作为有序列表一起读取，随后是一个决策位置。

Why allow that interaction? Options such as “none of the above” depend on the other choices. Even ordinary alternatives can clarify a question. “Payments”, “account access”, and “other” define a different decision from “bank”, “payment provider”, and “customer”. A listwise representation lets the model interpret that distinction before producing the distribution.为什么要允许那种交互？诸如“以上皆非”之类的选项取决于其他选择。即使是普通的备选项也可以阐明问题。“付款”、“账户访问”和“其他”定义的决策与“银行”、“支付提供商”和“客户”不同。列表式表示让模型在产生分布之前解释那种区别。

The strongest evidence is an experiment with an irrelevant extra option.最有力的证据是一个带有无关额外选项的实验。

Start with four possible causes of a payout failure: bank, provider, customer, and unknown. Then append weather: Bad weather caused it. If every original option receives an independent, unchanged logit and the server applies the same softmax temperature, adding a fifth option changes the normalisation but cannot change the odds between two existing options:从付款失败的四个可能原因开始：银行、提供商、客户和未知。然后附加天气：恶劣天气导致了它。如果每个原始选项都收到一个独立的、未更改的 logit，并且服务器应用相同的 softmax 温度，添加第五个选项会改变归一化，但不能改变两个现有选项之间的几率：

$$\frac{p(\text{customer})}{p(\text{unknown})} = e^{z_{\text{customer}}-z_{\text{unknown}}}.$$p(customer) / p(unknown) = exp(z_customer - z_unknown)。

The common denominator cancels. This gives us a specific, falsifiable prediction.公分母抵消了。这给了我们一个具体的、可证伪的预测。

The original study found a shift from approximately +0.49 to +0.08.¹⁰ To check whether this survived ordinary request variability, I repeated the experiment in ten randomised blocks. Each block included the four-option baseline, an identical four-option control, a five-option version with weather appended, an identical five-option control, and a five-option version whose added description changed from “Bad weather caused it” to “Wild birds caused it”. Each request contained one question.²¹最初的研究发现从大约 +0.49 偏移到 +0.08。为了检查这是否在普通的请求可变性中幸存，我在十个随机块中重复了实验。每个块包括四选项基线、相同的四选项对照、附加了天气的五选项版本、相同的五选项对照，以及添加的描述从“恶劣天气导致了它”更改为“野生鸟类导致了它”的五选项版本。每个请求包含一个问题。

The expansion result replicated. Pooling the two identical requests for each condition within each block, mean log-odds fell from +0.38 to +0.11. Every block showed a decrease; the average change was −0.28, with a descriptive 95% paired t interval of approximately −0.36 to −0.19. The pooling uses the control requests to reduce ordinary request noise rather than treating duplicate outputs as independent experiments.²¹扩展结果被复制。汇总每个块内每个条件的两个相同请求，平均对数几率从 +0.38 下降到 +0.11。每个块都显示下降；平均变化为 -0.28，描述性 95% 配对 t 区间大约为 -0.36 到 -0.19。汇总使用对照请求来减少普通请求噪声，而不是将重复输出视为独立实验。

4 options4 个选项→5 options5 个选项Add “bad weather caused it”添加“恶劣天气导致了它”

BLOCK −0.200+0.20+0.40+0.60+0.80 CHANGE

1 −0.02-0.02

2 −0.36-0.36

3 −0.26-0.26

4 −0.46-0.46

5 −0.26

6 −0.21-0.21

7 −0.28-0.28

8 −0.35-0.35

9 −0.33-0.33

10 −0.25-0.25

Mean平均值 4 options 5 options −0.28

← Favours unknownFavours customer →log [ P(customer) / P(unknown) ]

Fixed scores + fixed temperature

The dots would coincide点会重合

Observed

Lower in all ten blocksMean change −0.28 · 95% interval −0.36 to −0.19所有十个块中较低平均变化 -0.28 · 95% 区间 -0.36 至 -0.19

This is evidence against fixed independent logits followed by an unchanged softmax. It does not uniquely identify the mechanism. Changing the added description while keeping five options gave a smaller, inconclusive shift: its paired interval included zero. A set-dependent temperature remains possible, alongside content-dependent mixing.这是反对固定独立 logits 后跟未更改 softmax 的证据。它没有唯一地识别机制。在保持五个选项的同时更改添加的描述给出了较小的、不确定的偏移：其配对区间包括零。集合相关温度仍然是可能的，以及内容相关混合。

A readout that sees the complete list explains this naturally: adding an option changes the context it reads. The FIRST listwise ranking method works the same way, extracting a ranking from first-token logits instead of generating it token by token.¹¹看到完整列表的读取自然地解释了这一点：添加选项会改变它读取的上下文。FIRST 列表式排名方法以同样的方式工作，从第一个 token 的 logits 中提取排名，而不是逐个 token 地生成它。

Two readouts fit the evidence. A final-position head scores each option slot from the decision token’s representation; a pointer-style scorer compares that representation with each option’s own final hidden state. Both let options influence one another. The API accepts at most 255 options (2⁸ − 1), which suits a fixed 256-slot head, but that limit is enforced by request validation, not the model. With 200 options, a copied answer scored 1.00 at every position and errors didn’t spill onto neighbouring options, which suits a pointer. Neither result is decisive.²⁶两种读取方式符合证据。最终位置头部从决策 token 的表示中对每个选项槽进行评分；指针式评分器将该表示与每个选项自身的最终隐藏状态进行比较。两者都让选项相互影响。API 最多接受 255 个选项 (2^8 - 1)，这适合固定的 256 槽头部，但该限制由请求验证强制执行，而非模型。有 200 个选项时，复制的答案在每个位置得分 1.00，错误没有溢出到相邻选项，这适合指针。没有结果是决定性的。

Injected fake options never displaced the real ones, so option boundaries are marked in a way text cannot forge, and an option whose condition is duplicated elsewhere in the list loses probability to its rivals.²³注入的虚假选项从未取代真实的选项，因此选项边界以文本无法伪造的方式标记，且条件在列表中其他地方重复的选项会失去对竞争对手的概率。

The trade-off is visible in ordinary tasks too: reversing options shifted the probability of a technical-support classification from roughly 0.84–0.89 to 0.93–0.96. This came from the option_order probes.⁹ For a deployed decision policy, that matters. A threshold near 0.9 could change the action even though the labels and evidence are identical. Permutation tests belong in the evaluation of any implementation of this design.这种权衡在普通任务中也可见：反转选项将技术支持分类的概率从大约 0.84–0.89 转移到 0.93–0.96。这来自 option_order 探测。对于部署的决策策略，这很重要。0.9 附近的阈值可能会改变操作，即使标签和证据是相同的。置换测试属于对此设计任何实现的评估。

5. Train the distribution, then calculate confidence¶5. 训练分布，然后计算置信度

The fifth component is the training objective. Direct numerical outputs save decoding work, but a cheap probability can still be a bad probability.第五个组件是训练目标。直接数值输出节省了解码工作，但廉价的概率仍然可能是糟糕的概率。

Imagine a collection of cases assigned 0.8 probability of being urgent. Calibration asks whether about 80% really are urgent. It is a property of predictions across cases. We cannot determine whether one prediction is calibrated from whether that particular case turns out well.想象一组被分配 0.8 紧急概率的案例。校准询问大约 80% 是否真的是紧急的。这是跨案例预测的一个属性。我们无法从特定案例的结果好坏来确定一个预测是否已校准。

TypeSafe calls its training method Reinforcement Learning for Calibrated Decisions, or RLCD. The launch says it optimises for “answers with epistemically honest probabilities on System One tasks”; the company’s primer presents RLCD as a post-training path from pretrained language models.¹¹² The exact recipe is unpublished. My proposed training recipe adapts the transformer and readout to typed decision tasks using an outcome-based objective. That gives the backbone an opportunity to construct representations useful for reliable decisions, not merely fluent completions.TypeSafe 将其训练方法称为“校准决策强化学习”（RLCD）。发布称它优化了“系统一任务中具有认知诚实概率的答案”；该公司的入门介绍将 RLCD 呈现为从预训练语言模型开始的后训练路径。确切的配方未发表。我提出的训练配方使用基于结果的目标将 Transformer 和读取层调整为类型化决策任务。这给了骨干网一个构建用于可靠决策（而不仅仅是流畅补全）的表示的机会。

A natural objective is log loss, $-\log p(y)$ for the observed outcome $y$. Another is Brier loss, the squared distance between the predicted distribution and the observed one-hot outcome. Both are proper scoring rules: in expectation, reporting the true conditional distribution minimises the loss. Gneiting and Raftery give the formal definition and theory.¹³ This explains what such training tries to achieve. It does not establish which loss TypeSafe uses, whether its pipeline is reinforcement learning in a narrow algorithmic sense, or whether every backbone weight is updated.一个自然的目标是 log loss，-log p(y)，针对观察到的结果 y。另一个是 Brier loss，预测分布与观察到的 one-hot 结果之间的平方距离。两者都是适当的评分规则：在期望中，报告真实的条件分布会最小化损失。Gneiting 和 Raftery 给出了正式定义和理论。这解释了此类训练试图实现的目标。它没有确立 TypeSafe 使用哪种损失，其流水线是否在狭义算法意义上是强化学习，或者是否更新了每个骨干网权重。

Properness is also not a deployment guarantee. Finite data, model limitations, optimisation error, and distribution shift can all leave calibration imperfect. Guo et al. show both the calibration problems of modern neural networks and the usefulness of post-hoc adjustments. Training and post-hoc calibration are compatible mechanisms; the API cannot separate their contributions.¹⁴适当性也不是部署保证。有限的数据、模型限制、优化错误和分布偏移都可能使校准不完美。Guo 等人展示了现代神经网络的校准问题以及事后调整的有用性。训练和事后校准是兼容的机制；API 无法分离它们的贡献。

Observed evidence. The benchmark records let us compare predicted probability with observed accuracy, both in aggregate and within probability bins. The chart shows those checks. Agreement of the averages alone is weaker evidence than agreement within bins: overconfidence in one group can cancel underconfidence in another. On the 1,200-item MMLU sample, ten-bin expected calibration error was 0.0313 (bin definitions and item-level predictions). Most predictions were concentrated near certainty: 990 fell in the 0.9–1.0 bin.¹⁵观察到的证据。基准记录让我们比较预测概率与观察到的准确性，无论是在总量上还是在概率箱内。图表显示了这些检查。仅平均值的一致性是比箱内一致性更弱的证据：一组中的过度自信可以抵消另一组中的信心不足。在 1,200 项 MMLU 样本上，十箱预期校准误差为 0.0313（箱定义和项目级预测）。大多数预测集中在确定性附近：990 个落在 0.9–1.0 箱中。

MMLU sample1,200 items · ECE 0.0311,200 项 · ECE 0.031MMLU 样本1,200 项 · ECE 0.031

Fresh maths8 generated families · 20–30 items each8 个生成的系列 · 每个 20–30 项新鲜数学8 个生成的系列 · 每个 20–30 项

The small fresh-math study adds useful variation. On generated three-digit multiplication problems, accuracy was 86.7% and average top probability 0.83. On two-step word problems, accuracy fell to 32% and average top probability to 0.30. The model was less confident on the harder task (fresh_math_results, with 30 multiplication and 25 word-problem items).¹⁵ That is encouraging, although small category-level averages cannot establish calibration for every kind of unseen problem.小型新鲜数学研究增加了有用的变化。在生成的三位数乘法问题上，准确率为 86.7%，平均最高概率为 0.83。在两步文字问题上，准确率下降到 32%，平均最高概率下降到 0.30。模型在较难的任务上信心较低（fresh_math_results，有 30 个乘法和 25 个文字问题项）。这是令人鼓舞的，尽管小的类别级平均值无法为每种未见过的难题确立校准。

Those results also show why a public benchmark score is an imperfect measure of what the model knows. MMLU-Pro accuracy was 84.6%; newly generated word problems were much harder.¹⁵ Differences in task structure, distractors, difficulty, and training exposure could all contribute. That gap does not establish benchmark contamination. Fresh wording also does not make the underlying mathematical skill or factual knowledge unseen.这些结果还显示了为什么公共基准分数是模型所知的不完美衡量标准。MMLU-Pro 准确率为 84.6%；新生成的文字问题要难得多。任务结构、干扰项、难度和训练暴露的差异都可能有所贡献。该差距没有确立基准污染。新鲜措辞也没有使基础数学技能或事实知识成为未见过的。

There is a separate, unusually clear finding about the API’s field named confidence. The official adapter computes Choice confidence from a normalised distribution, for $K > 1$, as:有一个关于 API 名为 confidence 的字段的单独、异常清晰的发现。官方适配器计算 Choice 置信度来自归一化分布，对于 K > 1，为：

$$c = \frac{p_{\max}-1/K}{1-1/K}.$$c = (p_max - 1/K) / (1 - 1/K)。

For three options with a maximum probability of 0.8, this gives 0.7. The adapter handles the one-option case separately, returning 1. It measures how far the leading answer stands above a uniform distribution. It is not another learned estimate that the answer is correct. The Score type uses a different formula reflecting distance from the modal level.¹⁶对于最大概率为 0.8 的三个选项，这给出 0.7。适配器单独处理单选项情况，返回 1。它测量领先答案高出均匀分布多少。它不是答案正确的另一个习得估计。Score 类型使用反映与模态级别距离的不同公式。

In the proposed system, training produces the predictive distribution; ordinary arithmetic produces this summary field. Keeping those two objects separate prevents a common conceptual mistake: a concentrated distribution can still be confidently wrong.在拟议系统中，训练产生预测分布；普通算术产生此摘要字段。保持这两个对象分开可以防止常见的概念错误：集中的分布仍然可以是自信地错误的。

6. Sparse capacity¶6. 稀疏容量

I expect Jev to use a sparse mixture-of-experts transformer. At selected layers, a router sends each token through a small subset of feed-forward networks, so the model can store many parameters while activating only some of them for each token: the conditional-computation idea demonstrated by Shazeer et al.’s sparsely gated MoE layers.¹⁷我预计 Jev 使用稀疏专家混合 Transformer。在选定的层，路由器将每个 token 发送到前馈网络的一小部分，因此模型可以存储许多参数，同时仅为每个 token 激活其中一些：Shazeer 等人演示的稀疏门控 MoE 层所展示的条件计算思想。

Sparse experts can’t be observed from outside, but they are the likely choice. A prefill-only model is limited by compute, which is exactly what sparse routing saves. MoE’s usual serving costs mostly disappear: there is no token-by-token decoding, where memory bandwidth dominates and most experts end up active anyway, and no long-lived KV cache competing with expert weights for memory. The measurements point the same way. Jev processed about 30k tokens in roughly 160 ms; a dense 70B model on an 8×H100 node would need around a second, while a MoE with about 10B active parameters fits. And most of the strongest recent base models (DeepSeek-V3, Qwen3, GLM-4.5, Kimi K2, gpt-oss) are MoE. Specialised hardware could let a dense model match the speed, and benchmark scores may overstate how much knowledge the model holds, so this remains an inference, not a measurement.⁶¹⁵稀疏专家无法从外部观察到，但它们是可能的选择。仅预填充模型受计算限制，这正是稀疏路由节省的内容。MoE 的通常服务成本大多消失了：没有逐 token 解码，内存带宽占主导地位且大多数专家最终都会激活，也没有与专家权重竞争内存的长寿命 KV 缓存。测量结果指向相同方向。Jev 在大约 160 毫秒内处理了大约 30k token；8×H100 节点上的密集 70B 模型需要大约一秒，而具有大约 10B 活动参数的 MoE 适合。且大多数最强的近期基础模型（DeepSeek-V3、Qwen3、GLM-4.5、Kimi K2、gpt-oss）都是 MoE。专用硬件可以让密集模型匹配速度，基准分数可能夸大了模型持有的知识量，因此这仍然是一个推断，而不是测量。

Nothing else in the reconstruction depends on it. Swapping in a dense transformer would leave the interface, shared state, isolated branches and readout exactly as described.重构中的其他任何内容都不依赖于它。换入密集 Transformer 将使接口、共享状态、隔离分支和读取完全按描述的那样。

7. Schedule branches as a batch, not a conversation¶7. 将分支调度为批处理，而不是对话

The final component is a serving engine that treats question branches as independent work items. Their suffixes can be packed into batches while reading shared state representations. Application code then associates the numerical outputs with question identifiers and serializes the response.最后一个组件是一个服务引擎，它将问题分支视为独立的工作项。在读取共享状态表示的同时，可以将这些分支的后缀打包成批次。随后，应用程序代码会将数值输出与问题标识符关联起来，并将响应序列化。

The measurements reveal small differences between repeated identical answers, including between duplicate questions within one request. This means API-level determinism should not be assumed (noise, dup, and determinism).¹⁹ It does not imply that the model generates or samples text: numerical kernels, dynamic batching, routing, or deliberate randomness can all affect a direct readout.测量结果显示，重复的相同答案之间存在细微差异，即使是在同一个请求中的重复问题之间也是如此。这意味着不应假设 API 级别具有确定性（noise, dup, and determinism）。19 这并不意味着模型在生成或采样文本：数值内核、动态批处理、路由或刻意的随机性都可能影响直接读取的结果。

Response key orders also varied in a small number of recurring patterns.¹⁹ Multiple workers with different hash ordering are a plausible explanation. However, this side channel does not identify the worker count, establish where the KV cache lives, or tell us which numerical precision is used. Those are implementation details the available observations cannot resolve.响应键的顺序也呈现出少量重复的模式。19 使用不同哈希排序的多个工作进程是一个合理的解释。然而，这一侧信道无法确定工作进程的数量、KV 缓存的位置，也无法告诉我们使用了哪种数值精度。这些都是现有观察结果无法解决的实现细节。

What matters to the proposed architecture is the absence of a dependency chain between answers. The model does not need to finish writing the queue classification before beginning the urgency estimate. Both depend on the state; neither consumes the other’s generated answer.对于所提出的架构而言，重要的是答案之间不存在依赖链。模型不需要在开始估算紧急程度之前完成队列分类的编写。两者都依赖于状态，且都不会消耗对方生成的答案。

There is still a dependency limit. If a later question genuinely needs an earlier answer, the application must introduce another decision stage or express the joint decision in one question. Sharing context does not remove the logical structure of the workflow.但仍然存在依赖限制。如果后续问题确实需要先前的答案，应用程序必须引入另一个决策阶段，或者将联合决策表达为一个问题。共享上下文并不能消除工作流的逻辑结构。

What would change my mind?¶什么会改变我的想法？

This reconstruction makes different kinds of commitments. Direct probability outputs are publicly described. Question isolation and option-order effects are observable behaviours. KV sharing, causal attention, final-position or pointer-style readouts, and sparse experts are progressively more specific explanations.这种重构做出了不同类型的承诺。直接概率输出是公开描述的。问题隔离和选项顺序效应是可观察的行为。KV 共享、因果注意力机制、最终位置或指针式读取以及稀疏专家模型则是更具体的解释。

The reference-card experiment settles one question: the decision can use options placed last. The fake-option test shows that tricks in the input format cannot forge option boundaries. Broader relational tasks could constrain the representation further, although behavioural success alone would still not uniquely identify an attention mask.参考卡实验解决了一个问题：决策可以使用放置在最后的选项。虚假选项测试表明，输入格式中的技巧无法伪造选项边界。更广泛的关系任务可以进一步约束这种表示，尽管仅凭行为上的成功仍不足以唯一确定注意力掩码。

For option handling, the randomised follow-up replicates a choice-set effect, but the fixed-size description intervention remains inconclusive. More templates and independent request blocks could distinguish a shared temperature change from content-dependent interactions. A task of middling difficulty at 200 options could separate the slot head from the pointer scorer. For calibration, held-out workflow data and repeated evaluations under shift would matter more than another aggregate benchmark score. Confirming sparse experts would probably require a disclosure or evidence beyond this API.关于选项处理，随机化的后续实验复制了选择集效应，但固定大小的描述干预仍然没有定论。更多的模板和独立的请求块可以区分共享温度变化与内容相关的交互。在 200 个选项下进行中等难度的任务可能可以将槽位头（slot head）与指针评分器（pointer scorer）区分开来。对于校准而言，保留的工作流数据和在偏移下的重复评估比另一个聚合基准测试分数更重要。确认稀疏专家模型可能需要披露信息或 API 之外的证据。

My best reconstruction of Jev remains the one in the opening diagram: a causal transformer with a shared state prefix, isolated question suffixes, listwise option processing, typed numerical readouts, and training directed at predictive distributions. Sparse experts are the likely backbone, although nothing else in the design depends on them.我对 Jev 最好的重构仍然是开篇图示中的那样：一个具有共享状态前缀、独立问题后缀、列表式选项处理、类型化数值读取以及针对预测分布进行训练的因果 Transformer。稀疏专家模型很可能是其骨干，尽管设计中的其他部分并不依赖于它们。

Its usefulness comes from matching the computational graph to the job. A decision service needs to read evidence, compare permitted outcomes, and expose uncertainty. A transformer can do that without turning every decision into a sentence first.它的实用性来自于将计算图与任务相匹配。决策服务需要读取证据、比较允许的结果并揭示不确定性。Transformer 可以在不将每个决策先转化为句子的前提下做到这一点。

Methods¶方法

This essay is based on a 17 September 2026 investigation of jev-1.13.0, using one early-access account and one observed service region. The source study contains 1,029 instrumented probe records (including the 190 generated-math items), 6,800 benchmark records, and separate factual checks. Follow-up studies added 146 relational and option-interaction requests (trials, summary), 311 token-accounting requests, 445 tokenizer-fingerprint requests, 192 latency requests, 148 option-count latency requests, 181 option-position requests, 105 fake-option requests and 35 context-limit requests. Each is linked from the references, with exact requests and sanitised responses. Repeated benchmark configurations share underlying items; these counts are not counts of independent problems.本文基于 2026 年 9 月 17 日对 jev-1.13.0 的调查，使用了一个早期访问账户和一个受观察的服务区域。原始研究包含 1,029 条仪器化探针记录（包括 190 条生成的数学项目）、6,800 条基准测试记录以及独立的实事核查。后续研究增加了 146 条关系和选项交互请求（试验、摘要）、311 条 Token 统计请求、445 条分词器指纹请求、192 条延迟请求、148 条选项计数延迟请求、181 条选项位置请求、105 条虚假选项请求和 35 条上下文限制请求。每项请求均在参考文献中链接，并附有确切的请求和脱敏后的响应。重复的基准测试配置共享底层项目；这些计数并非独立问题的计数。

The downloadable evidence bundle records the observations used in this essay. API examples in the opening section are schematic. Quoted visibility and reference-card prompts come from the probe scripts and saved follow-up requests. Numerical observations are specific to this model version and test campaign.可下载的证据包记录了本文中使用的观察结果。开篇部分的 API 示例是示意性的。引用的可见性和参考卡提示来自探针脚本和保存的后续请求。数值观察结果特定于此模型版本和测试活动。

Latency figures come from the x-envoy-upstream-service-time response header. They are upstream service durations, with unknown queueing and execution boundaries, rather than isolated model timings. The latency figure’s sweeps were run one request at a time in shuffled order; none of the studies controlled server load. Local wall-clock measurements are not used as architectural evidence.延迟数据来自 x-envoy-upstream-service-time 响应头。它们是上游服务的持续时间，具有未知的排队和执行边界，而非孤立的模型计时。延迟数据的扫描是按顺序逐个请求进行的，顺序已被打乱；所有研究均未控制服务器负载。本地挂钟测量结果不被用作架构证据。

Probabilities were generally returned at two-decimal precision. Duplicate questions in one request share conditions and may have correlated errors. The MMLU calibration figure uses ten equal-width bins: [0, 0.1), [0.1, 0.2), and so on, with 1.0 included in the last bin. Expected calibration error is the sample-weighted absolute difference between accuracy and average top probability in each bin. Estimates depend on sample selection, binning, and response rounding. The evidence supports claims about the tested distributions, not guaranteed calibration across future customer workflows.概率通常以两位小数精度返回。同一请求中的重复问题共享条件，并可能存在相关的错误。MMLU 校准图使用了十个等宽的箱（bin）：[0, 0.1), [0.1, 0.2)，以此类推，1.0 包含在最后一个箱中。预期校准误差是每个箱中准确率与平均最高概率之间的样本加权绝对差。估计值取决于样本选择、分箱和响应舍入。证据支持关于所测试分布的声明，而非保证在未来客户工作流中实现校准。

Sources and related work¶来源与相关工作

Experimental references identify the original script tags so that each observation can be located in the evidence bundle. Paper citations establish the proposed mechanisms and their precedents; they do not establish that Jev uses them.实验参考文献标识了原始脚本标签，以便在证据包中定位每次观察。论文引用确立了所提出的机制及其先例；它们并不证明 Jev 使用了这些机制。

Sources来源

1. [1] TypeSafe (2026). Introducing System One Models and Jev. Primary source for the parallel-output claim and stated RLCD objective. [1] TypeSafe (2026). Introducing System One Models and Jev. 并行输出声明和既定 RLCD 目标的主要来源。
2. [2] TypeSafe. Full API documentation, accessed 17 September 2026. Typed questions, response distributions, and API contract. [2] TypeSafe. 完整 API 文档，访问于 2026 年 9 月 17 日。类型化问题、响应分布和 API 合约。
3. [3] Vaswani et al. (2017). Attention Is All You Need. Decoder masking, attention, and the linear/softmax output layer. [3] Vaswani et al. (2017). Attention Is All You Need. 解码器掩码、注意力机制以及线性/Softmax 输出层。
4. [4] API experiments: type_preamble and outputs. Token-accounting additivity, identifier changes, and the 255-option response. [4] API 实验：type_preamble 和输出。Token 统计可加性、标识符更改以及 255 个选项的响应。
5. [5] API experiment: visibility. Five repetitions each with the secret in a sibling question, absent from that sibling, and in the state. [5] API 实验：可见性。五次重复实验，每次将秘密信息分别置于兄弟问题中、从兄弟问题中移除，以及置于状态中。
6. [6] Latency sweeps (192 sequential requests). State length and question count, 8 shuffled repeats each; server-reported upstream durations. [6] 延迟扫描（192 次顺序请求）。状态长度和问题计数，各 8 次打乱顺序的重复；服务器报告的上游持续时间。
7. [7] Juravsky et al. (2024). Hydragen: High-Throughput LLM Inference with Shared Prefixes. [7] Juravsky et al. (2024). Hydragen: High-Throughput LLM Inference with Shared Prefixes.
8. [8] Yao et al. (2024). DeFT: Decoding with Flash Tree-attention for Efficient Tree-structured LLM Inference. [8] Yao et al. (2024). DeFT: Decoding with Flash Tree-attention for Efficient Tree-structured LLM Inference.
9. [9] API experiment: option_order. Ordinary ticket order sensitivity. [9] API 实验：option_order。普通票据顺序敏感性。
10. [10] API experiment: iia. Three requests per condition, each with forty duplicate questions; original, appended, and prepended choice sets. [10] API 实验：iia。每种条件三个请求，每个请求包含四十个重复问题；原始、追加和前置的选择集。
11. [11] Reddy et al. (2024). FIRST: Faster Improved Listwise Reranking with Single Token Decoding. [11] Reddy et al. (2024). FIRST: Faster Improved Listwise Reranking with Single Token Decoding.
12. [12] TypeSafe. Machine learning primer. Primary description of the RLCD post-training path and calibration contract. [12] TypeSafe. 机器学习入门。RLCD 后训练路径和校准合约的主要描述。
13. [13] Gneiting and Raftery (2007). Strictly Proper Scoring Rules, Prediction, and Estimation. Journal of the American Statistical Association 102(477):359–378. [13] Gneiting and Raftery (2007). Strictly Proper Scoring Rules, Prediction, and Estimation. Journal of the American Statistical Association 102(477):359–378.
14. [14] Guo et al. (2017). On Calibration of Modern Neural Networks. [14] Guo et al. (2017). On Calibration of Modern Neural Networks.
15. [15] Benchmark and generated-math records: accuracy and average predicted probabilities. ; MMLU reliability analysis: bin definitions, ECE, Wilson intervals and 1,200 item-level predictions. [15] 基准测试和生成的数学记录：准确率和平均预测概率；MMLU 可靠性分析：箱定义、ECE、Wilson 区间和 1,200 项项目级预测。
16. [16] TypeSafe. Official Python adapter, confidence_metrics.py, revision fb52b103. Choice and Score confidence formulas (read 17 September 2026). [16] TypeSafe. 官方 Python 适配器，confidence_metrics.py，版本 fb52b103。选择和分数置信度公式（阅读于 2026 年 9 月 17 日）。
17. [17] Shazeer et al. (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer. [17] Shazeer et al. (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer.
18. [18] Tokenizer fingerprint experiment (445 requests). Run-length, vocabulary and pre-tokenisation probes, compared against 192 public tokenizers. [18] 分词器指纹实验（445 次请求）。游程长度、词汇表和预分词探针，与 192 个公共分词器进行对比。
19. [19] API experiments: noise, dup, and determinism. Repeated probabilities and response-key orders. [19] API 实验：噪声、重复和确定性。重复的概率和响应键顺序。
20. [20] Follow-up relational experiment (96 requests). Two templates, two reference values, six permutations, two locations, and two repeats; exact requests and sanitised responses. [20] 后续关系实验（96 次请求）。两个模板、两个参考值、六种排列、两个位置和两次重复；确切请求和脱敏响应。
21. [21] Follow-up option-interaction experiment (50 requests). Ten randomised blocks of base4, null4, append5, replace5, and null5; paired changes and standard errors. [21] 后续选项交互实验（50 次请求）。十个随机化块，包含 base4、null4、append5、replace5 和 null5；配对变化和标准误差。
22. [22] Context-limit experiment (35 sequential requests). Per-branch and whole-request token limits, with accepted and rejected boundary cases. [22] 上下文限制实验（35 次顺序请求）。每个分支和整个请求的 Token 限制，包含已接受和已拒绝的边界情况。
23. [23] Fake-option injection experiment (105 requests). Seven delimiter formats, saturated and ambiguous base tasks, and full probability vectors. [23] 虚假选项注入实验（105 次请求）。七种分隔符格式、饱和与模糊的基础任务以及完整的概率向量。
24. [24] Token-accounting experiments (311 requests). Question-ID length, batch size, state difficulty, word IDs, and matched state versus ID strings. [24] Token 统计实验（311 次请求）。问题 ID 长度、批次大小、状态难度、单词 ID 以及匹配的状态与 ID 字符串。
25. [25] Option-count latency experiment (148 requests). One or 20 questions with 2–200 options, short and long labels, plus input/output decoupling controls. [25] 选项计数延迟实验（148 次请求）。1 个或 20 个问题，包含 2–200 个选项、短标签和长标签，以及输入/输出解耦控制。
26. [26] Option-position experiment (181 requests). Option-count cap, correct answer moved across 10-, 50-, 200- and 255-option lists. [26] 选项位置实验（181 次请求）。选项计数上限，正确答案在 10、50、200 和 255 个选项的列表中移动。

---

— Archer— Archer