不写字的模型：Jev、校准概率与“智能 if 语句”

先看一段每天都在发生的调用：代码需要知道一条工单该转给谁。它手里有一支最擅长写文章的模型，于是我们写提示词、要求“只输出 JSON”、解析、校验、重试，还要防它偶尔多写一句“好的，我先帮你分类一下”。

结构化输出的出现缓解了这段流程的痛，但没有改变它的性质：被调用的仍然是一个为生成而训练的模型，只是被临时要求去做判断。判断要的是值，生成给的是文本，两者之间必须有人做翻译。

更麻烦的是概率。判断类任务的产出本该附带一个诚实的把握程度——这条工单归到技术组，是八成确定还是五五开？通用大模型即使被明确要求给出置信度，也常常过度自信、且前后不一致。一个任务它 95% 的时候能做对，却从不说自己什么时候落在另外的 5% 里，那它就没有真正被自动化。

TypeSafe 的出发点正是这句反问：模型在对话上超人类已经好几年了，自动化到底在哪儿。创始人 Diogo Almeida 是前 OpenAI 研究员、InstructGPT 论文的共同一作，参与过 RLHF 那套让模型学会遵循指令的方法。创业两年后的答案不是“更聪明的模型”，而是“换一个接口”。

一、一个被将就了很久的接口

把三代训练目标并排放在一起，接口的差异就看得很清楚：

Jev 用的是第三种，TypeSafe 称之为“面向校准决策的强化学习”（Reinforcement Learning for Calibrated Decisions）。校准的含义是：当模型在大量预测中声称自己有 90% 的把握时，其中大约 90% 确实是对的。这不是对单次答案的保证，但它给下游代码提供了一个可以设阈值的量。

名字取自 19 世纪经济学家 William Stanley Jevons，对应杰文斯悖论——蒸汽机效率提升、煤炭变便宜之后，煤炭的总消耗反而上升。厂商押注的是同一件事：当一次判断便宜到接近零，它会被装进过去根本不会调用 AI 的地方。

二、机制：三种原语与并行求值

一次调用只有两个输入。state 是待判断的材料，可以是字符串，也可以是 JSON 对象或数组——这一点比想象中实用：不必把状态揉成一段自然语言，直接把字段摊开写进去，然后在问题里用反引号指名引用某个字段。questions 是一组带类型的问题，每个问题由你自己起一个 id。

题型只有三种，覆盖了绝大多数“判断”的形状。

几个容易误读的边界。Noul 返回的是“是”的概率，0.5 表示模型判不出来，而不是“中等程度”；要度量程度，得改用 Score。Choice 建议始终留一个 other 选项——不给退路，模型也只能硬选一个。Score 返回的是概率加权分，可以落在两档之间，比如 1.3。

三个工程性质值得单独说：

• 并行且独立。同一次请求里的问题各自对着同一份 state 求值，互不成为对方的上下文。官方给出的实测是：把 13 个问题打包成一次调用，比拆成 13 次串行调用便宜 11.5 倍、快 9.6 倍。不过“独立”只到接口层面为止：这些答案出自同一个网络对同一份材料的判断，误差完全可能相关——把并行的多个答案当作彼此独立的证据来用，是要小心的。
• 类型安全。答案被约束在你声明的选项集合或刻度之内，模型不会返回集合外的值。官方说这是数学上的保证，而非概率上的。
• 会拆题才是正确用法。“分析这条消息并给出最佳处理方案”是错的——那需要慢推理。正确做法是问三个窄问题：属于哪一类、有多紧急、情绪有多糟，再把三个答案在代码里加权。

下面这段请求把三种题型混在一次调用里，场景取自金融文本研究：判断一条互动易问答是否涉及研发、属于哪个主题、管理层回答得有多具体。

