过去几年，自动语音识别（ASR）的进步相当明显。从早期基于声学模型与语言模型的组合架构，到 Whisper、Paraformer、Qwen3-ASR 等深度学习模型，语音转文字已经逐渐成为智能终端、办公软件和行业应用中的基础能力。

但如果把一套在安静环境中表现不错的 ASR 系统直接放进会议室，识别效果往往会出现明显波动。

问题不一定出在说话人的发音上，而是环境中可能同时存在多个人声。

例如一场项目讨论中，负责人正在介绍技术方案，另一名参会者突然插话。两个声音同时进入麦克风，传统 ASR 可能将两人的发言混在一起，甚至把不同说话人的句子拼接成一段看似通顺、实际却不属于任何人的文字。

2026年9月，小米发布了开源语音识别模型 

，将一个长期存在于语音处理领域的问题重新带入大众视野：当多个人同时说话时，机器能否像人一样，有选择地听清其中一个人的声音？

一、鸡尾酒会问题：为什么多人语音识别比单人识别困难？

Cocktail Party Problem，即“鸡尾酒会问题”，是语音信号处理中的经典课题。

想象一个嘈杂的聚会环境：周围有音乐、餐具碰撞声和其他人的交谈声，但我们仍然能够把注意力集中在面前某个人的讲话上。

人类听觉系统能够利用音色、音高、声音空间位置及上下文等线索，从混合声音中追踪特定声源。

麦克风采集到的是多个声源叠加后的波形，可以简化表示为：

其中，(s_i(t)) 表示第 (i) 个说话人的声音，(n(t)) 表示环境噪声，(x(t)) 则是麦克风最终接收到的混合信号。

传统 ASR 的核心任务，是将音频映射为文本。但在多人重叠讲话时，系统不仅需要判断声音对应的文字，还要确定这些文字属于哪个说话人。

这带来了两个不同层面的问题。

：在噪声和人声干扰下，尽可能准确地还原讲话内容。

：确定一段语音究竟由谁发出，以及两个说话人同时讲话时应该如何处理。

二者并不是同一个任务。一个系统即使能够完整识别所有单独发言的内容，也未必能够准确处理真正发生重叠的语音。

这正是目标说话人语音识别（Target-Speaker ASR，TS-ASR）受到关注的原因。

二、Xiaomi-CocktailASR-1：利用参考声音识别指定说话人

与普通 ASR 尽可能转录整段音频不同，Xiaomi-CocktailASR-1 的核心目标是：

给定一段目标人物的参考语音，从多人混合音频中识别出这个人的讲话内容。

如果预先提供 A 的一小段参考语音，模型就可以利用其中的声纹特征，在混合音频中定位并转录 A 的讲话，而不是将两人的内容全部输出。

根据小米发布的技术报告，CocktailASR 采用端到端语音识别架构，主要由三个部分组成：Audio Encoder、Adapter 和大语言模型。

其中，Audio Encoder 基于 Data2Vec2 构建，规模约为 0.6B 参数，负责提取包含语音内容和说话人信息的声学特征；Adapter 将这些特征映射到语言模型可以处理的表示空间；最后由基于 Qwen3-8B 的语言模型生成目标说话人的文本。

参考语音 + 1 秒静音 + 待识别混合语音

静音片段用于区分参考声音和待识别声音，模型则利用参考音频提供的声纹信息，对混合音频进行有条件的识别。

这一设计的重要之处在于，它不需要先显式生成一条分离后的目标人物音轨，再交给独立 ASR 模型，而是直接输出目标说话人的文字。

此外，小米还专门训练了两项实际应用中很有价值的能力。

第一项是单人、多人场景兼容。

 当环境中只有目标人物讲话时，系统仍然需要保持正常的 ASR 性能，不能因为过度抑制干扰声音而误删目标语音。

 如果待识别音频中根本没有目标人物的声音，模型应当输出空结果，而不是从其他人的讲话中强行生成一段文本。

CocktailASR 还提供 CoT 推理模式，通过生成中间分析内容辅助目标说话人识别。不过，这种模式是否适合实际业务，还需要考虑额外的推理开销。

在小米公布的实验结果中，CocktailASR 在多个多说话人测试集上表现突出。

数据来自小米官方技术报告。英文任务采用目标说话人词错误率（TS-WER），中文任务按论文指标说明采用目标说话人字符错误率（TS-CER）；论文结果表中统一以 WER 标注。

需要注意，这些数值是特定数据集、任务设置下的错误率，不应直接换算成面向所有环境的“识别准确率”。

