Jev 决策模型初探

2026 年 9 月 15 日，TypeSafe 发布了 Jev——一个不生成文本、只返回带概率判断的模型。它在中文技术圈的热度从 9 月 21 日早上开始明显上升，因为官方在那天凌晨取消了 waitlist，注册即送 $5 额度（约 1.2 亿输入 token），不用绑卡。

==一句话结论：方向是真的，但适用区间比宣传的窄。它的置信度是一个”封闭世界”的置信度，而且中文表现明显弱于英文。==

这篇把官方 API 的调用方式、几组本机实测、社区已经踩过的坑放在一起，给想判断”要不要花时间试”的人一个参考。所有标注为实测的数据都由本机脚本产出、可复现；转述的第三方数据会写明出处。

从一张客服工单说起

先看一个具体场景。客服系统里进来这样一条工单：

同一笔订阅被扣了两次，我要退款。已经等了两天没人处理。

后台同时能查到的字段有：订单号、扣款记录（9 月 19 日两笔）、客户等级、历史工单数。系统需要在这条消息进来后的几秒内决定三件事：归哪个团队处理、客户是不是在要退款、有多紧急。

这三件事没有一件需要”推理”。它们需要的是一个又快又便宜、还肯告诉你”我有多确定”的判断函数。过去这类判断要么写规则（“扣款”两个字命中就转 billing，稍一变体就错），要么调一个大模型（准，但慢、贵，而且它说不出自己有多确定）。

Jev 想占的就是这个位置。它不生成文字，只回答你事先定义好的问题，并且把概率一起还给你。

Jev 是什么

Jev 出自前 OpenAI 研究员 Diogo Almeida 之手——他是 InstructGPT 的主要作者之一、RLHF 的早期参与者。公司今年拿到 DCVC 领投的 4000 万美元种子轮。

它最反常识的地方是不生成文本。你给它一段程序状态，加一组类型化的问题，它一次性把所有答案算出来，返回的是带概率的结构化值。没有 token 流，没有要 parse 的字符串，也没有一句人话。

问题只有三种：

它想占的位置叫 System One，这个词借自卡尼曼——System 1 是直觉、并行、廉价，System 2 是推理、串行、昂贵。TypeSafe 的判断是：软件里大量的判断本来就是 System 1 级的”分桶、判断、路由”，却一直在用 System 2 的模型硬扛。

这个定位要放下两个误解。它不是全新范式——把”分类器 / cross-encoder / reward model”这条跑了十几年的路线，接到大模型的通用语言理解上重新封装，不算发明。但它也不是”BERT 意图分类器换个 API”——值得看的是 zero-shot 定义标签 + 并行推理 + 校准这三件事同时成立。

官方自己画的技术谱系图挺诚实：

RLHF 对齐人类偏好，RLVR 对齐可验证奖励，RLCD（reinforcement learning from calibrated decisions）对齐的是概率与真实结果。Almeida 说 Jev 完全用合成数据训练，并把”统计上可控的合成数据”称作公司一半的核心资产。

怎么调它

请求体长什么样

还是那张工单。把材料放进 state，把要判断的事写成 questions：

{
  "model": "jev-latest",
  "state": "客服工单 #48213：客户说同一笔订阅被扣了两次，要求退款，语气很急。",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "这个工单应该归哪个团队处理？",
      "criteria": {
        "billing": "付款、发票、退款",
        "technical": "产品故障、性能问题",
        "account": "登录、权限、账户"
      }
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "客户在要求退款吗？"
    },
    "urgency": {
      "type": "score",
      "instructions": "这件事有多紧急？",
      "criteria": ["低", "中", "高"]
    }
  }
}

