Jev 背后：关于其基础模型的两种假设

一个双向编码器，还是一个没有生成循环的因果解码器？

2026年9月18日

Jev 提出了一个架构层面的问题：在一个返回决策而非文本的 API 背后，究竟是什么样的预训练模型？TypeSafe 描述了一个模型，它接收状态、问题和预定义答案空间，然后返回带类型的结果和概率。其训练方法“用于校准决策的强化学习”（Reinforcement Learning for Calibrated Decisions）被呈现为一条从预训练语言模型出发的后训练路径。此处引用的公开材料并未指明底层的检查点。TypeSafe 的训练概览

有两种可能性值得考虑：一种是 BERT 风格的双向编码器，另一种是被改造为无需自回归生成循环即可做出预测的因果解码器。这些都是架构层面的假设。二者都未指明具体的模型家族，也无法证明权重源自何处。

Archer Hume 的调查提供了有用的证据。基于大约 10,000 次 API 调用，他提出了一种因果 Transformer，具有共享状态计算、隔离的问题分支以及直接的概率读出。他还怀疑其骨干网络是混合专家架构。关键在于，他承认自己的实验无法区分因果解码器与双向编码器。他的重构是对所观察行为的一种合理解释，而非还原出的模型规格说明。Hume 的调查

第一种可能，是为通用决策任务构建的双向编码器。 BERT 确立了那种熟悉的模式：用双向注意力处理文本，再用得到的表示进行分类或其他预测。每个输入位置都能同时吸收来自前后位置的信息。产生分类结果无需文本生成循环。BERT 论文

一个类似 Jev 的实现可以联合编码状态、问题和候选描述，然后对候选打分。要支持新标签，就需要一种能解读其描述的机制，而不是一个输出神经元永远固定代表“账单”“销售”和“客服”的传统分类器。这是一项设计要求，而非某种具体实现的证据。Jev 的接口允许开发者在请求时定义问题和选项。TypeSafe 的问题原语

这一假设与产品的用途相符。分类和打分都能受益于对完整证据与答案集的表示。然而，复现接口并不能证明具备相当的能力。模型仍需具备广泛的语言理解能力、跨多种决策任务的训练，以及在不熟悉输入上仍然有用的概率输出。

此外，模型的“出身”与它的最终架构之间也存在重要区别。编码器不必从 BERT 检查点起步。LLM2Vec 表明，通过改变注意力机制并施加额外训练，预训练解码器可以被改造成双向文本编码器。它并不能解释 Jev，但它说明了为什么“最初作为解码器训练”和“当前作为双向编码器运行”是两种可以并存的描述。LLM2Vec 论文

第二种可能性是因果解码器在文本生成开始前即停止。 基于解码器的模型无需调用生成循环，即可提供隐藏表示和预测分数。现有实现已支持这一区分：Hugging Face 同时提供了 Llama 的因果语言建模版本和序列分类版本。这表明该设计在技术上是常规做法，而非 Jev 使用 Llama 的证据。Llama 实现文档

设想输入状态、问题和候选答案，后接一个指定的决策位置。在因果注意力机制下，该最终位置可以关注所有前置输入。预测头可将其表示映射为候选概率并停止。无需生成 JSON 响应的字符；应用程序代码可以对数值结果进行序列化。

OpenJev 提供了这种方法的一个具体实例。 独立的 TheoLeeCJ/openjev 项目在其直接评分路径中使用冻结的 Qwen/Qwen3.5-4B 权重。它输入状态、标准和候选描述，执行一次前向传播，仅对指定大写答案 token 的 logits 应用 softmax。它返回所得的选项概率，而不采样答案 token 或进入生成循环。该实现使用现有的语言模型输出分数；它不需要新训练的分类头。它还支持共享状态预填充后接并行问题分支。OpenJev 方法、模型清单

另一个独立项目 AlexWortega/openjev 展示了分类头这一变体。其 Qwen3.5-4B 检查点采用末位 token 池化，并使用一个三分类 NLI 头，通过交叉熵训练来区分蕴含、矛盾和中性。其配置将其标识为 Qwen3_5ForSequenceClassification。其“交叉编码器”的描述意味着前提和假设被联合处理；这并不能确立 BERT 式的双向注意力。检查点配置

Qwen 将底层模型描述为因果语言模型，混合了 Gated DeltaNet 和注意力层。因此，这些 OpenJev 项目提供了使用因果骨干网络进行直接决策的具体示例。它们展示的是可行性，而非 TypeSafe 的 Jev 的架构或检查点，且仅凭其概率输出并不能确立校准性。Qwen 模型概览

这并不会自动将网络转变为 BERT 式的编码器。因果注意力控制哪些位置可以交换信息。自回归生成反复选择一个新 token 并将其反馈回模型。移除该循环后，注意力掩码保持不变。较早的位置仍然无法纳入后续输入，尽管最终决策位置可以访问整个前缀。这一区别源于 Transformer 的注意力结构。Transformer 论文

并行输入处理也与因果注意力兼容。在预填充期间，输入 token 已经已知，因此它们的位置可以在每一层内一起处理，同时掩码强制实施可见性。生成额外的 token 则会产生额外的顺序依赖。直接决策读出避免了这种依赖，尽管仍然需要通过模型各层进行计算。

对于 Jev 的接口而言，因果注意力提供了一个实际优势：可复用的状态计算。如果每段文档都位于每个问题之前，那么文档的表示就不依赖于后续的问题文本。它们可以只计算一次，让各个问题后缀分别关注同一份缓存前缀。Hydragen 展示了针对共享前缀序列的高效注意力机制，包括树状共享模式。这确立了一个相关的工程先例，但并非 TypeSafe 实际的 serving 实现。Hydragen 论文

一个完全双向的模型若联合处理每个文档-问题对，则会面临不同的权衡：文档的表示可能依赖于问题，从而使那种精确复用无法实现。编码器设计仍可通过单独的文档编码或受限注意力来共享计算。因此，共享计算让因果假设颇具吸引力，但并未证明它。

若干观察结果与两种可能性都相容。快速的数值输出并不能识别出注意力掩码。问题之间的隔离并不能揭示服务器使用的是分别调用还是自定义掩码。Hume 的分词器探测也未能找到与某个公开分词器的精确匹配；这并不排除某个公开基础模型经过后续修改的可能。他的 MoE 提议尤其不确定，因为 API 延迟并不能揭示硬件或活跃参数量。Hume 的证据与局限

校准是另一个独立的问题。两种架构都能输出概率分布，也都可能自信地给出错误答案。TypeSafe 表示 RLCD 针对校准决策进行训练；其文档另行说明，API 的 confidence 字段是根据答案分布计算得出的。无论是分类头还是因果主干，单凭其自身都无法建立可靠的不确定性。TypeSafe 的置信度文档

我目前倾向于采用为直接决策而改造的因果解码器。它提供了一种直接的方式来复用预训练语言能力和共享前缀计算，同时消除了生成循环。双向编码器仍然可信，包括从解码器权重改造而来的编码器。现有证据足以支撑这些设计，但要在它们之间做出定论性选择，则需要披露注意力模式和训练历史。要指定具体的基座检查点，还需要更多证据。