从多模态 LLM 中引导构建音频嵌入

作者来自 Han XIao https://jina.ai/将任何多模态 LLM 转换为一个小型音频嵌入模型使用少 25 倍的数据超越 CLAP。GitHub - jina-ai/audio-embedding-kickstarter · GitHubGoogle 最近发布了 Gemini Embedding 2这是他们第一个原生多模态嵌入模型。文本、图像、视频、音频、文档全部映射到一个统一的 3072 维向量空间中。这是更广泛的全能嵌入模型趋势的一部分使用单一架构处理所有模态的统一模型从 jina-embeddings-v4 到 Omni-Embed-Nemotron再到 Omni-5。在去年的 EMNLP BoF 会议中我将全能模型作为 2026 年稠密检索的关键方向之一进行了介绍。我们关注的是音频。大多数人听到“多模态嵌入”时会想到图像可能还会想到视频。音频是被遗忘的模态更难收集更难标注并且从事这方面研究的人更少。在 Jina AI我们正好探索了这个问题构建小型1.2B 参数音频嵌入模型作为我们迈向全能嵌入模型工作的一部分。Gemini Embedding 2 的发布是分享我们一路探索过程中所学经验的好时机。音频嵌入音频嵌入是音频片段的固定长度向量表示。给定一个原始波形模型会生成一个稠密向量通常为 768 到 3072 个维度该向量捕获声音的语义内容。具有相似含义的两个音频片段会产生相似的嵌入并且一个音频片段会在共享嵌入空间中靠近它的文本描述。这是全能嵌入拼图中的一部分一旦你能够在同一个向量空间中嵌入音频、文本和图像就可以实现跨所有模态的跨模态检索。自 2022 年以来主流方法是 对比语言-音频预训练Contrastive Language-Audio PretrainingCLAP它将 CLIP 扩展到了音频领域。LAION-CLAP 使用 630K 对数据和特征融合对其进行了扩展。最强的变体Elizalde 等人2023使用 460 万对数据进行训练采用一个跨越 22 个多样化音频任务的音频编码器并与自回归解码器配对在 AudioCaps 上以 250M 参数实现了 42.0 cvR5。我们采用了不同的路径将已经理解音频的多模态 LLM 转换为嵌入模型。架构首先了解输入和输出内容。输入是原始音频从任何标准格式WAV、MP3、FLAC解码得到的波形并重新采样为 16kHz 单声道。音频编码器将这个波形转换为 128-bin 对数梅尔频谱然后将其处理为特征 token 序列大约每秒 150 个 token。一个 10 秒的音频片段会产生约 1,500 个 token。最大输入长度为 30 秒更长的音频需要进行分块处理。输出是一个单一的稠密向量即嵌入维度通常根据 LLM 主干模型大小不同在 896 到 3584 之间。我们从 Qwen2.5-Omni 开始这是一个具有原生音频理解能力的多模态 LLM。它包含三个组件一个音频编码器约 0.6-0.8B 参数通过约 4.5M 参数的线性投影将波形转换为特征向量一个 LLM 主干0.5-7B 参数使用每个 Transformer 层增加约 0.2B 参数的方式同时处理音频特征和文本 token以及一个池化层将最后隐藏状态进行平均池化转换为单个嵌入向量。两种模态共享同一个 LLM 主干因此它们已经通过预训练实现了大致对齐。左侧标准方法对完整的 MLLM 进行端到端微调3-7B 参数。右侧模块组合将预训练音频编码器与更小的 LLM 主干进行配对。共享主干同时处理音频特征和文本 token在同一个向量空间中生成嵌入。训练目标是 InfoNCE 对比损失。每种模态独立进行编码损失在两个方向上计算并取平均def training_step(audio_batch, text_batch): audio_embeds model.encode_audio(audio_batch) # [B, D] text_embeds model.encode_text(text_batch) # [B, D] audio_embeds F.normalize(audio_embeds, dim-1) text_embeds F.normalize(text_embeds, dim-1) sim audio_embeds text_embeds.T / temperature # [B, B] labels torch.arange(len(sim), devicesim.device) loss (F.cross_entropy(sim, labels) F.cross_entropy(sim.T, labels)) / 2 return loss训练数据五个音频-文本对数据集共计 181K 个样本数据集样本数描述AudioSetStrong108K带时间标签的事件GPT 生成的描述AudioSet 的子集FSD50K41K人工标注的声音事件200 个类别Clotho19K音频描述生成详细描述UrbanSound8K9K城市声音分类MACS4K城市声学场景CLAP 使用了完整的 AudioSet200 万 音频以及其他来源的数据总计 460 万对数据。我们仅使用 AudioSetStrong约 100K。从预训练 MLLM 开始大幅减少了所需的数据量。def load_sample(audio_path, caption): waveform, sr torchaudio.load(audio_path) waveform torchaudio.transforms.Resample(sr, 16000)(waveform) audio_inputs processor.feature_extractor( waveform, sampling_rate16000, return_tensorspt ) text_inputs processor.tokenizer(caption, paddingTrue, return_tensorspt) return audio_inputs, text_inputs四种方法目标构建一个小于 1.2B 的音频嵌入模型并超越 CLAP。完整模型微调。在音频-文本对上使用 Qwen2.5-Omni-7BAudioCaps T2A cvR5 63.2Clotho T2A 39.2。这是上限但 7B 无法部署。Tevatron 2.0 同样仅使用 AudioCaps 进行微调61.2但 Clotho 仅为 11.9表明单数据集训练的泛化能力较差。ColQwen-Omni 使用视觉文档任务进行微调没有使用任何音频数据通过跨模态迁移实现了 37.4。层剪枝。从 7B 模型中移除 Transformer 层。每层约 0.2B因此一个 10 层模型总参数量约为 3.5B。随着移除 Transformer 层模型性能与模型大小之间的关系。AudioCaps红色从 20 层减少到 5 层时cvR5 从 63.2 降低到 56.0。所有配置仍然超过 CLAP 基线虚线。即使在 5 层2.3B 参数时模型也无法达到 1B 目标。层数参数量AudioCaps T2A cvR5Clotho T2A cvR5205.8B63.239.2103.5B58.236.552.3B56.036.0批次大小32、64、128没有带来明显差异。更大的批次最初会有所帮助但后期可能会导致性能下降批次大小为 128 时在 Clotho 上训练 2K 步达到 31.3 NDCG但在 10K 步时下降到 29.3。仅文本模态迁移。仅使用文本对进行微调MultiNLI、SNLI、FEVER、SciFact依靠预训练的跨模态对齐能力。在完整的 7B 模型上有效AudioCaps 46.1超过 CLAP 的 42.0但在剪枝后的 10 层模型上完全失败cvR5 5.9。跨模态连接分布在整个网络中无法在剪枝后保留下来。模块组合。突破点从一个模型中获取音频编码器从另一个模型中获取小型 LLM甚至可以跨越不同模型系列。Qwen2.5-Omni 通过三个阶段进行训练1冻结 LLM 的情况下训练音频/视觉编码器2解冻所有参数332K 上下文。我们组合来自不同阶段的模块配置音频编码器LLM参数量M1Qwen3-Omni0.6B预阶段 1Qwen2.5-0.5B1.1BM2Qwen3-Omni0.6B预阶段 1Qwen2.5-3B3.6BM3Qwen2.5-Omni-3B0.8B后阶段 3Qwen2.5-3B3.8BM4Qwen2.5-Omni-3B完整完整 3B3.8B实现细节Qwen3-Omni 使用Qwen3OmniMoePreTrainedModel而独立的 Qwen3 使用Qwen3ForCausalLM。我们使用匹配维度初始化一个 Omni 模型外壳并将权重复制到对应位置。每个配置的 AudioCaps 和 Clotho T2A cvR5。M1 在 1.1B 参数规模下AudioCaps 达到 49.7超过 CLAP42.018%。使用经过后阶段 3 训练、对齐效果更好的音频编码器可以提升结果M3 对比 M2AudioCaps 提升 4.2。LLM 预训练的阶段 2-3 对嵌入质量并不关键M3 对比 M4 的差异在噪声范围内。评估评估音频嵌入的核心在于检索质量给定一个文本查询模型是否能够找到正确的音频片段关键挑战在于“正确”取决于数据集。AudioCaps 包含具体描述“一个人在说话随后一扇门关闭”而 Clotho 包含抽象描述“带有远处隆隆声的安静氛围”。一个记忆表层音频特征的模型在 AudioCaps 上表现良好但在 Clotho 上会遇到困难。我们最关注的是跨描述风格的泛化能力。CV-Recall5cvR5对于每个文本查询检查前 5 个结果中是否出现任何正确的音频片段。对所有查询取平均的二元评分。这是 MTEB 音频检索中的标准指标。def evaluate_cvr_at_k(model, dataset, k5): audio_embeds model.encode_audio(dataset.audio_clips) text_embeds model.encode_text(dataset.text_queries) sim F.normalize(audio_embeds) F.normalize(text_embeds).T hits 0 for i in range(len(dataset.text_queries)): top_k sim[:, i].argsort(descendingTrue)[:k] if dataset.ground_truth[i] in top_k: hits 1 return hits / len(dataset.text_queries)来自 MTEB 的三个评估数据集AudioCaps来自视频人类生成的描述、AudioSetStrong带时间标签GPT 描述、Clotho多样化抽象描述。CLAP 使用了完整的 AudioSet200 万而我们使用了 AudioSetStrong约 100K这部分解释了 CLAP 在该基准测试上的优势。横向条形图比较所有模型配置在 AudioCaps、AudioSetStrong 和 Clotho T2A 检索上的表现。红色虚线标记 CLAP 基线。模块组合模型绿色在小得多的规模下取得了强劲结果。完整的 7B 微调模型深蓝色设定了上限。应用音频嵌入正在传统检索之外变得越来越重要。在 agent 系统中音频嵌入可以实现意图路由接收语音输入的 agent 可以对音频进行嵌入并根据语义相似性将其路由到正确的工具或子 agent而无需等待完整转录。声音事件分类可以支持工业环境、智能家居自动化和安全系统中的实时监控。在多模态 agent 工作流中音频嵌入让 agent 能够像处理文本和图像一样对音频内容进行搜索、比较和推理。音乐和媒体应用使用它们进行相似性搜索、版权检测和内容推荐。随着语音接口成为 AI agent 的默认交互方式可以在设备端运行的紧凑型音频嵌入对于低延迟、保护隐私的应用变得至关重要。结论从预训练 MLLM 开始是最大的杠杆。它在一个统一组件中提供了跨模态对齐、强大的文本编码器以及高能力的音频编码器。模块组合是最有前景的方向混合来自不同模型和训练阶段的音频编码器与 LLM开启了一个几乎未被探索的设计空间。我们的模型在 AudioCaps 上占据优势但在 Clotho 上只能与 CLAP 持平而 Clotho 的抽象描述暴露了 AudioCaps 未能发现的弱点。跨模态迁移无法在模型压缩后保留。这项工作是迈向全能嵌入模型的一步一个能够将文本、图像、音频、视频和文档嵌入到统一检索空间中的单一模型。模块组合方法表明你可以通过复用预训练组件高效地引导构建新的模态。下一步包括使用 500M 激活参数的 MoE 架构将模块组合与模态迁移结合以及使用 WavCaps、MusicCaps 和语音数据集扩展数据规模。原文https://jina.ai/news/bootstrapping-audio-embeddings-from-multimodal-llms/