返回是这样（下面是实测的真实响应，只省掉了 department 的选项概率表）：

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice", "choice": "billing",
      "probabilities": {"technical": 0.0, "account": 0.0, "billing": 1.0},
      "confidence": 1.0
    },
    "refund_requested": {"type": "noul", "noul": 0.98},
    "urgency": {
      "type": "score", "score": 1.95,
      "legend": {"0": "低", "1": "中", "2": "高"},
      "probabilities": {"0": 0.0, "1": 0.05, "2": 0.95},
      "confidence": 0.92
    }
  },
  "usage": {"input_tokens": 472, "output_tokens": 70}
}

注意 Noul 的返回里没有 confidence 字段，只有一个概率。如果代码里统一按 confidence 取值，Noul 那一支会拿到 None。confidence 和 noul 要分开读：前者是分布有多集中，后者才是是非判断的概率。

接入方式和几个硬限制

POST https://api.typesafe.ai/v1/systemone
model: jev-latest        （实测回报 jev-1.13.0）

• 价格：输入 $0.042 / 百万 token，输出免费。 新账号那 $5 约等于 1.2 亿输入 token。
• 上下文：单请求 64K token，但其中只有 32K 留给 state + 最长的问题。 长材料要先切块，撞上限会返回 400 max_tokens_exceeded。
• 限速：250K token/秒、1200 请求/分钟，而且官方明确说这个数字会随时变，因为正在等 GPU 扩容。超限返回 429。
• 模型闭源，不支持微调，所有账号共用同一套权重。适配靠三件事：材料塞进 state、规则写进 instructions/criteria、大判断拆成原子问题在代码里组合。
• 英语是主训练语言。 官方原话是其他语言”能处理但不同等”，中文场景必须自己跑评测——后面有一组实验证明这句话不是客套。

官方还发了个 Agent Skill，装上之后写代码的 agent 会自己知道该怎么调：

npx skills add typesafe-ai/skills --skill typesafe-ai

官方直连和 OpenRouter 差多少

社区有个说法是官方端点比 OpenRouter 快很多。实测下来对，但幅度被高估了。

做了交错采样（每一轮交替调用两边、随机化顺序，避免时间漂移污染结果），每条目 24 次：

1. 差距是 5%–8%，不是数量级。 真正明显的是稳定性——OpenRouter 的 p90 在短 state 上差了 60ms 以上。
2. 两边服务的是同一个模型。 官方回报 jev-1.13.0，OpenRouter 回报 typesafe/jev-1.13-20260917 + provider: TypeSafe，输入 token 数完全相同。差的不是模型，是链路。
3. 延迟比一周前快了 2–3 倍，而模型版本没变。 9 月 20 日测同一批请求是 568–792ms，今天 245–326ms——开放注册前官方显然做了扩容。任何延迟数字都要带测量日期。

所以如果只是想要一个统一的计费视图，OpenRouter 完全够用；如果在意尾延迟，直连。但别把”官方更快”当成选型理由，那是 5% 的事。

它能一次问多少个问题

这是 Jev 区别于 LLM 的结构性能力，值得单独说：一次请求里问 N 个问题，延迟几乎不涨。

实测：同一份 state，问题从 1 个加到 30 个，延迟基本没动（269ms → 296ms），只有 token 数线性增长（978 → 2328）。

它的意义不在于”省了 N 次请求的钱”，而在于它改变了工作单元：

• 用 LLM 时，你问一个问题、解析答案、再决定下一步——控制流在模型手里。
• 用 Jev 时，把所有可能影响决策的问题一次问完，拿回一个定长向量，分支写在自己的代码里——可测、可日志、可重放。

代价是 token 随问题数线性涨。所以它本质上是把延迟问题换成了 token 问题。这笔交易划算，只是因为 token 便宜、延迟不便宜。

那它有没有天花板？ 专门扫了一遍——同一批查询，候选数从 5 加到 50，每个候选一道 Noul：

问题数翻了 10 倍，延迟只从 317ms 涨到 393ms（+24%）；token 涨了 8.5 倍；而质量不降反升。 没有出现”问题多了互相干扰导致质量下滑”的现象。

由此得到一个设计原则：别省着问，省着放。 该纠结的是 state 里塞多少材料（那才是真正贵、且有上下文上限的部分），不是问题问了几个。

