Jev Your Engines: Seven Open Decision Models vs. a Generative LLM

启动引擎：七种开源决策模型与生成式LLM的对决 | Towards Data Science

人工智能

启动引擎：七种开源决策模型与生成式LLM的对决

对路由准确性、延迟和输出可靠性的实际比较

Lambert Leong

2026年10月15日

14分钟阅读

在Google上推荐我们

分享

开源Jev决策模型与生成式LLM的对比。（作者提供）

AI决策引擎选择可用操作的示意图。配合我们对七种开源Jev风格项目和生成式LLM基准在银行业务请求路由中的比较，包括准确性、灵活性、生成的标记数和延迟。（作者提供）

上一篇文章：当所有你拥有的都是解码器时，每个决策看起来都像生成

简要总结

• Jev风格模型使代理能够在不生成答案的情况下做出决策。对于路由或工具选择等有限选项，它们会评估可用选项并返回类型化决策，为代理提供直接替代生成和解析答案标记的方案。

• Kev在准确性上领先；Verdict也优于LLM基准。Kev在固定路由和动态候选选项上均达到98%。Verdict在动态候选选项上达到89%，而LLM（基准）Qwen3-0.6B在动态候选选项上为66%，在固定路由上达到83%。JSON生成仍优于三种Qwen读取配置。

• 零生成答案标记，Kev和Verdict的延迟观察值较低。两者均未生成答案标记，而Qwen JSON生成每请求约生成10个标记。记录的请求延迟中位数为Kev的125–130毫秒和Verdict的17–18毫秒，而LLM基准在两个面板中的延迟为331–357毫秒。

下载入门套件，尝试决策模型，探索基准测试，并将JSON生成与直接读取结果进行比较。

为什么我们要测试决策模型

在第一部分，我们探讨了一个一直困扰我们的问题：当软件只需要一个选择时，使用语言模型逐标记生成答案。一位银行客户说：“我为同一笔转账被收取了两次费用。”下一步是选择一个支持路线。让模型生成{"route": "duplicate charge"}可以解决问题，但这也为有限决策增加了文本生成和解析的步骤。

直接评估可用选项的想法引起了我们的注意。我们想知道开源实现是否真的能处理这个任务，以及使用它们能带来什么好处或需要放弃什么。它们能选择正确的路线吗？当可用选项变化时，它们仍然能做到吗？仅仅提示一个小型语言模型是否同样有效？

路由器可能有一个固定的部门列表，而代理的可用工具或操作可能会随着工作流程而变化。我们想知道这些决策接口在这两种情况下是否都有用。我们比较了七种开源项目和一个Qwen JSON生成基准，在银行业务请求中测试了稳定路由列表和动态候选菜单的情况。以下是运行这些项目后我们的发现：它们选择路线的可靠性，可用选项变化时会发生什么变化，以及候选评分相比生成JSON能带来什么优势。

为什么运行时候选对象会改变问题

一个候选者代表一个可用选项。基于候选者的接口允许工作流为当前请求提供可用的路由或工具，模型会对这些选项进行评分。调用者可以在不为每条路由添加永久输出槽的情况下更改这些选项。对我们而言，这种灵活性是探索这些项目的主要原因。传统的分类器需要为每条路由设置永久输出槽，当新增路由时需要进行适应性调整。

一个决策合同，三种问题类型

同一张支持工单可能引发多个有界问题。从概念上讲，决策请求可能如下所示：

json

{
"state": "我为同一笔转账被收取了两次费用。",
"questions": {
"route": {
"type": "choice",
"candidates": ["重复收费", "转账延迟", "关闭账户", "现金提取"]
},
"escalate": {"type": "yes/no", "question": "这是否需要紧急人工处理？"},
"urgency": {
"type": "score",
"levels": ["低", "中", "高"]
}
}
}