例如，LibriMix 是合成混合语音测试集，而 AliMeeting-Far 包含真实会议中的远场拾音与多人交谈。不同数据集的语音重叠程度、噪声条件和评价方式都会影响最终结果。

真正值得关注的，不是某个单独的百分比，而是 ASR 正在从普通的声音转文字，向更精细的说话人选择与识别发展。

三、说话人分离、声纹识别和 Target-Speaker ASR 有什么不同？

讨论 CocktailASR 时，一个容易混淆的问题是：既然已经存在 Speaker Diarization 和声纹识别，为什么还需要专门研究目标说话人 ASR？

事实上，这几项技术解决的是不同问题。

Speaker Diarization：谁在什么时候说话？

说话人分离通常将一段连续录音按照说话人划分为不同的时间区间，再为不同声音分配 Speaker 1、Speaker 2 等标识。

它主要关心说话人的一致性与时间归属，并不一定知道每个说话人的真实身份。

Speaker Recognition：说话的人是谁？

声纹识别通过分析说话人的声学特征，将当前声音与已注册的声纹进行比较，完成身份验证或身份辨认。

例如，企业会议系统可以提前录入参会人员的声音，在会议过程中对识别到的发言人进行身份匹配。

Target-Speaker ASR：指定的人究竟说了什么？

这一任务更强调混合声音中的选择性转录。即使其他人同时讲话，模型也需要尽可能只输出指定说话人的内容。

传统工程系统可以采用级联方式，将语音分离、ASR、说话人分离和声纹匹配组合使用；CocktailASR 则尝试通过端到端训练直接解决目标说话人的识别问题。

级联系统便于独立替换各个组件，能够根据行业需求选择不同的识别模型、声纹模型及降噪算法，但也会增加模块间的数据传递和误差传播问题。

端到端系统可以联合优化目标识别任务，减少对显式语音分离环节的依赖，但模型复杂度、计算资源消耗，以及对特定业务功能的定制能力，同样需要评估。

在多人会议、语音质检、访谈录音和智能设备等应用中，技术选型往往并不是简单地比较哪条路线更先进，而是要判断系统究竟需要“识别所有人”，还是“只识别指定的人”。

四、从实验室指标到工程部署，ASR 还面临哪些问题？

模型在公开数据集上取得不错的成绩，并不意味着接入真实业务系统后就能获得完全相同的表现。

对于实际的语音识别服务，至少还需要处理以下几类问题。

真实环境中的干扰并不只有其他说话人，还包括空调、风扇、键盘、回声和麦克风失真。

因此，一套完整的语音处理链路往往需要结合语音活动检测（VAD）、降噪、回声消除、音频分帧等技术。

例如，VAD 可以识别有效语音区间，减少长时间静音带来的无效计算；降噪则主要处理影响语音可懂度的环境干扰。

不过，环境降噪与目标说话人提取并不等价。普通降噪算法可以有效削弱机械噪声，却未必能准确消除另一个正在讲话的人。

离线转写可以在拿到完整录音后进行识别，实时转写则必须随着音频不断输入，持续输出可用结果。

实时系统需要考虑模型首结果延迟、语音分块长度、上下文缓存和增量文本修正等问题。

如果模型使用较长的上下文才能保证识别质量，实际系统就可能在识别准确性与响应速度之间进行权衡。

此外，真实业务还有并发需求。单路音频处理流畅，不代表同时接入多路麦克风、会议室或语音终端时仍然能够满足延迟要求。

通用语音模型可能对日常交流识别得很好，但在医疗、制造、科研等场景中，专业术语、英文缩写和产品型号仍然容易出现错误。

行业应用通常需要结合领域词典、热词机制、术语纠错和业务上下文，提高关键实体的识别稳定性。

与此同时，方言和地方口音也会影响识别效果。面对全国性企业或者跨地区业务系统，单纯测试标准普通话通常不足以覆盖真实需求。

除了常见的 WER、CER，复杂语音系统还应根据任务引入其他指标。

例如，Speaker Diarization 可以使用 DER 衡量说话人分离错误；目标说话人识别可以采用 TS-WER、TS-CER；当系统具有目标缺席拒识机制时，还要考察拒识率（RR）和误拒率（FRR）。

对于实际部署，还需要记录实时率（RTF）、推理延迟的 P95/P99、资源占用和多路并发表现。

这些指标合在一起，才能比较完整地反映一个 ASR 系统的工程价值。

五、从语音识别模型到 OEM 能力模组：另一条产业化路径