具体用法大致三种形状：多问题 × 单份材料（把一个模糊判断拆成五到八个窄问题，一次并行问完，工单分流、表单校验、工具审批都是这个形状）；单问题 × 多份材料（把判断扇出到全量数据上，以前”扫一遍所有日志”因为贵只能抽样，现在这个价位可以全量跑）；塞进高频循环（语音助手逐句判断”是不是在对我说话”、游戏 AI 每秒两三次决策）。官方 skill 还专门建议”问一些有用的推测性问题”——把所有可能的下一步动作一次问完，走到哪个分支再取哪个答案。

社区已经有具体数字：OpenRouter 的 feed filter 是一条请求判断 40 条帖子；官方的工具调用审批配方是 24 个 tool call 各做 4 项检查，96 个检查一次跑完。

（一个诚实的边界：只测到 50 就停了，因为候选池只有 50。K 再往上会不会出现质量拐点，这批数据回答不了。官方的 32K “state + 最长问题”预算也意味着，候选越多、每篇能放的文本就得越短——这两个是绑在一起调的。）

它的概率准不准

造了一套 54 道可真值判定的题（12 行员工名册，题型混着来：直查、否定、全称量化、计数比较、数值比较、日期推理、两跳关系），答案由代码算不由人判断。

结果是准确率 94.4%，ECE 0.048（ECE 是 Expected Calibration Error，衡量你说的把握和实际正确率差了多远，0.05 以下通常算校准良好）。最高那一档（0.97–1.01）24 道题全对。

但校准好只说明它平均而言诚实，不说明它的置信度有用。有用是指它能分辨出自己哪些题会做、哪些不会做。把它和 DeepSeek-V4.1-Flash 放在同一批难题上比：

DeepSeek 更聪明（那批题它全对），但它对”我会的题”和”我不会的题”一样自信。Jev 答错更多，却明确知道自己哪些题没把握。

这就是 confidence-gated routing 里真正要找的东西。你要的不是一个更自信的模型，是一个能分辨自己会错在哪的模型。前者的置信度只是一句安慰，后者才是可以写进 if 的信号。

这一点上有个第三方做了更严格的对照：一份预注册测试里，Jev 的原始准确率在所有参测模型里只排中游，但允许每个模型跳过自己低置信的案例后，Jev 在两个任务上都反超了——包括它原始准确率落后的那个。作者的总结是：“你可以从任何 LLM 拿到同样的答案，但你拿不到同样的那个数。”

顺带一个可能对中文用户有用的结论：把同一批题翻译成中文又跑了一遍，准确率 0.944、ECE 0.039，和英文几乎一致，而且错的是同样那三道题。社区流传过”Jev 中文弱”的说法，至少在这个口径下不成立——不过下一节会看到，这个结论不能外推。

材料里没写的，它当成不存在

上面那些题，材料里都写着答案。接下来这组没有。造了 24 道材料里根本没有答案的题：“Ava 有兄弟姐妹吗""Ben 对薪酬满意吗""Rex 半年内打算辞职吗”。这类问题没有正确答案，正确的行为就是低置信。

结果 Jev 在这组题上的平均置信度是 0.831，24 道里有 8 道给出了超过 0.90 的确定答案：「Uma 有博士学位吗」它说否，0.96；「Vic 入职时拿到签约奖金了吗」它说否，0.97。这些信息材料里一个字都没有。

而同一组题里，DeepSeek 24 道有 22 道给出的是精确的 0.50，一个干净的”我不知道”。

分界线不在信息缺没缺，在问题类型。 问”某个属性存不存在”的时候，它把材料里的”没写”读成了”不存在”，给出 0.87 的确定否定；问”这是什么判断”的时候，它反而给的是真实的不确定（0.57）。

