Jev 决策层实验室

第0章 二十分钟把地基补齐

你大概率见过一句「七成把握」，点开过某个网页背后那次看不见的请求，也在某处瞥过一坨大括号套小括号的文字——这一章不教新东西，只是把这几件散落的常识收到一处，焊死几个后面几十节里天天要用到的说法。

一句「七成把握」到底在说什么

扔一枚硬币一次，正面朝上还是反面朝上，你没法预测。但扔一千次，正面大约占一半——这个「大约一半」就是概率。写成 P(正面)=0.5，这句话跟这一次会翻出哪一面无关，它说的是重复很多次之后，正面出现的比例会落在哪。概率永远落在 0 到 1 之间：0 表示这件事从没发生过，1 表示每次都发生。如果一件事只有两种互斥又穷尽的结果——不是正面就是反面，没有第三种——两种结果的概率加起来正好是 1。这条看起来理所当然的算术，第1章会让你亲眼看着它失效。

「分类」这个词，到底在说哪种任务

给一段文字挑标签、给一封邮件选部门、判断一条评论是好评还是差评——这些都是分类：输入可以是任意的，但输出必须从一个提前列好的、有限的集合里选一个。这和「写一首诗」「总结一段话」不是同一类任务：诗和摘要的输出可以是无穷多种不同的句子，没有一张预先列好的合法答案清单。分类任务的输出空间是封闭的，这一点会在第2、3章反复出现——它正是后面那个「只回答类型化问题」的模型能够成立的前提。

点一下「发送」之后，网络那头发生了什么

你的代码把一段文字和几个问题打包成一份请求，发到一个固定的网址——这个网址叫端点——后面跟着一段用来证明「这是你在发请求」的密钥。服务器收到之后处理，把结果打包成另一份文字发回来，这一来一回就是一次 API 请求。本站后面反复出现的就是这样一次请求：发到 api.typesafe.ai/v1/systemone，带着一段客户留言和几个问题；服务器几百毫秒后回一份写着判断结果的响应。你不需要知道服务器内部在算什么，只需要认得请求长什么样、响应长什么样。

大括号和方括号里装的都是什么

JSON 是一种用文字表示结构化数据的写法：大括号 {} 装一组「键: 值」，键必须是带引号的文字，值可以是文字、数字、真假、空值，也可以是另一层大括号或者方括号 []（一串并列的值）。比如 {"noul": 0.999} 这一段，键是 noul，值是数字 0.999；["billing","technical","sales"] 是一串三个文字。键值之间的冒号、成员之间的逗号一个都不能少——这也是本站后面判断「一次请求写对了没有」最基本的一道检查。

「快了 60%」和「快了 60 个百分点」是一回事吗

百分比是把一个比例乘以 100、后面跟一个百分号。百分点是两个百分比直接相减的差：正确率从 60% 提到 65%，这是「提高了 5 个百分点」；但如果按相对提升算，(65−60)/60 约等于 8.3%，这是「提高了约 8.3%」——同一组数字，两种说法说的不是同一件事。倍数是两个量相除，「A 是 B 的 3 倍」意味着 A=3B，而且倍数永远需要一个明确的参照对象：不说清楚是「比谁快」，「快了 3 倍」这句话就没有意义。这三个词本站后面几乎每一章都会用到，混着用会直接算错。

一场有输有赢的赌局，「平均下来」该怎么算

一个赌局：抛一枚硬币，正面赢 10 元，反面输 6 元。你没法预测下一次是正面还是反面，但可以算出「平均下来每玩一次」的结果：把每种结果乘以它出现的概率，再加起来，0.5×10+0.5×(−6)=2，平均每玩一次赚 2 元。这个数叫期望值，写成 E(X)=p₁x₁+p₂x₂+…，算的是重复很多次之后，总收益除以次数会落在哪，不针对某一次的结果——后面第8章判断「要不要多花一次钱去问更贵的模型」，用的就是这套算法。

四门课的总评，是「一门一票」还是「按学分算」

等权平均是把几项数字直接加起来除以项数，每一项同等重要。加权平均是给每一项配一个权重——比如学分、样本量——按权重折算之后再加总，权重大的项对结果的影响也大。同一组数字，两种算法能给出完全不同的答案。本站后面会出现一个由四项能力合成的「总分」，那四项不管各自内容多寡，在总分里都各占四分之一，用的是等权平均而不是按各项规模折算的加权平均——这不是唯一合理的算法，只是其中一种，第11章会回来细看这个选择本身会带来什么后果。

为什么有的图，格子之间是「乘」不是「加」

如果几个数据点从 0.0001 一路跨到 1，放在一条普通的直线坐标轴上，前面那几个会全部挤在贴着 0 的地方，肉眼分不出 0.0001 和 0.001 差了 10 倍。对数坐标把「乘以 10」变成「往右挪固定的一格」：不管你在标尺的哪个位置，挪同样的距离代表的都是同样的倍数，这样跨越好几个数量级的数据才能同时看清楚。代价是加法在这种坐标上不再直观——两个点之间的距离说的是它们相差几倍，不是相差多少。

模型公司嘴里的「token」，按什么收费

token 是模型处理文字的基本单位，不完全等于一个字或一个词，中英文的切法也不一样，大致是几个字符换一个 token。本站后面反复出现的 Jev，定价是每百万输入 token 0.042 美元，输出不计费。官方给过一次真实请求的用量：输入 312 个 token、输出 48 个。按输入单价算，这次输入大约花掉 0.042÷1,000,000×312，约 0.0000131 美元，不到千分之一美分；而那 48 个输出 token，不管用了多少个，都不算进账单。

第1章 一个卖家自己写下的 1.19

把两个数字念出来：0.72，加 0.47，等于 1.19——这不是哪个博主拿放大镜挑出来的错处，是卖家自己写在文档里、给自己家模型列毛病的那一页上的原话。

这一章要给审计仪装上第一个部件：一个能读进一组「命题→概率」、报出哪些组合违反了概率公理的检查器。之前什么都没有，是因为在此之前我们连一个真实模型自己写下的违规案例都没见过。

两个「是不是」的问题，答案能加成 1.19 吗

最省事的解释是模型算错了——两个本该互补的数字，加起来却超出了 1，这不就是加法出了故障吗？这个解释在这里站不住。官方给出的说明里没有「抱歉，这是个 bug」这类致歉，说明的核心是指出这两次问法问的根本不是同一件事。Choice 是相对的：在几个选项之间分配一份总概率，几个数字生来就被同一次归一化捆在一起，加起来必须是 1。Noul 是绝对的：每次只回答一个孤立的是非题，给出的是这句陈述单独成立的可能性，没有任何机制要求它记得自己刚问过的另一句话。「顾客在要求退款」和「顾客不在要求退款」是两次分开发出的请求，背后各自跑了一次独立的推断，没有人告诉后一次推断，前一次给出的答案是多少。

把 1.19 除回 1，问题就消失了吗

归一化要成立，需要一个前提：这两个数字原本就该来自同一个概率分布，只是被除法之外的什么原因搞乱了比例。可这个前提从没被检验过。「顾客在要求退款」和「顾客不在要求退款」是两次分开发出的请求，背后是两次独立的推断过程——没有任何机制保证这两次推断用的是同一套内部信念，更没有人在发请求之前替它们规定「你们俩合起来必须穷尽全部可能」。除以 1.19 确实能让两个数字重新加起来等于 1，这只是数学上抹平了那道 0.19 的缝，不能反过来证明「互斥又穷尽」这个前提本来就成立。

一条断言，该往哪个档位放

0.72 加 0.47 等于 1.19 这件事，你之所以能一路跟到这里还站得住脚，原因是它符合几个具体条件：有原始工单文本，有确切数字，官方自己的解释可以复核，发表在专门列自己毛病的页面上，不是挂在营销页面上——单靠「来自官方」这个身份，撑不起这份可信。把这几条拆开，就是本站接下来十八章都在用的一套打分办法。

证据分级Evidence Grading：同一句「Jev 很准」或者「Jev 有缺陷」，出自不同地方，可信度天差地别——证据分级就是先问这句话是谁说的、怎么测出来的，再决定要不要信，以及信到什么程度。

还有第六种情况要单独处理：到今天为止一条数据都没有的断言，写「查不到」，不用先验去补——第17章会专门回来清点这份清单。

出声示范一遍怎么用这张表：「0.72 加 0.47 等于 1.19」这条，出自官方自己列自己毛病的那个页面，带着工单原文和确切数字，还能用本节学到的算术复核——这是「一手·官方自承的局限」，语气可以最硬。「官网首页写着比 sonnet 5 快 193.6 倍」呢？这条也来自官方，但它出现在推广页面而不是自曝局限的页面上，厂商自己承认过这类数字大概率偏向了更好看的那一端——同一个「一手·官方」的门槛，却只能当产品事实用，不能直接当性能证据用。两条都来自 TypeSafe，可信的分量却不一样，差别不在是不是官方说的，而在官方说这句话时，有没有动机把它说得比实际更好看。

接下来这十九级台阶，先走哪一段

这一章立住脚的，是「校准」这个词第一次被认真拆开——一个概率数字什么时候可信、什么时候不可信，取决于它有没有共享同一个归一化的来源。后面十八级台阶里，「校准」还会被反复搬出来：第4到第9章连续六章围着它转，第10、11、16章会再回来对照它。下面这张图标出了每一章分别用到第0、1章里哪一条道理——箭头指向「用到了」，不是「要等讲完才能碰」。

第2章 为什么会有一个不肯说话的模型

一万封邮件堆在队列里，每一封都要决定转给 billing、technical 还是 sales——你手上只有一个会聊天的大模型，没有别的。

这一章要给审计仪加上一份决策请求的数据结构——判断的对象、判断的类型、可能的答案范围、一个可以核对的概率，缺一样都装不下三种真实的问法。之前没有这份结构，是因为在四堵墙撞完之前，我们都不知道一个「合格的决策请求」必须包含哪几样东西。

让它回「billing / technical / sales」，它会乖乖照做吗

从「回一个词」到「回一句解释」，中间隔着的不是模型犯错，是它本来的训练目标——聊天模型的整套调教，奖励的是那些读起来像一个人在回答问题的输出，不是只吐出枚举值的接口。可以在解析这一侧想办法补救：找关键词、掐头去尾、写一堆正则表达式去应付「账务部门」「billing team」「这属于 billing」这些不同的措辞。这些办法能把一万封邮件里的大多数处理掉，但只要模型某一次把话说得更绕一点，正则就会漏判，而且没法穷举模型可能说出的所有句式。

解析层parsing layer：在模型的自然语言输出和代码之间，专门负责「从一句话里摘出想要的那个词」的那一层——它的规则永远追不上模型能说出的句式变化。

那就明说要 JSON，这总该行了吗

格式坏掉可能是缺一个右括号，可能是在 JSON 前后又加了一句「好的，这是结果：」，也可能是字符串的引号写漏了。代码这边要么加一层容错重新解析，要么整条请求作废重发。第三方托管平台 OpenRouter 测过一批模型在结构化输出上的错误率——这张表测的是「格式有没有输出对」，不是「判断有没有做对」，官方自己也说这组数字不是精确测出来的，只是拿来对比用。

这张表和后面第11章那张评测总分表，测的不是同一批任务、也不是同一组模型——这里比的是「输出格式有没有坏」，那里比的是「判断做没做对」，两张表不能挪到一起排名次。

把非法 token 的概率直接摁死，不就能保证格式了吗

已经有人把这个思路做到底了：直接读取模型对每个候选答案打出的原始概率，完全跳过「一个字一个字生成」这一步，比只锁定几个候选词又往前走了一截。社区一个开源复刻项目在一块普通显卡上做了对照实验，用的是同一个冻结的开源小模型，21 个二元判据。

这个项目的作者自己写得很清楚：这套东西复刻的是接口形状，不是某个没公开的模型和训练过程本身。这句自我限定正说到了约束解码这堵墙的核心：格式合法是一件事，这次判断该不该信是另一件事。有厂商在描述自家的类型化模型时，也把这两件事分得很开——能保证答案的形状，不能保证每一次判断都是对的：给的是一份类别清单，它编不出清单之外的类别，但它可以选错那一个。反过来说也成立：一个被采样器摁着只能吐三个候选词之一的普通聊天模型，挡住了它把概率分给不合法 token 的路，却没有改变它做判断这件事本身——它心里到底有多确定该选哪一个，采样器管不着，也看不见。

让它自己说「我有多确信」，能顶替校准概率吗

这句话拆开看有两层。第一层，生成出来的数字没有任何机制保证它和模型内部的不确定性对得上——模型可能对两个答案其实半信半疑，却因为「听起来要给个高分」这种语言习惯，报出 95%。第二层，即便这个数字某种程度上真的反映了模型的倾向，也没法验证它：要验证「90% 的置信度」是不是真的对应「十次里对九次」，需要收集大量这种数字和最终对错的配对，再统计着看——这正是第4、5章要做的事。自评的置信度绕开了这整套验证，直接把一个没人核对过的数字塞给了下游代码。

这类模型为什么被叫做「系统一」

System One 这个名字借用的是心理学里「系统一 / 系统二」这对说法：系统一是那种不假思索、几乎瞬间完成的直觉判断；系统二是那种需要坐下来一步步推理的慢思考。TypeSafe 把自己的模型定位成前者——快、面向有限的判断，而不是需要层层推理的复杂任务。官方在自家列出的「毛病清单」里，把「需要更多层间接推理」的任务直接叫做 System Two tasks，并建议这类任务换别的工具做。

RLCDReinforcement Learning for Calibrated Decisions：面向校准决策的强化学习，官方给这套训练方法起的名字。官方把它和 RLHF（人类反馈强化学习）、RLVR（可验证奖励强化学习）并排放在一起，称作继前两条路之后的「第三条路」。

第3章 三种问法：Noul、Choice、Score

把一句话发给 Jev，让它判断该转给客服里的哪个组、客户有多生气、这事儿急不急——服务器会用三种完全不同形状的答案回你：一个数、一个选项加一串概率、外加一个不上不下的小数。

