Jev是否被高估？我们在4个真实企业任务上进行了测试。

作者：@eddiedzhou, @mr_cheu, @MatZhao, Aviral Singh, Manav Agrawal

Jev是一个用于做出类型化决策的模型。你向它发送上下文信息以及一组固定的问题和选项，它会返回选择、分数和概率，而不是生成文本。它是一个“系统一”模型！

但分类并非新事物，结构化输出、小型模型或从对数概率中读取概率也不是。这段历史解释了人们对Jev反应不一的部分原因……

怀疑者的观点有其道理，但Jev确实在这个生态系统中占有一席之地。要理解这一点，我们需要梳理完整的解决方案空间。

替代方案有哪些？

当系统需要一个标签、分数或是否的答案时，有四种合理的选择：

Jev的优势在于：团队无需收集新的训练集即可更改问题和选项，同时避免了部署模型优化的工作。没有人应该对此嗤之以鼻。“我们自己也能构建”这一点适用于大多数基础设施产品。

开源复现使其创新性主张受到制约。使用Qwen和SGLang、DiffusionGemma和vLLM，以及Kev的实现复现了其大部分API或模型形态。

在n=764的测试中，Jev达到85.7%，Kev-8B为79.6%

在n=764的测试中，Jev达到85.7%，Kev-8B为79.6%

Parallel的外部测试同样发现Jev在重排序方面具有竞争力，而专用模型仍在两项分类任务中胜出。

我们在Glean的实践

这就引出一个实际问题：Jev的零样本灵活性与托管推理相结合，在何时能真正超越替代方案？我们在Glean测试了四个有界的决策场景，这些场景我们已有基准，可以比较真实的企业质量。这些基准大多是基于LLM的系统，因此我们知道在这些实验中，成本和延迟预计会有两个数量级的改善。结果范围从明显差于生产环境到比基于LLM的路由器更快且更准确。

查询分类

查询分类将请求映射到下游系统使用的广泛任务。这是一个天然的Jev工作负载，因为虽然标签空间是预先已知的，但分类体系可能变化得比微调分类器重新训练的速度更快。

对于此实验，我们专注于衡量Jev与我们的生产/基准预测（基于LLM）的一致性。我们预期并观察到Jev在离线吞吐量上有大幅提速，因此我们将一致性作为质量的一个便捷代理指标。我们还与Laya（一个开源权重决策模型）以及微调的Laya作为基准进行了对比。这次微调可以在几小时内本地运行，并且该模型也足够小，可以在开发者机器上运行。

作为一个方便的、无需训练的现成模型，Jev明显优于Laya，但略显不足为奇的是，微调使Laya表现出色，特别是考虑到性能数据。其代价在于获取优质标签和建立训练的工作量。当任务较新或其标签在变化时，Jev可能仍然更具吸引力。

模型路由：专家转移

模型路由是与查询分类相关的问题。在此，我们将模型路由构建为专家转移，即我们的系统选择哪个专家/模型应处理请求。我们的生产基准目前是在系统工具链的智能循环中，让一个LLM原生地做出该决策。虽然这自然地测试了Jev能否用有界决策替代生成式调用，但一个重要的技术限制是，Jev在发生非转移时，会严格增加一次调用。这与生产基线不同，在非转移情况下，生产基线可以通过相同的首次LLM调用开始工具调用工作。

我们使用了我们简化版的生产路由，仅包含3个专家，通过更新的Jev路由器重放了751个可比较的黄金条目，并将其选择的路由与我们现有的基于提示的路由器（由传统LLM驱动）进行比较，同时衡量其相对于黄金标签的准确性。

我们还单独分析了40个现有路径确实进行了专家转移调用的条目（样本量n较小），并比较了这些条目上的调用延迟。

每条目的中位数加速比为8.1倍。这是目前最强的内部Jev结果之一：在这个有界的路由任务上，Jev既更准确又大幅更快。差值的幅度表明，我们在非专家路由请求上承担的“阻塞”开销可能是一个很好的权衡。请注意，这仍然是离线黄金集比较，延迟样本仅包含40个正向转移，因此还有更多风险需要降低和测试！

