一般

TypeSafe AI 发布 System One 模型 Jev

1
作者TypeSafe
来源跳转
发表时间

内容

多年来,模型在聊天方面已经超越人类,那么自动化究竟在哪里?

这是我过去四年一直在追问的核心问题。在 OpenAI 期间,我帮助构建了让语言模型能够遵循指令并与人交流的方法。这项工作最终成为 ChatGPT 的研究基础。当时,我以为对话模型可能会通向通用人工智能(AGI),但尽管 hype 不断,我逐渐意识到有一个非常关键的东西缺失了。

经过两年的潜心研发、无数的技术挑战和科研突破……我非常激动地宣布,TypeSafe AI 今天正式发布我们的首个 System One 模型:这是一类全新的前沿模型,专门为实现软件可直接使用的快速、结构化决策而构建。

我们构建了一个完全专注于自动化的全新技术栈:采用全新的模型架构、并行采样器以实现最大效率,以及我们称之为"校准决策强化学习"(RLCD)的训练方法。

我们的首个公开模型是 Jev,今日正式开放早期访问。Jev 在 System One 任务上实现了与现有 LLM 相当的智能水平,同时速度快了两个数量级,效率也更高。虽然 Jev 放弃了字符串生成能力,但它针对结构化输出进行了优化,不会产生幻觉。

可以把 Jev 看作一个前沿智能的函数调用:输入非结构化状态,输出带类型的概率决策。

非凡的主张需要非凡的证据,请往下看我们的证据。💅

新旧前沿