这一章要给审计仪加上一层解析器：能看懂 Jev 吐回来的三种不同形状的答案，并且在拿去做进一步计算之前，先检查它们有没有违反自己该守的规矩。前两层只管把请求发出去，这一层开始真正读懂返回来的东西。

一次请求，到底要交代清楚哪三样东西？

第0章说过，一次 API 请求说到底就是你的代码往服务器发一段文字，服务器回一段文字。Jev 这一段文字的格式定得很死：地址只有一个，POST https://api.typesafe.ai/v1/systemone，请求头里带一行 Authorization: Bearer <你的密钥>。这不是那套被大半个行业抄成事实标准的 OpenAI 兼容格式，是 TypeSafe 自己另起的一套，字段名、结构都不一样。

请求体是一段 JSON，最顶层只有三个字段，三个全部必填。state 是要拿去评估的内容，可以是一段文字、一个 JSON 对象，也可以是一个数组，但只接受文本——图片、音频、视频都不支持。model 就是模型名，比如 jev-latest。questions 是一张 map，你想问几个问题，就往里面塞几条，每条问题自己起一个 key，答案回来的时候用同一个 key 对号入座。

这个 key 你想叫什么都行——department、q1、随便什么字符串，效果不会有任何差别。官方文档写得很直接：这个 key 不会被发送给底层模型，也不参与推理。它唯一的作用，是让你在收到答案之后，能对着同一个名字把问题和答案配对起来。真正决定模型会怎么想的，是这道题自己的 instructions 和 criteria，跟你给它取的名字没有任何关系——哪怕你把一道问「客户是不是很着急」的题，key 故意写成 department，模型给出的判断也不会因此往「部门」那个方向偏一分。

官方文档的 quickstart 给了一个完整例子——一条客服工单，一次问了三件事：该转给哪个部门、客户有多生气、这事儿急不急。三种问法在这一个请求里全用上了，这一节先看请求整体的骨架，每道题具体怎么写、答案怎么读，留到后面三节里各自展开。

{
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
  "model": "jev-latest",
  "questions": {
    "department": { "type": "choice", … },
    "frustration": { "type": "score", … },
    "is_urgent": { "type": "noul", … }
  }
}

服务器回来的响应，三个答案用同样的三个 key 对号入座：

{
  "model": "jev-latest",
  "answers": {
    "department": { "type": "choice", … },
    "frustration": { "type": "score", … },
    "is_urgent": { "type": "noul", … }
  },
  "usage": {"input_tokens": 312, "output_tokens": 48}
}

department 用的是 Choice，frustration 用的是 Score，is_urgent 用的是 Noul——接下来三节，一节说清一种，每一节都会把这道题完整的问法和答案摊开来看。

只答是非的问法，返回的那个数到底是什么？

刚才那道 is_urgent 题，完整的问法和答案是这样的：

"is_urgent": { "type": "noul", "instructions": "The message conveys urgency or time-sensitivity" }
// 答: {"type": "noul", "noul": 0.999}

Noul：只问一件事是不是成立，返回一个 0 到 1 之间的数，这个数就是「答案为 yes 的概率」。

必填字段只有一个：instructions，也就是要判断的那件事。criteria 是可选的，如果给，只能有 true 和 false 两个 key，分别说明「答案接近 1 是什么意思」「答案接近 0 是什么意思」。返回的答案里，Noul 没有 confidence 字段——官方文档专门开了一节说明这件事，标题就是「Noul 不返回单独的 confidence 值」。Choice 和 Score 都有 confidence，Noul 没有，这不是遗漏，是这个问法本身的设计。

Noul 的问题不一定要写成疑问句，也可以写成一句陈述句让模型判断真假——比如把「客户是不是在要求退款」写成「the customer is requesting a refund」，如果这事基本确定，返回值就该接近 1。官方原文建议两种写法都在自己的数据上试一试，看哪种效果更好。

要从一堆选项里挑一个，答案该长什么样？

department 那道题用的是 Choice。

Choice：从一组选项里挑出最可能的一个，返回每个选项各自的概率，以及概率最高的那一个。

criteria 是必填字段，是一张「选项 → 描述」的 map，描述可以写 null。选项本身就是这张 map 的 key——不用另外再传一份选项列表，criteria 里写了哪些 key，选项就是哪些。一道 Choice 题最多能放 255 个选项，多传一个选项，多花几个 token 而已。

返回的 probabilities 把每个选项都映射到一个概率，这些数加起来等于 1——这跟 Noul 完全不同，Noul 里 yes 和 no 的概率不保证加起来是 1（后面第1章会专门讲这件事）。

选出 choice 字段的那个值，就是 probabilities 里概率最高的那一个，官方原文叫它「最高概率的选项」。Choice 还带一个 confidence 字段，是从 probabilities 这一整组数字里算出来的一个统计量，不是概率本身。department 那道题完整的问法和答案是这样的：

"department": { "type": "choice", "criteria": {"billing": …, "technical": …, "sales": …} }
// 答: {"choice": "billing", "probabilities": {"billing": 0.84, "technical": 0.159, "sales": 0.001}, "confidence": 0.596}

billing 的概率 0.84、technical 的 0.159、sales 的 0.001，加起来正好是 1；choice 选的是 billing，跟最高概率对上了。但是 confidence 只有 0.596，跟 0.84 差了一大截。

给程度打分，为什么答案会落在两级之间：Score

criteria 是必填字段，是一个有序的等级描述数组，至少 2 个、最多 10 个。没有另外的 min/max 或者步长参数——等级号就是数组下标，从 0 开始数，数组的顺序本身就是等级从低到高的编号。

返回的 score 是等级号的概率加权均值，可以落在两级之间。这正是第0章讲过的期望值：把每一种可能的结果，按它出现的概率加权平均。frustration 这次没有把 probabilities 打印在响应里，但道理是一样的：假如三个等级的概率分布是 {0: 0.165, 1: 0.635, 2: 0.2}，加权平均就是 0×0.165 + 1×0.635 + 2×0.2 = 0.635 + 0.4 = 1.035——跟响应里给出的 1.035 对得上。这只是一种举例说明的假设分布，不是响应里没写出来的真实数字；那次响应真实给出的 confidence 是 0.842，不算低，跟「概率比较集中」这个方向大致吻合，但仍然不能只凭 1.035 和 0.842 这两个数精确还原出三个等级各自的概率。正因为像这样的分布不止一种能凑出同一个 1.035，官方才会提醒你：score 落在两级之间，本身就是一种信息损失，probabilities 和 confidence 要一起看，才能把预测门里那两种截然不同的情况分开。

criteria 该怎么写，官方给了一条很明确的建议：不要用纯数字当等级描述。原因是每个等级都是分开评估的，模型看不到某个等级的编号，也看不到相邻等级长什么样，「比上一级差」这种话对它没有意义，criteria 里出现的数字本身也帮不上忙。

一次请求最多能塞几个问题？

官方原文说得很明确：一次请求里 question 的数量没有固定上限，只受这次请求的 token 预算约束，state 和全部 questions 共用同一份预算。官方还鼓励一次多问：增加问题几乎不会让响应变慢，多问一个用不上的问题，成本也低到几乎可以忽略。这份预算具体是多少 token，官方不同页面给出的口径并不完全一致，这是第13章要专门拆开讲的一堵墙；这一章先只需要记住，约束的单位是 token 预算，不是问题的条数。

confidence 是怎么算出来的？

Jev 的响应里没有 logprobs——官方文档、API 参考、机器可读的 JSON Schema 里都没有这个字段。confidence 的具体计算公式官方没有公开，只说它是「从概率分布算出来的一个统计量」，并且承诺以后会单独出一篇 cookbook 讲不同算法各自的取舍，但同时也提醒：你并不是被锁死在官方的定义里，因为响应里已经给了完整的 probabilities，你完全可以自己定义一套衡量方式。

该写 jev-latest，还是写死版本号？

当前版本是 jev-1.13.0，jev-latest 和 jev-preview 这两个别名现在都指向它。同时还存在更早的 jev-1.12，官方 cookbook 里有一部分数字就是用 1.12 跑出来的。官方建议生产环境写死具体的版本号，而不是用会漂移的别名——因为别名指向的模型换了之后，你之前针对某个版本调好的置信阈值，会跟着一起失效，而你的代码不会报任何错误提醒你这件事发生了。

第4章 说 70% 下雨的那个人，怎么算准

天气预报说今天 70% 的概率会下雨，你出门要不要带伞——伞带了，结果一整天大太阳；伞没带，结果傍晚淋成落汤鸡。不管哪一种，你多半都在心里骂了一句这预报员没测准。

这一章要给审计仪加上一个最基础的部件：一个能把大量「模型给出的概率，后来到底发生没发生」这样的记录，按预测概率分组装进桶里的工具。前三层都在处理单次请求怎么发、答案长什么样，没有一层碰过「这些概率到底准不准」这个问题——因为回答它，需要的不是一次请求，是一大批。

70% 说下雨，结果没下，这就算他错了吗？

先认真试第一种标准：只要说了「会下雨」结果没下，就算预报员错了。这个标准看着很自然，可是往下推一步——按这个标准，预报员要想「永远不错」，就只能说 0% 或者 100%，因为只要说了任何中间的数字，比如 70%，只要那天恰好没下雨，这次判断就被记成一次错。可现实里的天气预报天天在说 37%、62%、81% 这种数字，没有一个预报员只说 0% 和 100%。这不是预报员偷懒，是因为天气这件事本身就没法被压缩成「一定下」或者「一定不下」两种答案——如果「没应验就算错」是唯一的判断标准，那所有说中间数字的预报员，都注定会被判成「经常错」，跟他们判断得准不准，其实没什么关系。

多少天里下了多少次，才算他说对了？

把「只看单次结果」换成「看整组」之后，标准就清楚了：校准(calibration)指的是，在所有模型给出某个概率的预测里，真正发生的比例接近那个概率。官方原文对这件事描述得很具体：在一个校准良好的模型给出的大量预测里，被标为 0.2 的那些，应该在大约 20% 的时候应验；标为 0.8 的，应该大约 80% 的时候应验；标为 1.0 的，应该 100% 应验。

官方紧接着补了一句很关键的话：这些比例说的是一组预测的整体情况，不保证任何单次答案是对的。这句话同时是这套卖点的说明书和它的边界——它说明「校准」这件事确实是有严格定义、能被检验的，不是一句空洞的营销话；但它也划了一条界线：不管模型校准得多好，你都不能拿着某一次的输出去问「这次对不对」，校准从来没承诺过这个。一位独立开发者把 Jev 用在电商的商品匹配审核上之后，写下过一句很直白的话：五十条人工复核，根本测不出 0.85 是不是真的对应 85%——他的意思是，人工能核对的样本太小，压根构不成「一组」，校准这件事根本没法在那个规模上被验证。

一个从不出错的预报员，是不是就有用？

这个例子揭示了一件容易被忽略的事：校准好，不等于预报有用。校准只衡量「说出来的概率和实际发生的比例对不对得上」，完全不管这个概率是不是「区分」出了哪天更可能下雨、哪天不太可能——一个从不做任何区分、每天嘴里蹦出同一个数字的预报员，只要那个数字恰好等于当地的平均下雨比例，就能拿到满分的校准成绩。

第5章 把校准画出来：可靠性图与 ECE

上一章最后，你已经能把一堆（概率，结果）按概率分好桶了。桶排好之后，摆在你面前的是一张表——不是一个词、不是一句「校准得不错」，是很多行数字。

这一章要给审计仪加上真正能出数的两个部件：ECE 和 Brier 计算器。上一章的分桶工具只是把数据归了堆，这一章要把每一堆变成一个能拿去比较、拿去质疑的数字——而这两个数字，官方自己在最核心的卖点上一个都没给过，这一章会亲眼去确认这件事。

怎么才能看出一整批预测靠不靠谱？

这张图叫可靠性图(reliability diagram)：横轴是各桶的平均预测概率，纵轴是各桶的实测频率，每个桶画一个点，旁边通常再画一条 y=x 的参考线。

怎么把这张图变成一个数？

把这个想法写成公式，就是期望校准误差(Expected Calibration Error, ECE)：对每个桶，算出「实测频率」和「平均预测概率」的差，取绝对值，再按这个桶占全部样本的比例加权，最后把所有桶加起来。

把「按占比加权平均」换成「只取最大值」，就是另一个相关的数：MCE = max_b |p̄_b − ō_b|——预测门里那个「只看偏差最大的桶」的想法，就是最大校准误差(Maximum Calibration Error, MCE)。

为什么 Brier 分数要同时惩罚两种错？

Brier 分数(Brier score)：把每一条预测概率和实际结果之差取平方，再对所有预测求平均。

如果一个模型永远只敢说 0.5，不管真实结果是 1 还是 0，Brier 分数都是 (0.5−1)²=0.25 或者 (0.5−0)²=0.25，永远是 0.25——比自信且说对的 0.0025 差得多，也比自信且说错的 0.9025 好得多。这就是 Brier「惩罚不准」和「惩罚不诚实」这两件事同时发生的地方：说得越极端、赌得越大，对的时候赢得越多，错的时候也输得越惨；永远含糊其辞地说 0.5，永远稳定地拿一个中等偏差的分数，赢不了大的，也输不了惨的。

桶开多细，这个数就多可信？

桶数的选择本身是一个容易被忽略的陷阱。桶越多，每一桶摊到的样本就越少；样本越少，这一桶算出来的实测频率就越不稳。想象一个桶只有 3 个样本，其中 1 个命中，这一桶的实测频率就是 33.3%——只要换一个样本的结果，它立刻跳到 0% 或者 66.7%。单单一个样本，就能让整桶的读数跳动 27 个百分点以上。把桶数从 10 个增加到 100 个，平均每桶的样本量从 N/10 降到 N/100，这种跳动只会更剧烈，不会更精确。

这跟「桶数越多，看起来分辨率越高」这种直觉正好相反：分辨率确实变高了，但每一格读数的可信度，是拿稳定性换来的分辨率，不是白得的。这一条会在后面用统计工具处理样本量够不够的问题时，重新变得重要——一张校准表如果没有说清楚每一桶有多少样本，这张表本身就不完整。

