企业官网建设流程全解析

1. 双视角视频理解：为什么EgoExoBench能戳中MLLM的盲区

做多模态大模型（MLLM）评测这几年，我越来越明显地感觉到一个尴尬：模型在第三人称视频问答上分数漂亮，换成头戴相机录的第一人称画面就原形毕露。NIPS 2025的EgoExoBench，就是为这个具体问题设计的——它把第一人称（Ego）和第三人称（Exo）视频成对放在一起，用来评测MLLM能不能同时理解“我眼里看到的世界”和“别人眼中我的行为”。一句话概括：这是一个专门考验双视角视频理解能力的基准。

这个基准解决的实际问题很明确：现在大量视频理解模型都是在第三人称视频（监控、影视、网络视频）上训练的，但智能眼镜、机器人遥操作、自动驾驶等场景的核心输入恰恰是第一人称视角。Ego视角看不到自己的全身，镜头随头部运动剧烈晃动，手部交互占据画面主体，这些特点让习惯第三人称统计规律的模型极其不适应。EgoExoBench要做的，就是把这个能力缺口变成一个可量化、可复现的评测体系。

如果你在跑MLLM的评测、做AR/智能眼镜的感知算法、研究具身智能，或者刚入学想找视频理解方向但不知道从哪下手，这个基准都值得认真跑一遍。它不要求你重新训练模型，而是用一套标准的问答任务直接测出模型的双视角理解水平。读完这篇文章，你会知道它设计上盯住了哪些模型缺陷、实测流程怎么走、以及哪些位置全是坑。

1.1 第一人称和第三人称的真正差异

很多人以为第一人称视频“就是换个摄像头角度”，实际差别完全不止成像视角。第一人称画面里，人物主体基本不在画面中，模型只能靠手部动作、局部物体交互和周围环境变化来推断“我”在做什么，而第三人称画面天然包含了“一个人的完整动作轨迹”。这两类信息是互补的：Ego视角包含执行者的意图与注意力，Exo视角提供客观全局和人物姿态。如果模型不能把Ego画面中的“手伸向杯子”和Exo画面中的“人弯腰拿杯”联系起来，那就说明它没有真正理解行为，只是在做模式匹配。

另一个常被忽略的点是时间动态。第一人称视频有大量快速扫视、头部转动带来的运动模糊，而第三人称视频中人物运动相对平滑。也就是说，同一段行为在两条视频流里的视觉分布差异极大。如果一个模型只利用单路视频进行推理，在EgoExoBench这种成对输入设置下会出现明显的视角偏见——它会把其中一路当成主要线索，另一路直接忽略。这种偏见在传统单视角评测里根本暴露不出来。

1.2 为什么MLLM时代需要新基准

传统视频理解基准走的是“每个任务训一个专用模型”的路线，行为分类用分类头，时间定位用回归头，评价指标也互不相通。但MLLM的范式是“一个模型统一处理所有视觉问答任务”，输出是自然语言，评测方式自然要变成zero-shot开放生成。EgoExoBench正是按这个范式设计的：不提供训练集微调，直接用问答测模型的泛化能力。

这个设计背后有一个很现实的部署考虑。智能眼镜和机器人系统的视频理解模块，在用户实际使用之前根本无法拿到第一人称训练数据，模型必须能zero-shot理解陌生的Ego视频。如果某个MLLM在EgoExoBench上分数很高，至少说明它的视觉编码器没有过度依赖第三人称偏见，这对实际落地很有参考价值。

2. 基准核心设计拆解：双视角任务体系与数据逻辑

EgoExoBench不是像传统基准那样只做“动作分类”或“视频问答”单一任务，而是把双视角理解拆成一组互补的任务，每个任务对应一种不同的推理能力。我在实际阅读这个基准的设计方案时，最直观的感受是：任务之间的区分度做得非常清楚，真正能让模型“偏科”。

2.1 五大核心评测任务

