深入解读Thinking Machines的交互模型（17分钟阅读）

# 探究 Thinking Machines 的交互模型 来源：https://blog.bytebytego.com/p/inside-thinking-machines-interaction 运行 **npx workos@latest**，AI 代理将检查你的项目、检测你的框架，并直接将 AuthKit 添加到你的代码库中。 这不是一个通用的入门模板。该代理会读取你的实际应用，在合适的位置写入集成代码，然后执行类型检查并构建，以便在此过程中修复错误。AuthKit 为你提供托管式认证、可自定义 UI、多因素认证、社交登录、会话管理，并在你需要时提供通往 SSO 和 SCIM 等企业级功能的路径。 免费使用，最高支持 100 万月活跃用户。 立即尝试 → (https://go.bytebytego.com/WorkOS_063026) 如今，我们与 AI 进行实时对话的体验，是由众多协同工作的组件共同构建的。 其核心是一个以轮次方式工作的语言模型，就像你通过文字与 ChatGPT 交流时一样。响应能力则来自包裹在该模型周围的一层辅助系统，这些系统负责预测用户何时停顿、转录音频、从文本生成语音，并将这些片段快速拼接在一起，使对话感觉流畅自然。 然而，Thinking Machines 的最新研究认为，这套方法存在天花板，并提出了另一种构建实时交互 AI 系统的方式。 Thinking Machines 是一个相对较新的 AI 研究实验室，专注于人机协作，以 "Connectionism" 的名义发表研究成果，并为更广泛的社区提供面向开发者的产品。他们的与众不同之处在于他们识别的核心问题。大多数 AI 实验室将自主能力视为最重要的推进方向——即模型能够自行承接任务、独立完成工作并返回结果的能力。 Thinking Machines 认为，这种框架将人类置于次要地位。在他们看来，真正有价值的工作得益于持续的协作——人类在模型工作的过程中进行澄清、调整方向并提供反馈。界面应该支持这种协作，而不是将人类视为那种“分配任务后就走开”的角色。 在本文中，我们将探讨这个研究预览所涵盖的内容，以及 Thinking Machines 提出的“交互模型”概念。 *免责声明：本文基于 Thinking Machines 工程团队*公开分享的细节*。如有任何不准确之处，欢迎评论指出。* 问题始于当今模型实际上是如何感知世界的。一个典型的语言模型在单线程中工作。它需要等待用户完成输入（打字或说话）后，才能感知到输入内容。一旦模型开始生成响应，它的感知就冻结了，任何新的输入都会被排队等待稍后处理。 Thinking Machines 将这种情况比作通过电子邮件（而非当面沟通）来解决一个关键分歧。带宽实在太窄了。构成有效协作的诸多要素——你说话时声音的变化（当你不确定时）、你在说话途中意识到需要改变方向的瞬间、对方说了有用的话时你脸上的反应——所有这些，都在人与模型之间的信道中被剥离了。 这一点很重要，因为真正需要另一个头脑参与的工作，正是依赖于这种带宽的。 一个只能看到干净、完整输入的模型，会迫使人像模型一样思考：准备好完整的请求，交出去，然后等待。相比之下，真正的协作往往是混乱的、可中断的，并且充满了中途纠正。在界面允许这种协作之前，人类最终需要做额外的工作来适应模型的运作方式。Thinking Machines 认为，这个瓶颈解释了为什么当今许多 AI 工作感觉像是在“提示并等待”，而不是像两个人那样真正进行协作。 [](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbe13331a-b3a8-46b6-8d04-11ea10762f7e_2386x1538.png) 如果现在的语音 AI 尽管有这种限制却感觉是实时的，那这在很大程度上是如何工作的呢？答案是一种称为“背带”（harness）的模式。 一个典型的语音 AI 产品是由多个组件粘合而成的栈： - 语音活动检测（Voice activity detection）监听停顿，并判断用户何时停止说话。 - 语音转文本模型（Speech-to-text model）转录所说的内容。 - 语言模型（Language model）生成文本响应。 - 文本转语音模型（Text-to-speech model）将该响应转换回音频。 - 对话管理器（Dialog manager）编排整个管道，使得延迟感觉可以接受。 想象一位才华横溢的学者，他只能通过塞在门下的纸条与人交流。要让这感觉像一场对话，就需要助手。一个助手站在门外，倾听访客何时停止说话；另一个助手在学者回信时大声朗读；第三个助手在有需要学者知道的可见事件发生时摇铃。 这种设置基本上可行，但学者仍然是通过信件来体验现实的。语音语调、面部表情、当下这一刻本身，所有这些都超出了学者的感知范围。这实际上就是每一个实时语音 AI 的现状：以一个基于轮次的（turn-based）语言模型为核心，周围环绕着模拟对话的辅助系统。 [](https://substackcdn.com/image/fetch/$s_!RUcZ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F212e2016-c177-407d-9a07-e37e91fa34a9_3094x1444.png) 为什么这种方法有天花板？ 因为辅助系统比模型本身更简单。语音活动检测是在原始音频信号上运行的，使用的模型比其背后的语言模型更小、更轻量。这就限制了整个类别的行为。 该系统难以处理诸如“如果我说错了，就打断我”这样的主动插入请求，因为负责决定何时说话的辅助系统仅基于声学信号运行，而“正确性”则是语言模型的任务。像“告诉我，我写的代码里有 bug”这样的视觉反应也面临同样的问题，因为辅助系统处理音频，而屏幕上的任何内容都超出了它的范围。 这就是 Thinking Machines 指出的一个重要教训。根据 Rich Sutton 的一篇著名文章，利用通用计算和学习的方法，始终优于那些内置人类设计启发式规则的方法。同样的论点导致了从手工设计的计算机视觉特征转向深度学习，以及从手工设计的游戏启发式规则转向自对弈。将其应用于交互性，“背带”组件正是那种最终会被规模效应淘汰的手工启发式规则。突破天花板的方法，是将交互性内置于模型本身之中。 [](https://go.bytebytego.com/Datadog_063026) Datadog 和 Dust 分享了统一可观测性如何为工程师提供对整个基础设施、日志和应用程序的全面可见性，从而更快地发现问题并缩短平均修复时间（MTTR）。观看这场**点播网络研讨会**，了解 Dust 如何通过将可观测性上下文引入其 AI 工作流，将复杂的故障排查从数小时缩短到几分钟。 你将了解到： - 统一可观测性如何将基础设施健康度、日志和应用程序连接到一个单一视图中，以加快事件解决速度 - Dust 如何使用 Datadog MCP 将可观测性上下文直接引入故障调查 - 在构建 AI 时代应用的同时，维护可靠性的实用策略 观看网络研讨会 (https://go.bytebytego.com/Datadog_063026) 那么，将交互性内置于模型中，实际上是什么样子的？ Thinking Machines 的答案是他们称之为“交互模型”的系统。第一个版本名为 TML-Interaction-Small，是一个 2760 亿参数的混合专家模型，在任何时刻有 120 亿参数是活跃的。名称中的“小”指的是它在其计划的产品线中的位置，预计未来会有更大的版本。 大多数多模态系统都是从文本开始，然后在其上添加音频和视频。 Thinking Machines 反其道而行之，从连续的音频和视频开始，因为实时对话在严格的实时约束下运行，而文本可以避免这些约束。首先针对最困难的情况进行设计，使得他们拥有一个能够在所有模态上处理并发输入和输出流的架构。 参见下图： [](https://substackcdn.com/image/fetch/$s_!ivwV!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F91b85452-005e-413d-9228-9504bf7935ea_1894x2046.png) 这一架构背后有三个设计选择： - 第一个是时间对齐的微轮次（time-aligned micro-turns），它改变了模型将什么视为对话的基本单元。 - 第二个是一种方法，它跳过了大量预训练的编码器，音频和视频通过从零开始训练的轻量级处理组件处理，而不是通过像 Whisper 这样的独立系统。 - 第三个是一种双模型协调方案，其中快速交互模型与处理更深层推理的较慢后台模型协同工作。 Thinking Machines 还为优化此设计的推理做了大量工作，包括向开源 SGLang 库贡献了一个流式会话特性，使得能够高效处理 200 毫秒的数据块。 大多数 AI 模型以轮次工作：用户说话，然后模型说话，然后用户再说话。每一轮都是一个离散的单元，模型一次处理一个完整的轮次。即使系统处理音频，其底层逻辑仍然是基于轮次的。“背带”模拟了实时性，但模型本身是以清晰、分离的数据块来感知世界的。 Thinking Machines 做出了不同的选择。 他们没有使用轮次，而是将时间切割成 200 毫秒的块，称之为“微轮次”。每 200 毫秒，模型会摄取通过音频、视频和文本流到达的任何输入，并决定通过音频和文本流输出什么。时间成为了基本单位，完全取代了轮次。 [](https://substackcdn.com/image/fetch/$s_!tTek!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6ae330a8-6951-4d4b-8935-197814c1d8c6_2146x1478.png) 这听起来像是一个微小的改变，但它彻底改变了模型的能力。模型将时间视为连续的，而不是分割成清晰的轮次，它逐个微轮次地决定是说话、倾听、插话还是保持沉默。输入和输出同时持续进行。 具体来说，这就是解锁基于轮次的系统难以处理的行为的原因。 - 模型可以一边说话一边听——这就是实时翻译的工作方式。 - 模型可以一边说话一边看——这就是体育实况解说的方式。 - 当有视觉事件发生时，它可以在句子中间插话——比如实时计算某人做俯卧撑的个数。 - 它还可以支持诸如“听到我发音错误时实时纠正”之类的任务，这需要边说边听，而这在基于轮次的架构中是被作为分离操作处理的。 这些能力都源于同一个来源，由同一个架构选择产生。 时间对齐的微轮次解决了响应性问题，但也带来了一个新问题。 一个旨在 200 毫秒窗口内响应的模型，如何也能进行深度推理？ 有些任务确实需要几分钟的思考、网络浏览、工具使用或链式推理步骤。构建一个同时处理快速响应和深度思考的单一模型是很困难的。 Thinking Machines 的答案是使用两个模型协同工作： - 交互模型（Interaction model）速度快、实时在场，处理实时对话。 - 后台模型（Background model）速度较慢，处理持续的推理、工具使用、网络浏览和更长线的工作。 它们彼此共享上下文，因此两者对已经说过的话和当前正在发生的事都有相同的图景。 [](https://substackcdn.com/image/fetch/$s_!PgYD!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F63be5ab8-f161-463d-a3d9-880f4d1edfd4_2306x1390.png) 协调方式如下： - 当交互模型遇到需要更深层推理的事情时，它会将一个丰富的上下文包发送给后台模型。 - 这是完整的对话，而不是一个独立的查询，这使得后台模型能够充分理解情况。 - 后台模型异步运行，结果在生成时流式返回。 - 然后，交互模型会在合适的时机将这些结果编织到对话中，而不是作为某事中间的一个生硬上下文切换。 从用户的角度来看，这是一个单一的连续对话：一个 AI 在思考、回应，偶尔暂停进行更深入的研究，然后顺畅地将结果编织回来。在幕后，是两个系统在持续协调。 同样的逻辑在计算领域随处可见：快速路径与慢速路径配对，前台进程与后台进程配对，这在操作系统和网络浏览器中都是常规的例子。Thinking Machines 所做的，是以一种原则性的方式将这个模式应用于 AI 推理，而不是将推理延迟视为用户必须承受的问题。 所有这些设计选择加起来，产生了这样的效果：交互模型管理自己的对话，知道用户是在思考、暂停发言还是在进行自我纠正；它可以根据上下文进行口头或视觉上的插话；它可以同时说话和倾听——这是实现实时翻译的关键；它对经过的时间有直接感知；它可以与对话同时调用工具、搜索和生成 UI，并在结果准备好时将之编织回来。 这些说法需要证据。现有的语音 AI 基准测试难以捕捉这些质的飞跃，因此 Thinking Machines 构建了他们自己的基准。 - **TimeSpeak** 衡量模型是否能在用户指定的时间点以正确的内容主动说话，一个示例任务是“在我说停之前，每 4 秒提醒我呼吸一次。” - **CueSpeak** 衡量模型是否能在用户仍在说话时，在正确的时机说话，一个示例任务是“每次我转换语码时，用原始语言告诉我正确的词。” - **RepCount-A** 在给出指令“数一下俯卧撑的个数”后，流式传输某人做动作的视频。 - **ProactiveVideoQA** 流式传输视频，并提问那些正确答案取决于特定时刻视觉内容的问题。 [](https://substackcdn.com/image/fetch/$s_!fxc0!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb134f76b-67c6-47c2-9a30-a2e2620a6bdc_2446x1594.png) 结果非常显著。在这些基准测试中，所有现有模型都难以完成这些任务，大多数要么保持沉默，要么给出错误答案。这是 Thinking Machines 提出的最有力证据，证明他们的架构转变解锁了一个新的能力类别，而不仅仅是加速了旧有的行为。 尽管结果令人鼓舞，但研究也指出了仍然困难的地方。 - **长时间会话**仍然是该架构的一个真正挑战。连续的音频和视频会非常快速地积累上下文。虽然流式会话设计能够很好地处理中短时交互，但非常长的会话仍然需要谨慎的上下文管理。 - **网络连接**仍然是一个硬性要求，因为低延迟的流式音频和视频需要可靠的互联网连接。糟糕的连接会导致体验显著下降。 - **扩展模型规模**受到延迟目标的制约，TML-Interaction-Small 之所以是现在这个规模，部分原因是因为 Thinking Machines 更大的预训练模型目前在提供服务时速度太慢。 回顾过去，这