EgoCross 官方资源解读与进一步研究方案

1. 资源总览

本次解读基于 4 个入口：

• EgoCross Benchmark 官网：https://egocross-benchmark.github.io/
• CVPR 2026 EgoVis Workshop：https://egovis.github.io/cvpr26/
• 评测推理代码仓库：https://github.com/MyUniverse0726/EgoCross
• Qwen3-VL-4B 训练微调仓库：https://github.com/LiYu0524/EgoCross_SFT_qwen3vl4b

按 2026-03-17 当前页面内容，EgoCross challenge 已经挂到 EgoVis @ CVPR 2026 下，workshop 日期为 2026-06-03 / 2026-06-04，challenge leaderboard 自 2026-02 起开放，关闭时间是 2026-05-13。

2. 官网与 Workshop 解读

2.1 EgoCross 官网在说什么

官网的定位很直接：

• 这是一个 cross-domain egocentric VQA benchmark
• 覆盖 4 个域：Surgery、Industry、Extreme Sports、Animal Perspective
• 规模是 798 clips、957 QA
• 同时支持 CloseQA 与 OpenQA

官网更像 challenge 门户，而不是文档中心。它给出的最重要信息是：

• challenge 已经作为 CVPR 2026 EgoVis Workshop 的一部分启动
• 有两个 Codabench 入口：
  • Source-Limited Track
  • Open-Source Track

所以如果从实验设计角度理解，官网承担的是“官方口径 + challenge 入口”的角色。

2.2 Workshop 页面透露了哪些更关键的信息

Workshop 页面比官网多出 3 类对实验更有用的信息：

1. Challenge 的任务定义 给定 novel domain 的第一视角视频和一个问题，目标是在 A/B/C/D 四个选项中选出正确答案。

2. 两条赛道的约束

   • Source-Limited Track：限制使用官方提供的 baseline model 和小规模 support set，强调 adaptation algorithm 的公平比较
   • Open-Source Track：页面描述里写的是“对 base model 没有限制，甚至鼓励 commercial models”，并允许额外数据，只要不是专门手工构造来对齐目标域

3. 当前 SOTA 两个赛道页面都写了同一个当前 SOTA：SFT-Qwen3VL，四域平均准确率 0.4608

这三个点说明目前 challenge 的官方 baseline 仍然偏弱，且“方法空间”并没有被收紧到很死，至少在非 source-limited 轨道里仍然有很大研究空间。

2.3 一个值得注意的命名漂移

几个官方/半官方页面之间存在轻微命名不一致：

• 官网 / workshop 页面叫 Open-Source Track
• Qwen3-VL-4B 训练仓库 README 里叫 Source-Free

从页面描述看，后一种说法更接近“零样本或不受 support-set 约束的更开放赛道”，但 workshop 页面实际描述又允许额外数据和 commercial models，因此更准确的理解应以 workshop 当前文字为准，而不要仅凭仓库 README 的历史命名。

3. 评测代码仓库解读

3.1 这个仓库实际提供了什么

MyUniverse0726/EgoCross 当前仓库根目录主要有：

• eval_os_closedset.py
• eval_gpt_closedset.py
• eval_gpt_openset.py
• eval_gemini_closedset.py
• eval_gemini_openset.py
• datasets/

可见它主要覆盖的是：

• 本地 open-source VLM 的 closed-set
• GPT / Gemini 的 closed-set + open-set

3.2 代码层面的几个明确信号

从 eval_os_closedset.py 可以看出，当前本地开源模型评测的默认思路是：

• 输入为视频或抽帧后的图片序列
• 通过固定 prompt 让模型输出 JSON：
  • prediction
  • reason
• 最终只比较 prediction 和正确选项字母

支持的模型分支包括：

• qwen25vl
• qwen25vl_3b
• internvl25
• internvl3
• videollama3

但这里已经能看出仓库存在维护漂移：

• setup_model() 里仍支持 qwen2vl
• parse_args() 的 choices 却没有 qwen2vl
• README 里提到 preference.py
• 仓库根目录当前并没有这个文件
• eval_gpt_openset.py 依赖 chat_vlms
• 仓库根目录当前也没有这个模块

这意味着当前仓库更像“可参考的 benchmark 脚本集合”，而不是一套无缝可复现的完整评测包。

3.3 对实验设计的启发

这个评测仓库背后的默认范式其实非常朴素：

• 单轮推理
• 固定 prompt
• 直接 answer selection

这恰好说明还有很大的研究空间没有被 baseline 吃掉，特别是：

• 更强的时序采样策略
• 更强的 task-aware prompt
• domain-aware adaptation
• OpenQA 对开源模型的完整实现