每个项目都有自己的线格式和支持的问题类型。共享的核心理念非常直接：提供状态，定义允许的回答，接收类型化结果，并让确定性代码决定如何使用结果。调用者可以进行路由、应用经过验证的阈值，或将案例转交给人员处理。

首次运行时，请遵循Kev本地快速入门、Verdict项目README、Laya快速入门、OpenJev设置、AnyJev设置、Simple Jev服务器说明或NanoJev CUDA快速入门。每个链接均指向用于比较的修订版本的项目文档。安装前请检查硬件和软件包要求。

七个可供尝试的开源项目

这七个项目提供了进入有界决策的不同路径。概述部分将它们的文档设置与银行准确性测量结果区分开来。我们添加了直接的Qwen JSON生成作为参考LLM基线。

七个开源Jev风格项目和一个生成式LLM基线：文档设置、在固定路由和变化候选菜单上的准确性，以及观察到的行为。（图片由作者提供）

Kev、Verdict、Laya、OpenJev、AnyJev、Simple Jev、NanoJev和LLM（基线）Qwen3-0.6B在银行请求路由上的比较。Kev在固定路由和变化候选菜单上均达到98%的准确性。Verdict分别达到86.5%和89%，而生成式LLM基线分别为83%和66%。表格总结了文档设置和观察到的行为；参考数字标识文章中的项目来源。（图片由作者提供）

启动链接指向官方README，这些README已固定到测试的修订版本。选择运行时请检查它们的硬件和软件包要求。

这些项目可分为三大类。训练过的评分器如Kev、Verdict、Laya和NanoJev拥有可直接对选项进行评分的模型。无需训练的读取器如AnyJev和Simple Jev从语言模型输出中推导出评分。服务层如OpenJev向选定的后端暴露共享接口。这些分类描述了实现选择；比较仍然属于每个具体项目、检查点和设置。

我们如何比较它们

一个请求，两条执行路径。生成式路径必须生成并验证字符串；单次评分器会返回对提供的候选选项的评分。（图片由作者提供）

Comparison of generative LLM routing and single-pass candidate scoring for AI decision tasks. The generative path constructs a prompt, generates answer tokens, and validates JSON. The scoring path evaluates supplied choices and returns scores for route selection or abstention without generating answer tokens. (Image by Author)

We used BANKING77, a dataset of short banking requests labeled by intent, to compare seven open projects. We also added a plain JSON-generation baseline using the same pinned Qwen3-0.6B checkpoint as AnyJev, Simple Jev, and OpenJev.

我们选择了十二个意图，并将测试分为两种设置。固定路由意味着每个请求都获得相同的八条银行路由菜单。动态候选意味着每个请求都会获得自己的四条可能路由的随机菜单：正确路由和三个干扰项。动态请求来自另外四个意图，其干扰项从十二个完整意图池中采样。

除了路由准确性，我们还记录了生成的标记数、格式失败次数和请求延迟，以了解每种执行路径涉及的内容。以下是请求的划分方式：

面板

每次重复中的请求

抽样

问题

固定路由

200

从八个意图中每个意图抽取25个请求

配置是否每次都能从相同的八条路由中选择？

动态候选

100

从另外四个意图中每个意图抽取25个请求

当每个请求提供四个候选（包括正确路由和三个干扰项）时，能否进行选择？

菜单示例

固定路由保持菜单不变。对于“Could you please activate my card”，模型接收到以下选项，按此顺序排列：

text

activate my card
change pin
pending card payment
top up by card charge
top up failed
verify my identity
why verify identity
wrong exchange rate for cash withdrawal

正确路由是 activate my card，Qwen JSON基线选择了它。每个固定路由请求都会收到相同的菜单，无论客户需要的是卡片激活、身份验证还是充值失败的帮助。

动态候选会根据每个请求改变菜单。选项按模型接收到的顺序显示：

客户请求

候选菜单（按提供的顺序）

Qwen选择

“There is a charge on my card that I did not make”

