睡眠检测模型复现与调试全流程：从数据对齐到边缘部署

睡眠检测模型这事儿，光看论文觉得不难，真正自己从零复现一遍，再把手头数据跑通，你会发现坑全藏在数据采集和调试链路里。我前前后后折腾了小两个月，从多模态传感器数据的对齐，到训练曲线忽高忽低，再到把模型压进边缘设备，每一步都踩出过经验。这篇就把我完整的复现和调试过程拆开讲，从数据链路选型到线上日志排查，思路和代码都给到，希望对正在搞睡眠分期、状态监测或者穿戴设备模型落地的朋友有点用。

1. 睡眠检测模型的整体架构与选型依据

复现一个睡眠检测模型，第一步不是急着找代码，而是想清楚一个问题：你要监测的“睡眠状态”到底靠什么信号来体现。睡眠分期在临床上靠多导睡眠图（PSG），要采集脑电、眼电、肌电、心电、呼吸、血氧一大串信号，这套设备在实验室没问题，放到家用场景就完全不现实。所以绝大多数工程落地项目，走的都是折中路线：用更容易采集的信号来近似推断睡眠阶段。

常见的近似方案有三类。第一类是基于体动和心率，用手环、手表里的加速度计加光电传感器（PPG）来估计清醒、浅睡、深睡、REM，优点是硬件门槛低，缺点是精度上限不高，个体差异很大。第二类是基于毫米波雷达，整套系统不接触人体，能感知呼吸和微小体动，适合做床头设备，但受摆放位置、房间多径干扰影响较大。第三类就是我现在在做的，多模态融合，把雷达呼吸特征、音频鼾声特征、还有可穿戴设备的体动和心率特征全部汇总，用模型做综合判断。这类方案设计好了以后上限最高，但调试难度也最大，因为每个模态都有一堆自己的噪声问题。

我这次复现的目标是跑通一条完整的“数据采集—信号清洗—特征提取—模型训练—边缘端推理”流水线。模型结构上选的是融合了CNN和Transformer的时序分类框架：CNN负责提取短时局部特征，比如单帧内的频谱峰值、呼吸波的形态；Transformer负责建模长程依赖，毕竟睡眠分期本质上是非常依赖上下文的任务，一个30秒的片段是深睡还是REM，往往要看前面几分钟的趋势才能定。输入数据用固定窗口切分，窗口长度取30秒，和临床PSG分期标准保持一致，滑动步长15秒保证相邻窗口有重叠，这样后续做平滑后处理比较方便。

说实话，真正试过一圈之后我的体会是：睡眠检测模型的骨架并不神秘，复现的最大难点在数据链路。你从公开数据集下载的原始信号跟论文里提到的基本对不上，要么采样率不一样，要么传感器类型不一样，要么数据集本身分好了训练验证测试但标签噪声很大。所以整个项目的调试重心，我从第一天就放在了数据链路和可观测性上。后面所有踩坑和修复，基本上也都是围绕这条链路展开的。

2. 多模态传感器数据采集的预处理与对齐调试

2.1 原始信号质量的三个隐藏问题

做多模态睡眠检测，数据采集阶段最常说的三个问题是采样率不统一、时间戳不同步、单模态信号偶发丢失。这三个问题在公开数据集里往往已经被处理干净，但一旦用自己搭的采集板，问题立刻就暴露出来。

采样率不统一，比如雷达模块输出呼吸波形的频率是20Hz，可穿戴设备的心率特征只有1Hz，麦克风采集音频又是16kHz，如果直接拼在一起喂给模型，时间维度的语义完全对不上。我的做法是先把所有信号的时间轴对齐到同一个基采样率，统一用2Hz作为最终特征帧率，也就是每0.5秒一个样本帧。处理方式是对高频信号降采样加低通抗混叠滤波，对低频信号做线性插值上采样。这里有个很容易忽视的点：插值虽然能补出采样点，但不会增加真实信息，所以低频信号的特征本身就不该指望靠插值变丰富，模型结构里要相应调整不同模态支路的采样密度和感受野。

时间戳不同步比采样率问题更隐蔽。我用的是多个设备各自独立采集，虽然都是通过同一台电脑上的程序启动，但串口打开、设备初始化、缓冲建立都有各自的延迟。刚开始复现时，我直接把各路数据按到达顺序拼接，结果训练出来的模型验证集准确率比随机高不了多少，后来一查才发现两个模态的时间差最多能到3秒多。这个偏差对睡眠分期的判断是致命的，因为呼吸波形的某个特征和体动信号明明是同一时刻发生的，却被模型当成两个不同时刻的事件来学。

