状态：草案（2026-10-26），已反映实测数据。 数据规模由我们亲自统计，许可证仅核实了各数据及仓库官方页面和 LICENSE 文件中记载的文本。 本文不属于法律意见。 “可用于商业用途”基于所记载的文本，商业服务中的最终判断需经过法律审查。 编写规则：实测数据为基础，无法测量的数据标记为“未实测”，未找到依据的标记为“无法确认”。
数据、许可证、学习过程
目录
1. 为什么需要单独写这篇文章
模型的故事通常以结构和准确率告终。然而在实际服务中，总会有两个问题随之而来。
- 这些数字是用什么测出来的？ 即使是相同的模型，根据使用的数据和规则不同，测出的数字也会有很大差异。
- 这个模型可以使用吗？ 用于训练的数据的许可证会直接延续到模型上。
TT Lab 于 2026-10-18 确定了转向商业服务的方向，自那以后，第二个问题便成了所有模型的首要问题。本文的最后一节将介绍这一方向、原则与计划。
2. 数据集表格
| 数据 | 来源 | 许可证 | 商业使用 | 我们的用途 | 规模（亲自统计） |
|---|---|---|---|---|---|
| OpenTTGames | 公开乒乓球数据集（随 TTNet 论文 [1] 一同公开） | CC BY-NC-SA 4.0 | 不可 | 研究与评估的基础（固定拆分） | 12 场，644,199 帧，89.5 分钟，1920×1080·120fps，无声音。球标记 52,987 帧（8.2%），事件 4,271 个 |
| Extended OpenTTGames | 上述数据的扩展标签（arXiv:2512.19327） | CC BY-NC-SA 4.0 | 不可 | 多拍胜者与原因标准答案、击球标签（研究与评估） | 多拍结束 281（使用已知发球方的 275 个），击球 1,456 |
| T3Set | 公开训练视频数据集（KDD 2025） | CC BY-NC-SA 4.0 | 不可 | 其他条件泛化评估（无球标准答案，人工检查），声音实验，教练基准值 | 选手 32，轮次 387，视频 734 个，26.9GB，1080p 60fps，有声音 |
| TT Sounds | 乒乓球撞击声数据集 [2] | CC BY-NC 4.0 | 不可 | 仅限声音分类实验。不放入引擎 | 15ms 片段 6,037 个，标签 5,702（球拍 3,396 · 球台 777 · 地面 290 · 其他 1,239），原始录音 149 |
| 实验室乒乓球视频（OpenNeuro ds004505） | 公开神经科学实验数据 | CC0 1.0 | 可 | 演示一个，球台查找测试（实验室对角 3 张）。由于实验室内环境相同，故从顶点训练中排除 | 无法确认 |
| 2015 年斯洛文尼亚联赛转播 | Wikimedia Commons | CC BY 3.0 | 可（标明出处） | 顶点模型 训练 12 张（与测试不重叠的区间），球台查找测试 26 张，首屏演示 | 1080p 25fps，24.7 分钟 |
| 4K 俱乐部比赛 | Wikimedia Commons | CC BY 3.0 | 可（标明出处） | 俱乐部演示，球台查找测试（侧面 4 张）。同一体育馆的视频已从顶点训练中排除 | 无法确认 |
| 1934 年乒乓球新闻片 | Wikimedia Commons | 公共领域 | 可 | 老电影演示，球台查找测试 2 张 | 无法确认 |
| 手机竖屏比赛视频 | Wikimedia Commons | CC BY-SA 4.0 | 可（使用相同许可证） | 竖屏手机演示，分条件测试一个片段 | 1080×1920，26.08fps |
| 合成乒乓球台图像 | 我们的代码（无外部图像） | 自有 | 可 | 顶点模型训练的 80% | 随机相机·光照·地面·背景·旁边球台·人物，2,500 次重复 × 批次 12 = 3 万张 |
合成多拍(ttscore/sim/) |
我们的代码 | 自有 | 可 | 引擎合成测试（标准答案由单独编写的代码生成） | 物理 1ms 积分，多拍 7 种类型，相机 12 种预设 |
| 实验室 3 场比赛 (TT3D) | 研究公开资料 | 无法确认 | 无法确认 | 仅限泛化评估 | 标准答案帧 49,516 |
| 国际转播自动追踪 (LATTE-MV) | 研究公开资料 | 卡片为 Apache-2.0，原始转播视频权利不明 | 不明 | 仅限泛化评估（标准答案非人工标记） | 812 场比赛，23,781 个片段，640×360·30fps |
| 球拍关键点 (RacketVision 乒乓球分类) | 研究公开资料 | 注释 MIT，视频权利不明 → 仅限内部使用 | 不明 | 比分图形读取实验（内部） | 780 个片段，170,027 帧 |
有些内容仅通过表格无法完全展现。
- 非商业数据是评估的基础。 具备球的位置、弹跳、多拍胜者标签的公开乒乓球数据大多为非商业许可证，迄今为止几乎所有的准确率数字都是在此基础上测得的评估结果。
- 可用于商业用途的实际训练资料目前还很少。 目前，我们仅将 2015 年联赛转播中与测试不重叠的 12 张图片用于顶点训练。第四部分提到的“未能展现出向其他体育馆的泛化能力”这一局限性便源于此。
- 相同场所的视频已从训练中排除。 与测试图像处于同一体育馆、同一实验室的其他视频，尽管连标签都已制作，但并未纳入训练中。如果纳入，测试结果将会过于乐观。
- 各数据集的陷阱（如标签仅存在于事件附近、多个多拍被合并为一个标签等）在前序系列 第 7 篇中有详细说明。
存档
原始数据原封不动地保存在 NAS 中，不做修改。工作副本位于 GPU 服务器的卷中，共 15 个包，约 89GB（包括 OpenTTGames 33GB、T3Set 26GB、国际转播 20.7GB 等）。笔记本 GPU 端不单独配置卷，而是以只读方式挂载 NAS 进行读取。研究产物（推断结果、热力图、训练好的权重）也存放在 NAS 的独立文件夹中。下载记录中显示同位置的大小为 132GB，数值存在冲突（无法确认哪一个才是当前数值）。
3. 学习实际上在哪里以及如何运行
一提到“学习（训练）”，人们往往会联想到大型 GPU 集群，但得分引擎的训练大多非常轻量。
| 模型 | 训练地点 | 耗时·规模 | 运行 |
|---|---|---|---|
| 过滤虚假弹跳 (1D CNN, 1.8万) | 笔记本 CPU | 20 个 epoch，批次 2048，5 个种子 | 开启 |
| “需要确认”校准 (Logistic Regression, 19特征) | 笔记本 CPU | 训练比赛 5 场 × 退化条件判定，比赛单位 5 折交叉验证 | 开启 (v2) |
| 学习型“多拍结束”（减少延迟） | 笔记本 CPU | — | 驳回 (原记录 E10) |
| 微调球模型 (clutter-v1) | 笔记本 GPU（8GB 级），一次性 Pod | 8,934 步，69 分钟 | 关闭 |
| 球台顶点模型（头部 64 万） | 笔记本 GPU（8GB 级），一次性 Pod 集 | 各 2,500 次重复 × 批次 12，约 20 分钟 | 开启 (2026-10-25) |
提取与推断（在整个公开视频上运行球模型、提取姿态等）是在 GPU 服务器或笔记本 GPU 的 CPU/GPU Pod 中运行的。
一次性 Pod 的方式
笔记本 GPU 上的训练是在 Kubernetes 上的 一次性 Pod中运行的。将包含训练代码和输入的 Pod 固定启动到该节点上，结束后即行删除（--rm）。之所以采用这种方式，是因为吸取了实际经历过的教训。
- 如果不固定节点，就会落到奇怪的地方。 曾发生过沉重的构建任务在没有固定节点的情况下落到了内存较小的节点上，导致同一节点上的其他服务也随之崩溃的情况。因此，训练 Pod 总是会固定节点，在启动前检查该节点的剩余内存和 GPU 分配情况，并填写内存请求与限制（顶点训练的请求为 3Gi · 限制 5Gi，启动前确认可用内存为 6–8GiB）。
- 结束后不留痕迹。 如果 Pod 占着 GPU 不放，运维人员就无法使用 GPU。训练结束后需确认“剩余 Pod 为 0”。
- 不赋予权限。 一次性 Pod 同样不使用服务账户令牌，NAS 仅以只读方式挂载。
也曾遇到过因 GPU 驱动程序问题导致 GPU Pod 根本无法启动的日子。在使用小型实验室规模的 GPU 时，比起训练代码，养成 先检查环境是否正常的习惯是非常必要的。
Kubeflow 虽已安装，但对得分引擎尚未使用
我们于 2026-10-18 通过 GitOps 安装了 Kubeflow Trainer（v2.3.0、JobSet v0.12.0），并确认了正常的同步状态。还创建了专用的训练区域。该区域的边界如下：
- Pod 为非 root、剥离所有 capability、禁止权限提升（Pod Security
restricted). - 占用 GPU 时仅限笔记本 GPU 节点，镜像仅限内部注册表，无服务账户令牌。
- 1 张 GPU，内存限制总和 6Gi，最多 4 个 Pod。
- 无出入站网络（pip 也无法访问互联网）。所需内容需提前放入共享卷（NAS，200Gi）中。
然而，迄今为止通过此 TrainJob 运行的训练 仅限于乒乓球机械臂强化学习和推理测试。 没有使用 TrainJob 训练得分引擎模型（球、过滤、校准、顶点）的记录。 原因记录在运维文档中。球模型微调所需的资料和大 GPU 位于 GPU 服务器上，但训练区域的 GPU 固定为笔记本 GPU 节点，规则不匹配。迁移资料或更改规则的决定必须先行。流水线（KFP 2.16.1）和超参数搜索（Katib v0.19.0）虽然安装文件齐全，但在处理安装后的同步错误的相关记录之后，当前状态为无法确认，也没有找到将其用于乒乓球模型的记录。
说实话，以目前的规模来看，这不是什么大问题。过滤和校准在笔记本电脑 CPU 上只需几分钟，顶点模型也只需 20 分钟。当我们需要从头重新训练球模型时（第 6 节），训练平台才会变得必要。
4. 实验规则：让数字值得信赖
比训练更耗时的是 公平测量。我在研究日志的最开始写下了适用于所有实验的规则（2026-10-13）。
固定分割
| 名称 | 比赛 | 包含发球的拉锯战 | 用途 |
|---|---|---|---|
| dev_train | 3 场公开训练比赛 | 140 | 制作研究用学习型候选模型 |
| dev_val | 2 场公开训练比赛 | 78 | 仅在此处选择超参数、阈值和组合 |
| test | 7 场公开测试比赛 | 57 | 每个实验 仅在最后进行一次。退化条件表也在里边。 |
| all12 | 上述全部 | 275 | 仅在与旧记录进行比较时使用 |
此分割仅用于研究。商业服务的训练材料遵循第 6 节的原则。
写下数据泄露警告
规则引擎是在 2026-10-11–12 期间参考全部 12 场公开比赛（包括 7 场测试赛）打磨出来的。因此， 规则基准的测试分数是样本内（in-sample）的，因而过于乐观。由于新的学习型方法从未见过测试比赛，比较结果对新方法不利。我们将此警告写在日志的最开头，并在每次比较时一同列出。此外，由于球模型的训练视频列表未公开，我们无法得知其是否与测试比赛重叠。因此，我们不能将球检测质量解读为泛化性能。
单一主要指标、成对比较、随机种子中位数
- 我们将主要指标固定为单一的拉锯战胜者准确度。辅助指标（无确认错误、需要确认、无判定、回球 F1、每帧毫秒数、判定延迟）会一并记录，但不会更改主要指标。这是为了防止在多个指标中挑选看起来较好的指标。
- 通过同一拉锯战的 成对比较来进行评估。使用 McNemar 准确度检验和成对自助法（paired bootstrap）95% 置信区间（1 万次）。如果在不同的退化条件下重复计算同一拉锯战，则它们并不独立，因此那时的置信区间应被视为过于乐观。
- 学习型模型应记录 3–5 个随机种子的中位数和范围。正如我们在顶点模型中所看到的，单一种子有时会在某个批次中增加 1–2 个确定且错误的情况。
在查看结果前写下判定规则
对于几项实验（需要确认的校准 v3、边界线条、从头到尾的相机记分牌、顶点模型），我们在 查看结果之前 就在日志中写下了采用条件（预注册）。例如，顶点模型的条件是：“在 35 个新画面中，确定且正确的情况增加，在任何批次中确定且错误的情况不得增加，以三个种子的中位数为准”。即便如此，如果有未能遵守的地方，我们也会毫不掩饰地记录下来。顶点模型在查看了第一次解码的测试结果后设计了第二次解码，并进行了两次测试，这些都原封不动地记录在日志和第 4 篇中。
实时预算
- 因果处理：判定时间点之后的帧只允许进行短暂的前瞻（默认 200ms 以下）。在观察完整场拉锯战后再进行判定的方法作为“录像回放轨道”单独记录，不予混同。
- 帧预算：60fps 时每帧 16.7ms。新模块总和应在每帧 5ms 以下。
- 判定延迟：拉锯战结束 → 得分 1.5 秒以下。
- 超出预算的方法，即使准确度再高，也会被归类为“无法实时运行”。姿态结合（每帧约 25ms）就是这样被否决的。
从失败中总结的规则（Ruling）
- R1. 坐标级别的合成遮挡无法替代真实遮挡。 开发实验中通过擦除球坐标来模拟遮挡所带来的收益，并未转化为实际的视频退化（在视频中绘制遮挡椭圆）。因为在真实遮挡中，检测往往不是消失，而是会跳变到错误的地方。
- R2. 学习型模块需要混入 30fps 的副本进行训练。 因为仅通过 60fps 训练出来的过滤在 30fps 下失效了（第 4 篇）。
- R7·R8. 标签修正。 我们找出了数据集中将多场拉锯战合并为一场的地方并将其分割，这些修正成为了校准 v2 的基础。
代码许可证原则
不引入 GPL、AGPL、MPL 代码，仅重新实现其方法。每个模型的训练材料都记录在权重元数据（nc_sources）和日志中。这些记录将成为未来转向商业化时决定重新训练哪些内容的依据（第 6 节）。
5. 当前实测数值一览
| 内容 | 条件 | 数值 | 依据 |
|---|---|---|---|
| 球精度 / 召回率 | 公开测试 7 场比赛，60fps，512×288 半径 5px，2026-10-11 | 0.9817 / 0.9785 | PERFORMANCE 2.1 |
| 拉锯战胜者（离线，以拉锯战为单位） | 12 场公开比赛 275 个拉锯战，分割模型顶点 | 93.8% (258) | PERFORMANCE 2.10 |
| 拉锯战胜者（部署实时路径） | 同 275 个拉锯战，数据集掩码顶点，2026-10-13 | 90.2% (248) | 日志 E00 |
| 运营流程固定基准表 | 测试 7 场比赛 × 11 种退化条件，标签 638，2026-10-16 | 正确 508，无确认错误 8，需要确认 497，虚警 51 | 日志 E25·E27 |
| 12 种退化条件，以拉锯战为单位 | 运营球模型 + 校准 v2 | 587/696 (84%) | 日志 E33 |
| 相同条件，微调球模型 | clutter-v1 + 校准 v3（关闭） | 610/696 (88%) | 日志 E33 |
| 相机记分牌从头到尾 | 测试 7 场比赛 851 秒，虚拟相机 30fps，标签 58，2026-10-17 | 正确 47，无确认错误 0，需要确认 53/65 | 日志 E35 |
| 寻找球桌（运营，开启顶点） | 测试 204 张 JPEG 70，2026-10-25–26 | 无抓取且确定且正确 84，确定且错误 23 | 日志 E44 |
| 判定延迟 | 测试 7 场比赛清晰画面 | p90 1.31 秒 | 日志 E00·E07 |
| 手机拍摄的真实乒乓球馆 | — | 未实测（带标签的手机视频 0 个） | — |
最后一行最为重要。到目前为止的所有数字都来自于 公开视频。它们是用固定相机拍摄的优质研究视频、转播视频以及合成退化视频。我们还没有用户在实际中使用的“社区乒乓球馆里架在三脚架上的手机”的数据。要获得这些数据，我们需要自己拍摄并带有标签的视频，这也与下一节的任务息息相关。
6. 通往商业服务之路：方向与原则
TT Lab 于 2026-10-18 确定了商业服务的方向，并正顺应这一方向， 将训练数据和权重替换为获准商业使用的内容。 这里仅记录方向、原则和计划。所有判断均以数据和代码库中的说明为准，不替代法律审查。
原则
- 运营模型使用获准商业使用的数据进行训练。 可用的材料有四种：自行拍摄并标注的视频、我们用代码生成的合成材料（球桌绘图、合成拉锯战轨迹）、允许商业使用的公开视频（如 CC BY、CC0、公有领域），以及同意用于训练的用户修正判罚（第 6 篇）。
- 非商业（NC）数据集仅用于内部研究和评估。 上述数据集表中的非商业数据将用于研究和评估引擎，而不会用作商业服务的训练材料。其在评估中的使用也受法律审查约束（见下文）。
- 公开内容应使用可商业使用的原始素材制作。 为配合商业转型，网站的演示视频已重新制作（2026-10-24–25），采用可商业使用的原始素材。相机记分牌演示使用 CC BY 联赛转播视频重新拍摄，且每个原始素材都在屏幕上标注了作者、许可证和修改内容。
- 为每个模型记录训练材料。 在权重元数据（
nc_sources）和研究日志中留下材料记录，以便随时明确哪个模型需要用什么材料重新训练。 - 不引入 GPL、AGPL、MPL 代码。 仅重新实现其方法（第 4 节）。
遵循此原则制作的首个案例
第 4 篇中的乒乓球桌顶点模型是首个完全遵循此原则制作的模型。它使用 Apache-2.0 编码器、80% 的自研合成图像、20% 的 CC BY 3.0 转播（12 张图像）进行训练，非商业数据集仅用于测试（元数据 nc_sources=[]）。如何在训练得到的权重中遵守 CC BY 的署名要求，将通过法律审查来决定。
计划
- 学习型过滤与校准。 第 4 篇中的边界过滤和“需要确认”校准，由于其输入仅为球轨迹和判罚特征，因此无需视频即可重新训练。使用合成拉锯战代码生成轨迹进行训练，并用少量自主标注的比赛进行验证，是最快的途径。积累的修正记录也将用作校准的材料。
- 球模型。 球模型也在筹备通过自行拍摄和标注的数据进行训练的途径。这需要带标签的视频和大型 GPU，这也正是第 3 节中提到的训练平台真正派上用场的地方。
- 规则引擎的阈值。 使用自有测试集重新验证并通过人工观察公开比赛确定的常量。
- 自采测试集。 这是同时解决下文评估相关讨论以及“手机现场准确度未实测”问题的关键，因此被放在首位。
评估数据将如何处理
评估目前正在使用非商业数据。7 场公开比赛测试是本文几乎所有数字的基础。商业公司是否允许在内部评估中使用非商业数据，取决于对数据许可证中“非商业”一词的法律解释，在此我们不作定论。技术上确定的道路只有一条： 制作带标签的自采测试集。这同时也填补了“手机现场准确度未实测”这一最大的空白。
7. 总结
- 迄今为止的准确度大多是在非商业公开数据上测得的评估结果，可用于商业的实际训练材料仍然较少。
- 训练规模很小。在笔记本电脑 CPU 上只需几分钟，在笔记本电脑 GPU 的单次运行 Pod 中只需 20–70 分钟。Kubeflow 虽然已经安装，但尚未用于得分引擎的训练。
- 为了让数字值得信赖，我们坚持了固定分割、单一主要指标、成对比较、随机种子中位数、预注册和实时预算，并对未能遵守的部分进行了记录。
- 我们正在顺应商业服务的需求，将训练材料和权重替换为可商业使用的内容。非商业数据仅用于内部研究和评估，重新训练将从 自采、自主标注和合成数据开始。
TT 点评。 模型预测得是否准确固然重要，“由谁的数据训练而来”同样重要。所以从现在开始，我们要用自己拍摄、自己绘制的笔记本内容来学习。
参考文献
- R. Voeikov, N. Falaleev, R. Baikulov. "TTNet: Real-time Temporal and Spatial Video Analysis of Table Tennis." CVPR Workshops, 2020. arXiv:2004.09927. OpenTTGames 数据采用 CC BY-NC-SA 4.0 许可证（数据公开页面说明）。
- T. Gossard, J. Schmalzl, A. Ziegler, A. Zell. "Sound-Based Spin Estimation in Table Tennis: Dataset and Real-Time Classification Pipeline." IEEE STAR, 2025. arXiv:2409.11760. 数据 CC BY-NC 4.0（仓库 README）。
- T. Gossard, F. Radovic, A. Ziegler, A. Zell. "BlurBall: Joint Ball and Motion Blur Estimation for Table Tennis Ball Tracking." CVPR Workshops (CVsports), 2026. arXiv:2509.18387. 代码 MIT。
- N. Ravi 等。“SAM 2: Segment Anything in Images and Videos。”ICLR, 2025. 代码及检查点 Apache-2.0。
- Y. Xiong 等。“Efficient Track Anything。”ICCV, 2025. 代码及检查点 Apache-2.0。
- Extended OpenTTGames（对打结束原因·胜者、击球标签）。arXiv:2512.19327. CC BY-NC-SA 4.0。
- 我们的测量与记录：仓库
docs/tt/PERFORMANCE.md2.1·2.10·2.19,docs/study/tt-score-models/07-datasets.md（数据计数），研究日志第 0 节（实验规则）·Ruling·E00·E25·E27·E33·E35·E44，deploy/下方训练任务指南文档，backend/app/tt_score_demos.py前言（演示原版）。
延伸阅读
- 本系列 第 4 篇：模型原理与论文：这里提到的三个训练模型的架构与实测。
- 本系列 第 6 篇：比赛记录与隐私：人工修正的判罚能够再次成为训练素材的条件。
- 前序系列 TT Score 模型剖析第 7 篇：亲自数一数乒乓球数据集.