北京
在企业级数据系统里待久了，会养成一种错觉：数据天生就是干净的。仓库、管道、别人清洗好的表——模型拿到手的时候，一切都已经排好队。直到我把一枚小小的运动传感器绑上网球拍，试图让它"看懂"一次挥拍，这种错觉才被彻底打碎。
想法在纸面上简单得不像话：拍子上装传感器，捕捉挥拍动作，实时告诉球员刚才打的是什么球、打得怎么样。就在球场上，就在手机里。我原本以为机器学习会是整件事里最难啃的骨头。
结果机器学习是整件事里最简单的一环。
真正让我栽跟头的，是它前面那一长串没人愿意多看一眼的环节。先把整套系统从头到尾摆出来，因为每一个难缠的问题，都藏在这条管道的某个位置上：
- 球拍上的惯性测量单元（加速度计+陀螺仪）：原始运动数据流，其中绝大部分根本不是挥拍
- 手机应用，通过低功耗蓝牙接收：拿到数据流，丢包频率比你希望的高得多
- 挥拍检测与切分：在持续不断的噪声里找出一次挥拍从哪里开始、到哪里结束。这一块占了问题的一半
- 特征窗口：把击球点前后的一小段窗口，转成少量廉价、可解释的特征
- XGBoost分类器：整个系统里最小的一个决策
- 端侧推理，100毫秒以内：不能走服务器往返，否则反馈说的就是上一个球了
- 球型与质量反馈：在下一个球到来之前送到球员眼前
真实世界的数据不是一行一行来的
在企业世界里，数据抵达模型之前，已经过摄取、校验和十几次转换。它是一行一行来的。它会迟到，但足够干净，干净到你可以对它进行推理。
传感器数据不一样。它是一根消防水龙带，喷出来的运动信息里，绝大部分不是你关心的东西。球员走向底线、拍球、调整握拍、挥拍，全都会产生运动信号。我的模型不会收到一个标注好的"注意，正手来了"的旗标。它收到的是一条连续不断的流，而第一个真正的问题不是分类，是先判断出到底有没有发生一次挥拍，以及它在永不停止的噪声里从哪里开始、到哪里结束。
这就是为什么整个系统的最后一行是模型调用，而它之前的一切才是真正的工作：
把原始运动流变成特征，并且只在检测到挥拍之后才对窗口做一次分类。代码结构大致是这样——缓冲区持续追加加速度和陀螺仪样本，如果还没检测到挥拍就直接返回，检测到之后才提取击球点前后约300毫秒的窗口，算出峰值加速度、旋转能量、挥拍时长、击球锐度等特征，最后交给分类器预测。那几十个特征里，大部分在测试之后都被我扔掉了。
我花了多年时间把"切分"当成别人的活儿。到了这里，它就是整个问题的前半部分。
那个把我的模型打崩的双手反拍
在企业里，数据到达模型之前已经过了摄取、校验和一堆转换，它是一行一行来的，虽然会迟到，但足够干净，干净到可以拿来推理。而传感器数据是一根消防水龙带，喷出来的大部分都不是你要找的东西。
球员走向底线、拍球、调整握拍、挥拍，全都在产生运动信号。模型拿不到一个"正手来了"的标注旗标，它拿到的是一条连续流。所以第一个真问题不是分类，而是先判断出到底有没有发生挥拍，以及它在永不停止的噪声里从哪里开始、到哪里结束。
这也是为什么整个系统里最小的那一行是模型调用，而它前面的一切才是真正的工作量所在。我过去一直把切分当成别人的活儿，到了这里才发现，它就是整个问题的前半部分。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