现有 LLMSystem One + Jev
优化方式基于人类反馈的强化学习(RLHF)/基于可验证奖励的强化学习(RLVR)校准决策强化学习(RLCD)
优化目标人类偏好:人类评估者更喜欢的撰写内容和对话回复。 可验证奖励:可以通过程序化方式验证的输出。校准决策:在 System One 任务上具有认知诚实概率的答案。
输入非结构化数据(如文本),强调顺序消息非结构化数据(如文本),强调结构化程序状态
输出字符串/生成的文本。 字符串非常灵活,可以是任何内容:对话回复、代码、幻觉、拒绝,甚至类型安全的结构化值。要被软件使用,回复需要解析+验证。此外,AI 总是存在偏离轨道的风险。类型安全的结构化值。 可能的输出和结构在事先定义。模型永远不会产生类型错误。所有答案都附带校准后的概率和置信度分数。
采样方式顺序。 一次生成一个 token,每个 token 都依赖于前一个。并行。 在单次查询中生成所有输出。极其高效且硬件感知。
成本输入 token:0.200.20 到 10 / MTok。 输出 token:大约是输入 token 成本的 5 倍。输入 token:0.042/MTok(每十亿token0.042 / MTok(每十亿 token 42)。 输出 token:免费(几乎可以忽略不计)。
速度端到端响应时间 前沿模型为3 到 329 秒。对于与人交互来说足够快,但集成到代码中时是很大的瓶颈。端到端响应时间为 70ms-500ms。对于相同前沿智能水平的 System One 形状查询,速度可快 40 倍到 200 倍。
置信度即使提示模型给出置信度估计,它们往往过度自信且不一致。如果一个模型有 95% 的时间能完成任务,但在处于 5% 的失败情况下没有说明,就无法自动化该任务。每个输出都始终传达置信度和不确定性。已校准:更高的置信度意味着更高的准确率。更一致:对于相似输入返回相似答案。
使用场景人机协作任务(聊天机器人、编程助手、编码代理)。 通用且强大,但需要人类监督,因为它们的自由度也意味着可能会偏离轨道。 可验证问题(数学证明、内核优化)。 当正确性可以被低成本自动检查时,LLM 可以生成、测试和迭代,直到找到可行的方案。 演示。 字符串的灵活性使其非常适合快速制作有时有效的原型。AI 驱动的工作流/智能 if 语句。 结构化输出可以作为模糊决策规则插入普通软件:分类、路由、打分、提取,或在手工逻辑过于脆弱的地方进行分支。周围代码限制了它们的自由度,使它们更容易组合成可靠的系统。 大数据 Map-Reduce。 将 PB 级数据转化为特征和洞察。 实时应用。 100ms 的速度意味着你可以在用户体验至关重要的应用中使用 AI。** 验证一切。** 对 LLM 提示、推理过程和/或输出进行打分、判断、验证、护栏和越狱检测。

证据/技术结果

我们欢迎怀疑论者,我们自己也是。

有些主张你可以轻松验证:

  • 每次调用速度: 我们确实这么快,尽管我们发布的评测通常是从西海岸的笔记本电脑上运行的(这是我们服务目前所在地)。
  • 每次调用成本: 我们公开透明定价。我们无法证明它没有补贴;我们需要长期时间来证明我们定价的可持续性(我们预计价格会下降,而不是上涨)。
  • 无类型错误: 这是一个很容易被单一反例证伪的事情,但数学上不可能出错。

对于我们更大胆的主张,我们希望尽可能提供更多细节。

并排演示

我们的并排演示展示了我们模型与 LLM 之间的关键差异:Jev 并行输出所有概率,而不是自回归地逐 token 生成。字符串非常强大和通用,但代价高昂。"放弃"字符串实际上赋予了我们很多超级能力!

细节说明
  • 对于已获得 TypeSafe 早期访问权限的用户,这里有实际查询
    • 查询经过了高度简化,questions 被选择具有描述性的、人类可读的键,以便屏幕上的输出易于理解。
      • state 也是一段简短、密集且详细的段落,以强调采样方法的差异。相对较短的输入使我们的模型显得更有优势。
  • 对于眼尖的人来说,在录制运行时,唯一与 GPT-5.6 Terra 不一致的地方是"流失可能性级别"。对我们来说,实际答案看起来确实有些模糊。
  • 我们在这个例子中使用了默认推理的 GPT-5.6 Terra,因为我们发现它在平均智能水平上与 Jev 最具可比性。
  • 有趣的事实:一个类似的演示说服了我们全力投入 System One 模型的方向!

工作流评测

我们创建了一种新型评测来衡量 AI 在代码中的表现。我们不针对 ground truth 分类进行优化,也不允许评测框架和模型改变(这可能会通过框架工程导致过拟合)。相反,我们假设存在一个正确的计算图(一个用代码表示的"工作流"),并使用最大、最聪明、最昂贵的外部模型的预测作为参考概率。

换句话说:每个模型获得相同的工作流。我们测试它们与最聪明模型的平均水平相比如何(在这种情况下是 Astra 和 Fable)。

Jev 表现超群——在近两个数量级上占据了帕累托前沿。我们还与使用生成提示在思维链中完成所有逻辑的模型进行了比较,但这往往比直接使用工作流本身要差得多。

请注意,这里的调用比上面的并排演示要复杂得多。这是因为它们更能代表真正的业务自动化所需的生产级工作负载类型。以下是我们发布的 4 个工作流中最简单的一个:

最可靠的真实世界工作流往往有许多独立的、分解后的问题,其精细行为依赖于概率而非离散决策。最终结果是离散分支,但我们如何得出最终答案涉及大量需要高度一致执行的领域特定工程。

请查看我们的工作流评测网站了解所有细节:示例、不一致之处、完整查询和每个工作流。

细节说明
  • 这就是我们的主页上 193.6 倍更快、444.6 倍更便宜的声称来源,我们预计这些是现实世界收益的上限。
  • 这些工作流的内容不是人为选择或构建来让我们的模型看起来更好的,也不在我们的训练分布中。然而,它们是由我们模型能力团队的成员创建的,因此可能存在一些偏差。
  • 我们使用 GPT-6 Astra 和 Fable 5.1 的平均值作为参考答案,这使答案偏向 OpenAI 和 Anthropic 的模型。我们可能低估了我们模型和 DeepSeek 模型的相对性能。
  • LLM 使用我们的 System One LLM 包装器,将 LLM 约束为输出与我们 API 兼容的结构化决策。我们发现这是从 LLM 获取决策最准确的方式,但这往往比不带概率的决策更慢、更昂贵。

幻觉和类型安全

幻觉和类型安全本质上是相关的,我们认为后者是自动化的基本要求。在 agent 中产生幻觉的工具调用是不方便的,但如果它是具有延迟保证的系统的一部分,或者深埋在几层依赖链中,那就是绝对的 deal-breaker。现有的模型,无论多聪明,仍然会产生幻觉和类型错误。

细节说明
  • LLM 的数字来自 OpenRouter,即几乎肯定存在偏差:更复杂的查询可能被路由到更好的模型。
  • 我们的数字不是经验性的。Schema 匹配是有保证的,因此我们可以自信地在图表中加入 0%。

有趣的演示

也许我们工作最令人兴奋的部分是实现新的使用场景。我们还有很多要展示的,但这里有几个团队的最爱:

Doom

我们喜欢这个 demo 展示了实时智能以及代码+AI 可以做什么。背后的工程师担心能否达到每秒 10 次查询(最终成本约为 $7/小时),但我们其他人一致认为这比预期的要低!这太有趣了,我们不仅打算发布详细的使用教程,还打算举办一些活动来hack这个项目。

细节说明
  • Demo 展示的是作为数据结构的结构化状态(包含文本),而不是图像(目前)。
  • 非 AI 的 doom bot 可以玩得更好,但我们想要一个能对不同游戏状态表示做出反应的 bot,最重要的是……遵循指令实在太酷了!

维基竞速

游戏的目标是,从一个 Wikipedia 页面开始,仅使用遍历过程中遇到的链接到达特定的另一个 Wikipedia 页面。每一步都意味着要在数百到数千个链接之间做出选择!这是展示每秒智能的绝佳场所,也是展示在高基数选择下不产生幻觉的复合效益的绝佳场所。

细节说明
  • 据我们所知,第二和第三个挑战都以"Rubber Duck"开头完全是随机的。作者直到团队指出后才注意到。
  • 我们在这里的加速效果往往比之前的演示要小得多。这是因为这是针对模型的非推理模式(除了 Astra 设置为最低推理设置)。这也是为什么 Jev 往往以更少的步数完成(这是更高智能的标志)。这是为了让演示更易于观看。启用了推理的 LLM 在这个任务上看起来要差得多。
  • Jev 支持高达 255 的基数。对于更高基数的选择,我们采用两阶段系统:先独立打分,然后做出明确选择,因此偶尔会出现减速。

下一步

Jev 还处于早期阶段。我们有更多的东西在筹备中,非常激动能够继续发布。🔥

今天,我们开放早期访问,并尽快将开发者从候补名单中移出。我们想听听你需要自动化哪些决策,Jev 在哪里有效,哪里不足。告诉我们你想构建什么样的科幻应用!!

我们创立 TypeSafe 是因为我们相信 AI 需要一个软件可以依赖的接口。迫不及待地想看到新的使用场景不断扩散到社区和经济中。

评论

(0)
未配置登录方式
暂无评论