最近评测视频生成模型时发现一个问题:很多模型生成的画面已经非常流畅,但如果你追问它“画面里的球为什么往左滚”,它大概率答不上来。这暴露了生成能力与理解能力之间的断层。视频生成模型到底有没有真正“看懂”自己生成的视频?VGI-Bench 就是用来回答这类问题的评测基准。
VGI-Bench 的思路可以理解为“探针式评测”:给视频生成模型输入一段视频,再注入一组专门设计的视觉理解问题,通过回答正确率来判断模型在动态场景、时序关系、物理常识等维度上是否具备视觉智能。它不关心画面好不好看,只关心模型怎么理解画面内容。
如果你正在做视频生成模型选型、模型能力对比,或者想搞清楚本地部署的视频模型除了生成之外还能不能承担视觉推理任务,这篇文章可以收藏。下文会拆解 VGI-Bench 的评测设计思路、本地部署流程、探针任务实测方式、批量评测与结果分析方法,最后给出常见问题和排查建议。
1. VGI-Bench 核心能力速览
| 能力项 | 说明 |
|---|---|
| 项目类型 | 视频生成模型视觉智能评测基准 |
| 评测对象 | 视频生成模型、视频理解模型、多模态大模型 |
| 评测方式 | 输入视频片段 + 探针问题,自动化计算回答正确率 |
| 探针任务 | 动态场景理解、目标跟踪、时序推理、物理常识、因果判断、空间关系等 |
| 是否支持本地部署 | 通常可作为 Python 脚本运行,具体以项目仓库的 README 为准 |
| 启动方式 | 命令行 / Python API |
| 是否支持批量任务 | 支持按目录批量加载测试视频,可批量输出结果 |
| 是否支持 API | 取决于模型部署方式,评测脚本本身一般以本地模型为主要测试对象 |
| 推荐硬件 | 建议配备 NVIDIA GPU,显存需按被测模型参数量评估 |
| 输出形式 | 分任务正确率、失败样例、可导出的结果文件 |
| 适合读者 | 视频模型开发者、评测同学、多模态大模型应用工程师 |
从材料看,VGI-Bench 的核心价值不是提供一个“分数排行榜”,而是通过标准化探针任务把模型的能力边界量化出来。对做模型选型的人来说,它比纯看生成样例更接近模型真实水平。
2. 为什么需要“探针式”视觉智能评测
视频生成模型正在从纯粹的像素生成器演变为一种“视觉基础模型”。用户不仅让它生成内容,还希望它理解内容:判断视频中的物体运动是否合理、预测下一帧会发生什么、回答关于场景的问题。但现有评测体系并没有跟上这种变化。
传统视频生成评测主要关注以下指标:
- 画面质量:FVD、IS、PSNR、SSIM 等。
- 文本对齐:CLIP Score 等。
- 运动质量:动态一致性、时间连续性。
这些指标能证明模型生成的画面逼真,却不能证明模型理解画面。一个模型完全可以生成一个球从斜坡滚落的视频,却不知道重力方向,也不清楚球撞击障碍物后应该弹向哪边。
这正是 VGI-Bench 这类“视觉智能探针”存在的意义。它把评测粒度从“整段视频像不像”下沉到“具体视觉推理问题答得对不对”。探针任务可以看作是视觉版的“单元测试”:每个任务探测一个具体能力维度,汇总后形成模型的能力剖面。
这个思路和智能车视觉组有相似之处:视觉组不只看摄像头能不能采图,而是看算法能不能识别车道、锥桶、障碍物,再据此做决策。视频生成模型的视觉智能也是一样,需要拆分成具体能力项来逐一验证。
从实际使用角度来看,探针式评测比人工看视频更高效。一组探针任务可以在短时间内跑完,输出结构化结果,方便横向比较不同模型。这正是工程团队在选型和验收阶段最需要的工具。
3. VGI-Bench 评测设计拆解
3.1 探针任务类型
“探针”这个称呼借用了硬件测试中的概念。探针卡通过接触芯片的引脚来测试电路功能,VGI-Bench 则通过一系列视觉问题来测试模型的视觉认知功能。探针任务可以从以下维度展开:
| 任务维度 | 评测内容 | 举例 |
|---|---|---|
| 动态目标感知 | 目标是否出现、移动方向是否合理 | 视频中是否有小车从右向左行驶 |
| 目标维持 | 物体消失后是否仍保持存在性判断 | 球被遮挡后,它是否还在运动 |
| 物理常识 | 重力、碰撞、惯性等物理规则 | 被推倒的杯子是否往下掉落 |
| 时间顺序 | 事件先后关系是否成立 | 是先听到声音还是先看到画面 |
| 空间关系 | 物体的相对位置是否准确 | 椅子是在桌子左边还是右边 |
| 因果关系 | 事件之间的因果是否成立 | 风吹过之后树叶是否飘动 |
每种任务又可以根据难度分成多级。初级任务只要求判断“是/否”,高级任务要求从多个候选中选出正确答案,再高一级则要求模型生成一句解释。不同难度组合可以评估模型在浅层感知和深层推理上的差异。
3.2 评测流程
VGI-Bench 的典型评测流程如下:
- 准备测试视频集,每个视频对应一组探针问题。
- 加载被测模型。模型既可以是需要本地推理的生成模型,也可以是已经部署好的 API 接口服务。
- 把视频帧序列和探针问题组织成模型可处理的输入。
- 模型输出答案,评测脚本与标准答案比对。
- 按任务类型统计正确率,输出结构化结果。
整个流程的关键在于问题生成和答案判定。问题需要被设计成“无法靠画面统计直接蒙对”,否则就退化成普通的视频标签分类。答案判定则需要同时支持精确匹配和语义匹配,避免模型答对了但措辞不同被误判为错误。
3.3 与人工评测的结合
自动评测的最大优势是效率,但纯自动评分也可能出错。VGI-Bench 类的评测工具通常会保留人工复核环节:把自动评测不通过的样本导出,让人工标注者判断是模型答错、题目本身有歧义还是视频标注有误。这种“自动化初筛 + 人工复核”的组合,在实践中比纯自动化更可靠。
4. VGI-Bench 适用场景与使用边界
4.1 适合哪些场景
- 模型选型:在多个视频生成模型之间做横向对比,量化判断哪个模型理解能力更强。
- 版本迭代验收:每次更新模型后跑一遍探针任务,确认能力有没有回退。
- 能力边界探测:找出模型在哪类视觉推理任务上最薄弱,为后续训练数据收集提供方向。
- 论文实验:作为视频生成模型评测的补充基准,用于展示模型视觉智能水平。
4.2 不适合哪些场景
- 不建议把 VGI-Bench 当成通用视频问答产品。它是评测工具,不是面向最终用户的应用。
- 不建议用它替代端到端的业务效果评测。实际场景中的准确率还取决于模型部署方式、提示词工程和后处理逻辑。
- 如果被测模型只做画面生成,没有开放任何视觉理解接口,VGI-Bench 的探针问题就无法直接注入,需要额外接一个视觉问答模型来完成评测。
4.3 使用边界与合规提醒
VGI-Bench 涉及视频素材和模型输出,使用时需要确认以下几点:
- 测试视频是否具备合法版权或已获得授权,不得使用未授权的影视、短视频、人物肖像素材进行公开评测。
- 如果测试过程中涉及真实人物画面,需要确认肖像授权。
- 评测结果如果对外发布,建议只公开汇总数据和脱敏样例,避免泄露敏感视频内容。
- 本地部署模型时,注意检查模型权重文件和评测数据的许可证协议。
5. VGI-Bench 本地部署:环境准备
VGI-Bench 的部署方式取决于被测模型和测试脚本的依赖关系,但一般遵循“Python + PyTorch + GPU 推理”的模式。环境准备可以按下面的检查清单逐项确认。
5.1 操作系统
推荐使用 Linux(Ubuntu 20.04 以上)。Windows 也可以跑,但需要在驱动和 CUDA 环境上多花一些时间。macOS 可以运行纯 CPU 推理,但评测速度会明显变慢,不建议用于大规模批量评测。
5.2 Python 环境
建议使用 Python 3.9 或 3.10。项目依赖通常包括:
- PyTorch
- Transformers
- OpenCV
- NumPy
- 评测解析相关的 NLP 工具库
如果被测模型是本地权重,还需要安装模型对应的推理库。例如:
- 视频生成类模型可能依赖 diffusers、ComfyUI 等。
- 视频理解类模型可能依赖 transformers、modeling 相关代码。
5.3 GPU 与驱动
强烈建议准备 NVIDIA GPU,并确认驱动已安装完成。CUDA 版本需要与 PyTorch 版本匹配。
nvidia-smi通过上面的命令可以查看显卡型号和驱动信息。然后根据 PyTorch 官方要求安装对应 CUDA 版本:
# 以 PyTorch 2.x 为例,具体版本号以 PyTorch 官网为准 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118如果需要减省配置时间,可以直接使用全局 OCR / 视觉模型依赖的大型整合镜像,或在 conda 中创建独立环境。
conda create -n vgibench python=3.10 -y conda activate vgibench pip install -r requirements.txt5.4 磁盘空间
磁盘空间主要被三部分占用:
- 评测脚本和依赖库:通常几 GB。
- 被测模型权重:从几 GB 到几十 GB 不等。
- 测试视频集:取决于视频数量和分辨率。
建议预留至少 50GB 可用空间,避免跑一半磁盘写满。
5.5 端口占用提醒
如果被测模型通过本地 API 方式提供服务,评测脚本需要访问本地端口。启动前检查端口是否被占用:
# 检查 8000 端口是否被占用,实际端口以模型服务配置为准 lsof -i :8000端口冲突时,可以换用其他端口启动模型服务,并在评测脚本中配置对应的服务地址。
6. 安装与启动评测流程
6.1 获取评测项目
VGI-Bench 项目代码一般托管在 GitHub 或 Gitee 上。克隆代码时建议固定到一个版本,避免仓库更新导致接口变化。
git clone https://github.com/your-repo/VGI-Bench.git cd VGI-Bench如果网络不稳定,可以下载源码压缩包手动解压。解压后的目录一般包含:
- datasets:测试视频与标注文件目录。
- scripts:评测脚本目录。
- configs:配置文件目录。
- docs:说明文档。
- README.md:项目说明。
6.2 安装依赖
pip install -r requirements.txt有些项目会附带 setup.py 或 pyproject.toml,此时可以执行:
pip install -e .这个命令会把评测脚本安装为本地包,后续无论在哪个目录下都能调用命令行工具。
6.3 准备测试数据
VGI-Bench 需要测试视频和对应的标注文件。项目自带示例数据时,可以直接用示例数据跑通流程。如果需要自定义测试集,需要按照项目要求的格式组织视频和问题标注。
以常见的评测格式为例:
datasets/ videos/ video_001.mp4 video_002.mp4 annotations/ video_001.json video_002.json单个视频对应的 JSON 标注文件内容,通常包含视频信息、探针问题和标准答案:
{ "video_path": "./datasets/videos/video_001.mp4", "fps": 24, "questions": [ { "question": "视频中蓝色小球最终滚向了哪个方向?", "options": ["A. 左侧", "B. 右侧", "C. 前方", "D. 静止不动"], "answer": "B", "task_type": "physical_common_sense" } ] }标注格式以项目实际为准,这里只是演示常见结构。
6.4 启动评测
跑通评测的基本命令一般如下:
python run_eval.py \ --config configs/eval_config.yaml \ --model_path /path/to/your/model \ --data_dir ./datasets \ --output_dir ./outputs \ --device cuda:0如果没有现成的 run_eval.py,也可以直接用 Python API 方式加载评测器:
from vgibench.evaluator import Evaluator from vgibench.models import load_model model = load_model("your-model-name", device="cuda:0") evaluator = Evaluator(model) result = evaluator.run(data_dir="./datasets") print(result.summary()) result.export("outputs/result.json")具体 API 名称和参数需要按项目文档调整。第一次运行时建议先用 2 到 3 个视频小批量测试,确认脚本能跑通后再全量执行。
7. 探针任务实测:从输入到结果
7.1 基础理解能力测试
测试目的:确认模型能对视频内容做出基础判断。
输入:一段包含球体运动的 4 秒视频。探针问题为“视频中是否存在一个圆形物体在运动?”模型需要回答“是”或“否”。
运行方式:通过评测脚本传入视频路径和问题模板。
预期结果:模型回答“是”,脚本判定为正确。
判断标准:正确率高于随机水平。这类基础问题如果模型都答不对,基本上可以认为该模型不擅长视频理解。
常见失败原因:
- 模型只支持文本输入,不支持视频输入。
- 视频帧采样数太少,模型没有捕获到运动信息。
- 问题模板与被测模型的提示词格式不匹配。
7.2 运动方向与空间关系测试
测试目的:检验模型对物体运动方向和空间布局的判断能力。
输入:视频中一个小车从画面左侧驶向右侧。探针问题为“小车在画面中的运动方向是什么?”
操作步骤:
- 把视频解码为帧序列。
- 将关键帧和问题一起组成模型输入。
- 收集模型输出。
- 与标准答案比对。
预期结果:模型能输出“从左向右”或等价的描述。
如果模型输出“车辆静止”或“从右向左”,说明模型在运动方向感知上存在明显问题。此时需要确认是采样帧不连续导致信息丢失,还是模型本身空间推理能力不足。
7.3 物理常识与因果推理测试
测试目的:验证模型是否理解重力、惯性、碰撞等物理规律。
输入:球从斜坡上滚下,撞击一个小木块,木块被弹开。探针问题为“视频中的球撞击木块后,木块发生了什么?”
这类任务模型很难靠画面统计直接蒙对,需要真正理解视频中的因果链。比较理想的结果是模型回答“木块向右移动”。如果模型回答“木块消失”或者“木块没有移动”,说明模型可能只关注了局部帧,没有建立跨帧的因果推理。
排查建议:
- 增加输入帧数,确保模型能看到碰撞瞬间。
- 把问题拆成更细的子问题,例如先问“球是否接触到了木块”,再问“木块是否发生了位移”。
- 检查模型上下文长度限制,更长的视频可能需要截断,截断策略会影响因果推理结果。
7.4 目标持久性与遮挡测试
测试目的:检验模型在目标被遮挡后是否仍能保持对目标的认知。
输入:小球滚入箱子后面,过两秒后从另一侧滚出。探针问题为“小球被箱子遮挡后,是否还在继续运动?”
人类的视觉系统可以保持目标存在性,但视觉模型经常在目标被遮挡后直接失去目标。如果模型在这类任务上失败,说明它依赖的是“看得见才判断存在”的浅层特征,而不是真正建立了目标的运动轨迹模型。
判断标准:理想回答是“是,小球继续运动并从另一侧出现”。如果模型回答“小球消失了”,说明目标持久性建模不足。
7.5 综合能力雷达图
跑完所有探针任务后,VGI-Bench 会把各任务的正确率汇总,形成类似下面的输出:
| 任务维度 | 正确率 | 样本数 |
|---|---|---|
| 动态目标感知 | 82.4% | 500 |
| 目标维持 | 68.2% | 500 |
| 物理常识 | 55.6% | 500 |
| 时间顺序 | 74.3% | 500 |
| 空间关系 | 79.1% | 500 |
| 因果关系 | 48.9% | 500 |
上面的数字只是演示格式,不代表 VGI-Bench 的实测结果。实际数值请以你本机跑出的结果为准。这样一张表格比单独看几个生成样例更能说明问题:哪个维度是短板、哪个维度已经满足业务需求,一目了然。
7.6 失败样例导出
评测脚本通常支持导出失败样例,便于后续分析。输出可以按以下结构组织:
outputs/ result.json failures/ physical_common_sense/ video_001_question_02.json video_003_question_07.json causality/ video_002_question_04.json每个失败样例文件保存输入视频路径、探针问题、模型答案、标准答案和模型推理日志。分析失败样例时,重点区分以下情况:
- 模型答错。
- 题目有歧义,标准答案不唯一。
- 视频标注错误。
- 帧采样导致信息丢失。
只有第一种情况才真正算模型能力缺陷,其余情况说明评测集本身需要清洗。
8. 批量评测与结果导出
8.1 批量任务设计
VGI-Bench 的批量评测通常采用“目录扫描 + 逐视频评测 + 结果聚合”的方式。评测脚本遍历数据集目录,对每个视频执行探针任务,最后把结果汇总成一份报告。
python run_eval.py \ --config configs/eval_config.yaml \ --data_dir ./datasets \ --output_dir ./outputs \ --batch_size 4batch_size 控制并发评测的视频数量。并发数过高会占用大量显存,过低则评测速度慢。建议从 batch_size=1 开始,跑通后再逐步加大,观察显存占用和推理速度变化。
8.2 结果导出格式
评测结果建议同时导出 JSON 和 CSV 两种格式,便于程序分析和表格查看。
JSON 结果示例:
{ "total_videos": 100, "total_questions": 600, "overall_accuracy": 0.712, "task_split": { "dynamic_perception": { "accuracy": 0.824, "correct": 82, "total": 100 }, "physical_common_sense": { "accuracy": 0.556, "correct": 55, "total": 100 } } }CSV 结果适合用 Excel 打开:
task_type,question,model_answer,ground_truth,is_correct,video_path dynamic_perception,视频中是否存在圆形物体,是,是,True,./datasets/videos/video_001.mp4 physical_common_sense,球撞击木块后木块发生了什么,木块消失,木块向右移动,False,./datasets/videos/video_002.mp48.3 失败重试策略
批量评测中偶尔会出现单条任务超时、GPU 显存溢出、模型推理异常等问题。稳妥的做法是:评测脚本支持断点续跑,已完成的样本不重复执行。
重试时也建议先记录失败原因再重试。显存溢出类的失败重试可能仍然失败,更有效的做法是降低并发数、减少输入帧数或缩小视频分辨率。超时类的失败则可以适当加大超时时间后重试。
8.4 Python 批量调用示例
如果评测脚本没有现成的批量命令,可以自己写一个遍历逻辑:
import json import os from vgibench.evaluator import Evaluator evaluator = Evaluator(model) video_dir = "./datasets/videos" output_dir = "./outputs" all_results = [] for video_name in sorted(os.listdir(video_dir)): if not video_name.endswith(".mp4"): continue video_path = os.path.join(video_dir, video_name) try: result = evaluator.eval_single_video(video_path) all_results.append(result) except Exception as e: all_results.append({ "video_path": video_path, "exception": str(e), }) with open(os.path.join(output_dir, "all_results.json"), "w", encoding="utf-8") as f: json.dump(all_results, f, ensure_ascii=False, indent=2)这段代码只是一个通用模板,实际运行时需要根据评测项目的 API 做适配。
9. 资源占用与性能观察
9.1 显存占用观察方法
评测过程中的显存占用主要取决于被测模型的大小和输入视频的帧数。同一个模型,输入 8 帧和输入 32 帧的显存占用可能相差数倍。
观察显存可以使用:
watch -n 1 nvidia-smi在评测脚本运行时持续观察,重点关注:
- 显存占用峰值。
- 多个视频并行评测时是否出现显存溢出。
- 长时间运行时显存是否被逐步占满、有没有释放。
9.2 影响性能的关键因素
| 因素 | 影响程度 | 说明 |
|---|---|---|
| 模型参数量 | 高 | 模型越大,单次推理耗时越长 |
| 输入帧数 | 高 | 帧数增加一倍,显存和耗时通常增加一倍以上 |
| 视频分辨率 | 高 | 分辨率越高,视觉编码耗时越明显 |
| 问题长度 | 中 | 长问题会让文本编码和生成阶段变慢 |
| 并发数 | 中 | 并发可以提高吞吐,但受显存上限约束 |
| 是否使用半精度 | 中 | fp16 通常比 fp32 节省一半显存 |
9.3 降低资源占用的方法
- 使用半精度(fp16 或 bf16)加载模型。
- 缩小输入视频的分辨率到 320 或 256 像素。
- 减少采样帧数,优先保留运动变化最明显的关键帧。
- 显存不足时降低 batch_size,不要同时评测多个视频。
- 如果被测模型本身过大,可以先把视频预处理成特征向量,再加载轻量级理解模型完成探针任务。
9.4 端口与进程残留
如果被测模型通过本地服务方式运行,评测结束后要记得关闭服务进程。否则下一次评测启动时可能遇到端口冲突。
# 找到占用 8000 端口的进程,PID 以实际输出为准 lsof -i :8000 # 结束该进程,谨慎使用,避免误杀 kill -9 PID更稳妥的方式是让评测脚本在启动时自动寻找可用端口,并把端口号写入配置文件。
10. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 评测脚本运行时报模块不存在 | 依赖没有完整安装 | 检查 pip list,确认依赖包版本 | 重新执行 pip install -r requirements.txt |
| CUDA 相关报错 | 显卡驱动与 PyTorch 版本不匹配 | 运行 python -c "import torch; print(torch.cuda.is_available())" | 安装与驱动匹配的 CUDA 版 PyTorch |
| 视频无法解码 | 视频编码格式不支持 | 用 OpenCV 读取测试帧,查看是否报错 | 使用 ffmpeg 转码为标准 H.264 MP4 |
| 显存溢出 | 输入帧数过多或 batch 过大 | 查看 nvidia-smi 显存占用 | 降低帧数、分辨率或 batch_size |
| 模型输出为空 | 提示词格式与模型不匹配 | 打印请求参数和模型返回 | 调整提示词模板,增加输出长度限制 |
| 评测结果全部相同 | 模型没有接入视频输入,只用了文本先验 | 检查模型加载方式,确认视频是否真正传入 | 换成支持视频输入的多模态模型 |
| 多次运行结果不一致 | 模型生成阶段存在随机采样 | 设置随机种子和温度参数 | 固定随机种子,使用确定性解码 |
| 端口被占用 | 上一次服务未关闭 | 检查 lsof -i :8000 | 关闭旧进程或切换端口 |
| 批量任务卡住无日志 | 某个样品超时 | 查看模型推理端日志 | 增加超时处理,跳过耗时过长的样本 |
| 中文问题回答不好 | 模型中文指令跟随能力弱 | 对比英文问题结果 | 改用模型更强的语言提问,或增加中文示例 prompt |
11. 最佳实践与使用建议
11.1 第一次跑评测不要贪多
先用 3 到 5 个视频验证全流程是否能跑通。确认命令、数据格式、模型加载、结果导出都正常之后,再扩展到全量数据集。这样能避免批量跑了一小时之后才发现格式错误。
11.2 固定随机种子
视频模型如果带有生成能力,推理结果可能不稳定。评测时在配置中加入随机种子,保证同一个模型两次评测结果一致。如果项目不支持设置种子,至少记录每一次运行时的随机状态,方便追溯。
seed: 42 temperature: 0.0 top_p: 1.011.3 数据目录规范化
测试视频、模型权重、评测结果建议分目录管理:
~/vgibench_workspace/ models/ datasets/ videos/ annotations/ outputs/ raw/ reports/ logs/日志和输出目录标记日期,方便复盘。
11.4 批量任务加日志和重试
批量评测不是“一把梭”。每个视频的评测结果、耗时、是否成功都要写入日志。失败任务单独记录,评测结束后统一分析。
11.5 接口服务限制访问范围
如果被测模型通过 API 方式部署,且局域网内其他设备也能访问,建议加上访问控制。评测脚本默认只监听 127.0.0.1,避免模型服务被外部调用。
11.6 涉及素材必须确认授权
VGI-Bench 评测过程中会处理视频素材。无论是从公开数据集中获取,还是自己拍摄,都要确认素材的使用许可。涉及人脸、声音、品牌标识的视频,对外发布评测结果前必须进行脱敏处理。
11.7 发布结果前做效果复核
自动评测只是第一步。对外发布模型评测分数前,建议让有经验的人员抽检 10% 到 20% 的样本,确认评分结果与主观判断一致。生成式模型的评测很容易出现“分数高但实际效果差”的偏差,人工复核是最后一道防线。
12. 总结与下一步
VGI-Bench 最有价值的点在于它把视频生成模型的视觉智能从“主观感受”变成了“可量化指标”。通过探针任务,可以快速定位一个模型在动态感知、物理常识、因果推理哪个环节存在短板。对于正在做视频生成模型选型或迭代的团队,这套评测流程值得在项目早期就引入。
最先要验证的功能一定是最基础的动态目标感知任务。先用几个简单视频跑通流程,确认视频输入、模型推理、答案判定、结果导出没有问题。之后再加难,逐步尝试物理常识和因果推理这类高阶任务。最容易踩的坑有两个:一个是视频输入根本没有被模型读到,只是模型在靠文本先验回答问题;另一个是评测数据集本身标注有误,导致模型答对了却被判错。
后续可以扩展的方向包括:接入更多视频生成模型做横向对比、自定义探针任务适配业务场景、把评测结果接入 CI/CD 流程实现自动化回归。VGI-Bench 这类评测基准解决的是“生成模型懂了没有”的问题,这个问题的答案,直接影响我们应该把哪些任务放心地交给视频模型。