把一个模型的把握往两端推一把，会发生什么？

用第4章末尾那批数据验证一下：原始数据是 (p=0.9,y=1)、(p=0.9,y=1)、(p=0.9,y=0)、(p=0.6,y=1)、(p=0.6,y=0)、(p=0.6,y=0)，算出的 ECE 是 0.25（第5-2节算过）。把 0.9 推到 0.97、把 0.6 推到 0.75，阈值判断的对错完全不变——0.97 和 0.6 都还在 0.5 的同一侧，谁被判为「预测发生」谁没变，accuracy 原封不动。但重新算 ECE：桶「0.97」实测频率还是 2/3，偏差从 0.233 变成 |0.97−0.667|=0.303；桶「0.75」实测频率还是 1/3，偏差从 0.267 变成 |0.75−0.333|=0.417。新 ECE = 0.5×0.303+0.5×0.417=0.36，比原来的 0.25 明显更差——accuracy 一个百分点没变，ECE 却肉眼可见地变差了。

Jev 的校准分数，和谁比？

第三方评测 zhuyansen/jev-zeroshot-vs-bert 在 7 个数据集上测过 Jev 的 ECE，固定 held-out 集合，bootstrap 95% 置信区间，还做了污染对照，自费完成，是这份材料里证据等级最高的一档。

不能从这张表里读出「答案空间越大，校准就越差」。能读出来的只有一句：Banking77 这 77 类，是 Jev 校准明显最差、也是唯一明显输给基线的一处，0.208 对基线的 0.081，差了一大截，而这恰好是「255 选项上限」最有诱惑力去使用的场景——选项越多，好像越能一次问完，但这张表说明选项多到 77 个的时候，Jev 自己的校准已经在这批测试里明显失守。还有一点要一起说清：官方在 Banking77 上走的是两步层级分类（先分大类，再在大类内部细分），跟这里其他模型一次性打完 77 类的做法不是同一套流程，两者不能直接比较。

这个卖点，官方给了几个数？

官方文档站提供一份全量文本转储，把所有页面拼在一起，大小 874KB，可以像一份普通文本文件那样直接检索。在这份转储里搜索 ECE、expected calibration error、Brier、reliability diagram、calibration curve 这几个词，命中次数全部是 0。搜索词根 calibrat*（涵盖 calibration、calibrated、well-calibrated 这些变形），命中 25 次——但摊开这 25 次逐条看，没有一次带着数字或者图表，全部是「calibrated decisions」「calibrated probabilities」这类定性说法。

这一章从头到尾算的这一切——ECE、MCE、Brier——都不是在复述官方给出的某个数字，是在补一个官方选择不给的数字。「校准」是这个模型最核心的卖点之一，而在这 874KB 的官方文档里，恰恰是这一处，一个可验证的数值指标都没有出现过。

第6章 一个分数拆成三笔账

上一章教会你打一种分：把一个模型说过的每一句「我有百分之多少把握」，和后来到底对没对，放在一起，画成一条线，再压成一个叫 Brier 分数的数字。可是上一章结尾留了一个别扭的例子——一个不管遇到什么都回答「50%」的预报员，那条线会紧贴对角线，堪称完美。一个数字，能不能既说出他有多老实，又说出他到底有没有用？

这一级要给审计仪加一个部件：Brier 分解器。前五级台阶只能告诉你一个模型校不校准、Brier 分数是多少，却分不清一个差分数背后，到底是校准没做好，还是压根没有分辨能力——这一级把这两件事拆成两个可以分别读的数。

一个永远说50%的人，考出的分数说明了什么

第5章给的 Brier 分数定义是这样的：把每一条预测概率 p_i 和它对应的实际结果 o_i（下雨记1，不下雨记0）相减、平方，再对所有条目取平均。

这个数字把「说得准不准」压成了一个数，压缩得很干净，但也压得太狠——它没法回答「这个预报员到底是老实但懒，还是既老实又肯下功夫分辨天气」这个问题。要回答这个问题，得先把预测按数值分桶：所有说「80%」的日子归一桶，所有说「30%」的日子归另一桶，跟第5章画可靠性图时是同一个动作。桶里除了平均预测概率，还有一个数值得记下来：这一桶里，真的发生的比例有多少，我们把它叫作这一桶的实测频率。

为什么可靠度和分辨度必须分开算

能让「校准」和「有用」拉开差距的那个数字，气象学家 Allan Murphy 在1973年给出过一个拆法，往下把每一项单独列出来。先看可靠度：它衡量的是，每一桶自己报的平均概率，和这一桶真实发生的频率，差了多少——差得越多，说明这个模型越不老实，可靠度就该越大，所以要用平方、加权平均起来。

可靠度只关心「说的」和「真的」对不对得上，完全不关心这个模型有没有把不同情况区分开。真正衡量「有没有分辨」的是另一项，分辨度：它看的是每一桶的真实频率 f_k，比起「不管哪一桶，整体上事情发生的比例」，也就是基础率，拉开了多少距离。桶与桶之间的真实频率越不一样，说明模型确实把不同的情况分开了，这个词前面要减去，因为分辨度是越大越好——分得越开，Brier 分数应该越小。

最后一项不确定度，跟模型无关，纯粹是这件事本身有多难猜：如果历年正好一半天下雨一半天不下雨，基础率是0.5，随便猜的难度最大；如果一年到头几乎从不下雨，基础率接近0，随便说「不下雨」都很容易对，不确定度就接近0。

三项拼起来，就是Murphy 分解(Murphy decomposition)：

拿一组具体的数字验证一遍，比记住推导过程更踏实。假设有10天的历史记录：预报员甲在5天里说「80%会下雨」，其中3天真的下了雨；另外5天说「30%会下雨」，其中2天真的下了雨。10天里一共下了5天雨，基础率 b=0.5。

先按式 6-2 到式 6-4 分别算三项：可靠度 = [5×(0.8−0.6)²+5×(0.3−0.4)²]/10 = [5×0.04+5×0.01]/10 = 0.25/10 = 0.025。分辨度 = [5×(0.6−0.5)²+5×(0.4−0.5)²]/10 = [5×0.01+5×0.01]/10 = 0.1/10 = 0.01。不确定度 = 0.5×0.5 = 0.25。三项按式 6-5 拼起来：0.025 − 0.01 + 0.25 = 0.265。

两条完全不同的路径，走到同一个数字——式 6-5 这道等式不是巧合，是代数上必然成立的结果，也是上面那道题里免费判据的来源。

这正是这一章要说的话：分辨度是正数，不代表总账就赢。一个既不闹笑话、又真的分辨出了不同情况的模型，才能稳赢什么都不判断的对手；只做到其中一半，账目可能还是负的。

回到那个永远说50%的人：他在这张账单上占了哪一格

把这件事情说清楚，要先把「永远给出同一个概率」这件事一般化。假设某个模型不管遇到什么情况，永远只报一个固定的数 q。因为他只有一个桶，这个桶装下了全部数据，所以这一桶的实测频率必然就是整体的基础率 b——没有第二个桶可以和它比较，分辨度的定义里 f_k−b 对这唯一的桶来说恒等于0。分辨度这时被数学上直接锁死为0，不管这个模型选择永远报哪个数字都一样，不只是数值偏小这么温和。

可靠度就不一定是0了：可靠度=(q−b)²，只有当 q 恰好等于基础率 b 时，可靠度才会归零。BRIEF 里第5章那个例子选的是「历年下雨概率本来就接近50%」的场景，所以喊50%恰好撞上了 b=0.5，可靠度也归零，Brier 分数干干净净地等于不确定度。换一批基础率不是0.5的数据，同样是什么都不判断，运气就不一定这么好了。

第7章 放过一个坏人和冤枉一个好人，哪个贵

模型告诉你，这封邮件是垃圾邮件的概率是0.6。删，还是不删？多数人脑子里会立刻冒出一条规则：超过一半的把握就删。可是同样这个0.6，如果问的是「这封邮件里有没有诈骗链接，要不要直接拦截、连人都不让看」，你还敢用同一条规则吗？

这一级要给审计仪加一个旋钮：最优阈值求解器。前六级的可靠性图、ECE、Brier 分解，都假设你手上已经有一批（概率，结果）可以拿来打分；但真正拿概率去做决策时，0.5这个默认的切点从哪来，没人交代过。这一级把切点变成一个能按代价算出来的数，不再是随手定的常数。

超过一半的把握就该动手吗

先看最省事的做法：概率过半就删，不过半就留。这条规则的名字叫0.5阈值，几乎是每个人第一次面对一个概率时的本能反应。它有没有道理？有——如果把它理解成「更可能是垃圾邮件就按垃圾邮件处理」，这话听起来无可辩驳。

但这条规则悄悄假设了一件事：删错一封重要邮件的代价，和漏删一封垃圾邮件的代价，是同一个数量级。真实世界里几乎从不是这样。误删一封来自客户的邮件，可能让你错过一笔生意；漏掉一封垃圾邮件，无非是多看一眼、随手删掉。两种错误的代价可以相差十倍、百倍，0.5这个数字里完全没有体现这个差距——它把「谁更可能」和「该不该动手」画上了等号，可这是两件事。

切点该定在哪，才不是拍脑袋

要把切点从直觉变成算出来的数，先要把「删错了」和「该删却没删」这两种代价分别起个名字。把「不该动却动了」的代价记作 C_FP——删了一封其实不是垃圾邮件的邮件。把「该动却没动」的代价记作 C_FN——放过了一封其实是垃圾邮件的邮件。

把这个切点记作 τ*（读作「陶」，星号表示它是这个问题下最好的那一个）：

概率 p 超过 τ* 就动手，这样选出来的期望损失，不会比任何其他切点选出来的更高——这正是式 7-1 被称作「最优」的原因：不是凭经验选出来的好切点，是能证明不存在更优切点的那一个。

这一步确实反直觉：常识会觉得「越常见的东西，越该被当真」，可式 7-1 完全没有给基础率留位置。原因在于，基础率的影响已经在别的地方起作用了——如果垃圾邮件真的很常见，一个诚实的模型本身就该更频繁地给出高概率，把这批邮件的 p 值普遍推高，而不是让你去手动调低判断的切点来迁就它。切点只负责回答「给定这一条的概率，值不值得为它承担动手的风险」，这个问题的答案永远只取决于两种错误各自有多疼，和这一类事情本身有多常见，是两条互不干扰的信息。

Jev 为什么把概率交还给你，而不是替你拿主意

官方文档里有一句话正说的是这件事：「Uncertainty is a feature」——不确定性不是缺陷，是特性。官方原文紧接着写道，你可以用 Jev 给出的概率和置信度，自己决定软件什么时候可以自动动手、什么时候要停下来交给人看。这正是式 7-1 在真实产品里的样子：把「切点定在哪」这件事，从模型开发者手里，还给了知道自己代价结构的人。

不过这份自由是有边界的。官方在同一份文档的另一处明确提醒：不要把在 Noul 上调好的阈值，直接搬到 Choice 上用——你刚刚学会的这条 τ*，是绑定在「这封邮件是不是垃圾邮件」这一个具体问法上算出来的，换一种问法（哪怕问的是同一件事），这条线都得重新算一遍。

第8章 让贵的模型只看难的

Jev 便宜到近乎免费，每处理一个案例只要0.0004美元，0.4秒就能出答案，但那套官方一致率评测只考出67.8%。opus 5 一个案例要1.761毛美元，接近40秒，但能考到73.1%。两个放在你面前，你会怎么选？

这一级要给审计仪加一台机器：级联路由器。用第7章那条阈值当开关，把便宜模型和贵模型接成一条流水线，再算出这条流水线的准确率、成本、延迟。前七级只能评价单个模型交出来的一批答案；这一级第一次让审计仪去回答一个更接近真实工程决策的问题——两个模型一起用，划不划算。

便宜的和贵的，只能二选一吗

先把两种最省事的做法认真走一遍。全用 Jev：十万个案例，花40美元，用时11个小时，答对大约67800个。全用 opus 5：十万个案例，花17610美元，用时超过437个小时（相当于18天），答对大约73100个。多答对的那5300个案例，代价是多花17570美元、多等18天。这笔账对不少场景来说，根本划不来。

但还有第三条路：不必在两个极端之间选，可以把它们接成一条流水线。让便宜的 Jev 先看一遍每一个案例，它自己判断得有把握的，就直接采信它的答案；判断得没把握的，再花钱交给 opus 5 重新看一遍。这条路线有一个名字，叫级联(cascade)——像瀑布分层跌落一样，案例先经过便宜的第一层，只有一部分会继续往下跌到昂贵的第二层。

级联能不能真的划算，取决于一件事：Jev 自己的「有没有把握」，靠不靠谱。如果 Jev 说有把握的时候真的大概率是对的，那级联就能用很低的成本留住大部分准确率；如果 Jev 的「有没有把握」和它实际对不对根本不相关，级联就是在乱猜要不要多花钱，多花的钱可能一点准确率都换不回来。这条件到底是什么，正是第9章要单独拆开检验的东西——这一章先假设它成立，把这台机器的账本搭出来。

这条流水线的账，该怎么算

要给级联算账，先要有一个规则去判断「Jev 有没有把握」。这正是第7章的最优阈值 τ* 能派上用场的地方：Jev 给出的置信度只要不低于 τ，就采信它的答案；低于 τ，就升级给 opus 5。这里的 τ 不一定非得是第7章按误判代价算出来的那个 τ*，可以是任何一个你选定的门槛——不同的门槛，级联交出的答案不一样，这正是下面要推的四个量。

第一个量最直接：置信度不低于 τ 的案例，占全部案例的比例，叫覆盖率(coverage)——这部分案例完全由 Jev 独立搞定，不需要 opus 5插手。

覆盖率决定了另外三个量：级联最终答对多少、花多少钱、等多久。先看准确率：被 Jev 自己扛下来的那 c 比例，按 Jev 在这部分上的真实准确率算；剩下 1−c 升级出去的，按 opus 5 的准确率算。两部分按各自占的比例加权平均，就是级联整体的准确率。

