简介：这份资源面向机器学习与智能交通方向的初学者及进阶学习者，聚焦异常驾驶行为检测这一典型时序异常识别任务，提供可自行修改的完整实现方案。压缩包共6个文件，以3个ipynb交互式笔记本为核心，配合2个html结果页面与1个md说明文档，整体约9.52MB，便于在Jupyter环境中直接运行、调试与二次开发。内容围绕异常检测算法与速度进度分析两条主线展开，涵盖数据预处理、特征构建、模型训练与结果可视化等环节，读者可据此理解异常驾驶检测的完整流程，并对照说明文档快速上手。已有101人学习下载，适合课程设计、毕业设计或相关课题的参考与复现，也可作为时序异常检测入门的练手项目。
1. 异常驾驶检测到底在检测什么：从一次误报说起
凌晨两点，我收到一条告警：某辆测试车的异常驾驶评分突然飙到 0.93。回放数据才发现，司机只是低头捡了个手机，方向盘轻微抖了一下。模型把「短暂分神」和「疲劳驾驶」混为一谈了。这件事让我意识到，异常驾驶检测的核心不是「检测异常」，而是「区分哪种异常、持续多久、要不要报警」。
基于机器学习的异常驾驶检测，本质是用传感器数据（方向盘转角、车速、加速度、车道偏移）训练一个分类或回归模型，判断当前驾驶行为属于正常、疲劳、分神还是激进。它解决的是传统阈值规则「一刀切」的问题——固定阈值要么太灵敏天天误报，要么太迟钝漏掉真危险。适合谁做？车联网数据工程师、ADAS 算法入门者、以及手里有行车数据想跑通完整机器学习流程的人。源码和说明书的意义在于：你不用从零搭特征工程，改改参数就能验证自己的数据。
2. 数据从哪来、特征怎么造：异常驾驶检测的输入层拆解
2.1 三类常见数据源与采样频率的取舍
做异常驾驶检测，第一步不是选模型，是确认数据能不能用。常见数据源有三类：OBD 接口读出的车速、转速、油门开度，采样频率通常 1～10 Hz；IMU 惯性单元给出的三轴加速度和角速度，频率可以到 50～100 Hz；摄像头或毫米波雷达输出的车道线距离、前车距离，频率 10～30 Hz。
采样频率不是越高越好。我一般把高频 IMU 数据降采样到 10 Hz 再和 OBD 对齐，因为方向盘转角的有效变化集中在 0.5～2 Hz，再高的频率只会引入噪声。说明书里如果写了原始频率，先做重采样对齐时间戳，否则后面特征全是错位的。
注意：不同车型的 OBD 协议不同，PID 编码有差异，拿到的车速单位可能是 km/h 也可能是 mph，统一成 m/s 再进模型。
2.2 用滑动窗口造出模型能吃的特征
原始时序数据不能直接喂给大多数分类器。常见做法是切滑动窗口，每个窗口算统计量。窗口长度取 3～5 秒比较稳，重叠率 50%。下面这段代码是我常用的特征生成骨架：
import numpy as np import pandas as pd def sliding_window_features(df, window_sec=4, fs=10, overlap=0.5): """ df: 包含 speed, acc_x, acc_y, steering_angle 等列的 DataFrame window_sec: 窗口长度（秒） fs: 采样频率（Hz） overlap: 窗口重叠比例 """ win = int(window_sec * fs) step = int(win * (1 - overlap)) features = [] for start in range(0, len(df) - win + 1, step): seg = df.iloc[start:start + win] feat = {} for col in ['speed', 'acc_x', 'acc_y', 'steering_angle']: feat[f'{col}_mean'] = seg[col].mean() feat[f'{col}_std'] = seg[col].std() feat[f'{col}_max'] = seg[col].max() feat[f'{col}_min'] = seg[col].min() # 方向盘转角绝对均值，反映修正频率 feat['steer_abs_mean'] = seg['steering_angle'].abs().mean() # 加速度合矢量标准差，反映驾驶平顺性 feat['acc_mag_std'] = np.sqrt(seg['acc_x']**2 + seg['acc_y']**2).std() features.append(feat) return pd.DataFrame(features)逻辑说明：每个窗口提取均值、标准差、极值，再加两个领域特征——方向盘绝对均值反映司机是否频繁修正方向，加速度合矢量标准差反映车身是否平稳。参数怎么改？窗口从 4 秒改成 3 秒，误报会略增但响应更快；改成 6 秒，漏报减少但报警延迟明显。我一般先用 4 秒跑基线，再根据业务容忍度微调。
2.3 标签怎么打：弱监督和规则辅助
异常驾驶检测最头疼的是标签。真实数据里「异常」是稀疏事件，人工标注成本极高。常见做法是用规则先打弱标签：比如方向盘转角标准差超过阈值且持续 5 秒以上，标为「激进」；车速波动大且加速度频繁过零，标为「疲劳」。然后用这些弱标签训练模型，再用模型去发现规则漏掉的模式。
说明书里如果有标注规范，优先按规范来。没有的话，我一般用「三倍标准差 + 持续时长」做初筛，再人工抽检 10% 修正。这一步别省，标签质量直接决定模型上限。
3. 模型选型与训练：从逻辑回归到轻量梯度提升
3.1 为什么我不一上来就用深度学习
异常驾驶检测的数据量通常不大，单辆车一天有效驾驶片段可能就几百条。这种规模下，LSTM 或 Transformer 很容易过拟合，训练慢且不好解释。我一般先跑逻辑回归和随机森林做基线，再用 LightGBM 或 XGBoost 提精度。树模型对缺失值和异常值鲁棒，特征重要性还能直接看，方便和业务方解释「为什么报警」。
如果数据量真的上万条且时序依赖强，再考虑一维 CNN 或 GRU。但注意：车载端算力有限，模型参数量最好控制在 100K 以内，推理延迟低于 50ms。
3.2 训练脚本与关键参数
下面是一个 LightGBM 训练的核心片段，假设特征表已经生成好：
import lightgbm as lgb from sklearn.model_selection import train_test_split from sklearn.metrics import f1_score, classification_report # X: 特征矩阵, y: 标签（0正常 1疲劳 2分神 3激进） X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, stratify=y, random_state=42 ) params = { 'objective': 'multiclass', 'num_class': 4, 'metric': 'multi_logloss', 'learning_rate': 0.05, 'num_leaves': 31, 'max_depth': 6, 'min_data_in_leaf': 20, 'feature_fraction': 0.8, 'bagging_fraction': 0.8, 'bagging_freq': 5, 'verbose': -1 } dtrain = lgb.Dataset(X_train, label=y_train) dval = lgb.Dataset(X_test, label=y_test, reference=dtrain) model = lgb.train( params, dtrain, num_boost_round=500, valid_sets=[dval], callbacks=[lgb.early_stopping(30), lgb.log_evaluation(50)] ) y_pred = model.predict(X_test).argmax(axis=1) print(classification_report(y_test, y_pred))逻辑说明：多分类目标，4 个类别对应正常、疲劳、分神、激进。num_leaves和max_depth控制模型复杂度，数据量小就调小。min_data_in_leaf设 20 是防止叶子节点过拟合噪声。early_stopping(30)表示验证集 30 轮不提升就停，省时间也防过拟合。
参数怎么调？如果疲劳类召回率低，先看特征里有没有「闭眼时长」或「车道偏移方差」，没有就补特征，别急着调参。如果整体 F1 上不去，把learning_rate降到 0.02，num_boost_round加到 1000，通常能涨 2～3 个点。
3.3 类别不平衡的处理：别只用 accuracy
异常样本通常只占 5%～15%，accuracy 会骗人。我一般用class_weight='balanced'或自定义权重，让少数类样本权重更高。LightGBM 里可以通过scale_pos_weight处理二分类，多分类则用样本权重数组。评估看 macro F1 和混淆矩阵，重点看疲劳和分神有没有互相混。
提示：如果某个类别样本少于 50 条，考虑合并类别或改用异常检测思路（如 Isolation Forest），别硬做多分类。
4. 避坑与排查：异常驾驶检测落地时最容易翻车的 5 个点
4.1 现象：模型在测试集 F1 0.9，上车就疯狂误报
原因：训练数据来自固定路线和少数司机，测试集也是同分布，但实车场景换了司机、换了路况，特征分布漂移。解决：训练时按司机划分训练集和验证集，不要随机划分；上线前用新司机的数据做一次冷启动验证，F1 掉超过 15% 就要重新采样。
4.2 现象：疲劳类召回率极低，几乎全漏
原因：疲劳样本太少，模型偏向多数类。解决：先确认标签里疲劳样本占比，低于 5% 就用过采样或合成少数类（SMOTE），同时把评估指标从 accuracy 换成 macro F1。另外检查特征里有没有能区分疲劳的——比如方向盘修正频率降低、车速波动减小，没有就补。
4.3 现象：推理延迟忽高忽低，偶尔超过 200ms
原因：特征计算用了 pandas 的groupby或rolling，在车载端单线程跑会卡。解决：把特征计算改成 numpy 手写滑动窗口，或者提前算好缓存。模型推理用 LightGBM 的predict单条模式，别批量预测再取第一条。
4.4 现象：方向盘转角特征在部分车型上全是 0
原因：OBD 没读到方向盘转角 PID，或者该车型不支持。解决：先做数据可用性检查，缺列就换特征组合，用 IMU 的横摆角速度替代。说明书里如果列了支持 PID，对照确认。
4.5 现象：报警阈值调来调去，业务方总不满意
原因：模型输出的是概率，业务要的是「报不报」。解决：把概率映射到报警等级，比如疲劳概率 > 0.7 报一级，> 0.9 报二级，中间加持续时长过滤（连续 3 个窗口都超阈值才报）。这样误报会明显下降，业务也能接受。
5. 把模型塞进车载盒子的最后一步：量化与阈值调优技巧
模型训练完只是半成品，真正上车还要过部署关。我一般用 LightGBM 的save_model导出文本模型，再用 ONNX 转一次，推理速度能提升 30% 左右。如果盒子是 ARM 架构，注意编译时开-O3和 NEON 指令集。
阈值调优有个笨但有效的办法：拿一周的实车数据，按时间顺序跑推理，画出每个类别的概率曲线，然后人工标出「你认为该报警」的片段，反推阈值。我通常会把疲劳阈值设在 0.65～0.75 之间，分神设在 0.6～0.7，激进设在 0.7～0.8。具体值取决于业务能容忍多少误报。
还有一个血泪经验：别在训练集上调阈值。我吃过亏，训练集上调到 F1 0.95，上车一跑全是误报。后来固定用验证集调阈值，测试集只做最终评估，才稳定下来。
最后分享一个验证方法：把模型输出和 CAN 总线里的原始信号对齐时间戳，随机抽 20 个报警片段回放，人工判断是否合理。如果 20 个里超过 3 个是误报，阈值就得往上提。这个习惯我坚持了两年，比任何指标都管用。希望帮到你。
本文还有配套的精品资源，点击获取