3.4 一个重要现实点

README 里把 MyUniverse0726/EgoCross 写成主仓库，但同时又说真正的 “official evaluation code (leaderboard/submission)” 在 EgoCross-Benchmark/EgoCrossCodes。这说明当前你给的这个仓库更像公开版评测脚本和说明，而不是 challenge 提交后端的唯一标准实现。

因此做实验时最好区分三类东西：

• 论文 benchmark 定义
• 公开脚本仓库
• 真正 leaderboard 的提交格式与后端

不要默认三者完全等价。

4. Qwen3-VL-4B SFT 仓库解读

4.1 它的定位

LiYu0524/EgoCross_SFT_qwen3vl4b 的定位非常清楚：

• 基于 Qwen/Qwen3-VL-4B-Instruct
• 用 LLaMA-Factory 做训练
• 提供 full_sft.yaml 与 lora.yaml
• 目标是给 EgoCross challenge 提供一个可复现实验 baseline

4.2 数据与训练设定

README 里给出的 support set 统计是：

• Animal：20
• Industry：20
• XSports：20
• Surgery：20
• 合计：80 条 support samples

也就是说，这个 baseline 不是大规模训练，而是典型的小样本域适配设置。

训练配置也很标准：

• Full SFT：4 卡，lr=1e-5，2 epochs，DeepSpeed ZeRO-2
• LoRA：单卡可跑，rank=64，lr=2e-4
• 图像像素上限控制在 360000

4.3 它真正说明了什么

README 给出的结果是：

• Baseline：45.14
• Full SFT epoch 1：45.98
• Full SFT epoch 2：46.08

这个结果很有启发性，因为它说明：

1. SFT 是有效的，但收益很有限 只提升了不到 1 个点。

2. 跨域泛化不是“补一点 support set 就自然解决”的问题 这类任务更像结构性泛化缺陷，而不是简单缺监督。

3. 各域收益不均衡 README 中 Surgery 甚至略降，Animal 基本不动，说明单一统一 SFT 并没有真正解决 domain-specific difficulty。

4.4 仓库当前的边界

这个仓库当前更像“训练 baseline + 提交模板”，而不是完整研究框架：

• 有训练配置
• 有 prepare_data.py
• 有 submission_template.json
• 但没有完整的研究型 ablation 组织
• 也没有更强的 domain routing / retrieval / RL / OpenQA 方案

因此它更适合作为你做后续方法扩展的起点，而不是终点。

5. 哪些方向最值得进一步研究

下面这些方向不是泛泛而谈，而是从 challenge 规则、评测代码现状和 SFT baseline 短板直接推出来的。

5.1 Domain-Aware Routing / Adapter Routing

为什么值得做

• EgoCross 的难点本质就是 domain shift
• 当前 baseline 用一个统一模型直接回答四个域
• SFT 整体收益小，说明统一参数更新不够针对

怎么做

• 先做 domain classifier，识别输入属于 surgery / industry / xsports / animal 哪一类
• 根据域选择：
  • 不同 prompt
  • 不同 LoRA adapter
  • 不同 frame sampler
  • 不同 answer post-processor

适合赛道

• Source-Limited：可以做 support-set 驱动的 adapter routing
• Open-Source：可以进一步做 mixture-of-experts 或 router + external memory

5.2 Support-Set Retrieval Augmentation

为什么值得做

• 官方 support set 每域只有 20 条，但它们非常宝贵
• 当前 baseline 更像把 support set 当训练样本，而不是“推理时可检索知识”

怎么做

• 建立 support-set embedding index
• 按视觉相似度、问题类型、对象词汇检索相近样本
• 在推理时注入 few-shot exemplars 或 structured hints

价值

• 比统一 SFT 更符合小样本适配场景
• 对 Source-Limited track 尤其自然

5.3 Task-Type-Aware Specialization

为什么值得做

• EgoCross 明确分成 Identification / Localization / Prediction / Counting
• 这些任务的推理结构差异非常大

怎么做

• 先做 question type classifier
• 为不同 task family 设计不同的 answer protocol：
  • Localization：强制 timestamp 格式
  • Counting：显式“先枚举后计数”
  • Prediction：显式“当前状态 -> 下一步”
  • Identification：显式“候选项对比”

价值

• 这比单一 prompt 更可能提升难任务稳定性
• 特别适合 OpenQA / Localization / Prediction

5.4 Temporal Calibration 和 Timestamp Grounding

为什么值得做