还试了四种”怎么写缺失”的文案——静默省略、明示”没有信息”、明示”你只看得到它在”、显式宣告”这份材料是完整的”。对判断类问题四种文案几乎没差别；对属性类问题有作用但不解决问题，明示缺失只把 0.88 降到 0.73，还是很高。

所以这不是 prompt 能修的。 它是封闭世界语义的一部分：Jev 回答的是”在你的材料里”，不是”在世界上”。材料里没出现的，对它来说就是假的。

危险的地方在于，人会把 0.96 读成”这件事在世界上 96% 为真”，而它实际说的是”在你的材料里找不到”。材料是世界的节选时——大多数时候都是——这个假设就会咬人。

当重排模型用：英文打平，中文落后

这是社区最热的用法之一。网上已经有人做过这个对比，Zilliz 那篇（9 月 21 日）的结论是”Jev 效果更好，但代价也明显更高”——测到 Jev 的精排延迟是专用 reranker 的 10.2 倍、成本 6.7 倍。

这个结论值得怀疑，因为那些延迟数字来自**“一个候选一次请求”**这个调用形状（30 个候选并发 30 次调用），而上文刚说过，这个模型的能力恰恰是”一次请求问 N 个问题”。把调用形状的开销算进模型本身，等于测错了对象。

于是重做了一版，把 Jev 包成一个和专用模型完全同契约的重排接口：同样的 query、同样的候选集、同样的文档文本长度、同样的指标算法，唯一差别是内部怎么算出那个分数。候选集用 BM25 top-50（重排文献的标准基线，确定可复现）。三条语料各抽 100 条查询对照 Qwen/Qwen3-Reranker-8B。

三点结论：

• 英文场景：质量打平、成本打平、延迟快一个数量级。 它替代不了一个调好的专用 reranker（没有收益），但它是个不用换基础设施就能拿到同等质量、且快得多的选项。如果重排环节现在是延迟瓶颈，或者干脆还没上重排，它是个合理的起点。
• 中文场景：不要用。 三个措辞的置信区间全部排除零，这不是”效果差不多”的程度，是统计上看得出来地更差。这正好印证了官方那句”能处理但不同等”。
• 调用形状对质量的影响比换模型还大。 同一个模型、同一批文档、同一个问句，只是一次问完 50 篇而不是一篇一篇问，nDCG@10 从 0.7594 掉到 0.6569——掉了 0.10，比 Jev 和 Qwen 之间的差距大一个数量级。

（一个必须说明的局限：中文那组每篇文档只截断了 600 字符，因为 Jev 的 32K 是 “state + 最长问题” 共享的预算，50 篇文档塞不下更多。也就是说中文组双方拿到的材料都更少，绝对分数不可与英文组直接比。但如果 Jev 的长上下文中文理解是弱项，这个截断反而对它有利——它还是在输。）

别人已经踩过的坑

这一周从 GitHub、HN、公众号上能看到的东西，比官方文档有信息量得多。

重排：三个互相矛盾的结论

除了 Zilliz 那篇，还有两篇值得放在一起看。

hev/jev-rerank 是目前最严格的横向对比，把 Jev 和 Cohere rerank-v3.5、Voyage rerank、Mixedbread、GPT-5.6、Claude Haiku/Opus 放在同一份 BM25 top-30 候选集上比。结论是 Jev 在三个语料上都”达到或超过 Cohere”。它的关键发现是：Jev 用 30 个 Noul 一次请求的形状，p50 只有 208–238ms——正是 Zilliz 没测的那种写法。

zhuyansen/jev-search-rerank-eval 是一篇负面结果，而且做得很规范（164 条中英查询、9831 个标注对、还量了”裁判循环性”）：单独用 Jev 的分数，打不过一个好的 embedding ranker（+0.012 nDCG@10，置信区间跨零；换一个不相关的模型来判，甚至是 −0.028）。但融合有效：rrf(bge-m3, jev@30) 比纯 embedding 高 +0.090，置信区间 [+0.077, +0.104]。作者的原话是：“Jev 在这里的价值是第二路信号，不是排序器本身。”

