为什么你的会议录音转出来一团糟

如果你经常要整理会议纪要，一定遇到过这种崩溃时刻：远程会议录完音，丢进转文字工具，结果张三说话和李四说话全糊在一起，输出内容像一锅乱炖。更糟的是，线下讨论时几个人同时插话，传统 ASR 直接“宕机”，要么漏掉关键信息，要么把不同人的话拼接成一句谁也看不懂的句子。

问题的根源在于，传统语音识别模型被设计成“听到什么写什么”。在单人、安静、无混响的理想环境下这没问题，但一旦进入真实会议场景——多人交叉发言、设备拾音距离远、会议室混响严重——模型就懵了。它缺乏“选择性听觉”，无法像人类一样把注意力锁定在某一个具体的人身上。

小米最近开源的 CocktailASR-1 换了个思路：不是让模型更努力地“降噪”，而是直接告诉模型“只听这个人的”。这种目标说话人语音识别（Target Speaker ASR）的设计，让模型先认识目标说话人的声音特征，再只转录这个人的内容，从根本上解决了多人场景下的识别混乱。

目标说话人语音识别的核心逻辑

传统方案走的是“先分离、后识别”的流水线：先用一个独立的说话人分离模块把混合音频拆成单轨，再分别送入 ASR 模型。这个路径有几个绕不开的痛点——分离模块引入的延迟、分离错误向识别模块的累积传播、以及整套系统在不同场景下需要切换不同模型的维护成本。

CocktailASR-1 的做法更直接。它采用端到端的 LLM 架构，整条链路是 D2V2 音频编码器 → Adapter → LLM 解码器，所有权重放在一个 checkpoint 里。输入端的设计很巧妙：把参考音频和目标音频拼接在一起，中间插入一秒静音作为分隔，统一以 16kHz 单声道格式送入模型。

参考音频的作用是让模型“认识”目标说话人。通常只需要几秒到十几秒的清晰语音，比如会议开始前让老板简单打个招呼，或者从之前的录音里截一段。模型通过这段参考音频提取说话人的声纹特征，然后在后续的目标音频中定位并只转录这个人的内容，自动过滤掉其他人的说话声、会议室混响和背景噪音。

这种设计意味着单人会议和多人会议可以用同一个模型处理，不需要针对不同场景切换不同的模型配置。对于经常要处理不同类型会议的职场人来说，这省去了不少折腾。

从准备参考音频到拿到转写结果

实际操作起来，整个流程可以拆成几步，每一步都不复杂。

第一步：准备参考音频。 最理想的情况是在会议开始前，让目标说话人对着设备说几句话，录个 5-10 秒即可。如果做不到现场录制，也可以从之前的会议录音、视频素材或语音消息里截取一段清晰的片段。关键是这段音频要只包含目标说话人的声音，不能有其他人重叠。

第二步：拼接输入格式。 把参考音频和目标音频（即整段会议录音）按顺序拼接，中间插入一秒静音。格式要求是 16kHz 单声道。用 Python 和 librosa 可以很快搞定：

import librosa
import numpy as np

ref, sr = librosa.load("boss_reference.wav", sr=16000)
target, _ = librosa.load("meeting_full.wav", sr=16000)
silence = np.zeros(int(16000))  # 1秒静音

combined = np.concatenate([ref, silence, target])

第三步：送入模型推理。 把拼接后的音频输入 CocktailASR-1，模型会输出目标说话人的转写文本。由于整个过程是端到端的，不需要额外的分离或后处理步骤，延迟比流水线方案明显更低。

第四步：后处理与校对。 虽然模型已经做了过滤，但会议场景复杂，建议对输出结果做一遍快速校对，特别是涉及数字、专有名词的部分。

这个流程里最省心的设计是，即使会议室里其他人也在说话，甚至和目标说话人同时发声，模型依然能比较稳定地锁定目标。这对于经常要整理“吵架式讨论”会议纪要的人来说，简直是救命功能。

负样本拒识：目标说话人没说话时怎么办

真实会议里还有一种常见情况：你只想转录老板的发言，但老板中间去接电话了，二十分钟内都是其他人在讨论。传统 ASR 会不管三七二十一全部输出，最后你还得在大量无关内容里翻找老板的话。

CocktailASR-1 内置了负样本拒识机制。当参考音频对应的目标说话人没有参与当前对话时，模型会直接输出空文本，而不是强行转录一段内容凑数。

测试数据显示，这个机制的拒识率相当可观：在 LibriSpeech 负样本上达到 79.59%，Aishell 上 75.35%，小米自有的中文测试集上也有 68.54%。作为对比，同赛道的 Qwen3-ASR 和 StepAudio 目前不具备这种能力，目标说话人不在场时仍可能输出一堆无关内容。

