视频生成模型发展到现在大家关注的焦点已经不是“它能生成多清晰的画面”而是“它到底懂不懂自己在生成什么”。同样是让模型生成一段“猫从桌子跳下来”的视频有的模型能给出流畅合理的运动过程有的模型却会出现猫在空中翻跟头的诡异画面。这类差异暴露出的问题恰恰是现有很多评测指标回答不了的。VGI-Bench 这类以“探针”方式切入的视频生成模型视觉智能评估体系正是冲着这个痛点来的。这篇文章会讲清楚三件事为什么现在需要一个专门评测视频生成模型视觉智能的基准测试、探针评测和传统评测在方法论上有什么本质区别以及作为一个普通开发者或研究者你可以怎么理解和使用这套评测思路。1. 视频生成模型评测卡在哪里了如果只看近几年的视频生成模型论文会发现评测部分几乎形成了一套固定模板FVDFréchet Video Distance算一下、CLIP Score 算一下、再来几个主观打分结论就是“我们的方法比 baseline 好”。这套体系在模型能力还比较弱的时候是够用的因为那时候大家比的是谁生成的画面更清晰、更逼真。但当视频生成模型进入大规模扩散模型和 DiT 架构时代之后问题开始变得棘手。很多模型生成的画面已经足够逼真单张截图甚至能骗过人类的眼睛可一旦把视频连续播放或者让模型去完成一个需要“理解物体关系、运动规律、因果关系”的任务它就会暴露出物理世界认知能力的不足。一个很典型的场景是你用视频生成模型生成一个人拿起杯子喝水的视频。仔细观察中间几帧杯子可能先出现在手边然后突然瞬移到嘴边中间完全没有经典的运动轨迹。这种错误对 FVD 这类指标来说并不敏感因为 FVD 衡量的是生成视频分布和真实视频分布之间的特征距离它会把“杯子瞬移”当成合理的统计波动。这正是为什么需要 VGI-Bench——它不是为了再增加一套“打分标准”而是要回答一个更底层的问题视频生成模型在生成过程中是否表现出了对视觉世界的理解能力我倾向于把这种评测称为“能力探针”它不再只看模型输出的画面质量而是通过设计特定任务探测模型内部是否具备某种视觉认知能力。这和当年 NLP 领域从“BLEU 分数”走向“Benchmark 测试集”的路径非常相似。从技术演进的视角看视频生成模型的评测正在经历三个阶段评测阶段核心关注点代表指标主要局限第一阶段画质评测单帧/短片段清晰度PSNR、SSIM、FVD无法体现语义理解第二阶段文本对齐评测生成内容与提示词匹配度CLIP Score、T2V Metrics对时序和物理规则不敏感第三阶段视觉智能评测模型对世界运行规律的理解VGI-Bench 类任务评测设计难度高处于发展期这篇文章的读者如果你正在做视频生成模型的评测工作、研究视觉智能的评价方法论或者只是想搞清楚“市面上这些视频生成模型哪个真的更强”VGI-Bench 这套思路值得你花时间读完。2. 视觉智能到底是什么怎么评测先说概念。“视觉智能”和“视觉生成能力”是两码事。视频生成能力指的是模型能生成符合文本描述的动态画面视觉智能指的是模型在生成过程中是否具备关于物体、空间、时间、运动和因果关系的内部认知。举个例子。你让一个模型生成“篮球从高处掉落到地面然后弹起”的视频。生成能力强的模型可能输出一段画质精美、光线真实的视频但篮球落地后可能直接穿过地面消失或者弹起的高度毫无规律。而具备视觉智能的模型哪怕画质稍微弱一些也会生成符合重力规律的弹跳过程。前者是“画得漂亮”后者是“懂物理”。那这种“懂不懂”该怎么评测传统指标抓不住它主观评测又缺乏可复制性。VGI-Bench 采用的关键方法就是“探针”。“探针”这个词学术上叫 probe最初在神经网络可解释性研究里用得比较多。它的核心思路是不直接观察模型内部的隐层表示而是设计一些特定的输入或任务观察模型的输出行为从行为反推模型内部是否学到了某些概念或规则。在 VGI-Bench 这个场景下探针任务的设计逻辑通常是这样的首先选定一个可验证的视觉理解维度。比如物体运动轨迹、物体恒存性、空间位置关系、物理规律、时序逻辑、交互动作等。然后为这个维度设计一个可自动判定的生成任务。这里的“可自动判定”很重要——你不能靠人眼看视频打分因为那样成本高、主观性强、难以规模化。最后把模型生成的视频输入到另一个具备视觉理解能力的判定器里用规则化或模型化的方式判断是否满足预期的视觉逻辑。这种设计思路最巧妙的地方在于它把“生成模型是否理解视觉世界”这个问题转化成了“生成模型能否完成一系列需要视觉理解才能完成的任务”。前者难以直接回答后者则可以设计成标准化测试。从评测方法上讲探针可以分为两种类型。一种是“行为探针”就是直接测试输入输出行为看模型在特定任务上的表现另一种是“内部探针”需要访问模型内部表示这通常适用开源模型。VGI-Bench 如果要覆盖多种闭源模型大概率走的是行为探针路线因为不需要访问模型内部只需要定义输入、跑推理、判定输出即可。3. 为什么现有视频生成模型会在视觉智能上翻车要理解 VGI-Bench 的价值得分清视频生成模型在哪些环节容易暴露“智能不足”的问题。这里按我的观察梳理四个最常见的翻车场景。第一个是物体恒存性问题。一个物体被遮挡之后模型能不能记住它仍然存在很多视频生成模型无法处理这种情况。比如一个球滚到箱子后面再从另一侧滚出来中间的遮挡过程一旦超过几帧有些模型就会忘记球的存在或者让球在遮挡期间改变颜色、形状。这种错误本质上反映了模型缺乏物体持久性认知。第二个是物理规律问题。重力、碰撞、弹性、惯性这些在物理世界里再自然不过的规律视频生成模型经常学不好。原因在于训练数据里虽然包含了大量的物理视频但模型更多学会了统计相关性而不是物理因果模型。用统计方式拟合物理规律在训练分布覆盖的范围内表现不错一旦遇到训练集里不常见的情景组合就会产生离谱的错误。第三个是时间逻辑问题。视频天然是时间序列模型需要保证因果顺序正确。比如“先开门再进门”这个顺序不能颠倒。部分视频生成模型在这一块偶尔出错原因在于生成过程往往是从噪声逐步去噪出来的整个视频立方体时序上的一致性依赖注意力机制对跨帧关系的建模但注意力机制擅长捕捉局部相关性并不天然保证全局时间因果。第四个是空间关系问题。物体之间的相对位置关系比如“桌子左边放着一杯水”“杯子在书的前面”这种空间逻辑在中文文本描述中尤其容易出错。因为中文的空间关系表达比较灵活模型在文本编码阶段可能就理解了错误的语义然后生成阶段又把错误的语义视觉化。这些翻车场景用现有评测指标几乎很难被精确捕捉。FVD 看的是分布距离CLIP Score 看的是文本-视频的整体匹配度都无法把“球被遮挡后是否还存在”这类细粒度逻辑抽出来检查。VGI-Bench 的探针任务设置很大程度上就是围绕这些具体的认知维度来展开的。4. VGI-Bench 探针评测设计应该长什么样虽然我没法给出 VGI-Bench 官方测试集的全部细节但从“探针评测”的通用方法论出发可以把一套合理的 VGI-Bench 流程拆解成五个环节。首先是指标维度定义。先确定要评测哪些视觉智能维度通常包括物理规律理解、空间关系推理、时序一致性、物体交互逻辑、运动轨迹合理性、场景语义一致性等。每个维度需要定义清晰保证评测者之间能达成共识。其次是探针任务生成。每个维度都要设计成具体的生成任务。比如物理规律维度可以设计“小球从斜坡滚下、撞到障碍物后改变方向”这种明确需要物理理解的任务。任务本身要足够简洁确保一个真正具备视觉智能的模型应该能轻松完成而不是依赖复杂推理。这个设计原则是为了避免把“视觉智能”和“通用知识”混在一起。第三是自动判定机制。这是探针评测能否规模化的关键。常用的方式有两种基于规则判定和基于模型判定。基于规则判定适合空间位置、运动轨迹这类客观属性明确的场景比如检测物体的边界框是否穿越了不应该穿越的区域。基于模型判定适合更复杂的语义逻辑比如用视觉语言模型去判断生成视频是否符合某个逻辑描述。两种方式各有优劣规则判定可解释性强但灵活性差模型判定适应性强但需要防范判定器自身的误判。第四是多任务综合评分。单个任务只能反映一个维度的能力VGI-Bench 需要覆盖多个维度然后设计合理的聚合方式。这里最忌讳的是简单平均因为不同任务的难度并不相同。更合理的做法是分维度报告分数让使用者根据自身需求关注不同维度。第五是最小可评测样本量。探针测试任务需要保证统计显著性不能只生成一次视频就下结论。因为视频生成模型本身有随机性同一条提示词生成多次结果可能差异很大。通常需要重复生成 N 次统计正确率或者平均分。5. 用 Python 实现一个极简 VGI-Bench 探针评测脚本理解了原理之后下面用一段极简的 Python 代码演示 VGI-Bench 的探针评测工作流。这里不做完整实现而是带你跑通“定义探针任务-调用视频生成模型-自动判定结果”的最小闭环。# 文件路径probe_eval_demo.py 极简 VGI-Bench 风格探针评测示例 用于演示探针任务的设计与自动判定流程 from dataclasses import dataclass from typing import Callable, Dict, List dataclass class ProbeTask: 一个探针任务的基本结构 task_id: str dimension: str # 评测维度如 physical / spatial / temporal description: str # 任务描述 prompts: List[str] # 该任务对应的输入提示词 validator: Callable # 判断生成结果是否满足预期的函数 def generate_video(prompt: str, model_name: str demo_model) - dict: 调用视频生成模型生成视频。 在实际使用时这里应该替换为真实的模型推理代码例如调用 Sora、Kling、Runway 等模型的 API 或本地模型。 当前示例返回模拟结果用于演示流程。 return { model: model_name, prompt: prompt, video_path: foutputs/{model_name}_{abs(hash(prompt))}.mp4, # 真实场景中这里还会包含视频文件或其他必要信息 } def check_gravity(result: dict) - bool: 示例判定函数检查生成的视频是否满足重力规律。 真实实现中可以调用目标检测模型提取物体轨迹 然后检测轨迹是否符合重力加速度曲线。 这里用模拟值代替。 # 模拟判定真实场景请替换为轨迹检测逻辑 return result.get(gravity_ok, True) def check_spatial_order(result: dict) - bool: 示例判定函数检查生成视频中物体空间关系是否正确。 可以借助目标检测模型输出物体位置再判断相对关系。 return result.get(spatial_ok, True) # 构造探针任务 physics_probe ProbeTask( task_idprobe_001, dimensionphysical, description检测生成视频中的重力规律, prompts[ 一个小球从桌面边缘掉落垂直落到地面, 一个苹果从树上掉下来砸在地面上弹了一下 ], validatorcheck_gravity, ) spatial_probe ProbeTask( task_idprobe_002, dimensionspatial, description检测生成视频中的空间位置关系, prompts[ 一杯水放在一本书的左边镜头缓慢推近, 一只猫坐在一张椅子的下方 ], validatorcheck_spatial_order, ) PROBES [physics_probe, spatial_probe] def run_probe_evaluation(tasks: List[ProbeTask], model_names: List[str], repeat: int 3) - Dict[str, Dict[str, float]]: 运行探针评测。 对每个任务使用多条提示词每条提示词重复生成 repeat 次统计通过率。 results {} for model in model_names: model_result {} for task in tasks: pass_count 0 total_count 0 for prompt in task.prompts: for _ in range(repeat): # 生成视频 video generate_video(prompt, model_namemodel) total_count 1 # 调用任务自身的判定器 if task.validator(video): pass_count 1 accuracy pass_count / total_count model_result[task.dimension] round(accuracy, 4) results[model] model_result return results if __name__ __main__: output run_probe_evaluation(PROBES, [model_A, model_B]) for model, scores in output.items(): print(f模型: {model}) for dim, score in scores.items(): print(f 维度 {dim}: 通过率 {score:.2%})运行这个脚本预期输出如下$ python probe_eval_demo.py 模型: model_A 维度 physical: 通过率 100.00% 维度 spatial: 通过率 100.00% 模型: model_B 维度 physical: 通过率 100.00% 维度 spatial: 通过率 100.00%因为判定函数里写死了返回 True你会看到所有模型的通过率都是 100%。把这个示例应用到你自己的项目中时需要替换两处核心逻辑一处是generate_video接上真实的模型推理接口另一处是各个check_*函数接上真正能够分析视频内容的算法或模型。如果判定结果全部为 100% 或者全部为 0%先不要怀疑模型能力先检查判定函数是否工作正常。常见做法是先用人工标注好的视频片段测试判定器确认判定器本身的准确率达到合理水平再对生成模型做批量评测。6. 用视觉语言模型实现自动化判定器探针评测里判定器的重要性不亚于生成模型本身。在真实 VGI-Bench 评测中很多维度不是用规则就能判定的比如“视频是否符合‘猫先跳到桌子上然后坐下来’这个描述”这种时候可以考虑用视觉语言模型作为判定器。下面给出一个用视觉语言模型做判定的思路伪代码仅用于说明流程。# 文件路径vlm_validator_demo.py 使用视觉语言模型VLM作为探针判定器的思路演示 from typing import Dict def validate_with_vlm(video_path: str, expected_logic: str) - Dict[str, any]: 思路将视频帧序列 预期逻辑描述输入给 VLM 让 VLM 以结构化 JSON 的形式返回判断结果。 # 1. 从视频中抽帧 # frame_paths extract_frames(video_path, sample_rate1) # 2. 构造 VLM 输入 user_query f 请观看以下视频帧判断视频内容是否符合这个逻辑描述 {expected_logic} 请以 JSON 格式返回判断结果格式如下 {{ is_match: true/false, reason: 简要说明判断依据 }} # 3. 调用 VLM API 或本地模型 # response vlm_api.infer(frame_paths, user_query) # 这里使用模拟返回 response { is_match: True, reason: 视频中猫先跳到桌面然后坐下的动作顺序正确。 } return response if __name__ __main__: video outputs/sample_cat.mp4 logic 猫先跳到桌子上然后坐下来 result validate_with_vlm(video, logic) print(result)在实际评测过程中使用 VLM 做判定器有一个必须注意的坑VLM 自身对视频内容的理解能力并不是100%准确的。如果 VLM 判定出错整个评测结果就会失真。所以当用 VLM 做判定时需要做两件额外的事情一是人工抽检一部分判定结果确认 VLM 判定的准确率二是对判定事件重复多次投票降低随机误差。这个设计也体现了“探针”方法论的另一层价值它既评测了视频生成模型也在一定程度上评测了作为判定器的视觉理解模型。如果你在做一个视频生成模型的横向对比评测把 VLM 判定器的置信度分开报告对使用者会更有参考价值。7. 视频生成模型本地部署对探针评测的影响在视频生成模型领域“本地部署”这几个字非常关键。VGI-Bench 要跑测试集不能只依赖几个云端模型 API。模型如果只能通过 API 访问你的评测就得受限于别人的限流策略、成本和网络延迟。而且闭源模型可能因为提示词审核机制直接拒绝部分探针任务的生成请求这样评测的覆盖度就会大打折扣。本地部署的模型通常来自开源社区比如基于 Stable Video Diffusion 衍生出的改进模型、Open-Sora 系列或者其他开源视频扩散模型。这些模型可以拉下来跑在本地 GPU 上评测过程完全可控。本地部署对探针评测的意义体现在三个方面第一是可重复性。你可以在完全相同的硬件、依赖版本、随机种子条件下多次运行探针任务确保评测结果可复现。这对学术研究尤其重要。第二是可定制性。你可以修改模型的推理流程例如改变采样步数、使用不同的 classifier-free guidance 权重观察这些因素对视觉智能表现的影响。这种“干预式”实验只能通过本地部署实现。第三是可解释性。如果模型在某个探针任务上失败你可以进一步检查模型中间层的注意力权重定位是文本编码的语义理解出了问题还是去噪过程中的时序建模出了问题。不过本地部署视频生成模型的硬件门槛不低。以当前主流的开源视频生成模型为例显存需求普遍在 24GB 以上生成一段几秒钟的视频通常需要几分钟到十几分钟。这意味着在跑 VGI-Bench 探针评测时需要提前估算总耗时合理安排生成批次和参数。这里给一个保守的算力估算方式假设评测集有 50 个探针任务每个任务 5 条提示词每条提示词重复生成 3 次总生成次数就是 750 次。如果单条视频生成耗时 3 分钟总耗时约 37.5 小时。在实际评测之前先跑一个小规模子集估算单条生成耗时再决定是否缩减任务量。8. 探针评测结果怎么解读探针评测跑完之后得到的不是简单一个分数而是一组细粒度的能力画像。读结果时需要注意以下几点。同一个模型的各维度得分通常参差不齐。比如某个模型可能在“物理规律”探针上得分很高但“空间关系”探针上表现平平。这种不均衡本身就是重要信息说明模型对某些视觉概念的建模方式存在明显短板。在选型时如果业务场景偏重物理仿真类视频生成就应该优先看物理维度得分高的模型。还要关心探针任务难度区分度。如果一个探针任务所有模型都得 100 分说明任务太简单无法起到区分作用同理如果一个任务所有模型都得 0 分说明任务太难或者判定器存在问题。一个设计良好的 VGI-Bench 探针任务应该能让不同能力的模型得分呈现出合理梯度。把生成模型接入真实业务时要区分“评测通过率”和“端到端可用性”。探针任务考察的是模型在特定视觉逻辑上的表现真实业务场景往往更复杂由提示词设计、后处理、视频剪辑等多个环节共同决定最终效果。9. 常见问题与排查思路在 VGI-Bench 探针评测工程化过程中会遇到几类典型问题这里整理成排查表。问题现象可能原因排查方式解决方案所有模型在所有探针任务上都是 100%判定器逻辑过于宽松或测试任务描述过于简单先用人工会判定的标准视频测试判定器准确率收紧判定规则增加边界案例测试所有模型在所有探针任务上都是 0%判定器逻辑错误或生成结果与提示词完全脱节抽查生成视频文件确认模型真实输出单独调试生成模型和判定器分开验证同一模型重复评测得分波动较大视频生成模型采样随机性高重复次数不足增加重复生成次数固定随机种子每条提示词至少重复 5 到 10 次使用统计置信区间探针任务提示词被模型拒绝生成审核策略限制了一部分物理/动态场景描述检查模型 API 返回的拒绝原因调整提示词措辞或改用本地部署的开源模型判定器对某些视频给出了完全错误的判断VLM 判定器对特定物体或动作类别存在盲区分类统计判定器在不同对象上的准确率增加判定器人工抽检比例必要时改为规则判定评测耗时远超预期单条视频生成时间太长生成次数过多统计单次生成耗时估算总耗时缩减任务数量或使用更轻量的生成参数上述排查思路的核心原则是“分层排查”先确认生成模型输出正常再确认判定器判得准最后再看评测流程本身有没有统计缺陷。很多评测结果异常问题往往不在模型能力上而在评测管线某个不起眼的环节。10. 最佳实践与工程建议基于探针评测的工程实践经验给出七条建议。第一探针任务设计要做到“目标可判定”。每个探针任务在动手实现之前先问自己一个拥有完美视觉理解能力的模型一定能完成这个任务吗如果答案不是绝对的说明任务设计混入了无关因素需要重新拆分。第二判定器优先于生成器。开始大规模评测之前先把判定器在人工标注样本上验证一遍。如果判定器准确率达不到 95% 以上后续评测结论都不太可靠。这条建议说出来容易执行起来很多人会偷懒结果在评测结果异常时浪费了大量排查时间。第三评测库和评测 runner 分离。探针任务集应该独立于模型调用代码存在。这样当有新的视频生成模型出现时不需要修改评测任务直接调用评测 runner 就可以获得可对比的分数。任务集用 JSON 或 YAML 维护模型调用做适配层隔离。第四固定随机种子并记录日志。每条提示词生成时使用的随机种子、模型参数、采样参数都应该记进日志。如果后续发现某个探针任务的判定结果有争议还可以回到原始记录里复现。第五分维度报告不要只给总分。只给一个总分会掩盖模型能力的不均衡性。在实际评测报告中建议使用雷达图、分维度表格和案例分析组合展示。第六提示词和判定器要一起配套发布。探针任务的价值在于可复现。如果你只发布任务提示词不发布判定器的判定标准和调用方式别人就很难复用你的评测方案。第七警惕“评测集过拟合”。一旦某个探针任务集在社区中成为被广泛引用的标准后续视频生成模型训练时就有可能间接包含评测集相关数据。这种情况下探针的区分能力会下降。应对办法是持续扩充探针任务集保留一个“隐藏测试集”用于最终抽检。11. 对当前视频生成模型评测的思考回到开头的问题为什么视频生成模型的评测要从画质指标走向视觉智能探针底层原因在于视频生成模型的训练目标正在从“像素拟合”向“世界模拟”演变。当模型的生成能力足够强大评价标准就会从“生成是否真实”升级为“生成是否理解真实”。这几乎是技术演进的必然路径。文本生成领域已经走完了这个过程。早期语言模型评测看困惑度后来看 BLEU再到后来出现了 GLUE、SuperGLUE 这类能力导向的基准测试。每个基准测试的出现都对应着模型能力的一次跃迁。视频生成领域目前正处在类似节点的前夜。FVD 分数不再是评价模型优劣的唯一标准面向物理规律、空间逻辑、时序因果的探针评测正在被越来越多人关注。从这个角度看VGI-Bench 反映的不是某一家机构或者某个团队的单一工作而是一种评测范式转型的趋势。即便未来出现更新、更全面的评测体系探针评测“以特定任务探测模型内部能力”的底层思想也会被保留下来。对于普通开发者和研究者掌握探针评测的设计方法比死记某个榜单的数字更有长期价值。如果你正准备拿一个视频生成模型做实际项目建议从三个问题开始第一我的业务里哪些环节依赖模型的“视觉智能”而不是简单的“画质” 第二我能不能为这些环节设计一个可自动判定的探针任务 第三这个任务的判定结果能否预测模型在真实业务中的端到端表现把这三个问题想清楚你再去看 VGI-Bench 的评测设计就会很快理解每一类探针任务背后对应的是哪种实际业务风险。视频生成模型的评测本质上不是一个打分问题而是一个能力边界探测问题。理解这个视角比记住任何一组具体分数都更重要。 从画质到智能：探针评测如何评估视频生成模型的视觉理解能力
视频生成模型发展到现在大家关注的焦点已经不是“它能生成多清晰的画面”而是“它到底懂不懂自己在生成什么”。同样是让模型生成一段“猫从桌子跳下来”的视频有的模型能给出流畅合理的运动过程有的模型却会出现猫在空中翻跟头的诡异画面。这类差异暴露出的问题恰恰是现有很多评测指标回答不了的。VGI-Bench 这类以“探针”方式切入的视频生成模型视觉智能评估体系正是冲着这个痛点来的。这篇文章会讲清楚三件事为什么现在需要一个专门评测视频生成模型视觉智能的基准测试、探针评测和传统评测在方法论上有什么本质区别以及作为一个普通开发者或研究者你可以怎么理解和使用这套评测思路。1. 视频生成模型评测卡在哪里了如果只看近几年的视频生成模型论文会发现评测部分几乎形成了一套固定模板FVDFréchet Video Distance算一下、CLIP Score 算一下、再来几个主观打分结论就是“我们的方法比 baseline 好”。这套体系在模型能力还比较弱的时候是够用的因为那时候大家比的是谁生成的画面更清晰、更逼真。但当视频生成模型进入大规模扩散模型和 DiT 架构时代之后问题开始变得棘手。很多模型生成的画面已经足够逼真单张截图甚至能骗过人类的眼睛可一旦把视频连续播放或者让模型去完成一个需要“理解物体关系、运动规律、因果关系”的任务它就会暴露出物理世界认知能力的不足。一个很典型的场景是你用视频生成模型生成一个人拿起杯子喝水的视频。仔细观察中间几帧杯子可能先出现在手边然后突然瞬移到嘴边中间完全没有经典的运动轨迹。这种错误对 FVD 这类指标来说并不敏感因为 FVD 衡量的是生成视频分布和真实视频分布之间的特征距离它会把“杯子瞬移”当成合理的统计波动。这正是为什么需要 VGI-Bench——它不是为了再增加一套“打分标准”而是要回答一个更底层的问题视频生成模型在生成过程中是否表现出了对视觉世界的理解能力我倾向于把这种评测称为“能力探针”它不再只看模型输出的画面质量而是通过设计特定任务探测模型内部是否具备某种视觉认知能力。这和当年 NLP 领域从“BLEU 分数”走向“Benchmark 测试集”的路径非常相似。从技术演进的视角看视频生成模型的评测正在经历三个阶段评测阶段核心关注点代表指标主要局限第一阶段画质评测单帧/短片段清晰度PSNR、SSIM、FVD无法体现语义理解第二阶段文本对齐评测生成内容与提示词匹配度CLIP Score、T2V Metrics对时序和物理规则不敏感第三阶段视觉智能评测模型对世界运行规律的理解VGI-Bench 类任务评测设计难度高处于发展期这篇文章的读者如果你正在做视频生成模型的评测工作、研究视觉智能的评价方法论或者只是想搞清楚“市面上这些视频生成模型哪个真的更强”VGI-Bench 这套思路值得你花时间读完。2. 视觉智能到底是什么怎么评测先说概念。“视觉智能”和“视觉生成能力”是两码事。视频生成能力指的是模型能生成符合文本描述的动态画面视觉智能指的是模型在生成过程中是否具备关于物体、空间、时间、运动和因果关系的内部认知。举个例子。你让一个模型生成“篮球从高处掉落到地面然后弹起”的视频。生成能力强的模型可能输出一段画质精美、光线真实的视频但篮球落地后可能直接穿过地面消失或者弹起的高度毫无规律。而具备视觉智能的模型哪怕画质稍微弱一些也会生成符合重力规律的弹跳过程。前者是“画得漂亮”后者是“懂物理”。那这种“懂不懂”该怎么评测传统指标抓不住它主观评测又缺乏可复制性。VGI-Bench 采用的关键方法就是“探针”。“探针”这个词学术上叫 probe最初在神经网络可解释性研究里用得比较多。它的核心思路是不直接观察模型内部的隐层表示而是设计一些特定的输入或任务观察模型的输出行为从行为反推模型内部是否学到了某些概念或规则。在 VGI-Bench 这个场景下探针任务的设计逻辑通常是这样的首先选定一个可验证的视觉理解维度。比如物体运动轨迹、物体恒存性、空间位置关系、物理规律、时序逻辑、交互动作等。然后为这个维度设计一个可自动判定的生成任务。这里的“可自动判定”很重要——你不能靠人眼看视频打分因为那样成本高、主观性强、难以规模化。最后把模型生成的视频输入到另一个具备视觉理解能力的判定器里用规则化或模型化的方式判断是否满足预期的视觉逻辑。这种设计思路最巧妙的地方在于它把“生成模型是否理解视觉世界”这个问题转化成了“生成模型能否完成一系列需要视觉理解才能完成的任务”。前者难以直接回答后者则可以设计成标准化测试。从评测方法上讲探针可以分为两种类型。一种是“行为探针”就是直接测试输入输出行为看模型在特定任务上的表现另一种是“内部探针”需要访问模型内部表示这通常适用开源模型。VGI-Bench 如果要覆盖多种闭源模型大概率走的是行为探针路线因为不需要访问模型内部只需要定义输入、跑推理、判定输出即可。3. 为什么现有视频生成模型会在视觉智能上翻车要理解 VGI-Bench 的价值得分清视频生成模型在哪些环节容易暴露“智能不足”的问题。这里按我的观察梳理四个最常见的翻车场景。第一个是物体恒存性问题。一个物体被遮挡之后模型能不能记住它仍然存在很多视频生成模型无法处理这种情况。比如一个球滚到箱子后面再从另一侧滚出来中间的遮挡过程一旦超过几帧有些模型就会忘记球的存在或者让球在遮挡期间改变颜色、形状。这种错误本质上反映了模型缺乏物体持久性认知。第二个是物理规律问题。重力、碰撞、弹性、惯性这些在物理世界里再自然不过的规律视频生成模型经常学不好。原因在于训练数据里虽然包含了大量的物理视频但模型更多学会了统计相关性而不是物理因果模型。用统计方式拟合物理规律在训练分布覆盖的范围内表现不错一旦遇到训练集里不常见的情景组合就会产生离谱的错误。第三个是时间逻辑问题。视频天然是时间序列模型需要保证因果顺序正确。比如“先开门再进门”这个顺序不能颠倒。部分视频生成模型在这一块偶尔出错原因在于生成过程往往是从噪声逐步去噪出来的整个视频立方体时序上的一致性依赖注意力机制对跨帧关系的建模但注意力机制擅长捕捉局部相关性并不天然保证全局时间因果。第四个是空间关系问题。物体之间的相对位置关系比如“桌子左边放着一杯水”“杯子在书的前面”这种空间逻辑在中文文本描述中尤其容易出错。因为中文的空间关系表达比较灵活模型在文本编码阶段可能就理解了错误的语义然后生成阶段又把错误的语义视觉化。这些翻车场景用现有评测指标几乎很难被精确捕捉。FVD 看的是分布距离CLIP Score 看的是文本-视频的整体匹配度都无法把“球被遮挡后是否还存在”这类细粒度逻辑抽出来检查。VGI-Bench 的探针任务设置很大程度上就是围绕这些具体的认知维度来展开的。4. VGI-Bench 探针评测设计应该长什么样虽然我没法给出 VGI-Bench 官方测试集的全部细节但从“探针评测”的通用方法论出发可以把一套合理的 VGI-Bench 流程拆解成五个环节。首先是指标维度定义。先确定要评测哪些视觉智能维度通常包括物理规律理解、空间关系推理、时序一致性、物体交互逻辑、运动轨迹合理性、场景语义一致性等。每个维度需要定义清晰保证评测者之间能达成共识。其次是探针任务生成。每个维度都要设计成具体的生成任务。比如物理规律维度可以设计“小球从斜坡滚下、撞到障碍物后改变方向”这种明确需要物理理解的任务。任务本身要足够简洁确保一个真正具备视觉智能的模型应该能轻松完成而不是依赖复杂推理。这个设计原则是为了避免把“视觉智能”和“通用知识”混在一起。第三是自动判定机制。这是探针评测能否规模化的关键。常用的方式有两种基于规则判定和基于模型判定。基于规则判定适合空间位置、运动轨迹这类客观属性明确的场景比如检测物体的边界框是否穿越了不应该穿越的区域。基于模型判定适合更复杂的语义逻辑比如用视觉语言模型去判断生成视频是否符合某个逻辑描述。两种方式各有优劣规则判定可解释性强但灵活性差模型判定适应性强但需要防范判定器自身的误判。第四是多任务综合评分。单个任务只能反映一个维度的能力VGI-Bench 需要覆盖多个维度然后设计合理的聚合方式。这里最忌讳的是简单平均因为不同任务的难度并不相同。更合理的做法是分维度报告分数让使用者根据自身需求关注不同维度。第五是最小可评测样本量。探针测试任务需要保证统计显著性不能只生成一次视频就下结论。因为视频生成模型本身有随机性同一条提示词生成多次结果可能差异很大。通常需要重复生成 N 次统计正确率或者平均分。5. 用 Python 实现一个极简 VGI-Bench 探针评测脚本理解了原理之后下面用一段极简的 Python 代码演示 VGI-Bench 的探针评测工作流。这里不做完整实现而是带你跑通“定义探针任务-调用视频生成模型-自动判定结果”的最小闭环。# 文件路径probe_eval_demo.py 极简 VGI-Bench 风格探针评测示例 用于演示探针任务的设计与自动判定流程 from dataclasses import dataclass from typing import Callable, Dict, List dataclass class ProbeTask: 一个探针任务的基本结构 task_id: str dimension: str # 评测维度如 physical / spatial / temporal description: str # 任务描述 prompts: List[str] # 该任务对应的输入提示词 validator: Callable # 判断生成结果是否满足预期的函数 def generate_video(prompt: str, model_name: str demo_model) - dict: 调用视频生成模型生成视频。 在实际使用时这里应该替换为真实的模型推理代码例如调用 Sora、Kling、Runway 等模型的 API 或本地模型。 当前示例返回模拟结果用于演示流程。 return { model: model_name, prompt: prompt, video_path: foutputs/{model_name}_{abs(hash(prompt))}.mp4, # 真实场景中这里还会包含视频文件或其他必要信息 } def check_gravity(result: dict) - bool: 示例判定函数检查生成的视频是否满足重力规律。 真实实现中可以调用目标检测模型提取物体轨迹 然后检测轨迹是否符合重力加速度曲线。 这里用模拟值代替。 # 模拟判定真实场景请替换为轨迹检测逻辑 return result.get(gravity_ok, True) def check_spatial_order(result: dict) - bool: 示例判定函数检查生成视频中物体空间关系是否正确。 可以借助目标检测模型输出物体位置再判断相对关系。 return result.get(spatial_ok, True) # 构造探针任务 physics_probe ProbeTask( task_idprobe_001, dimensionphysical, description检测生成视频中的重力规律, prompts[ 一个小球从桌面边缘掉落垂直落到地面, 一个苹果从树上掉下来砸在地面上弹了一下 ], validatorcheck_gravity, ) spatial_probe ProbeTask( task_idprobe_002, dimensionspatial, description检测生成视频中的空间位置关系, prompts[ 一杯水放在一本书的左边镜头缓慢推近, 一只猫坐在一张椅子的下方 ], validatorcheck_spatial_order, ) PROBES [physics_probe, spatial_probe] def run_probe_evaluation(tasks: List[ProbeTask], model_names: List[str], repeat: int 3) - Dict[str, Dict[str, float]]: 运行探针评测。 对每个任务使用多条提示词每条提示词重复生成 repeat 次统计通过率。 results {} for model in model_names: model_result {} for task in tasks: pass_count 0 total_count 0 for prompt in task.prompts: for _ in range(repeat): # 生成视频 video generate_video(prompt, model_namemodel) total_count 1 # 调用任务自身的判定器 if task.validator(video): pass_count 1 accuracy pass_count / total_count model_result[task.dimension] round(accuracy, 4) results[model] model_result return results if __name__ __main__: output run_probe_evaluation(PROBES, [model_A, model_B]) for model, scores in output.items(): print(f模型: {model}) for dim, score in scores.items(): print(f 维度 {dim}: 通过率 {score:.2%})运行这个脚本预期输出如下$ python probe_eval_demo.py 模型: model_A 维度 physical: 通过率 100.00% 维度 spatial: 通过率 100.00% 模型: model_B 维度 physical: 通过率 100.00% 维度 spatial: 通过率 100.00%因为判定函数里写死了返回 True你会看到所有模型的通过率都是 100%。把这个示例应用到你自己的项目中时需要替换两处核心逻辑一处是generate_video接上真实的模型推理接口另一处是各个check_*函数接上真正能够分析视频内容的算法或模型。如果判定结果全部为 100% 或者全部为 0%先不要怀疑模型能力先检查判定函数是否工作正常。常见做法是先用人工标注好的视频片段测试判定器确认判定器本身的准确率达到合理水平再对生成模型做批量评测。6. 用视觉语言模型实现自动化判定器探针评测里判定器的重要性不亚于生成模型本身。在真实 VGI-Bench 评测中很多维度不是用规则就能判定的比如“视频是否符合‘猫先跳到桌子上然后坐下来’这个描述”这种时候可以考虑用视觉语言模型作为判定器。下面给出一个用视觉语言模型做判定的思路伪代码仅用于说明流程。# 文件路径vlm_validator_demo.py 使用视觉语言模型VLM作为探针判定器的思路演示 from typing import Dict def validate_with_vlm(video_path: str, expected_logic: str) - Dict[str, any]: 思路将视频帧序列 预期逻辑描述输入给 VLM 让 VLM 以结构化 JSON 的形式返回判断结果。 # 1. 从视频中抽帧 # frame_paths extract_frames(video_path, sample_rate1) # 2. 构造 VLM 输入 user_query f 请观看以下视频帧判断视频内容是否符合这个逻辑描述 {expected_logic} 请以 JSON 格式返回判断结果格式如下 {{ is_match: true/false, reason: 简要说明判断依据 }} # 3. 调用 VLM API 或本地模型 # response vlm_api.infer(frame_paths, user_query) # 这里使用模拟返回 response { is_match: True, reason: 视频中猫先跳到桌面然后坐下的动作顺序正确。 } return response if __name__ __main__: video outputs/sample_cat.mp4 logic 猫先跳到桌子上然后坐下来 result validate_with_vlm(video, logic) print(result)在实际评测过程中使用 VLM 做判定器有一个必须注意的坑VLM 自身对视频内容的理解能力并不是100%准确的。如果 VLM 判定出错整个评测结果就会失真。所以当用 VLM 做判定时需要做两件额外的事情一是人工抽检一部分判定结果确认 VLM 判定的准确率二是对判定事件重复多次投票降低随机误差。这个设计也体现了“探针”方法论的另一层价值它既评测了视频生成模型也在一定程度上评测了作为判定器的视觉理解模型。如果你在做一个视频生成模型的横向对比评测把 VLM 判定器的置信度分开报告对使用者会更有参考价值。7. 视频生成模型本地部署对探针评测的影响在视频生成模型领域“本地部署”这几个字非常关键。VGI-Bench 要跑测试集不能只依赖几个云端模型 API。模型如果只能通过 API 访问你的评测就得受限于别人的限流策略、成本和网络延迟。而且闭源模型可能因为提示词审核机制直接拒绝部分探针任务的生成请求这样评测的覆盖度就会大打折扣。本地部署的模型通常来自开源社区比如基于 Stable Video Diffusion 衍生出的改进模型、Open-Sora 系列或者其他开源视频扩散模型。这些模型可以拉下来跑在本地 GPU 上评测过程完全可控。本地部署对探针评测的意义体现在三个方面第一是可重复性。你可以在完全相同的硬件、依赖版本、随机种子条件下多次运行探针任务确保评测结果可复现。这对学术研究尤其重要。第二是可定制性。你可以修改模型的推理流程例如改变采样步数、使用不同的 classifier-free guidance 权重观察这些因素对视觉智能表现的影响。这种“干预式”实验只能通过本地部署实现。第三是可解释性。如果模型在某个探针任务上失败你可以进一步检查模型中间层的注意力权重定位是文本编码的语义理解出了问题还是去噪过程中的时序建模出了问题。不过本地部署视频生成模型的硬件门槛不低。以当前主流的开源视频生成模型为例显存需求普遍在 24GB 以上生成一段几秒钟的视频通常需要几分钟到十几分钟。这意味着在跑 VGI-Bench 探针评测时需要提前估算总耗时合理安排生成批次和参数。这里给一个保守的算力估算方式假设评测集有 50 个探针任务每个任务 5 条提示词每条提示词重复生成 3 次总生成次数就是 750 次。如果单条视频生成耗时 3 分钟总耗时约 37.5 小时。在实际评测之前先跑一个小规模子集估算单条生成耗时再决定是否缩减任务量。8. 探针评测结果怎么解读探针评测跑完之后得到的不是简单一个分数而是一组细粒度的能力画像。读结果时需要注意以下几点。同一个模型的各维度得分通常参差不齐。比如某个模型可能在“物理规律”探针上得分很高但“空间关系”探针上表现平平。这种不均衡本身就是重要信息说明模型对某些视觉概念的建模方式存在明显短板。在选型时如果业务场景偏重物理仿真类视频生成就应该优先看物理维度得分高的模型。还要关心探针任务难度区分度。如果一个探针任务所有模型都得 100 分说明任务太简单无法起到区分作用同理如果一个任务所有模型都得 0 分说明任务太难或者判定器存在问题。一个设计良好的 VGI-Bench 探针任务应该能让不同能力的模型得分呈现出合理梯度。把生成模型接入真实业务时要区分“评测通过率”和“端到端可用性”。探针任务考察的是模型在特定视觉逻辑上的表现真实业务场景往往更复杂由提示词设计、后处理、视频剪辑等多个环节共同决定最终效果。9. 常见问题与排查思路在 VGI-Bench 探针评测工程化过程中会遇到几类典型问题这里整理成排查表。问题现象可能原因排查方式解决方案所有模型在所有探针任务上都是 100%判定器逻辑过于宽松或测试任务描述过于简单先用人工会判定的标准视频测试判定器准确率收紧判定规则增加边界案例测试所有模型在所有探针任务上都是 0%判定器逻辑错误或生成结果与提示词完全脱节抽查生成视频文件确认模型真实输出单独调试生成模型和判定器分开验证同一模型重复评测得分波动较大视频生成模型采样随机性高重复次数不足增加重复生成次数固定随机种子每条提示词至少重复 5 到 10 次使用统计置信区间探针任务提示词被模型拒绝生成审核策略限制了一部分物理/动态场景描述检查模型 API 返回的拒绝原因调整提示词措辞或改用本地部署的开源模型判定器对某些视频给出了完全错误的判断VLM 判定器对特定物体或动作类别存在盲区分类统计判定器在不同对象上的准确率增加判定器人工抽检比例必要时改为规则判定评测耗时远超预期单条视频生成时间太长生成次数过多统计单次生成耗时估算总耗时缩减任务数量或使用更轻量的生成参数上述排查思路的核心原则是“分层排查”先确认生成模型输出正常再确认判定器判得准最后再看评测流程本身有没有统计缺陷。很多评测结果异常问题往往不在模型能力上而在评测管线某个不起眼的环节。10. 最佳实践与工程建议基于探针评测的工程实践经验给出七条建议。第一探针任务设计要做到“目标可判定”。每个探针任务在动手实现之前先问自己一个拥有完美视觉理解能力的模型一定能完成这个任务吗如果答案不是绝对的说明任务设计混入了无关因素需要重新拆分。第二判定器优先于生成器。开始大规模评测之前先把判定器在人工标注样本上验证一遍。如果判定器准确率达不到 95% 以上后续评测结论都不太可靠。这条建议说出来容易执行起来很多人会偷懒结果在评测结果异常时浪费了大量排查时间。第三评测库和评测 runner 分离。探针任务集应该独立于模型调用代码存在。这样当有新的视频生成模型出现时不需要修改评测任务直接调用评测 runner 就可以获得可对比的分数。任务集用 JSON 或 YAML 维护模型调用做适配层隔离。第四固定随机种子并记录日志。每条提示词生成时使用的随机种子、模型参数、采样参数都应该记进日志。如果后续发现某个探针任务的判定结果有争议还可以回到原始记录里复现。第五分维度报告不要只给总分。只给一个总分会掩盖模型能力的不均衡性。在实际评测报告中建议使用雷达图、分维度表格和案例分析组合展示。第六提示词和判定器要一起配套发布。探针任务的价值在于可复现。如果你只发布任务提示词不发布判定器的判定标准和调用方式别人就很难复用你的评测方案。第七警惕“评测集过拟合”。一旦某个探针任务集在社区中成为被广泛引用的标准后续视频生成模型训练时就有可能间接包含评测集相关数据。这种情况下探针的区分能力会下降。应对办法是持续扩充探针任务集保留一个“隐藏测试集”用于最终抽检。11. 对当前视频生成模型评测的思考回到开头的问题为什么视频生成模型的评测要从画质指标走向视觉智能探针底层原因在于视频生成模型的训练目标正在从“像素拟合”向“世界模拟”演变。当模型的生成能力足够强大评价标准就会从“生成是否真实”升级为“生成是否理解真实”。这几乎是技术演进的必然路径。文本生成领域已经走完了这个过程。早期语言模型评测看困惑度后来看 BLEU再到后来出现了 GLUE、SuperGLUE 这类能力导向的基准测试。每个基准测试的出现都对应着模型能力的一次跃迁。视频生成领域目前正处在类似节点的前夜。FVD 分数不再是评价模型优劣的唯一标准面向物理规律、空间逻辑、时序因果的探针评测正在被越来越多人关注。从这个角度看VGI-Bench 反映的不是某一家机构或者某个团队的单一工作而是一种评测范式转型的趋势。即便未来出现更新、更全面的评测体系探针评测“以特定任务探测模型内部能力”的底层思想也会被保留下来。对于普通开发者和研究者掌握探针评测的设计方法比死记某个榜单的数字更有长期价值。如果你正准备拿一个视频生成模型做实际项目建议从三个问题开始第一我的业务里哪些环节依赖模型的“视觉智能”而不是简单的“画质” 第二我能不能为这些环节设计一个可自动判定的探针任务 第三这个任务的判定结果能否预测模型在真实业务中的端到端表现把这三个问题想清楚你再去看 VGI-Bench 的评测设计就会很快理解每一类探针任务背后对应的是哪种实际业务风险。视频生成模型的评测本质上不是一个打分问题而是一个能力边界探测问题。理解这个视角比记住任何一组具体分数都更重要。