{
  "model": "jev-1.13.0",
  "state": {
    "question": "公司上半年研发投入同比变化如何？",
    "answer": "报告期内公司持续加大研发投入，研发费用同比增长 23.6%……"
  },
  "questions": {
    "is_rd_related": {
      "type": "noul",
      "instructions": "该问答是否涉及研发投入或技术进展？",
      "criteria": {
        "true": "明确提到研发费用、研发人员、技术突破或专利申请",
        "false": "只涉及业绩、市场或常规经营事项"
      }
    },
    "topic": {
      "type": "choice",
      "instructions": "该问答主要属于哪个主题？",
      "criteria": {
        "rd": "研发投入、技术进展、专利",
        "performance": "业绩、营收、利润",
        "risk": "风险、诉讼、监管",
        "other": "以上都不是"
      }
    },
    "specificity": {
      "type": "score",
      "instructions": "管理层的回答具体到什么程度",
      "criteria": ["泛泛而谈", "提及具体指标", "给出具体数值或时间窗口"]
    }
  }
}

注意每个问题的 instructions 都要写完整。问题 id 只是给你的代码定位答案用的，不会发给模型——一个叫 refund_requested 的键名，对模型来说什么也没说。

三、置信度才是真正的接口

三种答案里，我认为最值得关注的是 confidence。它不是一个独立预测出来的数字，而是把概率分布的形状压成一个 0 到 1 的标量：概率全部集中在一个选项上就接近 1，摊得越平越低。

官方文档里的例子很能说明问题：一张工单被归到 billing 的概率是 0.84，看着很高，但 confidence 只有 0.596——因为 technical 还分走了 0.15，分布并不够尖。

把这个数字接进路由逻辑，整套写法才立得住。参考实现是三段式：低置信不自动执行，中置信谨慎执行，高置信交给确定性代码直接分支。

from typesafe_sdk import Choice, TypeSafeClient

client = TypeSafeClient()

response = client.system_one(
    state=ticket_text,
    questions={
        "action": Choice(
            instructions="这条消息在让客服做什么？",
            criteria={
                "query": "只是查询信息，读操作",
                "change": "要求修改账户或订单，可逆写操作",
                "refund": "要求退款，不可逆操作",
            },
        ),
    },
)

action = response.answers["action"]

if action.confidence < 0.5:
    route_to_human(ticket_text)            # 模型说它判不出来
elif action.choice == "query":
    handle_automatically(ticket_text)      # 读操作，容错高，可以放宽
elif action.confidence > 0.9:
    confirm_then_execute(ticket_text)      # 写操作，只有高置信才自动
else:
    ask_user_to_confirm(ticket_text)

阈值不是固定值。同一个系统里，读操作的容错高、可以放宽；写操作与不可逆操作必须收紧。文档给的原则很朴素：先在保守的阈值上跑，用自己的数据实测，再逐步调整。

置信度有一个必须知道的盲区。它只反映“概率分布是否集中”，不反映“判定规则是否缺失”。独立评测者 Pawel Huryn 用 50 份多语种发票做过检验：在只给类别名、不给定义时，模型的每一次错误都落在 0.80 置信度以下，用 0.80 作自动通过线能拦住全部错误；但当他递给模型一条从未告知的业务规则（重复扣费应转客服而非账单组），24 条里错了 19 条，其中 15 条的置信度高于 0.90。高置信度地做错，比低置信度更危险。

结论很直接：业务规则必须写进每一次请求，规则不会在调用之间被“记住”。他还试过用标注样例代替规则，效果反而更差（13/24）。这个模型的假设是“你已经把判定标准写清楚了”，它不替你补。

四、把评测数字放回条件里读

官方给出的核心数字很大：在自家工作流评测上，比前沿模型快 193.6 倍、便宜 444.6 倍。这些数字是真的，但它们有明确的条件。

先看准确率那一列：Jev 与中游前沿模型打平，落后最强的那两个约五个百分点。更关键的一点藏在方法里——这些评测的参考答案不是人工标注，而是取两个最强模型预测的平均值。所以 67.8% 的准确含义是“与参考模型的一致率”，不是“正确率”。厂商自己也标注了几处偏差：工作流由自家模型能力团队设计，参考模型偏向 OpenAI 与 Anthropic，这些倍数代表现实收益偏高的那一段。

再看独立复现。Pawel Huryn 把厂商展示过的发票分类任务刻意加难：50 份文档、6 种发票类型、10 种语言，其中 32 份埋了误导性线索（已发货的货物却写着 PROFORMA INVOICE，不是付款请求却叫 INVOICE SUMMARY）。结果是 Jev 50/50，每千次判断 0.025 美元；Claude Haiku 4.5 同样 50/50，两个可本地部署的开源模型 48/50，成本约是 Jev 的 1.2 到 1.25 倍。

