BloomBloom
发起研究

OmniCapBench：给音视频字幕打分，得拆成可逐个核对的小单元

一、读起来像样的字幕，为什么测不出它到底错没错？

2025 年 6 月，一批研究者把 23 个视频语言模型拉到一起，让它们自由描述视频里发生了什么，然后给每段字幕算两个成本：编造成本和遗漏成本。结果有点扎眼。绝大多数模型的点落在对角线上方，意思是它们漏掉的内容比编造的内容更多；而当时公认最好的 Gemini 2.0-Flash，编造成本仍然有 41%。也就是说，哪怕是那个时间点最好的模型，让它自由讲一段视频，写出来的内容里仍有四成左右与画面不符。ARGUS

问题不只是"模型还不够强"。一段字幕读起来通顺、语法流畅、和参考字幕很像，这三个条件可以同时成立，而它同时说错了主体、搞错了动作、也没注意到画面里其实响起了警笛。BLEU、CIDEr、METEOR 这类指标量的正是"和参考文本像不像"，而不是"说的对不对"。而事实错误的规模并不小：早在 2023 年，模型生成的视频字幕里就有 57.0% 的句子含事实错误，同一批研究却发现，各类 n-gram 指标与人类事实性判断的相关性弱得惊人，最强的 METEOR 在句子级也只有约 0.20。FactVC 一个量"像不像"，一个问"对不对"，两把尺子量的根本不是同一件事。通顺和正确之间，隔着一整个评测体系看不见的缺口。

ARGUS 的幻觉成本与遗漏成本散点图

图注：横轴是编造成本（ARGUS-H），纵轴是遗漏成本（ARGUS-O），每个点是一个视频语言模型，点的大小表示平均字幕长度。大多数点落在对角线之上，说明漏掉比编造更普遍；图中标注 Gemini 2.0-Flash 表现最佳。ARGUS

41% 这个编造成本不是今天才冒出来的意外，而是一条任务线跑了五六年都没测出来的东西。原因并不复杂：任务定义要求模型同时听懂声音、看懂画面，评测却只问写出来的这段话和参考像不像。音视频字幕这条任务线本身并不年轻。AVSD 在 CVPR 2019 就用 11,816 段对话、118,160 个问答把"声音必须真参与"写进了任务定义；VALOR 在 2024 年把它推成一张 3×3 的任务矩阵，检索、字幕、问答各自再按音频、视觉、音视频三种模态组合，配上 VALOR-32K 基准与百万级人工标注数据集。VALOR 任务定义越铺越细，尺子却一直没换。后面我们还会回到这把尺子，说清它和 OmniCapBench 各自在量什么。

所以 OmniCapBench 面对的，不是一道凭空冒出来的题，而是一条已经跑了五六年、却始终拿一把粗尺子打分的任务线。整整五六年里，"看起来像"被默认成了"理解对了"的同义词。于是真正该追问的问题浮出来了：出错的地方可能不在模型，而在评测本身。要修的不是更强的模型，而是一把能量到细处的尺子。

二、换更强的裁判也没用，三种老评测范式卡在同一个缺口

要看清老评测卡在哪，得先知道它由两半拼成：一半是评测单元，也就是"拿什么和参考比"；另一半是评分算子，也就是"用什么规则给它打分"。主流做法把这两半捆成一个死结：评测单元是一整段自由文本，评分算子是让一个全局 LLM 裁判通读全段，给一个分数。

论文把这条路线的变体摊成三种，每种都有自己缺的那一半。

第一种是整段打。把模型写的一整段字幕原封不动交给一个全局 LLM 裁判，输出一个标量分数。它覆盖面广，什么都能说上两句，但分数是不透明的：你只知道"这段 7 分"，不知道失分发生在哪一句、哪一层。第二种是问答探针。不问整段，改问一组精心设计的问题，比如"画面里有几个人"。它能定位到具体问点，但问题数稀疏，漏掉的角落就永远看不到，而且换一个裁判模型，同一批输出的分数会明显抖动。第三种是先解析再打分。先把字幕解析成事件列表之类的结构，再交给 LLM 评分。看起来兼顾了两头，实际上解析是事后做的、很脆：跨镜头"还是不是同一个人/同一件东西"，以及"这声音是不是来自画面上这个物体"，依旧是 LLM 一次性隐式判断出来的，没有任何独立可核对的凭证。OmniCapBench

