GigaChat Audio: Time-aware Large Audio Language Model
Aleksandr Kutsakov, Mariia Sadovina, Georgii Gospodinov, Alexandr Maximenko, Oleg Kutuzov, Pavel Bogomolov, Fyodor Minkin
eess.AS, cs.CL
2026-07-12
把 hh:mm:ss 时间锚点周期性插入音频 token 流,音频大模型在 20-40 分钟录音上时序定位达 53.8 mIoU,最长支持 120 分钟,远超 Qwen3-Omni 与 Gemini 3 Flash。
音频大模型已经能听懂录音内容,但在长录音里做「时序定位」(temporal grounding)还是不行。问它「这句话出现在第几分钟」,它要么吐出无法解析的时间戳,要么给个很粗的范围,甚至编一个撑不住的时间。GigaChat Audio(来自俄罗斯 Sber 旗下的 AI 团队,模型已开源到 HuggingFace)要解决的,就是让音频 LLM 在最长 120 分钟的录音里,带着明确时间戳回答问题。
作者把问题拆成三件:用什么形式表示时间、怎么大规模造时序监督数据、以及怎么在不同时长间泛化。第三件他们发现一个不对称规律:只用短音频训练,推不到长录音上;只用长音频训练,短录音的表现又掉下去。必须混合。
模型底座是一个 10B 参数、激活 1.8B 的 MoE 文本模型,上下文 256k token。音频这一侧走 编码器→下采样→投影 的标准结构,用 FlashAttention 加 chunk-wise attention(8 秒一块、40ms 步长),输出 160ms 一帧的嵌入。音频编码器是 HuBERT 类的,在 2200 万小时数据上预训练过。
核心设计是把时间戳直接「插入」音频 token 流。每隔固定间隔(7 秒到 240 秒,可调)插一个时间锚点(inter-timing),让模型在听音频的同时不断读到「现在到第几分第几秒」的标记。锚点用纯文本 hh:mm:ss 格式,后面跟一个结束标记。这一招比专门的时间 token 又便宜又好训:用 hh:mm:ss 时,模型只要 16.7% 的时序数据占比就能达到 57.5 mIoU;换成专用 token,得喂到 50% 占比才追平。
监督数据靠级联(cascaded)流水线造:从 YODAS2 语料里筛出 1.4 万小时英语,用 WhisperX 打词级时间戳,从约 10 分钟的切片里生成问答,再单独跑一个 verifier 把前后对不上的滤掉。评测时每题生成 5 个候选答案做聚合。
| 任务 / 时长 | GigaChat Audio | 对照 |
| 时序定位 mIoU(20-40 分钟) | 53.8(inter=60s)/ 65.2(inter=7s) | Qwen3-Omni-30B 3.6 |
| AMI 会议(15-50 分钟)MAE | 3.50 秒 | Qwen3-Omni 290.5 秒 |
| 时序定位 mIoU(0-1 分钟) | 53.0 | Gemini 3 Flash 41.7 |
| 去掉时间锚点(20-40 分钟) | 14.2 mIoU | 有锚点时 53.8 |
锚点频率是精度和开销的权衡:每 7 秒插一个能到 63.0 mIoU,但要多吃 16% 的 token;每 60 秒插一个只有 50.9 mIoU,但只多 1.9%。时间格式里,hh:mm:ss(50.9)远好于把时间当成「第 N 秒」整数(20.9),后者训练崩得很厉害。
会议、讲座、播客、监控这类场景里,「这件事发生在第几分钟」是高频刚需。这篇用最朴素的方法(往音频流里插文本时间戳)把音频 LLM 的可用时长从几分钟推到两小时,而且锚点机制可调,部署时能在精度和算力之间自己挑。对做会议和播客 AI 的人,这是一个可以直接拿来用的开源基座。
作者承认,语言润色、合成监督、以及用 LLM 当评委做评测时都用了生成式 AI(他们称都经人工复核)。数据只筛了英语,多语种没覆盖。长度泛化的不对称说明它对训练时长分布敏感,换个分布未必稳。时间格式如果换成「第 N 秒」整数会崩,说明这个能力相当吃表示方式的选择,换法就有风险。