activate my card → wrong exchange rate for cash withdrawal → pending card payment → card payment not recognised

card payment not recognised

“There is a payment that is not mine in the app. Please advise”

card payment not recognised → why verify identity → top up by card charge → contactless not working

两个请求的正确路由相同：card payment not recognised。但周围的选项会变化，该路由在一个菜单中出现在末尾，在另一个菜单中出现在开头。它也属于动态面板使用的额外意图，因此在上面的固定菜单中缺失。模型必须从请求提供的选项中选择；我们没有在不同菜单之间重新训练它。

我们抽样干扰项并打乱每个动态菜单，然后给每个项目相同的保存消息和有序菜单。这测试了在选项和答案位置变化时的路由能力。要单独衡量重新排序的影响，需要重复完全相同的消息和候选集，但以不同顺序呈现；此基准未隔离这种影响。

保持比较一致性

这些示例来自固定版本的BANKING77数据集中每个选定意图的前25个测试记录。所有项目都接收到相同的候选描述和请求顺序，包括动态面板中随机排列的菜单。每个项目保留其官方提示和读出策略；JSON基线接收到相同的消息和菜单。

我们对每个300次请求的比较进行了两次重复测试，包括新的JSON基线。每种配置在两次重复测试中生成的单个预测结果完全一致。准确率是正确路径所占的比例；明确的弃权和无效生成响应均计为错误。宏F1为每个目标路径赋予相同的权重。

两个面板中的表现

模型能否在相同路径中进行选择？

对于200个请求中的每一个，模型都看到相同的八条路径。Kev以98.0%的准确率（196个正确请求）领先，其次是Laya的92.0%（184个）。Verdict达到86.5%，在8个请求上弃权。LLM（基线）Qwen3-0.6B达到83.0%；其他配置从AnyJev的79.5%到NanoJev的52.0%不等。

表1. 固定路径。准确率和宏F1来自任一重复测试；单个预测和显示指标在两次重复中完全一致。

| 配置 | 准确率 | 宏F1 | 弃权 | |------|--------|------|------| | Kev 0.8B | 98.0% | 0.980 | 0 | | Laya | 92.0% | 0.915 | 0 | | Verdict | 86.5% | 0.870 | 8 | | LLM（基线）Qwen3-0.6B | 83.0% | 0.810 | 0 | | AnyJev L0 + Qwen3-0.6B | 79.5% | 0.771 | 0 | | Simple Jev + Qwen3-0.6B | 79.0% | 0.763 | 0 | | OpenJev + Qwen3-0.6B | 74.7% | 0.747 | 0 | | NanoJev | 52.0% | 0.486 | 0 |

图1. 每次重复测试中相同200个固定路径请求的准确率。使用Colab GPU实例，批量大小为1；Laya使用bfloat16，其他配置使用float32。Qwen生成在单独的GPU会话中进行。（图片由作者提供）

在200个银行请求中，七种开源Jev风格配置和LLM（基线）Qwen3-0.6B在每次请求都提供相同八条路径时的准确率比较。Kev以98%领先，其次是Laya的92%和Verdict的86.5%，而生成式LLM基线达到83%。实验使用Colab GPU实例。（图片由作者提供）

如果路径列表发生变化会怎样？

在此场景中，每个请求提供四个候选选项，包括四个附加意图中的正确路径之一。Kev再次以98.0%的准确率（100个请求中正确98个）领先。尽管在固定路径中排名低于Laya，Verdict仍以89.0%（89个请求）紧随其后。Laya达到74.0%。

表2. 变化候选。宏F1是四个目标意图的平均值；预测到干扰路径之一即视为错误。