先解析再打分的代表是 LongVALE。它把视觉边界、音频边界、台词分别解析出来，再让 Gemini-1.5-Pro 做一次关系推理，把三路信息整合成带起止时间的事件列表。这一步走得比整段打细很多，但它的整合是一次性的语义推理，跨镜头身份与音视关联并没有被拆成可以单项验证的字段。LongVALE

同期的另一条路走得更远一点，但方向不同。VC-Inspector 在同一时期走的是 reference-free 路线：不依赖参考字幕，而是用合成数据微调一个多模态模型，直接输出 1 到 5 的整段质量分加一段解释。VC-Inspector 两条路都在回答"怎么给视频字幕打分"，但一条守住整段视角，另一条把字幕拆成原子单元。

三种评测范式并排对比图

图注：并排展示三种评测范式。(A) 整段打把自由字幕交给全局 LLM 裁判，得到一个不透明标量，有覆盖但没有定位；(B) 问答探针能发现局部错误，但覆盖稀疏、且随裁判不同而不稳定；(C) 论文提出的深结构化评测，先把字幕表示为可验证的原子单元，再用确定性规则校验，只把已对齐的单元交给有界局部 LLM 做语义核对。OmniCapBench

三种路线看着各有各的毛病，其实是同一个死结的不同面：覆盖和定位只能二选一，结构判断和裁判判断绑在一起。一整段文本要全覆盖，就没法定位；要定位到具体单元，覆盖就变稀疏；而只要评分的最后一步交给一个全局 LLM，分数就会随裁判换人而漂。这不是"哪家没做好"的工程问题，是捆绑方式本身制造的矛盾。想解开，必须换掉矛盾的两端，而不是换个更聪明的裁判。

三、要定位错误，被评测的对象就不该是一段话

论文给出的第一个答案听起来朴素：先换掉被评测的对象。如果评测单元是一整段自由文本，那么"哪里错了"这个问题在单元内部根本无法回答；只有当字幕本身被组织成可以逐个核对的小块，定位才有落脚点。

想象要核对一本流水账日记有没有写错。如果整本日记是一整段话，你想改一个配角的名字，几乎要重写全篇；你想确认第三段写的那个人是不是第一段那个人，只能通读全文、靠记忆去比对。可要是把它改写成三张表：一张人物表记录"谁是谁、长什么样"，一张分镜表记录"第几秒到第几秒在干什么"，一张音轨记录写"第几秒响起了什么声音"。改动只落在对应那一行，核对身份只看两处引用的编号是不是同一个。拆开的好处不在于表格更整齐，而在于每一个错误都有了一个可以独立指认的位置。

这条路其实不算全新。早在 2020 年 ECCV，SODA 就用动态规划做时序最优匹配，配上双向精确率与召回率，把"评测对象是一个有序事件序列"这件事讲清楚了。只是那条线一直停在视觉单模态，没有把音频和跨镜头身份拉进来。SODA

论文的三轨原子单元正是这个思路的下一站。上游的 MTSS 工作先把视频表示成四条互补的流：Reference 流负责"谁和哪里"，Shot 流负责视觉叙事的时间切分，Event 流负责与画面耦合的音频事件与对话，Global 流负责整体氛围与背景音。它靠两个原则把这些流重新接回同一条时间轴：一条是 Stream Factorization，先把纠缠的整体拆开；另一条是 Relational Grounding，再用身份链和时间锚把拆开的流重新绑到一起。拆开解决"改一处要重写全篇"的规模问题，重连解决"拆散之后人和物对不上号"的一致性问题。MTSS

