Jev 背后：关于它基座模型的两种假设

作者：Roy Chen（@RoyChenBuild）；文中引用 Archer Hume 的 API 探测、LLM2Vec 与 Hydragen 论文、两个 OpenJev 项目、TypeSafe 官方文档

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

Jev 提出了一个架构问题：一个返回「决策」而不是「文本」的 API，背后站着什么样的预训练模型？

TypeSafe 描述的是一个接受状态、问题和预定义答案空间的模型，返回类型化结果和概率。它的训练方法 RLCD（面向校准决策的强化学习）被表述为一条从预训练语言模型出发的后训练路径。本文引用的公开材料并没有指明底层的那个 checkpoint。

有两种可能性值得考虑：BERT 式的双向编码器，和被改造过、不做自回归生成循环就直接做预测的因果解码器。这两个都是架构假设。它们既不能锁定某个具体的模型家族，也不能证明权重的来源。

Archer Hume 的调查提供了有用的证据。基于大约一万次 API 调用，他提出的判断是：一个因果 transformer，共享状态计算、问题分支相互隔离、直接读出概率。他还怀疑底层是混合专家（MoE）。关键在于，他承认自己的实验无法区分因果解码器和双向编码器。他的重建是对观察到的行为的一种合理解释，而不是还原出来的模型规格。

第一种可能：一个为通用决策任务构建的双向编码器

BERT 确立了那个熟悉的模式：用双向注意力处理文本，然后用得到的表示做分类或其他预测。每个输入位置既能吸收前文信息，也能吸收后文信息。要产出分类结果，不需要文本生成循环。

一个类似 Jev 的实现可以联合编码状态、问题和候选答案的描述，然后给候选打分。要支持新的标签，就需要一个能解释这些标签描述的机制，而不是一个输出神经元永久固定表示「账单」「销售」「客服」的传统分类器。这是一项设计要求，不是对某个具体实现的证据——Jev 的接口让开发者可以在请求时定义问题和选项。

这个假设与产品的用途是契合的。分类和打分能从「完整证据加完整答案集」的表示中获益。但是，复制出这个接口并不能证明具备相当的能力。模型仍然需要广泛的语言理解、跨多种决策任务的训练，以及在不熟悉的输入上依然有用的概率。

这里还有一个重要区分：模型的出身和它的最终架构。编码器不一定得从 BERT 的 checkpoint 出发。LLM2Vec 证明了，一个预训练解码器可以通过改变注意力方式加额外训练，被改造成双向文本编码器。它不能解释 Jev，但它说明了为什么「原本作为解码器训练」和「当前作为双向编码器运行」这两种描述可以并存。

第二种可能：一个在文本生成开始之前就停下的因果解码器

基于解码器的模型可以在不调用生成循环的情况下提供隐藏表示和预测分数。现有实现已经支持这个区分：Hugging Face 同时提供了 Llama 的因果语言建模版本和序列分类版本。这证明的是这个设计在技术上是平常的，而不是证明 Jev 用了 Llama。

想象一下：喂进状态、问题和候选答案，后面跟一个指定的「决策位置」。在因果注意力下，最后这个位置可以注意到前面所有的输入。一个预测头可以把它的表示映射成候选概率，然后停下。不需要生成 JSON 响应的那些字符；序列化数字结果交给应用代码去做。

OpenJev 提供了这条路线的一个具体例子。独立的 TheoLeeCJ/openjev 项目在它的直接打分路径里使用了冻结的 Qwen/Qwen3.5-4B 权重。它喂进状态、评判标准和候选描述，做一次前向传播，然后只对指定的大写答案 token 的 logits 做 softmax。它返回得到的选项概率，不采样答案 token，也不进入生成循环。这个实现用的是语言模型原有的输出打分；它不需要新训练一个分类头。它还支持共享的状态 prefill，后面接并行的多个问题分支。

