# Jev 和决策模型的兴起：系统一号人工智能对安全工具意味着什么 > TypeSafe AI 表示，其新模型 Jev 可以在几毫秒内给出经过打字、校准的决定而不是段落的答案。这正是所声称的内容、其含义以及仍需要独立测试的内容。 HisnLabs Security & Research Team · Published 2026-09-25 Canonical: https://hisnlabs.com/zh/blog/jev-system-one-decision-models 2026 年 9 月 25 日，TypeSafe AI 发布了 Jev，这是其所谓的“System One”类别中的第一个模型：不是聊天机器人，也不仅仅是一个更大的语言模型，而是该公司所描述的决策模型 - 旨在通过键入的、经过校准的答案而不是一段散文来回答有界问题的模型。该公告充满了具体的数字，因此本文完全按照所声称的那样进行了介绍，清楚地标记了我们可以验证和无法验证的内容，并探讨了为什么决定而不是生成的基本想法值得认真对待，特别是对于安全软件而言。 ## TypeSafe 实际宣布了什么 TypeSafe AI 由 Diogo Almeida 创立，他在公告中写道：“在 OpenAI，我帮助构建了一些方法，使语言模型在遵循指令和与人交谈方面变得有用。” Jev 被称为该公司的“第一个公共模型”，它被定位为一项完全不同的工作：生成 TypeSafe 所谓的具有校准概率和置信度的类型安全结构化值，这些值是通过所谓的并行采样器而不是通常的逐个令牌解码生成的，并使用该公司称为校准决策强化学习（RLCD）的方法进行训练。 - TypeSafe 报告的端到端响应时间为“70 毫秒至 500 毫秒”，而与 Jev 相比的前沿语言模型测得的响应时间为“3 至 329 秒”。 - TypeSafe 将输入代币定价为“$0.042 / MTok”，输出代币列为免费。 - 在其自己的工作流程评估中，TypeSafe 报告 Jev 的运行速度比其衡量的策略“快 193.6 倍，便宜 444.6 倍”。 - TypeSafe 将 Jev 输出中的类型错误描述为“数学上不可能”。 - Jev 处于抢先体验阶段； TypeSafe 表示，它正在“尽快将开发人员从候补名单中剔除”。 > **Note:** 上面的每个数字都是 TypeSafe 自己的声明，取自其公告和评估页面。 FireAI 背后的团队 HisnLabs 尚未运行 Jev，无法访问它，也没有独立复制任何这些数字。本文中的任何内容都不应被视为 HisnLabs 证实了这些观点，而只是报告了 TypeSafe 所说的内容，并推理了如果它成立将意味着什么。 ## 一代与决策 所谓的“人工智能在生产中”的很大一部分实际上根本不是写作任务。允许或阻止连接。升级或关闭票证。标记或清除交易。将消息路由到一个队列或另一个队列。所需的输出不是散文，而是从简短的固定列表中提取的标签，有时还附有分数。通过为生成流畅段落而构建的模型来运行此类问题是不匹配的：返回的 JSON blob 必须经过解析并希望其有效性，并且任何声明的置信度往往没有什么特别的意义，因为没有任何东西强迫它跟踪模型的实际错误率。 这里有两个声明值得分开，因为它们不是同一件事：打字和校准。键入的输出限制了答案的形式——“选择”问题返回列表中的选项之一，“分数”返回声明范围内的数字，而不是杂散的句子或发明的字段。校准是一个更古老且完全独立的想法。它是一种统计属性，而不是风格属性：这意味着当系统给出的概率为 0.62 时，在许多类似的预测中通常都是正确的，因此下游程序实际上可以对该数字进行阈值处理，而不是将其视为装饰。 TypeSafe 的命名借鉴了心理学而非统计学的词汇。 [丹尼尔·卡尼曼](https://en.wikipedia.org/wiki/Daniel_Kahneman)因“将心理学研究的见解整合到经济科学中，特别是关于不确定性下的人类判断和决策”而获得2002年诺贝尔经济学奖，他在[思考，快与慢](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow)中普及了这些术语：“系统1”是“快速、自动、频繁、情绪化、刻板、无意识”，而“系统2”是“缓慢、费力、不频繁、逻辑、计算、有意识”。这个比喻很令人回味，但它描述了人类的认知，而不是对软件的保证。模型可以像系统 1 一样快，但其声明的置信度没有任何意义——校准必须通过获得和测量来实现，而不是通过名称来暗示。 ## “不能产生幻觉”可以和不能意味着什么 TypeSafe 声称类型错误“在数学上是不可能的”是在描述约束解码，这种技术在其他地方已经存在。 OpenAI 自己的结构化输出指南也做出了类似的保证：该功能“确保模型始终生成符合您提供的 JSON 架构的响应，因此您无需担心模型会省略所需的键，或产生无效的枚举值。”这种保证是真实且有用的。它也比听起来更窄：它限制了答案的形状，而不是答案是否正确。具有三个选项的“选择”问题将始终返回三个选项之一 - 包括，如果模型误判了输入，则返回一个自信的、有效输入的错误答案。 校准是必须检查的部分，而不是断言的部分。标准工具是可靠性图：根据其声明的置信度进行桶预测，以及对于每个桶图，这些预测实际上被证明是正确的频率；对角线和观察线之间的间隙通常总结为预期校准误差。这对于机器学习来说并不是一个新问题——[郭等人2017年论文《On Calibration of Modern Neural Networks》](https://arxiv.org/abs/1706.04599) 发现“现代神经网络……默认情况下校准很差”，而一种称为温度缩放的简单单参数修复在修复它方面“非常有效”。该课程总结了一篇论文：校准不是模型可以宣布其自身的属性。这是你在自己的标记数据上检查的东西，因为它往往会在你最需要的地方降级——在看起来不像模型所调整的输入上。 ### 最小的评估工具（模板） 在通过任何决策模型（Jev 或其他）做出真正的决策之前，三个问题比任何供应商数据更重要：输入的答案是否每次都会根据您的模式进行解析，声明的置信度是否跟踪其在您自己的数据标记样本上的真实命中率，以及该校准是否能够在与模型已经看到的输入不同的输入上生存。下面的草图是围绕 TypeSafe 自己的快速入门文档中显示的请求形状构建的模板。它没有声明针对 Jev 运行它会显示什么——我们还没有运行它，这是说明性的伪代码，而不是报告。 *calibration_check.py — 仅模板，不针对 Jev 运行* ```python # Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's own # quickstart docs (POST /v1/systemone with state, model, and typed questions). # Not run against Jev or any live API; no results are claimed here. import requests def ask(state: str, question_id: str, question: dict) -> dict: resp = requests.post( "https://api.typesafe.ai/v1/systemone", headers={"Authorization": f"Bearer {API_KEY}"}, json={"state": state, "model": "jev-latest", "questions": {question_id: question}}, ) return resp.json()["answers"][question_id] # 1. Shape check: does every response parse against the declared type, on your # own edge cases, not just a vendor demo set? # 2. Calibration check: bucket the stated confidence and compare it to the # true label rate, on data the model has never seen. buckets = {i: {"n": 0, "correct": 0} for i in range(10)} for state, true_label in labeled_sample: # your own traffic, labeled by hand answer = ask(state, "decision", {"type": "noul", "instructions": "Should this be allowed?"}) bucket = min(int(answer["noul"] * 10), 9) buckets[bucket]["n"] += 1 buckets[bucket]["correct"] += int(round(answer["noul"]) == true_label) for b, s in buckets.items(): if s["n"]: stated = (b + 0.5) / 10 observed = s["correct"] / s["n"] print(f"stated~{stated:.2f} observed={observed:.2f} n={s['n']}") # the gap here is your calibration error ``` - 键入的答案是否始终解析您自己的系统产生的输入，而不仅仅是供应商的演示集。 - 在您自己的标记流量上，而不是在其他人的评估集上，所规定的 0.9 是否正确大约十分之九。 - 这种校准是否适用于与以前见过的任何输入不同的输入：新应用程序、新协议、阅读了您刚刚阅读的相同公告的发送者。 - 调用者在超时或中断时执行的操作，因为当决策模型无法访问时，决策系统需要安全默认值。 ## 为什么这对安全工具很重要 防火墙、垃圾邮件过滤器、欺诈检查、分类队列：其中每一个都是一个决策系统，一遍又一遍地回答相同形状的问题 - 给定此输入，允许或阻止它，有多少置信度以及阈值所在。 TypeSafe 自己的评估页面正是从这个领域中汲取了例子：判断是否关闭安全警报、将其升级给某人或立即遏制它是一个分类决策，而不是一个编写任务，而且这是安全工具不断发出的那种调用，其数量是分析师无法手动审查的。 | | 生成式 LLM 答案 | 类型化决策（Jev 式） | | --- | --- | --- | | 输出 | 解释与不常见端口上的陌生地址的连接的段落“可能值得审查” | { 允许：假，置信度：0.81 } | | 解析 | 正则表达式，或第二个模型调用，从散文中提取动作 | 保证与声明的模式匹配 | | 阈值化 | 没有数字置信度可与政策进行比较 | 调用者可以直接设定阈值的置信度值 | | 失效模式 | 流利、听起来合理，但有时根本就是错误的 | 附加的数字有误，校准检查至少可以平均捕获该数字 | *说明性比较，不是任何真实系统的抄本。* ## 老实说，隐私权衡 正如 TypeSafe 所描述的那样，Jev 是一个托管 API：请求通过互联网向 TypeSafe 的服务器携带“状态”，即问题涉及的任何数据。对于 TypeSafe 本身强调的安全事件和分类示例，该状态正是许多人不愿意在默认情况下交给第三方的信息 - 哪个应用程序正在与哪个地址、从哪个设备通信的频率。将其发送到任何云模型，无论速度有多快或成本有多低，都意味着数据会离开其来源的机器。 > **Warning:** 这并不是针对 TypeSafe 的批评——对于每个托管模型（生成模型或决策模型）都是如此。这种权衡是在调用远程 API 时内置的，这并不是这个特定设计中的缺陷。 FireAI（HisnLabs 自己的 macOS 防火墙）对于本文所涉及的确切决策类别做出了相反的选择。 FireAI 在 macOS 14 或更高版本上运行，一次性售价 49 欧元，并且显然不是防病毒软件，也不是 VPN。当您以前从未见过的应用程序尝试连接网络时，FireAI 可以在设备本身上运行一个小型模型（可选的 1.5 GB 下载）来检查该连接并提示您附上简单语言的原因；正在审查的流量永远不会发送到任何地方。每一个人工智能辅助决策都成为一条可见的规则，与应用程序的代码签名相关联，您可以查看和撤消这些规则，并与本地应用的威胁源一起放置，而不是针对远程服务器进行查询。 我们并不是说 FireAI 的设备上模型在原始正确性、速度或价格方面与 Jev 或任何其他系统单一模型相匹配 - 我们尚未进行比较，也没有我们自己的评估可在此发布。此公告所支持的是一个设计方向：安全决策可以通过靠近数据运行的小型、快速、有界模型来很好地服务，而不是通过其他地方的通用聊天机器人来路由。 TypeSafe 正在从 API 方面进行论证； FireAI 已经从设备端建立在它的基础上，并且出于不同的原因 - 因为特别是对于防火墙来说，有问题的数据根本不应该离开机器来进行判断。 ## 开放式问题 - 独立评估：尚未有任何外部方针对 TypeSafe 未选择的数据发布 TypeSafe 公告中速度或成本倍数的复制品。 - 分布转移下的校准——郭等人的论文所讨论的确切场景，也是对于一旦防御方法公开后就会适应的对手来说最重要的场景。 - 定价是否符合实际产量，以及规定的延迟是否在持续负载而不是单个演示的请求下保持。 - 模型如何处理对抗性或真正模糊的输入，其中自信的输入答案可能不如“不清楚”的答案诚实。 - 当早期访问超出等候名单时，向谁以及在什么条件下以“状态”发送数据。 目前，Jev 是一组来自具有真实资质且尚未经过外部验证的团队的声明。它试图命名的类别是决策模型而不是生成模型，它指出了迄今为止安全软件如何使用人工智能的真正差距。无论 Jev 本身是否经得起独立测试，这都是一个有用的提醒，即防火墙、欺诈过滤器或分类队列的有趣问题从来不是“它能否写出令人信服的句子”，而是“它能否做出可以支持的决定，速度足够快，足以发挥重要作用”。这就是我们每次更改 [消防人工智能](https://hisnlabs.com/fireai/zh/download) 中的设备上模型时都会提出的问题 - 这就是为什么对我们来说，答案保留在设备上，而不是成为对其他人的 API 的请求。 ## FireAI 和 HisnLabs 在其中扮演的角色 We have not tested Jev and make no claim it works as described or that FireAI matches it in any way — but the idea that a security decision deserves a small, bounded, fast model instead of a paragraph from a chatbot is one we built FireAI around a year before TypeSafe wrote a blog post about it. FireAI 是 HisnLabs 自己的产品：一款直接在 Mac 上运行的 AI 防火墙。它用通俗易懂的语言显示你的应用建立的每一个连接，并让你决定哪些数据可以离开你的 Mac——它的 AI 在本地运行，因此你的流量永远不会发送给我们或任何其他人。HisnLabs 的安全研究团队负责让这些判断保持准确：归类哪些域名只是普通的遥测、哪些属于真正的服务，追踪连接背后的国家和网络，并用真实的流量模式训练设备端模型（FireAI Pilot 功能）——这一切都不会离开你的 Mac。 你可以阅读它背后的技术决策，或试用 FireAI 17 天：[HisnLabs 出品的 FireAI](https://hisnlabs.com/fireai/zh/download)。 ## Sources - [TypeSafe AI: Introducing System One Models and Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) - [TypeSafe AI docs](https://docs.typesafe.ai/) - [TypeSafe AI: workflow evals](https://evals.typesafe.ai/) - [Wikipedia: Thinking, Fast and Slow](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow) - [Wikipedia: Daniel Kahneman](https://en.wikipedia.org/wiki/Daniel_Kahneman) - [Guo et al., "On Calibration of Modern Neural Networks" (arXiv:1706.04599)](https://arxiv.org/abs/1706.04599) - [OpenAI: Structured Outputs guide](https://developers.openai.com/api/docs/guides/structured-outputs)