模型研究笔记 · · 约 18 分钟
Jev 与 GPT：生成语言，还是直接作出决策？
Jev 是 TypeSafe AI 的 System One 模型。它把“读入状态、回答有限选项的问题”做成一等接口；GPT 系列以逐 Token 生成语言为基础，也可以通过约束解码返回结构化值。真正需要比较的是计算路径、训练目标、输出语义和适用边界。
证据等级：Jev 尚无可复现的架构与训练技术论文公开。下面的“Jev 如何工作”仅包含官方描述和 API 可见行为；图和交互是原创教学抽象，不是其网络结构图或跑分。
把语言模型接入软件，究竟卡在哪里？
一个客服流程需要的可能只是“是否要求退款”“属于哪个部门”“风险有多高”。自由文本模型可以回答，但代码要从回复中抽取字段、检验类型、处理拒绝或截断，并为每个判断决定能否自动执行。格式正确并不代表判断正确，而漂亮的解释也不等于概率可靠。[1][5]
TypeSafe 提出的 Jev 把输出空间先写在请求里，返回有限选项上的概率，让应用程序执行显式的业务规则。它不回答开放式“写一封邮件”，也不生成代码或长篇推理；这与 GPT 的通用语言接口目标不同。OpenAI 的 Structured Outputs 已能对 GPT 的输出施加 Schema 约束，所以差异不能简化成“GPT 一定会生成无效 JSON”。[2][5]
软件需要大量低延迟、可组合的判断，通用续写往往要花时间生成与解析文本。
Jev 用 State + Choice / Score / Noul 提交一批独立问题，返回类型受限的概率分布。
答案空间事先可枚举；复杂业务分解成窄问题，跨问题逻辑由代码负责。
长篇写作、开放式代码生成、从零构造未知输出类型，也不自动保证语义真实。
三条技术路线，不要混成两个产品标签
| 维度 | GPT 自由生成 | GPT + Structured Outputs | Jev + 类型化问题 |
|---|---|---|---|
| 状态表示 | 上下文 Token 序列；现代具体架构未全部公开 | 同一类语言模型输入，另有 Schema | 文本、JSON 对象或文本数组构成的 state；问题有预设类型与候选项 |
| 输出机制 | 条件于之前 Token，逐步生成下一 Token | 仍逐步生成；每步只允许当前 Schema 合法的 Token | 官方描述：同一 state 上多个独立问题并行给出有限空间的概率 |
| 训练目标 | GPT-3：语言建模；InstructGPT：示范与偏好反馈后训练 | 语言模型加 Schema 理解训练与确定性的解码约束 | 官方称 RLCD 优化校准决策；损失函数、数据、训练细节未披露 |
| 适用输出 | 文章、代码、解释、开放式回答 | 可变字段与嵌套 JSON，仍可表达文字 | Choice、Score、Noul；不能自由生成字符串 |
| 代价与边界 | 长输出需要更多串行步骤 | 格式可保证，内容仍可能错；拒绝、截断要处理 | 窄判断适合批量处理；候选项不全、状态错误仍会导致错误决策 |
先看数据怎样进入、怎样离开
例如输入是“订单 A-104 有两笔相同扣款，客户要求退款”，程序同时询问：是否要求退款（Noul）、属于账单还是技术问题（Choice）、情绪等级（Score）。三个结果用同一个 state，但互相不读取前一个答案。若第二步必须先根据第一步结果查数据库，那么依赖是真实存在的，代码应再发一次请求；“并行”不能抹掉依赖。[2]
哪些公式有依据，哪些只是接口抽象？
GPT：下一个 Token 的条件分布
设输入和输出拼成 Token 序列 t₁,…,tₙ。自回归语言建模将联合概率分解为一串条件概率；生成第 i 个 Token 时，前面已生成的 Token 构成条件。训练时可并行计算许多位置的损失，但输出阶段的下一步依赖上一步结果。这不等于 GPU 对每一层内部都串行计算。[6]
右侧乘积说明输出顺序上的依赖；Transformer 每一步仍有矩阵运算可在加速器上并行执行。
GPT 的类型约束：仍然生成，但每步裁掉非法选项
OpenAI 的 Structured Outputs 将支持的 JSON Schema 预处理成上下文无关文法（CFG），在已生成前缀 t<ᵢ 下计算合法 Token 集 A(t<ᵢ,S)。从概念上可将不合法 Token 的概率设为零，再归一化。这保证符合可支持 Schema 的格式；安全拒绝、未完成输出和字段内容错误仍需要应用程序处理。所以“Jev 有类型、GPT 没有类型”不是准确比较。[5]
S 为 Schema，指示函数在 Token 不合法时取 0。它改变可输出集合，并没有从根本上取消自回归依赖。
Jev：状态、候选空间和并行的问题
官方文档提供三种原语：Choice 在预定义候选项中选择并返回概率；Score 在定义好的等级上给出分布及连续位置；Noul 给一个二元命题为真的概率（0 到 1）。Choice/Score 的 confidence 是从概率分布形状得到的摘要，Noul 没有单独 confidence。若候选集合遗漏“都不是”，模型仍被限制在错误的选项表内。[2][3]
Cⱼ 是第 j 题允许的候选项或等级，Pⱼ 是返回的概率。TypeSafe 称这些问题同批并行且彼此独立；无法由 API 推导网络层数、注意力形式或 FLOPs。
训练目标不是一个神奇的缩写
GPT-3 公开的是自回归语言建模；InstructGPT 先用示范做监督微调，再通过人类偏好排序与强化学习改善遵从指令。TypeSafe 的资料另把有可程序验证奖励的训练称为 RLVR，作为数学题等路线的背景；不能断言所有 GPT 版本都只用 RLHF。TypeSafe 把自己的后训练路线命名为 RLCD（Reinforcement Learning for Calibrated Decisions），声称使输出概率与正确率更一致。然而公开资料没有足够信息重建其奖励函数、优化器、数据构成、模型结构或训练规模。不能凭“RL”三个字替它写出损失函数，也不能声称 GPT 的概率从不校准。[1][4][7]
GPT 输出逐 Token 依赖，不妨碍每个 Token 的矩阵运算使用 GPU 等加速器。Jev 官方称有并行 sampler、硬件感知效率，却未公开完整部署拓扑；不能把 Jev 简单写成“CPU 算”、GPT 写成“GPU 算”。网页演示不是芯片测量。
看依赖链，再理解校准
输出变长，和问题变多，是同一件事吗？
滑动控制项；格子表示对外输出步骤，不表示 FLOPs 或实际毫秒数。
教学抽象。真实延迟还取决于输入长度、模型大小、批处理、排队、网络、硬件和推理设置；复杂问题并不会因一次调用而自动变简单。
所谓校准是跨一组问题的频率性质：如果模型给许多事件都报 80%，其中约 80% 最终为真，才称这组 80% 预测得到良好校准。单个判断不能证明自己已校准。选择适当的阈值还要看错误的代价，例如读取页面和执行转账的阈值不能一样。[3][4]
模型说 80%，事后只有 40% 正确，会怎样？
把同一概率区间内的一组二元事件当作玩具数据，观察校准差与 Brier 分数。
教学数据，由滑块人为设置，绝非 Jev 或 GPT 的真实校准测试。Brier = f(1−p)² + (1−f)p²；分数低不保证单个事件正确。
漂亮的速度数字测了什么？
| 公开报告 | 设置 / 指标方向 | 结果和可解释范围 | 仍缺什么 |
|---|---|---|---|
| TypeSafe 发布演示 [1] | 短而密的文本状态，多个可读键名问题；与 GPT-5.6 Terra 默认推理比较。端到端延迟越低越好。 | 官方给 Jev 的响应范围 70–500 ms，并称某些同类 System One 查询快 40–200 倍。 | 特意缩短的输入对 Jev 有利；单个演示不是通用能力测试。 |
| 四个工作流 [1][8] | 安全事件、代理轨迹、发票、客服；精度相对于 GPT-6 Astra 与 Fable 5.1 的平均“共识标签”，成本/时延越低越好，精度越高越好。 | 官方从其工作流得出最高 193.6× 更快、444.6× 更便宜；作者也说这些属于真实收益的高端。 | 标签不是独立的人类真值；工作流出自能力团队；模型默认推理设置和封装影响公平性。 |
| Schema 合规 [1][5] | Jev 输出受预设选项限制；OpenAI 自有复杂 JSON Schema 评测中 GPT-4o-2024-08-06 加约束解码。格式合规率越高越好。 | Jev 的类型保证属于接口设计；OpenAI 在其自有评测报告 100% Schema 合规，说明 GPT 也可可靠遵守格式。 | 两者的任务与 Schema 不同，不能横向拿百分比排名；格式合规不测语义真伪。 |
| 校准和语义正确 | 应按同一真实标注数据比较准确率、Brier、ECE、拒绝覆盖率与分布外错误。 | 本笔记没有可复现的 Jev 对 GPT 独立校准曲线或成对部署测量。 | 缺独立地面真值、消融、训练资源、长期故障率和多语言压力测试。 |
该选哪一个，取决于你要输出什么
Jev 的有利场景：一个已知状态要回答很多相互独立的窄问题，代码先定义候选项，再根据概率、成本和风险分流。这样可减少不必要的生成步骤。文档把图像、音频、视频列为暂不支持的输入；英文是目前表现最好的语言，中文任务应单独测。[2][10]
产品约束：官方发布称直接 Choice 最多支持 255 个候选项，更多选项需要分阶段评分和选择。发布时列出的价格为每百万输入 Token 0.042 美元，输出不单独计费；这是厂商报价，不是 Jev 的真实硬件成本证明，也不能与不同任务的 GPT 每 Token 单价直接比较。[1][10]
GPT 的有利场景：输出空间事先不知道、需要解释、生成代码、长文写作、多步推理，或希望在一个模型中处理多种任务。严格 Schema 能解决许多类型问题，但不会给每个字段自动提供经过外部核验的语义概率。使用更强推理也可能提高判断质量，代价是额外的时间和费用。[5][7]
共同风险：遇到缺失证据、提示注入、模糊标签或分布变化，两类系统都要通过独立测试和应用侧的拒绝路径。Jev 的“每题独立”限制了同一批次里题目之间的真实依赖；GPT 的多步骤工作流则需要检查自由文本、Schema 和工具调用结果。两者不是一个绝对替代关系。
怎样做一项能验证的项目小实验？
以你的论文资料库为例：先把文章元数据、摘要和链接构成 state，提出“是否主要讲 PBD”“是否有可复现的代码”“是否需要人工核实引用”等窄问题。Jev 返回概率后，代码做阈值分流；GPT 只在需要写摘要或解释原因时介入。不要让“论文链接是否真实”成为无证据的模型猜测，要通过 DOI/原站检查。
固定 200–500 条人工标注样本、同一输入和输出 Schema；同时测试 Jev、GPT + Structured Outputs、简单关键词/规则基线。报告：宏平均 F1、每类混淆矩阵、Brier、可靠性图、端到端 p50/p95 时延、实际账单、拒绝率。对中文资料和新领域各留一组独立测试，并记录模型版本及提供商区域。只在达到目标精度时比较速度，才能回答“对我的系统是否值得”。
先做小规模离线评测。Jev 的公开源码适配器可用于统一接口比较，但不能代替使用真正的 Jev API 评测其模型。