所以更严谨的表述是：Jev 赢在成本、延迟和“可设阈值”这三件事上，不在绝对准确率上。与可本地运行的 8B 级模型相比，它大约便宜 20%，单次还慢 90 毫秒左右——真正的优势是能把多问题并行，并把概率作为一等输出。

五、它做不到什么

边界相当清楚，而且官方自己列了出来。

• 不生成。写回复、写总结、写代码、解释理由，都不行。它没有理由输出，也就没有可供审计的推理链。
• 不做算术。数数、比较日期、多步推导都是已知弱项，这些应该留在代码里。发票核对这类需要“找到金额、定位子项、做加法、再比较”的任务，正是它最吃亏的场景。
• 不擅长否定与言外之意。它回答的是你写下的问题，不是你心里想的问题，措辞需要具体。
• 只吃文本。图片、音频、视频都不支持。
• 规模有限制。上下文预算约 64K token，其中 state 加最长的一个问题需控制在约 32K 以内（聚合网关的模型页标注为 32K，以你实际使用的版本为准）；Choice 最多 255 个选项，Score 2 到 10 档。
• 中文偏弱。官方明确说训练以英语为主，中日韩文字能用但准确率更低。

对做中文研究的人来说，最后一条最要紧。任何中文语料上的应用，都必须先在你已经人工标注的样本上验证准确率与置信度的关系，再决定是否上量。厂商的英文基准不能外推。

还有一条要写进方法部分：模型不公开架构，也没有论文。TypeSafe 把 RLCD 描述到高层，但不足以复现。第三方观察者的分歧也在这里——一方认为它只是把编码器分类包装成了新品类，另一方认为接口设计、概率校准与并行采样本身就是工程价值。两种看法可以同时成立。

六、怎么开始：三条路径与两个坑

上手成本很低。按投入从小到大，有三条路。

1. 先在 Playground 里试

   打开控制台的 Playground，把一段文本贴进 state，加几个问题，直接看返回。判断一个任务适不适合交给它，这一步花十分钟就够。

2. 再决定走哪条通道

   官方 API 目前是早期访问制：官网留邮箱排队，端点是 POST https://api.typesafe.ai/v1/systemone，社区反馈放号速度尚可。不想排队的话，OpenRouter 已上架 typesafe/jev-latest，但它必须发到 Decisions 端点，不能当普通对话模型调用。另有 Vercel AI Gateway 与 Cloudflare Workers AI 两条通道。

3. 写代码时用 SDK

   Python 安装 typesafe-sdk（需 3.10 以上），客户端会从环境变量 TYPESAFE_API_KEY 读取密钥，比硬编码安全。想让编码助手帮你接入，官方也提供了对应的 agent skill。

坑一：别用浮动别名。jev-latest 会随新版本前移，官方明说别名移动之后答案可能变化。你按某一版调好的阈值会随之漂移。生产环境和研究项目都应钉住具体版本号，并把响应里返回的版本 id 记进日志。

坑二：规则必须写在每一次请求里。这一点在第三节已经说过，但值得重复——它是目前最容易踩、也最难被发现的错误来源。

名字相近的东西也值得一并澄清：System One Adapter 是让其它大模型模拟同款接口的对照工具，不是 Jev 的开源权重；官方提供的 agent skill 只是给编码助手的接入说明；GitHub 上的 OpenJev 项目与 TypeSafe 没有关系。若用 Adapter 做对照实验，方法部分要写清它模拟的是接口形状，不是同源模型。

一份可以直接照做的起步清单：

1. 选任务。挑一个你已经在做、频率足够高的判断任务，把它拆写成三到五个窄问题。
2. 写选项。每个问题写清楚选项或等级的含义；边界模糊时，补一句它与相邻选项的差别。
3. 带规则。每条选项描述里都要包含业务规则，不要指望模型“知道”你这里的规矩。
4. 小样本校准。先设保守阈值跑 50 到 100 条，人工核对，算准确率与置信度的关系。
5. 再上量。校准成立后才放量，同时把每次调用的输入、答案、置信度与版本号留档。