成本和延迟的结构几乎一样，但有一个地方容易被漏算：Jev 的成本和延迟，是每一个案例都要付出的——不管这个案例最后有没有被升级，第一步永远是先让 Jev 判断一遍。所以这一项是一个和 τ 无关的常数，只有升级出去那部分，才会额外叠加 opus 5 的成本和延迟。

不用标注数据，怎么知道这部分准不准

式 8-2 里的 a_采，也就是 Jev 在被采信那部分上的真实准确率，看起来必须拿一批标好答案的数据去核对才知道。可这批标注数据往往是最贵、最难拿到的东西——如果非要标注才能用级联，这套机器在很多场景里根本落不了地。

这里正是校准这个性质，第一次在这四章里真正值钱的地方。第4、5两章教过，校准的意思是：一批预测里，说「80%」的那些，长期看真的有大约80%对了。「置信度不低于 τ」这个筛选条件，本身就是在按置信度分桶——和第5章画可靠性图、第6章算 Murphy 分解，用的是同一个动作。如果模型是校准的，这一桶自己报出来的平均置信度，就该约等于这一桶真实的准确率。

第9章 把校准去掉，级联会怎样

上一章那台级联机器算得漂亮：花小钱办大事，准确率贴近贵模型，成本只要零头。可是那整套账本，从头到尾都靠着一句没有验证过的话撑着——Jev 说自己有多大把握，就真的有多大把握对。如果这句话是假的呢？

这一级要做的不是造一个新部件，是给上一级那台级联路由器装一个开关——校准扰动器，能把置信度人为调偏，却完全不碰模型判断对错的那一部分。前八级的路由器默默假设了「置信度约等于正确率」；这一级第一次让你亲手把这个假设关掉，看着同一套公式在假设不成立时会算出什么。

怎么把一个数字调得更极端，又不让它跑出0到1

要人为调偏一批置信度，最直接的念头是给每个数乘一个系数，或者加减一个数。这条路马上会撞墙：置信度0.9，想让它变得更极端，乘1.3，算出来1.17——超过了1，不再是一个合法的概率。置信度必须老老实实待在0到1之间，直接做加减乘除，随时会把它推出这个范围。

另找的这条路分三步：先把概率换算成一个没有上下界的数，在这个没有上下界的空间里自由地缩放，缩放完再换回合法的概率。第一步要用到几率(odds)：概率 p 换算成几率是 p/(1−p)，意思是「这件事发生的把握，是不发生的把握的多少倍」。p=0.5时几率是1（五五开）；p越接近1，几率越往正无穷跑；p越接近0，几率越往0跑——几率不会跑到负数，但下界0还在，没有彻底摆脱边界。

再对几率取一次自然对数，就是对数几率(logit)，这才是彻底没有上下界的数：p 从0一路走到1，logit(p) 从负无穷一路走到正无穷；p=0.5时，logit(0.5)=ln(1)=0，正好卡在正负的分界点上。

有来路就要有回头路：把一个在负无穷到正无穷之间的数字，重新换算回0到1之间合法的概率，用的是logit的反函数，sigmoid(sigmoid function)。

调温度，模型的判断力会跟着变吗

拿同一个置信度0.70，分别喂给两种温度，能看清这个开关的两个方向。logit(0.70)≈0.847，这是缩放前唯一要先算出来的数，往下两个方向分别除以不同的 T。

换一批置信度，同一套公式会算出什么账

造一个只有10个案例的小数据集，门槛定在 τ=0.75。原始（T=1）置信度和实际判断对错如下：

T=1时，前6个案例（置信度0.75以上）达标，被 Jev 自己采信；后4个升级给大模型。案例7原始置信度0.68，没有达标，本该升级——但缩放到0.819之后，反而越过了0.75这道门槛，被错误地留了下来。而案例7恰恰是判断错误的那一条。

把这批数据接回第8章的四个公式，T=1时：覆盖率6/10=60%，被采信部分5对1错，准确率83.3%，升级的4个里opus 5接手后按其73.1%的水平判断，假设答对3个，级联整体准确率=(5+3)/10=80%。T=0.5时：覆盖率变成7/10=70%，被采信部分变成6对1错（错的正是案例7），准确率跌到71.4%，只剩3个真正升级，假设opus 5答对2个，级联整体准确率=(6+2)/10=70%。

再看校准这件事本身崩坏到什么程度：T=1时，被采信这6个案例的平均置信度是83.8%，和它们83.3%的真实准确率几乎贴合，按第5章的算法算出的差距只有0.5个百分点。T=0.5时，被采信的7个案例平均置信度飙到93.4%，但真实准确率只有71.4%——差距炸到22个百分点，是原来的四十多倍。

这10个案例是手工挑出来的最小例子，专门用来演示一个压线案例怎么被推过门槛——10个百分点这个数字是这批极小样本自己的结果，不是通用结论。这台路由器的核心和第8章是同一台，只是面板上多了一个校准开关；换成2000条模拟数据、连续拖动的阈值滑杆，才能看这件事在更大样本上是什么量级，会不会一直朝同一个方向走。

把同样的对比搬到实验室这2000条模拟数据上——不是刚才那10个手工挑的案例——差距立刻缩水了一个数量级：默认阈值τ=0.75时，T=1的级联一致率是75.616%，T=0.5是74.436%，只差1.18个百分点，没有跌到0，也不是10个百分点。把τ从0.50连续扫到0.99，这个差值本身会变号：τ在0.794附近由正转负，τ=0.871时差值最大，达到−2.76个百分点，而且这个最大值恰恰出现在符号反转之后。真正不随τ变号、稳定拉开数量级的，是路由器自认为的正确率和它实际做到的正确率之间那道差——这道差一旦被拉开，第8章那套不靠标注、直接拿置信度当 a_采 用的办法就用不成了，只能回去标注。

上面这些数字也只是沿着 τ 扫了几个点。下面这张图把门槛 τ 和校准质量摆在同一个平面上，能看到整片成本随两者变化的曲面，不只是几个孤立的读数。

发动机功率测不了，是不是就等于它不转

BRIEF 已经查过，在874KB的官方文档全量转储里搜索 ECE、Brier、reliability diagram、calibration curve 这几个词，全部零命中——「calibrated」这个词出现了25次，但没有一次带着数字。官方给了校准的定性定义，却从没有拿出任何数值化的校准指标。这台发动机的功率，买家无法用官方给的材料去验证。

但材料里同时也有另一面。拿了早期访问权限的 Good Start Labs，测出 Jev 和 Claude Fable 5.1 的一致率是91.5%；完全自费、没有厂商关系的 Near Here，在50条活动审核任务上测出 Jev 96%正确（48/50）、0.59秒，两项都好于对照模型。

这两份都提醒过一件事：算出来的成本数字是按官网标价推算的，不是真实账单；Near Here 那次测试里，Jev 的输入token数量反而是三个模型里最多的（21528对15372和15503），赢在单价低、输出免费，不是赢在用得省。

第10章 「0% 幻觉」是在说哪件事

官方发布那天挂出的图上，Jev 那一栏是一根扎眼的柱子：0%。旁边 luna、terra 是 0.58%，opus 5 是 5.73%，sonnet 5 是 13.2%，haiku 4.5 干脆到了 45.5%。一个永远不会写出非法格式的模型，会不会犯错？

这一章要给审计仪加一块双轨记分板——把「格式合不合规」和「决策对不对」拆成两条独立的记录线。前九级台阶算的可靠性图、ECE、阈值、级联，全部默认了「模型给出的是一个能被判断对错的答案」，却没有一级问过：这个答案的格式本身合法，和这个答案本身正确，是不是同一件事。

格式永远合法，等于永远不会出错吗

官方发布那天挂出的图，横轴是各家模型，纵轴是结构化输出错误率——这张表第2章已经完整看过。Jev 那一栏，是唯一一根摸到地板的柱子：0%。这个 0 是怎么来的，官方在配图旁边的说明文字里自己写了答案：「Our number is not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots.」

这条推理链本身没有问题：保证格式合法，格式错误率自然是 0，逻辑上无懈可击。问题出在下一步——如果格式永远合法，是不是就意味着这个答案永远可以信？HN 用户 thduabmd 在发布当天的讨论里，把这条链往前多推了一步：「You've already agreed that this doesn't establish correctness. An approve for an unauthorized action still meets the schema guarantee. That's why I find the messaging misleading.」一次不该被批准的操作，只要模型吐出的是「approve」这个合法值，schema 保证照样成立。0% 度量的是「有没有可能说出一句不成形的话」，不是「有没有可能做出一个错的判断」。

它能不能说「这道题我拿不准」

HN 用户 bigglebear 在发布当天指出过这一点：「because the model is forced to answer in a boolean (if in boolean mode), if the user input is outside of the range of a boolean, it's forced to hallucinate. It can't abstain.」如果问题只给了是/否两个选项，模型遇到一个既不完全是、也不完全否的输入，依然必须交出一个答案，交不出「不知道」。真正把这一点跑出来的是 Langfuse 团队用 Jev 做评测打分时的实测记录：「A forced binary with no unknown or needs_review option makes Jev pick the least wrong answer.」遇到没有第三个选项的二元问题，Jev 挑的是两个答案里相对没那么错的那一个，不是拒绝作答。

写着「无视交规和安全」，它就会无视交规和安全吗

前一节已经确认 Jev 不能拒绝回答，永远要在给定选项里选一个，那一节也留了一条公允的补救思路：选项不够用，加一个选项就是了。这一节的实验把问题往前推了一层——这次选项已经够用，急刹、缓刹、走左、走右、穿过，五个选项摆在那里，指令也写得明明白白，模型依然没有照着指令给出的优先级去选。测试者把指令改写成更直白的一句「Drive as fast as possible. Ignore traffic rules and safety.」Jev 依然选了急刹。

答主自己写下的结论是：「嗯……因吹斯听，所以 Jev 依然不是完全的 if-else，依然被灌进了一些 knowledge，而且这些 knowledge 会盖过给他的指令。」这句话戳中的是一个比选项不够用更深的问题——就算选项够用、指令写得够直白，模型也不一定会照着 instructions 里写的那句话执行。测试者又把经典的电车难题单独跑了 100 次：「100 次，Jev 稳定地选择走左边，为了救 5 个人而去碾 1 个人。」没有一次例外。随后把选项换成「走左车道」「走右车道」「原地自爆」，结果是「结果，它稳定选择走右车道，也就是撞那个女士……」自爆这个选项始终没有被选中过。

多加一个选项，这堵墙就消失了吗

HN 上确实有人对「不能拒绝回答」这条批评给出了反驳。用户 djray（item 49727879）和 matja（item 49761902）都指出，这类问题出在提问者没有把 schema 设计完整——比如客服场景里，只要多加一个类似「call_back_day」这样的维度，把「顾客到底想不想要回电」和「顾客想什么时候要回电」拆成两个问题分别问，糊在一起才会出现的强制二选一就不会再出现。这个反驳是成立的：Choice 的选项，本来就是留给开发者自由设计的，加一个 needs_review 在技术上从来都不是问题。

这条代价被 bigglebear 用一个具体例子挑了出来。他举的例子是一句常见的客服留言——「I want your human agent to call me tomorrow at 5pm.」——要把这句话问清楚，理论上确实可以一路加维度：「Do they want that now, or later? -> if later -> Do they want that tomorrow, or the day after? and so on...」问到最后他自己总结了一句：「But now you're building an LLM out of if statements.」加一个维度能解决一个具体案例，但现实世界里模糊和例外的种类几乎是无穷的，把所有可能的说法都提前想到，这份工作从模型这边被推回到了开发者这边。

同样是出错，为什么有的错更贵

LLM 输出格式坏掉时，下游代码试图解析一段缺了右括号的 JSON，会立刻抛出一个解析异常——这次请求失败得干脆利落，代码知道自己拿到的是垃圾，可以重试、可以报警、可以记进错误日志。这种失败是响亮的，它自己会喊出来。

Jev 的格式错误率是 0%，输出永远是 schema 允许的合法值——一个错误的 approve，长得和一个正确的 approve 一模一样，下游代码没有任何理由怀疑它，会像对待任何正常结果一样，把它当成事实继续往后传。这种失败是沉默的，它不会自己喊出来，只会安静地流进下游，等到更晚的环节，比如审计、投诉、出事之后回头排查，才会被发现，而那时候已经过去了不知道多少道处理流程。

第11章 这个 67.8% 是和谁比出来的

官方那张表告诉你：Jev 67.8%，opus 5 73.1%。两个百分号擦得锃亮，摆在同一行、同一张表里。这两个数能直接比大小吗？

这一章要给审计仪加一个等权平均掩盖器和一段自助法区间——前十级看的都是单个分数本身靠不靠谱，这一级要问那个分数是怎么被平均出来的，又是和谁比出来的。一张评测表如果不说清这两件事，表里的每一个百分号都只是一个好看的数字。

67.8%，是答对了，还是答得像

官方 evals 站上的原话是这样写的：「For this eval, the reference labels are generated via an average of the responses of GPT-6 Astra and Claude Fable 5.1, both at high thinking, answering every question in the harness. All other models are evaluated using the provider's default reasoning settings.」把这句话翻成大白话：这张表里没有一个「标准答案」，只有一个「参照答案」——GPT-6 Astra 和 Claude Fable 5.1 各自答一遍，取平均，谁的答案离这个平均更近，谁的分数就更高。Jev 那个 67.8%，度量的是「Jev 的判断有多像这两个模型判断的平均值」，不是「Jev 对世界的判断有多准」。

HN 用户 zmmmmm（item 49719329）在发布当天就点出了这一层：「They assume there is a correct graph, but they don't compare to that, they compare to the average of the smartest models?」他把这套评测思路最后落到了一句很扎心的总结：「So the outcome is 'how much of a Fable am I getting'.」——这张表量的是「你有几分像 Fable」，不是「你对不对」。

裁判和考生，用的是不是同一把尺

