📄 不只用文字指挥检索:当嵌入器学会看区域、听时段

英文题目:Omni-Interactive Universal Embedder

一句话:为解决文本指令无法精确定位重叠声源与画外音的问题,OmniUE 以全模态大语言模型为骨干、用分段器把视觉掩码与音频时段编码为交互嵌入并做跨层聚合,在视频、音频与交互检索上均超越同规模基线,代价是依赖现成大模型与掩码推理的高开销。

标签:#音频检索 #多模态模型 #音视频理解 #对比学习 #基准测试

评分:7.5/10 | 创新 1.6/2 | 技术严谨 1.2/1.5 | 实验充分 1.2/1.5 | 清晰度 0.8/1 | 影响力 1.2/1.5 | 开源 0/1.5 | 可复现 0.5/0.5 | 工程/实践 1/1.5

👥 作者与机构

  • Wei-Yao Wang:Sony Group Corporation
  • Kazuya Tateishi:Sony Group Corporation
  • Shuyang Cui:Sony Group Corporation
  • Christian Simon:Sony Group Corporation
  • Takashi Shibuya:Sony AI
  • Shusuke Takahashi:Sony Group Corporation
  • Yuki Mitsufuji:Sony Group Corporation;Sony AI

💬 毒舌点评

首次把交互从文本扩展到视觉掩码与音频时序片段,并用分段器与跨层聚合把 omni-modal 输入真正做成了可条件化的统一嵌入,在 4 个系列基准上都拉开差距。短板是核心依赖 Qwen2.5-Omni 与 SAM-Audio / SAM-3 的现成能力且未开源任何产物,OmniCHOIR 仅 479 样本且合成流程重度依赖大模型生成,泛化与可复现性存疑。

📌 核心摘要

该工作要解决现有通用嵌入器仅支持文本指令、无法处理细粒度视觉与音频交互的问题,提出首个全模态交互式通用嵌入器 Omni-Interactive Universal Embedder(OmniUE)。方法以全模态大语言模型(omni Large Language Model,omni-LLM)为骨干,引入视觉分段器与音频分段器将点、框、掩码、时序片段等交互信号编码为交互嵌入,并通过 4 个可学习令牌在间隔 4 层的中间层抽取后加权聚合得到统一表示。与仅靠末层 EOS 表征或单一文本指令的范式不同,该设计同时建模全局上下文与实体/时段级线索。为评估该能力,作者构建了 OmniCHOIR 全模态交互式文本-视频-音频到音频检索基准,包含 7 种交互组合与 3 类困难负样本。实验中 OmniUE-7B 在 MMEB-v2-video 上总体 51.8 超最强 7B 基线 UME-R1 的 47.5 约 4.3 个点,在 SCaR 视觉交互任务上总体 55.2 超 VIRTUE-7B 的 27.8 约 27.4 个点,在 MAEB 上总体 53.4 超 LCO-Emb-7B 的 52.2,在 OmniCHOIR 全模态条件下 28.4 超 LCO-Emb-7B 的 23.8,验证了多模态交互与跨层聚合的有效性。该框架为检索、上下文工程与智能体记忆等需要用户条件化表征的场景提供了可复用路径。主要局限在于强依赖预训练分段器与 omni-LLM、掩码交互带来显著推理开销、且 OmniCHOIR 规模与合成偏差仍需更大规模验证。

