先列清单：体育里到底有哪些数据
如果只问“体育大模型要处理什么数据”，答案很容易停留在“多模态”三个字。更有用的办法，是把它们一种一种摆出来，看它们各自长什么样。
按来源，大致可以分成三组：
- 内容与赛事类：比赛视频、文字报道与评论、比分与事件流、解说语音。
- 人体运动类：摄像头里的人体姿态与关键点、IMU（加速度与角速度）、智能鞋的压力与触地信息、GPS轨迹。
- 生理与状态类：心率、HRV（心率变异性）、睡眠，以及用户主观的疲劳或状态反馈。
三组数据的差异，不只是内容不同，还包括形态、频率、误差来源和缺失方式。下面逐项展开。
每种数据的形态与麻烦
| 数据 | 形态 | 主要的麻烦 |
|---|---|---|
| 比赛视频 | 按帧的图像序列 | 遮挡、镜头切换、回放与直播画面混杂 |
| 文字 | 非结构化的报道与评论 | 表述不统一，可能含过期或错误信息 |
| 比分与事件流 | 带时间戳的结构化事件 | 事件补录、更正与延迟到达 |
| 语音 | 连续的音频信号 | 环境噪声、术语与人名识别 |
| 人体姿态 | 每帧的骨骼关键点 | 遮挡、深度歧义、机位与视角 |
| IMU | 高频的连续数值 | 漂移、佩戴位置差异、需要标定 |
| 智能鞋 | 压力分布与触地事件 | 鞋垫尺码、磨损、温度影响 |
| GPS | 位置与速度序列 | 高楼与场馆内信号变差、更新间隔不稳 |
| 心率与HRV | 低频的生理读数 | 运动伪影、佩戴松紧、个体差异大 |
这里有几个容易被忽略的事实。频率差别很大：IMU这类传感器的读数密度，远高于心率这类读数；视频按帧走，事件流按“发生了才有一条”走，两者没有天然的对应关系。误差的性质也不同：视频里的问题多是“看不清”，传感器里的问题多是“漂了”或“丢了”，文字里的问题则是“说得不对”。
统一到两条轴上：时间与实体
把这些数据放在一起，最基础的一步是对齐。我们习惯把它拆成两条轴。
时间轴
每一条数据都要有可比较的时间。这看起来简单，实际上问题不少：
- 不同设备的时钟不同，手表和手机的时间可能有偏差，需要在训练开始时做校准或事后对齐。
- 视频有播放延迟与回放，直播画面里的时间与事件流里的比赛时间未必一致。
- 事件有滞后到达：一次进球可能过几秒才出现在数据里，但它发生的时间应该是进球那一刻，而不是收到的那一刻。
所以系统里应该同时保留“事件发生时间”和“数据到达时间”两个字段，二者不能混用。后面谈到实时播报的过期内容，就是从这里来的。
实体轴
第二条轴是人和物。同一位球员，在视频里是画面中的一个跟踪框，在事件流里是一个编号，在文字里是一个名字，可能还有不同写法。同一位用户，在训练里是一台手机和一块手表，在球迷内容里是一个阅读账户。
实体对齐的目标，是让“视频里穿几号球衣的人”“事件流里的球员ID”“文章里提到的名字”能对应到同一个实体。这一步如果出错，后面所有的推理都会建立在错误的对象上。
不同任务需要哪几种数据
不是每个任务都要吃下所有数据。下面用一个举例的对照来看，标记“主要”的是核心输入，“辅助”是提升质量的补充：
| 任务 | 主要数据 | 辅助数据 |
|---|---|---|
| 球迷赛前内容 | 事件流、阵容与伤停信息、近期比赛记录 | 文字报道、用户阅读偏好 |
| 虚拟主播 | 实时事件流、比分 | 比赛视频、术语与人名表 |
| 数字人教练 | 人体姿态、关键点轨迹 | IMU、心率、用户的训练历史 |
| 智能穿戴解读 | 心率、HRV、IMU、智能鞋 | GPS、睡眠、主观反馈 |
可以看到，虚拟主播最依赖的是结构化事件，而不是视频；数字人教练最依赖的是姿态与运动信号，而不是文字。让大模型直接“看视频、读文字、听语音”固然是一条路，但在很多任务里，先把数据转成结构化结果、再交给语言模型去表达，更可靠。这一点在多模型协作的分工里会详细展开。
举例：一次跑步训练的数据是怎样对齐的
用一次假设的训练来走一遍。用户在公园跑步，手机架在路边拍了一段画面，手腕上戴着手表，鞋里有压力传感器。
- 手表提供心率和GPS，手机提供摄像头画面，鞋垫提供触地信息，三者各有各的时钟。
- 训练开始前，用户按提示做一个简单的同步动作，比如原地跺两次脚。鞋垫上会出现两个明显的压力峰值，视频里能看到两次落地，把这两个时刻当作锚点，就能把设备时间对到同一条时间轴上。
- 视频里的人被跟踪框标记成“当前用户”，鞋垫与手表通过账户绑定到同一个实体。
- 之后系统才有可能回答“配速下降时，触地时间有没有变长”这类需要跨数据源的问题。
这里的同步动作只是一个示意的做法，实际可以用别的方式对齐。要点在于：对齐不是靠模型悄悄猜出来的，而是需要在数据采集阶段就留下可用的线索。
缺失与冲突：现实数据的常态
真实的体育数据几乎从来不完整。常见的情形有：
- 缺失：手表松了，心率中断；摄像头被遮挡，关键点丢失；GPS在场馆内信号变差。
- 冲突：手表显示恢复状态不错，智能鞋却显示落地模式变化；视频里球已越线，事件流里还没有进球记录。
- 延迟：一部分数据比另一部分晚到，若不处理，就会拼出不同时刻的画面。
合理的做法不是补齐一切，而是给每个数据带上质量标记，让上层知道它有多可信。冲突时不简单取平均，而是根据各传感器擅长的方面做仲裁，这个思路在手表与智能鞋数据的融合示例中有具体的场景说明。
接口：模型之间传什么
多种数据的最终目的，是让不同模型能共同工作。传递给下游的最好不是“原始数据”，而是带有以下信息的结构化结果：
- 内容本身，比如“左膝在下蹲后半程向内偏移”。
- 时间范围，比如“第三次重复的下降阶段”。
- 对应的实体，比如“当前用户，左腿”。
- 置信度或质量标记，比如“关键点可见度较低”。
- 来源，比如“来自摄像头姿态模块”。
有了这样的接口，语言模型就不必去猜数字，只需要在明确的边界内组织语言。
数据类型对模型选择的影响
数据形态决定了适合的模型，这也是不能用一个模型通吃的原因之一：
- 图像与视频适合视觉模型与跟踪模型，输出的是位置、关键点与轨迹。
- 连续的传感器信号适合时间序列模型，输出的是状态、趋势与异常提示。
- 音频需要语音识别与语音合成两类模型，输出与输入分属不同方向。
- 文字与结构化事实适合语言模型，但事实必须由结构化数据来约束，而不是让模型自行回忆。
换句话说，数据类型先决定了“谁来看”，语言模型再负责“怎么说”。
边界：这里还没有解决的问题
必须坦率说明，多模态数据的统一并不是已经完成的工作，以下问题都仍然存在：
- 标定与个体差异：同样的心率读数，对不同用户意义不同，需要个体基线，这需要时间积累。
- 数据量与隐私：视频与身体数据都很敏感，需要授权、最小化采集与本地优先处理的思路。
- 评估困难：对齐是否正确、融合是否合理，缺少统一的评估方式，往往要靠人工抽查。
- 场景差异：足球比赛的数据与个人训练的数据，采集条件差别很大，同一套方法不一定通用。
小结
体育大模型要处理的，不是“多少种数据”这个数字，而是这些数据能否落在同一条时间轴与同一批实体上，并且带着质量标记被交给合适的模型。先把数据说清楚，再谈模型怎么分工，这是江南体育AI梳理多模态问题时的基本顺序。赛前内容如何利用事件流与阵容信息，可以参考赛前分析为什么不能只拼历史数据。
