Jev 企业人工智能缺失的控制层

Jev 的解释及其对人工智能企业的意义

与日常使用的大语言模型相比，Jev 并不生成文本。TypeSafe 公司构建它的目的是接受程序状态，并返回三种类型化的判断：选择、评分或判断陈述真实性的概率。

当人工智能可能需要修改记录、授予权限、释放资金或封闭端点时，这种更狭窄的接口就非常有用。应用程序需要一个有界答案，以便在执行前根据权限和策略进行测试。然而，无论推理多么严谨，一段文本都是错误的接口。

一个有用的是架构层面的比较。Jev 能否用一个应用程序可以验证、管理和记录的决策，来替代脆弱的提示与解析步骤？

对于某些企业工作流，我认为它可以。

我是 Oximy 公司的创始人兼首席执行官 Naman。我们通过连接人工智能活动和成本与已完成的工作，帮助企业识别人工智能在何处创造价值并衡量其交付成果。Jev 与这项工作相关，因为它生成了更结构化的模型判断记录。该记录可以支持行动前的治理和工作完成后的测量。

TypeSafe 的性能声称来自其自身的评估。目前尚无基础称其为一个完整的企业控制层。更恰当的理解是，它是一个决策组件，企业可以围绕它构建一个控制层。

Jev 实际上做什么

大多数生产环境中的智能体使用语言模型来完成两项不同的任务。模型解释一个模糊的情况，然后以应用程序可消费的格式表达决策。

第一项任务需要判断力。第二项则带来了不必要的风险。

团队通常通过请求 JSON、验证模式、重试格式错误的响应以及添加回退逻辑来管理这种风险。结构化输出功能已经改进了这种模式，但应用程序仍然在将一个文本生成模型调整为软件决策。

Jev 从决策本身开始。

应用程序发送相关状态和一个或多个类型化问题。TypeSafe 目前提供三种问题类型。

Choice 从列表中选择一个选项，并返回选择项、概率和置信度。Score 根据评分标准评估状态，并返回分数、概率和置信度。Noul 返回一个 0 到 1 之间的值，表示陈述的真实性概率。

TypeSafe 建议每个问题保持狭窄范围。如果一个决策依赖于多个因素，应用程序会分别询问每个因素，并在代码中组合结果。

考虑一个账户访问审查。应用程序可以询问请求是否与员工角色匹配、设备是否符合策略，以及是否有已批准的工单解释该请求。然后，代码可以应用公司的批准、拒绝或人工复核规则。

模型处理模糊的评估。公司控制着行动和连接评估与行动的策略。

TypeSafe 报告响应时间在 70 到 500 毫秒之间，早期访问的输入定价为 0.042 美元/百万 tokens。

低延迟和低成本可以使系统在工作流的更多节点评估更多条件。这增加了企业必须控制的机器判断数量。随着部署范围的扩大，治理需求也随之增长。

发布的安全工作流显示了 Jev 的定位

TypeSafe 发布了一个安全事件评估，使预期架构具体化。

该工作流读取警报、受影响资产、未解决的工单和变更请求、已注册设备、计划维护和现有授权。它询问活动是否未经授权、现有记录是否能解释它，以及证据的强度如何。

代码将这些答案与资产的重要性和环境相结合。响应来自一个固定集合——通知用户、升级到二级支持、终止进程、禁用账户或紧急升级。

Jev 提供概率性判断。它不定义响应类别、决定哪些机器是关键，或设置禁用账户的阈值。安全团队将这些决策保留在策略和代码中。

这种分工很重要。像“处理此事件”这样宽泛的指令，将解释状态、选择策略和选择行动的责任都赋予了模型。TypeSafe 工作流则分离了这些责任。每个模型问题都很狭窄，应用程序拥有最终的决策权。

同样的模式可以应用于安全以外的领域。财务工作流可能会询问发票是否与采购订单匹配，以及例外情况是否类似于已知类别。客户支持工作流可能会对退款资格进行评分，同时代码强制执行退款限额。访问工作流可能会评估上下文风险，而身份系统则强制执行角色权限。

这些都是合理的 Jev 候选场景，因为状态可以组装，判断可以被约束，并且可用的行动已经是已知的。

类型安全的输出仍然可能出错

TypeSafe 表示 Jev 不会产生类型错误。Choice 问题返回应用程序定义的选项之一。模型不会返回一段文章、格式错误的 JSON 或无法识别的行动。

这个保证消除了软件故障。但它并不保证判断的质量。

模型可能返回一个有效的 DISABLE_ACCOUNT 响应，而分析师本应将案例排入审查队列。应用程序可以完美解析答案，但仍然可能采取错误的行动。

