Is Jev overhyped? We tested it on 4 real enterprise tasks. Tony Gentilcore 2026-09-29 13.0 KB 196.4K 379 ☆ 收藏 𝕏 文章列表 作者基于 Glean 的四个真实企业场景测试了 Jev——一个输出类型化决策(选项、分数、概率)而非生成文本的'System One'模型。文章梳理了通用 LLM、零样本分类器、微调分类器与 Jev 的替代方案权衡,并对比了 Qwen/SGLang、Kev 等开源复现。实验显示:查询分类上 Jev 零样本明显优于 Laya 但微调后反超;模型路由(专家转移)是最强结果,准确率更高且中位加速 8.1 倍;重排序中 Jev 的 Choice 表述最强,但平均 41 个候选中约 37 个分数相同需靠生产排序打破平局。结论是 Jev 在新任务或标签频繁变化时最具吸引力,是否被高估取决于具体场景。 Jev分类模型模型路由重排序Glean微调零样本System One推理成本延迟 83 强烈推荐 ▶ 基于真实企业任务的实证评测,包含具体数据和方案空间分析,时效新且实用,但部分实验样本量小且结论尚不完整。 # Is Jev overhyped? We tested it on 4 real enterprise tasks. **作者**: Tony Gentilcore **日期**: 2026-09-28T18:28:27.000Z **来源**: [https://x.com/tonygentilcore/status/2104639390266036251](https://x.com/tonygentilcore/status/2104639390266036251) ---  Authors: [@eddiedzhou](https://x.com/@eddiedzhou), [@mr_cheu](https://x.com/@mr_cheu), [@MatZhao](https://x.com/@MatZhao), Aviral Singh, Manav Agrawal [Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) is a model for making typed decisions. You send it context plus a fixed set of questions and options, then it returns choices, scores, and probabilities instead of generating text. It’s a “System One” model! But classification is not new, and neither are structured outputs, small models, or reading probabilities from logits. That history explains some of the split reaction to Jev...  The skeptics have a real point, but Jev has a real place in this ecosystem. To understand more, we should lay out the full solution space. # What are the alternatives? When a system needs a label, score, or yes-or-no answer, there are four reasonable options: | Approach | Why use it | Tradeoff | | --- | --- | --- | | A general-purpose LLM | Zero-shot, flexible, can also generate arguments or explanations. Arguably “higher intelligence” via inference-time compute (reasoning). | Paying autoregressive-model latency and cost for a small decision | | An open zero-shot classifier | Cheap, local, and controllable | Variable quality; you own model selection and serving | | A fine-tuned classifier | Usually the best bet for a stable, high-volume task with good labels | Data collection, training, deployment, drift, and a less flexible taxonomy | | Jev | Zero-shot flexibility behind a clean, hosted API | Task-dependent quality, no generated text, and provider dependency | The case for Jev: a team can change the question and options without collecting a new training set, while avoiding the work of serving a model well. No one should turn their nose up at that. “We could build it ourselves” is true of most infrastructure products. Open reproductions keep the novelty claim in check. Implementations using [Qwen and SGLang](https://github.com/ekzhang/openjev-sglang), [DiffusionGemma and vLLM](https://github.com/mmastrac/djev-spark), and [Kev](https://github.com/jaredpalmer/kev) recreate much of the API or model shape.  85.7% for Jev and 79.6% for Kev-8B on n=764 [Parallel’s external tests](https://parallel.ai/blog/testing-jev) likewise found Jev competitive on reranking, while specialized models still won two classification tasks. # What we’ve seen at Glean That leaves a practical question: when does Jev’s combination of zero-shot flexibility and hosted inference actually beat the alternatives? We tested four bounded decisions at Glean where we already had a baseline and could compare real enterprise quality. Most of these baselines are LLM-based systems, so for those experiments we know to expect two orders of magnitude improvement on cost and latency. The results ranged from materially worse than production to both faster and more accurate than an LLM-based router. ## Query classification Query classification maps a request to a broad task used by downstream systems. It is a natural Jev workload because while on a per-request basis, the label space is known in advance, the taxonomy can still change faster than a fine-tuned classifier can be retrained. For this experiment, we focus on gauging Jev’s agreement against our production / baseline predictions, which is LLM-based. We expect and observed a large speedup in offline throughput with Jev, so we report agreement as an easy proxy for quality. We also baselined against Laya, an open-weight decision model as well as a fine-tuned Laya. This fine-tuning was able to run locally in a few hours, and the model is also small enough to be served on a developer machine. | Experiment | Broad Task Agreement | Perf | | --- | --- | --- | | Jev zero-shot | 66.8% | ~12min (concurrency of 4) | | Base Laya | 35.9% | ~90s (local dev machine) | | Fine-tuned Laya | 74.5% | ~90s (local dev machine) | As a convenient, no-training off-the-shelf model, Jev clearly outperforms Laya, but somewhat unsurprisingly, fine-tuning makes Laya shine, especially given the performance numbers. The tradeoff is the effort to get good labels and set up training. Jev likely remains more attractive when a task is new or its labels are changing. ## Model routing: expert transfer Model routing is a related problem to query classification. Here, we frame model routing as expert transfer, where our system chooses which expert / model should handle the request. Our production baseline currently asks an LLM to make that decision natively inside the harness's agentic loop. While this is a natural test of whether Jev can replace a generative call with a bounded decision, an important technical limitation is that Jev will strictly add a call in the event of a non-transfer. This is in contrast to the production baseline, which in non-transfer cases, can begin the tool-calling work via the same single first LLM call.  We used a simplified version of our production routing with only 3 experts, replayed 751 comparable golden entries through the updated Jev router and compared its chosen route with our existing prompt-based router (powered by a traditional LLM), and measuring the accuracy against golden label.  We also isolated 40 entries where the existing path made an actual expert-transfer call (smaller n) and compared call latency on those same entries.  The median per-entry speedup was 8.1×. This is one of the strongest internal Jev results so far: on this bounded routing task, Jev was both more accurate and substantially faster. The magnitude of the delta implies that the “blocking” tax we incur on non-expert-routed requests may be a good tradeoff. Note that it is still an offline golden-set comparison, and the latency sample contains only 40 positive transfers, so there's a lot more to derisk and test! ## Reranking A problem near and dear to Glean! Below, our production baseline is the order produced by Glean’s existing search stack. This experiment then asked Jev to reorder up to 50 results. We tried four ways to express relevance through Jev’s typed outputs: | Formulation | How it expresses relevance | | --- | --- | | Pointwise Noul | Ask a separate yes-or-no relevance question for each result, then sort by the probability of “yes.” | | Shared-state Noul | Show Jev the full candidate set as shared context, then ask the same yes-or-no question for each result. | | Score | Ask Jev to assign each candidate a numerical relevance score. | | Choice | Treat all candidates as alternatives in one decision, then rank them by their resulting probabilities. | We ran this on an internal evalset where the user does not have access to all canonicals, so the absolute numbers are not reflective of our production ranking – but the relative numbers are of interest. Jev “Choice” was the strongest formulation. On a paired control of 4,855 captured search queries, with production-based tie-breaking removed, the result was:  Jev Choice cost roughly $0.00044 per query and took 0.195 seconds at p50 in the offline test. But it assigned identical scores to roughly 37 of the 41 candidates in an average query. Using production order to resolve those ties raised Recall@6 from 40.2% to 44.3%, making the uncorrected result look stronger than Jev’s scores alone warranted. There are many caveats here as per usual, but directionally, Jev is a cheap, efficient baseline, not a replacement for Glean’s production ranker. ## Citation-support judging Citation judging asks two related questions: do claims that need evidence have adequate citations (citation recall), and do the cited sources actually support the claims attributed to them (citation precision)? At first glance, because the output / label space is bounded (similar to most judge settings) this seems like an obvious fit for Jev. The rubric is complex, however, and may require decomposing several claims – in addition, Jev doesn’t produce the rationale that we often use for error analysis, so there is some risk to both quality and usability. We tested Jev on a real 1,448-word production-eval response, holding the response and citation evidence fixed. We compared its shared precision-and-recall pass with GPT-5.6 Luna using no reasoning and xhigh reasoning. To reduce variance, we ran each judge three times. | Judge | Original measured time per response | Original measured cost per response | | --- | --- | --- | | Jev | 6.6 s | $0.014 | | GPT-5.6 Luna, no reasoning | 81.3–85.5 s | $0.030–$0.047 | | GPT-5.6 Luna, xhigh | 227.4–259.7 s | $0.047–$0.060 | Note that the timing is directional rather than end-to-end: Jev reports sequential client wall time, while the Luna rows sum model-call durations. Costs include observed caching. We also compared consistency on the same 28 paragraphs. A changed item means the judge changed its verdict on whether a paragraph had adequate citation coverage in at least one of three identical-input runs. Pairwise disagreement counts each paragraph across the three run pairs, for 84 comparisons per judge. | Judge | Paragraphs with a changed recall verdict | Pairwise recall disagreements | | --- | --- | --- | | Jev | 1 of 28 (3.6%) | 2 of 84 (2.4%) | | GPT-5.6 Luna, no reasoning | 7 of 28 (25.0%) | 15 of 84 (17.9%) | | GPT-5.6 Luna, xhigh | 5 of 28 (17.9%) | 10 of 84 (11.9%) | Jev’s only change was whether one paragraph counted as needing a citation; its raw recall category did not change. Jev’s paragraph-level citation-coverage verdicts were therefore more repeatable than either Luna configuration. We're not concluding that this makes Jev the more accurate judge (the systems applied different support criteria and scoring denominators, and we didn't have time to do independent human labels). But even with xhigh reasoning (which roughly tripled Luna’s model time), it remained less consistent than Jev. The result supports Jev as a fast, inexpensive, and comparatively repeatable way to implement a narrow citation policy. # Experiment Takeaways and Practical Guide In some cases, Jev shines as a low-friction alternative to both traditional LLMs and fine-tuned classifiers. When the baseline is strong (reranking), or it’s easy to fine-tune a smaller model (query classification), the upside is weaker. There are signs of stronger quality for some tasks (model routing) as well as indications of better consistency and stability (citation judge). In some of our most important workloads, it delivers the expected cost and latency wins against traditional LLMs. The above results give good directional leads, and at Glean, we’re very excited about Jev. After a few more steps (mainly, operational readiness like data residency and guarantees) we plan to ship Jev into some of these use cases. Also, Jev will play a big role in our internal hackathon this week and we’re excited to share more results! Some general advice to conclude – if the output can be listed in advance, benchmark Jev. If the task and labels are stable and volume is high, benchmark a fine-tuned classifier too. If the call needs to generate a query, explanation, or other dynamic text, keep a generative model in the loop. Tool calling is a good example: Jev can help choose a tool, but most Glean tools still need dynamically generated arguments (like search queries). Jev does not change the fact that classifiers already existed. It makes a good zero-shot classifier much easier to use. That’s a solid product, even if it’s not a new foundation for every AI system. ## 相关链接 - [Tony Gentilcore](https://x.com/tonygentilcore) - [@tonygentilcore](https://x.com/tonygentilcore) - [126K](https://x.com/tonygentilcore/status/2104639390266036251/analytics) - [@eddiedzhou](https://x.com/@eddiedzhou) - [@mr_cheu](https://x.com/@mr_cheu) - [@MatZhao](https://x.com/@MatZhao) - [Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) - [Qwen and SGLang](https://github.com/ekzhang/openjev-sglang) - [DiffusionGemma and vLLM](https://github.com/mmastrac/djev-spark) - [Kev](https://github.com/jaredpalmer/kev) - [Parallel’s external tests](https://parallel.ai/blog/testing-jev) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [2:28 AM · Sep 29, 2026](https://x.com/tonygentilcore/status/2104639390266036251) - [126.5K Views](https://x.com/tonygentilcore/status/2104639390266036251/analytics) - [View quotes](https://x.com/tonygentilcore/status/2104639390266036251/quotes) --- *导出时间: 2026/9/29 15:29:03* --- ## 中文翻译 # Jev 是否被过度炒作了?我们在 4 个真实企业任务上进行了测试。 **作者**: Tony Gentilcore **日期**: 2026-09-28T18:28:27.000Z **来源**: [https://x.com/tonygentilcore/status/2104639390266036251](https://x.com/tonygentilcore/status/2104639390266036251) ---  作者:[@eddiedzhou](https://x.com/@eddiedzhou)、[@mr_cheu](https://x.com/@mr_cheu)、[@MatZhao](https://x.com/@MatZhao)、Aviral Singh、Manav Agrawal [Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) 是一个用于做出类型化决策的模型。你向它发送上下文以及一组固定的问题和选项,它会返回选择、分数和概率,而不是生成文本。它是一个“系统一”模型! 但分类并不是什么新东西,结构化输出、小模型以及从 logits 中读取概率也都不是。这段历史解释了人们对 Jev 反应不一的部分原因……  质疑者的观点确实有道理,但 Jev 在这个生态系统中确实占有一席之地。要深入了解,我们应该梳理完整的解决方案空间。 # 有哪些替代方案? 当一个系统需要标签、分数或“是/否”答案时,有四种合理的选择: | 方案 | 为什么使用它 | 权衡 | | --- | --- | --- | | 通用 LLM | 零样本、灵活,还可以生成论证或解释。通过推理时计算(推理)可以说具有“更高的智能”。 | 为一个小决策付出自回归模型的延迟和成本 | | 开源零样本分类器 | 便宜、本地化、可控 | 质量参差不齐;需要自己负责模型选择和服务部署 | | 微调分类器 | 对于标签良好、稳定且高流量的任务,通常是最好的选择 | 数据收集、训练、部署、漂移,以及分类体系不够灵活 | | Jev | 通过干净的托管 API 获得零样本灵活性 | 质量因任务而异、无法生成文本、依赖服务提供商 | Jev 的优势在于:团队无需收集新的训练集就可以更改问题和选项,同时避免模型服务部署的工作。没有人应该对此嗤之以鼻。“我们可以自己做”这句话适用于大多数基础设施产品。 开源复现项目对这一新颖性主张有所约束。基于 [Qwen 和 SGLang](https://github.com/ekzhang/openjev-sglang)、[DiffusionGemma 和 vLLM](https://github.com/mmastrac/djev-spark) 以及 [Kev](https://github.com/jaredpalmer/kev) 的实现重现了 API 或模型形态的大部分内容。  在 n=764 的测试中,Jev 达到 85.7%,Kev-8B 达到 79.6% [Parallel 的外部测试](https://parallel.ai/blog/testing-jev)同样发现 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 可能仍然更有吸引力。 ## 模型路由:专家转移 模型路由是与查询分类相关的问题。在这里,我们将模型路由定义为专家转移,即我们的系统选择应由哪个专家/模型处理请求。我们的生产基线目前是在 harness 的智能体循环内让 LLM 原生地做出这一决策。虽然这是测试 Jev 能否用有界决策替代生成式调用的自然场景,但一个重要的技术限制是:在不需要转移的情况下,Jev 会严格地增加一次调用。这与生产基线不同——生产基线在非转移情况下,可以通过同一个首次 LLM 调用开始工具调用工作。  我们使用了生产路由的简化版本,只包含 3 个专家,将 751 条可比的黄金条目重放给更新后的 Jev 路由器,并将其选择的路由与我们现有的基于提示的路由器(由传统 LLM 驱动)进行比较,并针对黄金标签测量准确性。  我们还分离出 40 条现有路径实际发生专家转移调用的条目(样本量较小),并在这些相同条目上比较调用延迟。  每条目的中位数提速为 8.1 倍。这是目前为止 Jev 最强的内部结果之一:在这个有界的路由任务上,Jev 既更准确又明显更快。差距之大意味着我们在非专家路由请求上承担的“阻塞”代价可能是一个不错的折衷。请注意,这仍然是一个离线黄金集对比,且延迟样本仅包含 40 个正向转移,因此还有更多工作需要降险和测试! ## 重排序 这是 Glean 亲近且重视的问题!下面,我们的生产基线是 Glean 现有搜索堆栈产生的排序。这个实验让 Jev 对最多 50 条结果进行重排序。 我们尝试了四种通过 Jev 类型化输出表达相关性的方式: | 表述方式 | 如何表达相关性 | | --- | --- | | Pointwise Noul | 对每条结果分别提出一个是/否相关性问题,然后按“是”的概率排序。 | | Shared-state Noul | 将完整候选集作为共享上下文展示给 Jev,然后对每条结果提出相同的“是/否”问题。 | | Score | 让 Jev 为每个候选者分配一个数值相关性分数。 | | Choice | 将所有候选者视为一个决策中的备选项,然后按其产生的概率排序。 | 我们在一个内部评测集上运行了此项测试,用户并非对所有标准文档都有访问权限,因此绝对数字并不能反映我们的生产排序水平——但相对数字值得关注。 Jev 的“Choice”是最强的表述方式。在 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,保持响应和引用证据不变。我们将其共享的“精确率与召回率”评估与 GPT-5.6 Luna(无推理和 xhigh 推理两种设置)进行了比较。为了减少方差,每个评判运行了三次。 | 评判者 | 原始测量的每响应时间 | 原始测量的每响应成本 | | --- | --- | --- | | 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 系统的全新基础。 ## 相关链接 - [Tony Gentilcore](https://x.com/tonygentilcore) - [@tonygentilcore](https://x.com/tonygentilcore) - [126K](https://x.com/tonygentilcore/status/2104639390266036251/analytics) - [@eddiedzhou](https://x.com/@eddiedzhou) - [@mr_cheu](https://x.com/@mr_cheu) - [@MatZhao](https://x.com/@MatZhao) - [Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) - [Qwen 和 SGLang](https://github.com/ekzhang/openjev-sglang) - [DiffusionGemma 和 vLLM](https://github.com/mmastrac/djev-spark) - [Kev](https://github.com/jaredpalmer/kev) - [Parallel 的外部测试](https://parallel.ai/blog/testing-jev) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [2:28 AM · Sep 29, 2026](https://x.com/tonygentilcore/status/2104639390266036251) - [126.5K Views](https://x.com/tonygentilcore/status/2104639390266036251/analytics) - [View quotes](https://x.com/tonygentilcore/status/2104639390266036251/quotes) --- *导出时间: 2026/9/29 15:29:03*
新 新模型 Jev 爆火,5 天挤进 14 万开发者:快 200 倍、便宜 400 倍 文章介绍了发布即爆火的新模型 Jev(TypeSafe 公司出品),它不生成文本,只做判断:路由、分类、打分、审核。相比大模型,它判断速度快 40-200 倍(0.1 秒级),成本便宜约 400 倍,且因输出限定在预定义选项内而不存在幻觉空间。创始人 Diogo Almeida 是前 OpenAI 研究员。文章给出了三条免费或低成本使用方式(OpenJev、官方 waitlist、OpenRouter),并冷静指出官方数据的局限:444 倍提升是评测上限,第三方实测准确率约 68%。Jev 定位为给大模型打配角的 System One 模型,适合 Agent 场景中的高频小判断。 技术 › LLM 路飞 2026-09-20 JevTypeSafeSystem One模型路由内容审核Agent推理成本OpenRouterAI判断幻觉
W Will TypeSafe's Jev change how we build AI applications? 文章分析了 TypeSafe 发布的新模型 Jev——一种只能做分类、评分和路由决策、不能生成文本的'System One'模型。Jev 比通用 LLM 快 40-200 倍、便宜 40-400 倍,通过 RLCD 训练方法实现零样本概率判断。早期独立测试显示其准确率接近 GPT-5.6 等大模型,垃圾邮件分类甚至可媲美有标注训练的分类器。代价是失去了解释能力,无法说明判断理由。作者认为这可能改变 AI 应用架构:用 Jev 做大规模廉价监控评估,用 LLM 判官处理少量样本以获取改进方向信号。 技术 › LLM Aparna Dhinakaran 2026-09-19 JevTypeSafeLLM-as-a-judge模型评估System One分类模型RLCD成本优化模型路由AI应用架构
B Building a Harness with Jev 本文介绍 TypeSafe AI 发布的新模型 Jev,一种名为 System One 的非传统 LLM 模型。Jev 不生成文本,而是通过 RLCD 强化学习训练,对给定状态快速返回结构化决策(Choice、Score、Noul 三种问题类型)及概率,推理速度最高快 200 倍、成本低至 1/400。文章展示了如何通过 LangChain 的 TypeSafeClassifier 集成 Jev,并给出两大应用场景:模型路由(根据任务复杂度自动选择低成本或高性能模型)和 Auto Mode(对危险工具调用进行分类守护,提升 Agent 可信度)。Jev 适合作为 LLM 的补充,在 Agent 循环中承担快速、低成本的分类决策。 技术 › Agent Sydney Runkle 2026-09-18 JevLLMAgentLangChainSystem OneRLCD模型路由分类模型Harness EngineeringTypeSafe AI
J Jev 新手指南:System One 判断型模型入门 本文是 Jev(一个通用 System One 模型)的新手指南。Jev 专为快速、聚焦的判断设计,而非长推理或开放式写作。用户给它提供上下文(状态)和决策表(问题),它返回结构化答案及不确定性概率。答案类型包括 Choice(单选)、Noul(是/否概率)和 Score(有序打分),可一次请求多个互不影响的问题。文章介绍了 Jev Playground 中的六个用例,如支持工单分流、模型路由、Agent 工具调用守卫、智能家居请求等,并强调最终决策应由代码完成:设置阈值、硬规则和权限判断。Jev 适合重复性、答案有界的判断场景,但在算术、计数、日期、对抗性输入等方面表现不均,需谨慎使用。 技术 › LLM elvis 2026-09-21 JevSystem OneLLM模型路由Agent判断型模型TypeSafe AI概率输出新手指南AI Playground
拿 拿到 Jev,然后呢?剔掉虚火之后的一份真实落地清单 TypeSafe AI 于 2026 年 9 月发布的 Jev 是一个只做选择题的 AI 模型(单选、打分、是/否),响应 0.07–0.5 秒、输入价格极低、输出免费。作者梳理了官方数据及 Hacker News 上的质疑,指出“Jev 取代大模型”是伪命题,其合理定位是高频、低价地执行小判断。文章按用途分类整理了已真实跑通的案例:为 AI Agent 当决策器、海量数据分类、高低置信度分流混合架构、实时反应界面和仿真实验,并列举了已接入的商业产品。作者还分享了自己四次失败的集成尝试与两轮实测结论,强调概率校准的重要性。 技术 › LLM huangserva 2026-09-19 JevTypeSafe AILLM模型评测AI Agent分类模型推理成本OpenRouter落地案例概率校准
一 一文解密 Jev:一个不聊天的模型,为什么突然火了? TypeSafe AI 于2026年9月发布的 Jev 是一个不做对话和内容生成的专用判断模型,主打低成本、高速度地解决软件中的小型理解判断任务,如工单分类、优先级评分和概率判断,提供 Choice、Score、Noul 三种能力。其极低价格(每百万输入token 0.042美元)和 Vercel、Netlify 的快速接入引发开发者关注。文章分析了其'零幻觉'宣传的真实含义、评测数字的适用边界,并指出 Jev 的价值在于与生成式模型、程序和人分工协作,让软件能以低成本读懂小问题。 技术 › LLM Ray Wang 2026-09-19 JevTypeSafe AILLM分类模型System OneRLCDAgent模型分工成本优化推理
火 火爆全网的Jev到底是什么? 文章介绍了旧金山创业公司 TypeSafe 推出的闭源基础模型 Jev。它不做文本生成,只做判断题、选择题和打分题,输出严格限定在预设选项内,可在约100毫秒内出结果,成本极低。其核心技术是通过 RLCD 强化学习实现概率校准,类似于卡尼曼所说的 System 1 快思考,与传统大模型的慢思考互补。文章展示了社区应用案例,如浏览器 Agent、游戏实时决策、LangChain 工具路由、AI 输出审核等,也指出其在数数、算数、多跳推理和中文上的短板及提示词注入风险,认为 AI 调用正在走向分层架构。 技术 › LLM 泊舟 2026-09-19 JevTypeSafeAI模型分类模型AgentSystem 1RLCD概率校准模型路由推理效率
S System One Models: What Comes After Agentic Software 文章介绍 TypeSafe 发布的 Jev 模型,一种用于快速语义决策而非生成或长推理的 System One 模型,延迟低至 70ms 且成本低廉。作者认为这类模型可将小型语义智能分散嵌入应用的各个决策点,而非集中于 Agent 循环中,从而推动微推理时代的到来。这将使代码库中包含更多非确定性判断,同时应用层更明确地掌控编排控制流,推理模型则退居处理模糊和复杂案例的升级路径。文章还探讨了围绕微推理所需的基础设施(批处理、缓存、模型路由),并以自动驾驶和 Waymo 的 ML-primary 架构类比这种通用语义模型进入控制循环的新范式。 技术 › LLM Josh Rosen 2026-09-17 System OneJev微推理Agent架构语义决策TypeSafe推理模型AI架构模型路由嵌入推理
全 全网最详细的 Jev 及同类决策模型学习资料导航:12 大主题、58 份资料、80 个链接 本文系统整理了 Jev 及同类决策模型的学习资料,涵盖 12 大主题、58 份资料、80 个链接。文章首先解释了 Jev 是 TypeSafe AI 推出的决策模型,输入为状态、问题和候选项,输出为结构化的选择、评分及概率分布。作者分析了评估此类模型的关键维度:动态候选项、受限输出与概率校准、推理方式、训练方式及答案边界。随后提供了按目的划分的阅读路径(入门、本地试用、训练研究、中文场景、Agent 应用),并分类整理了云端决策服务(OpenAI Decisions、Liquid d1)、开放模型(Cloudflare Clef、Perplexity Decider、GLiNER2.5-Decide)及本地社区实现(Laya、Kev)等资源,是一份完整的决策模型学习导航。 技术 › LLM Smartpig 2026-10-08 Jev决策模型LLMRLCD概率校准受限输出分类模型Agent学习资料导航开放模型
J Jeff:把 Jev 类决策模型压到 0.8B,跑在本地 Mathias Strasser(Scissero)基于 Qwen3.5 和 Gemma 4 微调出 Jeff 系列 0.8B/2B 决策模型,用于零样本分类:输入描述与选项,一次前向传播返回各选项校准概率。模型在 RTX PRO 6000 上约 22 毫秒、M4 Max 上 28 毫秒即可完成一次决策,0.8B 仅 1.7GB,可直接本地部署。整体基准分 Jeff-2B 达 83.1,几乎追平 Jev 的 83.0;Doom 零样本测试中 Jeff-0.8B 在无人提示规则下达到 6.55,追平 Jev 公布成绩。作者诚实列出局限:不能推理、最多 26 个选项、只支持英文文本等。代码 MIT、权重 Apache 2.0 开源。 技术 › LLM yibie 2026-09-30 JeffJev零样本分类本地AI小模型微调开源基准测试决策模型MLX
有 有人把 Jev 开源复刻了,还给出了「自己微调」的完整闭环 Jared Palmer(Cognition)开源了 Kev,一族建在 Qwen3.5/3.8 之上的 Jev 式小型决策模型(0.8B~27B,Apache-2.0)。文章介绍了 Kev 与 Jev 的对比数据:Kev-27B 在新数据源上与 Jev 相差一个点以内,但作者强调这不是受控比较。最有价值的部分是完整的微调闭环:通过 coding agent 的 skill,可自动从用户代码中找出问题、转换已有标签、在 Modal 上微调并部署,一次 Kev-4B 训练在 H100 上约 1 美元,示例中把准确率从 67.7% 提到 73.6%。文章还总结了校准温度、问题隔离设计等工程细节,以及作者诚实的自我限制态度。 技术 › LLM yibie 2026-09-28 KevJev开源微调决策模型Qwencoding agent部署模型对比
把 把 GLM-5.3-Flash 变成一个 Jev 式的 System One 模型 本文介绍一种无需微调的方法,把现成的 LLM(GLM-5.3-Flash)变成类似 Jev 的专用决策模型(System One 模型)。核心做法是给选项编号、预填答案、通过读取选项索引上的概率分布,让模型在一次前向传播中给出类型化决策及其置信度。文章详细说明了 vLLM 部署中的三个实现细节(allowed_token_ids、logprob_token_ids、tokenizer 分词),并在 29 个公开数据集上与 Jev、Laya 进行基准对比:文本决策准确性与 Jev 相当,延迟相近但成本较高;由于具备视觉能力,还能做图像上的类型化决策,这是 Jev 和 Laya 做不到的。文章还讨论了推理模式的准确性收益与成本代价、选项数量与重命名对结果的影响,并开源了实现与基准代码。 技术 › LLM yibie 2026-09-28 LLM决策模型GLMJev基准测试vLLM多模态置信度System One机密计算