解决时间戳不同步，我用了双保险。硬件层面，每次采集启动前通过串口给所有设备发一个同步启动命令，同时物理上用一个LED灯同时照射所有设备的光感引脚，LED亮起的那一刻就是共同的时间基准点，程序里记录这个时刻作为t0。软件层面，在预处理代码里实现一个基于互相关的偏移校准函数：选一段高频信号作为参考，对另一路信号做滑动偏移，计算两路的归一化互相关，峰值对应的偏移量就是估计出的时间差，再按这个差值把整段信号平移对齐。

单模态信号偶发丢失，这个在长时间整夜采集中特别常见。雷达偶尔因为嵌入式端计算拥堵丢掉一段数据，可穿戴设备因为佩戴松动心率通道出现长时间无效值。刚开始遇到丢数据，我的代码直接抛异常退出，导致连续采集三天才有的一整夜数据作废。后来改成“低质量段标记”策略：对每一段信号算质量指标，比如心率有效帧比例、呼吸波形信噪比，低于阈值就把这段标记为低质量，不直接丢弃，喂给模型时通过数据增强随机遮蔽这个模态，让模型学习在部分模态失效时依然做合理判断。这个策略对最终系统鲁棒性的提升非常明显，模拟测试时哪怕人为丢弃30%的某一个模态，分期准确率只掉了不到5个百分点。

2.2 数据预处理流水线的可复现调试

预处理代码是整个复现项目里最容易产生“结果对不上”的部分。网上很多开源仓库，同样的睡眠数据集，跑出来的指标和论文差好几个点，多半不是模型结构的问题，而是预处理细节不一致。

我搭预处理流水线时做了一个现在回头看很有价值的决定——把每一步都单独封装成函数，并且每一步输出都落盘保存成中间文件。举个例子，原始波形很长的csv先进去，第一步是带通滤波，滤波结果存一份npz；第二步是分帧加窗，再存一份；第三步是特征提取，存一份特征矩阵。这样做的直接好处是：当训练结果异常时，可以按顺序回放每一步，定位是哪个环节出了问题，而不是对着一个黑盒流水线瞎猜。

基于这个落地经验，我强烈建议在预处理代码里加入“输出快照”功能，比如下面对滤波结果做验证的片段：

python复制def verify_bandpass_output(raw_signal, filtered_signal, fs, lowcut=0.1, highcut=0.8):
    # 直接用FFT对比滤波前后频谱差异
    from scipy.signal import welch
    f_orig, pxx_orig = welch(raw_signal, fs=fs, nperseg=1024)
    f_filt, pxx_filt = welch(filtered_signal, fs=fs, nperseg=1024)
    # 滤波带宽外的能量衰减至少20dB
    mask_out = (f_filt < lowcut) | (f_filt > highcut)
    atenuation = 10 * np.log10((pxx_filt[mask_out].sum() + 1e-12) / (pxx_orig[mask_out].sum() + 1e-12))
    assert atenuation < -20, f"filter attenuation too weak: {atenuation:.2f} dB"
    # 滤波带宽内的信号不能被过度削弱
    mask_pass = (f_filt >= lowcut) & (f_filt <= highcut)
    pass_ratio = pxx_filt[mask_pass].sum() / (pxx_orig[mask_pass].sum() + 1e-12)
    assert pass_ratio > 0.8, f"passband energy loss too high: {pass_ratio:.2f}"

顺带说一下特征提取部分的调试心得。睡眠检测里大家最爱用的特征无非是时域的均值、标准差、过零率，频域的带内能量、峰值频率、频谱熵，再加一些非线性特征。这些特征计算本身不复杂，难度在于特征之间的量纲差异非常大。我跑聚类可视化时候，发现有的特征数值范围是0到1，有的直接上千，如果不做标准化直接进模型，模型的loss会很难下降。所以归一化一定要做，而且是基于训练集统计量做，中途不能混入验证集信息，否则会有轻微的信息泄露。

预处理里还有一个我调试了很久的点：数据标准化之后，训练集和测试集同一特征分布不一致。后来定位到问题出在我用了两种不同批次的传感器硬件，一个做了温度补偿校准，一个没做，导致两批数据的基线漂移不同。这个问题的修复办法是在标准化之前先做一次基线校正，比如对每条记录取前5分钟的安静段均值作为基线减掉。不要小看这个操作，它直接让我的验证集准确率提升了6个百分点。