🔗 开源与复现资源

  • 代码:论文中未提及代码链接
  • 模型权重:论文中未提及,未提供 HuggingFace 或 ModelScope 具体链接,仅说明基于 Qwen2.5-Omni-3B 和 Qwen2.5-Omni-7B 初始化
  • 数据集:提出 OmniCHOIR 基准,基于 SAM-Audio-Bench 构建,包含 819 个 10 秒样本,视频来源为 AudioSet、VGGSound、MUSIC、MUSIC-AVQA、AVSpeech、CondensedMovies 共 6 个公开数据集,背景音采样自 ESC-50 数据集,训练数据总量约 3.5M 多模态样本,论文中未提供数据集下载链接或开源协议
  • Demo:论文中未提及
  • 复现材料:附录 C 与 Table 5 提供完整训练配置,Omni-LLM 为 Qwen2.5-Omni-3B 与 Qwen2.5-Omni-7B,视觉分割器为 facebook/sam3,音频分割器为 facebook/sam-audio-base,SAC 头数 2,LoRA rank 32、alpha 64、dropout 0.1,温度系数 0.02,批量大小 1024,训练步数 3300,预热步数 200,学习率 2e-5,最大序列长度 20480,最大帧分辨率 156800,音频采样率 16kHz,优化器 AdamW beta1 0.9 beta2 0.999,精度 bf16,设备 8 张 H100 80G,训练时长 177 小时与 195 小时,评估基准包括 MMEB-v2-video、MAEB、SCaR 与 OmniCHOIR
  • 论文中引用的开源项目:Qwen2.5-Omni、Qwen2-Audio-7B、SAM-3、SAM-Audio-Base、LLaVa-OneVision-7B、LAION larger_clap_general、LoRA、GradCache、InfoNCE、SAM-Audio-Bench、AudioSet、VGGSound、MUSIC、MUSIC-AVQA、AVSpeech、CondensedMovies、ESC-50、MMEB-v2-video、MAEB、SCaR、VALOR-32K,论文中未提供上述项目的具体 URL 链接

🧭 深度解读

为什么只靠一句话,往往指不准你要的声音?

想象一段 10 秒的街景视频:画面里有人在说话,画外传来断断续续的鸟鸣,背景还有车流。用户想检索的不是笼统的“鸟叫”,而是“视频里那只鸟在 2 到 4 秒那两声清脆的叫声”。如果只能输入文字,模型很难区分“哪只鸟”“哪一段时间”“是不是画面里的那只”。文字太粗,视觉框选又可能框不到画外的声源,音频本身的重叠与间歇更让检索变得模糊。

嵌入器(embedder)的任务是把查询和候选都压成一个向量,用余弦相似度做检索。过去的通用嵌入器已经能把文本、图片、视频、音频混在一起编码,也能听懂“请找出符合这句话的音频”这类文本指令。但当用户想用手指一下画面某块区域,或在波形上圈出一段时,模型就没接口了。这正是这篇工作要补上的缺口:让嵌入器同时接受文字、视觉区域、音频时段这 3 种交互,并把它们和多模态查询一起,压成一个受用户条件控制的统一向量。

从双塔到大模型嵌入器,交互为何一直卡在文字上?

早期的多模态检索多用双塔结构(two-tower):一边编码文本,一边编码图像或音频,再拉近配对样本的距离。后来大家发现,用大语言模型(Large Language Model,LLM)做骨干的嵌入器更灵活——同一个模型,换一句指令就能做分类、问答、检索,因为大模型本身就擅长跟随指令。

这条路线先在图文、视频上跑通,随后扩展到全模态(omni-modal),也就是把文本、视频、音频都放进同一个大模型里统一编码。代表性的工作把 Qwen2.5-Omni 这类全模态大语言模型(omni-LLM)微调成嵌入器,实现了任意模态组合的输入。但交互方式几乎都停留在“文字指令”,唯一的例外是 SCaR 引入了视觉框选来做图文检索,仍局限在图像-文本。

OmniUE 的位置就在这里:它不满足于“多模态输入+ 文字交互”,而要做“多模态输入+ 全模态交互”。也就是说,查询可以是文本、静默视频、音频的任意组合,交互也可以是文字、视觉的点/框/掩码、音频的时序片段的任意组合。这一步把嵌入器从“听懂一句话”推向“看懂你指哪里、听懂你圈哪段”。

论文把什么定义为任务,又用什么来检验它?

作者把任务形式化为:给定一个多模态查询(文本、视频、音频的任意组合)和一组可选的全模态交互提示(文本描述、视觉区域、音频时段),模型输出一个 d 维的统一嵌入,用于和候选音频的嵌入做余弦检索。关键在于“条件化”——同一个查询,换一个掩码或换一个时段,嵌入应该跟着变。