另一个独立项目 AlexWortega/openjev 展示了分类头那一变体。它的 Qwen3.5-4B checkpoint 用 last-token pooling 加一个三分类 NLI 头，用交叉熵训练来区分蕴含、矛盾和中性。配置里把它标为 Qwen3_5ForSequenceClassification。它被描述成「cross-encoder」，意思是前提和假设被联合处理；这并不能确立 BERT 式的双向注意力。

Qwen 把底层模型描述为一个因果语言模型，混合了 Gated DeltaNet 和注意力层。所以这两个 OpenJev 项目提供了用因果骨干做直接决策的具体例子。它们证明的是可行性，不是 TypeSafe 的 Jev 的架构或 checkpoint，而且它们输出的概率本身并不能证明校准。

这不会自动把网络变成一个 BERT 式编码器

因果注意力控制哪些位置之间可以交换信息。自回归生成会反复选出一个新 token 并把它喂回模型。去掉这个循环，注意力掩码本身没有变化。 前面的位置依然无法纳入后面的输入，即使有一个最终决策位置可以访问整个前缀。这个区分来自 Transformer 的注意力结构。

并行输入处理也和因果注意力兼容。在 prefill 阶段，输入 token 已经全部已知，所以它们的位置可以在每一层内一起处理，而掩码负责约束可见性。生成额外的 token 才引入了那个额外的顺序依赖。直接决策读出避开了这个依赖，尽管穿过模型各层的计算仍然是必须的。

对 Jev 这个接口来说，因果注意力提供了一个实际优势：状态计算可复用。如果每个问题前面都跟着同一份文档，那么文档的表示不依赖于后面出现的问题文本。它可以被计算一次，然后让各个问题后缀去注意同一份缓存前缀。Hydragen 演示了如何为共享前缀的序列做高效注意力，包括树状共享模式。这确立了一个相关的工程先例，而不是 TypeSafe 实际的 serving 实现。

一个联合处理「文档加问题」配对的完全双向模型会面对一种不同的权衡：文档的表示可能依赖于问题，从而导致那种精确的复用无法实现。编码器设计仍然可以通过分别编码文档或限制注意力范围来共享工作。所以共享计算让因果假设更具吸引力，但并不能证明它。

若干观察对两种可能性同时成立

快速的数值输出无法判定注意力掩码。问题之间的隔离无法说明服务端用的是分开调用还是自定义掩码。Hume 的 tokenizer 探测也没能识别出与公开 tokenizer 的精确匹配；但这并不排除一个做了后续修改的公开基座模型。他的 MoE 猜想尤其不确定，因为 API 延迟不暴露硬件，也不暴露激活参数量。

校准是另一个独立问题。两种架构都能输出概率分布，两种也都可能自信地出错。TypeSafe 说 RLCD 训练的是校准决策；它的文档另外说明了 API 的 confidence 字段是从答案分布算出来的。分类头和因果骨干，单靠它们自己，都不能确立可靠的不确定性。

我目前更倾向因果解码器改造而来的直接决策模型。它提供了一条直接的路：复用预训练语言能力和共享前缀计算，同时消掉生成循环。双向编码器仍然可信，包括从解码器权重改造而来的那种。这些证据足以支撑这些设计的动机，但要在两者之间做出结论性的选择，需要披露注意力模式和训练历史。要指名一个具体的基座 checkpoint，则还需要更多证据。

链接

原文（Roy Chen，本刊译）：https://x.com/RoyChenBuild/status/2100813649036390489

TypeSafe 问题原语文档：https://docs.typesafe.ai/primitives

TypeSafe 置信度文档：https://docs.typesafe.ai/confidence

AlexWortega/openjev（分类头变体，文中引用）：https://huggingface.co/AlexWortega/openjev

LLM2Vec 论文：https://arxiv.org/abs/2404.05961

Hydragen 论文：https://arxiv.org/abs/2402.05099

说明：文中提到的 Archer Hume 的 API 探测调查、以及 TheoLeeCJ/openjev 项目，原文给出的是引用标注而非直链；本刊未能验证到可访问地址，故不列出，以免给出失效或错误的链接。

#模型架构 #注意力机制 #开源复现