1. 从会聊天的模型到只做决策的模型Jev 到底在解决什么问题大多数人第一次听到 Jev 这个名字第一反应都是又一个套壳聊天机器人。但真正去看它的定位会发现它走的是完全相反的一条路它不聊天不写作文不做头脑风暴它只干一件事——在给定上下文里输出一个带概率的结构化决策。这个定位本身就值得琢磨因为过去两年我们被对话式 AI训练出了一种惯性思维觉得模型越能说会道就越强但真到了生产系统里最让人头疼的恰恰是那些话很多但落不了地的输出。Jev 的提出者背景里有一个关键词是前 OpenAI 研究员这个信息点的价值不在于背书而在于它暗示了设计动机在真实的产品和 Agent 系统里模型最需要的不是生成一段漂亮的自然语言而是在多个候选动作之间做出可解释、可回滚、可统计的选择。比如一个自动化运维 Agent面对磁盘使用率 92%这个信号它需要输出的不是建议您检查一下磁盘哦而是{action: clean_logs, confidence: 0.83}这样的东西。前者人类还得再判断一次后者可以直接进决策流水线。这就是 Jev 的核心命题把决策从语言生成里剥离出来。它属于所谓 System One 模型的一类思路——不是慢思考的推理链而是快速、直接、带概率的直觉式判断。你可以把它理解成一个决策分类器 概率校准器的组合体而不是一个对话引擎。关键词里的 TypeSafe AI 也指向同一个方向输出必须是类型安全的字段、枚举值、取值范围都被约束住模型不能自由发挥。适合读这篇内容的人大概有三类一是正在做 Agent 或自动化流水线、被 LLM 输出不稳定折磨的工程师二是想理解结构化决策模型和对话模型本质差异的技术决策者三是好奇 RLCDReinforcement Learning from Contrastive Decisions 这类对比式决策强化思路到底怎么落地的人。下面我会把 Jev 的定位、原理、接入方式、实际使用中的坑以及它和 Codex 这类工具怎么配合一层层拆开讲。2. Jev 的定位拆解为什么不说话反而是它的优势2.1 对话模型的隐性成本在决策场景里被放大了我们先算一笔账。假设你有一个客服工单自动分流系统每天 10 万条工单需要判断每条工单该进退款技术投诉咨询哪个队列。如果你用一个通用对话模型来做典型流程是拼一段 prompt让模型输出一段话再用正则或二次模型去解析出类别。这个链路里有三个隐性成本。第一是token 成本。模型为了礼貌往往会输出根据您描述的情况这应该属于退款类问题建议……这种话几十个 token 全浪费在客套上。第二是解析成本你得写解析逻辑而解析逻辑一旦遇到模型换了个说法就崩。第三是概率缺失对话模型给你的是一段文本你根本不知道它对这个判断有多确信没法做阈值过滤低置信度的样本没法自动转人工。Jev 这类模型的设计就是冲着这三个成本去的。它直接输出结构化结果附带概率值没有客套话解析逻辑可以极简。我实测过类似的决策模型接入同样的分流任务token 消耗能降到对话方案的十分之一左右而且因为输出格式被类型约束住解析失败率几乎为零。2.2 带概率这三个字才是真正值钱的地方很多人看到结构化输出觉得没什么稀奇JSON mode 早就有了。但 Jev 强调的带概率是另一回事。普通 JSON mode 只是约束了格式模型内部依然是 softmax 出一个 token 分布最后你拿到的类别是 argmax 的结果那个第二名差多少的信息被丢掉了。而 Jev 输出的概率是校准过的置信度意思是当它说 0.83 的时候历史上这类样本大约真的有 83% 是对的。这个性质在工程上极其重要因为它让你可以做分级决策。比如置信度区间系统行为理由≥ 0.9直接自动执行高置信误判成本可接受0.6 ~ 0.9执行但记录异步抽检中等置信需要监控 0.6转人工或触发澄清低置信自动执行风险高这张表就是带概率带来的直接价值。没有校准概率你只能一刀切要么全自动风险高要么全人工没意义。校准概率让系统有了知道自己不知道的能力这是决策模型和生成模型最本质的分水岭。2.3 System One 思路快决策不等于浅决策System One 这个词借用了认知心理学的双系统理论指的是快速、直觉、自动化的判断对应的是慢速、审慎、需要推理链的 System Two。很多人误以为 System One 就是简单模型这是误解。在 Jev 的语境里System One 意味着决策路径短、延迟低、可高频调用。它不需要展开几千 token 的思维链而是在一次前向传播里给出判断。这背后依赖的是训练阶段把推理内化进了权重而不是在推理时显式展开。打个比方老司机开车换挡不需要在脑子里列步骤新手才需要。Jev 想做的就是那个老司机——把决策模式压缩进模型让调用方拿到即用。这也解释了为什么它适合嵌在 Agent 循环里。一个 Agent 一秒钟可能要决策几十次选哪个工具、传什么参数、要不要重试如果每次都跑一个慢思考模型延迟和成本都扛不住。Jev 这种快决策模型正好补上这个位置。3. 结构化决策背后的技术逻辑RLCD 与 TypeSafe 是怎么配合的3.1 RLCD 的核心用对比而不是打分来训练决策RLCD 这类对比式决策强化思路和传统 RLHF 有个关键区别。RLHF 通常让人类对单个输出打分这个回答好不好1 到 5 分而 RLCD 更强调成对或成组的对比在同一个上下文下给出多个候选决策让模型学会哪个决策更优而不是这个决策值几分。为什么对比更有效因为人类对绝对分数的判断极不稳定今天给 4 分明天给 3 分但A 比 B 好这种相对判断一致性高得多。对于决策任务这种相对信号恰好是模型最需要的——它要学的是在候选动作之间排序而不是给单个动作贴标签。落到训练流程上大致是这样一条链路先构造大量上下文 候选决策集的样本通过对比标注得到偏好对再用这些偏好对去优化模型让高概率落在被偏好的决策上。同时引入概率校准损失保证输出的置信度和实际正确率对齐。这一步是很多团队容易忽略的——只做偏好优化不做校准模型会变得过度自信概率全是 0.99分级决策就失效了。3.2 TypeSafe 约束让模型想跑偏都跑不了TypeSafe AI 这个关键词落到 Jev 上就是输出 schema 的强约束。你接入的时候会先定义一个决策类型比如from typing import Literal from pydantic import BaseModel, Field class RoutingDecision(BaseModel): action: Literal[refund, tech, complaint, inquiry] confidence: float Field(ge0.0, le1.0) reason_code: Literal[billing, bug, attitude, howto, other]模型被约束成只能在这个空间里输出。action只能是四个枚举值之一confidence必须在 0 到 1 之间reason_code也是封闭集合。这种约束在解码阶段就生效不是生成完再校验所以不会出现模型输出了个不存在的类别然后你解析报错的情况。这里有个实操细节值得说枚举值的设计直接决定模型好不好用。我见过有人把 action 设计成 30 多个细分类别结果模型置信度普遍偏低因为类别太细边界模糊。经验做法是主类别控制在 5 到 8 个需要更细的维度就拆成第二个字段比如上面例子里 action 粗分、reason_code 细分让模型分层决策而不是一次性在几十个类里选。3.3 概率校准从看起来像概率到真的是概率前面反复提到校准这里展开讲一下为什么它难。模型原始输出的 softmax 值往往不是校准的典型表现是过度自信——明明只有 60% 把握却输出 0.95。校准要做的就是把这个 0.95 拉回到 0.6 附近。常见做法是温度缩放temperature scaling和分桶校准isotonic regression。温度缩放简单在验证集上找一个温度参数 T把 logits 除以 T 再 softmax让置信度和准确率对齐。分桶校准更精细把置信度分成若干区间每个区间单独映射。Jev 这类模型在训练时就把校准纳入了目标所以开箱即用的概率相对可信但你在自己的业务数据上还是应该做一次领域校准因为分布偏移是常态。提示判断一个决策模型是否校准最直接的方法是画可靠性图reliability diagram——横轴是预测置信度纵轴是实际准确率理想情况是一条对角线。如果你拿到 Jev 的输出发现所有样本置信度都挤在 0.9 以上那大概率是没校准好或者你的输入分布和训练分布差太远。4. Jev 的接入实操从申请密钥到在 Codex 里跑通4.1 环境准备与密钥申请几个容易卡住的点接入 Jev 的第一步是拿到访问凭证。通常流程是去官网提交申请说明用途和预估调用量通过后拿到密钥。这里有几个实操经验。第一申请时把用途写具体。写我想试试和写我要做工单自动分流日均 5 万次决策调用通过率和配额完全不一样。第二密钥要分环境管理开发、测试、生产用不同的 key方便限流和审计。第三注意密钥的权限范围有些密钥只能调特定模型或特定决策类型申请前先确认清楚。环境变量建议这样组织避免硬编码export JEV_API_KEYyour_key_here export JEV_BASE_URLhttps://api.example.com/v1 export JEV_MODELjev-decision-v1注意密钥千万不要提交到代码仓库。用.env文件加.gitignore或者用密钥管理服务。我见过太多因为密钥泄露被刷爆配额的案例这个坑一次就够疼。4.2 最小可运行示例一次决策调用长什么样下面是一个最小调用示例用 Python 演示。核心是构造上下文、指定决策 schema、解析返回的概率。import os import json import requests API_KEY os.environ[JEV_API_KEY] BASE_URL os.environ[JEV_BASE_URL] def decide(context: str, candidates: list[str]) - dict: payload { model: jev-decision-v1, context: context, decision_space: { action: candidates, confidence: {type: float, min: 0.0, max: 1.0} }, return_probabilities: True } resp requests.post( f{BASE_URL}/decide, headers{Authorization: fBearer {API_KEY}}, jsonpayload, timeout10 ) resp.raise_for_status() return resp.json() result decide( context用户反馈付款后订单状态一直显示待支付已经等了 2 小时。, candidates[refund, tech, complaint, inquiry] ) print(json.dumps(result, ensure_asciiFalse, indent2))返回大概长这样{ action: tech, confidence: 0.78, probabilities: { refund: 0.09, tech: 0.78, complaint: 0.08, inquiry: 0.05 } }注意probabilities字段它给出了完整分布而不只是 argmax。这个分布非常有用——如果 top1 和 top2 差距很小比如 0.45 vs 0.42说明这个样本本身模糊即使 top1 置信度不算低也应该谨慎处理。我一般会加一条规则top1 与 top2 的差值小于 0.15 时无论绝对置信度多少都转人工。这条规则帮我拦下了不少边界样本。4.3 在 Codex 里使用 Jev把决策能力接进编码工作流Jev 在 Codex 中使用是很多人关心的场景。这里的思路是Codex 这类编码助手负责生成和修改代码而 Jev 负责在关键节点做决策判断。比如一个自动重构工具面对这段代码要不要抽成函数的问题可以让 Jev 基于代码上下文输出决策和置信度而不是让编码模型自由发挥。具体接法通常是写一个工具函数把 Jev 包装成 Codex 可调用的 tooldef jev_decide_tool(context: str, options: list[str]) - str: 供编码助手调用的决策工具返回结构化决策。 result decide(context, options) return json.dumps({ chosen: result[action], confidence: result[confidence], alternatives: result[probabilities] }, ensure_asciiFalse)然后在 Codex 的工具注册里声明这个函数让模型在需要做选择时调用它。这样做的好处是决策和生成解耦编码模型专注写代码决策模型专注判断各司其职。实测下来这种分工比让一个模型既写代码又做判断要稳定得多因为决策模型的输出被 schema 约束住不会出现它一边写代码一边改主意的混乱。4.4 批量与流式不同调用模式的取舍Jev 一般支持单次调用和批量调用两种模式。单次调用延迟低适合在线 Agent 循环批量调用吞吐高适合离线打标、数据清洗这类场景。模式典型延迟适用场景注意点单次同步几十到几百毫秒在线决策、Agent 循环注意超时和重试批量异步秒级到分钟级离线打标、批量分流注意批次大小和限流流式首 token 快需要边决策边展示决策场景用得少决策场景其实很少需要流式因为你要的是最终那个判断不是过程。所以我的建议是在线用单次同步 超时降级离线用批量异步。超时降级的意思是如果 Jev 调用超时不要卡死整个流程而是走一个默认决策或转人工保证系统可用性。5. 实际使用中的坑与调优经验5.1 上下文太长反而让决策变差这是我最想强调的一条。很多人觉得给模型的上下文越多越好把用户历史、日志、文档全塞进去。但在决策任务里冗余上下文会稀释关键信号导致置信度下降、误判增加。我做过一组对比同一个工单分流任务上下文从 200 字扩到 2000 字准确率不升反降了大约 6 个百分点而且平均置信度从 0.81 掉到 0.68。原因是模型被大量无关信息干扰注意力被分散。正确做法是做上下文压缩只保留和决策直接相关的字段。比如工单分流真正有用的是问题描述 订单状态 用户等级用户的历史浏览记录基本没用。压缩上下文不仅提升准确率还降成本、降延迟一举三得。5.2 类别不平衡会让概率失真如果你的业务里 90% 的样本都是某一类模型会倾向于给这一类高概率哪怕当前样本明显属于少数类。这是训练数据分布导致的先验偏移。应对办法有两个。一是在训练/微调阶段做重采样让各类别更均衡。二是在推理阶段做先验校正用贝叶斯公式把模型输出的后验概率除以训练集先验再归一化。第二种方法不用重训模型工程上更轻量def correct_prior(probs: dict, train_prior: dict) - dict: adjusted {k: probs[k] / train_prior[k] for k in probs} total sum(adjusted.values()) return {k: v / total for k, v in adjusted.items()}提示先验校正的前提是你知道训练集的类别分布。如果拿不到可以用线上流量的分布做近似但要定期更新因为业务分布会漂移。5.3 置信度阈值不能拍脑袋定很多人设阈值就是0.8 吧听起来挺高。这是错的。阈值应该由业务成本反推。假设误判一个退款工单的成本是 50 元转人工的成本是 5 元那么当自动执行的期望损失超过 5 元时就该转人工。期望损失 (1 - 置信度) × 误判成本。令它等于转人工成本(1 - c) × 50 5解得c 0.9。所以这个场景下阈值应该是 0.9而不是 0.8。不同类别误判成本不同阈值也应该不同——投诉类误判成本高阈值就该更高。这套算法我在多个项目里用过比拍脑袋靠谱得多。关键是把业务成本量化哪怕只是粗略估计也比没有强。5.4 监控与漂移检测别等出事了才发现决策模型上线不是终点。你需要持续监控几个指标置信度分布如果整体下移说明输入分布变了、各类别占比如果某类突然暴涨可能是上游数据问题、人工复核一致率抽检自动决策和人工判断的一致程度。我一般会设三条告警线置信度中位数周环比下降超过 10%、某类别占比日环比翻倍、人工复核一致率低于 85%。触发任何一条就去看数据大概率是上游变了或者模型需要重新校准。这套监控帮我提前发现过好几次数据管道故障避免了错误决策扩散。6. 把 Jev 放进真实系统几个落地场景的取舍6.1 Agent 工具选择决策模型比生成模型更合适一个 Agent 通常有十几个可用工具每一步都要选一个。用生成模型做这件事你得让它输出工具名然后解析还经常遇到它编一个不存在的工具。用 Jev 这类决策模型工具名就是枚举值选不出来就是选不出来不会瞎编。更重要的是决策模型能告诉你这一步我有多确定。如果置信度低Agent 可以选择先澄清、先查资料而不是硬着头皮选一个。这种知道自己不确定的能力是 Agent 稳定性的关键。我见过太多 Agent 因为某一步选错工具后面全盘崩溃而如果当时置信度低就停下来问一句根本不会走到那一步。6.2 内容审核分级概率让审核有层次内容审核是典型的决策场景通过、拦截、转人工。用 Jev 输出概率后可以做成三级高置信通过直接放行高置信拦截直接拦中间地带转人工。这样既保证了安全性又不会把所有内容都堆给人工。这里的关键是两个阈值而不是一个。通过阈值和拦截阈值之间留出灰区灰区样本转人工。灰区宽度由人工审核容量决定——容量大就放宽灰区容量小就收窄。这种弹性是纯分类模型给不了的。6.3 和规则引擎的配合模型负责模糊规则负责确定不要用模型去替代所有规则。有些决策是确定的比如用户被拉黑就直接拒绝这种用规则引擎零延迟零成本零误判。模型应该只处理规则覆盖不到的模糊地带。我的做法是规则引擎先跑一遍能定的直接定剩下的交给 Jev。这样既降低了模型调用量又保证了确定性场景的绝对可靠。实测下来规则能覆盖 40% 到 60% 的样本模型只需要处理剩下的部分整体成本和延迟都大幅下降。7. 我对这类决策模型的一点个人判断用了一段时间 Jev 这类结构化决策模型我最大的体会是AI 落地难的从来不是生成而是决策。生成内容人类还能审一审决策一旦自动化就是真金白银的影响。所以决策模型的价值不在于它多聪明而在于它可解释、可校准、可回滚——你能看到它为什么这么选概率分布能知道它有多确定校准置信度能在它不确定时接管阈值分级。如果你正在做 Agent、自动化流水线或者任何需要让模型做选择的系统我建议把决策和生成拆开生成交给擅长生成的模型决策交给 Jev 这类专门做决策的模型。这个分工看起来多了一层实际上让整个系统稳定了一个量级。至于具体阈值怎么定、上下文怎么压、类别怎么设计这些都得结合你自己的业务数据去调没有万能参数。先跑通最小闭环拿真实数据画一张可靠性图剩下的就是迭代的事了。