上线之后评什么，也值得先想好。只看准确率容易误导：一个只自动处理三成流量、准确率 95% 的系统，未必好过覆盖九成流量、准确率 85% 的版本。至少同时记两个数——自动化覆盖率（自动处理数除以总数）与自动处理里出错的比例，再配上 P95 延迟和总成本。还有一笔容易算反的账：把 Jev 叠在原有的大模型调用之上而不替换，总成本只会更高；它省下的是被替代掉的那次调用，不是白捡的。

七、对做实证研究的人意味着什么

对做金融实证的人来说，这套接口补上的恰好是研究里最费人力的一环：把非结构化文本变成可以进回归的变量。

传统做法有两条路，都不轻松。一是人工编码，几百条还行，几万条就要靠助研，成本高、一致性还难保证。二是自己训练一个分类器，需要标注数据、需要训练，而且换一个研究问题就得重来一遍。Jev 占据的是中间地带：它像分类器一样返回受限的概率分布，但换任务只需要换一段自然语言写成的判定标准，不需要标注、不需要训练。

具体到数据。站内数据平台上那批语料——互动易问答、股吧帖子、上市企业年报、专利摘要、企业工商信息——都可以先用这种方式打上语义列，再用 SQL 与面板回归消费。比如互动易提问是否涉及研发投入、股吧帖子的情绪方向与是否引战、年报里是否新增了风险提示条款、专利摘要属于哪个技术领域。

还有一种更轻量的用法是核验。把一段结论和一段证据一起放进 state，问模型“证据是否支撑结论”，三个选项：支撑、矛盾、证据不足。对研究者，它可以直接用来核对由 AI 生成的文献综述与原文是否一致；对教学，这是演示“幻觉检测”最短的一条路径。注意“证据不足”和“矛盾”是两个答案——证据没说，不等于证据反对，混用这两者会把核验变成误判。

第二个好处是概率本身就是变量。通用模型给出的情绪打分常常过度自信，直接作为连续变量进入回归会污染系数；而一个经过校准的概率分布，可以更放心地当作连续因子使用，或者在构造模糊性（ambiguity）代理变量时作为原始输入。这与本站《可复现的文本自变量》里的关切是一致的：文本变量要稳定、可复现、可追溯。

第三个好处是低置信样本会自动浮出来。这批样本恰好就是边界案例，把它们交给人复核，既提高数据质量，也顺带得到一组人工与模型的一致率，可以直接作为稳健性检验的材料。

还有一条纪律值得单独立住：模型判断的是语义，不是事实与权限。客服场景里，“识别出用户要求退款”与“系统应当退款”是两件事，后者要靠代码去核验订单与规则。放进研究语境同样成立——年报里出现了“风险”这个词，不等于公司发生了风险事件；语义列能告诉你文本说了什么，不能替你确认文本说的是真的。凡是把“文本提及”直接当作“事件发生”来用的变量，都需要另找一个独立来源交叉验证。

但要在论文里站得住，方法部分必须交代清楚：使用的具体版本号与调用日期、每个判定问题的原文、选项定义、置信度阈值的设定依据，以及在你自有样本上的校准曲线。浮动别名、没有留档的判定标准、只报准确率不报校准——这三件事里任何一件，都会让审稿人有理由质疑结果的复现性。

同样的逻辑也适用于教学。概率校准、置信度阈值、把模糊判断写成可执行规则，这些概念在纯生成式的框架里很难讲清楚，而在一个能跑、能改、单次成本近乎为零的接口上，学生花二十分钟就能亲手验一遍——这是课程里少见的、可以把“模型不确定性”从名词变成可操作对象的例子。

结语

Jev 不是一个更聪明的大模型，而是一个更难被写错的接口。它把“判断”从“生成”里拆出来，代价是彻底放弃写的能力，换来的是百毫秒级的延迟、几乎为零的输出成本，以及一个可以被代码设阈值的概率。

值得动手的部分也许不在它本身，而在它逼出来的那个问题：你手上那些“每天判一遍”的活，有多少其实从来不需要语言？把它们列出来，才知道什么样的活儿该交给哪一种智能。