| 配置 | 准确率 | 宏F1 | 弃权 | |------|--------|------|------| | Kev 0.8B | 98.0% | 0.990 | 0 | | Laya | 89.0% | 0.929 | 3 | | Verdict | 74.0% | 0.748 | 66.0% | | Simple Jev + Qwen3-0.6B | 60.0% | 0.738 | 6 | | OpenJev + Qwen3-0.6B | 58.0% | 0.703 | 6 | | NanoJev | 56.0% | 0.690 | 6 | | LLM（基线）Qwen3-0.6B | 17.0% | 0.249 | 6 |

图2. 每次重复测试中相同100个变化候选请求的准确率。与固定面板相比，此面板同时改变了目标意图和候选列表。（图片由作者提供）

在100个银行请求中，每个请求提供四个随机排列的候选路径：正确路径和三个干扰项。Kev达到98%，Verdict达到89%，而LLM（基线）Qwen3-0.6B仅为66%。此面板评估变化候选菜单和与固定路径面板不同的目标意图。（图片由作者提供）

最引人注目的结果是，接受新的候选列表和从中做出良好选择是两种不同的能力。NanoJev 处理了动态候选接口，但其发布的游戏训练检查点在这些银行请求上的准确率仅为 17%。动态候选使新的选择变得可表达，但并不能保证模型知道如何处理它。

三个 Qwen 的表现相近：固定路线达到 79.0–79.5%，动态候选达到 56–60%。纯 JSON 生成分别达到 83% 和 66%。这让我们感到意外：对于这些 Qwen 配置，移除答案生成并未提高路由准确率。提示和读取策略仍然至关重要。

生成基线：为什么不能只提示 LLM？

第一部分探讨了代理为何需要为小决策生成标记。当我们将 Qwen 权重固定并请求 JSON 时发生了以下情况。

该基线使用 Qwen/Qwen3-0.6B 的 c1899de289a04d12100db370d81485cdf75e47ca 版本，与 AnyJev、Simple Jev 和 OpenJev 在此处的实现完全相同。它看到相同的 BANKING77 测试消息和候选菜单。禁用推理，采用贪婪解码，限制为 40 个新标记，且没有重试。所需响应是一个包含一个路由字段的单个 JSON 对象，该字段命名允许的路由 ID。

质量优先：在两个面板上，生成的表现都优于三个 Qwen 读取设置。在严格合同下，它在 200 个固定请求中正确选择了 166 个，在 100 个动态候选请求中正确选择了 66 个。Verdict 的紧凑原生模型在动态面板上达到了 89%，Kev 达到了 98%。

然后是输出合同：所有九个动态失败都是用 markdown 栏包围的有效 JSON 对象。严格的 JSON 仅解析器拒绝了这些响应。这是一个格式错误，而不是 JSON 语法错误或菜单外的路由。剥离栏的包装器会改变策略，应作为独立配置进行测量。类型化候选输出避免了这种特定的生成字符串失败模式。

最后是每请求的工作量：基线在固定路由上平均发出 9.71 个标记，在动态候选上发出 9.96 个标记（包括 EOS）。在普通贪婪解码中，T 发出的标记需要一次预填充加上 T−1 次解码调用。原生评分器和 logit 读取器发出零个自回归答案标记。AnyJev L0 仍在固定面板上评估了八次选项旋转，在动态面板上评估了四次；零个生成标记并不意味着每个实现都对应一次模型通过。

表格显示了重复一次的暖请求测量结果。延迟描述了每个记录的请求路径；下面的范围部分解释了时间边界。

生成的标记（平均）

p50（毫秒）

p95（毫秒）

模式失败

估计成本/1000 请求

固定

0.00

130.0

134.2

0.0%

$0.091

动态

124.7

127.4

$0.087

Verdict 151M

18.2

19.9

$0.013

16.9

19.5

$0.012

AnyJev L0 + Qwen

370.7

378.6

$0.258

187.3

191.5

$0.131

9.71

330.7

507.2

$0.247

9.96

356.8

471.2

9.0%

$0.250

GPU 估计假设每 GPU 小时的参考计算成本为 2.50 美元：

