StreamEval
StreamEval 硅基写手StreamEval 将数字人对话、表演、世界生成与两类实时视频编辑纳入统一流式评测,以 300 个最长 5 分钟、含增量多模态请求的脚本检验任务执行、状态保持、画质和音画协同。本文拆解其时间线—预言机设计、十项指标与 37 模型实验,并分析自动裁判、排行榜聚合和交互延迟评测尚存的边界。
论文基本信息
- 题目:StreamEval: Evaluating Interactive Streaming Video Generation Models
- 作者:StreamEval Team;成员包括 Jungang Li、Ziqi Huang、Tian Ye、Haocheng Xi、Yuezhou Hu、Kai Jiang、Zhifei Li、Yichuan Wang、Shuo Yang、Zhiqiu Lin、Zian Zheng、Alberto Taiuti、Jintao Zhang
- 机构:Tsinghua University、NVIDIA、Carnegie Mellon University、UC Berkeley、Princeton University、National University of Singapore、Reactor
- arXiv:2610.28402v1,2026 年 10 月 20 日提交,类别 cs.CV,全文 22 页
- Daily Papers:Hugging Face 页面 2026 年 10 月 22 日榜首
- 研究对象:能够在生成过程中持续接收语音、文本、图像等新请求的交互式流式视频系统
- 评测规模:5 项任务、300 个脚本化测试、15–300 秒五档时长、37 个模型、47 个任务配置
- 链接:Hugging Face 详情页;arXiv 摘要页;arXiv HTML 全文;arXiv PDF 全文;项目与排行榜;代码仓库;基准数据
一句话结论
StreamEval 的价值不是再给视频模型增加一个“画面好不好看”的总分,而是把交互过程写成带时间点、目标状态和保护条件的可执行契约;它揭示了当前系统即使能维持较好身份与画质,也经常无法按时执行新请求并保留既有状态,但自动裁判与手工加权、未单列端到端响应延迟、部分结果筛选等设计仍限制了排行榜分数的解释范围。
背景与动机
从离线短视频到持续交互
传统文本生成视频或图生视频评测通常给模型一个静态条件,再判断几秒结果的清晰度、运动质量和语义对齐。交互式流式视频面对的是另一类问题:视频尚在生成,用户就可能追加新要求。数字人要在对话中记住角色和上下文,也要判断何时回答、何时被打断;世界模型要执行新的物体、动作或镜头控制,同时不能破坏无关场景;实时编辑器则要跟随不断前进的源视频,添加、更新或取消编辑。
这意味着“当前帧看起来合理”只是必要条件。系统还必须回答四个连续状态问题:
- 新请求有没有在规定时间内发生;
- 请求是否作用于正确目标和范围;
- 先前仍有效的状态有没有保留;
- 取消编辑后能否恢复到同一时刻的源视频,而不是回到一张旧画面。
现有基准分别覆盖视觉质量、时序转变、多轮世界控制、长视频编辑或全双工对话,却很少用统一协议同时覆盖数字人、生成世界与在线编辑。StreamEval 的目标正是建立一个共同的“会执行、能保持、看得好、配得准”评测框架。
论文真正要测的能力
论文把交互能力拆成四个维度:任务执行、状态一致性、视觉保真度、音画协同。这个拆法很重要,因为单一总分会掩盖完全不同的失败模式。例如,一个数字人可以身份稳定、画面清晰,却不按要求抬手;一个视频编辑器可以保住背景,却始终没有把灰色斗篷换成指定的金色材质;一个世界模型可以生成漂亮场景,却在新控制到来后丢失物体或改变空间关系。
因此,StreamEval 的核心问题不是“哪一个模型综合最好”,而是:模型在持续输入下究竟在哪个环节失效,以及画质、执行、记忆和同步之间是否存在明显错位。
核心贡献
1. 用统一协议覆盖五类流式任务
基准包含数字人对话、数字人表演、世界生成、指令编辑和参考图编辑五项任务。每项任务各有 60 个测试,均衡分布在 15、30、60、120、300 秒五档时长,每档 12 个;全部 300 个测试覆盖 240 个独立源族,一次完整运行对应 525 分钟主动流式生成。
与只测试一次性提示不同,每个测试都包含初始素材、按时间到达的在线输入,以及明确的改变与保留要求。300 个测试共安排 1,347 个在线事件,不含初始化和持续到达的源视频帧。输入形式覆盖语音、文本与视觉参考,一个事件还可能同时产生多个执行和保护约束。
2. 把交互请求写成可验证的状态契约
每个案例都包含时间线和作者审定的 oracle。时间线说明控制何时释放,oracle 则规定每个检查点需要建立、保留、取消或恢复什么状态。调度器只在预定时刻把输入交给模型,评分机会也随会话时钟出现,因而模型不能预先看到后续请求。
这一设计尤其适合连续编辑。例如,系统先把对象 A 改成红色,再增加对象 B 的编辑,同时保留 A;之后切换 B 的参考图,最后取消 A,使它恢复为当前源视频中的状态。每一步都同时包含“必须变化的部分”和“不得变化的部分”,比只比较最终帧更接近真实编辑会话。
3. 用十项指标分离执行、状态、画质与协同
StreamEval 定义十项 0–100 指标:
| 维度 | 指标 | 主要问题 |
|---|---|---|
| 任务执行 | Dialogue、Following、Edit Success | 回答或动作是否正确,编辑契约是否完整完成 |
| 状态一致性 | Stability、Continuity、Preservation | 视频是否稳定,世界状态是否连续,非目标与源运动是否保留 |
| 视觉保真度 | Quality、Identity、Reference | 画面缺陷、人物身份、参考外观是否符合要求 |
| 音画协同 | A–V Sync | 语音事件与唇部开合是否对齐 |
这些指标按任务选用。数字人表演同时看 Following、Quality、Stability、Identity 与 A–V Sync;世界生成看 Following、Continuity、Quality 与 Stability;指令编辑把 Following 与更严格的 Edit Success 分开,后者要求作用范围、激活状态、截止时间、持续性和受保护内容全部通过。
4. 在同一框架中评估 37 个模型
作者报告 37 个不同模型的 47 个任务配置,包括商业接口与开源系统,覆盖 15 个数字人对话配置、7 个数字人表演配置、17 个世界生成配置、5 个指令编辑配置和 3 个参考图编辑配置。每个测试对每个模型重复三次,并先在案例内平均,再分别平均五档时长,避免 300 秒案例仅因帧数更多就压倒短会话。
方法拆解
基准如何构造
Qwen3.8-Max 用于起草会话目标、定时控制、受保护属性和期望结果,GPT-Image-2 与 Qwen-Image 生成合成肖像或视觉参考,Qwen3.5-Omni 生成用户语音和规定台词。编辑源则来自经许可的实拍、动画与基准生成视频,包括 Wikimedia Commons、NASA 和 Blender Studio 素材。
自动化不等于直接采用模型输出。作者对素材做了多层检查:Qwen3-ASR 转写合成语音,归一化词错误率必须不高于 0.25;Qwen3.8-Max 检查主体清晰度、解剖与渲染缺陷;编辑视频还要排除场景切换、冻结片段和不合适目标。被退回的素材重新生成后必须通过同一流程。
值得注意的是,论文称全部案例的时间线、oracle 和媒体会一并发布,这使复现实验不只依赖一组提示词,还能获得判定状态变化所需的结构化规则。
五项任务分别测什么
- 数字人对话:输入用户语音,检查事实回答、跨轮记忆、轮次管理、打断与修复,同时评估身份、画质、稳定性及音画同步。
- 数字人表演:给定规定语音和视觉控制,检查视线、表情、姿态或手势是否在指定目标上执行。
- 世界生成:持续更新对象、动作、镜头或空间状态,既看控制跟随,也看运动、物体恒存、转场和空间关系的连续性。
- 指令编辑:用文字修改不断前进的源视频,要求目标、范围、时限、持续性和保护条件同时满足。
- 参考图编辑:用图像指定外观,并测试参考切换、多目标保留与取消编辑后的源状态恢复。
自动评分如何工作
Quality 以五秒片段为单位,根据缺陷数量和严重程度映射为 0、25、50、75、100。Stability 不只是“有没有闪烁”:片段还必须没有严重时序缺陷、最多一个轻微时序缺陷且 Quality 至少为 50,因此两个指标存在设计上的重叠。
Identity 由 Qwen3.8-Max-0902 和 Qwen3-VL-Plus 两个裁判比较初始肖像与采样帧,取较低评分,以防同风格但不同人物被误判为身份一致。A–V Sync 则计算唇部开合与音频包络的相关性,并要求汇总偏移的 95% 区间落在 -200 到 200 毫秒内。
作者还用正负探针校准生产裁判,目标阈值是每类误报率不高于 5%、漏报率不高于 10%、无法判定比例不高于 10%。无法判定的结果形成上下界,表格在存在未决判定时报告保守下界;无输出、不支持的操作、未触发事件和超出服务时长限制的控制都计零分。
分数怎样聚合
单项指标先平均每个案例的三次运行,再平均同一时长档内的案例,最后等权平均五档时长。任务的 Q-Overall 是所有适用指标的算术平均,没有按业务重要性或指标相关性重新加权。
数字人任务另加一个手工“sweet-spot bonus”:支持自定义头像的系统在 Q-Overall 上加 5 分,只能使用供应商固定头像的系统不加分。因此数字人 Overall 理论上可达 105,而其他任务仍是 0–100。这个奖励表达了接口能力,但不属于输出内容质量,阅读排行时应同时查看 Q-Overall 与 Overall。
实验结果
总体观察:好看不等于听话
37 个模型的共同图景是,视觉质量、身份保持和时序稳定可以很高,但对在线请求的可靠执行仍明显落后。不同指标上的冠军也经常不是同一个系统,说明“最佳模型”高度依赖应用究竟优先画质、控制、状态还是同步。
| 任务 | Overall 领先者 | 关键成绩 | 主要短板信号 |
|---|---|---|---|
| 数字人对话 | Vidu S2 Avatar | Overall 93.98;Dialogue 75.29 | 仍有约四分之一计划轮次未完全满足 |
| 数字人表演 | Vidu S2 Avatar | Overall 81.71;Following 36.90 | 最佳动作跟随仍低于 40 |
| 世界生成 | MemFlow | Overall 33.36 | 最高 Following 仅 25.93,且来自 Krea Realtime |
| 指令编辑 | Vidu S2 Editing | Overall 45.43;Edit Success 57.20 | Quality 22.99、Stability 13.94 |
| 参考图编辑 | Vidu S2 Editing | Overall 39.02;Edit Success 15.00 | 完整编辑契约成功率极低 |
数字人对话与表演
在支持自定义头像的对话系统中,Vidu S2 Avatar 以 88.98 的 Q-Overall 加 5 分奖励得到 93.98 Overall,并在 Quality 96.78、Dialogue 75.29、Identity 90.12 上领先。固定头像系统 Tavus CVI Full 的 Q-Overall 为 86.65,A–V Sync 达 94.44、Dialogue 达 73.91,但因不能自定义头像没有奖励。
分项错位非常明显。MuseTalk 1.5 的 Quality、Stability、Identity 分别达到 95.34、97.11、88.44,A–V Sync 却只有 38.09;LiveAvatar FULL 的 Stability 为 100,A–V Sync 却是 0。它们说明稳定输出不能替代内容、行为和同步评测。
数字人表演更能暴露控制瓶颈。Vidu S2 Avatar 虽以 81.71 Overall 领先,Following 也只有 36.90;LiveTalk 获得最高 Quality,但不是最可靠的动作执行者。换言之,当前实时数字人更像稳定的“说话视频生成器”,还不是精确接受视线、表情、姿态和手势控制的可编程角色。
世界生成
MemFlow 以 33.36 Overall 排第一,Rolling Forcing 为 33.01,Krea Realtime 为 31.61。HappyOyster 1.0 Adventure 的 Quality 和 Stability 最高,分别为 58.34 与 56.67,但 Following 仅 5.56、Continuity 仅 2.78,最终 Overall 为 30.84。
Krea Realtime 的 Following 最高,也只有 25.93;Matrix-Game 3.5 的 Continuity 最高,为 34.50;Reward Forcing 的 Following 达 23.33,Stability 却只有 16.06。结果表明世界模型尚未同时解决三件事:把画面生成好、维持长程世界状态、及时服从新的在线控制。提升其中一项经常不能迁移到另外两项。
指令编辑与参考图编辑
指令编辑中,Vidu S2 Editing 以 45.43 Overall 领先:Following 72.10、Edit Success 57.20、Preservation 60.93,但 Quality 与 Stability 只有 22.99 和 13.94。JoyAI-Video-Edit 以 42.39 排第二,Preservation 最高,达到 83.33,却在完整编辑成功和视觉稳定性上落后。
这里 Following 和 Edit Success 的差距很有解释力:前者只要求操作和目标基本正确,后者还要求范围、时限、持续状态与受保护内容全部满足。看见“确实改了”并不意味着系统完成了正确、及时且不破坏其他内容的编辑。
参考图编辑更困难。Vidu S2 Editing 的各项成绩均领先,但 Edit Success 也只有 15.00;JoyAI-Video-Edit 和 XMax X2.0 分别只有 8.89 与 1.11。论文展示的斗篷案例中,模型能维持原场景,却没有采用 10 秒时切入的金色缎面参考外观,直接说明“保住源内容”和“执行新参考”是两个独立能力。
如何理解这些结果
交互视频的瓶颈已经从生成转向状态控制
短视频模型的早期竞争主要集中在清晰度、运动和文本对齐。StreamEval 显示,当模型进入持续交互场景,难点转变为“有条件地改变”:只修改指定目标,在正确时间发生,持续到取消命令到来,同时维持其他对象、身份、镜头和运动。
这类问题不能靠提高单帧画质自然解决。它更接近带视觉生成器的状态机:系统需要显式表示当前有效指令、对象绑定、事件时序、保护约束和可撤销历史。对模型开发者而言,评测结果提示训练目标应覆盖请求执行与状态转移,而不能只优化重建或感知质量。
一张总榜不足以支持产品选型
各模型的优势分散在不同维度。数字人客服可能更看重 Dialogue、身份和 A–V Sync;虚拟演出需要动作 Following;游戏世界强调控制与 Continuity;直播编辑则要在 Edit Success 和 Preservation 之间保持平衡。StreamEval 的分项指标比 Overall 更适合做系统选择。
尤其是数字人任务的加 5 分自定义头像奖励,它可能改变排序,却不代表生成内容本身提高了 5 分。实际使用者应先按接口能力筛选,再比较 Q-Overall 和关键分项,而不是把 Overall 当作跨任务、跨产品的绝对能力值。
应用影响
对模型研发
- 用时间线与 oracle 直接生成训练或强化学习奖励,把“建立—保留—替换—取消—恢复”作为状态转移单元。
- 针对长会话加入显式对象记忆、指令有效期和保护集合,降低新请求覆盖旧状态或全局漂移的概率。
- 将画质、执行和保留分别优化,避免一个感知分数掩盖控制失败。
- 对 15–300 秒各时长分层评估,区分即时执行问题与随时间积累的状态漂移。
对产品与系统工程
- 数字人和实时视频编辑产品可把 StreamEval 风格的案例转成上线前回归测试,而不是只做主观样片评审。
- 商业 API 若存在会话时长上限或不支持某类在线操作,会在全量计划事件分母中暴露真实能力边界。
- 直播、游戏和虚拟角色系统可以分别建立面向自身风险的加权指标,不必照搬论文的等权 Overall。
- 编辑产品应单独展示操作命中、完整成功和源内容保留,避免用“看起来改过了”替代严格验收。
局限与批判性分析
自动裁判尚未与大规模人类偏好闭环
论文对自动裁判设置了误报、漏报和未决比例阈值,也用双裁判的较低分保护身份评估,这是比直接调用一个 VLM 打分更谨慎的设计。然而,结论明确把收集人类成对判断并检查其与任务 rubric 的一致性列为下一步,说明当前还没有给出覆盖全部指标和任务的大规模人类一致性结果。
自动裁判可能受提示、模型版本、视觉细节可见性和自家模型偏差影响。结构化规则能提高可审计性,却不能证明 0–100 的细微差距都具有同等的人类意义。因此,小幅排行榜差异不应被解读为稳定的真实能力差距。
Overall 包含可争议的设计选择
各适用指标等权平均,尽管 Quality 与 Stability 明确重叠;数字人又额外加入固定的 5 分自定义头像奖励,使其 Overall 可超过 100。五档时长等权可以防止长视频主导结果,但也意味着每分钟真实失败率不会直接反映在总分中。
这些选择并非错误,却是价值判断。论文完整披露公式和分项,因此合理用法是根据场景重新聚合,而不是把 Overall 当成自然常数。
“实时”能力没有被完整刻画
案例有明确的请求时间、截止时间和会话时钟,Dialogue 与 Edit Success 也包含时限条件;超出供应商时长上限的请求会计零分。但论文没有单列首帧延迟、控制响应延迟、稳定帧率、吞吐、算力或成本,也没有在统一硬件上比较端到端服务性能。
因此,StreamEval 主要测“流式会话中的内容与状态正确性”,不能单独证明一个模型满足真实直播或交互产品的延迟预算。内容得分相同的两个系统,部署可用性仍可能完全不同。
模型覆盖广,但并非所有结果都无条件报告
论文称编辑表只展示 Overall 至少为 5 的配置,而且这个展示子集是在评估后选择的。低于阈值的系统不出现在表中,会让读者难以观察完整失败分布,也削弱模型总数与可见结果之间的直观对应。
同时,商业 API 与开源模型的输入接口、头像定制、最长会话和适配组件不完全相同。统一协议能反映产品实际可用能力,但不能把分数差异全部归因于模型架构本身。
覆盖仍有明确边界
基准使用合成肖像与语音、受控声学变化和许可视频,尚未系统覆盖更广泛身份、环境、全局重置,以及多个并行编辑存在时的选择性恢复。数字人对话也不测试实时用户视频的非语言感知,而这正是 VideoFDB 等全双工评测关注的部分。
此外,300 个案例和 240 个源族足以做首轮横向诊断,却仍可能被未来模型针对性优化。案例版本、隐藏测试集和持续扩充机制将决定 StreamEval 能否长期避免基准过拟合。
相关工作脉络
- 视觉质量与语义对齐:VBench、VBench++、EvalCrafter 将画质、运动和语义拆成多维指标,T2V-CompBench 强调组合对齐;StreamEval 在此基础上加入在线请求和状态约束。
- 时序变化与长期记忆:TC-Bench 评估状态转变,NarraStream-Bench、MBench、ViewBench 分别关注叙事一致性、世界记忆和几何漂移;StreamEval 把这些问题放入增量控制会话。
- 交互世界评测:WorldScore、WorldMark、WBench 与 WBench-Editing 已测试世界控制、多轮导航和连续编辑,StreamAV-Bench 进一步评估流式音视频更新与状态复用。StreamEval 的增量是把多个应用域放进共享协议,而不是首次提出交互评测。
- 数字人与全双工对话:THEval 和 GenBench 关注说话人画质及同步,Full-Duplex-Bench 和 VideoFDB 关注轮次、打断和非语言视听互动。StreamEval 区分规定表演与开放对话,但没有覆盖实时用户视频感知。
- 流式视频编辑:LiveEdit、SANA-Streaming、StreamEdit、EgoEdit、JoyAI-Video-Edit、EditaLive 和 Vidu S2-Editing 探索少步生成、源内容保持与参考条件。StreamEval 用持续前进的源视频和显式撤销要求统一比较这些接口。
最终判断
StreamEval 是一篇以评测设计而非新生成模型为中心的工作。它最扎实的贡献,是把模糊的“交互性”具体化为带时间、目标、有效状态和保护范围的可检查契约,并用分项结果证明高画质与可靠控制并不等价。300 个跨五任务、最长五分钟的会话也比只看短片或最终帧更接近持续视频系统的真实失败面。
论文支持的准确结论是:当前交互式流式视频系统已经能在部分任务上维持较高视觉质量、身份或源内容,但动作跟随、世界控制和参考编辑的完整成功率仍低;特别是参考编辑最高 Edit Success 只有 15.00。它尚不能支持“某模型已经全面实时可用”,因为延迟和成本没有统一测量,自动裁判仍待大规模人类校准,Overall 又包含明确的手工聚合选择。
如果后续版本加入隐藏案例、统一系统性能测量、人类一致性报告和更广的用户感知与恢复操作,StreamEval 有潜力成为连接研究指标与实际交互视频产品验收的重要基准。就当前版本而言,最有用的不是记住谁排第一,而是采用它的基本原则:把每一次交互写清楚——何时发生、改什么、保留什么、何时撤销,然后分别测量。