UIUC与CMU等团队提出Omni框架：多模态模型如何应对实时交互
作者：钟浞清转载请联系本公众号获得授权，并标明来源来自 UIUC、CMU 等团队的研究人员在最新研究中提出了统一概念框架，系统讨论多模态模型如何在持续接收信息的过程中，保留理解与推理能力，并协调回应、打断和任务修正。来自 University of Illinois Urbana-Champaign、Carnegie
来自University of Illinois Urbana-Champaign、Carnegie Mellon University、Columbia University等机构的研究团队，在综述《Native Real-Time Interactive Omni Intelligence: A Unified Framework》中提出了一个统一概念框架。文章系统讨论多模态模型在持续接收信息的过程中，怎样保留理解与推理能力，同时协调回应、打断和任务修正。综述还比较了系统适配与模型原生两条发展路径，并进一步讨论多速率计算与会话级评测，为分析实时交互系统提供共同视角。
文本、图像、音频、视频，多模态模型已经能把它们放在一起理解并作答。问题在于，真实对话里的输入很少有一个清晰的收尾点：用户会在模型作答途中追加条件，视频里的场景会不断变化，工具调用也可能等到任务改过之后才把结果送回来。
举个例：用户让语音助手查周五的会议时间，系统开始检索后，用户又补了一句「改成下周一，下午也不行」。助手这时得继续听取补充、更新当前任务，还要判断先前启动的查询是否仍然有用。回答生成得多快、旧查询是否准确，单独来看都说明不了系统能否处理好这次变化。
内容和交互由此被绑到了一起。系统一边得吃进新信息，一边要拿捏回应的时机——什么时候该开口，什么时候该等，正在进行中的回答或动作又是否要改。综述正是沿着这些要求，把模型表示、架构、训练、状态维护、部署和评测收进了同一个框里。
研究亮点
建立连接Omni Intelligence与Omni Interactivity的概念框架，用流式输入、演化状态和在线响应控制来描述实时交互行为。
比较系统适配与模型原生两条发展路径，并分析跨越这两条路线的前台与后台协同设计。
从六个维度组织评测，讨论能力保留、运行时协调及多速率交互智能方面的研究问题。
论文地址：
https://preprints.org/manuscript/202610.1649
项目主页：
https://plan-lab.github.io/interactive-omni
资源仓库
https://github.com/ShenYifanS/Awesome-Interactive-Omni
交互持续变化时该如何描述，概念框架给出了自己的切分。
综述先把两个相互关联的概念分开：Omni Intelligence 管的是跨模态的理解、知识、推理和生成；Omni Interactivity 管的是交互展开时的响应决策——什么时候回答、什么时候等待、什么时候改口或停下。两者合在一起，才叫 Interactive Omni Intelligence。这样区分之后，内容和行为就能一并检查。有的系统答得没错，却用不上随后到来的纠正；有的系统接话很快，可证据还没攒够就下了判断。框架把这两种表现放进同一次交互里看，分析的是模型能力在持续变化的条件下究竟怎么被用出来。
图1 展示实时交互式 Omni 智能的总体框架，把交互要求、流式表示、模型、执行与评测串在一起。来源：论文图1。
落到具体写法，文章用三个属性刻画实时交互：
- 流式输入（Streaming Input）：信息可以一步步到来，连续音视频、文本更新、屏幕变化和工具反馈都算。信息还不完整，系统就得开始处理，并随着输入不断往下推。
- 演化状态（Evolving State）：新信息要能并入当前的交互状态，哪怕先前的推理或生成还没收尾。会议查询里改一个日期，系统正在维护的任务条件就要跟着变，后面的处理也随之受影响。
- 在线响应控制（Online Response Control）：输出从何时起步，以及交互过程中输出能不能改、能不能停。管的对象可以是语音、文本、工具调用和界面操作。用户一打断，系统得按更新后的状态决定接下来怎么办。
这三个属性说的是系统的交互行为。实现起来，可以用流式接口加外部控制器，也可以把相关机制做进模型架构和训练里。至于支持更多模态、压低生成延迟，跟上面这些行为之间，还得一项一项去建立联系。
图2 单工、半双工与全双工语音交互：三种模式分别对应单向通信、交替发言，以及允许重叠的同时听说。来源：论文图2。
2 条发展路径
连接模型能力与交互控制
沿着这些属性，综述比较了两条路径：系统适配与模型原生。前者在预训练语言模型或全模态模型周围加接口、加模块，再做后训练和编排；后者在架构和训练中直接学时间结构、连续多模态处理、生成及交互控制。
系统适配这条路上，模块之间怎么配合、状态怎么传，是绕不开的问题。
典型的级联系统把语音活动检测或端点检测、语音识别、语言模型、语音合成与播放控制串在一起。流式识别能一边接收一边处理用户语音，增量语音合成则可以依据部分文本提前把音频生成出来，话轮切换、打断与恢复交给外部控制机制负责。这样拆开的好处是每个组件都能单独优化、单独替换，可模块之间还得把时间信息和任务状态传下去。比如用户打断时，系统要处理已经生成、还没播放出去的语音，还要分清用户实际听到了哪些内容。不然，后面的回答就可能引用用户根本没听见的信息。
记忆、检索与工具调用同样可以挂进系统适配里。用户改了请求之后，这个变化要传到已经启动的工作中去，系统还得判断哪些中间结果能留、哪些得重算。
再看模型原生路线，它关注的是时序建模和训练。
原生全双工模型把双方的语音流放在一起建模，从中学习重叠语音、简短反馈和话轮交接的时间关系。全模态输入输出模型则进一步把视觉等信息纳进来，探索跨模态对齐与流式生成。至于不同模型对持续输入和响应控制能支持到什么程度，得结合具体实现来看。
训练数据同样要留住交互里的时间结构。停顿可能是犹豫，也可能代表话轮结束；插话可能是确认，可能是纠正，也可能是要求停下。这些信号如何影响内容生成和响应时机，模型得结合语境去学，评测也要把相应行为查一遍。
不管走哪条路，音视频信息以什么形式进入模型都要想清楚。音频的不同表示方式，能留下的语义和声音细节不一样，算力开销也不一样。视频的采样与压缩方式，则决定了哪些画面变化能被保留、新信息多久能进到模型里。这些选择会同时作用在内容理解和响应延迟上。
多速率计算
快速交流与较慢推理之间怎么协调
实时交互里，各项任务的时间要求并不相同。话轮交接、简短反馈和打断处理得及时响应，检索、验证、规划与工具执行则可能拖得更久。综述把不同计算时间尺度之间的这种协调称为多速率交互智能（Multi-Rate Interactive Intelligence）。前台与后台分工是其中一种做法：前台一直接收输入，处理简短回应和打断，后台去做较慢的推理、检索或记忆更新。这种机制在系统适配和模型原生两条路径上都可能出现。
后台查询跑完，麻烦才刚开始。它可能是在请求还没说全的时候发起的，等用户改了条件才返回；结果要是直接塞进回答，失效的信息就又回到会话里了。
所以系统得给后台操作记上对应的任务版本，结果回来时再对一下和当前请求的关系。还有效的中间结果接着用，过时的活儿就取消或者重算。至于已经对外部产生影响的动作，能不能恢复，要看这个动作撤不撤得回来。
这也是为什么「开始回应」和「给出有用答案」要分开看。助手可以先说一句「我查一下」，同时继续收集证据；真正把任务往前推的时间，取决于后面的推理、验证和工具执行。多速率设计要把这两段都照顾到，前台和后台的状态还得对得上。
评测分了 6 个维度，看的是完整交互过程
为了比较不同系统，综述把评测拆成六个维度：延迟、时机质量、内容质量、鲁棒性、长会话质量和修复能力。
延迟这块，算的是开始生成、客户端把语音播出来、响应打断这几个阶段的耗时。时机质量则看系统有没有在该说话的时候说话：用户只是短暂停顿，系统是不是抢了话轮；用户已经说完了，系统有没有及时接上。
内容质量盯的是正确性、完整性和指令遵循。鲁棒性看的是重叠语音、噪声、旁人在说话这些条件下的表现。一次流畅的演示能展示部分能力，但这些不同条件的测试还是得覆盖到。
长会话质量关心的是实体、事件、任务条件和记忆在持续交流中能不能保持一致。用户模拟可以补上一块评估：让模拟用户和系统互动，再根据产生的交互历史看表现。修复能力查的是系统有没有把纠正接住、停掉过时输出，恢复后的响应是否满足改过的请求。
这些评测还得报告硬件、网络、并发负载和资源预算等条件。不同论文用的任务和部署设置并不一致，光看一个分数很难说明完整的交互体验。按时间把输入、响应、纠正和工具结果记下来，有助于分析错误出在哪个环节。
文中也谈到智能与交互如何取舍（Intelligence–Interactivity Trade-off）：训练时要确认语音和交互适配完成后，模型原有的知识储备与推理能力是否仍然保留；运行时要统筹算力预算、回复时机与证据是否有效。这些表现跟模型、数据、训练方法以及系统实现都有关系，就目前掌握的证据看，还不能断言实时交互就一定会让推理能力变弱。
交互时间一长、环境一开放，要求又不一样了
交互持续更久之后，系统要分清哪些是当前信息、哪些已经失效，把没做完的任务留着，还得让用户能改记忆、删记忆。多人交流时，还要区分谁在说话、话是说给谁的、谁有行动权限，别把旁人的话当成用户指令。
主动交互绕不开一个时机问题：几时出手。系统捕捉到新事件后，得把任务、用户指令和当下情境放在一起权衡，再决定是发提醒，还是接着等。评估这类能力时，有帮助的干预、错失的机会和多余的打扰要分开来看。
感知一旦持续运行，隐私和安全上的要求也跟着上来。音视频里可能录进旁人的交谈，或者拍到私人屏幕上的内容，采集、处理、传输、存储、使用这几个环节都得分别设限。至于发消息、披露信息、控制设备这类操作，确认边界要参照不确定性的大小和后果的轻重来划。
网络、传感器或者工具出故障时，系统该怎样降级，需要有明确规定。比如把视觉采样频率降下来、把后台计算往后推，或者切换到更受限的交互模式。能力打了折扣之后，系统要讲清楚缺了哪些信息、延迟了多少，同时尽量把当前的交互状态维持住。
图3 开放问题与研究方向，包括多速率交互、持久与主动交互，以及安全高效的开放环境运行。来源：论文图15。
写在最后
这篇综述的主要贡献落在概念框架和文献比较上，把多模态能力、交互控制以及不同时间尺度上的计算协调串了起来。它给出的是一组分析系统的具体问题：新信息能不能刷新当前理解，进行中的响应能不能跟着调整，后台算完的结果是否还适用于当前任务，以及出错以后能不能恢复。对于实时多模态助手来说，这些问题得放在同一次持续交互里检验。
模型开始进入更长的会话、面对更多参与者、部署环境也更复杂，能力保留、状态一致性、隐私与行动安全就需要放在一起评估。相关研究在论文和项目页面上有整理，可供进一步阅读和比较。
参考资料：
https://preprints.org/manuscript/202610.1649
