作者：@eddiedzhou、@mr_cheu、@MatZhao、@CosmicPegasis19、@manav_ai
Jev 是一个用于做出类型化决策的模型。你向它发送上下文以及一组固定的问题和选项，它会返回选择、分数和概率，而不是生成文本。它是一个“System One”模型！
但分类并不新鲜，结构化输出、小模型或从 logits 中读取概率也不是。这段历史解释了为什么人们对 Jev 的反应会出现分歧……
怀疑者确实有道理，但 Jev 在这个生态系统中也确实有自己的一席之地。为了更好地理解这一点，我们应该把整个解决方案空间梳理清楚。
有哪些替代方案？
当系统需要一个标签、分数或是非答案时，有四种合理的选择：
方案
使用理由
权衡取舍
通用 LLM
零样本、灵活，还能生成论据或解释。可以说通过推理时计算（reasoning）实现了“更高的智能”。
为了一个小决策却要承担自回归模型的延迟和成本
开源零样本分类器
便宜、本地运行、可控
质量不稳定；你需要自己负责模型选择和部署
微调分类器
对于标签质量好、流量稳定的任务，通常是最佳选择
需要收集数据、训练、部署，还要应对数据漂移，且分类体系不够灵活
Jev
在简洁的托管 API 背后提供零样本的灵活性
质量因任务而异，不生成文本，且依赖供应商
选择 Jev 的理由：团队可以随时更改问题和选项，无需重新收集训练集，同时也省去了高质量部署模型的麻烦。没人应该对此嗤之以鼻。“我们自己也能做”这句话对大多数基础设施产品都成立。
各种开源复现让“新颖性”的说法冷静了下来。使用 Qwen 和 SGLang、DiffusionGemma 和 vLLM 以及 Kev 的实现，在很大程度上复刻了它的 API 或模型形态。
在 n=764 的测试中，Jev 为 85.7%，Kev-8B 为 79.6%
Parallel 的外部测试同样发现 Jev 在重排序任务上很有竞争力，不过在两个分类任务中，专用模型依然胜出。
我们在 Glean 的观察
这就引出了一个实际问题：Jev 将零样本灵活性与托管推理相结合，到底在什么时候能真正胜过其他方案？我们在 Glean 测试了四个边界明确的决策场景，这些场景已有基线，可以对比真实的企业级质量。其中大多数基线都是基于 LLM 的系统，因此在这些实验中，我们预期成本和延迟会有两个数量级的改善。结果参差不齐：有的明显不如生产环境，有的则比基于 LLM 的路由器更快更准。
查询分类
查询分类会将请求映射到下游系统使用的宽泛任务类别。这是 Jev 的天然适用场景，因为虽然单个请求的标签空间是预先确定的，但分类体系的更新速度可能快于微调分类器的重训速度。
在这个实验中，我们重点关注 Jev 与生产环境/基线预测（基于 LLM）的一致性。我们预期并观察到 Jev 在离线吞吐量上有大幅提升，因此用一致性作为衡量质量的简便指标。我们还以 Laya（一个开放权重的决策模型）以及微调后的 Laya 作为基线。这次微调只需几小时就能在本地完成，而且模型足够小，可以在开发机上部署。
实验
宽泛任务一致性
性能
Jev 零样本
66.8%
~
12 分钟（并发数为 4
）
基础 Laya
35.9%
~
90 秒（本地开发机）
微调 Laya
74.5%
~
90 秒（本地开发机）
作为一个方便、免训练的现成模型，Jev 明显优于 Laya；但不出意料的是，微调让 Laya 大放异彩，尤其是考虑到它的性能数据。代价则是获取优质标签和搭建训练流程的工作量。当任务较新或标签频繁变动时，Jev 可能依然是更具吸引力的选择。
模型路由：专家转移
模型路由是与查询分类相关的问题。在这里，我们把模型路由定义为“专家转移”，即由系统决定该由哪个专家/模型来处理请求。目前的生产基线是在 Agent 循环内部直接让 LLM 原生做出这个决策。虽然这很适合测试 Jev 能否用边界决策替代生成式调用，但一个重要的技术限制是：在不发生转移的情况下，Jev 会严格地增加一次调用。相比之下，生产基线在不转移时，可以通过同一次初始 LLM 调用直接开始工具调用工作。
我们使用了简化版的生产路由（仅含 3 个专家），将 751 条可对比的黄金标准条目通过更新后的 Jev 路由器重放，并将其选择的路由与现有的基于提示词的路由器（由传统 LLM 驱动）进行对比，同时以黄金标签为基准衡量准确率。
我们还单独挑出了 40 条现有路径实际发起了专家转移调用的条目（n 较小），并在这些相同条目上对比了调用延迟。
每条目的中位加速比为 8.1 倍。这是迄今为止内部最强的 Jev 测试结果之一：在这个边界明确的路由任务上，Jev 既更准确又大幅提速。这一差距意味着，我们在非专家路由请求上付出的“阻塞”代价可能是值得的。需要注意的是，这仍然是离线的黄金数据集对比，且延迟样本只包含 40 次正向转移，所以还有很多风险需要排除、很多测试需要做！
重排序
这是 Glean 非常看重的一个问题！在下文中，我们的生产基线是 Glean 现有搜索栈生成的排序。这个实验让 Jev 对最多 50 条结果重新排序。
我们尝试了四种通过 Jev 的类型化输出来表达相关性的方式：
形式
如何表达相关性
逐点 Noul
对每条结果单独提出一个是非相关性判断问题，然后按回答“是”的概率排序。
共享状态 Noul
将整个候选集作为共享上下文展示给 Jev，然后对每条结果提出相同的是非问题。
评分
让 Jev 为每个候选项分配一个数值型相关性分数。
选择
将所有候选项视为同一个决策中的备选项，然后根据得出的概率进行排序。
我们在内部评估集上进行了测试，由于用户无法访问所有规范文档，绝对数值并不能反映我们的生产排序水平——但相对数值值得关注。
Jev 的“选择”形式表现最强。在一组包含 4,855 条已捕获搜索查询的配对对照实验中（剔除了基于生产环境的平局决胜机制），结果如下：
在离线测试中，Jev Choice 每次查询的成本约为 $0.00044，p50 耗时 0.195 秒。但在平均一次查询中，它对 41 个候选项里的约 37 个给出了相同的分数。利用生产环境的排序来打破这些平局后，Recall@6 从 40.2% 提升到了 44.3%，这使得未校正的结果看起来比 Jev 本身分数所应得的更强。像往常一样，这里有很多注意事项，但从方向上看，Jev 是一个低成本、高效率的基线，而非 Glean 生产排序器的替代品。
引用支持度评判
引用评判要回答两个相关问题：需要证据支撑的主张是否有充分的引用（引用召回率），以及被引用的来源是否真的支持归因于它们的主张（引用精确率）。乍一看，由于输出/标签空间是有限的（与大多数评判场景类似），这似乎是 Jev 的理想用例。然而，评判标准很复杂，可能需要拆解多个主张——此外，Jev 不会生成我们常用于错误分析的推理依据，因此在质量和可用性上都存在一定风险。
我们在一段真实的 1,448 字生产评估回复上测试了 Jev，保持回复和引用证据不变。我们将它在精确率和召回率上的综合表现，与不使用推理和使用 xhigh 推理的 GPT-5.6 Luna 进行了对比。为降低方差，每个评判器我们都运行了三次。
评判器
原始测得的每条回复耗时
原始测得的每条回复成本
Jev
6.6 秒
$
0.014
GPT-5.6 Luna，无推理
81.3–85.5 秒
$
0.030–
$
0.047
GPT-5.6 Luna，
xhigh
227.4–259.7 秒
$
0.047–
$
0.060
注意，这里的耗时是方向性参考而非端到端数据：Jev 报告的是客户端顺序挂钟时间，而 Luna 的数据是模型调用时长之和。成本包含了观察到的缓存收益。
我们还对比了在相同 28 个段落上的一致性。“发生变化”指在三次输入完全相同的运行中，评判器至少有一次改变了对某段落引用覆盖是否充分的判定。“成对分歧”则将每个段落在三组运行对中分别统计，每个评判器共 84 次对比。
评判器
召回率判定发生变化的段落数
成对召回率分歧数
Jev
28 个中有 1 个（3.6%）
84 次中有 2 次（2.4%）
GPT-5.6 Luna，无推理
28 个中有 7 个（25.0%）
84 次中有 15 次（17.9%）
GPT-5.6 Luna，
xhigh
28 个中有 5 个（17.9%）
84 次中有 10 次（11.9%）
Jev 唯一的变化在于某个段落是否被计入需要引用的范畴；其原始召回率类别并未改变。因此，在段落级别的引用覆盖判定上，Jev 比两种 Luna 配置都更具可重复性。
我们并不会据此断定 Jev 是更准确的评判器（各系统采用了不同的支持标准和计分分母，而且我们没时间做独立的人工标注）。但即便开启了 xhigh 推理（这让 Luna 的模型耗时大约增加了两倍），它的一致性仍然不如 Jev。这一结果说明，Jev 是实现窄范围引用策略的一种快速、低成本且相对可重复的方式。
实验结论与实践指南
在某些情况下，Jev 作为传统 LLM 和微调分类器的低摩擦替代方案表现出色。当基线本身很强（如重排序），或者微调小模型很容易（如查询分类）时，它的优势就没那么明显了。有迹象表明它在某些任务上质量更高（如模型路由），也有迹象显示它具备更好的一致性和稳定性（如引用评判）。在我们一些最重要的工作负载中，它相比传统 LLM 实现了预期的成本和延迟优势。
以上结果提供了很好的方向性指引，在 Glean，我们对 Jev 感到非常兴奋。再完成几个步骤（主要是数据驻留和保障等运维就绪工作）后，我们计划将 Jev 应用到其中一些场景中。此外，Jev 将在本周的内部黑客松中扮演重要角色，我们很期待分享更多成果！
最后是一些通用建议——如果输出可以提前穷举，就拿 Jev 跑个基准测试。如果任务和标签稳定且量大，也顺便测一下微调分类器。如果调用需要生成查询、解释或其他动态文本，那就继续保留生成式模型。工具调用就是个很好的例子：Jev 可以帮忙选择工具，但大多数 Glean 工具仍需要动态生成的参数（比如搜索查询）。
Jev 并没有改变“分类器早已存在”这一事实。它只是让一个好用的零样本分类器变得更易上手。这是一个扎实的产品，即便它并非每个 AI 系统的全新基石。
