MIST：面向智能家居的多模态交互式语音工具调用对话助手

# 面向智能家居的多模态交互式语音工具调用对话助手

**来源:** https://arxiv.org/html/2605.06897

**作者:** Maximillian Chen¹, Xuanming Zhang¹*, Michael Peng, Zhou Yu¹, Alexandros Papangelis, Yohan Jo²

**机构:** ¹哥伦比亚大学, ²首尔国立大学

**邮箱:** \{maxchen, billyzhang\}@cs\.columbia\.edu, yohan\.jo@snu\.ac\.kr

*   * 表示同等贡献。
*   YJ 为通讯作者。
*   MC 现就职于 Google，AP 现就职于 Apple。

###### 摘要

物联网（IoT）设备在物理世界中的兴起，需要能够处理复杂用户体验的基于语音的接口。虽然现代大型语言模型（LLM）已展现出强大的工具使用能力，但对真实世界 IoT 设备建模提出了一个困难且研究不足的挑战，该挑战结合了时空约束建模与语音输入、动态状态跟踪以及混合主动性交互模式。我们引入了 **MIST**（多模态交互式语音工具调用数据集，Multimodal Interactive Speech-based Tool-calling Dataset），这是一个针对 IoT 设备的合成式多轮、语音驱动的代码生成任务。我们发现，在 MIST 上，开放权重与闭源多模态 LLM 之间存在显著差距，即使是前沿的闭源 LLM 也有巨大的提升空间。我们发布了 MIST 以及一个可扩展的数据生成框架，以便构建相关数据集，从而促进对涉及物理世界约束推理的混合主动性语音助手的研究。