为了检验这种能力,论文新建了一个基准 OmniCHOIR,全称是全模态交互式文本-视频-音频到音频检索。它的构造很能说明问题:从 SAM-Audio-Bench 的 819 个真实 10 秒样本出发,用大模型分离出目标声,再用 ESC-50 的背景声以 -15 到 -5 分贝随机混入,形成带噪的混合音频。每个样本要同时看文本、静默视频和混合音频,再根据 7 种交互组合(文本、时段、掩码及其两两和三者组合)去 16 选 1。负样本不是随机挑的,而是 3 类各 5 个:只换背景、同类换目标、跨类换目标,专门考验细粒度区分。

这个设计把“能否用交互精确定位”变成了可度量的检索题。图 3 展示的正是这条流水线:分离、生成背景类别、动态混音、构造困难负样本。读者看这张图时,重点不是混音参数,而是“正样本是否被分离误差污染、负样本类别是否由大模型合成”这两个后续要讨论的边界。

双流加聚合:如何把全局上下文和细粒度线索装进一个向量?

OmniUE 整体是一个端到端的双流对比学习框架。图 2 把它和以往只用 omni-LLM 的灰色基线对比得很清楚:新增了两条分段器流和一个上下文聚合模块。数据流可以这样理解:所有模态先各自编码、投影到大语言模型空间,再叠加上交互分段器的特征和几枚可学习的令牌,一起送进大语言模型做前向,最后从多层抽取、加权聚合成最终嵌入。

第一流叫查询流,负责“看全”。视觉和音频用 omni-LLM 自带的编码器提取,文本分词后,三者经连接器得到 Hv、Ha、Ht。为了装下组合式的多模态语义,序列末尾追加 K=4 枚随机初始化的可学习令牌 Hlt。这是对传统“只取最后一层 EOS 隐藏状态”做法的替代——单枚令牌容量不够,单层也容易丢信息。

第二流叫交互提示流,负责“指准”。视觉分支用 SAM-3,音频分支用 SAM-Audio,它们把点、框、掩码、时段等交互信号编码成交互嵌入 Hvs 和 Has。无交互时,视觉置空、音频置零向量或 <null>,模型仍能靠默认输入保留实体级细节。2 流在解码前就抽取特征,已带交互感知,无需再解回像素或波形。

第三块是上下文聚合。把 H=[Has, Hvs, Hv, Ha, Ht, Hlt] 送入大语言模型后,每隔 l=4 层抽 1 次可学习令牌的隐藏状态,得到 Z,再用可学习的层-令牌权重做加权求和与均值池化,得到最终嵌入 E。训练时用 InfoNCE 损失拉近查询与正样本、推远负样本,并用 GradCache 把批量扩到 1024 以增加负样本多样性。

三个关键组件在张量层面到底做了什么?

先看交互编码如何避免序列爆炸。直接把高分辨率特征图展平会得到极长的序列,论文用卷积压缩加注意力对齐来解决。视觉特征图 Fvs 在掩码预测头前抽取,尺寸 288×288×256,经 Conv2D 降采样、2 头自注意力与多层感知机得到 Hvs;音频特征图 Fas 在解码器前抽取,经扩散变换器与 8 步常微分方程求解器采样后,再经 Conv1D、2 头自注意力与多层感知机得到 Has。公式上写作:

\[H_{vs}=\text{MLP}_{vs}(\text{SA}_{vs}(\text{Conv2D}(F_{vs})))\in\mathbb{R}^{|F^{\prime}_{vs}|\times d},H_{as}=\text{MLP}_{as}(\text{SA}_{as}(\text{Conv1D}(F_{as})))\in\mathbb{R}^{|F^{\prime}_{as}|\times d},\]

这里 Fvs、Fas 是分段器解码前的交互感知特征,Conv2D/Conv1D 把视觉的 82944 个令牌压到 256、音频最多 250 帧压到最多 128,SA 是 2 头自注意力连接器,MLP 对齐到大语言模型维度 d。输入是带交互的视频或音频提示,输出是定长的交互嵌入,职责是“把你指的区域/时段变成大模型能读的令牌”。

再看跨层聚合为何不用大 MLP。把 36 层的大语言模型每 4 层抽 1 次,可得 M 层、每层 K=4 枚令牌的张量 Z。论文不直接用 O(L·d²) 的 MLP 去融合高维隐藏状态,而是学一个很小的权重矩阵 W,经 Softmax 归一化后加权求和,再对 K 枚令牌均值池化:

