Workday 使用 Jev 模型利用预制组件实时构建 Sana 界面

Workday 已开始使用 TypeSafe 的 Jev 决策模型，在用户于其人工智能助手 Sana 中输入内容时构建动态变化的用户界面。Sana 已成为 Workday 人力资源、财务和信息技术软件的新主页，系统管理员可以向用户提供 Sana，但不必将其设为默认界面。

在一次演示中，关于工资单的提问显示出一张需要点击后才能显示金额的卡片；而休假申请则生成了日期选择器，Sana 填写了其余字段。其核心理念并不是让语言模型完整编写一个全新的界面，而是让它从 Workday 预先准备好的设计系统中选择组件。

选择组件，而不是生成界面

Workday 首席人工智能官兼 Sana 创始人 Joel Hellermark 表示，生成式界面的常见方法相对缓慢。根据演示说明，Workday 将设计系统中的每个原子组件提供给 Jev，而没有为每种情况编写固定的选择逻辑。但团队还需要调整数据预加载；演示中，工资单卡片在问题输入完成之前就已出现。

TypeSafe 表示，Jev 的响应时间在 70 至 500 毫秒之间，因此适合实时选择界面元素。开发者向模型发送应用数据和一组类型明确的问题，模型会从最多 255 个选项的列表中返回一个选择、一个分数或是非答案，并为每个结果提供概率。Jev 不会生成文本。

实际会发生什么变化？

这种设计将界面任务的一部分从开放式生成转变为受控分类。这样，应用可以显示已知且可测试的元素，而不必每次都等待语言模型编排新的结构。Workday 之外公布的测试显示，速度可能存在明显差异：Very Good Ventures 的 Andrew King 表示，在具有明确答案的问题中使用 Jev，将生成式仪表板的中位渲染时间降至 3.8 秒；而使用高级模型构建该仪表板时为 29 秒，测试使用的是合成数据。

在 Banking77 数据集上的测试中，Jev 的中位耗时为 175 毫秒，准确率为 81%。Claude Opus 5 的准确率为 84.4%，但耗时 2.3 秒，成本则根据消息来源高出约 22 倍。

限制与悬而未决的问题

TypeSafe 的文档指出，Jev 在计数、计算和日期方面存在困难，并且可能倾向于选择列表中排在第一位的选项。此外，它不会默认将注入内容视为恶意内容。在部分实验中，当 Jev 的置信度低于 50% 时，会使用备用语言模型，这限制了其决策范围，而不是让它生成任何可能的形式。

Workday 没有说明 Sana 所使用的设计系统规模，也没有说明当请求不适合任何可用组件组合时会发生什么。Workday 还将 TypeSafe 加入了能够处理客户数据的分包商名单。目前，TypeSafe 可应要求提供 SOC 2 Type II 报告，但消息来源并未证实有关保护架构或数据保留政策的更多细节。

这一步属于决策模型领域更广泛竞争的一部分；OpenAI、Amazon、Cloudflare 和 Perplexity 已推出类似模型，Microsoft 也在上周加入其中。TypeSafe 于 9 月 15 日推出 Jev 模型，并完成了由 DCVC 领投的 4000 万美元种子轮融资；随后又宣布完成由 Andreessen Horowitz 领投的 8.7 亿美元 A 轮融资，公司估值达到 75 亿美元。