下面这张表是我整理的EgoExoBench任务构成，包含每个任务在考什么、难在哪。具体任务名称以基准文档为准，这里按我的理解做了归纳。

第一项Next-Event Prediction是整个基准里最直观也最难的任务。模型必须同时看到Ego视角下“手正在拿起锅铲”和Exo视角下“人正站在灶台前”，才能推断下一步是“翻炒”。如果只看Ego画面，缺少全局场景，模型很容易把动作猜成“拿筷子”之类；只看Exo画面，又可能忽略手的细节。这种交叉验证式的推理，恰好是当前多数MLLM最不擅长的地方。

2.2 数据构建的双路线逻辑

EgoExoBench的数据构建遵循一个很清晰的逻辑：同一个事件必须同时录制第一人称和第三人称。采集时，被试者佩戴头戴相机执行真实任务，另一台相机从外部同步拍摄，或者利用多机位阵列完成时间对齐。这里最关键的不是设备成本，而是同步精度——两路视频一旦出现几十毫秒的时间偏移，跨视角推理任务基本无法完成，模型学到的任何规律都会被时间错位污染。

数据采完还要做很重的标注。每个视频片段需要有人物动作起止时间、行为类别、手-物交互状态、以及跨视角对应关系。这个标注成本相当高，所以基准一般会采用“自动预标注+人工校验”的流水线。设计上的考量是，任务必须难到足以区分模型能力，但又不能因为标注质量问题导致误判。例如Consistency Judgment任务里，“同一件事”的定义就必须非常严格，否则标注人员的判定标准差异会直接影响评测噪声。

2.3 开放生成怎么评分

MLLM的输出是自然语言，没法直接和标签做字符串匹配。EgoExoBench这类基准目前普遍采用“参考答案+大模型裁判+人工抽检”的三层评分机制。先用规则筛选掉明显不相关的答案，再让一个更强的大模型按评分标准给出1到5分，最后从全部结果里抽一部分做人工复核，用来修正大模型裁判的系统性偏差。

这个方法也有自己的坑。大模型裁判对“看似合理但实际错误”的长答案往往过于宽容，容易给高分；而对格式不对但语义正确的短答案过于严格。所以实际操作时不能只看一个总分，最好把每种任务的得分拆开做subgroup分析，才能看出模型的真实短板。

3. 实操记录：用EgoExoBench跑通一个MLLM的完整流程

下面这部分要讲的实操流程，是我自己按常规做法总结出来的。EgoExoBench的评测流程其实并不复杂，复杂的是那些“看起来能跑但跑出来不可信”的细节。我会把每个环节的实际操作方式、参数选择原因都写出来。

3.1 整体流程与运行环境

评测一个MLLM在EgoExoBench上的表现，核心链路是：视频抽帧 -> 构建双视角输入 -> 批量推理 -> 评分。这个链路里，视频抽帧是最容易被低估的环节。很多MLLM的输入是图像序列，不是原始视频，所以先得用ffmpeg按统一时间轴抽帧。

下面是我在评测时常用的抽帧命令，关键是“统一时间轴”这几个字：

ffmpeg -ss <start_time> -i ego.mp4 -t <duration> -vf "fps=2" -q:v 2 ego_frame_%04d.jpg ffmpeg -ss <start_time> -i exo.mp4 -t <duration> -vf "fps=2" -q:v 2 exo_frame_%04d.jpg

注意两路视频要使用完全相同的start_time和duration，不能各自随便从头抽。否则送入模型的两路帧根本不对应，评测结果自然失真。

模型推理可以用常见的开源MLLM框架，加载视觉编码器与大语言模型部分，直接把抽好的帧序列拼接进对话。显存方面，双路视频输入的开销比单路明显增大。以我常用的14B级别模型为例，双路各抽16帧，batch size设为1，大约需要40GB以上显存；如果显吃紧，可以把帧数降到8帧，但这会影响长视频任务的表现。评测文件里一般会给出推荐的帧数配置，基准官方默认值通常是可复现性最优的选择。