3. 模型复现的环境搭建与训练工程化

3.1 依赖和版本的一致性比什么都重要

论文复现的第一步是搭环境，很多人栽在这里。睡眠检测相关的开源仓库，依赖的PyTorch版本、Python版本、甚至CUDA版本五花八门。比如有的仓库用torch==1.9.0，配合numpy==1.19.5；有的仓库用新版torch==2.1.0，底层算子上有些API变了，直接跑旧代码会报torch.cat的报错。麻烦的是还能跑过，但结果不对。

我的建议是，不管你是不是在复现，一律用conda建独立虚拟环境，并且把依赖锁定到最小粒度。复现项目先别急着全部装最新版，先看README里给的requirements.txt，逐条对照，能不加新版本就不加。我这次踩过的版本坑是torchaudio和librosa的采样率接口对不上，新版本的librosa默认用sox_io_backend，跟旧版写数据的接口完全不一样，导致我能提取出特征但重读后数据全错位。最后我只能把librosa降到0.9.2版本才解决。

如果你本地GPU显存不够，也别硬顶着全部加载，用梯度累积加混合精度训练，可以把原版的batch_size减半再乘2个梯度累积步，效果几乎一致。

3.2 代码封装和数据流分层

这里分享一下我复现后整理出来的工程目录结构，可以直接抄作业。整个项目按“数据-特征-模型-训练-评估”五层拆：

text复制sleep-detection/
├── config/                 # 所有超参数yaml文件
├── data/
│   ├── raw/                # 原始信号csv和JSON标签
│   └── processed/          # 预处理后npz特征
├── src/
│   ├── pipeline/           # 数据加载、预处理、对齐
│   ├── models/             # 模型结构定义
│   ├── trainer/            # 训练循环、优化器、调度器
│   └── utils/
├── scripts/
│   ├── preprocess.py
│   ├── train.py
│   └── evaluate.py
└── logs/                   # tensorboard日志、模型权重

训练脚本里，我额外加了一个功能，把每个epoch的loss、准确率等指标直接写入JSON日志文件，同时在控制台打印。现在很多IDE和远程SSH环境里，控制台乱码或者日志保存不完整都是常见问题，所以直接设置一套自己的logger逻辑，把输出同时打给控制台和文件，调试时查看历史记录特别方便。可以参考我写的这一小段logger初始化代码：

python复制import json
import logging
from pathlib import Path

def setup_logger(log_dir="logs"):
    Path(log_dir).mkdir(parents=True, exist_ok=True)
    logger = logging.getLogger("sleep_logger")
    logger.setLevel(logging.INFO)
    
    fmt = logging.Formatter("%(asctime)s [%(levelname)s] %(message)s")
    fh = logging.FileHandler(f"{log_dir}/train.log", mode="w")
    fh.setFormatter(fmt)
    ch = logging.StreamHandler()
    ch.setFormatter(fmt)
    
    logger.addHandler(fh)
    logger.addHandler(ch)
    return logger

def log_metrics(logger, metrics: dict, step: int):
    logger.info(f"step={step} " + " ".join(f"{k}={v:.4f}" for k, v in metrics.items()))
    with open(f"logs/metrics_{step}.json", "w") as f:
        json.dump(metrics, f)

这套结构跑起来后，我调参和定位问题的效率提升非常明显。最核心的原因是把数据加载逻辑和训练逻辑解耦了。睡眠数据的WindowDataset每次要同时从多个模态文件取一段窗口，如果我直接在训练循环里写死数据读取，想调整样本窗口长度或模态组合就得改训练代码，极易引入新bug。用独立的Dataset和DataLoader封装后，训练代码只管拿tensor，数据层面随便改。

3.3 数据加载器的性能瓶颈

睡眠检测的数据加载很容易成为训练瓶颈，原因是窗口化和特征提取是IO密集型操作。一条整夜记录可能几百MB，每次按窗口读取，如果不用缓存机制，一个epoch有一大半时间花在磁盘读取上。

我排查性能瓶颈的思路是：先用一个简单的基准测试脚本看数据加载耗时和GPU计算耗时的比例。如果数据加载每个step要0.5秒，GPU前向加反向只要0.05秒，那瓶颈一定在数据端。解决办法有三个。

