“你的膝关节在最低点大约是93度，比较理想，继续保持。”
设想这样一次模拟测试：把三张深蹲截图直接丢给一个通用大模型，问它膝关节角度是多少，得到的就是上面这句话。回答流畅、语气笃定，还带着鼓励。问题是，这个数字没有任何来源。模型没有量过，它只是生成了一句“最像正确答案的话”。换一张图再问一遍，得到的可能是88度，也可能是97度，而用户无从分辨哪一个是真的。
这个失败案例几乎是所有多模型设计的起点：语言模型擅长理解意图、组织语言、做解释，却不是一台测量仪器。要让它在运动分析里既好用又不说谎，办法不是让它变得更“聪明”，而是把精确的活分给专门的模型，让它只做自己擅长的部分。这就是od体育采用多模型协作的原因。整套体系对“大模型到底该读懂什么”的更宏观的讨论，可以参考《od体育官网如何理解“体育大模型”：真正困难的是让AI同时读懂动作、数据和比赛》，这里只谈分工与接口。
大模型“编”出一个关节角度，是怎么发生的
先弄清楚它为什么会错，才知道分工该怎么划。语言模型的工作方式，是根据上下文逐个生成最可能出现的下一个词。当问题是“膝关节角度是多少”，它学到的是：这类问题的答案通常是一个介于60到120之间的数，后面跟着一句评价。它并没有一个从像素到角度的测量过程。
即使是能看图的多模态大模型，也是把图像切成小块编码后再“读”，分辨率有限，也没有统一的坐标系和尺度。一张深蹲截图里，膝盖到底弯了多少度，取决于镜头位置、拍摄距离、大腿和小腿两条线在画面里的透视关系；这些都不是靠“看着差不多”能得出精确数值的。更麻烦的是，模型对自己“不知道”这件事很不敏感：输出一个数字比承认不知道更符合它的训练习惯。
所以边界要在设计层面划死：凡是精确的数字，比如角度、速度、时间、距离、负荷量，必须来自专用算法的计算结果；大模型可以复述、解释、对比这些数字，但不能自己生成它们。
一张分工表：每个模型只管自己那一段
| 角色 | 输入 | 输出 | 为什么不能让大模型替代 |
|---|---|---|---|
| 姿态模型 | 视频帧 | 每帧关节关键点及置信度 | 要的是逐帧空间定位，语言模型没有这种精度 |
| 追踪模型 | 连续帧里的检测结果 | 同一个人的稳定编号与轨迹 | 需要跨帧一致性，不能每帧重新“认人” |
| 时序模型 | 关键点或传感器序列 | 动作分段、速度曲线、异常片段 | 需要严格按时间窗口计算，不能凭印象概括 |
| 优化与规则模型 | 目标、负荷、约束条件 | 可行的训练方案候选 | 有硬约束，超出范围就是错误，不是风格问题 |
| 大语言模型 | 用户话语、上述模型的结构化结果 | 拆解任务、调用工具、组织解释、追问 | 它擅长的正是理解与表达 |
需要说明的是，这张表描述的是分工思路，实际系统里各角色可以由一个或几个具体模型担任，也可以有传统算法参与。公开研究里常见的姿态方法，比如OpenPose、HRNet、RTMPose、ViTPose，都是姿态模型这一栏的候选；多目标追踪、时间序列分类也各有成熟做法。关键不在于用了哪个名字，而在于每一栏输出的东西，是否能被后一栏当作确定的输入。
大模型的岗位：听懂目标、拆问题、决定叫谁
那么大模型做什么？它做的是最难被规则替代的部分：把人话变成任务。假设一位用户说：“三个月后想跑半程马拉松，但右膝上下楼梯有点不舒服，帮我看看这周该怎么练。”这是一句模拟的话，里面塞了至少四层信息：一个有期限的目标，一个身体上的疑点，一个时间窗口，还有一句隐含的请求，就是别让我练伤了。
大模型把它拆成几个子任务：调取近几周训练记录，让时序模型汇总跑量趋势；请用户上传一段侧面跑步视频，交给姿态模型和时序模型看落地与膝盖轨迹；把“右膝不适”标记成需要谨慎的约束，交给规则层限制强度；最后把各路结果拼成一份能读懂的说明。它自己没有算过一个数，但它知道该叫谁、该问什么、结果怎么组织成一句人话。
这份计划最终怎么生成、怎么解释依据，《AI教练应该告诉运动员“练什么”，还是解释“为什么”？od体育大模型正在进入训练计划生成》展开讲了训练建议这一层，这篇更关心它下面的接口是不是可靠。
接口：工具调用不是“随便叫一声”
大模型调用其他模型，靠的是工具调用：它输出一个结构化的请求，系统执行后把结构化的结果交还给它。这里有几个容易做错的细节。
结果必须是结构化的，不是一段文字。姿态模型返回的应该是“时间戳、关节、坐标、置信度”这样的字段，而不是“看起来膝盖有点内扣”这种自然语言。如果上游已经变成描述，下游就无法核对。每个数字必须带单位、坐标系和来源。“93”没有意义，“膝关节屈曲角，侧面视角，第3组第2次的最低点，来自姿态模型某版本，置信度较低”才有意义。还要记录模型与版本。姿态模型换了一版，关键点的定义或精度分布可能变了，历史数据的对比就未必公平。失败也要有格式：视频里没有人、人被遮挡、画面过暗，工具应该明确返回“无法计算”，而不是硬凑一个结果，否则大模型会当成真值继续解释。调用还要有边界：设置超时和重试次数，某个工具一直没有返回时，系统应当告诉用户“这一项暂时算不出来”，而不是让大模型在没有结果的情况下继续写完整份报告。工具之间也不应随意互相调用，谁能读取哪些个人数据，需要在接口层面写明，这既是稳定性问题，也是隐私问题。
校验：数字变成文字之前，要过几道关
工具的结果回来以后，并不能直接交给用户。中间需要几道关卡。
- 范围检查：膝关节屈曲角不可能是负数，也不可能超过人体的物理范围；步频、心率同理。超出范围的值直接判为异常，回头检查是算法问题还是数据问题。
- 一致性检查：视频算出的落地时刻与IMU检测到的冲击时刻相差很大，两者至少有一个不对，或者时间没对齐，需要重新对齐或降级输出。
- 置信度门槛：关键点置信度低的片段，不进入评分，只在说明里写明“这一段画面不清晰，未参与计算”。
- 溯源核对：大模型生成的最终文字里出现的每个数字，都要能对应到工具返回值。对不上的，整句丢弃或重写。
第四条最容易被忽略。它相当于给大模型的回答做一次“对账”：数字是不是从工具来的，引用的时间点是否真的存在，结论有没有超出数据能支持的范围。如果大模型说“你最近三周速度曲线越来越好”，而时序模型只返回了一周的数据，这句话就该被拦下。
一次完整请求，模拟场景走一遍
仍然是那位想跑半程马拉松的用户。假设她上传了一段四十秒的侧面视频，同时授权读取近三周的训练记录。
系统先让姿态模型逐帧提取关键点，并附上置信度；追踪模型确认画面里始终只有她一个人；时序模型把关键点序列切成步周期，估计步频、触地时刻和膝盖轨迹。这一阶段全部是确定性的数值计算，没有大模型参与。结果发现：落地瞬间右膝有向内偏移的趋势，但视频里右腿有一段被栏杆挡住，那一段置信度很低。
大模型拿到的是这样一组结构化结果，外加训练记录里“近两周跑量上升”的摘要。它可以写：“侧面视频里，右膝在落地阶段有内扣的趋势，但有一小段画面被遮挡，结论只能视为线索；同期跑量在上升，两者是否有关无法从这段视频判断。”然后它会追问：“上下楼梯时疼的是膝盖前侧还是外侧？”并建议：这周不再增加跑量，重拍一段无遮挡的视频，若疼痛持续，先找专业人员评估。它没有报出任何一个自己算出来的度数，也没有下诊断。
延迟与成本：什么时候根本不该叫大模型
多模型协作还有一个很现实的理由：成本。大模型调用慢、贵，而运动分析里有很多环节要求实时反馈。比如深蹲时提示“重心偏了”，如果每一次都要等一次大模型往返，用户早已站起来了。这类实时提示更适合在手机上由较小的姿态模型和简单规则完成，只有在训练结束、需要总结和建议时，才调用大模型。
于是常见的分层是这样：需要毫秒级响应的，交给端侧的小模型和规则；需要跨次训练比较的，交给时序与统计计算；需要理解意图、生成解释的，才交给大模型，而且往往只把压缩后的结构化摘要交给它，而不是把整段视频塞进去。这样做的好处，除了省，还有一点：喂给大模型的信息越精炼，它越不容易在无关细节上发挥。同一个用户如果一天内要看三次分析，还可以缓存已经算出的姿态和时序结果，只重新生成解释，避免每次都从头把视频跑一遍。旧手机和新手机的算力差别也会影响哪些环节能留在本地，具体以App内的提示为准，不必让每个用户都为最重的那条链路买单。
协作的代价，以及什么时候一个模型就够了
多模型协作并不是没有代价。误差会叠加：姿态模型偏了一点，时序模型基于偏了的数据算出速度，后面再叠一层解释，最终结论可能离真相更远，而且很难看出错在哪一层。接口也需要维护，任何一个模型升级，输出格式或分布变了，都可能让下游悄悄失效。调试也更难，一句离谱的回答，可能是意图理解错了，可能是工具返回了异常值，也可能是校验没拦住。
所以并不是所有问题都要走完整条链路。如果用户只是问“深蹲时膝盖不能超过脚尖吗”，这是一个知识性问题，不需要调用任何视觉模型，也不需要个人数据，让大模型基于稳妥的运动科学知识回答，并说明个体差异即可。相反，凡是要对某个人的动作下判断，就必须有专用模型给出的证据。
这套协作能把“编造数字”的风险压低，但不能变成零。校验只能抓到已知类型的错误，遇到疼痛、伤病、青少年训练这类问题，最终判断仍应交给真人教练或医生。大模型的角色是把证据讲清楚，不是替人拍板。
