JevStation
返回博客

Jev 基准测试汇总：迄今所有独立测试，以及它们说明了什么

Jev 准不准？迄今能找到的所有独立 Jev 测试，从 AI 控制试验到 GLiNER 对比和路由测试，附样本量、局限，并把厂商数字单独列出。

JevStationJevStation

在少数经过独立测试的任务上，Jev 的表现不错，但证据很薄：只有几个小规模试点，没有大型人工标注基准，而且有一个明确的案例显示它校准很差。 它在一项 AI 控制试验中很好地给含后门的代码排了序，在三个文本数据集中的两个上胜过一个零样本分类器，并把 40 条提示词都路由到了预期档位。每项测试的规模都很小，每位作者也都这么说。

本文收集了我们能追溯到的所有独立测量，把 TypeSafe 自己的数字单独放在一节，最后列出还没有人测过的东西。我们的站点跑在 Jev 上，所以对好结果刻意比对坏结果要求更严。

汇总

测试谁做的任务核心结果样本主要局限
AI 控制后门监控Venkat T，发表于 LessWrong把含后门代码排在正常代码之前（一个 Noul）AUROC 0.976；2% 审计预算下约抓到 9/10 的后门600 个后门对 1,200 份正常解答玩具场景、单一数据集、未跑 LLM 基线；原始概率偏弱
jev-benchmarksAbdelStark，GitHub（预注册）零样本文本分类，对比 GLiNER两个数据集上准确率 0.91、0.87，对 0.70、0.61；第三个打平300 条（每个数据集 100 条）第三个数据集上校准很差；延迟对比条件不对等
LLM 路由一位 Classmethod 工程师（DevelopersIO）从四个模型档位中选一个40 次调用全部返回预期档位40 次调用，每档一条提示词作者：不是准确率基准
重评 TypeSafe 示例jev-on-a-laptop，GitHub与 TypeSafe 参考答案的一致率86.6%，处在 86–90% 的前沿模型区间内20 个案例中的 343 个问题对参考答案来自前沿模型，不是人工标注
LLM 国际象棋排行榜一位 dev.to 作者下完整的国际象棋对局Elo 约 243，排名约第 59；每局都下完80 局不是 Jev 的设计用途
agent-assist 延迟jev-experiments（由 Devin 智能体构建）选客服话术模板，每次调用九个问题Jev 调用 p50 88 ms，p95 209 ms40 条消息只测延迟；LLM 基线是模拟的
单次评估成本JevStation不同请求规模下的 token 用量每次评估 $0.000012 到 $0.00037711 次调用只测成本；单一模型版本

AI 控制试验：排序强，概率弱

迄今最完整的测试是一项在 ControlArena APPS 后门场景上做的 AI 控制试验，发表在 LessWrong。整个监控器只有一个 Noul，问代码里是否有被刻意植入的后门，state 约 1,050 个 token。测试集是 600 个经验证的后门，对比 600 份 LLM 写的和 600 份人写的正常解答。

  • 排序： 对 LLM 写的正常代码 AUROC 0.976，对人写的 0.970；在 2% 误报率下分别抓到 89.5% 和 87.8% 的后门。
  • 一致性： 同一批代码重复打分五次，分数平均只变动 0.008，被标记的前 10% 在各次之间重合 92.4%。
  • 对照： 一个只看代码长度的模型得分 0.674，说明 Jev 不只是在读长度。

作者对弱点说得同样清楚。Jev "相当欠自信"，所以原始分数是好的排序、差的概率。能在提交前查几次分数的攻击者让约三分之一的后门漏过，而不是十分之一。Jev 对新增分支的识别远好于对已有逻辑的改动。作者也没有跑 LLM 基线，所以和已发表的推理模型监控器（0.92 到 0.96）的比较只是定位参考，不是实测。整个试验花了约 5 美元的额度。每个数字的细节见《用 Jev 当评判模型》。