第一加缓存，把预处理完的特征矩阵一次性加载进内存，再用内存切片替代每次文件读取。如果你的数据集不是特别大（比如几十GB以内），这招效果远强于任何异步加载。第二加num_workers和多进程，但要注意每个worker都会复制一份特征引用，内存翻倍要算好。第三是针对数据增强的随机性做缓存层级拆分，把不涉及随机操作的通用特征缓存，把增广操作放到训练时实时做，这样既保随机性又压了IO开销。

这一步调试完，训练一个epoch的时间从85分钟降到了22分钟，提速显著。

4. 训练阶段的高频问题与调试链路

4.1 损失曲线平稳下不来，先看标签分布

我第一次把模型跑起来时，训练集损失下降到一定程度后就开始震荡，验证集准确率卡在70%上下不去。当时第一反应是调学习率、改batch size、换优化器，折腾了一周没用。后来静下心做了个数据分布的统计，发现问题出在类别不均衡上。

睡眠分期的标签分布太不均匀了。正常人整夜睡眠里，浅睡期占比可能超过一半，深睡期和REM加起来不到30%，如果直接用标准交叉熵损失，模型学到的最优策略就是“把所有样本都预测成浅睡”，这样总准确率能到60%以上，但深睡和REM的召回率接近0。问题就是70%这个准确率上限的来源。

解决方案采用了两路并进。第一路是修改损失函数，给少数类更高的权重，我用的是带类别权重的交叉熵加Focal Loss的混合形式，Focal Loss的gamma取2.0对困难样本的梯度提升很有帮助。第二路是修改训练采样器，让每个batch里各类别的样本比例尽量均衡，我用的是WeightedRandomSampler，权重设为样本数的倒数。

两路并进之后，验证集准确率到了78%，但更关键的是每个类别的F1分数都拉到了0.7以上，整体F1从0.65升到了0.76。

4.2 过拟合和欠拟合的快速定位方法

很多人在睡眠检测训练时遇到的另一个典型问题：训练集loss不断下降，验证集loss却一路回升，过拟合。

睡眠数据的样本量通常没有图片分类那么大，而且特征之间冗余度高，确实容易过拟合。我的排查标准是：训练集最终loss降到验证集的30%以下几乎必然过拟合，在50%到70%之间属于正常。定位过拟合后，可以优先尝试以下三个操作：

1. 加正则化。把模型里的dropout打开，sleep模型中通常在Transformer的每个attention层后加0.1的dropout，在全连接层后加0.3的dropout。

2. 数据增强。睡眠信号的增强要保证不破坏分期语义。我用的增强方法：加小幅度高斯噪声、时间轴轻微缩放、对频域特征的局部频带做随机遮蔽。注意不能做大幅时间扭曲，因为睡眠分期的时序连贯性一旦被打乱，标签含义就失效了。

3. 降低模型容量。如果你的Transformer层数超过8层且头数超过8个，对睡眠检测这种特征维度不足的任务来说可能过高了，减少到4层4头通常能同时改善过拟合和推理速度。

如果是欠拟合，训练和验证loss都下不去，那优先检查模型输入特征是否真的包含判别信息。我用一个小技巧，先把单帧特征用PCA降到2维，然后按标签画散点图。如果不同标签的样本点完全混杂，说明特征本身区分度不够，与其调模型，不如重新设计特征提取。

4.3 调试中的模型可解释性手段

调睡眠检测模型，最怕的就是“不知道模型为什么错”。我复现过程中加入了一个注意力热力图可视化模块。因为Transformer的自注意力权重可以直接可视化，把每个序列位置对最终分类的贡献画成一条曲线，叠在原始呼吸波形和体动信号上，一眼就能看出模型是不是在靠某个不合理的特征做判断。

比如有一次模型把一段明显的清醒期预测成了深睡，我调出注意力热力图后发现，模型注意力集中在一条异常高的心率spike上。后来查了原始信号，是用户翻身的动作让PPG信号产生了剧烈伪迹，模型把这个伪迹特征学成了深睡标志。这个发现帮我直接改进了预处理，加了更激进的伪迹剔除，同时模型预测效果也更合理了。

在调试早期，另一个实用手段是单模态单独训练再融合。我们训练多模态模型时，不要一开始就全部模态一起上，应该分别单独训练单模态的基座模型，记录每个模态单独能达到的最佳准确率。这样在多模态融合模型出问题时，能搞清楚是融合方式的问题，还是某个单一模态本身信息不足。我当时单模态训练的结果是：体动+心率单独准确率62%，雷达呼吸特征单独准确率68%，融合后准确率78%。这说明雷达呼吸特征贡献更大，后续调试融合模块时我重点关注了雷达特征的压缩方式，而不是盲目去调整融合层结构。