MTSS 的整段字幕与四流分解对照图

图注：左侧是纠缠在一起的整段字幕，右侧是拆开的多流脚本，包括 Event、Shot、Reference、Global 四条流；中间靠身份链与共享时间锚把各流重新接回同一条时间轴。颜色块是流类型标识，不是评测指标。MTSS

OmniCapBench 在这套表示之上把评测对象定义成三条轨。Reference 是持久身份，人物、物体、场景各有一个唯一 ref_id，外加一段外观锚点，记录它区别于同类的可视特征。Event 是带连续时间区间的音频事件，比如"狗叫，10.5 秒到 12.0 秒"，其中对话还带逐字转录的台词。Shot 是连续的视觉镜头段落，带自己的时间区间，并显式记录这个镜头里有哪些活跃事件、引用了哪些身份，再进一步拆成更细的 subshot，也就是镜头内部一个个原子级的视觉状态。它相对上游做了两处关键改造：用连续时间区间取代离散的单个时间点，把视觉镜头进一步拆到 subshot。OmniCapBench

这里有一件事要说清楚，免得混淆：MTSS 是表示范式，回答的是"视频该怎么被写成结构化脚本"；OmniCapBench 接管它、回答的是"模型写出的脚本该怎么被逐单元打分"。MTSS 本身不是独立评测基准，R/E/H 三轨的定义权在 OmniCapBench 这边。也正因为它站在一个已经被验证过的表示基础上，它不需要再论证"拆成原子单元是否合理"，可以直接把力气花在打分机制上。

这一章带走的判断很简单：让评测可信的第一步，不是找个更聪明的裁判，而是换掉"被评测的到底是什么"。把一段话换成带身份和时间锚、可以逐个核对的小单元。

四、拆成单元只是开始：怎么保证单元可信、又怎么打分不被裁判带偏？

拆出单元容易，但要保证这些单元本身可信，还要保证打分不随裁判漂移，是两件更难的事。论文分别用一条构造管线和一套解耦评分来回答。

先看单元是怎么造出来的。786 段视频经过三个阶段。Stage I 只做筛选，按是否存在有效音频、按视频时长分桶、按每个桶对应的结构密度阈值来挑出"音画复杂度够高"的原始视频。Stage II 按 Reference、Event、Shot 的依赖顺序生成单元，走一个"生成、评估校验、局部精修、选择"的迭代循环。这条循环里有一条硬规则：结构，也就是编号、时间戳、跨流链接，必须先通过程序化校验器，之后才允许对描述性字段做文本润色；一旦某次润色碰坏了链接，这次润色就被丢弃。换句话说，结构先于语义，润色只能在不动物理骨架的前提下进行。Stage III 再由人工审计定稿，处理遮挡人物、重叠音频、模糊镜头边界这类疑难。OmniCapBench

OmniCapBench 三阶段数据构造流程图

图注：三阶段构造流程。Stage I 从原始视频中筛选候选；Stage II 围绕 R、E、H 三个盒子走"生成、评估校验、局部精修、选择"循环，结构完整性先于语义润色被强制保证；Stage III 用可追溯的人工审计定稿。OmniCapBench

最终得到的是 786 段视频、5,818 个实体、6,537 个事件、11,419 个镜头、39,160 个 subshot 的参考系统。

再看打分。评分的第一道关是一个 schema 闸门，模型输出必须先能解析成 references、events、shots 三个数组，凡格式崩坏、混入 markdown 之类的不合规输出，下游所有指标直接归零。过了闸门，还有六条结构一致性谓词把关，专门拒绝悬空的身份引用、超出父镜头时间范围的 subshot、跨镜头前后不一致的身份编号，以及事件与镜头之间互相矛盾的时间链接。能确定性匹配的绝不交给模型判断：对话按归一化词错率匹配，阈值 0.50；非对话事件和镜头按时间交并比 tIoU 匹配，阈值分别是 0.20 和 0.30。只有 Reference 和 subshot 这类开放词汇字段，才交给一个有界的 LLM 做一对一比对，而且严格限定只比较局部的外观锚点字段，明确排除语义摘要、时间戳、事件镜头链接和更宽的上下文。OmniCapBench

