视频生成模型发展到现在，大家关注的焦点已经不是“它能生成多清晰的画面”，而是“它到底懂不懂自己在生成什么”。同样是让模型生成一段“猫从桌子跳下来”的视频，有的模型能给出流畅合理的运动过程，有的模型却会出现猫在空中翻跟头的诡异画面。这类差异暴露出的问题，恰恰是现有很多评测指标回答不了的。
VGI-Bench 这类以“探针”方式切入的视频生成模型视觉智能评估体系，正是冲着这个痛点来的。这篇文章会讲清楚三件事：为什么现在需要一个专门评测视频生成模型视觉智能的基准测试、探针评测和传统评测在方法论上有什么本质区别，以及作为一个普通开发者或研究者，你可以怎么理解和使用这套评测思路。
1. 视频生成模型评测，卡在哪里了
如果只看近几年的视频生成模型论文，会发现评测部分几乎形成了一套固定模板：FVD（Fré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": f"outputs/{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_id="probe_001", dimension="physical", description="检测生成视频中的重力规律", prompts=[ "一个小球从桌面边缘掉落，垂直落到地面", "一个苹果从树上掉下来，砸在地面上弹了一下" ], validator=check_gravity, ) spatial_probe = ProbeTask( task_id="probe_002", dimension="spatial", description="检测生成视频中的空间位置关系", prompts=[ "一杯水放在一本书的左边，镜头缓慢推近", "一只猫坐在一张椅子的下方" ], validator=check_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_name=model) 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_rate=1) # 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 的评测设计，就会很快理解每一类探针任务背后对应的是哪种实际业务风险。视频生成模型的评测，本质上不是一个打分问题，而是一个能力边界探测问题。理解这个视角，比记住任何一组具体分数都更重要。