5. 从模型到产品：推理部署与工程化调试

5.1 模型压缩和转换

训练好的模型要部署到边缘设备，比如RK3568这类嵌入式平台，第一步是模型转换和量化。PyTorch训练的权重格式不能直接用，常见的是转成ONNX再转成各芯片的专用格式。我在这个环节踩过的坑主要是算子兼容性。

Transformer里的GELU激活函数在某些推理引擎上不支持，或者支持得很慢，我换成ReLU后精度几乎不变，推理速度却快了1.5倍。LayerNorm在部分芯片上也有优化问题，可以把多个LayerNorm替换成全局BatchNorm，但要小心重新训练或校准。

量化在这一步如果操作不当，准确率下降会非常明显。我用的是后训练动态量化，只量化线性层和Transformer的QKV映射，保留LayerNorm和激活为浮点。实测下来准确率掉点控制在1个百分点以内，模型体积缩到原来的四分之一。如果动态量化掉点太多，可以试一下量化感知训练，但训练代码要额外加伪量化节点，调试成本会高不少。

5.2 边缘端推理的实时性调试

睡眠检测虽然不是严格意义上的实时告警系统，但如果是做成睡眠质量报告，至少要能做到整夜数据在几分钟内处理完。RK3568这类设备的特点是算力有限但有NPU加速。

我调试实时性时，第一步先测每个模块的耗时占比，用time.perf_counter()包住每一段预处理、特征提取、模型推理代码。结果发现预处理里的带通滤波居然是耗时大户，因为数组维度大，又是纯Python循环。改成基于scipy.signal.sosfiltfilt向量化后，耗时降了一个数量级。第二步是看模型推理NPU是否真的被调用，如果日志显示还是走的CPU回退，那就要检查模型是否全量化、输入数据维度是否对齐。

如果把模型部署到嵌入式平台像串口一类的通道，日志调试推荐用串口调试助手工具，把设备端打出的模型推理耗时、每帧预测结果、置信度都实时打印出来。这里有个小技巧：在串口输出的每行前面加一个统一前缀，比如[INF]，然后用串口调试助手的过滤功能只看这个前缀，排查问题时会清爽很多。

对于嵌入式开发，如果用了VSCode做远程开发调试，可以在launch.json里配置好gdb的远程调试参数，当模型推理崩溃时能直接定位到C++层崩溃的堆栈，比在黑框里看报错信息高效太多。我实际在模型推理初始化阶段遇到的野指针问题，靠的就是GDB的bt命令定位到分配数组越界访问的位置，然后发现是自己定义特征矩阵时行数算错了。

5.3 完整联调的长稳测试

模型部署后，必须做连续运行测试，不能只跑几次Demo就算完。睡眠检测产品实际跑起来是整夜连续运行，要命的是内存泄漏和内存碎片化问题，可能几个小时后才暴露。

我做的长稳测试方案很简单但有效：写一个脚本模拟整夜12小时的输入数据流，每30秒喂一批新数据给推理程序，记录每批的推理耗时和设备内存占用，画成曲线。如果内存曲线持续上升且不回落，那基本能断定有内存泄漏。定位的方式是用工具抓一下进程内分配最多的对象，很多开发框架都支持对象堆快照，一抓一个准。

另外一个长稳测试中需要注意的问题是NPU或CPU的温升降频。嵌入式设备长时间满载运行会触发降频，推理耗时会明显增加。我的处理是在调度框架里做动态batch：设备温度低时用较大batch，温度高时自动降batch并调高睡眠时间间隔。这套逻辑不算复杂，但能保证整夜运行中不会因为设备过热导致预测逻辑越积越慢。

联调阶段我自己最受益的一个习惯是：所有算法模块的参数和版本号全部打印在启动日志里，包括模型权重文件路径、预处理特征配置版本、量化参数。这样线上出问题时，只要拿日志和配置文件一对比，马上能定位是不是某个模块更新后与其他模块不匹配。睡眠检测的整体链路长，涉及模块多，没有这套版本可追溯机制，后期排障会非常痛苦。

6. 评估指标的选取与结果分析

6.1 不要只用准确率，加权F1和混淆矩阵才是真相