<sup>1</sup> [billyzhang24kobe.github.io/mist-smarthome](https://arxiv.org/html/2605.06897v1/billyzhang24kobe.github.io/mist-smarthome)

![[无标题图片]](https://arxiv.org/html/2605.06897v1/all-twemojis.pdf)

**MIST：** 面向智能家居的多模态交互式语音工具调用对话助手

## 1 引言与相关工作

![图1说明](https://arxiv.org/html/2605.06897#S1.F1)
**图 1：来自 MIST 的对话示例。** 用户发出带有自然流利度问题和不同口音的语音指令。助手必须在管理多轮对话中的歧义、纠正、冗余和状态化设备跟踪的同时，生成结构化的 API 调用。

物联网通过互联设备网络作为物理世界与虚拟世界之间的接口。随着大型语言模型应用于虚拟助手（例如 Alexa+、Gemini for Home）的最新进展，物联网的采用仍在加速，预计到 2030 年将有近 400 亿台连接的 IoT 设备 [Iji and Gurung (2024)](https://arxiv.org/html/2605.06897#bib.bib31)。随着这些系统包含 increasingly complex capabilities，僵化的基于规则的接口已变得不足。能够在 spoken 和 text 两种模态上进行推理的多模态大型语言模型（MLLMs）为开发能够应对多样化物理约束和用户交互模式的智能体提供了一条有前景的路径。

![图2说明](https://arxiv.org/html/2605.06897#S1.F2)
**图 2：构建 MIST 的数据生成框架概览。** 我们首先从多样化的用户角色、IoT 设备和房间中采样以形成家庭配置，然后根据这些配置反复采样有效的对话动作和工具调用，以形成目标导向的对话。

为真实世界的 IoT 设备开发现代多模态对话助手，需要超越传统的任务导向对话（TOD）任务，如槽位填充和意图检测 [Coucke et al. (2018)](https://arxiv.org/html/2605.06897#bib.bib22); [Hemphill et al. (1990)](https://arxiv.org/html/2605.06897#bib.bib23); [Schuster et al. (2019)](https://arxiv.org/html/2605.06897#bib.bib24)。现代挑战包括管理物理世界的状态化表示 [Rivkin et al. (2024)](https://arxiv.org/html/2605.06897#bib.bib41)、执行工具调用 [Goele et al. (2023)](https://arxiv.org/html/2605.06897#bib.bib15) 以协调各种设备的动作、建模多轮对话历史 [Budzianowski et al. (2018)](https://arxiv.org/html/2605.06897#bib.bib14); [Rastogi et al. (2020)](https://arxiv.org/html/2605.06897#bib.bib16)，以及在面对不流利用户时保持鲁棒性 [Goele et al. (2023)](https://arxiv.org/html/2605.06897#bib.bib15); [Qi et al. (2024)](https://arxiv.org/html/2605.06897#bib.bib40)。

在本文中，我们建立在 TOD 和对话任务合成 [Bae et al. (2022)](https://arxiv.org/html/2605.06897#bib.bib18); [Qian et al. (2025)](https://arxiv.org/html/2605.06897#bib.bib39) 的丰富历史工作基础之上，并结合数字文本工具调用 [Qi et al. (2024)](https://arxiv.org/html/2605.06897#bib.bib40) 和基于语音的 TOD [Zhang et al. (2023)](https://arxiv.org/html/2605.06897#bib.bib45); [Faisal et al. (2021)](https://arxiv.org/html/2605.06897#bib.bib47); [Si et al. (2023)](https://arxiv.org/html/2605.06897#bib.bib46) 中不断增长的文献。我们引入了 **MIST**（多模态交互式语音工具调用数据集），这是一个新颖的基准任务，要求 MLLMs 在多轮对话中联合建模语音请求和混合主动性对话动态，同时理解具有物理世界影响和时空约束的 API 调用。为了构建 MIST，我们创建了一个神经符号数据生成框架。

## 2 MIST 概述

MIST 包含 10,000 次对话，共计 88.1 小时的语音对话。MIST 包括 50 种最常见的独特 IoT 设备，涵盖 27 种独特的能力/API 函数，这些数据均源自在线文章 [Zell (2025)](https://arxiv.org/html/2605.06897#bib.bib66); [ESHP (2025)](https://arxiv.org/html/2605.06897#bib.bib65); [BHHS (2025)](https://arxiv.org/html/2605.06897#bib.bib67)。每次对话平均包含 5.6 个用户轮次。如图 1 [所示](https://arxiv.org/html/2605.06897#S1.F1)，每次对话涉及用户要求虚拟助手与物理 IoT 设备进行交互。

### 2.1 数据生成框架

图 2 [展示了](https://arxiv.org/html/2605.06897#S1.F2) MIST 的数据生成框架概览。在数据生成框架的第一阶段，我们首先为这三个要素定义一组可能的值。我们根据表 A3 [中](https://arxiv.org/html/2605.06897#A3.T3) 定义的词法定义了“房间类型”（例如，“厨房”或“露台”）。每个房间都映射到一组合理的 IoT 设备。每个 IoT 设备都有其独特的能力（例如，智能灯泡上的“颜色”或“亮度”），可以通过函数调用进行交互。支持的 IoT 设备及其能力和放置约束在表 A4 [中](https://arxiv.org/html/2605.06897#A3.T4) 定义。最后，我们根据行为个性（例如，“开朗”；见表 A7 [](https://arxiv.org/html/2605.06897#A3.T7)）、专业知识（例如，“新手”；见表 A7 [](https://arxiv.org/html/2605.06897#A3.T7)）、口音（例如，“澳大利亚口音”）、音调、语速和设备噪声（映射到高斯噪声；见表 A5 [](https://arxiv.org/html/2605.06897#A3.T5)）定义了用户特征的 possible values。

第二阶段涉及由概率协调器管理的对话生成。对于每次对话，框架采样一个独特的家庭配置和一个一致的用户配置文件。家庭配置参数化了一个 **Home State** 对象，该对象作为物理世界设备状态的“数字孪生” [VanDerHorn and Mahadevan (2021)](https://arxiv.org/html/2605.06897#bib.bib62)，跟踪每个设备能力和例程的实时状态。协调器在每个轮次中概率性地采样目标交互意图。一旦选定意图，系统会对 Home State 执行符号检查以 grounding 交互。

我们的框架支持六种核心交互模式（即对话动作）：

1.  **动作执行：** 用户要求实时在设备上执行动作（例如，“关闭二楼的所有设备”），代理必须识别这是一个有效请求并产生正确的工具调用。
2.  **例程更新：** 用户可以请求动作、触发器和条件的组合，这些可以被创建、更新和删除（例如，“周末早上 7 点打开露台灯”），代理必须识别其有效性并产生正确的调用以更新智能家居的例程管理器。
3.  **纠正循环：** 代理通过多个工具调用应用用户请求的纠正（例如，“其实，我意思是把音量调到 30”），并在必要时“撤销”之前的动作。
4.  **歧义解决：** 协调器在三个层面识别潜在冲突：设备名称重复、房间类型歧义（例如，两个卧室）或房间内设备类型重复。在这些情况下，它生成一个澄清子对话，用户提出未指定清楚的请求，代理必须提出澄清问题<sup>2</sup> [我们分配随机颜色以区分相同类型的房间（例如，“蓝色卧室”与“红色卧室”）](https://arxiv.org/html/2605.06897#S1.F1)（例如，在图 1 中，存在多个相同类型的房间）。
5.  **冗余处理：** 用户可能会提出冗余的“无操作”请求，代理需要具备通过评估当前 Home State 来识别并拒绝这些请求的能力。
6.  **状态更新：** 用户可能会询问智能家居的当前状态，代理应形成工具调用来检索所有设备的状态。

在每次交互之后，家庭状态会根据代码执行进行更新。每种交互模式都映射到一对包含固定用户侧对话动作和“最佳”代理侧对话动作的内容。两者都有默认的模板化话语。用户侧对话根据该对话采样的行为特征使用 Gemini 2.5 Flash-Lite 进行释义。为了反映自然交互，基于规则的注入器随后随机添加语音流利度问题，包括单词重复和修改 [Shriberg (1994)](https://arxiv.org/html/2605.06897#bib.bib64); [Passali et al. (2022)](https://arxiv.org/html/2605.06897#bib.bib7)。最后，文本根据采样的声学配置文件使用 Google Cloud TTS API 合成为音频，并注入高斯噪声以模拟录制噪声 [遵循 Chen et al. (2025a)](https://arxiv.org/html/2605.06897#bib.bib42)。实现细节见附录 C [](https://arxiv.org/html/2605.06897#A3)。

为了验证数据集质量，我们随机采样了 300 个示例，并要求专家注释员收听语音请求并阅读现有的智能家居上下文。注释员的任务是验证相对于数据集声明的黄金对话动作和工具调用的正确性。我们发现，超过 92% 的对话动作和提议的工具调用是正确的，且注释员在这些任务上的同意率超过 90%。完整的人类评估细节见附录 F [](https://arxiv.org/html/2605.06897#A6)。

## 3 实验

在 MIST 中，以下文本输入提供给 MLLM：智能家居布局（包括所有 IoT 设备及其能力）、现有的 Home State 和现有对话历史。MLLM 还接收用户的当前请求（即目标）作为语音输入。用于聚合这些输入的提示在附录 G [中](https://arxiv.org/html/2605.06897#A7)。

#### 评估

模型沿两个维度进行评估。首先是**代码智能**，通过**执行匹配**（生成的工具调用导致正确最终家庭状态的轮次百分比）和**精确匹配**（生成代码的字符级匹配）给出，如 [Yue et al. (2019)](https://arxiv.org/html/2605.06897#bib.bib63) 所示。这些指标针对需要工具调用的示例计算。其次是**对话智能**：代理通过产生具有正确对话动作的响应来识别歧义、冗余和其他现象的能力。我们测量推断动作的 Macro F1 和准确率（实现细节在附录 D [中](https://arxiv.org/html/2605.06897#A4)）。这反映了 [Chen et al. (2025b)](https://arxiv.org/html/2605.06897#bib.bib44) 提出的动作级评估设置，并使用 Macro F1 和准确率进行测量。

#### 基线

我们使用几个基线来 contextualize MLLM 性能。对于代码生成，我们使用一个基线，其中我们使用初始家庭状态，并为对话的每一轮使用此状态计算“执行匹配”（“初始状态”）。我们还考虑了一个假设家庭状态与上一轮相比没有变化的基线（“前一轮状态”）。对于对话智能，我们展示了一个假设候选响应始终遵循 MIST 中最常见的对话动作的基线（“恒定预测”）。

#### 模型

我们考虑了几个具有竞争力的开放权重 MLLMs：Qwen Audio [Chue et al. (2023)](https://arxiv.org/html/2605.06897#bib.bib52)、Qwen 2 Audio [Chue et al. (2024)](https://arxiv.org/html/2605.06897#bib.bib53)、Soundwave [Zhang et al. (2025b)](https://arxiv.org/html/2605.06897#bib.bib54) 和 Qwen 3 Omni [Xue et al. (2025)](https://arxiv.org/html/2605.06897#bib.bib55)。我们还评估了一个前沿闭源模型系列：Gemini 2.5 Flash-Lite、Flash 和 Pro [Comanici et al. (2025)](https://arxiv.org/html/2605.06897#bib.bib56)。

![图3说明](https://arxiv.org/html/2605.06897#S3.F3)
**图 3：错误分析，按比例表征每种 MLLM 的错误类型。** 前沿模型最常见的工具执行错误是选择“错误值”，而开放权重模型则在错误的时间触发工具调用或针对错误设备方面 struggles。

### 3.1 结果与讨论

**表 1：代码生成** 结果表明 Gemini 2.5 Pro 实现了最强的精确匹配，领先于领先的开放权重模型。

#### 代码智能

表 1 [显示](https://arxiv.org/html/2605.06897#S3.T1)，闭源前沿 MLLMs 与领先的开放权重音频模型之间存在明显差距。开放权重模型取得了中等水平的执行匹配分数（范围从 48.76% 到 60.94%），但除了 Qwen 3 Omni 之外，所有模型在精确匹配指标上都几乎完全失败（≤2.26%）。“前一轮状态”基线揭示，在 71.6% 的示例中，无需对 IoT 设备执行动作（例如，代理应 eliciting 更多信息或拒绝请求）。图 3 [中的](https://arxiv.org/html/2605.06897#S3.F3) 代码智能错误分析显示，对于所有开放权重 MLLMs，至少 46% 的错误函数调用涉及“过度触发”，意味着代理执行了不必要的代码动作。开放权重 MLLMs 的第二大常见错误是 targeting the “wrong device”。这表明模型在理解可能包含相似设备的复杂上下文方面效果不佳，这具有 **serious physical world implications**（例如，留错门未锁，打开错误的烤箱）。

相比之下，闭源 MLLMs 取得了不错的性能。Gemini 2.5 Pro 取得了最佳性能，执行匹配率为 79.53%，精确匹配率为 65.56%。闭源模型的总体错误数量要低得多，这体现在较低的过度触发率和选择错误设备的比率上。相反，最常见的错误类型是在代码中产生“错误值”（例如，将扬声器设置为不正确的音量设置）。最后，我们也看到模型性能似乎随着模型规模而提高，表明该任务是可以攀爬的，并且在弥合开放和闭源 MLLMs 之间的跨模态推理能力方面存在巨大机会。

**表 2：对话智能** 基于推断对话动作的 F1 和准确率。

#### 对话智能

表 2 [中](https://arxiv.org/html/2605.06897#S3.T2) 的...