对开放词汇字段，论文还用了双向指标。同一个动作，模型可能拆成三个 subshot，人可能拆成一个，两边都没有事实错误，只是粒度不同。于是评测同时跑两个方向：召回方向从参考到预测，罚漏报；精确方向从预测到参考，罚幻觉；两者取调和均值得到 F1。还有一条开放世界打分策略，遇到"有效但超出参考范围"的事实时不扣精确度，只记录下来留作诊断。这样既不会把正确但没被标注的事实误判成幻觉，又不放过真正的编造。

为什么"结构先校验、模型只做局部"能压住裁判方差？外部有一组实证证据可以解释。有一项针对 LLM 评委的系统研究发现，评分标准比参考答案更关键，缺少评分标准时相关性会明显下滑；多次采样取均值优于贪心解码；而在评分标准清晰时，额外的思维链带来的增益很小。LLM-as-Judge 把 LLM 限死在局部、先校验结构，恰好把这些方差来源提前移除了。

这里还有一个刺眼的对照。如果允许模型先自由写散文，再用解析器事后转成结构化输出，格式合规率能接近满分，可跨镜头身份一致性会从 34.43 直接塌到 5.20。结构化不是一种格式，不能事后补。这一个数字，就解释了为什么论文宁愿在生成端就要求结构化。

这一章带走的判断是：可信的评分等于结构先交给确定性规则把关，LLM 只在不影响结构的局部做语义核对。不是"用更强的裁判"，而是"让裁判少管闲事"。

五、分数变成诊断：前沿模型到底弱在哪一层？

有了可定位的单元，评测就不再只是给一个分数，而是能回答"弱在哪一层"。论文把评分拆成一族指标，每一族对应一种系统能力。其中两个最值得说的，恰好也是前沿模型最弱的两个。

一个是跨镜头身份一致性（CCC），它测的是"同一件东西换了镜头之后，还能不能一直被认成同一个"。另一个是音视频关联分（EVSA F1），它测的是"这个声音事件，有没有接到正确的视觉镜头上"。

身份链与音视频关联示意图

图注：左图 (a) 显示在全局文本指标下不同模型的分数挤在一起，而在结构化约束下才被拉开，并与人工审计的排序一致；右图 (b) 是归一化后的失败构成，把每个模型的失分按错误类别铺开，对比前沿模型与开源模型的短板分布。OmniCapBench

这两条关系用两张简图就能看清，它们测的是两件不同的事。第一张看身份一致性：镜头之间那条身份链有没有断。第二张看音视频关联：声音事件、镜头、身份这三者之间有没有接对。两张图各自用各自的身份编号，不要混在一起看。

上面这张只讲人物跨镜头的身份链：镜头 1 和镜头 2 指的都是同一个人 REF-1，到镜头 3 却被写成了另一个编号 REF-5，链子就在那里断掉。

下面这张是另一个例子，讲狗叫这个声音事件有没有接到正确的镜头和身份上，编号同样只在本图内有效。

数字说明问题。CCC 这一列，最强的 Gemini 2.5-Pro 也只有 37.81%，Gemini 3.1-Pro 是 34.43%，开源模型普遍低于 12%，其中 MiniCPM-o-2.6 只有 4.29%。而同一批模型在最基础的 Reference 主体识别上还在 80 分档。差距摆在这里："认出过一件东西"和"跨镜头一直认成同一个"是完全不同的两种能力。EVSA 这一列同样惨淡，Gemini 3.1-Pro 以 51.46% 居首，Gemini 2.5-Pro 为 43.74%，开源模型普遍低于 20%。更细的层面还藏着一个信号：Gemini 3.1-Pro 的镜头精确度能到 88.77%，但 subshot 精确度掉到 60.29%，也就是说它能找到动作大概发生的时间，却会凭空编出镜头内部更细的时间切分。OmniCapBench