\[E=\phi(\tilde{Z}),\tilde{Z}=\sum_{m=1}^{M}\tilde{W}_{m}\odot Z_{m}\in\mathbb{R}^{K\times d},\tilde{W}=\text{softmax}(W),\tilde{W}_{m}\in R^{K},\]

其中 Z∈R^{M×K×d},W∈R^{M×K} 是层-令牌重要性权重,φ 是均值池化。输入是多层多令牌的隐藏状态,输出是单一嵌入 E,职责是以极少参数自适应地兼顾浅层细节与深层语义。论文算过,对 3B 模型做 MLP 融合要 155M 参数,远超 LoRA 本身的 45M,而这个加权方案几乎不增加负担。

比喻一下:如果把大模型比作一栋 36 层的楼,传统做法只在顶楼门口问一个人,OmniUE 则是在每 4 层都派 4 个联络员记录信息,再按学到的权重汇总。这样既不会漏掉低楼层的细节,也不会让高楼层的语义被淹没。

原论文 Figure 1:Applicability of OmniUE, which takes omni-interactive prompts (pp) and queries (qq) to retrieve…

论文图 1。这张图来自原论文 Figure 1:,图示内容为“Applicability of OmniUE, which takes omni-interactive prompts (pp) and queries (qq) to retrieve any-modality targets (cc), including text, image, video, and…”。请结合“三个关键组件在张量层面到底做了什么?”的正文,按图例、坐标轴或模块连线核对;图中没有呈现的内容不作外推。

模型如何训练,花了多少算力?

训练目标是标准的 InfoNCE 对比损失,温度系数 τ 设为 0.02。查询嵌入 Eq、目标嵌入 Et 和一批负样本 Ej 一起参与,模型要把正样本的余弦相似度推高、负样本推低。为了在有限显存下看到更多负样本,作者用 GradCache 把有效批量扩到 1024。

优化上,大语言模型部分不全量微调,而是用低秩适配(Low-Rank Adaptation,LoRA),秩 32、alpha 64、dropout 0.1;两个分段器连接器从零开始训练。优化器是 AdamW,beta1 0.9、beta2 0.999,学习率 2e-5,预热 200 步,总步数 3300,精度 bf16,最大序列长度 20480,最大帧分辨率 156800,音频采样率 16 kHz。这些数字在附录 Table 5 中集中给出,复现时可直接对照。

数据与硬件同样关键。训练集约 3.5M 样本,来自 AudioSet、WavCaps、MSR-VTT、PE-Videos、VALOR、AudioCaps、Clotho、Panda70m、Shot2Story、VGGSound、Youtube8m 等,其中部分视频-音频对的文本标注由 Qwen3-Omni-30B-A3B-Instruct 合成,VGGSound 则沿用 AudioSetCaps。训练在 8 张 H100 80 GB 上完成,3B 约 177 小时,7B 约 195 小时。值得注意的是,训练时并未加入视觉与音频交互数据,交互能力是在推理时零样本展现的,这既证明了泛化,也意味着交互上限尚未被充分训练。

在哪些数据上测,用什么尺子量?

评估覆盖 4 类基准,分别对应不同的交互形态。MMEB-v2-video 有 18 个视频任务,按分类、问答、检索、时刻检索汇总;MAEB 有 30 个音频任务,按 8 个元任务汇总;SCaR 有 5 个视觉交互的图文检索任务,需要根据边界框找最贴合区域的描述;OmniCHOIR 则是新建的 7 种交互组合的音频检索,指标统一用 Recall@1,越高越好。图 1 帮助理解这种“任意查询模态到任意目标模态”的设定,图 4 则用于核查超参数选择是否稳健。

根据论文正文与图中报告值整理,数据集与实验协议可概括如下:

基准/数据集样本与任务构成查询与交互指标与划分基线与对照
MMEB-v2-video18 个视频任务,分 4 个元任务文本交互为主,静默视频+ 文本各元任务平均分与总体分VLM2Vec、UME-R1、LCO-Emb、e5-omni 等
MAEB30 个音频任务,分 8 个元任务文本交互,音频+ 文本各元任务平均分与总体分MS-CLAP、LAION CLAP、LCO-Emb、Qwen2-Audio
SCaR5 个视觉交互 TI2T 任务文本+ 边界框指区域Recall@1 类检索准确率VLM2Vec、MMRet、UniME、VIRTUE
OmniCHOIR479 个 10 秒样本,16 选 1,3 类困难负样本各 5 个文本/掩码/时段 7 种组合Recall@1ImageBind、LCO-Emb、WAVE、以及文本/裁剪启发式

