一个请求要经过哪些模型
设想用户对着手机说：“帮我看看刚才那组深蹲，哪里不对？”这句话从说出口到得到回答，至少要经过下面这些环节：
- ASR（语音识别）：把语音转成文字，并识别其中的意图。
- 姿态模型：从视频里提取人体骨骼关键点。
- 追踪模型：在多帧里持续锁定同一个人，避免换人或丢失。
- 时间序列模型：分析关键点随时间的变化，识别重复次数、动作阶段与异常。
- LLM（大语言模型）：理解用户的问题，把分析结果组织成一段能听懂的话。
- TTS（语音合成）：把文字变成语音。
- Avatar引擎：驱动数字人的口型、表情与示范动作。
每一环都有自己专门的输入、输出和评价方式。如果让LLM把前面所有环节都包了，它需要“看视频”和“算角度”，而这恰恰不是语言模型最可靠的部分。
为什么不让LLM包办
把所有工作交给一个大模型，有几个现实的问题。
第一，精度与可核对性。 关节角度、重复次数、触地时间，这些是数值问题，专门的姿态与时间序列模型输出的是可以复算、可以回放核对的结果。语言模型对数值的处理更容易出现“听起来对但其实不准”的情况。
第二，成本与速度。 视频每秒有大量帧，让语言模型处理所有画面既慢又贵。姿态模型可以在设备上或近端完成，只把提炼后的结果交给语言模型。
第三，可替换与可维护。 姿态模型可以单独升级，TTS可以更换音色，Avatar引擎可以换形象，互不牵连。一个整体大模型则很难只改一个环节。
第四，可解释性。 出了问题，容易定位到是“关键点识别错了”还是“反馈说得不合适”。
分工表：谁产出，谁只负责表达
| 模块 | 输入 | 产出 | 不应该承担的事 |
|---|---|---|---|
| ASR | 语音 | 文字、意图 | 判断动作或事实 |
| 姿态模型 | 视频帧 | 关键点及置信度 | 给出教学建议 |
| 追踪模型 | 多帧关键点 | 稳定的人物ID | 语言表达 |
| 时间序列模型 | 关键点、IMU、心率序列 | 动作阶段、趋势、异常 | 直接与用户对话 |
| LLM | 结构化结果与知识 | 解释与反馈文本 | 自己去“看”画面、编造数值 |
| TTS | 文本 | 语音 | 修改文本含义 |
| Avatar引擎 | 语音与动作指令 | 口型、表情、示范 | 决定说什么 |
这张表的原则是：结构化结果由专门模型产生，语言模型只负责表达。LLM可以说“你的左膝在下蹲后半程向内偏移”，但“向内偏移”这件事，必须来自姿态与时间序列模块的输出。
接口：模型之间到底传什么
多模型协作的关键，是接口。接口不好，模型再强也会互相拖累。我们倾向于要求模块之间传递带结构的结果，而不是一段自由文本。一份合格的结构化结果至少包括：
- 结论：比如“下蹲后半程左膝内扣”。
- 时间范围：哪一次重复的哪个阶段。
- 对象：哪位用户，哪一侧肢体。
- 置信度：这个结论有多可靠，是否受遮挡影响。
- 来源：由哪个模块产生。
下游的LLM读取这些字段，并遵守两条规则：不能引用接口里没有的数字，不能把低置信度的结论说成确定的判断。这样表达与事实就分开了。关于这些数据本身如何统一，可以看体育大模型要同时理解多少种数据。
失败降级：某一环坏了怎么办
多模型系统一定会遇到某个模块失败或变慢。设计上的降级路径，比单个模型的精度更能决定体验。举例如下：
- ASR识别不确定：向用户确认一次意图，而不是猜。
- 姿态模型置信度低：不给具体纠正，只提示调整机位、光线或距离。
- 追踪丢失：暂停当前分析，等重新锁定后再继续，避免把别人的动作算到用户身上。
- LLM超时：退回预先写好的模板化反馈，内容依然来自结构化结果。
- TTS失败：退回文字字幕。
- Avatar引擎卡顿：降低渲染复杂度，保留语音与关键文字。
这里的共同思路是：每一环失败，都不应该让下游去“猜”。宁可少说一句，也不要在缺少依据时编造。
举例：一次完整请求的走向
把上面的模块串起来，用一个假设的请求走一遍，数字与时间均为示意。
用户说：“看看刚才那组深蹲。”
- ASR得到文字，识别出意图是“分析最近一组深蹲”，并附带一个不太确定的信号：用户没有说明是哪一组。系统按时间取最近一组，同时在回复里说明“我分析的是刚才完成的这一组”。
- 姿态模型对这一组的视频逐帧输出关键点，追踪模型保证始终是同一个人。
- 时间序列模型把关键点的变化切成几次重复，每次再分成下降、底部、上升三个阶段，并标出其中一次上升阶段的左右不对称程度较高。
- 系统把这个结果整理成结构化条目：哪一次、哪个阶段、哪一侧、置信度为中等。
- LLM读取条目和教学知识，生成一句反馈，比如“第三次起身时左侧发力偏少，下一组试着让两只脚的压力保持均匀”。
- TTS合成语音，Avatar引擎驱动数字人，并只演示与用户动作有差异的一小段。
整个过程里，语言模型没有接触原始视频，也没有自己“发现”问题，它接到的是一份可核对的结构化结果。如果第3步的置信度很低，第5步就应该改成“这一组画面遮挡较多，建议调整机位再录一次”，这就是接口约束带来的好处。
延迟：串联之后的时间账
多个模块串联后，时间是要精打细算的。我们通常从三个方向控制：
- 流式处理：姿态模型不必等整段视频结束，可以边拍边算；LLM生成文本时，TTS可以在第一句完成后就开始合成，而不是等整段结束。
- 并行：视觉分析与用户意图理解可以同时进行，最后再汇合。
- 按任务分级：实时提示只依赖轻量的检测，复杂的分析放到训练后再做。
延迟对不同场景的含义不一样：主播场景里，过期内容是事实错误；教练场景里，过晚的提醒是无效反馈。这些问题在关于数字人系统的专题里也有更宏观的讨论。
主播场景中的同一套思路
上面以教练为例，虚拟主播的协作方式也是类似的，只是输入换成了赛事事件流：事件确认模块产生结构化事件，LLM根据事件与预设要点写稿，TTS与Avatar引擎负责表达。关键仍然是事实来自结构化数据而不是模型记忆。两种场景的差别可以在AI体育主播最难的是别把比赛讲错里看到，而教练场景的具体反馈方式则在数字人教练如何把动作数据变成可执行的反馈里展开。
协作带来的新问题
分工不是没有代价。多个模块串联，会带来新的困难：
- 误差累积：前一环的小错误，可能在后面被放大。
- 延迟叠加：每多一个环节，就多一分等待，需要在链路里做流式与并行处理。
- 接口维护：字段变化需要同步，否则容易出现“上游改了，下游没跟上”。
- 评估复杂：整体效果不好时，要拆开逐环评估，才能知道问题在哪。
因此，江南体育AI在设计时会为每个模块保留独立的日志与回放，便于定位。这些都是设计思路的一部分，具体的实现程度与性能，以后续公布的信息为准。
小结
让大模型负责说，让姿态与追踪模型负责看，让时间序列模型负责算，是一种朴素但可靠的分工。它的价值不在于用了多少个模型，而在于每个模型只承担自己能承担的部分，接口清楚，失败时能安全降级。这是江南体育看待数字人系统的基本方式。