jev-benchmarks：三个数据集中两个胜过 GLiNER，一个校准更差

jev-benchmarks 是唯一一项预注册的对比。它在三个数据集上各取 100 条留出样本，比较 jev-1.13.0 和 fastino/gliner2.5-multi-v1。

数据集标签数Jev 准确率GLiNER 准确率Jev − GLiNER，95% 置信区间Jev 覆盖率（误差 ≤5%）GLiNER 覆盖率
AG News40.9100.700+0.130 到 +0.2900.8300.240
Banking77720.8700.610+0.220 到 +0.3000.8600.270
DAIR Emotion60.4800.440−0.070 到 +0.1500.0000.020

在情绪标签上，准确率差异没有定论，而 Jev 的校准明显更差：Brier 0.846 对 0.668，NLL 5.588 对 1.381，并且有 16% 的样本给真实标签的概率是零。作者说结果是"刻意呈现的有好有坏"。延迟不可直接比较：GLiNER 在本地 CPU 上运行，Jev 是从法国调用的托管 API。这对两者之间怎么选意味着什么，见《Jev 的替代方案》。

Classmethod 路由测试：40 中 40，按作者自己的说法只是冒烟测试

一位 Classmethod 工程师把 Jev 当作 LLM 路由器里的分类器来测试，共四个档位：simple、medium、complex 和 reasoning。40 次调用（每档 10 次）全部返回了预期档位。延迟中位数 0.643 到 0.674 秒，每次调用约 $0.000025 到 $0.000027。两端档位返回的置信度是 1.0，medium 档在 0.57 到 0.67 之间。

作者写明了局限：每个档位只用一条提示词，Jev 是单独调用的而不是接在路由器里，也不是对准确率的全面测试。medium 档的低置信度是最有用的发现，因为边界上的提示词正是路由器省钱或亏钱的地方。问题集见 LLM 路由器工具页。

jev-on-a-laptop：重评 TypeSafe 自己的示例

jev-on-a-laptop 主要是在小型开源模型上本地复现 Jev 背后的思路，没有接触 Jev 本身。它还重建了 TypeSafe 四个工作流评估的公开示例（20 个案例），并用 TypeSafe 的参考答案给各模型打分：Jev 86.6%（343 个问题对中 297 个一致），Opus、Sol 和 DeepSeek v4.1 Flash 为 89.2% 到 89.8%，本地 7B 模型为 73.8%。作者的解读是 Jev 处在前沿模型区间之内。

两点局限。参考答案是 TypeSafe 的，而且来自前沿模型而不是人工，所以这测的是一致率，不是正确率。作者还提到，更早一次只有五个案例的测试显示打平，后来证明那是小样本造成的假象；这对本文的每一项测试都是有用的提醒。

国际象棋和延迟：能说明什么，不能说明什么

一位 dev.to 作者让 Jev 上了 LLM 国际象棋排行榜：Elo 约 243，排名约第 59，每一局都下完，没有非法走子。80 局共花费约 $0.12。这个分数几乎说明不了分类能力；每局都下完说明类型化输出守住了协议。同一位作者还发现 Jev 不擅长一个字母一个字母地生成单词。

在 jev-experiments 里，一个由 Devin 编程智能体构建的客服中心演示对每条客户消息发送九个问题。40 条消息中，Jev 调用 p50 为 88 ms，p95 为 209 ms。这只是延迟测量；仓库里"快约 43 倍"的对比，对象是一个模拟的 4 秒 LLM，作者也明确标注了是模拟的。

我们自己的测量：成本，不是准确率

我们在 JevStation 允许的所有 state 大小和问题数量范围内发了 11 次真实请求，记录 Jev 返回的 token 数。结果：每次请求约 260 个 token 的固定开销，之后 state 约每 6 个字符一个 token，问题 JSON 约每 5 个字符一个 token，合计每次评估 $0.000012 到 $0.000377。方法和局限见《一次 Jev 评估到底花多少钱：实测》。它不涉及准确率。