把每个模型按指标失分归一化后，失败构成会显出两种完全不同的画像。Gemini 3.1-Pro 这类前沿模型，失分集中在动作幻觉 28.5%、音视频错位 23.7%、音频幻觉 17.9%，而格式与闸门错误只有 1.3%。它基础感知够好，卡在细粒度的跨模态绑定上。开源模型则是"系统性退化"，错误平均地铺在基础感知和复杂绑定两侧，没有明显的主战场。这个对比本身就很有信息量：在 OmniCapBench 所测的这些能力里，这批前沿模型最突出的短板，已经不是"看得见看不见"，而是"看得见却不能一直认得、接得对"。OmniCapBench

需要提醒一句：这套原子单元指标与句子级的评测不能直接比。ARGUS 那一类工作评价的是"哪句话有幻觉"，量纲是句级成本；这里的 CCC、EVSA 是原子单元级的结构化得分，两者数字不可互比。它们各自回答不同尺度的问题。

这一章带走的判断是：这套评测不只是给分，它把"弱在哪一层"变成了可读的诊断。在 OmniCapBench 所测能力中，这批前沿模型最突出的短板是身份漂移和跨模态错位，而不是"分数还不够高"。

六、结构优先的评测更可信，但它牺牲了什么？

可信不是靠嘴上说的。论文做了两组对照实验来证明结构优先确实更稳、更贴近人。

第一组是裁判敏感度。同一批模型输出，换弱、中、强三个不同的 LLM 裁判来打整段式评测的分数，结果从 71.24 一路摆到 93.92。换裁判就换名次，这种评测的可信度可想而知。而 OmniCapBench 自己的分数在同样的三个裁判下是 56.82、58.24、57.60，几乎纹丝不动。差别来自哪里？来自它把绝大部分判断交给了确定性规则，LLM 只在被严格限定的局部做核对，裁判的身份被吸收成了一个近乎恒定的量。OmniCapBench

第二组是人工审计。研究者挑出若干在文本指标下"难分高下"的模型对，文本指标给它们的对比是 53.0 对 47.0，看起来势均力敌。换到结构化评分，差距拉到 70.6 对 29.4；再看人类判断，是 74.2 对 25.8。结构化评分和人类，落在了同一个排序上，而文本指标把真实差距抹平了。OmniCapBench

代价也很实在，论文自己说得清楚。

边界具体含义
只对标注参考集给分评分针对一套人工标注的参考系统 S*(V)，对"有效但没被标注"的事实不给分，这是它与许多生成式基准共有的局限
时长上限视频限定在 5 分钟以内，长视频的跨镜头身份追踪不在范围
上游偏置风险Stage II 用前沿模型起草参考集，其中一些模型家族后来也参与了评测，存在评测模型偏置风险，确定性校验器与资深人工裁决只能部分缓解
schema 取舍严格的 JSON schema 对过度优化自由散文的模型不利，论文称这是为了推动领域走向可控结构化生成的刻意选择

把可迁移性和潜在误用分开看。可迁移的是"结构优先"这条思路：先让确定性规则校验结构，再让模型在局部做语义核对。这条思路原则上能搬到别的字幕任务甚至别的模态上去。但不应把 OmniCapBench 当成一个通用视频总分来用。它是一把精准的手术刀，用来查清一个模型在身份、时间、跨模态关联上具体弱在哪，而不是一把能给任意视频一言定高低的万能尺。

回到最初那个问题：给音视频字幕打分，分数为什么不可信、怎样才能可信。这篇论文的答案收敛成一句话：评测的可信度来自结构，而不是来自一个更强的裁判。

想深入可以读原文：OmniCapBench: A Deep-Structured Evaluation Framework for Fine-Grained Audio-Visual Captioning — arXiv:2610.12458

参考文献

OmniCapBench：给音视频字幕打分，得拆成可逐个核对的小单元