什么是 Jev？

作者：AGI Hunt 发布：2026-09-20 23:30 收录：2026-09-21 00:17 38 次阅读 约 8171 字
摘要：AGI HUNT / JEV 一道判断题： 演讲者说的话，对应 PPT 的哪一页？ 讲话 + 页面信息 轻点，得到页码 预设演示 · 动画不代表响应时间 08 / 产品规划 08 已就绪 得到页码后，可以直接交给程序给 PPT 翻页。 发布后，它引来了疯狂关注： 14 万人 200+ 发布后 36 小时 加入 wait
推荐理由：本文围绕「JEV」、「AGI」等主题展开。
AGI HUNT  /  JEV一道判断题：演讲者说的话，对应 PPT 的哪一页？讲话 + 页面信息轻点，得到页码预设演示 · 动画不代表响应时间08 / 产品规划08  已就绪得到页码后，可以直接交给程序给 PPT 翻页。发布后，它引来了疯狂关注：14 万人200+发布后 36 小时加入 waiting list发布后三天社区出现的复刻项目等待名单来自发布方；复刻数来自社区统计。先回答三个问题。它究竟是什么？它是面向程序决策的模型，接收状态和问题，返回选项、评分或概率。它值得关注吗？值得关注：适合低延迟、高频的分类与路由，但复杂推理和长期规划仍有限。它有什么不一样？与通常逐 token 生成文本的 LLM 相比，Jev 按问题并行返回判断与概率。请往下看，从自动翻页说起。01  /  JEV先看个 demoJev 发布已经好几天了，如果你还没有听说过，可以先看这个：模型给出判断，程序决定动作page_id: 8当前页面0308页码合法，还要确认判断正确。轻点已展开讲到「产品规划」，程序翻到第 8 页；讲到「定价策略」，再对应定价页。不是定时播放，全程不用按遥控器。有意思的是，两位独立开发者撞上了同一个想法，分别做出了同款。其实，用普通 LLM，也能做这样的翻页判断。但要连续运行，需要考虑：节奏每秒判断一次，延迟要跟得上讲话。费用单次足够便宜，才能一直调用。结果页码要便于程序读取；普通 LLM 的结构化输出也能限定格式。比较时应使用同一任务，同时看速度、费用和判断质量。Jev 想做的，是让这类判断能一直放在程序里运行。02  /  JEVTypeSafe AI出品 Jev 的公司公司TypeSafe AI，位于旧金山，研发两年后正式亮相。创始人Diogo Almeida，前 OpenAI 研究员，InstructGPT 论文共同作者。融资4000 万美元种子轮，DCVC 领投。发布后的反响36h14 万人加入候补名单。1 天Hacker News在榜首停留了一整天。投资人 Jason Pontin 称，这是他十几年投资生涯中见过的最佳公司发布（最会营销）。名字的两层意思System One来自 Kahneman 的《思考，快与慢》。系统 1，指快速、直觉式的判断。Jev来自经济学家 Jevons。杰文斯悖论：效率提高，使用量反而可能增加。TypeSafe 的期待是：一次判断越便宜，原来不值得做的应用，就越有机会出现。发布时的价格与延迟$0.042百万输入 token输出 token 免费。70–500毫秒官方端到端延迟范围。实际耗时还受输入、服务负载和网络影响。03  /  JEV一个调用例子一次 API 调用长这样：给一段 state（文本或JSON），带上若干 questions，每个问题有类型定义。state · 当前发生了什么客户消息Stripe 账号连接失败三天，正在损失销售，请尽快帮忙。modeljev-latestquestions一次定义多个判断，各自有instructions 和类型。可传文字或 JSON。下面横滑查看三个问题的完整含义。questions · 同一条消息，分别问←  左右查看  →
Choice · 分给哪个团队字段department问题哪个团队应处理返回返回一个候选项billing：支付或订阅问题。technical：故障或集成问题。sales：价格或账号问题。字段名只用于取结果；问题说明要写清楚判断要求。←  01 / 03  →Score · 客户有多恼火字段frustration问题客户表现出的程度返回返回加权档位0：冷静，陈述事实。1：不满，但保持礼貌。2：非常生气，措辞强烈。criteria 有顺序，不是三个互换的标签。←  02 / 03  →Noul · 是否紧急字段is_urgent问题是否表达紧急或时效性返回返回 0–1 概率instructions 描述要判断的命题。这里问的是消息是否紧急，而不是该交给哪个团队。←  03 / 03  →
下面用示意的返回数据结构，可参考结合你的调用。Choice 和 Score 返回分布，Noul 返回一个概率：answers · 示例调用←  左右查看  →
department类型choice结果billing附带confidence: 0.76billing：0.84technical：0.159sales：0.001选项值符合类型，不代表判断一定正确。←  01 / 03  →frustration类型score结果1.034附带confidence: 0.532第 0 档：0.139第 1 档：0.688第 2 档：0.1730 × 0.139 + 1 × 0.688 + 2 ×0.173 = 1.034。←  02 / 03  →is_urgent类型noul结果0.999附带没有独立 confidence返回的是当前命题成立的概率。它和 Choice 的置信度不是同一个量，不能混用。←  03 / 03  →
把上面的解读，放回完整示例请求  ← 左右滑动 →  返回
请求 · JSON1{2"state": "Hi, I've been trying toconnect my Stripe account for 3days and it keeps failing. I'mlosing sales. Please help ASAP.",3"model": "jev-latest",4"questions": {5"department": {6"type": "choice",7"instructions": "Which teamshould handle this",8"criteria": {9"billing": "Payment orsubscription issues",10"technical": "Bugs orintegration problems",11"sales": "Pricing or accountquestions"12}13},14"frustration": {15"type": "score",16"instructions": "How frustratedthe customer appears",17"criteria": [18"Calm, just stating facts",19"Frustrated but civil",20"Very angry, strong language"21]22},23"is_urgent": {24"type": "noul",25"instructions": "The messageconveys urgency ortime-sensitivity"26}27}28}返回 · 示例值1{2"answers": {3"department": {4"choice": "billing",5"probabilities": {6"billing": 0.84,7"technical": 0.159,8"sales": 0.0019},10"confidence": 0.7611},12"frustration": {13"score": 1.034,14"probabilities": {15"0": 0.139,16"1": 0.688,17"2": 0.17318},19"confidence": 0.53220},21"is_urgent": {22"noul": 0.99923}24}25}
同一条工单，三种问法Choice该交给谁？从定义好的选项中选择，返回完整分布与 confidence。Score客户有多恼火？档位有顺序，返回概率加权平均。1.034 在第 1、2 档之间，接近第 1 档。Noul事情紧急吗？返回 0–1 的概率，不另带 confidence。这个接口不带对话历史，也不设置 systemprompt 或 temperature。把当前状态和问题定义传进去，就能读取返回的概率。用 Python SDK 调用时，可以这样写：Python SDK1from typesafe_sdk importTypeSafeClient2client = TypeSafeClient()3response = client.system_one(4state=state, model="jev-latest",5questions=questions6)04  /  JEV和 LLM 的差异接口不同，都要检验判断普通 LLM通常用消息作为输入。也能接收程序状态，通过结构化输出返回合法JSON。Jev输入 state 和问题定义。返回类型化的答案与概率，代码按字段读取。Jev 让接入更直接，但是否理解正确，仍要用任务数据测试。把判断与执行拆开模型给答案输出选项和概率。代码定策略阈值进入常量和版本控制，可审计、可review。程序执行权限、当前状态、异常处理留在程序里。Jev 的概率接口让这种分工更自然，普通 LLM 也可以这样做。合法，与正确是两回事接口约束正常响应来自已定义的选项。仍需处理选错、误解、超时、网络错误和接口异常。05  /  JEV置信度每个 Choice 和 Score 的答案都带confidence。它是从已有分布计算出来的统计量，不是另一个独立学出的「答对概率」。官方公开适配器中，Choice 在 K > 1 时使用：Python SDK1c = (p_max − 1/K) / (1 − 1/K)Choice 分布越尖，confidence 越高；分布越平，confidence 越低。Score 使用另一套公式，衡量概率离众数档位的距离，不能直接用上面的公式。分数之后，还要有执行策略高满足业务条件后自动执行。中让用户确认，或先补充信息。低暂缓，转人工或换其他方法。0.6 / 0.95 只是只读和写入的阈值示意，不是通用标准。高风险操作还要检查权限并确认；阈值需用自己的数据验证。几个容易混淆的数字Noul不单独提供 confidence，也不能当成只有一个选项的 Choice。同题不同问法一组黑盒测试：Noul 得到 0.22；yes/no Choice 的 no 为 0.99，confidence 为 0.97。正反两个问题两个 Noul 的结果之和出现过 1.19。它们分别作答，没有被约束成互补。这些是具体探针结果；不同提问类型的数值不能直接互换。06  /  JEV并行与隔离同一份输入，三个独立问题state · 客户消息ChoicebillingScore1.034Noul0.999第二次请求等待前一步的部门结果它们不会读取彼此的答案。预设示意 · 第二次请求需要应用来衔接。把 department = billing 写进下一份 state再问：这个部门现在由谁负责？下一步，要用到部门结果呢？已展开把密码放在哪里，结果不同位置命中率共享输入state90%另一个问题instructions0%Archer Hume 的探针，与问题隔离的接口约定一致。问题多了，耗时怎样变？问题数中位耗时单个186ms批量2572ms批量10082ms大批量1500610msArcher Hume 黑盒测试 · 每组 8 次 · 不能外推成服务的时延保证同一场景，13 个问题一起问1/12.2相对费用对比逐个发送。10×相对速度该组答案完全一致。官方 cookbook 的一次对照，不是所有请求都能达到的收益。因此可以先把可能用到的问题一起问完：把所有可能用到的问题全塞进去，代码再决定用哪些答案。共享 state 可以减少重复输入费用，但新增问题和选项仍会增加输入 token。延迟变化小，不等于额外问题免费。如果几个判断有先后依赖，如果第二个判断依赖第一个的答案，就需要在代码里再发一轮请求。07  /  JEV不是自回归一次判断，为什么还要生成一串字？逐 token 生成直接读出概率 · 架构假设动画只解释计算顺序，不比较实际速度。下一页是80.840.1590.001看两种依赖关系已展开自回归生成要逐 token 预测，每一步都依赖前面的输出。启用推理的通用模型，有时会先生成很长的推理内容再给 yes/no；其中一个例子用了约 910 个推理 token，这不是所有 LLM 分类调用的固定开销。KV 缓存也避免了每步重新计算全部输入。黑盒实验能看到什么官方说明并行输出概率，而非逐 token 生成文本。拼写探针让 Choice 逐字符拼 incapable，没有成功；单凭失败不能推断内部结构。输出计数200 个选项返回 1911 个output_tokens，没有对应的逐token 解码耗时。测试者认为这里统计的是序列化响应，不能直接当成内部解码步数。已经公开的信息官方资料从预训练语言模型分出 RLHF、RLVR、RLCD 三条后训练方向。创始人回应在 HN 确认，RLCD 基于预训练底座。媒体报道TechCrunch 使用transformer-based 的描述。这些线索支持 Transformer 底座，但并没有公开了完整架构。公开材料显示它以预训练 Transformer 为基础做后训练。「一次 prefill + 读出头」是合理的候选解释，还不是官方披露的结构。所谓「只输出一个 token」也不能准确描述这个接口。08  /  JEV和 logit 用法的差别发布后很快就出现了多种复刻。拿现成 LLM 的logits 做分类，是其中上手最快的一种方案。零训练复刻的做法拼输入把 state、问题与选项组成 prompt。读分数前向计算后，取候选 token 的 logits，经过 softmax 得到分布。做校准用标注数据拟合温度；多字段可复用共享前缀的 KV 缓存。可实现合法 schema、多问题处理；一些实现报告了 5–7 倍提速。差别要看实现训练是否针对决策任务训练过。校准怎样训练概率，是否再做温度缩放。选项怎样表示候选项，能否利用它们的上下文关系。不能只看接口长得像不像。Jev 的训练方法叫 RLCD（ReinforcementLearning for Calibrated Decisions），官方说优化目标是「校准的决策」。零训练复刻常用事后温度缩放；Jev 宣称在训练中优化校准。训练与事后校准并不互斥，闭源接口无法分离二者贡献。限制输出，与理解任务复刻的常见做法从词表里挑候选 token，在这个子集上做softmax。TypeSafe 的主张如果模型还把概率分给非法 token，单纯屏蔽它们，并没有解决任务理解。Jev 允许调用方在运行时定义选项。右侧是创始人的观点，不能据此确认其内部读出实现。加一个选项，输入也跟着变了ABCD原有两项的 log-odds+0.38Archer Hume：10 个随机化区组均观察到变化。E→  +0.11＋ 天气原因已展开这只能排除「各选项原始分数固定、增加选项只改归一化分母」的模型。若完整选项列表进入prompt，新增选项也会改变 logits。这个实验提示选项之间存在上下文影响，但不能排除所有 logit 方法，更不能单独证明 Jev 采用了某种模型架构。09  /  JEVRLCD 与质疑三种训练方向RLHF根据人类偏好优化输出。RLVR用可验证的奖励训练推理。RLCDTypeSafe 提出的方向：优化校准的决策概率。具体训练配方尚未公开。0.8，要放进一组案例里看预测约 80%  /  实际约 80%许多被预测为 0.8 的事件，最后约有 80% 发生，才符合校准的含义。单独一个案例答对或答错，都不能证明校准好坏。官方说训练数据全部是合成的。创始人认为数据比架构更值得研究，但更具体的做法，只愿意向加入团队的人透露……招人小妙招？主要争论是否需要 RL三种输出都可微，社区质疑：交叉熵能做，为什么一定要用强化学习？新在哪里Turing Post 认为，这是旧想法在新时机的一次重新组合。不用RL 的例子Bespoke Nimble 通过对比数据策展，报告了约 90% 的准确率。官方也批评偏好优化可能压低其他输出的概率（modedropping），奖励听起来很自信的回答。争论仍需配方和实验来回答。RLCD 是官方对训练目标的描述，并不保证每个新任务都校准。速度还涉及推理路径、模型大小、硬件和服务实现，不能只由这个训练名称推出。10  /  JEV扩散模型的猜测速度快，就一定是扩散吗？猜测的起点Jev 很快。TypeSafe 的 GitHub组织还 fork 过LLaDA。证据的边界两条线索都不能证明内部采用扩散。复刻出同样接口，也不能反推架构。LLaDA 是扩散语言模型；一次 fork 不等于产品采用了它。这些线索都不足以判断内部架构。官方没有提到diffusion，不等于排除了扩散；在预训练模型上做后训练，也不与扩散互斥。output_tokens 与延迟解耦，只能说明这个 API字段不能直接代表内部计算步数。两位研究者的判断Niels Rogge省去自回归生成，就能解释相当一部分加速，不必假设特殊机制。Archer Hume其黑盒实验中，没有必须靠迭代去噪才能解释的现象。内部架构尚未公开。社区用 DiffusionGemma 做出了行为类似 Jev的东西，证明了扩散可以造出同样的接口形态。但其他五个复刻物用的是 encoder、LoRA、指针头等完全不同的路子，也做到了类似的benchmark，从行为无法反推架构。官方明确的是并行输出概率、不按文本逐 token采样。共享 state、隔离问题分支、数值读出头，可以组成一种解释这些行为的架构假设；是否单次前向、是否 MoE、是否含迭代过程，还没有公开证据定论。11  /  JEV速度与定价减少文本自回归解码，是官方描述中最直接的速度线索。不过，速度从哪里来，还要把公开信息和架构猜测分开来看。把现象和解释分开输出路径官方说明并行输出概率。直接读出可能省去长文本解码，但完整实现未披露。共享输入100 个问题以内延迟变化小，1500个约 610ms。64k 总预算、state加最长问题 32k，与共享计算相容。输入长度一组实验：360 token 为 57ms，29800 token 为 218ms。不能据此认定严格线性。上下文上限不保证最坏延迟；负载、排队、网络都需要实测。输出免费是产品的计费方式。直接返回数值有机会减少生成开销，但公开材料不足以看得出 Jev 的实际推理成本。暂时还不知道模型规模约 10B 激活参数、30B dense 都只是社区猜测；是否 MoE 未披露。非确定性特定重复输入实验出现 1.7–3.3% 的标签翻转，来源尚不明确。服务实现hardware-aware 的具体含义、跨地区实际延迟，还不能从接口直接读出来。12  /  JEV200+ 复刻200+发布三天内社区统计的复刻项目A · logitsB · LoRAC · 编码器D · 扩散四条主要路线，下面逐一拆解。JevBench v1.2 · 综合分Jev75.3SemIf74.6DiffusionGemma67.6534 条决策，四维几何平均。该快照中三者分别排名第1、2、5。难题上，差距拉开了JevSemIfhard tier74.1%59.5%SemIf 冻结 Qwen3.5-4B 直接读 logits；作者注明Jev 数字取自公开记录，没有实时调用其端点。接口复现不等于能力相同。社区主要尝试了下面四条路线。13  /  JEV路线 A：零训练 logit 包装实现示意 · 不代表 Jev 已公开的内部结构冻结 LLM 权重候选 logits路线 A · 不训练，先建立基线5.21×SemIf20.03 决策 / 秒。96.53%choosekit144 条任务上，与 Jev成绩相同。做法：冻结 LLM 权重，对候选 token 的 logits 做softmax。数据来自不同项目，不合并排名。快在上手，难在校准方便的地方当天可以接入，底座也能更换。需要测试的地方概率校准、选项间关系，以及选项顺序的影响。一项测试把 A=yes / B=no 换成 A=no / B=yes，准确率从 72% 降到 21%。14  /  JEV路线 B：LoRA + 读出头实现示意 · 不代表 Jev 已公开的内部结构Δ骨干 + LoRApointer head保留 decoder 做骨干，砍掉词表头，换pointer head。代表：kev（jaredpalmer）和Bespoke Nimble。kev · 同一套冻结题目分布内分布外kev-8b86.9%77.4%kev-4b85.2%79.4%Jev84.5%85.7%kev-8b：Qwen3-8B-Base + LoRA。分布外准确率更能看出这组模型的差距。在这组测试里，kev 的分布内成绩更高，分布外仍落后于 Jev。 训练成本：H100 上 40~70 分钟。Nimble 的重点在数据怎么造改一个事实，让答案翻转。2676 条对比样本，一天训练完。自建评测基座 66.4% → 90.1%；Jev 对照为93.2%。换一套题JevBench 综合分 63.5，hard tier为 43.6%。自建评测的提升，不等于换一套题还能保持同样成绩。15  /  JEV路线 C：编码器 + 决策头实现示意 · 不代表 Jev 已公开的内部结构双向编码器决策头双向编码器（ModernBERT / DeBERTa）加决策头。代表：Laya、CUA-S1-FORMS。Laya · 小骨干还需要训练421M总参数量ModernBERT-large 骨干约395M；25000 条人工标注，单卡训练 1.96 小时。0.362零样本成绩typed-decisions 接近随机；在训练切分上微调后为 0.766。<20建议选项数choice 不宜放过多选项。温度缩放后，ECE 从 0.466 降到 0.081。出厂概率并非天然可靠。706K 参数，赢在哪一项专用模型CUA-S1-FORMS，2.8MB。表单整体为99.7%，Jev 为 83.6%。换个统计范围真正需要判断的子任务，Jev 为 96%。差距来源整体成绩受一个 Jev 未训练过的约定影响，不能直接推成通用能力排名。16  /  JEV路线 D：扩散 infill实现示意 · 不代表 Jev 已公开的内部结构带空位的块并行细化继续调整DiffusionGemma · steps / sequentialDiffusionGemma 26B-A4B 也被用来做类 JevAPI。当时的 JevBench 综合分为 67.6、排第五。当时工程实现还依赖未合并的 vLLM PR；费用需要按相同请求量、token 口径和硬件比较。两个控制项steps允许迭代调整，让答案逐渐稳定。sequential后面的块可以读取前面的答案。Jev 同次请求隔离问题，依赖前一结果时要再发一轮；其他路线也能由代码串联。正反 Noul 之和 1.19、关系推理 0 分都是具体探针结果。17  /  JEV数据与难点官方说训练数据由团队自己制作。创始人也认为，数据比架构更值得研究。核心难题：手上有 0/1 标签，没有概率标签，而Jev 卖的正是那个校准过的概率。先从便宜的校准方法试起温度缩放Laya 的 ECE：0.466 → 0.081，相对减少约 82.6%。直接训练概率用适当评分规则训练；kev 和 Nimble 没用RL，也采用了交叉熵。再考虑 RLRewarding Doubt 展示了在未见任务上改善校准的实验。选择方法前，先留出独立验证集。绕开概率标注的方法：Nimble 的对比式策展（改一个事实让答案翻转）和 CUA 的程序化合成（强制 look-alike 混淆对，字段签名不相交切分）。最需要补的测试跨任务校准是非题 ECE 0.012，评分量表0.254，不能用一个成绩代表所有类型。中文官方承认 CJK 更弱；这里收集到的XNLI-zh 仅 200 条，结果 0.79。内部规则24 张发票只对 5 张；19 个错误里，15 个 confidence 超过 0.90。规则没写入 state。选项变化加入无关项、交换顺序，都应进回归集。完整 prompt 上的 logits 同样可能变化。发票结果来自 PawelHuryn 的分类测试。18  /  JEV训练方案一个可执行的复刻顺序先跑路线 A用 SemIf 零训练实现建立基线，收集自己的任务数据。再试路线 BQwen3-4B-Base + LoRA + pointer 读出头 + 块因果掩码。暂缓重工程扩散方案当时分数和工程依赖不占优势，不必一开始就押上去。有小规模复刻报告过不足 $5 的训练成本，但不能外推成通用预算，数据准备、试验和评测也要算进去。也有不必训练的情况通用判断先试 Jev 或 SemIf，用自己的数据比较。固定任务占大头若单一任务占约 80% 调用量，可评估专用小头。706K 是表单案例的规模，不代表所有窄任务都够用。19  /  JEV实时交互应用社区已经做出了一批可运行的演示。耗时与费用由演示者报告，环境和任务不同，不能横向当成统一跑分。实时交互←  左右查看  →
幻灯片自动翻页输入讲话与各页内容判断当前对应哪一页动作翻页（开头的 demo）：两位开发者独立做出。←  01 / 05  →免回车 function calling输入尚未按回车的输入判断参数是否已齐动作执行函数参数凑齐的瞬间就执行，不等用户按回车。←  02 / 05  →语音控制输入用户说话判断当前意图动作操作浏览器300ms 操控浏览器，话没说完 App 已经开了。←  03 / 05  →Ableton Live 控台输入一句音乐操作指令判断目标控制项动作调整音乐软件一句话操控音乐软件，0.5 秒响应，每次调用 $0.00002，对比 LLMcomputer use 要 23 秒。←  04 / 05  →预测式表格输入列首正在输入的字判断各行匹配程度动作即时评分列首打字的同时，每行即时打分，约100ms。←  05 / 05  →
这类应用需要延迟跟得上人的节奏、连续调用费用可承受、结果方便交给程序。格式可约束，判断仍然可能错。20  /  JEV游戏控制游戏：反应速度与规划能力←  左右查看  →
Doom输入预处理后的文本状态判断下一步动作动作移动 / 攻击官方 demo，每秒 7~10 次调用，约 $7/小时。输入是预处理后的文本状态（不是图像）。这个演示也有很明确的限制：输入是文本状态，30~40 行代码可以硬编码出类似行为，看不出规划能力。官方也承认非 AI bot 打得更好。←  01 / 06  →马里奥输入游戏状态判断选按键动作控制角色结构化输出直接当按键指令。←  02 / 06  →俄罗斯方块输入棋盘状态与策略判断选下一步操作动作移动 / 下落改 prompt 就改打法风格，模型可以持续控制方块下落。←  03 / 06  →吃豆人输入Astra 制定的策略判断即时动作动作Jev 执行Astra 定策略 + Jev 毫秒级执行，20分钟搭完。←  04 / 06  →闪电棋输入棋盘与剩余时间判断下一步棋动作落子5+0 赛制下 Jev 每步约 2.6 秒应手，Fable 5.1 每步 6~15 秒。Fable 材料领先 +16 子但超时判负。而 GPT-6Astra 18 步将死 Jev，自己还剩 2:27，时钟让延迟变成胜负因素，但这几局还不足以排出普遍的棋力高低。←  05 / 06  →Minecraft输入开放世界状态判断长期任务下一步动作行动24 小时直播冲末影龙……最终也失败了。有限动作集更容易编排，但这一次失败不能推出所有开放世界任务都会崩溃；长期规划能力需要单独验证。←  06 / 06  →
21  /  JEVAgent 工程Computer use · 不同方案的记录耗时费用查航班7 秒$0.00392048 / Jev44.9 秒$0.001082048 / Astra294.9 秒$1.45航班查询来自 Browser Use；2048 来自 Cua。另一个WebMCP 对照为 49/49，Jev 单独为 25/49，动作空间的收敛很重要。先问：需要唤醒大模型吗？轻量判断判断是否值得调用一次约 $1 的主编排器。分派任务7 个 Agent 的路由演示报告了 145 /271ms。检查继续条件Vercel evaluate() 的 stop 类型，用来判断是否继续执行。批量任务，需要和准确率一起看100 封邮件欺诈判断 96/100，16 秒、$0.07；置信低于 95% 的 31 封交给 KimiK3。500 封邮件$0.035。724 条广告40 秒。11000份文书16.5 份 / 秒。后三组吞吐或费用数字，没有同样完整的准确率报告。不同演示不直接合并比较。还有人用 Jev 给模型的回答打分。在一组包含3300 条生产回放的对照测试里，它在 4 项上胜出、3 项上落后。而在 OntBench 中，它几乎给所有输出都打了高分，没能区分回答的好坏。已接入的工具SDK / 框架Vercel AI SDK、DSPy、PydanticAI、LangChain、CloudflareGateway、Claude Code 插件。社区目录采集时：Jevable 359 个案例，JevDirectory 722 个；有统计称三天出现 3105 个可运行应用。目录数字是发布期快照，统计标准不同。22  /  JEVBenchmark 数据官方四工作流 · 一致率Jev67.8%Sol74.1%Opus 573.1%标签来自 Astra + Fable（high thinking）的共识，不是人工金标；发票处理 Jev 落后 Sol 17 个点。宣传数字，与用户帖记录官方上限用户中位数速度收益193.6×7×费用占比1/444.61/30官方称收益处于上限一端；用户帖统计来自OpenChamber 的 12759 条推文，不是同环境控制实验。第三方评测：每组都保留自己的口径42 / 49胜过无推理 Luna 的任务数jev-decision-bench · 8225 条Banking77Jev78%Terra85%Terra 开启 medium reasoning。JevBench · 单项准确率Luna97.1%Jev96.3%不是前文的四维综合分。钓鱼邮件Jev62.6%Haiku81.3%该组任务中，Jev 明显落后。AlexKim · 16 模型横评10 / 16Jev 准确率排名ECE：Jev 0.121，Haiku 0.122。该组里，Jev 同时做到了亚秒级响应与表达不确定。不同题目、不同指标分别展示，不合成一个总榜。Jev 值得比较的，是判断质量、概率校准、延迟和单价这几项放在一起的综合表现。23  /  JEV边界与翻车官方列出了九类短板基础判断字面理解、算数、日期。复杂条件多跳推理、过长上下文、对抗文本。任务定义矛盾判据、结构不变量、自由生成。对应官方 jaggedness 文档。第三方测试里也出现了一些问题：自信，也可能选错24 张发票 · 同一组内部分类规则5 对19 错其中 15 个错误，confidence 仍超过 0.90。图中带圆点的橙色块表示这些错误。PawelHuryn 的测试：内部分类规则没有写进 state，模型用自己的常识填补了缺失信息。也有开发者认为，这些能力并不新：instructor/ 结构化输出早就有；BERT 十年前就是编码器加分类头；有开发者试两天弃用，说可替换的点比预期少。Jev 目前没有公开论文或权重，内部机制还难以独立核实。官方在 jaggedness 文档里列出了这些局限，还给了具体例子。想用 Jev 的话，这份文档也值得先看一遍。24  /  JEV如何使用：程序中的三层分工把 Jev 接进程序之后，哪些事交给它，哪些事仍由代码或其他模型处理呢？程序中的三层分工确定性代码已知规则、权限、状态，以及if-else 逻辑。决策模型需要常识的分类、选择与评分。推理 / 生成多步思考、长期规划和内容生成。可以理解为把原来混在一起的任务，拆成不同职责。从自己的任务出发要持续判断有界选项、低延迟、概率阈值分支，可评估 Jev。任务固定有标注数据、固定 schema，可试GLiNER 或专用小模型；706K 只是一个表单案例。先求好接入能容忍秒级延迟，可用 SemIf 建基线；综合分只差 0.7 不代表你的任务也如此。不管用不用 Jev，把问题定义和阈值常量集中放一个文件、提交 git、让人 review。这可能是 Jev 带来的最实际的工程变化：问题定义、概率与执行策略有了更明确的接口。这个工程习惯也适用于普通 LLM。官方没有发布论文，以上所有关于内部架构的推断，都是基于公开材料的分析。回到最前面的幻灯片 demo：程序需要不断判断演讲者讲到了哪一页，单次调用足够快、足够便宜，这种持续、快速运行的场景才更有可行性。AGI HUNT  /  2026.09

转载声明：本文转载自原发布平台 （作者：AGI Hunt）， 原文标题《什么是 Jev？》， 查看原文。 版权归原作者及原发布平台所有，本站仅作收录与展示，未对正文内容作实质性修改； 若涉及侵权请联系本站处理。
【同一份电子数据，当事人、辩护人、鉴定人看到的是什么？】 →