训练与推理的细节也在协议之内:推理时文本交互用模板“Find the sound from the mixed audio and the video: {text}”等,掩码与时段可转为文本或直接裁剪作为对照,以区分“表征增益”与“启发式增益”。硬件与时延在附录中实测,文本模式约 1.3 秒、掩码模式约 9.4 秒、显存约 20.8 GB,边界框可降至 1.5 秒左右。

数字说明了什么,又没说明什么?

主结果的趋势很一致:只要需要细粒度定位,OmniUE 的增益就明显。根据论文正文报告值整理,关键对比可概括如下:

比较或条件指标明确报告值这项数字支持什么
MMEB-v2-video 总体平均分 ↑OmniUE-7B 51.8 vs UME-R1 47.5(+4.3),OmniUE-3B 48.4 vs LCO-Emb-3B 43.3(+5.1)文本交互下,全局+ 实体级互补有效
MAEB 总体平均分 ↑OmniUE-7B 53.4 vs LCO-Emb-7B 52.2,重排序 88.2、音频检索 93.3 显著领先音频任务上分段器仍提供增益
SCaR 总体检索准确率 ↑OmniUE-7B 55.2 vs VIRTUE-7B 27.8(+27.4),3B 51.3视觉交互能力零样本泛化成立
OmniCHOIR 全模态Recall@1 ↑OmniUE-7B 28.4 vs LCO-Emb-7B 23.8、WAVE 24.7;单模态文本 25.5、时段 26.3、掩码 26.7多模态组合优于单模态,掩码/时段各自已优于纯文本
任意模态互检Recall@1 ↑V2A 27.2 vs 25.0,VA2T 78.9 vs 74.5统一嵌入具备 any-to-any 泛化

反证同样重要。关闭视觉与音频分段器后,OmniUE-3B 在 MMEB-v2-video 从 48.4 回落到 45.0,在 SCaR 从 51.3 跌到 30.9,在 OmniCHOIR 从 26.4 跌到 16.3,说明交互流不是摆设,即使无显式交互也能补细节。把时段转为文字或直接裁剪音频的启发式基线显著更低,说明增益来自表征而非简单裁剪。

不能过度推断的地方也要点明:OmniCHOIR 只有 479 样本,负样本类别由大模型基于静默视频生成,可能存在合成偏差与视觉可推断性泄露;MAEB 上多标签分类等子项仍有波动;V2A/VA2T 等仅报告 Recall@1 且未给方差,证据强度弱于主基准。随机掩码会让掩码条件从 26.7 降至 16.8,随机时段让时段条件从 26.3 降至 19.6,说明模型对交互质量敏感,交互不准时收益会打折。

原论文 Figure 2:OmniUE overview. Compared to existing omni-LLM-based embedders (shown in gray; e.g., \\[58\\]), OmniUE…

论文图 2。这张图来自原论文 Figure 2:,图示内容为“OmniUE overview. Compared to existing omni-LLM-based embedders (shown in gray; e.g., [58]), OmniUE introduces three key components: 1) audio and visual…”。请结合“数字说明了什么,又没说明什么?”的正文,按图例、坐标轴或模块连线核对;图中没有呈现的内容不作外推。

原论文 Figure 3:The data collection pipeline for OmniCHOIR.

论文图 3。这张图来自原论文 Figure 3:,图示内容为“The data collection pipeline for OmniCHOIR.”。请结合“数字说明了什么,又没说明什么?”的正文,按图例、坐标轴或模块连线核对;图中没有呈现的内容不作外推。

原论文 Figure 4:Parameter study on 1) Aggregation from each ll layers; 2) # of learnable tokens (kk); 3) # of…