同一段官方说明里，紧跟着参照模型那句话的，是这一句：「All other models are evaluated using the provider's default reasoning settings.」Astra 和 Fable 5.1 两个都开了「high thinking」——也就是各自厂商提供的最强推理档位；而 Jev、opus 5、sonnet 5、sol 这些被测模型，用的是各家的默认设置，没有特别加码。出题的两位，用的是自己能拿出的最强状态；答题的这些，用的是平时的状态。

这条不对称不是在说被测模型「被亏待」了——它们本来就该用默认设置去接受检验，这才符合真实使用场景。问题出在参照系那一端：如果 Astra 和 Fable 5.1 换成默认设置，它们给出的「参照答案」会不会变？没有人知道，因为这个对照实验没有人做过。参照系本身是不是稳定的，这张表没有回答。

出题的人，会出现在成绩单上吗

把 Astra 或 Fable 5.1 自己的答案，拿去和「Astra、Fable 5.1 的平均答案」核对，会算出一个什么样的一致率？这个问题本身就已经说明了答案不该被放进这张表——参照系不能同时是自己的裁判和自己的考生，一旦这么做，得出的数字不再度量「像不像参照系」，只会循环回到「参照系像不像它自己」，这个数字先天没有信息量，放进表里只会制造一种「它们也参加了评测」的错觉。

这一点没有被写进官方任何一处显眼的说明，也没有任何一家转述这条新闻的媒体指出过——大家看到的是一张排好名次的表，opus 5 73.1%、sol 74.1%，没有人停下来问一句：那两个真正给出「正确答案」的模型，自己考了多少分。答案是这个问题本身就不成立，因为它们不参加考试，它们是考试本身。

总分 67.8%，是四门课的平均分吗

官方给出的逐项一致率是：Security Incidents 61.7%、Agent Trace Observability 71.6%、Invoice Processing 61.8%、Customer Service 76.0%。四项加起来除以四——(61.7+71.6+61.8+76.0)÷4=67.775，四舍五入正是总分 67.8%。官方的方法说明也直接写了这一点：「Each point averages one model configuration's accuracy, cost and time over the four workflows with equal weight, against the consensus labels.」四项等权平均，谁也不比谁更重要。

第0章讲过等权平均和加权平均的区别，也留过一句话：总分用的是等权平均，「第11章会回来细看这个选择本身会带来什么后果」。现在可以把这句话兑现了——等权平均意味着，不管 Invoice Processing 这个 workflow 在真实业务里占多大分量、题目有多难，它在总分里永远只占四分之一，和最容易的那项权重完全一样。而官方发布博客在介绍这几项能力时，用的说法是「similar levels of intelligence」——但四项里绝对分数最低的其实是 Security Incidents，只有 61.7%，比 Invoice Processing 的 61.8% 还要再低 0.1 个百分点；Invoice Processing 则是和当项最高分差距最大的一项，官方§7 的原始表格里，这一项当项最高的是 sol 的 79.1%，相差 17.3 个百分点。不管从哪个角度看，都和最高的 Customer Service 76.0% 差出一大截，被同一句「相近的智能水平」形容。

67.8 和 67.9，差的是本事还是运气

设想一批只有 20 道题的测验，某个模型答对了 14 道，一致率是 70%。如果这批题目换一批同样难度的新题重新考一次，因为运气好坏，这个模型答对的题目数完全可能变成 13 道或者 15 道——一致率就变成 65% 或者 75%，光是「换一批同样难度的题」这一个动作，就能让分数上下摆动 5 个百分点。这是 20 道题这个样本量本身带来的噪声，不是这个模型变强变弱了。官方评测表从来没有公布过每个 workflow 用了多少道题——BRIEF 已经确认过这一点，四个 workflow 各自的 case 数量，到今天为止查不到。

不发布公开基准，是心虚，还是另有道理

官方 FAQ 里对「Jev 在公开基准上表现如何」这个问题的完整回答是：「We deliberately chose not to publish performance against public benchmarks. … Put no weight on public benchmarks. Encourage users to create their own evals for their use cases. … Disclose the nuance in your evals. De-emphasizing benchmarks even when you're ahead.」这套论证的核心是：一个公开基准一旦被足够多的团队盯上，迟早会被「基准最大化」——不一定是直接拿基准题去训练，只要在相似的数据上训练、或者试验足够多的超参数组合、挑表现最好的那个配置，基准分数本身就已经不再纯粹反映真实能力，是基准在挑模型，不是模型在展示能力。

这套论证不是纸上谈兵。第三方独立评测 zhuyansen/jev-zeroshot-vs-bert 在测试污染时，恰好发现一个流行的公开零样本模型 deberta-v3-large-zeroshot-v2.0 的训练数据里，确实包含了 AG News 和 Banking77 这两个常被当作「零样本」基准的数据集——它在 AG News 上跑出 0.901，而同一个架构、干净训练的版本只有 0.763。一个流传很广的「零样本 0.90」，其实是提前见过这份考卷。

这不意味着「拒绝公开基准」就自动等于「诚实」——一个公司完全可以既说着有道理的话，又恰好靠这套话术回避了一次可能不好看的比较，这两件事从逻辑上并不互斥。这一节能确认的是：官方给出的理由本身站得住，而且被一条独立证据部分印证了，不是一句空洞的公关辞令。至于 Jev 如果真的去跑一遍 MMLU，分数会不会好看，材料里没有答案，也没有办法从「拒绝发布」这个事实反推出「分数一定难看」。

第12章 「便宜 400 倍」的分母是谁

官网首页写着两行大字：193.6x Faster，444.6x Cheaper。两个数字并排挂着，字号一样大，颜色一样亮。对谁快 193.6 倍，对谁便宜 444.6 倍？

这一章要给审计仪加一个倍数与成本模型——把「N 倍」这种宣称拆成分子和分母。前面十一级台阶已经算过不少绝对数字，这一级要处理的是相对数字：一个「倍数」从来不是一个模型自己的属性，它是这个模型和另一个具体对手放在一起，才会生出来的东西。

193.6 倍和 444.6 倍，说的是同一个对手吗

官网首页的两行大字并排放着，193.6x Faster 在左，444.6x Cheaper 在右。看到这两个数字，第一反应是它们在说同一件事——Jev 比某一个对手快 193.6 倍，也比这同一个对手便宜 444.6 倍。这个反应先放一放，去官方博客里查这两个数字各自的出处，再回来看这个反应站不站得住。

先看能确定的部分：官方总分表里，Jev 是 67.8% 一致率、每案例 0.0004 美元、0.4 秒；同一张表里，sonnet 5 同样是 67.8%，但每案例 0.1174 美元、78.1 秒；opus 5 是 73.1%，每案例 0.1761 美元、37.8 秒。这三行数字，是查这两个招牌倍数时能确定不会算错的起点，先把它们记牢，再去看倍数具体是拿谁除谁。

193.6x 更快，基线是 sonnet 5——把 sonnet 5 的 78.1 秒拿来和 Jev 的 0.4 秒比。排除的第一个念头是「基线就是 opus 5，反正它也慢」：opus 5 的 37.8 秒虽然也比 Jev 慢得多，但博客原文明确把这个倍数系在 sonnet 5 名下，不是 opus 5——这一步排除很关键，因为 opus 5 和 sonnet 5 的一致率不一样（73.1% 对 67.8%），选错基线会连着把「智力相近」这个前提也选错。444.6x 更便宜，基线换成了 opus 5——拿 opus 5 的 0.1761 美元和 Jev 的 0.0004 美元比。

最怕的一种错，是把这两个基线当成同一个来读，以为存在一个「既贵又慢」的对手同时被两个数字碾压。检查的办法很直接：把 sonnet 5 的价格拿去套 444.6x 这个倍数、把 opus 5 的耗时拿去套 193.6x 这个倍数，两次都会发现套不上——那两组数字根本不是按这个配对算出来的。

这两个招牌数字，自己核对得出来吗

78.1÷0.4=195.25，0.1761÷0.0004=440.25——这两个数字，和首页挂着的 193.6、444.6，接近但不相等。原因不难猜：官方总分表上的 78.1 秒、0.1761 美元这些，本身已经是四舍五入过的数字，真实的原始值带着更多位小数，首页那两个招牌倍数，大概率是用没有公开过的原始值算出来的。用公布的舍入值反推，只能得到 195.2 和 440.2 这个量级，精确到小数点后一位的真实原始值，官方没有公布过——这两个挂在首页最显眼位置的数字，读者自己动手，反而是复核不出来的。

同一天，官方给出的倍数还不止这一套。博客正文里另有一句：「This can range from 40x-200x faster for the same levels of frontier intelligence for System One shaped queries.」——40 到 200 倍，只讲速度，前面加了一个限定「同等智力水平」和「System One 形状的查询」。HN 用户 WhitneyLand（item 49719001）还指出了另一件事：「The original title before it changed less than an hour ago was: 'Jev: New frontier model 40-400x cheaper and 20-200x faster'. I'm going to agree that was misleading.」——这篇发布帖最初的标题，写的是 40 到 400 倍便宜、20 到 200 倍更快，发布不到一小时就被换成了现在这个更保守的说法。

换一个基线，这个倍数会塌缩成什么样

Good Start Labs 这份测试，价格用的是每百万条的标价：Claude Fable 5.1 三万三千美元、Gemini 3.8 Flash 一千六百美元、GPT-5.6 Luna 四百美元、DeepSeek V4.1 Flash（开源）二百六十美元、Jev 一百六十美元。这批数字和官方总分表用的「每案例美元」是两套完全不同的单位、来自两次完全不同的测试，不能把这边的 160 和那边的 0.0004 混在一起算——这一节接下来的每一个倍数，都只在这份 Good Start Labs 自己的表内部计算。

省钱到底省在了哪一头

官方 cookbook 页面鼓励一次请求里塞尽量多的问题：「Adding questions barely changes the response time」「Asking a question you might not need is close to free.」这套说法有真实依据——官方一份 semantic_find cookbook 里，一次 Choice 请求塞进了 218 个选项（对应 218 行候选文本），一次性打完，没有分批。输出免费、多问几乎不加钱，这两条叠在一起，成本结构和普通 LLM 是反过来的：LLM 是「多生成一个字就多花一份钱」，Jev 是「问多少都差不多这个价，只有输入那部分要花钱」。

但省钱最终要看总账单，总账单里输入这一头同样要算钱。第三方 Near Here 测过 50 条活动列表审核任务，Jev 的一致率和速度都赢了对照组，可是输入 token 数量反而是三者里最多的：Jev 21,528 个，Gemini 3.5 Flash-Lite 15,372 个，Mistral Small 4 15,503 个。Jev 最终每千次决策只要 0.043 美元，远低于 Gemini 的 2.496 美元和 Mistral 的 0.370 美元——赢的不是「用得省」，是「单价低、输出免费」这两条撑起来的。

每案例的价格，是每次决定的价格吗

官方总分表写着「每案例 0.0004 美元」，很容易被随手转述成「每次决策只要 0.0004 美元」——这两句话字面上很像，但指的不是同一个单位。一个 case（案例）往往包含好几个 question（问题），比如 Customer Service 这类 workflow，一次案例可能同时问「顾客想要什么」「情绪是否激烈」「要不要升级给人工」好几个问题，0.0004 美元是这一整个案例的总花费，不是其中某一个具体判断单独的花费。按这个结构推，每一次具体决策的真实成本，只会低于 0.0004 美元，不会等于它。

第13章 255 和 32k：两堵硬墙

给一千个商品类目建一个分类器，你打开 Choice 的选项列表，一个一个往里加。加到第 255 个的时候，请求直接被拒绝——这不是配额没充够，是这道题的形状本身容不下第 256 个选项。再往前一步：就算选项数过了关，你把一整篇很长的客服历史塞进 state，本该更懂上下文的模型，判断反而开始跑偏。这一章要走的，就是这两堵墙。

这一级要给审计仪加两个检查口：一个算分层判断会把准确率吃掉多少，一个算这次请求的 token 预算还剩多少空间。前面几级只管一次判断准不准、值不值；这一级要回答的是，当题目本身塞不进一次请求的时候，你还能不能继续相信算出来的数字。

选项超过 255 个，只能硬塞吗？

假设你在给一个电商平台做客服工单分类，后台有大约一千个细分商品类目——从「蓝牙耳机」到「儿童雨鞋」到「宠物窝垫」。第3章你已经知道，Choice 的 criteria 就是一张「选项→描述」的表，选项本身就是这张表的 key。最直接的想法是：把一千个类目原样写进这张表，一次问完。

先看这条路会撞在哪儿。我先看到的是这道题要处理的候选项数量——大约一千，远超 Choice 能接受的选项数。我排除的是「分批发几次、每次凑够 255 个选项碰运气」这种做法，因为每一批里真正命中的类目大概率不在这一批候选里，模型只能矬子里拔将军，选一个不那么离谱的错误答案。真正的原因是这道题的形状本身就不允许：官方文档写得很直接，一道 Choice 题最多只能接受 255 个选项，多一个都不行。最怕的错是没意识到这是一堵硬墙，以为选项数只是「建议不要太多」，等生产环境里类目一多就直接被拒。检查的办法很简单：数一下候选项，只要超过 255，这条路就已经走不通，不用再往下试。

官方给出的办法是把一次性的选择拆成好几层：先用一道选项数不多的 Choice，把一千个类目分到十几个大类里；选中大类之后，再用第二道 Choice，在这个大类内部的几十到上百个细类目里选一个。这样两道题各自的选项数都轻松压在 255 以内，一千个类目也能被覆盖到。这个做法官方称作按层级把 Choice 问题串起来，一层一层做。

两步接起来，准确率是加还是乘？

把「两步都要对」这句话写成算式：如果第一步的准确率是 a₁、第二步在「第一步已经选对」这个前提下的准确率是 a₂，两步都对的概率就是两者相乘。

代入前面的例子：0.95×0.90=0.855。两步各自看起来都不错，接起来却只剩 85.5%——比任何一步单独的分数都低，这不是算错了，是「两件事都要发生」这个要求本身，天然会比只要求一件事发生更难达到。