睡眠检测模型最容易被准确率误导。因为睡眠样本类别本身就有严重不均衡，随便一个把所有样本都判成浅睡的模型就能拿到很高的准确率，但对实际使用毫无价值。

我最终用的评估指标侧重三组：加权F1分数、Cohen Kappa系数、各类别召回率和精确率。Cohen Kappa衡量的是预测和真实标签之间的一致性程度，排除了随机猜中的部分，对不平衡分类比准确率有意义得多。睡眠分期的Kappa值在0.6以上算模型有实际参考价值，0.4以下基本可以认为不如传统规则方法。

混淆矩阵是分析分类错误类型的必备工具。我自己调试时发现，模型最容易混淆的是N1期和清醒期，这从生理信号角度看完全可以理解：这两个状态的体动和心率特征非常接近。发现这个规律后，我调整了后处理逻辑，对预测结果做时间平滑，要求某一状态必须持续至少3分钟才允许从另一状态切换过去。这个简单规则非常有效，让N1期和清醒期的错误翻转减少了很多。

6.2 跨个体泛化能力的测试方式

睡眠信号个体差异极大，同一个模型在这个人身上准确率80%，在另一个人身上可能只有60%。复现论文时，评估一定要做跨个体的泛化测试，也就是训练集和测试集按照不同受试者划分，而不是随机切片划分。随机切片会严重高估模型性能，因为同一个人的相邻睡眠片段高度相似，模型等于用一个人的数据训练又在这个人身上测，这是数据泄露的一种。

我建议做按受试者分组的多折交叉验证：把N个受试者分成N折，每折留出几位受试者做验证，其余做训练。这样得到的性能指标才是真实的“新用户性能”。这种评估方式下我们的模型准确率从78%降到了70%，Kappa从0.61降到了0.52，但这是诚实的数据，产品化后不会出现上线即翻车的情况。

针对跨个体泛化能力不足，目前比较实用的思路是对齐特定设备的静态特征补偿，或者用几天的个性化数据做少量微调。微调时需要冻结前几层特征提取器，只微调最后的分类层，这样既不会忘记通用特征，又能适应个体差异。

6.3 结果分析阶段的可视化工具

评估阶段我最常用的三个可视化工具：混淆矩阵热力图、分晚预测时序图、注意力重叠图。混淆矩阵直接查看各类别错分来源；分晚预测时序图把模型预测的睡眠分期和金标准对比展示，我能直观看到模型在整夜趋势上的表现；注意力重叠图则把模型注意力区域叠在原始信号上，帮助确认模型是不是真的学会了睡眠分期的生理学特征。

这些可视化逻辑建议在训练早期就接入，等模型训完再补很被动。我是在训练循环里每固定步数保存若干测试样本的预测结果和对应的原始信号片段，评估完直接画图，整个过程自动化，不用每次都重复导出数据。

7. 项目上线前的检查清单与个人经验总结

最后聊几个我踩坑踩出来的实际经验，如果你是第一次做这类项目，大部分坑可能也会遇到。

第一，设备时间同步的问题，务必在采集阶段就解决。我第一版模型效果差，背后真正的原因就是时间同步漂移，这个问题后期几乎无法通过算法来完全弥补，最好的做法是采集阶段加好同步信号和时间戳协议。

第二，数据采集脚本里一定要加“原始信号留底+处理日志留底”。我之前有一次预处理后发现所有特征矩阵都是错的，源头是中间某个状态下滤波参数没生效，如果没有留底和处理日志，排查会无从下手。

第三，模型训练和推理的预处理必须完全一致。我踩过一次训练时特征做了标准化，推理时却忘了做，结果模型输出的概率分布全乱了，还以为模型崩了。所有归一化统计量、所有滤波参数、所有窗口大小，建议都放进同一个配置文件，训练和推理共用。

第四，部署到嵌入式平台之前，先在本地模拟器上把整条推理链路跑通。我用的是本地CPU模拟加量化模拟，确认精度掉点在1%以内后才烧到板子上。板上的调试周期长、手段少，能省则省。

睡眠检测模型复现和调试是一个典型的全链路项目，算法模型只占工作量的一部分，真正花时间多的反而是数据采集质量、预处理一致性、评估方式和边缘端工程化。每次定位到一个看似玄学的问题，最后追溯下来根源往往在某个不起眼的预处理或接口环节。所以后来我给自己定了个规矩：每次训练或者实验前，先把“数据对没对齐、预处理参数对不对、评估协议对不对”这三个问题过一遍，再动模型，能让调试效率提升一半以上。