论文图 4。这张图来自原论文 Figure 4:,图示内容为“Parameter study on 1) Aggregation from each ll layers; 2) # of learnable tokens (kk); 3) # of attention heads in SA (hh); 4) LoRA ranks; 5) number of…”。请结合“数字说明了什么,又没说明什么?”的正文,按图例、坐标轴或模块连线核对;图中没有呈现的内容不作外推。

哪些局限是作者承认的,哪些是审稿视角的提醒?

作者在附录中坦诚了三点。第一,强依赖预训练模型,Qwen2.5-Omni 与 SAM-3/SAM-Audio 无法从零训练,嵌入性能与生成性能的尺度律相关,未来更强的基座可能直接带来提升。第二,掩码作为交互媒介在精度与效率间权衡,掩码模式端到端约 9.4 秒,远高于文本模式的 1.3 秒,作者提供了边界框替代,可降至 1.5 到 2.1 秒,但会损失约 1 个点。第三,OmniCHOIR 规模有限,未来计划扩展并探索更多交互组合与相似度度量等场景。

从审稿视角看,还有几处需要谨慎。OmniCHOIR 的正样本经 SAM-Audio-Large 分离后再混入背景,分离误差会污染正样本;背景与负样本类别由 Qwen3-Omni-30B 基于静默视频生成,既有合成偏差,也可能让背景声变得“可从画面猜到”,削弱检索难度。训练数据中大量合成字幕未做偏差分析,领域偏移未被量化。训练时未包含视觉与音频交互数据,虽然证明了零样本泛化,但也限制了交互能力的上限评估。

此外,论文未报告多次运行的方差与显著性检验,479 样本的结论需要更大规模与人工校验来加固。推理开销在实际检索中不容忽视,边界框虽快,但论文未充分评估不同任务下精度损失的相关性。这些都不是否定贡献,而是提醒读者在复用该框架时,要对数据合成链路与效率预算做额外检验。

如果要复现,需要哪些材料,缺什么?

可复现性上,论文给出了相当完整的训练配方:骨干为 Qwen2.5-Omni-3B/7B,分段器为 facebook/sam3 与 sam-audio-base,自注意力头数 2,视觉特征图 288×288×256 压到 256 令牌、音频最多 250 帧压到最多 128,Conv 核与步长均为 4,LoRA rank 32、alpha 64、dropout 0.1,温度 0.02,批量 1024,步数 3300,学习率 2e-5,最大序列 20480,优化器 AdamW,精度 bf16,8×H100 的训练时长也已披露。评估基准与指标、推理模板与时延显存都有实测表格。

缺失的部分同样明确:论文未提供代码仓库、模型权重与数据集下载链接,也未给出开源协议或后续开源承诺。OmniCHOIR 基于 SAM-Audio-Bench 构建,涉及 6 个公开视频来源与 ESC-50 背景声,但未发布整理后的 479 样本划分与生成脚本;训练用的约 3.5M 样本中合成字幕的生成细节仅描述为用 Qwen3-Omni-30B-A3B-Instruct 完成,未给提示词与过滤规则的完整可执行版本。

对想复现的研究生而言,最务实的路径是先用公开的 Qwen2.5-Omni、SAM-3、SAM-Audio 复刻双流与跨层聚合的最小可运行版本,在 MMEB-v2-video 与 SCaR 的小子集上验证“关闭分段器是否显著下降、随机交互是否显著变差”这两个关键反证,再逐步补齐 OmniCHOIR 的构造链路。

如何把这篇工作放进你的研究地图?

回到最初的问题:当用户想指一块区域、圈一段声音时,嵌入器能否把这种意图编码进向量?OmniUE 的回答是肯定的——用分段器把交互变成令牌,用可学习令牌与跨层加权把全局与细粒度线索融进一个向量,并在 4 个系列基准上给出了一致的增益。图 2 的架构、图 3 的基准构造与图 4 的参数研究共同指向一个信息:多模态交互不是在文本指令上打补丁,而是需要一等公民的编码路径。

对刚入行的同学,这篇工作提供了两个可复用的思路。一是“解码前特征即交互特征”:不必把分割结果解回像素或波形,直接在掩码头或解码器前抽取特征,再用轻量卷积与注意力对齐到大模型空间,既保留交互感知,又控制序列长度。二是“用权重代替大 MLP 做跨层融合”:当层数与维度很大时,学一个小权重矩阵做 Softmax 加权,往往比堆参数更稳、更省。