3.2 Prompt设计的实际经验

EgoExoBench的问答大多同时涉及Ego和Exo两路视频信息，Prompt怎么写直接决定模型能不能把自己的视觉能力发挥出来。我试过几种写法，最稳的是下面这个结构：

<image_ego> <image_exo> 第一段视频是第一人称视角，由佩戴在头部的摄像机拍摄； 第二段视频是第三人称视角，由旁观者拍摄。 两段视频展示的是同一个时间段内的事件。 请先分别用一句话描述第一人称视角和第三人称视角中正在发生什么，然后回答： <用户问题>

加上“先描述再回答”这步非常关键。不加这步时，模型经常直接跳到结论，导致它完全忽略某一路视频。先强制它描述两路画面，相当于逼它完成双视角信息的编码过程，后续回答准确率会明显提升。

还有一个细节：在Prompt里要把视角关系说清楚，比如“两段视频展示同一个时间段”。我见过不少模型在没有这句提示时，把Ego视频和Exo视频当成互不相关的两个独立片段处理，输出的推理逻辑完全断裂。这其实是模型对“多路视频同时输入”这一模式的先验不足，提示词能补偿一部分，但不能完全解决。

3.3 批量推理与结果收集

推理阶段建议按任务分组批量跑，而不是混合所有任务一次性跑完。因为EgoExoBench的不同任务对输出长度要求不同，比如Temporal Localization期望模型输出起止时间点，而Consistency Judgment只需要输出“是/否”。如果混在一起，用一个统一的解码配置，就会有一半任务输出格式跑偏。

输出格式偏差在实际评测里比模型答错更让人头疼。模型经常输出“事件发生在视频的1分23秒到2分05秒之间”这种自然语言，评分脚本如果预期的是“start 83 end 125”这类格式，就会把正确答案误判为零分。解决办法是构造一个轻量的格式后处理函数，从自然语言里正则提取时间数字，再转成标准字段。这一步并不复杂，但能显著减少评分系统误差。

批量推理完成后，把所有任务的模型输出保存成统一的JSONL文件，格式大致是：

{"task": "next_event", "sample_id": "001", "model_output": "...", "reference": "..."}

这个文件既是评分的输入，也是后续断点调试的凭证，不要直接用脚本现场生成现场打分，那样出错以后很难回溯。

4. 常见问题与避坑实录

跑过一轮完整评测之后，你会遇到大量难以归因的异常结果。很多问题不是模型能力不足，而是评测流程本身有bug。下面这些是我按问题出现频率整理的坑和对应处理办法。

4.1 双路视频时间偏移造成的隐性丢分

最隐蔽的问题是帧对齐。如果你在抽帧时用了不同的start_time，或者两路视频的原始时间戳标准不一致，模型看到的Ego画面和Exo画面就存在几百毫秒甚至几秒的错位。在视频理解任务里，几百毫秒的偏差足够让“手碰到杯子”这个瞬间在两条视频里对不上。

排查方式很简单：抽完帧后抽几对帧拼成一张网格图肉眼检查。如果Ego画面里手已经接触物体了，Exo画面里人还离物体老远，那帧对齐一定有问题。更稳妥的做法是用硬同步的时间戳元数据来抽帧，而不是依赖文件名顺序。

4.2 Ego运动模糊引发的手部交互误判

第一人称视频在快速转头时会产生整帧运动模糊，尤其是手部区域。我实测下来，很多模型在模糊帧上把手上的杯子识别成遥控器，把拿刀识别成拿笔。这种情况不是模型“不懂推理”，而是视觉编码器在低质量帧上提取不到有效特征。