随着开源 ASR 技术逐渐成熟，越来越多的终端厂商和行业软件开发者开始面临一个实际问题：是否有必要从零研发自己的语音识别系统？

例如，一家生产会议终端的硬件企业，可能已经具备成熟的麦克风阵列、录音与数据管理能力，但缺少语音转写和说话人识别算法；一家开发行业业务系统的软件企业，可能只希望增加语音录入、多人对话记录或者语音检索功能。

对于这类需求，完整的 AI 会议软件并不是唯一选择。

通过 SDK、API 或本地化 OEM 模组，把语音识别和声纹能力嵌入既有系统，可以在保留原有产品界面和业务流程的同时，增加底层语音处理能力。

这也是 ASR 技术供应商与完整应用软件厂商之间的一种重要区别。

以熙瑾信息的语音技术体系为例，其现有能力覆盖语音实时转写、多人说话人区分、声纹识别、多语种及方言识别。熙瑾会悟作为完整的 AI 会议应用，已经将这些能力组合进会议录音、发言人识别和智能纪要等业务环节。

但同一套技术能力并不一定要与完整会议软件绑定。

面向第三方设备和软件开发商，熙瑾的 ASR 能力可以通过 OEM 集成方式输出，按照业务需求组合语音转写、说话人识别、声纹管理等模块。对于需要在内网环境中处理敏感音频的客户，也可以采用本地化部署方式，让语音数据在客户控制的计算环境中完成处理。

这种技术集成方式尤其适用于已经拥有成熟业务系统、但希望补充语音交互能力的企业。

例如，智能录音设备可以在原有录音功能之外增加语音转写与发言人标记；行业访谈系统可以将音频内容转化为带有时间信息和说话人标识的文本；业务终端则可以根据使用场景接入语音输入、声纹验证或者特定语音指令识别。

对于 OEM 集成而言，真正需要交付的不只是模型文件，还包括规范的接口、音频数据处理流程、模型运行环境以及与现有系统之间的协作机制。

如果采用本地化部署，还应同时评估国产操作系统兼容性、硬件加速、并发容量和长期维护成本。完整应用的兼容性认证与独立 OEM 模组的适配结果应分别验证，不能简单地视为同一份测试结论。

当然，常规的说话人区分与声纹匹配，并不自动意味着具备 CocktailASR 式的端到端重叠语音识别能力。对于真正需要在强重叠语音中提取指定说话人内容的客户，应将这一能力作为单独的测试项目。

OEM 的价值是把复杂的语音算法变成能够接入现有业务、能够部署、能够维护的技术能力，而不只是提供一个识别精度不错的模型。

六、ASR 的下一阶段：不只是把声音转换成文字

回顾自动语音识别的发展，早期系统主要解决的是能否听懂连续语音，之后逐渐扩展到多语言、方言、实时识别和复杂噪声环境。

Xiaomi-CocktailASR-1 所体现的技术方向，则进一步强调了说话人的作用。

在多人交谈场景中，识别出了什么文字固然重要，但这些文字属于谁、是否混入了其他人的发言、目标人物没有讲话时系统能否保持沉默，同样影响最终结果。

未来的 ASR 系统可能会更加重视语音内容与说话人信息的联合建模，同时与降噪、声源定位、声纹识别和上下文理解等技术进一步融合。

而在产业应用层面，完整应用、开放 API、本地化 SDK 和 OEM 能力模组也会继续承担不同的角色。

对于开发者而言，值得关注的不仅是新的开源模型刷新了多少性能指标，更是这些技术如何进入现实中的会议设备、行业软件和智能终端。

小米 CocktailASR 带来的启示：当语音识别开始区分“谁在说话”，ASR 技术正在发生什么变化？

人工智能

开发工具

新闻资讯

小米开源CocktailASR-1模型，专注解决“鸡尾酒会问题”，通过参考声纹在多人混合语音中精准识别指定说话人。端到端架构结合Data2Vec2与Qwen3-8B，支持单人场景与负样本拒识，LibriMix测试集错误率低至4.11%。本文解析其技术原理、与说话人分离的差异及工程部署挑战。

数据管理

数据处理

身份验证

内容识别

系统测试

深度学习

语音识别

软件开发

服务器

GitHub

语音产品特惠新用户14.9元起


2026上云采购 | AI焕新·智启新局

fele

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

小米 CocktailASR 带来的启示：当语音识别开始区分“谁在说话”，ASR 技术正在发生什么变化？

小米 CocktailASR 带来的启示：当语音识别开始区分“谁在说话”，ASR 技术正在发生什么变化？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