# OpenJev 距离 Jev 仅差 3.8 分，但有个 102 行的星号注释

**Summary:** OpenJev 的 4B 基线在选定的 102 行子集上与 Jev 公布的 88.3% 达成 84.5% 的一致率。我认为这是一次对类型化决策接口的可信测试，而非证明 Jev 本身已被复现。

- Canonical: https://markhuang.ai/zh/news/openjev-3-8-point-102-row-asterisk
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-18
- Section: News
- Tags: OpenJev, Jev, 本地 AI
- Source: [OpenJev](https://openjev.com/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一个紧凑的本地决策引擎将概率 token 发送至玻璃边界与封闭的黑盒系统](https://cdn.markhuang.ai/news/openjev-3-8-point-102-row-asterisk/hero.webp)

*OpenJev 让决策接口变得可检查。我会一直关注这个玻璃边界：匹配接口和复现其背后的模型是两回事。*

[OpenJev 的浏览器演示](https://openjev.com/)用一个小模型跑起了 TypeSafe 随 Jev 推出的那套类型化决策接口，只不过模型在本地运行。它在选定的 TypeSafe 子集上跑出来的结果是：3.01 GB 的 Qwen3.5 4B 浏览器端产物达到 84.5% 的一致率，Jev 公布的数据是 88.3%。3.8 个百分点的差距已经够近了，值得认真看看——但这个对比有一个很大的前提条件。

在我看来，OpenJev 的意义不在于替代 Jev，而在于拆解这个产品理念。它证明开发者可以从普通开源模型中获得大部分接口模式：提供状态、定义允许的选项，直接读取概率，不用等模型生成答案。但它没有证明 Jev 未公开的架构或训练已被复现。

这个区别改变了我的判断。我会用 OpenJev 测试这种新接口是否该加入技术栈，但不会把最接近的基准数字当作底层系统可互换的证据。

## 接口先跑出来了

[OpenJev 仓库](https://github.com/TheoLeeCJ/openjev)对范围的说明异常直接。它明确说 Jev 是封闭服务，这个项目用开源模型复现的是接口模式，不是 Jev 的模型或训练。基线做法是把非结构化状态、运行时条件和类型化选项喂给 Qwen3.5 4B，然后读取声明选项的 logits，归一化成概率。不需要生成答案句子或 JSON 对象。

这已经够用了。Agent 的很多决策本来就是有界的：选一个队列、批准重试、判断证据是否支持某个结论。让聊天模型为这种选择写一段文字或 JSON，软件还得把输出解析回分支逻辑。OpenJev 直接把分支变成了模型接口。

```mermaid

flowchart LR
    A[状态和运行时条件] --> B[开源模型]
    C[声明的选项] --> B
    B --> D[读取选项 logits]
    D --> E[条件概率]
    E --> F{业务策略}
    F -->|执行| G[受限操作]
    F -->|放弃| H[人工审核]
```

最后这个分支是我的判断，不是模型的。OpenJev 警告说，它的分数取决于你提供的选项。这些不是校准后的置信度，也没法涵盖开发者忘记列进去的答案。再快的概率也需要一套策略来决定什么时候执行、什么时候放弃、什么时候交给人审。

## 102 行对比需要标注清楚

标题里的对比数据确实亮眼，但很容易过度解读。OpenJev 报告称，在 20 个案例共 102 行数据上，直接读 4B logits 的众数一致率为 0.845，Jev 公布的数据是 0.883。注意，这个项目并没有调用 Jev 的线上接口——它是从 TypeSafe 公开记录中重建出能对齐的行来做对比，而且明确说这覆盖不了 TypeSafe 报告的 711 行汇总数据。

众数一致率也不是通用准确率。它只说明 OpenJev 的选择在选定数据中与众数结果匹配的频率。它没法告诉我工作流里错误操作的代价、这些概率在我的流量上是否校准，或者任一系统在输入分布偏移后的表现。

这延续了我[第一次解读 Jev 时](https://markhuang.ai/news/jev-schema-guarantee-wrong-decision)的担忧。保证输出形状可以消除解析失败，但没法保证选出来的选项是对的。OpenJev 让这个边界更容易看清，因为它的 prompt、修订记录、行级输出、已知失败和校验和都是公开的。

## 速度结果才是更有力的论据

OpenJev 的系统对比更有说服力，因为它固定了模型和工作负载。在同一块 RTX 3090 上，同样的 Qwen3.5 4B 模型通过读取类型化 logits，1.023 秒内回答了 21 个二元条件。生成紧凑数组则耗时 5.332 秒，产生 111 个输出 token。直接路径快了 5.21 倍。

但有个细节值得留意。生成的选择在 21 个条件中有 18 个和直接 argmax 结果一致——换了一种读取方式，三个决策就变了，模型和状态完全相同。这是在提醒我们：推理管线不是中性优化，它会影响结果。

前缀复用也给了一个不错的数据。在自有工作负载（37 个状态 × 21 个条件）上，全新评分每秒处理 2.33 个决策，并行后缀达到了 20.03。不过项目也坦率地报告，实验性的 BF16 复用路径和全新评分相比，777 个 argmax 里有五六个结果不一样。这种披露我欣赏——生产团队得自己判断，这些差异算噪声还是不可接受的漂移。

## 浏览器演示是一次规模测试

浏览器页面提供了三个本地档位：Qwen3 0.6B 下载 639 MB，MiniCPM5 2B 下载 1.56 GB，Qwen3.5 4B 下载 3.01 GB。页面给出的平衡准确率从 44.0% 一路升到 68.6%、81.3%。权重留在浏览器缓存里，输入不会离开页面；同时也提醒了大模型可能跑不动某些设备，量化会影响质量和速度。

这里有个实际的产品教训。本地隐私、零输出 token 听起来很干净，但设备预算仍然决定能力上限。最小的浏览器模型胜在方便，不等于好用。评估这个模式的团队应该按错误成本来选模型，而不是按下载体验。

## 复制边界仍是真实成果

社区对“Jev”这个标签争论不休。在 [LocalLLaMA 的一个讨论帖](https://www.reddit.com/r/LocalLLaMA/comments/1whxf90/localjev/)里，有人指出零样本分类器早就有了，一个 Qwen 套壳不等于 TypeSafe 宣称的架构。也有人反驳说，概率输出和并行推理本来就是语言模型的自然能力，有个方便的本地接口有什么不好。

两种说法都有道理。OpenJev 不该背 Jev 私有系统的账，但也不必背。如果一个可复现的 4B 基线够快、能做类型化决策、能胜任路由或验证任务，开发者就多了一个选项，TypeSafe 也有了更有意义的对比对象。

> **Info:**
>
> 我的评估规则：用 OpenJev 在带标签的本地数据上测试接口，和现有规则、分类器、专用 LLM 调用做对比。动作阈值和放弃路径放在模型外面。

我期待的下一个基准不是更大规模的模仿赛，而是一个错误有真实代价的工作负载：漏掉的欺诈、不必要的升级、错误的重试、证据不足就发出去的答案。OpenJev 已经把机制摊开给你看了。现在轮到应用方来证明，这些决策值得自动化运行。