TypeSafe 的安全评估包括了 Jev 与其他测试模型存在分歧的案例。它也包括了一个所有三个模型都错过参考答案的案例。TypeSafe 公布这些分歧值得称赞，因为它们展示了阅读该产品的正确方式：类型安全约束输出；它并不建立真实性。

企业审查应将以下四个问题分开：

有效性： 模型是否返回了一个允许的值？

质量： 模型是否根据提供的状态做出了正确的判断？

权限： 应用程序是否被允许基于该判断采取行动？

结果： 该行动是否以可接受的风险和成本水平改进了工作？

Jev 为有效性问题提供了一个强有力的答案。其概率和置信度可以帮助团队调查质量问题。企业仍然拥有权限和结果的衡量权。

控制层需要的不仅仅是决策模型

完整的决策路径应在系统设计中可见：

权限 → 状态 → 判断 → 策略 → 行动 → 证据 → 已完成的工作

权限定义了应用程序可用的行动。财务智能体可能准备付款但没有授权释放它。支持智能体可能在既定限额内批准退款。安全智能体可能隔离一个标准端点，但在禁用特权账户前需要批准。

状态应包含判断所需的记录，并受组织数据边界的约束。审查需要指定源系统、字段、标识符、保留期、编辑和处理位置。模型的质量无法弥补记录缺失、记录过时或数据边界不清。

Jev 只应属于模糊的步骤。确定性规则应保留在代码中。这保持了概率性表面的小型化，并为企业评估模型性能提供了一个清晰的立足点。

策略将模型输出转换为行动。团队应根据错误成本设置升级阈值。低影响的操作可以在批准的置信度水平下自动进行。高影响的操作可能始终需要人工干预。模型置信度应为策略提供信息，而非取代策略。

证据记录应保留源引用、问题定义、模型版本、返回值、策略版本、最终行动和人工干预。仅记录工具调用是不够的。它只显示了结果，而没有显示系统为何允许它。

最后一环是已完成的工作。事件解决、发票过账、访问审查关闭或客户案例完成，为企业提供了一个评估系统的业务记录。模型调用和智能体运行显示了活动。它们并未显示工作流是否得到改进。

我将如何评估 Jev 的生产就绪性

从一个重复发生的决策开始。其可能的输出应该是已经定义好的，并且组织应有一个现成的人工流程来与模型进行比较。

在构建集成之前编写决策契约。它应说明允许的输出、所需的状态、确定性规则、升级条件、保留的证据以及标记工作完成的记录。安全、法律、工作流所有者和工程团队应审查同一份契约。

首先以影子模式运行 Jev。让它评估实时案例但不执行行动。将其输出与运营人员做出的决策进行比较，然后逐一检查分歧。

有用的审查应将模型错误与状态和策略错误区分开来。模型可能接收了不完整的状态。正确的模型判断可能通过一个设计不佳的阈值。运营人员可能不一致地应用策略。单一的汇总准确率数字掩盖了这些差异。

特别关注置信的错误。它们决定了哪些行动可以安全地自动化，哪些必须保留人工复核。错误的成本比平均模型准确率更应影响该决策。

影子期结束后，只允许一小部分低影响的操作。保留一个独立于模型路径的终止开关。对问题和策略进行版本控制。在每次重大模型、数据或工作流变更后审查性能。

Jev 应通过观察到的性能来赢得更大的决策范围。早期访问状态和强大的基准测试无法替代这些证据。

对企业领导者的意义

CIO 应审视 Jev 如何改变应用程序架构。它是否替代了一个脆弱的解析步骤？确定性逻辑能否保持在模型之外？组织能否在不重建整个工作流的情况下更换模型或策略？团队能否在不失去本地控制的情况下跨业务单元复用决策模式？

CISO 应审视数据和权限。哪些记录进入状态？它们在哪里被处理？哪些操作可供应用程序使用？哪些操作需要批准？谁可以更改阈值？在事件或审计期间哪些证据仍然可用？

两者都应审查运营结果。系统多久升级一次？它消除了多少人工复核？哪些错误增加了？工作流是否更快完成？每个完成单元的成本是否变化？

这些问题比单独询问 Jev 是否比通用模型更快更有用。企业购买的是受治理工作流的性能，而不是单个端点的延迟。

Jev 的企业用例是狭窄的，但这很有用

在工作流包含重复的模糊决策、所需状态可用且可能的响应是预先已知的情况下，Jev 值得评估。

当任务需要长篇推理、相关状态无法组装或行动无法安全地约束时，它就不适合。在这些情况下，带有传统语言模型和人工复核的设计可能仍然是更好的选择。

Jev 提供了一种新的决策原语。企业仍然需要围绕它构建权限、状态边界、策略、升级、审计证据和结果衡量。

这项工作决定了 Jev 是成为一个有用的控制组件，还是仅仅成为一个更快的模型调用。