普通视频问答只要求模型看完片段再回答，实时助手的建议会改变用户下一步动作。南京大学、南开大学和滑铁卢大学联合构建OmniAssistBench，用连续视频片段测试模型能否记住历史、读懂手势、等待关键事件并在正确时间提醒。榜单中Gemini-3-Pro最高也只有66.4/100，开源Qwen3-Omni-Instruct为51.2。
基准包含685组开放问答、7类主要任务和16项细分能力，数据制作投入超过1000个专家小时。团队还自行拍摄3组真实案例，每组平均超过15轮互动。
静态视频无法覆盖“建议改变后续画面”
用户问“下一步怎么做拿铁”，模型可以先建议萃取咖啡，也可以先打奶泡，两条路线都合理；但预录视频只会沿其中一条继续。若直接拿后续画面评分，另一条正确建议反而会被判错。
项目页流程：专家先从原视频提炼固定步骤，再设计多轮问答并剪成连续片段。
OmniAssistBench先从源视频总结过程知识，把可接受路径固定下来，再围绕该路径剪片段、写问题和答案。这样能利用现有互联网视频构造交互测试，但模型得到的先验也缩小了真实世界中的路线分叉，分数应理解为受约束交互能力。
从手势提示到延迟回应
基础层测试时间感知、非语音提示、指代和社交关系；高级层覆盖流程跟踪、主动回应、上下文回应、多任务跟踪和多事件触发。用户问题通过语音、屏幕文字、手写或手势嵌入视频，模型不能只读外部文本提示。
项目页概览：会议、烹饪和视觉辅助场景被拆成基础与高级交互能力。
最难的行为之一是保持安静。当目标事件尚未发生，模型应输出等待，而不是连续描述画面。论文发现，模型容易被当前视频里的说话声吸引，忘记早先目标；长对话中还会丢失人物、物品和任务状态。
11个模型最高仍未超过70分
项目页案例：助手要跨多个视频片段持续跟踪手工制作步骤。
Gemini-3-Pro基础层63.6、高级层68.2、真实案例68.0，综合66.4。Gemini-2.5-Pro综合64.6；豆包Seed-2.0-lite为57.3；Qwen3.5-Omni-Plus为51.6；Qwen3-Omni-Instruct为51.2。模型大多能判断用户想做什么，但回答常缺步骤、给错时机或忘记多轮信息。
所有输出由LLM裁判按0至5分评分后归一化。评分细则对语义正确、完整性和冗余有明确约束，但裁判模型仍可能带来偏差。数据和论文页面标注为评审后公开，当前仓库提供评测脚本与说明，不能把完整数据集写成已经发布。
三个自摄案例分别把多项能力串在一起，而不是拆成独立问答。模型必须继承上轮状态，判断当前片段是否触发某个目标，再决定回答或保持安静。单轮成绩不错的模型，到了这种组合条件下可能因一次遗忘影响后续多轮。
榜单还受取帧策略影响。部分模型按1fps输入，部分只取固定32帧；长视频中关键手势可能落在采样间隙。论文按各模型官方推理方式配置，适合比较端到端系统表现，却不能把差距全部归因于语言模型本体。
下一步要让助手知道何时不说话
项目页示例：模型同时维护多个任务，并在对应事件出现时回应。
实时助手落地需要三项改进：跨轮状态记忆、对视觉事件的精确触发，以及在证据不足时抑制输出。基准下一步还需加入更多自由路径，让用户不必沿预设步骤行动，并用真人交互检验建议是否真的帮助完成任务。做饭和视觉辅助等场景涉及实际动作，产品还要单独处理错误建议造成的风险。
另一个待补指标是响应时延。当前分数主要评价内容与时机语义，真正的助手还要在关键事件后几百毫秒内给出提示。内容正确但延迟数秒，在烹饪、导航或辅助场景里仍可能失效。
参考资料
https://arxiv.org/abs/2608.21360
https://arxiv.org/html/2608.21360
