title: 我们的语音助手的下一个迭代就在这里 - 语音第 10 章 description: '<img src=''/home-assistant/images/blog/2025-06-voice-chapter-10/art.png'' style=''border: 0;box-shadow: none;'' alt="我们正在进行的声音系列的第 10 章"。' 以及一些有用的新语音和人工智能功能
我们的语音助手的下一个迭代就在这里 - 语音第 10 章
欢迎来到语音第 10 章🎉，系列，我们将在其中分享 Open Voice 的所有关键进展。本章包括 Open Voice 每个元素的改进。经过改进，它可以支持更多语言，可以在更多硬件上使用，使其更容易做出贡献，同时使其更快、更可靠。
帮助引导 Open Voice
在我们开始之前，我们只想说《Voice Chapter 10》不仅仅是一个广播；它是一个广播。 这是一个邀请 ✉️。我们的公共语音项目板位于 GitHub 上，它显示了我们正在修复的内容、当前正在构建的内容以及我们下一步将要开展的工作。每一个回应都是开放评论的，欢迎大家查看并参与讨论。 👉 项目板：https://github.com/orgs/OHF-Voice/projects/2
ESPHome 获得话语权
当我们开始为开放式语音助手硬件 Home Assistant Voice Preview Edition 设计和构建固件时，我们考虑到了几个具体功能：
- 在设备上运行唤醒字。
- 使用完全开源的媒体播放器平台，可以解码高质量来源的音乐。
- 唤醒词可以即时启用和禁用；例如，“停止”仅在播放长时间播放的公告或计时器响铃时才会激活。
- 在降低音量（也称为“回避”）的音乐上混合语音助手通知。 这些功能需要在为设备提供支持的软件 ESPHome 中运行。一开始，ESPHome 只能做 1 和 2，甚至不能同时做！ 为了包含所有这些功能，我们最初将它们构建为外部组件，使我们能够快速迭代（当然，在此过程中会破坏许多东西）。我们一直打算将这些组件引入 ESPHome，引入它们的过程称为“上游”。这将使任何人都可以轻松构建包含语音预览版所有功能的语音助手，这也是我们自去年 12 月推出以来一直致力于的目标。
一个设备都不落下！
ESPHome 版本 2025.5.0 包含所有这些组件！ 我们不仅花时间复制代码，而且还努力改进它，使其更通用、更易于配置且速度更快。 作为这些速度改进的一个例子，语音预览版上的最高 CPU 负载发生在音乐与长公告混合时。在这种情况下，它解码两个不同的 FLAC 音频流，同时运行三个 microWakeWord 模型（语音活动检测器、“Okay Nabu”和“Stop”）。使用 12 月份的原始固件，这使用了 72% 的 CPU 😅。通过 ESPHome 中现已提供的新优化，当前的语音预览版固件仅使用 35%❗ 这些改进甚至允许资源极其有限的 ATOM Echo 支持其中许多功能，包括媒体播放和持续对话。
制作你自己的语音预览版
我就假装自己看懂了这一切
说到语音硬件变得更像语音预览版，为什么不使用领先的硬件作为您自己创作的基础呢？我们现在已经获得了 KiCad 项目文件，其中包括电气原理图和电路板布局，以及其他有用的文档可在 GitHub 上下载。结合我们的开源固件文件，任何人都可以在我们所做的工作的基础上进行构建，打造他们梦想中的开放语音助手。更大的扬声器、内置传感器、带有微笑的 Nabu 吉祥物的显示屏——选择几乎是无穷无尽的。构建语音预览版始终旨在引导整个语音硬件生态系统，我们已经看到了这种开放技术的一些令人惊叹的创作。
现在你说的是我的语言
语音到短语变得更加流畅
如果您错过了，我们构建了自己的本地运行的语音转文本 (STT) 工具，即使在硬件受限的设备上也可以快速运行。 语音到短语 的工作方式与其他 STT 工具略有不同，因为它只接受特定的预定短语，因此得名。我们一直在努力使其成为家庭本地和私人语音控制的最佳选择。 Speech-to-Phrase 的句式格式正在升级！除了让社区成员更容易参与贡献，它现在也允许进行更充分的测试，以确保与现有 Home Assistant 命令兼容。 我们还开始尝试更精确的句子生成，将“将{灯光}设置为红色”之类的句子仅限于支持设置颜色的灯光。另一项改进是让 Speech-to-Phrase 在组合某些语言的名称和冠词时更加谨慎。例如，在法语中，以元音或“h”开头的设备或实体在其开头会有一个“l”撇号，例如 l'humidificateur 或 l'entrée。允许 Speech-to-Phrase 理解这一点可以避免它猜测无意义组合的发音。 Speech-to-Phrase 目前支持六种语言，即英语、法语、德语、荷兰语、西班牙语和意大利语。我们现在正在与语言领导者合作，增加对俄语、捷克语、加泰罗尼亚语、希腊语、罗马尼亚语、葡萄牙语、波兰语、印地语、巴斯克语、芬兰语、蒙古语、斯洛文尼亚语、斯瓦希里语、泰语和土耳其语的支持 -- 这将使我们的语言支持达到 21 种语言 🥳！ 这些新模型最初是由 Coqui STT 项目的社区成员训练的（该项目现已不复存在，但幸运的是他们的工作是开源的 --- 自由开源软件拯救世界的另一个例子），我们非常感谢有机会使用它们！性能和准确性因语言而异，我们可能需要根据社区的反馈来训练我们自己的模型。
Piper 的数量正在增长
Piper 是我们为家庭本地和私人语音构建的另一个工具，它可以快速将文本转换为听起来自然的语音。 Piper 正在成为最全面的开源文本转语音选项之一，并且一直在不断发展势头。最近，我们增加了对新语言的支持，并为现有语言提供了额外的语音，包括：
- 荷兰语 - 皮姆和罗尼 - 新声音
- 巴西葡萄牙语 - Cadu 和 Jeff - 新声音
- 波斯语 / 法尔西语 - Reza_ibrahim 和 Ganji - 新语言
- 威尔士 - Bu_tts - 新声音
- 瑞典语 - 丽莎 - 新声音
- 马拉雅拉姆语 - Arjun 和 Meera - 新语言
- 尼泊尔 - 奇旺 - 新声音
- 拉脱维亚语 - aivar- 新声音
- 斯洛文尼亚 - 阿图尔 - 新声音
- 斯洛伐克语 - 莉莉 - 新声音
- 英语 - Sam（非二元）和 Reza_ibrahim - 新声音 这使 Piper 支持的语言和方言从 34 种增加到 39 种 🙌！这让全球相当大一部分人口（大约 30 亿人）都能用自己的母语生成语音 😎！
评分语言支持
这还只是意图部分的评分表……实际情况可能会更复杂
Home Assistant 用户在开始语音之旅时，通常会首先问一个问题：“我的语言受支持吗？”由于Home Assistant中的语音助手非常灵活，这个看似简单的问题回答起来相当复杂！在较高层面上，语音助手需要将您的口语音频转换为文本（语音到文本），弄清楚您想要它做什么（意图识别），然后回复您（文本到语音）。该管道的每个部分都可以混合和匹配，甚至可以通过回退到大型语言模型 (LLM) 来增强意图识别，这非常适合理清被误解的单词或复杂的查询。 考虑到整个管道，问题是“我的语言是否受支持？”变成“每个部分对我的语言的支持程度如何？”对于使用 Microsoft Azure 提供语音服务的 Home Assistant Cloud，我们可以确信所有支持的语言都能正常运行。 本地选项，如 Whisper（语音转文本）以及较小程度上的 Piper（文本转语音），可能在技术上支持某种语言，但在实践中或在用户硬件的限制内表现不佳。例如，Whisper 拥有不同尺寸的模型，随着尺寸的增大，需要更强大的硬件才能运行。像法语这样的语言可能在最大的 Whisper 模型（需要 GPU）上运行得很好，但在树莓派甚至 N100 级 PC 上却无法使用。 我们自己的语音到短语系统很好地支持法语，并且在树莓派 4 或 Home Assistant Green 上运行良好。代价是仅支持有限的预定义语音命令集，因此您不能使用 LLM 作为后备（因为无法将意外命令转换为文本以供 LLM 处理）。 最后，当然，并不是每个人都希望（或可以）依赖云，他们需要一个完全本地的语音助手。这意味着语言支持不仅取决于用户的硬件和可用的语音服务，还取决于用户的偏好。出于这些原因，我们根据服务的特定组合将语言支持分为三类：
- 云 - 家庭助理云
- 聚焦本地 - 语音到短语和 Piper
- 完整本地 - Whisper and Piper 每个类别的分数从 0 到 3，其中 0 表示不支持，3 表示完全支持。选择Home Assistant Cloud的用户可以查看Cloud评分来确定语言支持的级别。对于想要本地语音助手的用户，他们需要在“聚焦本地”（针对低功率硬件的有限命令）和“完全本地”（针对高性能硬件的开放式命令）之间做出选择。重要的是，这些分数考虑了我们的语言领导者翻译的语音命令的可用性。如果一种语言对有用语音命令的覆盖范围很小，那么它在每个类别中的得分都会降低。 有了这些语言分数，我们希望用户在开始使用 Home Assistant 的语音旅程时能够做出明智的决定。它们目前出现在 Home Assistant 的语音设置向导中以及我们的语言支持页面 上。
名字里有什么
Voice commands in Home Assistant 触发器 intents, which are flexible 动作 that use names instead of IDs. Intents handle things like turning 设备 on or off, or adjusting the color of 灯光.到目前为止，句子翻译的重点是语言是否支持意图（例如打开设备/off），但没有明确显示该命令是否支持设备名称、区域名称或两者。 This can change from language to language, which made gaps hard to spot.我们正在改用一种新的格式来突出显示这些组合，使贡献者更容易查看支持哪些名称，这将使翻译变得更简单。
持续对话更新
自上一章语音以来，语音团队一直致力于让Assist对于基于LLM的代理来说更具对话性。我们从基于 LLM 的代理开始，因为它更容易迭代。如果法学硕士带着问题返回，我们会检测到并继续对话，而无需您再次说“Ok Nabu”。
最重要的是，您现在可以直接从自动化或仪表盘发起与名为 start_conversation 的新动作的对话。这为基于法学硕士的代理提供了全方位的对话。
以下是两个协同工作的功能的快速演示：
媒体搜索和播放意图
Home Assistant 和开源的伟大之处在于，有时最好的想法来自社区中的其他项目。早期，许多人对用语音驱动音乐助理很感兴趣，但家庭助理缺少核心功能，例如搜索媒体库的能力。
我们努力将此功能引入 Home Assistant 的核心体验，并创建一个新的意图，即 搜索和播放 意图。现在，您可以与语音助手交谈并要求它在家中的任何房间播放音乐。
该意图可以由基于 LLM 的对话代理使用，但我们也有不需要任何 LLM 魔法的句子。您可以在这里找到英语句子。由于这是一项新功能，支持可能会根据您的语言而有所不同，请耐心等待我们出色的语言领导者进行这些翻译。
未来工作-Assistance 有话要说
与家人交谈应该像在厨房柜台上与朋友聊天一样自然。大语言模型 (LLM) 已经证明了这种来回的流畅性，现在我们希望每个 Home Assistant 安装都能享受相同的体验。因此，我们将重点放在默认对话代理的三个关键用例上，其中包括关键确认、后续操作和自定义对话。请注意，这些仍处于开发的早期阶段，您可能需要一段时间才能看到其中的一些功能。
关键确认
有些动作太重要了，如果不快速仔细检查就无法执行。打开前门，关闭百叶窗，或者运行“离家”脚本。我们希望你能够将那些实体标记为受保护。每当你说出一个触及其中一个实体的命令时，Assist 就会在行动前要求口头确认：
好的，Nabu，打开前门
你确定吗？
是的
解锁
因为每个家庭都是不同的，我们正在考虑管理这些确认 每个实体 并使它们完全可由用户配置。
缺失参数的后续处理
有时，Assist 可以掌握您想要的内容，但需要更多细节才能实现。我们希望 Assist 能够主动索取缺失的部分，而不是失败。这里举一个例子来说明。
好的，Nabu，设置一个计时器
多长时间？
15分钟
计时器开始
目前，我们仍在评估该用例的相关句子。我们正在实施计时器的后续行动，但目前发现更多并不是我们的首要任务。不过，我们愿意接受建议。
自定义对话
与 Home Assistant 的任何其他部分一样，我们希望 Assist 的对话方面能够个性化。简单的语音交易已经可以使用 conversation 动作和 set_conversation_response 动作通过我们的自动化引擎创建。
我们希望为对话带来相同级别的自定义，允许您创建完全本地的预定义对话，以便在您需要时触发，例如当您进入房间、开始就寝时间等时。
我们首先关注的是使自定义对话成为可能，以便您可以向我们展示您正在使用这个新的强大工具构建的内容。然后，我们将处理关键的确认用例，最后是参数丢失时的后续处理。
让我们继续推动 Open Voice 前进
仅在几年前，语音控制还是需要大量数据的公司的领域，而且基本上不存在这种开放技术。现在，作为一个社区，我们已经构建了功能强大的语音助手所需的所有部件，该助手完全开放且免费供任何人使用（甚至可以在此基础上构建）。 每一个篇章，我们都在稳步前进，这离不开您的支持。无论是来自那些通过支持开放家庭基金会（通过订阅 家庭助理云 和购买 官方家庭助理硬件）资助其开发的人，还是那些贡献时间来改进它的人。一如既往，我们希望支持所有可能的语言，如果您在我们支持的列表中没有看到您的母语，请考虑为此项目做出贡献。