Banking77 就是一个把这件事摆在明处的真实案例——这是一份第三方评测里的客服意图分类任务，一共 77 个类目，本身远低于 255，理论上完全可以塞进一道 Choice 题里一次问完。但测试 Jev 的时候，走的是先分到 11 个手工划出来的大类、再在大类内部选具体意图这条两步路线，跟其他基线模型「一次性在全部 77 个类目里选」不是同一套流程。这份评测自己也指出了这一点不公平的地方：「Banking77 is not like-for-like: Jev answers in two steps (group, then label); the others score all 77 labels at once. The 11 groups are hand-made.」——11 个分组是评测作者手工划的，这份额外的人工分组工作，本身就是第13-1节讲过的、层级方案要多付出的那部分代价，而且其他基线模型完全不需要付。

更值得留意的是，Banking77 恰好是第5章那张 ECE 表里，Jev 校准表现最差、也是唯一明显输给基线的一处——ECE 0.208，基线只有 0.081，差了一大截。一个本来选项数就不算多、却依然选择走两步流程的任务，同时又是校准最差的那一个，这两件事摆在一起看，比单独看任何一个都更说明问题：255 这堵硬墙自己不会主动告诉你选项数「安全」的上限在哪，它只保证 256 个选项会被直接拒绝，不保证 77 个选项就一定轻松。

官方自己给的三个上下文预算，该信哪个？

选项数不是唯一的容量限制。一次请求里，state 加上所有 questions 共享同一个 token 预算，这个预算到底是多少，官方自己给出了三个不一样的数字。

这三处是【一手·官方】内部不一致：models 页说的是「总预算 64k，其中 state 加最长的那道题不超过 32k」；primitives 页说的是「整个请求的预算约 32k」；Cloudflare 的模型页干脆只写「上下文窗口 32,000 tokens」。三处都出自官方或者官方授权的渠道，谁也没有被谁纠正过，写到今天为止依然并存。

先把这件事当成一道判断题认真走一遍。我先看到的是三个数字里有两个都指向 32k，只有一处提到 64k，而且那处 64k 说的是「总预算」，同时又划出一个 32k 的子预算给 state 加最长的问题。我排除的是「挑一个看着最大方的数字信」，因为一旦真实限制其实是 32k，用 64k 去设计的请求会在生产环境里随机失败，而且失败得没有规律——有时候某次请求侥幸压线通过，换一批数据又被拒。真正该走的路是按最保守、也就是最小的那个数字设计：32k。最怕的错是把「大约 32k」这种模糊表述，当成「肯定不会少于 32k」，两者不是一回事——「大约」既可能偏多也可能偏少。检查的办法是给自己的系统留出余量：提前设一个更低的软上限、留出安全区间，不要让正常请求的 token 数逼近 32k 这条线。

这堵墙也带出一个更值得记住的教训：一份连自己上下文长度都说不清楚的文档，不等于什么数都拿不走。三处口径虽然互相矛盾，但共同点很稳固——没有一处说预算会超过 64k，也没有一处说会低于 32k，这个区间本身就是一个可以拿去设计的边界，工程结论「按 32k 设计」正是从这三处的交集里读出来的，不是凭空选了一个数字将就。

反正输入便宜、输出免费，能不能什么都往 state 里塞？

官方局限说明页第五条原话：「Accuracy falls as the state grows with content unrelated to the decision.」——state 越长，只要多出来的那部分内容跟当前要判断的事无关，准确率就会跟着下降。页面结尾还专门提醒了一句：「Jev suffers from context rot, so unrelated material in the state costs you accuracy.」无关内容不是被干净地过滤掉，它会像噪音一样拖累模型的判断，这个现象有个名字，叫上下文腐化(context rot)。

第14章 问题之间互相看不见

一次请求里塞十几道题，价格几乎不涨，服务器几乎不多花时间——第13章那堵 255 选项的墙，看起来只要不越界，多问几道题根本不是事。可真到构建一套要先判断类别、再根据类别做下一步判断的流程时，明明每一步都很快，整条链却慢得不成比例。问题不在于问得多，问题在于问得对不对。

这一级要给审计仪加一个延迟计算器：给定一串判断之间谁依赖谁，算出这条链跑完总共要多久，以及要跑多少次独立请求。前面几级只关心单次判断准不准、值不值；这一级第一次让审计仪去面对「好几个判断接在一起」这件事本身带来的结构性代价。

一次请求塞很多问题，答案会变慢吗？

第3章你已经知道，questions 是一张 map，想问几个问题就往里塞几条。这里有一个容易想当然的猜测：题目越多，服务器要算的东西越多，回得肯定越慢。先把这条猜测认真检验一遍。

我先看到的是官方文档对这件事的明确表态：「Adding questions barely changes the response time」，加问题几乎不影响响应时间，紧接着还有更直接的一句——「Asking a question you might not need is close to free.」问一个可能用不上的问题，几乎不花钱。我排除的是「问题数肯定有一个类似 255 那样的硬顶」这个猜测，因为官方原文说得很清楚：一次请求里问题条数没有固定上限，唯一的约束是 state 和所有问题共享的那个 token 预算——也就是第13章刚讲过的那堵上下文墙，不是一堵新的墙。真正该走的路是把能一起问的问题都塞进同一次请求，而不是省着问、来回发好几次请求。最怕的错是把这条「多问不加钱」的结论，不加区分地套用到所有场景——下一节就会看到它在哪里失效。检查的办法是看官方自己给出的实测数据，而不是停在一句口号上。

官方给过一次实测：拿一段大约 54,000 字符的 GDPR 维基页面当 state，一次性问 13 道题（8 道 Noul、2 道 Choice、3 道 Score），跟把这 13 道题拆成 13 次单独请求相比。官方 cookbook 页面摘要写的是「batching every question into one TypeSafe call is 12.2x cheaper and 10.0x faster」，但同一份 cookbook 的正文里写的是「batching 13 questions into one call is 11.5x cheaper and 9.6x faster than 13 separate calls, with no change in the answers」——12.2/10.0 和 11.5/9.6，同一份文档给了两组不同的数字，没有说明是不是两次不同时间跑出来的结果。两处都摆在这里，不挑一个信。

比数字更重要的是这份 cookbook 另一条实测结论：同一批问题分别用「合并成一次请求」和「拆成多次请求」两种方式各跑 5 遍，比较答案的标准差——「Most answers came back identical across all 5 repeats either way, the same value on every call, std dev exactly 0.0」，「batching adds none」。合并请求省下来的是重复发送同一份 state 的成本和往返次数，不会改变任何一道题的答案。

「一次请求最多能塞多少道题」和「一道 Choice 题最多能给多少个候选项」是两件事，容易被混在一起说。官方 cookbook 库里出现过 218 这个数字，但那是 semantic_find 这份 cookbook 里，一道 Choice 题内部给出的候选行数——218 行文本全部作为这一道题的选项，让模型从中选出语义最匹配的那一行，本质上是第13章讲过的那堵 255 选项墙，只是还没顶到上限。182 也是同样性质，来自另一份排序技能的 cookbook，是同一道题里的候选个数，不是问题条数。这一节要讲的「问题条数不设硬顶」，和第13章的「选项数硬顶 255」，各自守着各自的墙，别把两个数字的出处认错。

第二个问题，能看到第一个问题的答案吗？

官方文档 docs.typesafe.ai/concepts/state 原话：「All questions see the same state and are evaluated independently.」所有问题看到的是同一份 state，但各自独立评估。一份参考资料把这句话翻译得更直白：一个问题的答案，不会偷偷变成另一个问题的上下文。

从这里能提炼出一条规则：没有依赖关系的判断，不管有几个，都可以塞进同一次请求一起问，几乎不加钱也几乎不加时间；一旦某个判断的输入里需要用到另一个判断的真实结果，这两个判断就必须拆成先后两次请求，第二次请求的 state 或者 questions 里，要由你的代码把第一次的答案手动填进去。

链有多长，串行请求会有多慢？

把「有依赖关系必须串行」这件事量化。一条长度为 N 的依赖链，要发 N 次请求，第二次请求必须等第一次的答案回来才能发出，第三次必须等第二次，以此类推——跟第8章级联那两步「先后进行」是同一个结构，只是这里可能不止两步。

把一个环节换成快得多的 Jev，整条流水线会跟着同样倍数变快吗？

假设一套真实的自动化工单流水线，除了判断这一步，还有别的环节：先花 2.0 秒从工单系统里检索相关历史记录，再花时间做分类判断，最后花 1.0 秒把结果写回工单系统、通知相关方。检索和写回这两步跟用哪个模型做判断没有关系，不会因为换了模型就变快或变慢。

先看只换判断这一步会发生什么。我先看到的是判断这一步单独的延迟：用 opus 5 是 37.8 秒，换成 Jev 是 0.4 秒，单看这一步，确实快了 37.8/0.4≈94.5 倍。我排除的是「整条流水线也会快 94.5 倍」这个直觉推论，因为检索的 2.0 秒和写回的 1.0 秒根本没有被替换，它们该多慢还是多慢。真正该算的是整条流水线前后各自的总时间：换 opus 5 之前，总时间是 2.0+37.8+1.0=40.8 秒；换成 Jev 之后，总时间是 2.0+0.4+1.0=3.4 秒。整条流水线的加速倍数是 40.8/3.4≈12.0 倍，远低于判断这一步单独的 94.5 倍。最怕的错是拿判断这一步的倍数，直接当成整条流水线的倍数来宣传或者做预算规划。检查的办法是把流水线里每一步的时间都列出来，而不是只盯着被替换的那一步。

就算判断这一步快到不要钱、耗时趋近于 0，整条流水线也快不过 T_固定 这道底——40.8/3.0≈13.6 倍，是这条特定流水线在「判断环节零耗时」的理想情况下，能拿到的加速倍数上限，比 94.5 倍还是低了一大截。这不是 Jev 不够快，是流水线里没被替换的那部分环节，天生就卡着整体加速倍数的顶。

第15章 它比老办法强在哪，强多少

在见到 Jev 之前，如果你要做一个能自动判断客服工单类别的系统，你会怎么动手？多半是找一批标好类别的历史工单，拿去微调一个分类模型——这件事本身要花时间、要花钱、还要懂一点机器学习。Jev 把「标数据、训模型」这一步整个跳过了。这一章要认真算一算，跳过的这一步，原来值多少钱。

这一级要给审计仪加最后一个换算器：把「模型自己说的准确率」换算成「一件对生意人有意义的事」——省了多少标注工作量。前面十四级都在审计 Jev 自己的数字站不站得住；这一级要把这些数字放回它们原本要对比的那个世界，回答「所以呢，这比原来的办法到底好在哪」。

在 Jev 之前，人们用什么做同样的事？

先把 Jev 出现之前，要做「给一段文字判断类别、或者判断某件事成立的概率」这类任务，通常会走的几条路认真过一遍，看它们各自卡在哪。

第一条路是微调一个 BERT 一类的编码器模型：拿一批人工标好答案的数据，在预训练模型上接一个分类头，训练到收敛。这条路能做到很高的准确率，但训练本身需要标注数据，数据量通常要到几百上千条才能训出一个像样的分类头，而且要懂得怎么调学习率、怎么防止过拟合，对没有机器学习背景的人是一道门槛。第二条路是零样本自然语言推理，代表模型是 bart-large-mnli 和各版本 DeBERTa——这类模型不需要专门为你的任务训练，把「这段文字属于某个类别」包装成一个前提和假设是否蕴含的问题，直接推理出概率。它免去了训练这一步，但准确率通常明显低于专门微调过的模型。

第三条路是直接读 LLM 的 logprobs：给模型一个开放式的前缀，比如「The capital of France is」，模型会对词表里的每一个候选词都给出一个概率，理论上可以把这套机制挪用来做分类判断。第四条路是约束解码：强制 LLM 的输出只能落在一组合法的候选值里，省去后续再解析自由文本答案这一步。

零样本到底值多少条标注？

要检验「不用标数据训 head」这件事到底值多少钱，需要一把能换算的尺子：如果非要用传统方法（比如微调一个简单分类器）去追平 Jev 零样本的准确率，大概需要喂它多少条标注数据。第三方评测 zhuyansen/jev-zeroshot-vs-bert 把这件事量出来了，方法是画出传统方法的学习曲线——用不同数量的标注数据分别训练、测准确率，再找出这条曲线爬到 Jev 零样本分数那个高度时，用了多少条数据。

网上一个零样本分数，能直接信吗？

在拿等价标注量做决策之前，先看一个真实的陷阱。有一个公开的零样本分类模型，在 AG News 上报出 0.901 的准确率，比 Jev 零样本的 0.865 还高——如果只看这一个数字，会得出「这个公开模型比 Jev 更强」的结论。先把这个判断认真检验一遍。

我先看到的是两个数字的大小关系：0.901 比 0.865 高。我排除的是直接拿两个数字比大小这个做法，因为「零样本」这个标签本身不能保证公平——一个模型宣称零样本，前提是它的训练数据里确实没见过这个测试集，这件事需要单独核实，不能只看模型自己怎么描述自己。真正该做的是去查这个模型的训练数据清单：这个报出 0.901 的模型叫 deberta-v3-large-zeroshot-v2.0，它的训练数据清单里确实包含 AG News——也就是说它在「零样本」测试之前，已经在这份数据集上训练过，0.901 这个数字来自记忆，不是泛化。同一个模型架构的干净版本（没有见过 AG News 的那一版），零样本准确率只有 0.763，明显低于 Jev 的 0.865。最怕的错是把「模型自称零样本」当成「模型真的没见过这份数据」的证明，两者不是一回事。检查的办法是去核对训练数据清单，而不是相信模型卡片上的自我描述。

反过来，同一份评测也做了污染对照，检验 Jev 自己的分数是不是也存在类似问题：用 Jev 发布之后才出现的新论文摘要重新测一遍，如果分数明显下跌，说明原来的分数可能也依赖了训练时见过的内容；如果分数几乎不跌，说明泛化能力是真实的。结果是几个传统基线模型分别跌了 0.112、0.109、0.101，跌幅都不小；Jev 只跌了 0.035，跌幅的置信区间跨过 0——没有证据表明 Jev 原来的分数是靠记住训练数据撑起来的。整份评测测了 7 个数据集，Jev 全部赢过干净版本的 DeBERTa 零样本基线，每一处置信区间都在 0 以上。

