1. 当所有人都在卷生成能力时Jev 为什么反着来第一次看到 Jev 这个模型的时候我承认我愣了一下。市面上绝大多数模型都在拼命证明自己能写、能画、能聊参数越堆越大输出越来越长恨不得把一句话能说清的事扩写成三千字。而 Jev 的定位恰恰相反——它不生成文字它只做决策。这个反差本身就值得琢磨。把 Jev 理解成一个决策内核更准确。你给它一个状态、一组候选动作它返回的是选哪个以及这个选择有多好而不是一段自然语言。这听起来好像很简单但真正做过 Agent、做过自动化决策系统的人会立刻意识到生成文字和做出决策是两种完全不同的能力。前者考验的是语言建模后者考验的是价值判断。Jev 把宝全押在了后者上。关键词里出现的 System One、RLCD、Choice、Score其实已经把它的技术骨架交代得七七八八了。System One 指的是快思考、直觉式决策对应的是那种不需要长篇推理、直接给出判断的路径RLCD 是它训练范式的核心Choice 和 Score 则是它输出的两个基本单元——选择与评分。这几个词串起来就是 Jev 的完整画像一个用强化学习式对比决策训练出来的、专门负责选和打分的模型。这篇内容适合谁看如果你在做 Agent 编排、在做推荐或排序、在做任何需要从多个候选里挑一个的系统Jev 这套思路值得你花时间。如果你只是想找个能聊天的模型那它可能不是你要的东西。我下面会从它到底解决什么问题、RLCD 是怎么运作的、Choice 和 Score 怎么用、以及实际接入时会踩哪些坑一层层拆开讲。2. 不生成文字这件事到底解决了什么真问题2.1 生成模型的决策税我先讲一个很多人踩过的坑。早些年做 Agent 的时候大家习惯让一个大语言模型既负责理解、又负责推理、还负责输出最终决策。比如让模型输出一段 JSON里面包含我选择方案 B理由是……。看起来很方便但实际跑起来问题一大堆。最典型的是格式不稳定。你要求它输出 JSON它十次里有两次会多写一句好的以下是我的选择然后你的解析器就崩了。你加正则、加重试、加约束解码代码越来越臃肿。更麻烦的是决策质量被语言能力稀释。模型在生成理由的时候其实是在做语言建模它倾向于生成听起来合理的理由而不是真正最优的选择。这两者经常不一致。这就是我说的决策税——你为了拿到一个决策不得不支付大量的解析成本、重试成本还要忍受语言生成带来的偏差。Jev 的思路是把这个税直接砍掉我不生成文字我只输出结构化的选择和分数你拿到就能用。2.2 System One 快思考的工程价值System One 这个词借用了认知科学里快思考的概念对应的是直觉、快速、低成本的判断。放到工程语境里它意味着低延迟、低算力、高吞吐。我实测过一些决策场景如果用一个通用大模型来做从 20 个候选里选一个单次调用动辄几百毫秒到一两秒还要消耗大量 token。而一个专门做决策的模型因为不需要自回归地生成一长串文字输出长度极短可能就是一个索引加一个分数延迟能压到很低。对于需要高频决策的系统——比如实时排序、游戏 AI、对话策略选择——这个差距是决定性的。注意System One 不等于简单。快思考的前提是背后有大量的训练把判断能力内化进了参数里。它快是因为它不需要在推理时展开思考链而不是因为它想得少。2.3 决策与生成解耦的架构意义把决策和生成拆成两个模型是一个很务实的架构选择。生成模型负责把话说漂亮决策模型负责把事做对。两者各司其职互不拖累。这种解耦带来的好处很直接决策模型可以做得小而快生成模型可以做得大而好你甚至可以用不同的硬件分别部署。更重要的是决策模型的输出是结构化的天然适合被程序消费不需要任何自然语言解析。对于构建可靠的自动化系统来说这一点比什么都重要。3. RLCD 到底在训练什么从偏好到可打分的决策3.1 RLCD 的基本直觉RLCD 是 Jev 训练范式的核心我理解它本质上是把强化学习和对比决策结合了起来。传统的偏好对齐方法比如基于人类反馈的强化学习通常是让模型学会哪个回答更好然后调整生成分布。但 Jev 不需要生成回答它需要的是对候选动作做出可比较的判断。所以 RLCD 的训练目标更接近给定一个状态和一组候选让模型学会给每个候选打出一个分数并且这个分数能正确反映它们的相对优劣。这本质上是在训练一个价值函数只不过这个价值函数是用神经网络参数化的而且能泛化到没见过的状态。3.2 为什么用对比而不是绝对打分这里有个很关键的工程细节。如果直接让模型学给单个动作打绝对分会非常难因为绝对分数的尺度很难定义不同场景之间也不可比。而对比学习——让模型判断A 比 B 好——要稳定得多。这就像你问一个人这家餐厅打几分很难得到一致答案但问这两家餐厅你更喜欢哪家就容易多了。RLCD 利用的就是这个原理通过大量的成对比较训练出一个能对任意候选排序的打分器。最终推理时模型对每个候选输出一个 Score你按分数排序取最高的那个决策就完成了。3.3 训练信号从哪来训练信号的质量直接决定决策模型的上限。常见的来源有几类一是真实系统里记录的用户行为点击、选择、停留这是最贴近真实偏好的信号二是人工标注的偏好对三是用更强的模型或模拟器生成的对比数据。我个人经验是行为数据 人工标注 模型生成但行为数据往往噪声大、有偏需要仔细清洗。比如点击数据里位置靠前的候选天然更容易被点这个位置偏差必须校正否则模型学到的只是排在前面的好而不是真的好。提示如果你自己要做类似的决策模型先花时间把偏好数据的偏差分析清楚比急着调模型结构重要得多。数据里的系统性偏差模型是学不掉的只会放大。4. Choice 与 ScoreJev 输出的两个基本单元4.1 Choice 是离散的落点Choice 就是最终选中的那个候选。它可以是索引、ID或者任何能唯一标识候选的符号。Jev 输出 Choice 的方式我理解是先打分再取最大而不是直接生成一个选择。这个区别很重要直接生成选择容易受生成顺序、词表分布的影响而打分排序是全局比较更稳。在实际系统里Choice 通常就是你要执行的动作。比如对话系统里选一个回复策略推荐系统里选一个物品游戏里选一个走法。拿到 Choice你的下游逻辑就能直接跑起来。4.2 Score 是连续的置信度Score 是 Jev 另一个关键输出。它不只是用来排序的还能告诉你这个选择有多确定。这个信息在很多场景里价值巨大。举个例子在自动化决策系统里你可以设一个阈值Score 高于某个值就自动执行低于就转人工审核。这就把决策模型变成了一个可以调节激进/保守程度的组件。再比如在多模型集成时你可以用 Score 做加权让更自信的模型说话更有分量。我踩过的一个坑是不同批次的 Score 尺度可能不一致。如果你的系统依赖绝对阈值一定要做校准比如用一批标注数据拟合一个映射把 Score 归一到稳定的区间。否则今天阈值 0.7 能用明天数据分布一变就全乱了。4.3 两个输出怎么配合使用Choice 和 Score 配合起来能玩出不少花样。最基础的用法是取 Score 最高的 Choice。进阶一点你可以做候选过滤先用 Score 筛掉明显差的再在剩下的里做更精细的决策。还可以做多样性控制如果前几个候选 Score 很接近说明模型也不确定这时候可以引入随机性或外部规则来打破平局。输出类型典型用途注意事项Choice离散标识直接执行动作、下游路由需保证候选集合稳定Score连续数值排序、阈值判断、集成加权需做跨批次校准5. 把 Jev 接进实际系统从候选构造到结果消费5.1 候选集合怎么构造Jev 的输入是状态 一组候选所以候选集合的质量直接决定决策质量。这一步经常被低估。我见过太多人把候选随便凑一凑就丢给模型然后抱怨决策不准。候选构造有几个原则。第一候选要覆盖真正可行的动作不能把好选项漏在外面否则模型再强也选不出来。第二候选数量要适中太少没有选择空间太多会稀释注意力、增加延迟。我的经验是几十个量级比较舒服具体看场景。第三候选之间要有区分度如果十个候选里八个几乎一样那决策就没意义了。5.2 状态特征怎么组织状态是模型做判断的依据。它可以是结构化的特征向量也可以是文本描述取决于 Jev 的具体接口。不管哪种形式核心是把和决策相关的信息都放进去把无关的噪声去掉。这里有个反直觉的点不是信息越多越好。冗余特征会干扰模型尤其是当某些特征和结果有虚假相关时。我一般会先做一轮特征筛选把明显无关的砍掉再让模型去学剩下的。5.3 结果消费与闭环拿到 Choice 和 Score 之后你的系统要能消费它们并且最好能形成闭环。所谓闭环就是把实际执行的结果反馈回去用来持续改进决策模型。这个反馈可以是显式的用户点了没点也可以是隐式的任务成功没成功。闭环是决策模型长期有效的关键。没有反馈模型就会慢慢偏离真实需求。有了反馈你就能定期用新数据做增量训练或校准让模型跟上环境变化。注意闭环反馈一定要处理延迟和归因问题。一个决策的好坏可能要很久之后才能看出来而且往往受多个因素影响。别把不相干的锅扣到决策模型头上。6. 接入 Jev 时最容易翻车的几个地方6.1 把决策模型当生成模型用最常见的错误就是期待 Jev 给你一段解释。它不生成文字你硬要它解释要么拿不到要么拿到的是硬凑的。正确的做法是决策归决策解释归解释。需要解释的时候把 Choice 和 Score 交给一个生成模型让它基于结构化结果去组织语言。这样两边都发挥所长。6.2 忽略 Score 的校准前面提过Score 的绝对尺度可能漂移。如果你的业务逻辑里有硬阈值一定要做校准。我一般会保留一批金标准样本定期跑一遍看 Score 分布有没有偏移偏移了就重新拟合映射。这个习惯能帮你避免很多线上事故。6.3 候选集合动态变化带来的问题如果你的候选集合是动态的比如推荐系统里物品池一直在变要小心模型对没见过的候选的处理。决策模型通常需要候选有稳定的表示如果新候选的特征分布和老候选差很多Score 可能不可靠。解决办法之一是给新候选做冷启动处理或者用探索机制先收集一些反馈。6.4 延迟与吞吐的权衡虽然 Jev 比生成模型快但如果你一次要评估成百上千个候选延迟还是会上去。这时候可以考虑两阶段先用一个轻量模型粗筛再用 Jev 精排。或者对候选做分批并行评估。具体怎么选取决于你的延迟预算和硬件条件。常见问题根因应对方式拿不到文字解释模型定位就是决策交给生成模型补解释阈值突然失效Score 尺度漂移定期校准映射新候选打分异常特征分布不匹配冷启动 探索大批量评估慢候选太多两阶段粗筛精排7. 我对 Jev 这类决策模型的一点个人判断用了一段时间、也拆过它的训练逻辑之后我越来越觉得不生成文字的决策模型这个方向被低估了。大家习惯了用一个大模型包打天下但真实系统里决策和生成本来就是两件事。把它们拆开各自做专做精系统的可靠性和效率都会明显提升。Jev 的价值不在于它多能聊而在于它把选和打分这两件事做得干净利落。RLCD 的训练范式、Choice 和 Score 的输出设计都是围绕让决策可被程序可靠消费这个目标来的。如果你正在搭 Agent 或者任何需要自动决策的系统我建议你把决策层单独拎出来考虑别让它和生成层搅在一起。最后分享一个小技巧刚开始接的时候别急着上复杂场景。先找一个候选数量少、反馈快的小场景跑通把候选构造、Score 校准、闭环反馈这几条链路都验证一遍再往大场景扩。决策模型的坑大多不在模型本身而在它和系统其他部分的衔接上。把这些衔接理顺了Jev 这类模型才能真正发挥出它该有的价值。