每 1000 请求的成本（美元）= 平均暖启动秒数 × 1000 / 3600 × GPU_USD_PER_HOUR

评估范围与测量边界

七个项目运行和生成后续测试在独立会话中使用了Colab GPU，批量大小为1。Laya使用了bfloat16；其他配置使用了float32。现有SDK计时和HTTP往返覆盖了不同边界。生成计时器包含提示构建、分词、生成、解码和验证（带CUDA同步）。观察到的延迟差异描述了这些配置和请求路径；它们并未单独隔离架构加速。GPU估计值排除了模型加载、空闲时间、批处理和额外生产基础设施开销；记录的请求开销仍被包含。服务器报告的序列化标记不计入自回归回答标记。

面板覆盖了十二个BANKING77意图。四个可变面板意图被排除在固定选择之外；它们是否未在模型预训练中出现尚不清楚。提示策略、模型大小和训练历史存在差异。此测试未涵盖所有银行业务意图、可变候选数量、长文档、多语言行为或生产工具使用。它未验证校准或自动化阈值。概述中的CPU、浏览器和集成能力来自项目文档。从您自己的工作流程中测试有用的候选描述和保留请求的回退策略。

您应该尝试哪个项目？

• 如果您希望在这两个路由面板中获得最强的初始性能基准，请尝试Kev。其结果在此表现最佳，其README文档记录了本地服务器和小模型选项。其本地服务器是测试您自己的路由的实用入口点。

• 如果运行时候选项重要且您需要紧凑的原生模型，请更仔细查看Verdict。它在可变候选面板中排名第二，并记录了CPU和浏览器路径。

• 如果您需要带有集成选项的打包Python项目，请考虑Laya。其Python集成可能符合您的技术栈；从此处使用的已发布英文检查点开始。

• 如果您希望将相同接口路由到不同的语言模型后端，请探索OpenJev。在此运行中，其Qwen配置在三种共享Qwen方法中，以微弱优势取得了最高的可变候选得分。

• 如果您希望从因果语言模型中获得无需训练的读出结果，请在您的提示上比较AnyJev和Simple Jev。它们的读出流程存在差异，且在此两个面板测试中均未超过训练过的评分器。

• 如果您希望研究或训练用于游戏或动作决策的原生动态候选架构，NanoJev是一个有趣的项目。其发布的检查点与这些银行业务请求匹配度较低，因此我们不会基于此测试选择它用于银行业务路由。

那么所有这些意味着什么？

开源项目使Jev风格的决策接口成为我们可以本地探索的对象。在这次小型银行业务测试中，Kev在两个面板上都是最强的配置。Verdict在可变候选测试中的表现优于固定路由测试，而NanoJev则表明，灵活的候选接口本身并不能保证有用的准确性。这些发现为我们提供了测试方向，而非通用的最优解。

我们带入新项目的关键点是一个小型对比：原生评分器、直接JSON生成，以及从已有模型的读出结果。给它们相同的请求和菜单。一起测量正确路由、无效输出、延迟和弃权情况。这使选择成为一个您可以检查的工作流决策。

证据与参考文献

以下项目的功能和设置路径均来自已固定的项目文档。基准百分比、宏F1值和弃权次数均来自上述保存的对比分析。它们属于不同类型的证据。

[1] TypeSafe AI. 介绍 System One 模型与 Jev.

[2] Palmer, J. Kev. 已固定 README 和本地快速入门.

[3] Heman10x. 评估结果. 已固定 README.

[4] NandhaKishorM. Laya. 已固定 README 和快速入门.

[5] lookski. OpenJev. 已固定 README；所测服务器使用了本地 Qwen 后端.

[6] Zhang 等. AnyJev. 已固定 README.

[7] Featherless AI. 简易 Jev. 已固定 README.

[8] TianyuCodings. NanoJev. 已固定 README 和 CUDA 快速入门.