AI 视频搜索评估：建立一套 30 条真实查询测试集
用 30 条真实查询评估 AI 视频搜索，覆盖相关性、镜头精度、元数据筛选、失败样本和源文件回链，建立可复现的采购测试。
评估 AI 视频搜索，应先固定有代表性的素材，再在测试前写好 30 条查询。查询需覆盖视觉含义、镜头语言、元数据筛选、歧义、已知失败和源文件回链。预先定义相关性，保持素材、结果深度和设置一致，同时报告命中与漏检。这样得到的是工作流证据，而不是通用准确率结论。
这套 30 条查询评估会产出什么
这是一套可重复的小规模试点，用来回答五个实际问题：
- 系统能否针对真实剪辑需求返回可用片段？
- 结果指向正确的文件、场景、镜头还是时间段？
- 已验证元数据能否限制范围，而不会与视觉含义混为一谈？
- 哪些查询会失败，误报会带来多少复核工作？
- 选中结果能否回到原始素材并进入下一步工作流？
这是一项采购与工作流测试，不是科学基准。NIST TREC围绕测试集合、主题和相关性判断组织检索评估；TRECVID则把共享评估方法用于视频检索研究。内部 30 条查询试点借鉴了固定输入和判断规则的原则，但结论只适用于本次素材、查询、设置和日期。
前提：打开产品演示前先冻结测试
评估任何产品之前，先建立测试清单：
| 项目 | 需要固定什么 | 为什么重要 |
|---|---|---|
| 素材集合 | 文件、版本、时长、语言、题材和版权状态 | 防止候选产品使用不同素材 |
| 搜索单元 | 文件、固定窗口、场景、镜头、帧或逐字稿段落 | 定义“一个结果”代表什么 |
| 查询集 | 30 条查询的准确原文 | 防止看到结果后改写弱查询 |
| 相关性判断 | 每条查询的已知目标和可接受替代项 | 让“好结果”可以复核 |
| 结果深度 | 例如每条查询统一查看前 10 个结果 | 保持复核工作量一致 |
| 设置 | 模型/索引版本、筛选条件、语言和调优 | 让复测结果可以解释 |
| 评审人 | 角色、领域知识和分歧处理方式 | 控制主观差异 |
| 测试日期 | 索引日期和搜索日期 | 产品行为会随时间变化 |
选择有代表性且版权清晰的素材，不要一开始处理整个档案库。应包含普通素材、困难样本、重复片段、长镜头、无声 B-roll、访谈、低光、不同语言语音，以及几条不应匹配任何结果的查询。不要允许供应商私下用准备好的演示素材替换测试集合。
搜索前定义相关性
运行每条查询前，先写下目标说明：
- 相关： 直接满足请求，经过正常剪辑复核即可使用。
- 部分相关： 主体或动作正确，但缺少镜头尺寸、时间、地点或版权条件等重要约束。
- 不相关： 看起来合理，但不满足请求。
- 预期无有效结果： 素材集合中本来就没有合格内容；返回空结果可能是正确答案。
相关性取决于任务。人物行走可能满足宽泛档案请求，却不满足演讲者以低机位跟拍方式走上舞台。把判断规则放在查询旁边，确保所有评审人判断的是同一任务。
30 条 AI 视频搜索测试查询
把人名、项目、地区和已知目标替换为已获授权测试素材中的真实值。保留六类结构，避免试点只测试漂亮的语义搜索示例。
| # | 类别 | 示例查询 | 测试内容 | 预先判断 |
|---|---|---|---|---|
| 1 | 视觉 | 人物打开一个纸箱 |
主体与动作 | 已知未打标签目标 |
| 2 | 视觉 | 双手组装一个小型设备 |
细粒度手部与物体互动 | 已知目标与近似误报 |
| 3 | 视觉 | 得分后庆祝的人群 |
多人动作与上下文 | 已知目标 |
| 4 | 视觉 | 夜晚有反光的雨天街道 |
天气、场景与外观 | 已知目标 |
| 5 | 视觉 | 演讲者在白板上写字 |
人物、物体与动作 | 已知目标 |
| 6 | 视觉 | 下班后的空办公室 |
缺席概念与场景上下文 | 有效结果可能有主观性 |
| 7 | 镜头语言 | 港口的全景建立镜头 |
景别与叙事功能 | 已知全景镜头 |
| 8 | 镜头语言 | 缓慢手持跟拍穿过市场 |
运镜与节奏 | 已知跟拍片段 |
| 9 | 镜头语言 | 浅景深的固定特写 |
构图与光学外观 | 已知目标 |
| 10 | 镜头语言 | 黄金时刻航拍推向海岸线 |
视角、运动与光线 | 已知目标或无有效结果 |
| 11 | 镜头语言 | 宣布消息后的低机位反应镜头 |
角度、剪辑角色与时间上下文 | 已知反应时刻 |
| 12 | 镜头语言 | 深色背景上的对称产品镜头 |
构图与产品呈现 | 已知目标 |
| 13 | 混合 | Atlas 项目访谈，2025 年拍摄，人物微笑 |
元数据加视觉含义 | 已验证项目/日期与视觉目标 |
| 14 | 混合 | 品牌 A 产品特写，已批准付费社交媒体 |
版权筛选加视觉搜索 | 只有已批准资产合格 |
| 15 | 混合 | 已获欧洲授权的城市夜景无人机素材 |
地区加场景 | 版权字段必须控制资格 |
| 16 | 混合 | B 机位拍摄的主持人走上舞台 |
摄像机元数据加动作 | 已知 B 机位目标 |
| 17 | 混合 | 第 4 集厨房场景中的俯拍镜头 |
制作结构加镜头语言 | 已知集数/场景目标 |
| 18 | 混合 | 提到 onboarding 的客户访谈，状态=已批准 |
逐字稿含义加流程状态 | 已批准逐字稿片段 |
| 19 | 歧义 | 看起来高端的素材 |
主观视觉概念 | 预先定义可接受示例 |
| 20 | 歧义 | 出问题前的那个时刻 |
叙事推断 | 预期评审分歧并记录 |
| 21 | 歧义 | 节奏快但镜头不晃 |
正向与负向组合约束 | 已知替代项 |
| 22 | 歧义 | 不是访谈，而是人物对镜头说话 |
否定与相邻概念 | 已知非访谈目标 |
| 23 | 歧义 | Apple |
水果、品牌或物体的实体歧义 | 标记歧义，不猜测意图 |
| 24 | 失败 | 雪地摩托穿越沙漠 |
空结果行为 | 预期无有效结果 |
| 25 | 失败 | 永久获得全球广播授权 |
不受支持的法律推断 | 必须要求权威元数据 |
| 26 | 失败 | 识别签署授权书的人 |
身份与同意边界 | 不得从外貌推断 |
| 27 | 工作流 | 回答采访问题后的安静特写 |
时间精度与周边上下文 | 已知镜头及相邻内容 |
| 28 | 工作流 | 适合 15 秒剪辑的最佳产品演示 |
检索加人工剪辑判断 | 多个候选，无唯一答案 |
| 29 | 工作流 | 所选港口镜头的源文件 |
源文件回链 | 必须返回准确文件路径和时间段 |
| 30 | 工作流 | 把三个已批准市场镜头加入可剪辑合集 |
多结果选择与后续交接 | 合集必须保留源引用 |
第 13–18 条需要可信结构化字段。视频元数据与语义搜索解释了为什么版权、所有权、审批和制作 ID 应是权威筛选条件，而不能由模型猜测。第 24–26 条则专门检查系统是否拒绝不受支持的结论。
一致地运行测试
对每个候选系统执行同一流程：
- 索引相同素材，记录所有排除或失败的文件。
- 使用完全相同的查询文字和允许的元数据筛选条件。
- 查看相同数量的结果并保存排序输出。
- 按预先规则判断每个结果为相关、部分相关或不相关。
- 确认结果文件、时间范围和周边上下文。
- 完成后续动作：打开源文件、建立 selects 或导出到目标剪辑工作流。
- 记录查询改写、供应商调优、崩溃、索引错误和人工干预。
如果改写了查询，必须同时保留原始版本。原始查询衡量自然易用性，改写查询衡量了解系统偏好后可以达到的效果。所有候选系统应获得相同的调优机会。
评估相关性与工作流适配
评分表应暴露漏检与复核成本，而不是把一切压缩成单一“准确率”。
| 指标 | 计算或观察方法 | 含义 |
|---|---|---|
| Success@10 | 前 10 个结果内至少有一个相关结果的查询数 / 30 | 用户能否找到可用候选？ |
| 首个相关结果排名 | 第一个相关结果所在名次 | 需要查看多少结果？ |
| 空结果正确率 | 正确返回无合格内容的空结果查询 / 预设空结果查询 | 系统能否避免自信噪音？ |
| 约束通过率 | 满足所有硬性元数据约束的混合查询 / 混合查询 | 筛选条件是否真正限制资格？ |
| 时间精度 | 结果是否指向可用时刻，而非只给出包含它的文件 | 还需拖动时间线多久？ |
| 源文件回链成功率 | 能打开正确原文件和时间段的已选结果 / 被测选择 | 检索结果能否完成交接？ |
| 误报复核时间 | 拒绝看似合理但不可用结果所花分钟数 | 揭示隐藏人工成本 |
| 工作流完成率 | 无需外部变通即可完成的任务 / 尝试的工作流任务 | 测试完整工作，而不只是搜索 |
只有在素材集合、查询集、相关性规则、结果深度和评审人可比时才能对比分数。如果两位评审人意见不一致，应保留双方判断，再用书面规则解决。小规模试点适合决定下一步测试，并不能证明对所有档案库都有效。
诊断失败模式
把失败归类，而不是把所有漏检视为同一个问题：
- 素材失败： 所需媒体未索引或无法解码。
- 粒度失败： 找到正确文件，但可用时刻仍埋在长素材中。
- 视觉语义失败： 没识别主体、动作、构图或关系。
- 逐字稿/音频失败： 语音缺失、转写错误或匹配过于字面。
- 元数据失败： 字段缺失、过期、映射错误或未强制执行。
- 查询歧义： 合理评审人对请求有不同理解。
- 边界失败： 系统把推断的身份、版权或同意当作事实。
- 交接失败： 结果无法回到正确原文件或剪辑时间码。
这能帮助团队判断应该调整素材集合、元数据治理、索引单元、模型、查询界面还是工作流集成，也能避免把元数据问题错误归因于 AI 模型。
ShotAI 适合测试哪些部分
ShotAI 的公开语义视频搜索说明介绍了对用户已索引素材进行自然语言检索；镜头级管理页面介绍了镜头级资产、源引用、合集和剪辑工作流导出。这些能力使 ShotAI 可以参与视觉、镜头语言、时间精度和源文件交接测试。
ShotAI 不是公共互联网反向视频搜索引擎、法律版权权威系统，也不是负责权限、保留、审批与分发的完整企业 DAM/MAM。经核验的业务元数据应保存在适当记录系统中，并测试真实集成。30 条查询不能保证结果或证明产品优越，只是让所有候选系统面对同样问题。
更广泛的选择标准可参考AI 视频搜索工具测试框架和视频资产管理采购指南。
试点检查清单
- 冻结有代表性且版权清晰的素材。
- 测试前写完 30 条查询及预期判断。
- 同时包含有效、歧义、混合和空结果案例。
- 保持结果深度、设置和调优机会一致。
- 保存排序输出与评审决定。
- 核验源文件、时间段与周边上下文。
- 完成下游工作流，而不是停在搜索结果页。
- 每次报告分数时同时披露限制、干预和测试日期。
常见问题
为什么正好使用 30 条查询？
30 条是可管理的试点规模，可以覆盖六种不同的失败和工作流类别。它不是行业标准，也不足以构成通用基准；试点发现重要缺口后应继续扩展。
每条查询都应该有已知正确结果吗？
不应该。应包含歧义请求和无有效结果的查询。实用系统应呈现不确定性，并在资格或证据缺失时避免编造匹配。
评审人应该查看多少条结果？
根据真实用户行为在测试前固定深度，例如前 10 个结果。所有系统使用同一深度，并在结论中披露。
元数据和语义搜索可以一起评分吗？
可以放在同一工作流测试，但要分别判断。元数据筛选决定资格，语义排序负责按含义排列合格素材。
怎样才算源文件回链成功？
选中结果必须在目标时间段打开正确原始资产，并保留足够身份信息，供下一步剪辑、审片或导出使用。
披露
本评估指南由 ShotAI 发布。它不包含 ShotAI benchmark，也不声称 ShotAI 会赢得这项测试。团队应使用有代表性的素材运行协议，并公布自身测试条件和限制。