2026年五部门联合印发"人工智能加教育"行动计划之后，教育SaaS产品里跟AI相关的需求量暴涨。我们团队负责的一个核心模块就是多模态学习数据采集------把学生在课堂上的行为、表情、语音、作答数据统一采集上来，喂给后端的AI分析模型做学情诊断。
这个模块听起来简单，做起来全是坑。今天把架构设计过程中的关键决策和踩过的雷分享一下，给同在做教育AI化的同学参考。
数据源分析
先理清楚要采集哪些数据：
课堂视频流（摄像头采集，用于表情识别和专注度分析） 课堂音频流（麦克风采集，用于语音评测和互动频次统计） 答题行为数据（平板/手机端，包括作答时间、修改次数、停留位置） 设备传感器数据（部分场景有智能笔，采集书写轨迹）
这四类数据的特点完全不同。视频和音频是连续流数据，带宽大延迟敏感；答题行为是结构化事件数据，量小但一致性要求高；传感器数据是高频时序数据，采样率从几十到几百赫兹不等。
架构设计的第一个决策：边缘计算还是全量上传？
最初方案是全量上传，所有原始数据直接传到云端。压测的时候发现根本扛不住。一个50人的教室，4路摄像头1080P30fps，带宽需求超过200Mbps。全国上万个教室同时上传，云端的带宽成本和计算成本直接爆了。
改成边缘计算方案：在教室端部署一个边缘节点（树莓派或小型工控机），视频和音频在边缘端做初步处理（人脸检测、表情分类、语音转文字），只上传结构化结果。原始音视频在边缘端缓存24小时后删除，需要回看的时候从边缘端拉取。
这个改动把上行带宽从200Mbps降到了不到2Mbps，云端只接收结构化的JSON数据。
数据采集层设计
边缘端的数据采集用了一个多进程架构，每个模态一个独立进程：
视频采集进程：用OpenCV读取RTSP流，每秒抽3帧做人脸检测和表情分类。表情分类用的是一个轻量化的MobileNetV3模型，在树莓派上推理时间约80ms，完全够用。 音频采集进程：用Python的sounddevice库采集音频，每30秒一个片段，用Whisper的tiny模型做语音转文字。这里踩了一个大坑：Whisper tiny在树莓派上的推理时间约15秒，刚开始直接同步调用导致音频丢帧。后来改成异步队列，采集和推理分离，问题解决。 行为采集进程：通过WebSocket接收学生平板端的行为事件，包括答题开始、提交、修改、切换页面等。每个事件带时间戳和学生ID。 传感器采集进程：通过蓝牙接收智能笔数据，采样率100Hz。这里有个坑是蓝牙连接不稳定，经常断连。加了一个自动重连机制和本地缓存，断连期间数据缓存在本地，重连后补传。
所有进程通过共享内存交换状态，通过本地消息队列（用Redis）传递事件。为什么用Redis不用RabbitMQ？因为边缘节点资源有限，Redis占内存小，而且我们不需要复杂的路由逻辑。
数据传输层设计
边缘端到云端的数据传输，踩了三个坑。
第一个坑：网络不稳定。教室的网络环境千差万别，有些学校用的是教育城域网，延迟高、带宽小、间歇性断连。最初用HTTP POST上传，网络一断数据就丢了。后来改用MQTT协议，QoS设为1，保证至少一次送达。边缘端本地保留未确认的消息，收到云端ACK后才删除。
第二个坑：数据乱序。MQTT不保证消息顺序，尤其是重连后补传的数据可能比新数据晚到。我们在每条消息里加了序列号和时间戳，云端收到后按序列号排序入库。对于实时性要求高的数据（如课堂专注度实时展示），用时间戳做窗口聚合，每5秒输出一次聚合结果。
第三个坑：数据量估算错误。最初按每个教室每秒1KB结构化数据算的，觉得一天一个教室不到100MB。实际上线后发现，行为数据和传感器数据的量远超预期。一个50人教室一天的行为事件约50万条，传感器数据约4000万条。压缩后还有约2GB。全国上万个教室一天就是20TB。
这个量级直接用MongoDB扛不住了（之前选型用了MongoDB），后来把行为数据迁到了ClickHouse，时序数据迁到了InfluxDB，MongoDB只存学生档案和课程信息。这个数据迁移花了将近三周，是整个项目里最痛苦的一段。
数据处理层设计
云端收到数据后，要做的第一件事是数据清洗。
教育数据的噪音比想象中大得多。比如表情识别在光线不好的教室里准确率会暴跌，有时候把"走神"识别成"困惑"。我们在清洗层做了一个置信度过滤，模型置信度低于0.7的结果标记为"不确定"，不参与后续分析但保留原始记录。
还有一个问题是学生ID的匹配。摄像头识别到的人脸需要跟学生花名册匹配，但学生可能换了座位、戴了帽子、侧着脸。我们做了一个多模态ID关联：先用教室座位表缩小范围，再在范围内做人脸比对。如果匹配失败，标记为"未识别"，交给老师手动确认。
这里有个工程上的小技巧分享：人脸特征向量不要每次都重新计算，在学生入学时计算一次存到数据库里，后续只做向量相似度比对。用FAISS做向量检索，1000个学生的比对可以在10ms内完成。
最后说一个安全合规的问题。
采集学生的视频、音频、行为数据，涉及未成年人隐私保护，这个在教育行业是红线。我们的做法是：原始音视频只在边缘端处理，不上传云端；结构化数据脱敏后上传，不包含可识别个人身份的信息；所有数据加密存储，AES-256加密；数据保留期不超过一个学期，学期末自动清除。
这个合规设计虽然增加了工程复杂度，但避免了很多潜在的麻烦。教育SaaS做AI化，安全合规不是可选项，是必须项。
总结
多模态学习数据采集的核心挑战不是AI模型，而是工程：边缘端的资源约束、网络的不确定性、数据量的增长速度、隐私合规的硬性要求。架构设计上最大的经验就是：能在边缘端处理的不要传到云端，能用结构化数据的不要用原始数据，能异步的不要同步。