没有数据支撑的实践者反馈

TechCrunch 里有两则常被转述的反馈。一位 Vercel 工程师说，把用于命令安全审查的 LLM 分类器换成 Jev 后，结果快了 5 到 18 倍，准确率也更高。Bryo AI 的 CTO 发现在商务邮件分类上 Gemini 略准一些，但贵 10 到 20 倍。两者都没有公开数据集或方法，只能当作个案。

还有一个流传的数字："67.8% 对 74.1%"，被说成是 Every 做的独立测试。这两个数字与 TypeSafe 自己公布的评估完全一致，而我们找不到那项独立研究，所以不计入。

厂商公布的数字

以下数字来自 TypeSafe，不是独立测量，阅读时应带上 TypeSafe 自己的说明。

  • 价格： 输入 $0.042 / 百万 token，输出免费。
  • 延迟： 端到端 70–500 ms，称比前沿 LLM 快 40–200 倍；首页上的"快 193.6 倍、便宜 444.6 倍"，按 TypeSafe 自己的说法，可能处在真实收益的偏高一端。
  • 工作流评估： Jev 平均 67.8%（各工作流 61.7% 到 76.0%），每个案例约 $0.0004、0.4 秒。TypeSafe 说明参考答案是两个前沿 LLM 的平均，会让结果偏向这两个模型，而且工作流由他们自己的团队搭建。第三方文章给出的同一评估框架下，一个 GPT-5.6 模型为 67.9%，另一个更强的为 74.1%，见《System One 模型是什么，不是什么》。
  • 批量提问： 13 个问题放在一次调用里，比分 13 次调用便宜 11.5 倍、快 9.6 倍。
  • 类型错误： 0%，TypeSafe 自己说这个数字不是实测得来的，而是由 schema 保证的。

TypeSafe 还表示，他们刻意不在公开基准上发布成绩。

还没有人测过的东西

  • 大规模、人工标注的准确率基准。 本文所有准确率数字要么来自小规模试点，要么是与模型生成的参考答案的一致率。
  • 真实业务负载上的校准。 一项研究发现两个数据集上校准良好、第三个很差；另一项发现 Jev 欠自信。Jev 自身任务上的校准曲线至今没有公开。
  • 与 LLM 在相同输入上的正面对比， 由 TypeSafe 以外的人来做，并且真的跑了 LLM 基线。
  • 非英文的准确率。 TypeSafe 说其他语言的效果不如英文，但没有人公开过数字。
  • 跨模型版本的稳定性。 上面所有测试都跑在迄今唯一发布的版本 jev-1.13.0 上。记录每个响应里的 model 字段，版本变化时重新检查你的阈值。
  • confidence 的计算公式， TypeSafe 尚未公开。

上面每位作者得出的实际结论都一样：用你自己的数据来测。把二十条你知道答案的输入贴进试验台，前 200 次评估免费。大家都在测哪些任务，见《Jev 用例》。

来源

继续阅读

Jev 的替代方案：什么时候该用 LLM、GLiNER 或自己训练的分类器

Jev 把文本变成带概率的类型化判断。结构化输出的 LLM、GLiNER 这类零样本分类器、你自己训练的模型也能做到。本文讲清各自擅长什么，并给出有实测的数字。

阅读全文

用 Jev 当评判模型：一个是非题能抓住什么、会漏掉什么

一个不写文字的模型能当 LLM 评判吗？目前最好的公开测试显示，只问 Jev 一个是非题，识别后门代码的 AUROC 就达到 0.976，每千次检查约 $0.04。本文讲它在哪里成立、在哪里失效。

阅读全文

一次 Jev 评估到底花多少钱：实测

我们按应用允许的每种 state 规模与问题数量发起了 11 次真实 Jev 调用，拟合出 token 模型并实测成本：每次评估 $0.000012 到 $0.000377。

阅读全文