状态：草案（2026-10-13），基于文档和论文（无内部实测）。 本文根据官方文档（2026-10-13 查阅）与论文中的数据编写。在我们的实验中并未实际调用视频-语言模型。慢速确认层仍处于规划阶段。 编写规则：以实测数据为基础，无法测量的项目标记为「未实测」。
目录
1. 诱人的想法
视频-语言模型（VLM）在输入视频后，能用句子回答发生了什么。它也通过文字了解乒乓球规则。那么，是否可以跳过从第 1 部分到第 7 部分的找球、球台几何学、事件规则、裁判引擎，直接问它「这个回合谁赢了？」呢。
从结论来说，目前 它并不适合用于决定比分。 这并非因为模型不够聪明，而是因为决定比分的瞬间 没有进入模型的输入中 。
2. 原因一：1秒1张
Gemini API 的视频理解文档（2026-10-09 更新）中写道：
- 视频输入默认提取 每秒一帧进行处理。
fps可以单独指定。 - 在低分辨率设置下，单帧为 66 个 Token，视频每秒约 100 个 Token。
- 视频中的特定时间点通过
MM:SS格式的时间戳询问。 - 并且文档本身给出了警告：「由于 1 FPS 采样，动作过快可能会丢失细节。」
用于实时对话的 Live API 文档则更加明确。视频以单张图片发送， 最高每秒 1 张，同时发送声音和视频的会话限制为 2分钟。
套用到乒乓球上是这样的。
| 我们所知的时间 | 值 | 依据 |
|---|---|---|
| 60fps 单帧 | 16.7ms | — |
| 发球前两次弹跳间隔 | 0.18–0.55秒，中位数为 0.40秒 | 实际比赛 12 场，标注发球 275 个（人工实测） |
| 回合内弹跳间隔 | 98% 在 1.5 秒以内 | 同上资料 |
| 需要怀疑同一侧两次弹跳的间隔 | 小于 0.25 秒 | 5 场 |
如果以每秒 1 张的速度观察，一次发球中发生的两次弹跳通常会在同一秒内、在 两个采样之间滑过。「落在哪一边几次」决定了比分，但那个瞬间根本不在输入中。模型能做的只有通过前后场景进行猜测。
fps 是否可以提高采样率。文档提供了指定方法但没有写上限，示例反而是 0.5。如果以 60fps 发送，Token 数量将增加 60 倍，即便如此，也找不到模型能够通过时间戳精准定位帧之间短暂停留的依据。以秒级处理时间戳这一点也让人担忧。对于 16.7ms 单位顺序至关重要的判定而言，秒级时间戳过于粗糙。
3. 原因二：基准测试展现的水平
TennisTV（arXiv 2509.15602，2026-04 的 v5）是一项评估 VLM 在球拍类运动视频中表现的基准测试。测试评估了 17 个 VLM，包含 1,298 个网球视频、2,527 个问题以及 8 种任务。
| 对象 | 总体准确率（论文） |
|---|---|
| 人类 | 89.2% |
| GPT-4.1 | 45.1% |
| GPT-4o | 44.5% |
| Gemini 2.5 Pro | 43.9% |
| 随机选择 | 27.9% |
最难的任务是 数一数在回合中球被击打了几次，Gemini 2.5 Pro 的准确率为 31.5%。某些模型的表现甚至低于随机选择（25%）。论文中还提到，出于成本考虑，商业模型是以 1fps 进行评估的。使用开源模型（Qwen2.5-VL-7B）更改帧数测试后发现，1fps 为 38.1，16帧为 38.6，32帧为 38.8，64帧为 38.4，几乎没有变化。这意味着 即使提供更多帧也不会自动变好。作者们得出结论：必须针对每个任务调整采样密度。
由于基准测试的不同版本中任务数量和数字略有差异，引用时必须附带版本说明。本次调查中未找到直接针对乒乓球的 VLM 判定基准测试。
4. 原因三：实时性与责任
- 延迟。 Live API 文档中没有延迟测量值（未确认）。第 1 部分的判定预算为 1.5 秒，当前引擎的判定延迟中位数为 0.16 秒。
- 会话。 如果声音+视频会话限制为 2 分钟，在观看一场比赛的过程中必须不断拼接会话。
- 是否可解释。 规则引擎可以逐个展示事件：「由于这次弹跳在这个时间发生在这侧，因此该选手失分」。当人类进行修正时，可以知道哪里出了问题。而 VLM 的文本回答即使听起来再逼真，也很难确认它是基于哪个画面得出的。
5. 所以该放在哪里：慢速确认层
VLM 做不到的是「16.7ms 内的顺序」，而它擅长的是「场景整体的语义」。回合是否已经结束、选手是否有计分的肢体动作、是否去捡球等粗粒度的事件，通过每秒 1 张也是看得出来的。因此，我们计划将其放在第 1 部分四个层的最底层，即 慢速确认层。
- 计分牌直接采用规则引擎的判定结果，不等待 VLM。
- 仅将标记为「需要确认」的回合的前后数秒剪辑异步发送给 VLM。
- 如果 VLM 的回答与裁判不同，则 仅做标记 。更改比分的是人类。
成本很低。按文档单价计算，以 1fps 重新审视一个 10 秒的回合大约需要 1,300 个 Token，在最便宜的等级中约为 0.0004 美元（按文档单价计算的值，未实测）。不过，由于是将视频发送到外部服务，因此必须先确定用户同意和数据保留条件。目前尚未实际调用过，在研究实验中也未进行调用（未实测）。
6. 总结
| 问题 | 规则引擎 | 视频-语言模型 |
|---|---|---|
| 输入时间分辨率 | 每帧（16.7ms） | 默认每秒 1 张 |
| 时间戳表示 | 秒的小数 | MM:SS |
| 判定依据 | 以事件序列展示 | 句子 |
| 擅长的事情 | 弹跳顺序、半场、时间戳 | 场景语义、说明 |
| 在 TT Score 中的位置 | 第 1–3 层（判定） | 第 4 层（慢速确认，规划中） |
如果视频-语言模型能够处理更细的时间粒度，这个表格将会改变。届时只需用同样的问题重新衡量即可：「决定比分的瞬间是否进入了输入中？」
TT 点评。 一个每秒睁一次眼的裁判是看不清球落在哪里的。不过，作为在比赛结束后提醒你「这个画面是不是有点奇怪？」的助手，它倒是个不错的选择。
参考
- Gemini API 视频理解： https://ai.google.dev/gemini-api/docs/video-understanding （2026-10-09 更新，2026-10-13 查阅）
- Gemini Live API 指南： https://ai.google.dev/gemini-api/docs/live-guide （2026-10-13 查阅）
- TennisTV： https://arxiv.org/abs/2509.15602 （v5）
- 弹跳间隔的实测：仓库
ttscore/referee.py页眉，events.py的END_AFTER_BOUNCE_S注释