三篇放在一起看比任何一篇单独看都有用：Jev 在重排上的收益有很大一部分取决于它被放在哪儿——单独当 ranker，收益不稳；作为并行的一路信号被融合，收益稳定。

上下文压缩：一个正在发生的翻车

这是社区最热的用法，也是最值得引以为戒的。

思路很直接：agent 的上下文一直在涨，与其用一个 LLM 写摘要，不如让 Jev 逐条判断”这个工具调用/结果还需要保留吗”，低于阈值就删掉。LiteLLM 已经把它做成了生产级的 guardrail，还有一堆 Claude Code / Codex 插件在做同样的事。

然后被打脸了。有人拿 16 个真实的 Claude Code 会话跑了复现：256 个工具结果，没有一个分数到 0.5，240 个被删掉或截断。而一个永远回答”不保留”的假打分器能做到 88.5% 的字符削减——真 Jev 是 87.7%。也就是说默认策略实际上等价于”全删”。 另一个开发者报告删掉了 98.7% 的上下文，丢了 7 个关键事实里的 6 个。

Theo（t3.gg）的批评值得完整引用一遍：“压缩是重建，不是过滤。” 逐条本地判断丢掉了跨轮次的关系；Jev 只看到占位文本（ok, 4213 chars (omitted)），根本不知道哪个失败重要；而且删 token 可能因为 prompt-cache 重写反而更贵。

这个案例的价值不在于”Jev 不行”，而在于它演示了一个通用陷阱：阈值型判断需要先验证分数分布。如果所有分数都挤在一端，你的阈值就不是阈值，是删除开关。

其他值得看的

• browser-use/jev-ultrafast（14k stars）——浏览器 agent，Jev 逐步决定”点哪个元素”，LLM 只负责打字。Google Flights 查一趟苏黎世到伦敦 7.1 秒、$0.0039。
• LangChain 的 agent 评测（9 月 20 日）——用 Jev 当 evaluator，5 条 agent trace 各重复 100 次对照人工 oracle：Jev 500/500 全中，GPT-5.6 Terra 99.8%、Claude Sonnet 4.6 80.0%，而且质量分的方差比 LLM 判官低 92–913 倍。
• Cribl 的负面结果（9 月 17 日）——用 Jev 把日志分成 28 类，错误率是专用分类器和 GPT-5.6 Terra 的 2–3 倍，最常见的失败是把已知类型丢进”其他”桶。换来的是快 18 倍、便宜 20 倍。
• jev-trader——每个 Monad 区块（约 300ms）做一次交易决策，实测模型延迟 81ms。

厂商自己写下的失效模式

docs.typesafe.ai/model-jaggedness/jev-1.13 是整个生态里最值得读的一页。厂商主动列出自己模型的九种失效模式，这个做法本身就该加分。

几条最要紧的：

它不会算数。 官方原话是”计数不可靠，把算术留在代码里”。前面那 54 道题里 Jev 的三道错题有两道就是计数题，和这条完全吻合。

日期是按文本比的，不是按时间序。 混用格式、季度、结算窗口时最容易出错。

state 是数据，它默认不把 state 当敌意的。 这句话的意思是提示注入可以推动它的答案。如果打算把它当护栏用，这条必须先想清楚——这正好解释了上面”上下文压缩”为什么会翻车。

结构不变量不保证。 官方给了一个具体例子：同一张工单，“客户在要求退款吗”用 Noul 问得到 0.22，用 Choice 的 yes 选项问得到 0.01；而且一个问题 P(yes)=0.72、它的否定 P(no)=0.47，加起来是 1.19。官方原话是”不要拿算术恒等式去要求它”。

准确率会随无关 state 增加而下降（context rot）。

另外两件不需要官方承认、但社区已经量出来的事：