对于需要批量处理大量会议录音的场景，这个功能能显著减少后期筛选的工作量。你不需要再打开每一段音频人工确认“这段有没有老板说话”，模型已经帮你筛了一道。

端到端架构的延迟与精度优势

前面提到传统“分离+识别”流水线的痛点，这里可以展开聊聊 CocktailASR-1 端到端设计带来的具体好处。

延迟方面，流水线方案需要等分离模块处理完一整段音频，才能送入识别模块。分离模块本身计算量不小，尤其是面对长音频时，累积延迟会非常明显。端到端方案则是一遍过，音频编码后直接进 LLM 解码，省去了中间环节的等待。

错误累积方面，分离模块的失误会直接传递给识别模块。比如分离时把目标说话人的半句话和另一个人的半句话拼在了一起，识别模块只能对着这个错误输入硬转，出来的结果自然离谱。端到端方案让模型自己学习“该听谁的”，避免了这种错误传播。

精度方面，CocktailASR-1 在多个基准测试上的表现都很能打。多说话人模拟测试中，LibriMix 2mix 的 WER（词错误率）只有 4.11%，LibriMix 3mix 上是 12.29%——这个测试里 Qwen3-ASR、Gemini、StepAudio 都未能有效输出。真实会议数据集上，AMI SDM 的 WER 为 21.81%，AliMeeting Far 为 20.63%，相比已有方案优势明显。

AMI SDM 是业界常用的会议场景数据集，录制于实际会议室，包含多人讨论的真实重叠和远场拾音问题。AliMeeting Far 则聚焦中文远场会议场景，对模型的抗混响和说话人分离能力要求更高。在这两个数据集上都能保持较低的错误率，说明 CocktailASR-1 已经能覆盖大多数真实会议场景的需求。

思维链推理：让模型“解释”自己听到了什么

除了核心的识别能力，CocktailASR-1 还有一个有趣的附加特性：思维链推理（Chain-of-Thought）。模型在输出最终转写结果前，会先展示一段推理过程，说明它为什么认为某段语音属于目标说话人。

这个功能对调试和可解释性很有帮助。比如你发现某次会议的转写结果里混进了另一个人的几句话，可以查看推理过程，定位是参考音频质量不够、还是那段语音确实和目标说话人声音过于相似。虽然展示推理过程会稍微增加输出长度，但对最终精度的影响很小，属于“花小钱办大事”的设计。

实际使用中，你可以根据场景决定是否开启这个功能。需要快速出结果时关闭，追求可解释性或遇到疑难问题时打开，灵活调整。

单人场景也不含糊

可能有人会问：我大部分时候是单人会议，用这个模型是不是大材小用？

CocktailASR-1 在单人场景下的表现同样扎实。LibriSpeech 等经典数据集上的测试显示，它的识别精度在单说话人任务上也领先于不少通用 ASR 模型。这意味着你不需要为不同场景维护不同的模型，一个 checkpoint 覆盖单人、多人、安静、嘈杂等各种情况，对于技术栈精简有要求的团队来说，部署和维护成本都更低。

实际落地的一些建议

如果你打算把 CocktailASR-1 用到工作流里，有几点经验可以参考。

参考音频的质量很关键。 尽量选目标说话人发音清晰、背景干净的片段。如果参考音频本身就有其他人说话或噪音干扰，模型定位的准确性会打折扣。条件允许的话，可以为目标说话人建立一个小型的参考音频库，不同场景下选用最合适的片段。

合理设置负样本预期。 虽然负样本拒识率已经不错，但 68%-79% 意味着仍有少量漏网之鱼。对于特别重要的会议，建议结合时间戳快速过一遍空输出段，确认没有遗漏关键内容。

长音频分段处理。 会议录音动辄一两个小时，直接整段送入可能会遇到内存或时长限制。可以按说话轮次或固定时长分段，注意分段时保留足够的上下文，避免在句子中间切断。

与其他工具链结合。 转写结果可以进一步接入摘要生成、待办提取、关键词标记等 NLP 工具，形成从“录音”到“可执行结论”的完整工作流。CocktailASR-1 的端到端特性让它很容易嵌入这类 pipeline，不需要为音频预处理环节做额外适配。

写在最后

从“听到什么写什么”到“只听这个人的”，CocktailASR-1 代表了一种思路上的转变。它不再把多人会议场景当作需要“克服”的噪音问题，而是把目标说话人信息作为输入的一部分，让模型主动聚焦。对于每周要开七八个会、会后还要花大量时间整理纪要的职场人来说，这种“精准抓取”能力意味着从繁琐的人工筛选中解放出来。

目前模型已经开源，感兴趣的话可以直接下载 checkpoint 试用。毕竟，能让周一早晨的会议纪要少熬半小时，怎么都是值得的。