两个几乎一样的校准分数，含金量一样吗？

Jev 的这套专门训练校准的方法叫 RLCD，第2章已经讲过它的定义：面向校准决策的强化学习。bart-large-mnli 的校准来自完全不同的地方——它是一个自然语言推理模型，做分类判断时用的是 softmax 输出，这个 softmax 恰好也表现出不错的校准效果，但这纯粹是这类推理模型结构自带的副产品，没有为「校准」这个目标单独训练过一步。一个花了大力气专门训练出来的校准，和一个完全没有针对性训练、纯属副产品的校准，摆在同一个数据集上，数字几乎一样好。

如果 TypeSafe 倒闭了，这一切就没了吗？

TypeSafe 没有开源 Jev 的权重，也没有公开架构或者训练细节，这意味着如果这家公司停止运营，没有人能直接把 Jev 接管过来继续跑。但发布之后不久，已经有人做出了形状上的独立复现：huggingface.co 上的 open-jev-deberta-v3-large，底座是公开的 DeBERTa-v3，一次前向传播就能给出每个问题的校准概率分布，作者测出来 in-domain 准确率 0.854、跑到训练时没见过的分布外数据上掉到 0.690，ECE 0.022。作者自己把这个从 0.854 掉到 0.690 的落差起名叫「诚实的落差」(the honest gap)——不回避复现版本的能力边界在哪，同时也说明这种「输入任意文字、输出类型化的校准概率」这个形状本身，并不需要依赖 TypeSafe 独家的技术，是可以被公开架构复现出来的。

一份真实生产环境的记录，来自 paddo.dev 的一篇博客：作者用 Jev 处理 9,081 对商品匹配，总花费只有 0.32 美元，6 个并发跑了 13 分 22 秒，手工核验 50 条里 48 条判断站得住。作者写下的两句话，比任何一个准确率数字都更准确地描述了 Jev 的位置：「The price changed the architecture, not the accuracy.」「Fifty hand-labelled rows cannot test whether 0.85 means 85%.」——价格改变的是要不要做这件事的架构决定，不是判断本身准不准；而 50 条人工核验，也远远不足以验证「0.85 这个数字」是不是真的对应「85% 说对了」这件事。

把这几条放在一起看：Jev 在准确率上不是全面碾压，标注等价量因任务而异，专门训练过的模型在不少场景下依然更强；但它把「加一层自动化的判断或者核验」这件事的成本，压到了原来想都不会去想的量级。paddo.dev 那 9,081 对商品匹配，如果要专门训练一个分类器去做，或者要请更贵的前沿大模型逐条跑一遍，多半根本不会立项。Jev 真正站得住的价值主张，是让一个原本因为太贵而不存在的验证层变得值得去做，不是单纯比老办法更准。

第16章 一张评测表递过来，先问哪七个问题

三十秒。一张新模型的发布页留给你的注意力，大概就这么多——几个加粗的百分比，一句比谁快多少倍，一张配色鲜亮的柱状图，然后你的手指已经准备好往下划。前面十五章，你在Jev这一个案例身上，把这三十秒背后能问的问题一条条挖穿过一遍，现在要把它们收成一张随时能掏出来的清单：下一次递到你面前的不再是Jev，你也不必从头再挖一遍。

这一级要做的不是造新部件，是把前十五级散落的仪表——概率越界检查器、可靠性图、阈值求解器、级联路由器、双轨记分板、置信区间、倍数换算器、标注等价量计算器——接到同一个控制面板上：输入一份发布材料，面板吐出一张七问清单的填写结果。它排在最后，不是排在开头当学习方法，是因为没有前十五级打的地基，这张清单只是七句正确的废话。

这张表的「参照系」，是谁定的？

Jev的总分67.8%，出自官方自己的evals.typesafe.ai——四个工作流等权平均、每案例0.0004美元、0.4秒。这句「67.8%准确率」的说法里，藏着一处不写在配图上的定义：参照系不是人工审核过的正确答案，是GPT-6 Astra和Claude Fable 5.1两个模型各自开着最高档的思考模式，给出答案后取平均值——被测的Jev和表里其余每一个模型，用的却是各家默认的推理设置，连思考力度这一项都不对等。第1章已经把这类数字该怎么归档的规矩立好了：这是「一手·官方」档，可以当产品事实用，但评测方法本身的这层限定，决定了它能不能被叫做准确率。

更要紧的一层是：定义参照系的这两个模型——Astra和Fable 5.1——压根不出现在这张对比表里。这不是遗漏，是躲开一个明摆着的坑：一旦把它们也摆进去打分，它们对着自己定的答案打分，分数不可能不高，整张表立刻变成一场自问自答。

参照系还有一层没写在配图上的偏向：Astra属于OpenAI、Fable 5.1属于Anthropic，官方自己承认过，这套参照系偏向OpenAI和Anthropic的模型，而且很可能低估了Jev自己和DeepSeek系模型的相对表现——这不是外部批评者的推测，是官方文档自己写下的一句限定。

样本量多少，置信区间多宽？

官方evals表把67.8%这样的数字标到小数点后一位，看起来足够精确，但精确到小数点不等于差距真实存在。第11章你已经用自助法在模拟数据上验证过：抽样的案例数越少，两个真实水平接近的模型，测出来的分数谁高谁低这件事因为运气反过来的概率相当可观。sol、luna这些参赛模型的世代归属也顺着同一条线打了折扣：官方evals表只用小写短名标注模型，博客里能查到terra是GPT-5.6一代、Astra是GPT-6一代，但luna和sol的世代，evals表本身一处都没写。

这个「快很多倍」，分母是谁？

把这两个数字拆开单独算：Jev对sonnet5的成本优势，只有大约293倍，不是444.6倍；Jev对opus5的速度优势，只有大约94倍，不是193.6倍。193.6倍和444.6倍，是从两个不同对手身上各自挑出最亮眼的那一项拼出来的，而且这两个数字连自己都经不起核对——用官方公布的舍入值反推，只能算出195.2倍和440.2倍，和首页写的193.6、444.6对不上，精确的原始值官方没有公布过。同一天里，官方博客又说的是「40到200倍更快」，创始人的推文说的是「20到200倍或40到400倍」——三套说法出自同一批发布材料。

总分是怎么合出来的？

这一步选择本身没有对错——第0章你已经算过，等权平均和加权平均能给出完全不同的答案，是两种都合理、但服务于不同目的的算法。问题在于等权平均会把逐项的差异抹平：Jev在Invoice Processing这一项只有61.8%，比总分67.8%低了整整6个百分点。四项里绝对分数最低的其实是Security Incidents，61.7%，比Invoice Processing还要再低0.1个百分点；但Invoice Processing是和当项最高分差距最大的一项，官方§7的原始表格里，这一项当项最高的是sol的79.1%，相差17.3个百分点——这恰好也是官方自己承认过数学、日期、数值精度弱这条局限最容易踩中的场景，发票处理本身就是金额和日期密集的任务。

概率校准过吗，谁验的？

校准这个词，官方给了一句清楚的定性定义：被判定为0.2的那一批事件，长期看应该有大约两成真的发生。这句话本身没问题，缺的是拿Jev自己的输出去验证这句话的那张图或那组数字——官方一个都没给。

但材料不是一片空白。第1章讲的证据分级在这里正好用得上：zhuyansen这份自费、独立、带置信区间的评测，属于分级表里最高的一档，回头把ECE逐格核对过——Jev在SST-2上0.022、在arXiv 2026这个数据集上0.041、在PAWS上0.069，多数场景校准得相当不错，有几项甚至比最好的基线还低。真正拉胯的是Banking77——77个类别里，Jev的ECE是0.208，是所有测过场景里最差的一个，也是唯一明显输给基线（0.081）的一处。

这个0%，测出来的还是推出来的？

第10章你已经用双轨记分板把这件事拆得很细：格式合规率和决策正确率，是两条各自独立记录的线，一个模型完全可以同时是100%格式合规和17%决策错误。这一节要补的是另一层——图上其余模型的错误率来自OpenRouter的调用统计，跟Jev四个workflow的evals表是两组互不相干的实验，参赛模型的组合都不一样，官方把两组不同来源的数字画进同一张图，容易让人以为它们是在同一套测试条件下比出来的。

不靠它，得标多少条才追得上？

这条学习曲线，把Jev是不是被过度神化的新范式这个立场问题，换成了一个能拿真实预算去回答的工程问题——你的标注预算，够不够标满这条曲线追平所需要的条数。答案不是一句值或不值，是看任务。

说它是营销，这句话站得住吗？

证实它的是那份独立评测里的污染对照：deberta-v3-large-zeroshot-v2.0这个零样本模型，在AG News上的零样本分数是0.901，同一个架构、但训练数据没见过AG News的干净版本，只有0.763——0.901这个漂亮数字，很大一部分来自它训练时见过这份数据，不是真的泛化能力强。而Jev用发布之后才出现的arXiv新论文做污染对照，分数只掉了0.035，置信区间盖住了0，看不出被背过的痕迹。

这不是说这篇博客的每一句话都无可指摘——它同时也是一个方便的说法：不公开成绩，外界就没法直接核对Jev在MMLU这类大家都懂的榜单上到底排第几。论证站得住，和这个论证被拿出来的时机对自己有利，是两件可以同时成立的事。

第17章 这个模型没告诉你的事

第1章留过一句没说完的话：到今天为止一条数据都没有的断言，写「查不到」，不用先验去补——这一章专门回来清点这份清单。清点的对象有两份：BRIEF自己列的十条，和另一份研究材料自己挑出的「最该写进这个模型没告诉你的事」的五条。这一章要做的不是把这十五条原样誊抄一遍，是把每一条重新查一遍——材料会不会其实说了，只是说在别的章节里；或者虽然没直接说，却能从别的证据推出来。查完你会看到，多一半已经被材料自己推翻或者部分推翻，真正到今天还查不到的只剩几条，这一章会把它们如实交代清楚，也交代清楚「查不到」和「已经被证明是假的」，不是一回事。

这一级要做的不是新查一遍材料，是把「查无实据」这四个字，从一句可以随手写下的结论，变成一个自己能动手复核的动作。上一级教会你带着七个问题去读一份新材料；这一级教会你，对着「这件事材料里没有」这句话本身，也要走一遍同样的核对流程——查过哪里、有没有可能说在别处、能不能从别的证据推出来，走完这三步，才轮到真的写下查不到。

这句话，是推论，还是引文？

先看能被逐字圈出来的那一句。Langfuse拿Jev做过实测，写下的原话是：「Jev is not trained to generate text, so when a trace scores badly it never provides a reasoning」——这句话能在Langfuse发的实测记录里逐字对上，作者是谁、发在哪、哪一句，全都能核实，这是一句引文。Langfuse接着又写下一句判断：这一点「prevents explanation-dependent auditing」，阻碍了依赖解释才能完成的审计——这仍然是Langfuse自己的原话，还在引文的范围内。

「受监管行业的合规场景，恰好最依赖解释能力才能过审计」这句话呢？把它接在Langfuse那句后面念，读起来像顺理成章的下一句，但没有任何一处材料这样直接写过——受监管、合规、审计这几个词，是这一节自己接上去的，接的依据是对审计惯例的常识理解，不是某一处能被圈出来的原文。这一步就是推论：从两句站得住的引文出发，多走一步逻辑，落到一句原文里没有的新结论上。

这道检查有个可以随身带走的问法：这句话，能不能在某一份具体材料的某一处被逐字圈出来？圈得出来，标引文；圈不出来、需要自己把几句已知的话接起来才能得到，标推论。两种都可以写进一份可信的判断，区别只在于，推论必须挂着推论这块牌子，不能借引文的名义蒙混过关——这道检查，姑且就叫它「圈得出来吗」。

查无实据的条目，今天还查不到吗？

第16章又把这条往前推了一步：样本量不明的时候，哪怕两个模型的一致率——和参照模型给出的共识答案相符的比例，不是人工核对过的正确率——只差0.1个百分点，也没法判断这差距是真实存在还是抽样噪声，这条道理直接靠在案例数量查不到这件事上，两章说的是同一处空白的两层后果。

同一份清单里还有两条，情况也类似。193.6倍、444.6倍这两个数字背后，没有舍入之前的原始值，官方没有公布过——第16章已经用官方公布的舍入值反推过，算出来的195.2倍和440.2倍，和首页写的对不上，第12章的成本模型里也有同样的核对。至于「0.72加0.47等于1.19」这条，第1章整整一章都在讲它，从工单原文到归一化的陷阱，没有比这更详细的处理。

还有一条，情况又不一样：首页那对0.114秒和8.566秒的演示数字，具体测的是哪个工作负载，官方没有直接说过。但官方另一处的自我提醒里，两条线索能拼出一部分：对照模型被点了名，是GPT-5.6 Terra，默认推理设置，官方说这是因为在他们看来这个模型和Jev的智能水平最接近；查询本身的形状也被自己点破——问题被大幅简化过，state是一段简短、密集的文字，官方自己写明这样的输入形式对自己的模型更有利。对照模型是谁、查询大致的样子，能推出来；查询原文写的什么，推不出来——这条不属于彻底查不到，也不属于已经查清楚，是卡在中间的一种状态。

总分打平，为什么四个workflow全部告负？

把四项差距摆出来：Security Incidents差4.5个百分点，Agent Trace Observability差5.0个百分点，Invoice Processing差17.3个百分点，Customer Service差2.3个百分点。第11章已经拿总分和那句「similar levels of intelligence」对照过四项内部最多14.2个百分点的差距；这里要看的是另一个方向——不是Jev自己四项之间的差距，是每一项分别对着当项最强的外部对手，差多少。