校准这件事本身有争议。 有一份独立审计重算了所有公开的 ECE 数字，结论是”在任何难度上概率都没有校准，ECE 是噪声底的 2.1–2.5 倍”，建议”把 Jev 的输出当成单调分数，不是概率，然后自己拟合校准映射”。反过来的证据也有：另一份测试发现符号是按原语分的——Choice 和 Score 过度自信，布尔型反而不够自信。所以真正决定能不能设阈值的是误差的方向，不是 ECE 的大小。

它的营销数字要带着出处引。 “快 193.6 倍、便宜 444.6 倍”出自官方自建的四工作流评测，官方自己在博客里列了三条偏差（是”真实收益的偏高区间”、工作流由自家团队制作、参考答案取的是 GPT-6 Astra 和 Fable 5.1 的平均值）。有一个第三方说得很准：它测的是”Jev 多便宜地同意前沿模型”，不是”Jev 多经常是对的”。至于”0% 结构化错误率”，官方自己在发布博文里写了 “our number is not empirical”——那是 schema 的数学保证，不是实测。

一个能盯着看的演示：Jev 小镇

上面这些结论光看表格很难有体感，所以做了个能盯着看的小游戏。

（开源在 github.com/eriklee1895/jev-town）

十二个居民、五个地方——集市、广场、酒馆、码头，还有一条后巷。每个居民每刻的每个判断，都是一次独立的 Jev 调用。而每个人拿到的材料里只有他自己视野范围内的那几个地方，后巷只有身在其中的人才看得见。

第 8 刻，广场上出现一个没有来历的包裹。然后能看到居民们朝它聚拢——不是脚本，是每个人各自判断”要不要靠近”的结果。

几个细节直接来自前面的实验结论：

• 头像外圈的颜色是戒备程度，鼠标悬停能看到他这次判断的完整概率分布；
• 右上角闪问号的是领先幅度不到 25% 的决定，就是那种离翻盘只差一点抖动的；
• 往材料里只写”门口有个包裹”不写里面是什么，然后会看到它对”上面有名字吗”这种问题给出 0.8 的确定答案——封闭世界那个坑在这里变成了看得见的东西；
• 给某个居民戴上眼罩，材料里不再包含任何可见信息，他仍然会继续做决定。

跑起来的量级：一屏十几个居民、每刻三十多个决策、二十多个决策每秒、单个决策成本约 $0.0000065。跑三十六刻两千多个决策，总共花了 $0.013。

第二层放了个对照：每八刻让一个小模型从高处看一眼全镇，写一段给镇长的简报。它拿到的不是画面，是结构化摘要。有一次它写出来的是：

广场中央凭空出现了一个无人认领的包裹，清晨已有六人聚在附近，多数倾向于凑近查看，但素娘和陈九仍在犹豫，风向随时可能倒向另一边……素娘和陈九这两张摇摆票是眼下最该盯住的。

它抓住了摘要里标注的”这一票很接近”，把两个摇摆的人点了出来。

两层大脑的差别一屏就能看出来：

这不是设计出来的，是测出来的——Jev 那边加问题不增延迟，另一边每次实打实要一秒多，架构只能跟着延迟走。

复盘：这次实验里踩的四个坑

参考别人的实验容易，发现自己实验的漏洞难。这次至少踩了四个，都记在这里：

一、第一轮对比里，两条臂拿到的材料不一样长。 给 Jev 的文档截断到 1200 字符，给 Qwen 的是 2000 字符。结果 Jev 的 token 消耗看着更少、分数看着更高——那测的是”谁看得多”，不是”谁判断得准”。改成同一个常量后才有了上面那张表。

二、措辞的影响和换模型是一个量级，而且不稳定。 前后跑了两轮，第一轮 task 措辞最好，第二轮 plain 措辞最好——排名是翻转的，而组间差距都在 0.01 上下，和那个”打平”的宽度一样。所以”Jev 在某项上比某模型高 0.01”这种结论，在这批数据上是不该下的。

