摘要你有没有写过这样的代码让大模型判断一条工单是否紧急于是你在 prompt 里写「请只返回 JSON格式如下……」然后拿到一堆带 json 标记、夹着「好的我认为……」的文字再用正则去抠、用try/except兜底、失败就重试一遍。Jev 想干掉的就是这一步。它是 TypeSafe 的旗舰模型也是第一个所谓System One模型输入是「状态state 一组类型化的问题questions」输出是「类型化的答案 概率分布」。不生成文本也不需要解析。本文带你搞清楚Jev 是什么、和 ChatGPT 这类大模型差在哪、三种原语怎么用、什么场景该交给它、它给出的概率凭什么可信最后用一个完整的中文实战案例收尾。关键词Jev、TypeSafe、System One、RLCD、概率校准、AI Agent、LLM 工程化TL;DR太长不看Jev 是 TypeSafe 的 System One 决策模型。三种原语Choice、Score、Noul。与 LLM 本质区别不生成文本只出判断。适用场景路由、排序、批量分流等程序决策。概率可信前提RLCD 校准需自测分布。心法模型管语义代码管规则。一、先说痛点我们到底在为什么买单传统 LLM 是为「人类阅读」而生的——它写出来的东西是给人看的。可一旦代码需要做判断流程就变成了这样中间这一步「把生成的文字再解析回程序能依赖的形式」既慢又脆。慢在要多生成一堆废话 token脆在格式随时可能崩多一个逗号、多一句寒暄、少一个引号你的json.loads就炸了。于是工程上涌现出各种补丁JSON Mode、function calling、结构化输出约束、重试兜底、双模型校验……本质上都是在给「生成」这一步打补丁。Jev 的思路更直接把生成这一步整个砍掉。它像 LLM 一样能读懂自然语言但只返回你问的那几个数而且每个数都带着概率。二、Jev 是什么一句话定义Jev 是 TypeSafe 的旗舰模型也是第一个 System One 模型——输入是 state 加一组类型化的问题输出是类型化的答案加概率分布。没有文本生成也没有解析。用公式表示就是Jev(state, questions) → { answer₁: (value₁, p₁), answer₂: (value₂, p₂), … }这里的state就是你要判断的那段文本可以是一句话、一段对话、一个 JSON、一个文本数组questions是你预先定义好的一组带类型的问题。两个必须知道的边界目前只接受文本输入——字符串、JSON、文本数组都行图像/音频/视频暂不支持。名字借自《思考快与慢》的「系统 1」——取「快速直觉判断」这个意象不是说它在科学上复现了人类思考。别过度解读这个名字。三、和聊天大模型到底差在哪这是最容易被问到的问题官方给了个非常清晰的对比表维度聊天大模型LLMJevSystem One训练目标生成讨人喜欢的回复RLHF校准决策RLCD概率对齐真实结果输出一段自由文本类型化取值 概率分布由你的问题定义会做什么写作、代码、解释推理只做判断不写回复、不解释推理适合谁消费人程序分支、排序、路由关键差异在第二行——训练目标。RLHF人类反馈强化学习目标是让回复更讨人喜欢产出是文本。RLVR可验证奖励强化学习目标是让推理更准产出是会思考但更慢更贵的模型。RLCD面向校准决策的强化学习Jev 走的第三条路——训练模型返回决策和校准概率而不是文本。一句话总结LLM 是给写给人看的内容的Jev 是给程序做分支用的。它不会给你写周报也不会给你解释推理过程。它就是个高速、带概率的判断器。四、三种原语就是它的全部词汇Jev 的全部表达能力就三个原语primitive。记住这三个你就掌握了它的 90%。原语问题类型示例输出Choice从选项中选一个choice: billing 各选项概率Score按有序标准打分score: 1.40平静1沮丧2非常沮丧Noul某陈述是否为真noul: 0.954.1 Choice —— 是哪一类从一组互斥的选项里挑一个返回选中的标签 每个选项的概率。criteria是「选项 key → 选项描述」的字典。选项 key 建议用英文描述用中文这样代码里判断分支时不会被中文 key 坑到编码问题。4.2 Score —— 打几分按一组有序的标准打分返回的是概率加权后的期望值所以会出现 1.4 这种小数而不是硬选一档。注意criteria这里传的是列表有序不是字典。下标 0/1/2 对应三档最终score Σ(下标 × 概率)。比如概率分布是{0: 0.05, 1: 0.26, 2: 0.69}那么这个设计很妙——它把「模棱两可」诚实地表达成了 1.64而不是强行归到某一档。4.3 Noul —— 是不是判断某个陈述是否为真返回一个 0~1 的概率值。noul这个名字挺怪官方的解释是它代表一个「是/否 不确定度」的量。不确定性直接体现在数值靠近 0.5——0.95 是很确定0.55 是基本没谱。4.4 一次调用三种混用核心体验这是 System One 最值得体验的一点三种问题可以在一次调用里混用每个问题并行、相互独立地对照同一个 state 求值。带来两个直接好处加问题几乎不增加延迟——不是串行地问三个问题是一次往返问完。没有长上下文「越读越糊」的问题——每个问题独立看同一份 state不存在多轮对话那种注意力稀释。五、三分钟上手5.1 环境准备要求 Python ≥ 3.10注意一个坑安装包名是typesafe-sdkPython 导入名是typesafe_sdk横杠 vs 下划线。然后配置 API Key不要写进代码或 Notebook5.2 最快的方式一行 curl不想装 SDK直接发 HTTP 也行也可以直接去官方 Playground 粘贴文本试连登录都省了。5.3 Python SDK一次调用问三个问题from typesafe_sdk import Jev 初始化客户端传入你的 API Key建议从环境变量读取不要硬编码 jev Jev(api_keyYOUR_API_KEY) 定义要判断的文本state state 我的订单已经付款三天了但一直显示待发货客服也没人理我要投诉 定义三个类型化的问题questions questions [ { key: urgency, # 问题标识用于在结果中取值 type: score, # 类型score打分 criteria: [ # 有序标准列表下标 0/1/2 对应三档 0常规咨询可稍后处理, 1需要尽快处理但不危及安全, 2紧急涉及资金或权益受损 ] }, { key: category, # 问题标识 type: choice, # 类型choice分类 criteria: { # 选项 key → 描述key 用英文描述用中文 refund: 客户要求退款, complaint: 客户投诉服务质量, inquiry: 普通咨询可自动回复 } }, { key: needs_human, # 问题标识 type: noul, # 类型noul是非判断 criteria: 这条消息是否需要人工客服介入 # 陈述句返回 0~1 概率 } ] 一次调用问完三个问题返回带概率的结果 resp jev.ask( statestate, # 要判断的文本 questionsquestions # 类型化问题列表 ) 打印结果每个答案都带概率 print(f紧急度 {resp[urgency].score:.2f}) print(f类别 {resp[category].choice} (概率: {resp[category].probabilities})) print(f转人工 {resp[needs_human].noul:.2f})5.4 读结果一发请求三份带概率的答案。这就是 System One 的核心体验。拿到手之后你的代码可以直接这么写干净、可测、不需要任何正则。六、提问纪律原子性最重要的工程经验这是整份教程里我认为最有价值的一条每个问题只问一件专家几秒内能下结论的事原子判断。复杂判断拆成多个独立问题在代码里用你自己的逻辑加权组合。这样做的好处是优先级变了只改代码里的系数不用改提示词、不用重跑评测。反例一个问题问两件事比如你想问「该不该给这条工单升级到人工」这是个不合格的问题。它其实混了两个独立判断这个问题严重不严重→Score或Noul当前的自动流程能不能处理→Noul或Choice如果塞进一个noul里问任一因素翻转都会污染概率——你拿到 0.6 的时候根本不知道是「不严重但要升级」还是「严重但能自动处理」。正例拆开问代码里组合模型管语义代码管规则。这句话是 Jev 用法的心法。七、场景地图什么活儿适合交给 Jev官方 Use Case Map 归纳了五大类用法用法人话解释自动化软件里的语义判断代码管流程Jev 出判断可后台跑上百万次不用人盯实时应用~150ms 出答案快到能进游戏和用户界面大数据上的批量判断同一个判断跑一百万次成本约为大模型调用的百分之一万能校验器查幻觉、查引用是否支撑结论、查越狱与违规话术给大模型当管家决定哪条请求发给哪个模型拦住注入与泄露映射到三种原语上常见的判断形态有这七种是哪一类意图 / 主题 / 风险类型 →Choice有没有垃圾 / 欺诈 / 紧迫 / 敏感信息 →Noul打几分严重度 / 相关性 / 质量 →Score该走哪条路工具选择 / 人工升级 / 队列分派 →Choice 代码分支找最相关的语义搜索 / RAG 上下文 / 排序 → 检索与排序组合核对有没有错引用支持 / 策略违规 →Noul逐条校验抽特征或字段购买意图喂预测模型 / 从文本回填表单 →Score/Choice两个边界别越界几乎所有场景都该配「不确定就转人工」。法务、理赔、招聘淘汰这类高风险终审不能全交给它。需要长篇写作或开放推理时转交大模型。更合理的架构是Jev 在前面快速定「该走哪条路」大模型在后面做重活。八、概率凭什么可信RLCD 与校准这是 Jev 最核心的卖点也是最容易被误用的地方。校准是什么意思这是 Jev 最核心的卖点也是最容易被误用的地方。校准是什么意思校准是按一组预测来衡量的不是按单次。给 0.8 概率的事件长期发生频率应该接近 80%。它不保证任何单次预测正确。换成 Jev 官方的表述就是三句话被赋予0.2概率的结果应该大约在20%的情况下发生被赋予0.8概率的结果应该大约在80%的情况下发生被赋予1.0概率的结果应该在100%的情况下发生。注意每一句的宾语都是「一组预测」。校准描述的是统计规律不是对某一条答案的担保。给你0.8的那条就是有五分之一的可能会错——而且你无从知道错的是哪一条。这一点怎么强调都不过分如果你把noul 0.93理解成「这条判断一定对」那你后面所有的阈值设计都会建立在一个错误的地基上。为什么普通 LLM 给不出这个数字同样是预训练模型改造出来的三条训练路线追求的东西完全不同方法全称它优化什么产物RLHF基于人类反馈的强化学习生成人们更偏好的回答聊天机器人RLVR可验证奖励的强化学习能做对可验证的题目数学、代码推理模型更慢更贵RLCD面向校准决策的强化学习返回决策 校准的概率Jev 这类决策模型RLHF 的问题不在于它不好而在于它的目标函数和你要的东西不一致RLHF 教模型说人们偏好的话。这个目标对聊天机器人很有效但它也可能奖励谄媚行为和听起来自信的幻觉。偏好优化还会带来模式丢弃mode dropping模型学会偏好某种特定风格比如「听话、有礼貌、给出确定结论」同时把其他可能输出的概率压下去。分布被人为收窄了剩下的那个概率值自然也就不再对应真实世界的频率。所以官方文档里有一句非常适合拿来当这一节题眼的话一个输出可以对人很有说服力却不足以可靠地支撑无人值守的自动化。人类偏好和机器可信度是不同的优化目标。顺带纠正一个常见误解让 LLM 输出 JSON、加上confidence: 0.85这个字段不等于拿到了校准概率。那只是模型「写」出来的一个数字没有任何训练目标逼着它为这个数字负责。JSON 约束不等于概率校准。用 20 条数据直观感受一下下面这组是构造出来的示意数据不是 API 实测只用来把概念讲清楚。假设我们对 20 条工单问了同一个是非问题「客户是否在要求退款」并记录下每条的预测概率和真实结果1 是0 否# (预测概率, 实际结果) 0.97→1 0.94→1 0.92→1 0.91→1 # 高分区4 条全中 0.88→1 0.84→1 0.81→1 0.76→1 0.71→0 # 有一条翻车 0.66→1 0.61→1 0.57→0 0.48→1 0.43→0 0.38→0 0.33→0 # 0.48 这条猜错了方向 0.22→0 0.15→0 0.09→0 0.04→0把 20 条按预测概率分桶再算每桶的实际发生频率预测概率区间条数实际为「是」实际频率区间平均预测值0.9 – 1.044100%0.940.7 – 0.95480%0.800.5 – 0.73267%0.610.3 – 0.54125%0.410.0 – 0.3400%0.13合计201155%0.59看这张表要抓三个点每一桶里「平均预测值」和「实际频率」都挨得很近。0.9 以上那桶预测 0.94、实际 100%0.7–0.9 那桶预测 0.80、实际 80%。这就是校准的样子——预测值越高实际发生的比例也越高而且数值对得上。单次预测确实会错。0.71那条判成了「是」其实是「否」0.48那条判成了「否」其实是「是」。校准从不承诺这两条不错它承诺的是当你把 20 条作为一个整体看时账能对上。但 20 条还远远不够。整体平均预测 0.59、实际 55%差了 4 个百分点——样本太少这个残差到底是模型失准还是抽样噪声说不清。官方对此的说法很明确人工小样本只帮助理解概念不足以评估模型校准。想真的下定论经验上是每个分桶里至少几十条、总量几百到上千条带标签数据才谈得上算 ECE期望校准误差。校准带来的三条实用推论如果概率是校准的那它就不只是一个「看着挺有道理」的数字而是可以直接参与计算的东西阈值等价于错误率预算。把自动执行的门槛设在 0.8等价于「我接受这一类判断里约 20% 会漏掉」。阈值不再是拍脑袋的魔法数字而是你对错误率的定价。概率可以直接当特征。把多个原子问题的概率喂给一个下游的经典 ML 模型逻辑回归、GBDT 都行让模型学出最优组合权重——这是官方 AutoResearch 那篇实战的思路。前提是这些输入是校准的否则下游模型学到的也是一堆噪声。概率之间可以比较大小。重排序那篇实战能直接用noul给 30 个候选排序就是因为在同一个问题、同一把criteria尺子下不同候选的概率是可比的。三个最常见的误用误用为什么错正确做法把0.93当「这条一定对」它意味着同类型判断里约 7% 会错高概率只降低风险不消除风险涉及授权、付款、安全校验的流程照旧走直接抄别人的校准结论校准在分布内成立换领域、换语言就失效中文场景尤其要自己测——官方明确说英语准确率最高其他语言效果不一路由时要盯住 confidence用 20 条就宣布「我验证过校准了」小样本只能讲概念不能下结论准备几百条带标签数据分桶后画 reliability diagram、算 ECE想自己验证最小步骤是这五步攒一批带真实标签的数据建议 200 条起越难的问题需要越多跑一遍你的Noul/Choice问题记录每条的(预测概率, 真实标签)按 0.1 的间隔分桶每桶算「平均预测值」和「实际发生频率」画 reliability diagram——横轴平均预测值、纵轴实际频率点落在对角线上就是完美校准偏离的加权平均就是 ECE在自己的这条曲线上定阈值而不要抄文档或别人文章里的 0.5 / 0.7 / 0.9。最后回到这一节的标题概率凭什么可信凭的不是模型的自信语气凭的是 RLCD 把「说出来的概率必须对得上真实频率」写进了训练目标。而这份可信是有边界的——它只对你测过的那个分布负责。两个组都「准」但组内单次照样会错。工程上的正确用法✅ 用概率做群体决策路由、排序、抽检、批量分流❌ 用概率做单点高风险动作的唯依据——该交给阈值 人工复核一句话校准好 ≠ 单次必对。九、社区实测数据来自 jev-cookbook以下数字来自 datawhalechina/jev-cookbook 收录的实验报告供选型参考JevBench v1.2242 个类型化决策的公开基准Jev 1.13.0 综合智能分榜首75.4答案可解析率 100%这一点对工程化太重要了路由任务74.1%中位延迟0.65 ~ 0.72 秒每千次决策成本约$0.04稳定性同一套题隔 16 分钟跑两遍仅1.2%的答案变化。这说明端点不是完全确定性的——读 benchmark 表格时约 1 个百分点的差距应视为噪声。能替代 Rerank 吗80 条 SciFact 查询精排对照相对不做精排Jev 的 nDCG10 提升0.0778比传统精排还高0.0332精排耗时与 token 用量显著更低结论固定候选集上的语义重排是 Jev 的甜点区。速度与价格量级输入$0.042 / 百万 token输出免费因为输出就那么几个数便宜到什么程度——可以「投机式地多问」把不确定用不用得上的问题都塞进同一次调用反正几乎不增加延迟和成本代码端再决定用不用。一个典型生产案例是智能家居场景一次调用捆绑 10 个问题意图、是否复合、范围、房间、设备类别 五类设备动作预判代码端剪枝无关分支。这就是「投机式多问 原子组合」的完整实战。十、实战赛事指挥台模型管语义代码管规则来个完整的中文场景。假设一次夜跑赛事收到三条现场消息我们要做自动分流。10.1 定义状态与问题先定义好状态state和三个原子问题questions。状态就是三条现场消息的原文问题则拆成三个互不重叠的原子判断state [ 补给站 3 号点的水快用完了还有 200 人没跑完请求尽快补货。, 5 公里处有一位选手扭伤了脚踝无法继续跑需要医疗支援。, 完赛包领取处有人问奖牌什么时候发能不能提前领 ] questions [ { key: urgency, type: score, criteria: [ 0常规咨询可稍后处理, 1需要尽快处理但不危及安全, 2紧急涉及人身安全或赛事正常进行 ] }, { key: category, type: choice, criteria: { medical: 需要医疗人员介入, supply: 需要补给物资调度, info: 普通信息咨询可自动回复 } }, { key: needs_human, type: noul, criteria: 这条消息是否需要现场负责人或医疗人员人工介入 } ]三个问题分别对应三种原语Score打紧急度分、Choice分派类别、Noul判断是否要转人工。这样拆开问代码里才能独立地按阈值做分支。10.2 逐条调用代码分流用 Python SDK 一次调用问完三个问题拿到带概率的结果from typesafe_sdk import Jev jev Jev(api_keyYOUR_API_KEY) results [] for msg in state: resp jev.ask( statemsg, questionsquestions ) results.append(resp) for i, r in enumerate(results): print(f消息 {i1}:) print(f 紧急度 {r[urgency].score:.2f}) print(f 类别 {r[category].choice} (概率: {r[category].probabilities})) print(f 转人工 {r[needs_human].noul:.2f}) print()输出结果大致如下示意消息 1: 紧急度 1.10 类别 supply (概率: {supply: 0.92, info: 0.05, medical: 0.03}) 转人工 0.12 消息 2: 紧急度 2.85 类别 medical (概率: {medical: 0.97, supply: 0.02, info: 0.01}) 转人工 0.96 消息 3: 紧急度 0.20 类别 info (概率: {info: 0.99, supply: 0.01, medical: 0.00}) 转人工 0.03最后用代码根据概率做分流决策。规则很简单紧急度超过阈值或转人工概率高就升级否则按类别自动处理URGENCY_HIGH 2.0 # 紧急度阈值 HUMAN_THRESHOLD 0.8 # 转人工概率阈值 def dispatch(r): urgency r[urgency].score category r[category].choice needs_human r[needs_human].noul if urgency gt; URGENCY_HIGH or needs_human gt; HUMAN_THRESHOLD: return 转人工, 现场负责人 / 医疗人员 if category supply: return 自动派单, 补给组优先处理 if category info: return 自动回复, 赛事 FAQ 机器人 return 转人工, 现场负责人 for i, r in enumerate(results): action, target dispatch(r) print(f消息 {i1} → {action}{target})运行结果消息 1 → 自动派单补给组优先处理 消息 2 → 转人工现场负责人 / 医疗人员 消息 3 → 自动回复赛事 FAQ 机器人这就是「模型管语义代码管规则」的完整落地Jev 只负责把每条消息翻译成带概率的原子判断至于阈值怎么定、走哪个分支、要不要转人工全部由代码里的规则决定。优先级变了只改URGENCY_HIGH或HUMAN_THRESHOLD这两个常数不用改提示词、不用重跑评测。