重排序

一个与Glean息息相关的问题！下面，我们的生产基线是Glean现有搜索堆栈产生的顺序。此实验随后要求Jev重新排列最多50个结果。

我们尝试了四种方式通过Jev的类型化输出来表达相关性：

我们在一个内部评估集上运行此测试，在该集上用户无法访问所有规范项，因此绝对数字并不反映我们的生产排名——但相对数字具有参考价值。

Jev的“选择”是最强的表述方式。在4,855个配对的捕获搜索查询对照测试中，移除了基于生产的平局处理后，结果如下：

Jev选择每次查询的成本约为0.00044美元，在离线测试中p50延迟为0.195秒。但它在平均查询中为大约41个候选中的37个分配了相同的分数。使用生产顺序来解决这些平局将Recall@6从40.2%提高到44.3%，使得未经修正的结果看起来比Jev分数本身所支持的更强。这里有很多注意事项，但方向性上来看，Jev是一个廉价、高效的基准，而非Glean生产排名器的替代品。

引用支持判断

引用判断涉及两个相关问题：需要证据的主张是否有足够的引用（引用召回率），以及被引用的来源是否实际支持归于它们的主张（引用准确率）？乍一看，因为输出/标签空间是有界的（类似于大多数判断设置），这似乎非常适合Jev。然而，标准很复杂，可能需要分解多个主张——此外，Jev不会产生我们常用于错误分析的推理过程，因此在质量和可用性方面都存在一些风险。

我们在一个真实的1448字生产评估响应上测试了Jev，保持响应和引用证据固定。我们将其共享的精确率和召回率通过方式与GPT-5.6 Luna（不使用推理和使用xhigh推理）进行了比较。为了减少差异，我们每个判断器运行了三次。

请注意，计时是方向性而非端到端的：Jev报告的是顺序客户端挂钟时间，而Luna行则是模型调用时长的总和。成本包括观察到的缓存。

我们还在相同的28个段落上比较了一致性。更改的项目意味着判断器在至少一次相同的三次输入运行中改变了对该段落是否具有足够引用覆盖的判断。成对不一致计数每个段落在三个运行对中的情况，每个判断器有84次比较。

Jev唯一的改变是某个段落是否需要引用；其原始的召回类别没有改变。因此，Jev在段落级别的引用覆盖判断比两种Luna配置都更具可重复性。

我们并非得出结论认为这使Jev成为更准确的判断器（系统应用了不同的支持标准和评分分母，且我们没有时间进行独立的人工标注）。但即使使用xhigh推理（大约使Luna的模型时间翻了三倍），它仍然不如Jev一致。该结果支持Jev作为一种快速、廉价且相对可重复的方式来实现狭窄的引用策略。

实验结论与实践指南

在某些情况下，Jev作为传统LLM和微调分类器的低摩擦替代品而大放异彩。当基准很强（重排序），或微调一个小模型很容易（查询分类）时，其优势就较弱。有迹象表明某些任务质量更强（模型路由），也有迹象表明一致性和稳定性更好（引用判断）。在我们一些最重要的工作负载中，它提供了相对于传统LLM预期的成本和延迟优势。

以上结果提供了良好的方向性指引，在Glean，我们对Jev非常兴奋。经过更多步骤（主要是运营就绪性，如数据驻留和保证）后，我们计划将Jev部署到其中一些用例中。此外，Jev将在本周我们内部的黑客马拉松中发挥重要作用，我们很乐意分享更多结果！

最后是一些通用建议——如果输出可以预先列出，请用Jev作为基准。如果任务和标签稳定且量大，也请将微调分类器作为基准。如果调用需要生成查询、解释或其他动态文本，请保留一个生成式模型在循环中。工具调用就是一个好例子：Jev可以帮助选择工具，但大多数Glean工具仍需要动态生成的参数（如搜索查询）。

Jev并没有改变分类器已经存在的事实。它使一个优质的零样本分类器更容易使用。即使它并非每个AI系统的新基础，这也是一个扎实的产品。