三、BM25 的空候选集会被误读成”重排效果差”。 第一版 BM25 只返回命中词项的文档，NFCorpus 上 323 条查询里有 25 条拿到空候选集——那样跑出来的不是重排指标，是检索失败率。真实 BM25 是对全部文档排序，不命中的得 0 分但仍在候选里，补齐之后数据才成立。

四、中文那组的 32K 上限是踩出来的。 一开始按英文的参数（每篇 2000 字符）发请求，直接返回 400 max_tokens_exceeded。Jev 的 32K 是 “state + 最长问题” 共享的，比 Qwen 那个纯 32K 更紧——同一个数字，两家的含义不一样。

还有一条不属于”错”但必须说清楚：中文那组只测了 100 条查询、单次运行，没有做多种子重复，也没有做显著性校正。它足以支撑”中文别直接用”这个方向性结论，不足以支撑任何精确的效应量。

什么时候该用，什么时候不该用

结论比社区流行的说法要窄一些。

值得用的场合：

• 有几十上百个异质、多变、没有标注数据的碎决策，不可能为每个分支单独训一个模型，也懒得为每个分支写一遍 prompt。
• 决策需要置信度信号本身，而不只是答案——也就是要按置信度分流。
• 输入本身就是结构化的程序状态，而不是需要理解的长文本。
• 成本敏感且量大，尤其是那些”以前因为贵所以只能抽样”的场景。

不适合的场合：

• 材料可能只是世界的节选，而你需要它知道”自己不知道”。 这是最大的坑，而且是静默的。
• 中文场景下的重排。 实测它在中文语料上显著劣于专用精排模型（英文语料上打平），和官方”中日韩文字能处理但不同等”的说明一致。中文的其它场景值不值得用，得单独测——别拿英文的评测结果外推。
• 单一、稳定、有标注数据的高频任务——这种情况微调一个小模型仍然更便宜、更可控、还能私有化。
• 需要世界知识、需要检索、需要生成文本的场景。
• 需要图像或音视频输入，它目前是纯文本。
• 需要算数、需要严格日期比较、需要对抗性输入防护的场景。 这三条官方自己写在 jaggedness 文档里。

验证方式： 挑一条真实的决策链，和现有方案比三个数就够——准确率、P99 延迟、单次成本。别拿官方那套倍数当依据。

还有两条跟用不用 Jev 无关、但更值钱的建议：

第一，把”置信度”和”领先幅度”分开记。 置信度告诉你这个答案有多可靠，领先幅度告诉你这个决定有多接近翻转。它们是两件事——一个模型可能在置信度上很诚实，但它的决定依然悬在一票之差上。小镇里实测过：概率在抖（±0.02–0.04），但决定不抖（12/12 完全相同），因为大多数时刻某个选项是压倒性的。但同一批决定里有三个领先幅度不到 25%，最接近的只领先 0.04，基本就是抛硬币。 该问的不是”这个模型确定吗”，而是”这个决定离翻转有多远”。

第二，一旦调好了置信阈值，就把版本钉死。 jev-latest 是别名，新版发布会自动跟进，答案可能在无感知的情况下变化。响应里的 model 字段会回报实际作答的版本，建议落日志。

最后说回那道题。“Uma 有博士学位吗”，Jev 说否，96% 确信。

它错了吗？取决于你问的是哪个世界。在它拿到的那份名册里，确实没有任何一行写着 Uma 有博士学位，按封闭世界的读法，“否”没有错。但在真实世界里这个答案毫无意义。

Jev 把这个问题当成了一道它有信息回答的题，然后算得很认真。 这就是它最值得被写下来的地方：它的校准是真的，区分度是真的，便宜和快也是真的，但它的置信度是一个封闭世界的置信度。你越信任它，越容易忘掉这一点——而它不会提醒你，因为它没有”我不知道”这个状态。

本文所有标注为实测的数据由本机脚本产出，可复现；方法、原始结果 JSON 与数据来源见同目录 notes.md。官方数字均标注出处与口径；Zilliz、hev、zhuyansen、LangChain、Cribl、primeline 等第三方数据为转述，未独立复现。