同时,也要把它的边界记在地图上:依赖现成大模型意味着你的复现与改进会受基座演进影响;掩码精度与推理时延的权衡决定了它更适合离线或交互式检索,而非极低延迟的在线召回;小规模合成基准的结论需要更大规模、人工校验与方差报告来加固。把这些优点与代价一起带走,这篇工作就能成为你做条件化检索、上下文工程或智能体记忆时,一个清晰的起点而非终点。

📎 论文与评分元数据

标签:#音频检索 #多模态模型 #音视频理解 #对比学习 #基准测试

7.5/10 | 创新 1.6/2 | 技术严谨 1.2/1.5 | 实验充分 1.2/1.5 | 清晰度 0.8/1 | 影响力 1.2/1.5 | 开源 0/1.5 | 可复现 0.5/0.5 | 工程/实践 1/1.5

7.5/10 | 前25% | 文档类型:方法研究 | 评分置信度:中 | #音频检索 | #多模态模型 | #音视频理解 #对比学习 | arxiv

⚖️ 评分依据与证据(展开查看)

逐维得分、全文证据与扣分边界
  • 创新性 (1.6/2):首次将交互从文本扩展至视觉点框掩码与音频时序片段,提出双流结构以 SAM-3 与 SAM-Audio 抽取解码前特征并经卷积压缩至 256 与 128 令牌,配合 K 为 4 的可学习令牌与间隔 l 为 4 的跨层加权聚合实现 omni-interactive 统一嵌入,系统级新能力明确

  • 技术严谨性 (1.2/1.5):双流与上下文聚合设计以层-令牌权重 Softmax 融合避免 O(L·d²) 的 MLP 开销,序列构造 H=[Has,Hvs,Hv,Ha,Ht,Hlt] 与 InfoNCE 优化逻辑自洽,已明确承认强依赖 Qwen2.5-Omni 与分段器及掩码效率权衡,无推导错误或不合理假设

  • 实验充分性 (1.2/1.5):在 MMEB-v2-video 总体 51.8 超 47.5 约 4.3 点、SCaR 总体 55.2 超 27.8 约 27.4 点、MAEB 总体 53.4 超 52.2 及 OmniCHOIR 全模态 28.4 超 23.8 上均有代表性基线对比,并做关闭视觉与音频流、多令牌与层聚合等直接消融,但 OmniCHOIR 仅 479 样本且负样本由大模型合成、未报告方差与显著性检验

  • 清晰度 (0.8/1):架构图与三模块数据流描述清晰,明确定义 Fvs 288×288×256 与 Fas 最大 250 帧的抽取位置及压缩方式,表格按元任务汇总并标注提升幅度,附录 Table 5 集中呈现配置,整体可读性良好

  • 影响力 (1.2/1.5):针对音频检索中文本指令无法精确定位重叠声源的痛点,在 MAEB 重排序 88.2 与音频检索 93.3 及 OmniCHOIR 多模态交互 28.4 上验证增益,并扩展至 V2A 27.2 与 VA2T 78.9 等 any-to-any 场景,为语音音频领域的条件化检索与智能体记忆提供可复用路径

  • 开源 (0.0/1.5):论文未发布核心代码、模型权重或数据资源,也未给出明确的后续开源承诺。

  • 可复现性 (0.5/0.5):附录 Table 5 与正文已披露 Qwen2.5-Omni 骨干、facebook/sam3 与 sam-audio-base、2 头自注意力连接器、LoRA rank 32 alpha 64 dropout 0.1、温度 0.02、批量 1024、步数 3300、学习率 2e-5、最大序列 20480 及 8×H100 80GB 与 177 小时等训练与评测细节,披露充分

  • 工程/实践价值 (1.0/1.5):提供真实测量:文本模式约 1.3s、掩码模式约 9.4s、显存约 20.8GB,边界框替代可降至 1.5s 至 2.1s 但损失约 1 点,并通过 Conv2D 与 Conv1D 将 82944 视觉令牌压至 256、音频最多 250 帧压至 128,避免超长序列,工程权衡有数据支撑


← 返回 2026-08-29 语音/音乐/音频论文速递