“大模型真的听懂你在说什么吗”这句话如果拿去问做过语音评测的人八成会得到一声冷笑。过去一年文本大模型评测已经卷到小数点后两位语音方向的 benchmark 却还停在“转写对不对”的层面。少数能直接吃音频的模型评测方式也大多是给一段语音然后问几个常识问题跟真正的“听懂并推理”差得还挺远。我最近一直在跟的一个工作就是把口语感知和推理放在同一套基准里做系统性评估目标瞄准 ICLR 2026暂定名字叫“口语感知与推理基准”。一开始我也觉得语音评测不就是 ASR 加几个 QA 吗真正动手才发现难点在于“口语”和“书面文本”根本是两种载体。人在说话时会有停顿、改口、倒装、重音、情绪还有环境噪声和多人插话这些信息一旦被 ASR 转成文字几乎全丢了。我们要做的不是再出一个“更难一点的 SpeechQA”而是把感知、理解、推理拆开分别看模型到底在哪一层断掉。这篇文章把我自己踩过的坑、跑过的基线、以及设计基准时反复纠结的细节整理出来给想做语音 LLM 评测、或者想给自己的模型搭内部口语测试集的朋友做个参考。1. 为什么还需要一个“口语感知与推理”基准1.1 现有评测的盲区都在考“转写”而不是考“听懂”现在市面上常见的语音理解评测大致分三类。第一类是纯 ASR benchmark例如 LibriSpeech、Common Voice它们只关心字错误率模型输出转写文本跑分一目了然。第二类是口语问答例如 OpenASR 扩展出来的 QA 任务给一段音频模型回答一个事实型问题但问题大多固定在“这段语音讲了什么主题”“说话人提到的时间是几点”本质上还是信息检索。第三类是语音翻译、语音命令识别这类任务它们更偏工程指标跟“推理”基本不沾边。这一类评测有个共同问题把 ASR 当成了口语理解的代理指标。只要转写正确就默认模型“听懂了”。可现实里大模型真正要面对的是会议纪要、客服对话、车载指令、课堂问答里面充满“不是在开玩笑吗”“三千不五千左右吧”“他说的是 John 还是 Jack”这种需要借助语气和上下文才能解读的内容。ASR 转写出来字面上可能完全通顺但意思已经变了一个量级。我也试过直接拿 Whisper 转写文本喂给 GPT-4o 或 Claude文本推理确实很强但一旦问到“说话人是在夸还是在讽刺”“这句话说完之后为什么改口了”模型几乎只能靠瞎猜。问题不是出在 ASR而是出在评测任务根本没设计“声学信息能帮忙推理”的题目。很多所谓语音评测只是把文本问答的题干用 TTS 读了一遍模型只要转写对推理就能对那测的到底是大模型还是 ASR1.2 口语场景到底难在哪韵律、改口和噪声文本里全看不见口语和书面语最大的差异不是“多了一些语气词”而是信息密度和表达方式完全不同。书面语是组织好的口语是实时的。说话人会在半句话里改主意会先说一个词再纠正会用重音强调某个数字会通过语气把疑问句和反问句区分开这些信息全部藏在声学信号里。举一个我在评测集里反复用的例子。原始音频是“我们预算大概是…三千不五千左右吧你按三千估就完了。”如果只看 ASR 转写模型通常会得到一句看似矛盾的文本。问题是“最后按多少预算估算”很多模型回答“五千”因为它们捕捉到了最后出现的数字。但人类听完原始语音能靠“你按三千估就完了”这个收尾语气判断说话人最终想要的是预算按三千来估算。这里“五千”只是他中途的自我修正不是结论。这种题目在纯文本 QA 里几乎不可能出现因为文字已经把口头修正的先后顺序摊平了。类似的还有指代。音频里说“他刚才说 John 昨天到了哦等一下不是 John是 Jack。”问“谁昨天到了”答案是 Jack但级联系统很容易答成 John。因为 ASR 转写里两个名字都出现了文本模型如果没有足够的上下文建模能力就会被先出现的名字带走。再就是噪声场景。会议录音里经常有两个人同时开口椅子移动声、键盘声混在一起关键数字被盖了一半。模型要做的不是“完美降噪”而是利用语义推测被遮挡的信息。这要求模型同时具备声学鲁棒性和语言先验这是单纯的 ASR 指标永远体现不出来的。1.3 这套基准想回答的核心问题模型是真听懂了还是只是把音频转成文本再读一遍我们设计这套口语感知与推理基准时内部吵得最多的一个问题是我们要“测能力”还是要“测用户体验”后来达成的共识是最终目标只有一句话——判断模型是否真的以语音为输入进行了推理而不是把它当成“ASR 加文本 LLM”的流水线来验收。为了回答这个问题我们把推理链路拆成三层。第一层是感知层模型能否从带噪、带口音、多说话人的原始音频中提取关键信息。第二层是理解层模型能否理解口语中的省略、指代、修正和情绪。第三层是推理层模型能否基于听到的信息完成逻辑推理、数学计算、因果判断和决策。三层对应三种评测条件直接听音频回答audio-only、给人工转写回答oracle transcript、给 ASR 自动转写回答ASR transcript。通过对比这三种条件下模型的成绩就能量化出误差的来源。如果 audio-only 表现很差但 oracle transcript 表现很好说明模型不擅长声学感知如果 oracle transcript 表现差那就是文本推理能力不足如果 audio-only 比 ASR transcript 还好说明模型确实能利用声学信息弥补转写错误。这个设计虽然简单却把“听懂”拆成了一个可诊断、可定位的指标体系。2. 基准设计任务体系与数据构建2.1 能力矩阵怎么拆声学、语用、逻辑三个维度不能混在一起整个基准最核心的部分是能力矩阵。我们没有沿用“语音问答”“语音摘要”这种按任务形态分类的方式而是先定义能力维度再为每个维度设计任务。原因是按形态分类会让结果无法归因同一个模型在“语音摘要”上表现差你很难知道是因为它没听见关键内容还是因为摘要能力本身弱。我们最终落地了六个能力维度。第一个是声学感知包括噪声鲁棒、重音识别、多说话人区分、方言与口音适应。第二个是语言与指代理解测试省略、指代消解、口头修正、倒装结构。第三个是语用推理包括反讽、委婉、情绪归因、说话人意图。第四个是逻辑推理包括基于语音的数学计算、条件推理、因果推断。第五个是知识应用用口语表达的方式考察模型能否调用常识和世界知识。第六个是长程记忆给一段 3 到 5 分钟的对话要求回答前文信息考察模型能否在长语音里定位并关联信息。每个维度单独计分同时输出一个加权总分。我们在设计时参考了 MMLU 的分层做法但把输入从“文本题干”换成了“真实语音加问题”。最早期版本我试过把所有任务混在一起打分结果完全看不出瓶颈后来才拆成这个矩阵。诚实说拆维度会让评测集构建成本翻倍但换来的可解释性值得。2.2 六类口语推理任务从“找数字”到“听出话外音”能力矩阵落成具体任务时我们设计了六类每类下再细分若干子任务。第一类是感知问答。音频里包含背景音乐或多人说话问题是“第二个说话人提到的订单号是多少”。这类题考的是在杂讯中锁定目标说话人并提取精确信息。第二类是指代修正。音频中有人先说 A 再改成 B问题是“最终确认的是哪一项”。这类题专门针对口语修正级联模型最容易翻车。第三类是语用理解。一句“你动作真快啊”配合不同语气可能是夸也可能是讽刺问题会明确问“说话人表达的是正面还是负面态度”。第四类是口语推理。给一段两三句话的语音例如“如果明天不下雨我们就去爬山结果早上天气阴阴的但没下雨”问“他们是否会去爬山”。第五类是长程信息定位。一段五分钟的会议录音穿插大量无效信息问“最后决定由谁负责预算”模型需要从后半段记忆中找到答案。第六类是混合指令执行。音频里包含口语数字、单位、方向词和条件限定例如“去三楼右边的第二个房间拿蓝色文件夹”考察多跳指令跟随。每种子任务我们都保证答案是可判定字符串而不是开放作文。这样评测时既可以用严格的精确匹配也可以用宽松的语义匹配避免评分主观性。2.3 数据来源与标注细节真实录音为主TTS 做对抗性补充数据永远是 benchmark 最麻烦的一环。我们一开始尝试纯用 TTS 合成语音好处是控制变量方便但很快发现模型很容易在合成语音上过拟合而且合成语音缺少真实口语的错乱、吞音和背景声测出来的“感知能力”太虚假。后来改成了“真实录音为主TTS 做对抗性补充”的策略。真实录音主要来自三块公开授权的播客和访谈、客服对话脱敏样本、以及我们自己在办公室录制的多人讨论。每条语音都经过人工转写再按照能力矩阵生成题目。这里有个关键细节题目不能只看转写生成标注员必须听完音频再写问题。因为很多语用和修正信息只靠看的根本看不出来只有听了原音才知道这里适合出什么题。TTS 部分则专门用来制造“对抗性样本”把关键数字随机替换、在音频后半段加入突发性噪声、模拟电话语音的带宽限制、混合两种方言口音。这样做是为了防止模型靠静音、时长这类非语义特征作弊。我们还特意加入了“诱饵信息”音频里会出现一个显然错误、但字面上更显眼的数字或人名看模型是否会被带偏。所有题目在进入测试集之前都要做 n-gram 重叠检查确保语音的转写文本与网络公开语料没有过度重合降低数据污染的隐患。3. 评测实操从跑通基线到读懂结果3.1 搭建评测环境音频要统一到 16kHz别让采样率成为变量我第一次跑评测时犯了一个很蠢的错不同模型内部要求的采样率不一样有的支持 16kHz有的支持 24kHz我直接按各自默认配置喂结果模型 A 和模型 B 的差距根本分不清是能力问题还是采样率问题。后来定了一个铁律所有音频统一预处理为 16kHz、单声道、16bit PCM WAV再按各模型的规范做内部重采样。评测脚本通常包括几步。先加载音频用torchaudio或librosa重采样到 16kHz再裁剪到模型支持的上下文长度内。我们的长程任务有五分钟音频但很多语音模型只支持几十秒这里需要做分段策略不能简单截断。我的做法是先用 VAD 切出说话片段再按“片段级检索加全局汇总”的思路设计 prompt把长音频拆成多段喂给模型最后让模型综合回答。硬件上我们评测 7B 到 8B 的开源模型单张 A100 就能跑主要瓶颈是长音频的预填充耗时。端到端语音模型比级联系统慢很多因为每一条音频都要和 prompt 一起过一遍模型。建议小批量跑先把问题、标准答案、音频路径写进 JSON逐个任务执行方便断点续跑。3.2 评测流程与指标audio-only、oracle transcript、ASR transcript 三条件并行完整流程是这样的先建一个统一的评测文件每条 sample 包含audio_path、question、standard_answer、task_type、condition。condition 有audio、oracle、asr三种。音频条件下直接把音频和问题拼进模型oracle 条件下把人工转写文本当作上下文asr 条件下先跑一个外部 ASR例如 Whisper-large-v3再把转写结果交给 LLM。输出答案后统一做规范化处理。英语去掉冠词和标点中文去掉标点和“的、了、呢”等干扰词。对精确匹配的任务用规范化后的严格相等判断对需要语义等价的任务用rougeL和bert_score作为辅助但最终榜单以人工抽检后的宽松匹配为主。我不太建议完全依赖 BERTScore因为它在短答案上噪声很大经常把“五”和“无”判成等价。指标上分四个维度汇报Audio-Acc是完整链路的成绩Oracle-Acc代表剔除了声学感知后的纯文本推理上限ASR-Acc代表在实际转写场景下的成绩Delta-Oracle是 Audio-Acc 减去 Oracle-Acc代表声学信息的损失如果这个值是正的很有意义说明模型能从语音里获得文本里没有的信息。3.3 我看到的典型失败模式改口、反讽、名字纠缠跑了几轮基线之后我的感觉是所有模型的失败都能归到四类模式里。第一类是“最后一位数字迷信”。只要音频结尾出现一个数字很多模型会直接把它当答案哪怕逻辑上它是被否定或修正的。前面那个“按三千估”的例子我把十来个模型的 answer 拉出来超过一半回答“五千”这就是典型的表面关联而不是因果推理。第二类是反讽识别能力接近于零。让模型判断“你动作真快啊”是夸还是损端到端语音模型略好但整体准确率也就百分之六十上下跟随机猜差不多。有意思的是给它人工转写文本之后成绩反而更差这恰恰说明声学语调是理解反讽的关键丢掉之后模型连判断依据都没有。第三类是双人名纠缠。John 和 Jack 出现在同一条语音里模型要么答成第一个出现的人要么直接说“无法确定”。级联系统尤其严重因为它们依赖的 ASR 对专有名词很容易听错——Whisper 在短人名上的错误率比我预想的高不少。第四类是噪声中的精确数字。电话语音加街道噪声的场景端到端模型偶尔能蒙对级联系统几乎必错。但这不是因为 LLM 推理出了什么反而是 ASR 把数字识别错误后文本模型强行“自圆其说”给出一个听起来合理但完全不对的数字。3.4 基线结果快照同一个 benchmark两种架构差距比想象中大为了验证基准的有效性我跑了三类代表模型一个级联系统Whisper-large-v3 加 Qwen2.5-7B-Instruct、一个端到端开源语音模型Qwen2-Audio-7B 类似的规模、以及一个闭源多模态语音 API。样本量为每任务 200 条共 1200 条说明不是完整跑分只是抽样子集。表三类模型在六个维度上的 Audio-Acc百分比近似值能力维度级联系统开源端到端闭源语音 API声学感知62.571.078.5指代修正48.052.561.0语用理解37.546.055.5逻辑推理65.058.569.0知识应用70.561.574.5长程记忆54.049.066.0这个快照最直观的结论是级联系统在纯文本推理上占优但语用和理解能力被 ASR 的丢信息拖累端到端模型声学感知更强但复杂逻辑明显弱一截闭源 API 相对均衡却也没有一项达到 80%。如果只看总平均分级联和开源端到端几乎打平可细看维度完全是两种能力的模型。这也再次说明综合分不拆维度就是耍流氓。4. 避坑指南与自己的评测集搭建4.1 评测污染最难防的一件事答案已经在训练集里了如果你准备公开发布口语评测集请务必把“防污染”摆在第一优先级。我见过不少团队拿语音问答集跑分模型分数奇高结果一查测试集就是网上流传过的版本模型早就在训练阶段见过文本转写了。语音评测的污染比文本评测更隐蔽因为即使模型没听过原始音频它也可能在大量网页文本里见过对应的转写稿。我们的做法是三道防线。第一测试集永不公开原始音频和标准答案的完整配对只发布一个抽样子集让大家看格式。第二发布前对所有问题的转写文本做 13-gram 重叠检测跟 Common Crawl、开源语料库比对重合度超过阈值的题直接替换。第三每年更新一个 held-out 版本放在加密环境里只对评测方开放 API。这听起来麻烦但真等到论文被质疑“数据泄漏”时再解释就晚了。4.2 提示词与参数设置差一个“请直接回答”结果可能差十个点语音模型对 prompt 的敏感程度不亚于文本模型。用“请听这段音频并回答问题”和“以下是一段音频请转写并回答问题”同一个模型在语用任务上可能差出十个点。原因是有些 prompt 会让模型误以为你在考转写于是它先输出一段“音频内容是……”再在最后给一个不完整的答案。我测试后比较稳定的指令是这样如果是端到端语音模型用“请根据语音内容回答问题。语音中可能包含噪声或无关信息请忽略。问题{question}。直接输出答案。”如果是级联系统把转写文本给 LLM 之前先强制加一句“请判断说话人的真实意图而不是只看字面意思”。虽然有点 hack但对语用类任务确实有效。生成参数记得固定temperature0、do_samplefalse、max_new_tokens64。长程任务的输出可以放宽到 256。不要开 beam search因为语音模型在解码时对重复惩罚的写法不一致开了反而让答案变得啰嗦。4.3 常见问题速查表自己搭评测时最容易踩的五个坑现象原因对策模型输出“我听到了……”而不是答案prompt 未约束直接回答在 prompt 尾部加“直接输出答案”同一模型两次跑分不同解码器温度未固定temperature 设为 0关闭采样Audio-Acc 比 Oracle-Acc 高声学信息在帮助推理细查是否利用重音/反讽确认不是随机转写正确但答案错误纯推理层失败单独查 oracle 条件定位到 LLM长音频任务全部超时上下文过长VAD 分段 分段摘要一些题所有模型全对大概率数据太简单或已泄漏对题目做难度分布和去重检查还有一个小技巧我一直建议团队在正式跑分前先做“冒烟测试”挑五条带明显改口、五个带明显噪声的音频先人工验证模型能否答对。如果连这几条都过不了后面大规模跑分大概率也是徒劳先调 prompt 或换模型别浪费时间跑完整集。4.4 想快速搭一个团队内部口语评测怎么做最小可行版本如果你不是要发论文只是想看看自己接的大模型语音能力到底行不行不用复刻整套复杂基准。我建议按最小可行版本搭两三天就能跑完。第一步去业务真实场景里录二十段音频每段 15 到 60 秒覆盖噪声、口音、改口三种情况。第二步人工写题目每段音频配两到三题既有事实题也有意图题。第三步把答案规范成语料 JSON内容包括audio_path、question、answer和type。第四步写好评测脚本先跑一个级联系统再跑你要选的端到端模型分别记录三条指标答案准确率、ASR 转写 WER、以及“提问者是否满意”的人工抽检率。这个过程中不要追求大而全。先挑一个业务上最痛的能力比如“客服对话中的诉求识别”针对它做 20 条测试比做 2000 条泛泛的题目有价值得多。评测集的建设本质上是把你的业务需求翻译成可判定的问题翻译得越准评测结果越能指导选型和迭代。我个人在实际操作中体会最深的一件事是评测基准不是为了证明某个模型更强而是为了让你清楚地知道它在哪一层会碎掉。这套口语感知与推理基准目前还在 ICLR 2026 的最小可用版本阶段任务权重和指标阈值都还会继续调。如果你也在做语音大模型的评测建议现在就开始录真实业务语音、写带修正和反讽的题目别等“统一标准”出现。语音评测的很多答案只有听过原始音频的人才写得出来。