我试过有效的方法是：把连续多帧作为一组输入，让模型在时间维度上做相互校正，再让评分脚本对多帧的推理结果做投票。效果比较明显，模糊帧导致的误判会大幅下降。另外，个别模型在训练阶段对运动模糊做了数据增强，这类模型在此项上明显占优。如果做模型对比，需要留意这个因素。

4.3 输出答案过长与评分误判

MLLM默认生成风格比较啰嗦，同一个正确答案经常被包在各种解释里，评分规则如果要求“完全匹配关键词”，就会大量误杀。我统计到的数据里，大约有15%到20%的正确答案因为表达冗余被判错。解决方式是给评分环节加一个判断函数，先检查参考标准中的核心实体是否出现在模型输出里，再检查否定词、时态等语义要素，最后才决定是否给分。

还要注意解码参数的影响。在推理时把temperature调到0.2以下，max_new_tokens控制在512以内，能显著降低模型编造内容的比例。我跑EgoExoBench类任务时，temperature设为0其实就是最稳的，因为这是在评测能力而不是评测创造性。

4.4 长视频任务的显存压力与切片策略

Temporal Localization这类任务输入的视频通常很长，全部抽帧送到模型里显存完全不够。我的做法是把视频按时间窗口切成多个重叠切片，每个切片分别推理，再用非极大抑制把重复定位合并。切片的长度要和模型的上下文窗口匹配，重叠率按10%设置比较合理。

示例切分逻辑大致如下：

ffmpeg -ss 0 -t 30 -i ego.mp4 ego_seg_0.mp4 ffmpeg -ss 27 -t 30 -i ego.mp4 ego_seg_1.mp4 ffmpeg -ss 54 -t 30 -i ego.mp4 ego_seg_2.mp4

这里30秒切片配上3秒交叠，能在完整覆盖和显存开销之间取得不错的平衡。交叠时间不能省略，第一人称视频中很多关键交互发生在片段边界附近，交叠太少会把事件一分为二，导致定位结果碎片化。

4.5 大模型裁判的系统性偏好

最后提一个评测层面的坑。用大模型做裁判时，它对“更长、更复杂、包含更多细节”的答案天然给高分，哪怕这些细节是编造的。这意味着，愿意多说废话的模型在裁判评分里会占便宜。

我尝试过几种修正方法，最有效的是强制裁判先给出评分理由，再计算整体分数，并且用三次独立采样取多数票。这个过程会把裁判的随机性从评分中分离一部分出来。人工抽检的比例不用太高，我一般抽10%到15%，但抽样要按任务类型分层抽取，确保Counterfactual这种容易编造的任务占比足够。

5. 跑完EgoExoBench后的几个真实体会

如果让我说跑这个基准最值回票价的一点，那就是它把“视角偏见”变成了一种可测量的东西。以前评测模型只看它在第三人称视频上的表现，总觉得“好像还可以”，但EgoExoBench的结果会非常清晰地告诉你：这个模型在Ego视角上的推理能力到底拉胯在哪个环节。我自己的评测记录里，相当一部分模型在Next-Event Prediction任务上几乎全错，原因不是语言理解不够，而是手部交互区域的视觉特征提取存在系统缺陷。

另一个体会是Prompt工程对视频MLLM的补偿能力有限。我们可以在Prompt里加大量提示，告诉模型“注意第一人称画面的手部动作”，能挽回一些分数，但这种补偿并不会让模型真正具备跨视角推理能力。等遇到完全没见过的交互场景时，这类靠提示词撑起来的表现就会衰减得很厉害。

所以EgoExoBench这类双视角基准带来的关键价值，不是简单地给模型排个名，而是帮助研究者定位问题出在视觉编码、时序聚合还是跨模态对齐。如果你正准备跑这个基准，我的建议是：第一轮老老实实按默认配置跑，拿一个可信的baseline；第二轮再开始尝试改提示词、改切片策略、改数据增强，逐步分析哪些改动真正有效。毕竟评测的意义在于可靠地暴露问题，而不是制造一个看起来漂亮但经不起复现的数字。