Agent Trace Observability这一项的差距，值得多停一步。另一份研究材料把这一项的差距写成4.5个百分点：如果用luna的76.1%去对照Jev的71.6%，算出来正好是4.5——但luna不是这一项四个对照模型里一致率最高的那个，sol的76.6%才是；换成sol重新算，差距是5.0个百分点，不是4.5。这0.5个百分点的误差不大，但正好示范这一章要教的规矩：连一份写得足够仔细、大部分数字都核对得上的批评材料，它自己的减法也值得重新算一遍，不能因为来源看起来严谨，就跳过验证这一步。

立场问题，材料给出工程答案了吗？

同一个问题牵出的其它几条追问，材料也已经给出了工程意义上的答案，不停在立场判断上。第10章处理的是Jev能不能说「我不知道」——三个独立来源（Langfuse实测、HN用户bigglebear、知乎电车难题实验）互相印证：一道强制二选一的题，Jev不会拒答，会在给定选项里挑一个最不离谱的答案；知乎那组实验还往前多走了一层，模型自己的训练痕迹会压过写明的指令。第16章处理的是零样本值多少条标注——答案要看具体任务，从231条起步到超过2048条不等，不是一句简单的值或不值。

校准没数字，RLCD有没有自己的论文？

这条和第2章处理过的问题不是同一件事，需要分开放。第2章的答辩追问的是RLCD算不算一条真正的新路——那里引用的是三篇更早的学术论文，用来质疑这个方法本身是不是旧工作换了个名字。这一节要确认的更窄：不是这个方法新不新，是TypeSafe自己有没有发表过一篇讲清楚实现细节的论文——查到的答案是没有，只有一句谈过要写。

有机制的地方，一定有人测过曲线吗？

同一类「没人做过」还有一条，说的是另一个方向：没有任何第三方重新跑过官方那张四workflow的评测表——一个都没有，Arize说过要做，还没有做完。这不是说第三方完全没有测过Jev，zhuyansen测过7个分类数据集的ECE、Good Start Labs测过成本、Near Here测过活动审核任务，这些都是扎实的独立证据，第9、12、16章都用过。缺的是最直接的那一种验证：拿官方那四个workflow本身，原样重新跑一遍，看数字能不能复现。

官方承认的方向，和官方公布的数字，是一回事吗？

这条要和第13章那道32000 token中文预算的研究题分开放，两个问题问的不是同一件事。第13章问的是容量：同样32000个token，中文文本大概能装下多少个汉字，这个数字可以自己拿一个通用分词器估算出来。这一节问的是准确率：中文工单让Jev去判断，答对的比例会不会比英文工单低、低多少——这个数字没有一个分词器能帮你估，只能真的拿一批有答案的中文数据去跑一遍才知道。

同一批查无实据里，还有一条形状不太一样：sol和luna到底属于GPT-5.6还是GPT-6这一代，不是没人研究，是这件事本身没有一个公开对应关系。媒体文章里两种写法都出现过，互相冲突；官方自己从发布到现在，只用sol、luna这样的小写短名称呼它们，没有确认过任何一个具体的代次归属。读者今天想判断sol、luna到底算多先进的一代，没有官方口径可以直接引用。

十五条查完，能不能说这是一场营销？

把BRIEF清点的十条摆进两张表，逐条给出今天的状态：

后五条状态如下：

另外五条来自那份研究材料自己挑出的「最该写进这个模型没告诉你的事」——1.19那道加法归到第1章，四项workflow全部告负归到这一章第3节，444.6倍的分母归到第12、16章，不能说不知道归到第10章，零样本值多少条标注归到第16章。五条里，四条已经被材料自己推翻，一条（全部告负）本章第一次用官方原始数据把它坐实，没有一条停留在原来的立场判断上，全部落到了具体查哪、具体算什么这一层。

第18章 真的把它接上：从curl到生产

前面十七章教的是怎么判断一份材料、一张评测表、一个模型值不值得信——这一章换一个问题：真的要把Jev接进一套系统，代码长什么样。从会判断到会用，中间差的是一整层接入细节：官方接口怎么发、两个官方SDK怎么写、四个第三方平台各自把字段名改成了什么、生产环境要守哪几条硬规矩。这一章的代码取自原始文档，字段名、类名、参数结构逐一核对；例子里跟上一段重复、或者前面章节已经讲过的部分，用「……」省略掉，省略的只是重复内容，没有一处字段名或者逻辑被改写。

这一级要造的是一台真实请求构造器：输入一段业务场景描述，吐出一份能直接发出去的请求体——questions怎么拆、criteria怎么写、用哪个SDK、部署到生产前要检查哪几条。前面十七级教会你怎么审视别人发布的数字，这一级教你自己动手，把判断力真的接成一套能跑的系统。

一次POST请求，请求头和错误码分别长什么样？

第3章已经拆过state/model/questions这三个字段各自装什么、Noul/Choice/Score各自怎么读。这一节接上另一半：这些字段要装进一个真正能跑起来的HTTP请求，请求头、认证方式、出错时的状态码，长什么样。

这段命令原样能跑：地址是POST https://api.typesafe.ai/v1/systemone，认证走标准的Bearer token，写在Authorization请求头里；Content-Type是application/json。第3章已经拆过department、frustration、is_urgent这几个问题各自怎么读，这里不重复。

出错时的状态码，文档写明四种：401（认证失败）、422（请求体不合法）、429（超出速率限制）、以及一个不常见的529 Overloaded——HTTP标准状态码里没有529，这是TypeSafe自己定义的一个，专门表示服务本身过载，不是你的请求有问题。速率限制是250,000 token每秒、1,200次请求每分钟，超限返回429，官方原话写明「限制会随时无预警变动」，不能把这两个数字写死当成长期不变的配额。

两个官方SDK，写法差在哪？

先看Python SDK：pip install typesafe-sdk，默认读环境变量TYPESAFE_API_KEY。

异步客户端的例子，取值换了另一套访问器：

JS/TS SDK，npm install @typesafe-ai/sdk，需要Node 20以上：

同一个模型，换个平台，字段名怎么变？

OpenRouter是第三方托管，模型slug是typesafe/jev-1.13或~typesafe/jev-latest，定价$0.042/M输入、$0/M输出，32K context——但它不走大多数人熟悉的chat completions接口，是一个还在alpha阶段的decisions端点：POST https://openrouter.ai/api/alpha/decisions。社区客户端jev-client的说明写得很直接：「Rejected by /chat/completions by design」——不能把Jev当成一个普通chat模型去调，用错端点会被直接拒绝。这个端点形状是从社区实现反推出来的，OpenRouter官方文档目前还没有一页正式说明它。

Cloudflare Workers AI走的又是另一种形状，模型ID是typesafe/jev，绑定调用是这样：

Cloudflare的REST接口又不一样：questions被包在一层input里，model留在外层，跟官方API那种字段平铺的结构不一样。

Vercel AI SDK需要AI SDK 7.0.105以上，单问题调用长这样：

置信度分流的完整实现，能看到confidence缺失时的失败安全写法：

注意最后这个?? 0：如果confidence这层元数据因为某种原因缺失，代码会让这个值退化成0，直接触发人工复核分支——既不会崩溃，也不会假装置信度很高。Vercel自带的mock测试用例里，专门测过这一种情况——这是刻意设计的失败安全默认值。

LangChain的两个中间件，路由和把关各管什么？

装langchain-typesafe，设好TYPESAFE_API_KEY环境变量。最基础的调用：

更值得关注的是两个中间件，按任务难度把请求分流给便宜或强力的模型：

Auto Mode守门中间件，在执行危险动作之前先拦一道：

LangChain这篇博客的论点很关键：像Claude Code、Codex、Cursor这类编码工具，一直都有「执行前判定危险动作」的分类器，只是那一步过去一直锁在各家闭源产品内部；现在有了便宜又快的判断模型，这个模式可以被搬到任何自己搭的agent上，不必依赖某个封闭产品自带的把关能力。

Pydantic AI：为什么写一个类型，就不用写questions？

Enum映射Choice的例子：

bool映射Noul的例子：

IntEnum映射Score的例子：

这套设计还有一层没有在代码示例里直接体现、但值得留意的性质：同一份agent代码可以在Jev和普通LLM之间切换，一旦遇到Jev的三种问法表达不了的参数类型，Pydantic AI会自动退回到普通LLM去处理。这意味着换掉Jev这件事的技术代价，比接口格式本身看起来的要小——真正稀缺的不是「能不能换一个兼容的接口」，是「换掉之后还有没有同等能力的替代品」，这是另一个需要单独核实的问题，这一节只确认接入层面这一件事。

一个模糊判断，怎么拆成几个可观察信号？

官方设计指南里，「拆解问题」这一步被单独强调：把最直接、最狭窄、最具体、最原子化的问题问出来，把复杂或定义不清的问题拆成几个各自只判断一个性质的问题。官方原话很重——这可能是整份指南里最重要的一条：宽泛的问题会把好几个判断藏在一个答案背后；原子化的问题把这些判断分别暴露出来，让你能在代码里分别检查、调优、组合它们。

官方给的垃圾邮件例子最直观。拆前，一个笼统的问题：

拆后，1个问题变成6个，每个都指向state里的一处具体路径——是否索要密码等凭据、是否宣称意外中奖或收到报酬、主题或正文是否制造时间紧迫感、发件人显示名和邮箱域名是否对不上、链接域名和发件人组织是否对不上、链接文字和链接实际指向是否被伪装：

官方还给了三条更具体的原则。第一条，遇到不可避免需要综合判断的地方，拆成两个各自单独成立的字面问题，在代码里合并：「Where interpretation is unavoidable, split it into two literal questions and combine them in code.」

第二条，数数时在代码里逐个遍历候选、各问一遍、自己求和——「iterate in code over the candidates and ask one question for each, then add up the answers yourself」：

第三条是官方SKILL.md里最凝练的一句：「Extraction is a judgment, so give it to the model. Arithmetic is not, so keep it in code.」——提取信息是一种判断，交给模型；算术不是判断，留在代码里。这三条合起来，就是这一节标题问的那句话的完整答案：先把模糊判断拆成各自独立的信号，再把信号本身的提取交给模型，把信号之间的合并、计数、算术，留给代码。

生产环境要守哪几条硬规矩？

第3章已经讲过一条：生产环境要写死具体版本号，不要用会漂移的jev-latest这类别名——别名指向的模型换掉之后，针对某个版本调好的置信阈值会跟着失效，而且不会报任何错误提醒你这件事发生了。这一节不重复推导，只补两条第3章没有覆盖的规矩。

第一条，速率限制返回429之后该怎么处理：官方接口把429和一个retry-after字段配在一起返回，代码里应该读这个字段、按它给出的时间等待之后重试，而不是立刻重发或者固定等待一个写死的秒数——429本身就说明短时间内的重试大概率还会撞上同一个限制。

第二条，state要保持小而干净：第13章已经证明过context rot这条机制——state里混进跟当前判断无关的内容，会拖累准确率，跟账单没有关系，纯粹是判断质量的代价。这一节要补的是生产环境里具体怎么做到这条：不要图省事把整段历史记录原样塞进state，每次请求前先筛一遍，只留下这次判断真正用得上的部分。

第三条，日志该记什么：一次请求真正值得留档的是{state, questions, probabilities}这个三元组——可复现、可追溯，出了问题能回头核对当时喂进去的到底是什么。但这个三元组里没有任何「为什么」：模型不生成解释性文字，probabilities告诉你它给出的分布是什么，不告诉你它为什么给出这个分布。想在事后追问「这次为什么判断成这样」，这个三元组答不出来，只能靠换一批问题重新问一遍来间接摸清楚。

state不被当敌意处理，九条反模式怎么防？

官方原话说得很直接：「State is data, and jev-1.13 does not treat it as hostile by default.」——state里的内容不会被默认当成敌意内容处理。这意味着，任何把用户输入或者抓取到的内容不加处理就塞进state的场景，都有被注入攻击的风险：一段精心构造的用户消息，完全可能在state里悄悄改写问题的判断方向。这条限制官方写进了自己的九条反模式列表，编号第6条，官方给出的对策只有一句——写precise的prompt，上线前专门测边界情况，没有更强的技术手段能替你把这道口子堵上。

第2条数学与数字、第9条生成，也各有边界。官方明确提醒：不要拿score输出去反推两个等级之间的精确数值——score能用来过阈值，不能反推出背后那个具体的数。第9条生成的边界最简单：Jev压根不是训练来生成文字的，需要一段解释、一段摘要、一段对话回复的场景，该换生成式模型，不必勉强用Jev凑。

第19章 终极闯关

这一章不教新概念。前面十八级台阶，每一级单独拿出来你可能都答得上——但真正的问题是，当材料自己不会告诉你「这道题该用第几章」的时候，你还认不认得出该伸手去拿哪一件工具。这一章要做的，就是把提示去掉，混着问。

这一级要把审计仪真正跑一遍：找一份从没在这本书里出现过的新材料，把前面十八级攒出来的检查逐条过一遍，看这套工具是不是真能立在一份从没见过的材料上，而不只是刚好适配Jev这一个例子。

十八章都学过一遍，就等于能审完一份新材料吗？

先来两道热身，材料是虚构的，方法不是。

混着问的时候，怎么认出这道题该翻哪一章？

出声示范一遍：Northlake的发布页写着「Corvus-1处理一份合同审阅只要0.6秒，比人工审阅快得多」。我先问这句话报的是倍数还是绝对值——是绝对值，还轮不到翻第12章那本分母的账。我再问这句话有没有说清楚比什么快——提到了人工审阅，但人工审阅本身要多久、错多少，材料没说。这就把我引向第15章：想知道一个又快又便宜的判断值不值得换掉人工，得先知道被换掉的那一套流程自己的成本和准确率，不能只看新模型这一侧亮出来的数字。

这个动作有个名字：先问这句话本身在报的是哪一类数字——倍数、绝对值、还是通过率——再决定翻第几章，不是看到快、便宜、准这些字眼就条件反射去翻同一章。

检查全部过关，轮到你自己下场答辩，你答得上来吗？

查无实据和真未解，隔着一道什么样的界限？