• 论文里已经点出 GPT-4.1 在 animal localization 上会答成“第几帧”，而不是时间戳
• 说明当前模型对 FPS、帧号、时间轴的绑定并不稳

怎么做

• 显式注入 frame-index -> timestamp 映射
• 对定位问题使用结构化输出约束
• 在训练时加入 timestamp normalization loss 或格式奖励

价值

• 这类方法可能不会提升所有题型
• 但很可能显著提升 Localization 类问题

5.5 OpenQA for Open-Source Models

为什么值得做

• 当前公开仓库对 open-source 模型只给了 closed-set
• 开源本地模型的 open-set / openqa 路径并没有完整落地

怎么做

• 补齐本地开源模型 OpenQA evaluator
• 统一 judge 协议
• 研究 answer normalization、semantic equivalence、self-critique

价值

• 这是很明确的仓库空白点
• 既是工程贡献，也能做成论文实验点

5.6 RL / Preference Optimization for Cross-Domain QA

为什么值得做

• 原论文 pilot study 里 RL 提升明显大于 prompt 和 SFT
• 当前 Qwen3-VL baseline 只有 SFT / LoRA

怎么做

• 以 support set 或 judge model 为奖励信号
• 做 DPO / ORPO / GRPO / RLAIF 风格优化
• 奖励项不只看答对，还看：
  • 格式正确
  • timestamp 合法
  • reasoning consistency

价值

• 这是当前 baseline 最缺的一环
• 也是最有希望超过 0.4608 的方法方向之一

5.7 Domain-Specific Knowledge Injection

为什么值得做

• Surgery 和 Industry 的困难之一是术语和工具知识
• 通用 MLLM 往往看懂大概动作，但说不准专业对象

怎么做

• 为不同域建立轻量知识库：
  • surgical tools / phases
  • industrial components / operations
  • sports maneuvers
  • animal action patterns
• 在开放赛道里做 RAG 或 concept injection

风险

• Source-Limited track 下要严格核对规则，避免越界
• Open-Source track 更适合做这类增强

5.8 Adaptive Frame Sampling / Video Token Budgeting

为什么值得做

• 当前公开脚本本质上还是固定 fps / 固定 token budget
• Extreme Sports 和 Industry 对关键帧密度更敏感

怎么做

• 按 motion / scene change / hand-object interaction 自适应抽帧
• 针对 Prediction / Localization 任务用更高时序密度
• 针对 Identification / Counting 任务用更稳的代表帧策略

价值

• 这是最容易在不大改模型前提下拿到收益的方向之一

5.9 Multi-Stage Answering Pipeline

为什么值得做

• 当前脚本基本都是“一次性直接答”
• 但 EgoCross 的很多问题天然适合分解

怎么做

• Stage 1：识别 domain / task /关键对象
• Stage 2：做局部证据抽取
• Stage 3：输出选项或开放式答案

价值

• 更适合复杂 Prediction 和 Localization
• 可与 retrieval、routing、RL 组合

6. 我建议你优先做的 3 条线

如果你接下来要把工作做成真正的论文级实验，我建议优先按下面顺序推进：

1. Domain-aware adapter routing 成本适中，和 benchmark 本质最对齐。

2. Support-set retrieval + task-aware prompting 最贴近 source-limited 赛道，容易形成强 baseline。

3. RL / preference optimization on top of Qwen3-VL 风险更高，但潜在收益也最大。

7. 直接可落地的实验设计

实验 A：统一 SFT vs 分域 LoRA

• Baseline：当前 full SFT / LoRA
• 方法：每域单独 LoRA + 路由器
• 指标：overall、4 domains、4 task families

实验 B：support-set 检索增强

• Baseline：直接答题
• 方法：检索 top-k 支持样本后拼到上下文
• 消融：视觉检索 / 文本检索 / 联合检索

实验 C：task-aware prompt

• Baseline：统一 prompt
• 方法：对 I/L/P/C 使用不同模板
• 重点观测 Localization 与 Prediction

实验 D：RL or preference tuning

• Baseline：SFT Qwen3-VL-4B
• 方法：在 support set 或 judge reward 上做偏好优化
• 重点看是否能把平均准确率稳定推过 0.4608

8. 结论

从 2026-03-17 看到的官方资源来看，EgoCross 现在正处于一个非常适合做方法研究的阶段：

• benchmark 定义已经清楚
• challenge 已经挂到 CVPR 2026 EgoVis
• 官方 baseline 还不强
• 公开代码存在明显空白和漂移

这意味着后续真正值得做的，不是再写一版普通 SFT，而是围绕 domain adaptation、retrieval、task decomposition、temporal grounding、RL 这几个方向做系统化方法设计。