简介面向时间序列预测与机器学习入门者的实战案例包围绕Xgboost梯度提升树算法展开兼顾时间序列预测与分类两类任务可用于金融、天气、股票等趋势建模场景的学习与复现。压缩包共3个文件包含2个Python脚本与1个ETTh1.csv数据集整体约407KB脚本分别承担模型训练预测流程与共享工具函数数据文件提供可直接运行的实验样本无需另行准备数据。目前已有6033人学习下载。案例完整覆盖数据分析、特征工程、输入特征选择、模型训练与本地保存、未来数值序列生成以及预测值与实际观测值的对比评估代码逐步注释便于读者理解每一步意图同时保留分类任务的实现思路帮助读者建立从数据处理到模型落地的整体认识适合作为动手实践、课程作业与项目练手的参考模板也可替换自有数据做迁移实验。1. 从一份可直接运行的时序案例说起预测和分类是两条腿某开发者手上有一份带时间戳的业务数据下周要交两样东西未来一段时间的数值走势以及每条记录属于哪种状态。前者是时间序列预测后者是时间序列分类。用 Python 和机器学习那套现成工具链XGBoost 能把这两条任务线压在同一份特征工程上跑通。这份案例的价值不在算法多新而在“点击即可运行”落到了实处——数据怎么切、特征怎么造、模型怎么调、结果怎么验每一步都有可执行的代码。适合正在做毕设、课设或者要给团队交一份可复现基线的人。后面按需求建模、特征工程、模型实现、避坑排查、验收答辩几段展开读完能直接照着搭一套。2. 需求与问题建模把业务问题翻译成回归和分类两个可交付任务2.1 任务定义目标列、时间粒度与预测步长时间序列项目最容易在一开始就跑偏数据拿到手就急着 fit结果目标列定义模糊粒度没对齐预测步长拍脑袋最后交上去的东西没人能验收。我一般的做法是先把三件事写死进一份配置——预测什么、以什么频率预测、预测多远。回归任务的定义是给定 t 时刻及之前的一段历史窗口输出 th 时刻的目标值。窗口长度 window 决定模型能看多远的历史步长 horizon 决定预测多远。分类任务的定义是给定同样一段窗口判定这段窗口对应的类别标签比如设备状态、流量等级、订单类型。两个任务共用同一套窗口切片逻辑只是标签来源不同。# 任务配置业务口径固定在这里训练、评估、推理都读同一份 CONFIG { time_col: timestamp, # 时间列名 target_col: value, # 回归任务的目标列 label_col: state, # 分类任务的目标列没有就置 None freq: h, # 数据粒度小时级 window: 24, # 用过去 24 个点拼一条样本 horizon: 1, # 预测未来 1 步 split_ratio: 0.8, # 按时间顺序切前 80% 训练 gap: 1, # 训练集与验证集之间留白防滑窗重叠 }配置里 window24 不是随手写的。小时级数据一天的周期是 24 个点模型要判断“现在这个点处于一天中的什么位置”至少得看到一整个周期。horizon1 是最保守的选择先把单步预测的链路跑通再考虑多步。split_ratio 和 gap 一起决定验证集从哪儿开始gap 的作用在 3.3 节细说。粒度这件事必须提前想清楚。同一份原始数据按分钟聚合和按小时聚合特征分布完全不同分钟级噪声大、滞后项多小时级更平滑但样本量掉一个数量级。选定粒度之后重采样规则、缺失值填充方式、标签对齐方式都得跟着改中途改粒度基本等于重做特征工程。所以配置里的 freq 一旦定下来整个项目别再动它。多步预测的策略也要在建模阶段定。常见三种递归法训一个单步模型预测值喂回去继续预测、直接法每个 horizon 单独训一个模型、多输出法一次输出多个值。递归法实现简单但误差会累积直接法稳但模型数量翻倍。案例里 horizon 默认 1就是为了避开这个分叉需要多步的时候再按 horizon 拆成多个回归任务各自训练各自的模型。2.2 选型对比为什么是 XGBoost而不是 ARIMA 或 LSTM时序预测的模型选择不少常见三类统计模型ARIMA/SARIMA、深度模型LSTM/TCN/Transformer、树模型XGBoost/LightGBM。这三个方向不是谁替代谁而是吃的数据形态不一样。维度ARIMA/SARIMALSTMXGBoost数据量要求小样本可用需要较多样本中等样本即可多特征融合弱外生变量接口受限强强直接拼列平稳性要求严格需差分定阶无无训练成本低高GPU 更稳低普通 CPU 可跑可解释性中低高有特征重要性趋势外推强中弱需去趋势调参难度中高中XGBoost 在这份案例里被选中主要是三个现实理由。第一业务数据往往带着一堆外生特征——节假日标记、促销标记、设备属性、历史统计量树模型把这些列直接拼进特征矩阵就能用不用给每个变量单独设计接口。第二训练快一台普通笔记本几分钟能跑完一轮交叉验证调参迭代的反馈周期短这对赶交付的场景是硬优势。第三特征重要性可以直接拿去做汇报业务方看得懂“上周同期值贡献最大”比解释 LSTM 的隐状态容易太多。但 XGBoost 有一个绕不开的短板树模型的预测值本质上是训练集目标值的加权组合落在训练集见过的数值范围内没法像 ARIMA 那样顺着趋势往外推。数据如果有明显上升趋势树模型会系统性地低估后半段。通常的处理是先把趋势剥掉——对目标列做一阶差分或者拟合一条线性趋势后对残差建模预测完再把趋势加回去。这一步不做评估指标看着还行画出来的预测曲线永远贴在下沿答辩现场被问一句就露馅。LSTM 不是不能打。序列很长、样本量足够、特征之间有明显时序依赖深度模型有优势。但对一份要交作业、要交付的案例来说可复现和可解释的权重更高XGBoost 的性价比明显更好。选型也不是一锤定音后续发现趋势外推是硬需求可以在树模型前面套一层 STL 分解趋势项和季节项分开处理树模型只学残差这是工程上常见的折中。2.3 交付物与目录结构一份能被人接手继续做的方案目录结构本身就是说明书。我一般按职责分文件配置、特征、切分、训练、评估各管一摊任何人拿到之后只看文件名就知道从哪进。timeseries-xgb/ ├── config.py # 全局配置列名、窗口、步长、超参 ├── data/ │ ├── raw/ # 原始数据只读不改 │ └── processed/ # 特征工程后的中间结果 ├── features.py # 滞后特征、滚动统计、时间特征 ├── split.py # 时序切分TimeSeriesSplit 封装 ├── train_reg.py # 回归任务训练与早停 ├── train_clf.py # 分类任务训练与类别权重 ├── evaluate.py # 指标计算、残差分析、混淆矩阵 ├── predict.py # 推理入口加载模型输出结果 └── requirements.txt # 依赖版本锁定raw 目录只读这条要当成纪律。原始数据一旦被就地修改后面所有实验都没法复现出了问题也查不到是哪一步改坏的。processed 目录存的是特征矩阵和标签能随时从 raw 重算所以它不进版本库。requirements.txt 锁 xgboost、pandas、scikit-learn 的版本这一点在验收环节很关键——同一份代码换个 xgboost 大版本早停行为和默认参数都可能变别人跑出来的数跟你对不上解释起来就是一场灾难。配置集中在一个文件里好处是调参时不用满项目搜数字。train_reg.py 和 train_clf.py 都从 config 读 window、horizon 和特征列清单保证两个任务的特征口径完全一致不会出现回归用了 24 个滞后项、分类只用了 12 个这种对不上的情况。predict.py 单独抽出来是为了让推理不依赖训练脚本——验收的时候别人只需要跑这一个入口就能看到结果。交付物里还要有一份特征字典记录每一个特征列的含义、计算方式、依赖的原始列。这份东西平时没人看一旦模型线上表现和线下对不上它就是排查的第一份材料。3. 特征工程滑窗构造、时间特征与防泄漏切分3.1 滞后特征与滑动窗口统计时序任务里特征工程决定了模型上限调参只决定你能多接近这个上限。XGBoost 本身不认识时间它看到的只是一张宽表所有时序信息都得靠人工造列塞进去。最核心的两类特征滞后项lag和滚动统计rolling。import pandas as pd def build_lag_features(df, target_col, lags(1, 2, 3, 6, 12, 24), windows(6, 12, 24)): 构造滞后项与滚动统计所有特征只使用当前时刻之前的信息 out df.copy() # 滞后项t-1、t-2…… 直接取历史值 for lag in lags: out[f{target_col}_lag{lag}] out[target_col].shift(lag) # 滚动统计先 shift(1) 把当前点排除再开窗 for w in windows: roll out[target_col].shift(1).rolling(windoww, min_periodsw // 2) out[f{target_col}_roll_mean{w}] roll.mean() out[f{target_col}_roll_std{w}] roll.std() out[f{target_col}_roll_max{w}] roll.max() out[f{target_col}_roll_min{w}] roll.min() return out这段代码里最关键的一行是out[target_col].shift(1).rolling(...)先 shift 再 rolling。少了这个 shift窗口里会包含当前时刻的目标值模型在训练集上表现惊艳上线之后直接塌方。我见过不止一个项目栽在这血泪经验写特征函数的时候先把 shift 加上再说别的。lags 取 1、2、3、6、12、24覆盖了短周期和一天周期。取太多滞后项不是好事特征维度上去了树模型分裂时更容易撞上噪声列而且训练时间线性增长。window 取 6、12、24 对应半天、一天、两天不到的观察窗口标准差和极值这类统计量能帮模型判断当前处于平稳段还是波动段。滚动统计的 min_periods 设成 w//2是为了序列开头那一段不至于全是 NaN。全 NaN 的行后面统一丢掉但丢太多样本对短序列项目是致命的宁可让开头的统计量略微不准。这个取舍要看数据长度样本少于 500 条的时候min_periods 可以再放松一点。3.2 时间特征与周期性编码原始时间戳不能直接喂给树模型得拆成模型能理解的数值。基础三件套是小时、星期、月份再补一个是否周末的布尔标记。import numpy as np def build_time_features(df, time_col): 时间特征基础粒度 周期编码 out df.copy() ts out[time_col] out[hour] ts.dt.hour out[weekday] ts.dt.weekday out[month] ts.dt.month out[is_weekend] (ts.dt.weekday 5).astype(int) # 周期编码把 23 点和 0 点在数值上拉近 out[hour_sin] np.sin(2 * np.pi * out[hour] / 24) out[hour_cos] np.cos(2 * np.pi * out[hour] / 24) out[weekday_sin] np.sin(2 * np.pi * out[weekday] / 7) out[weekday_cos] np.cos(2 * np.pi * out[weekday] / 7) return outhour 这种整数特征对树模型是有问题的。树只会在某个阈值上做二分23 和 0 在数值上隔了 23在业务上却只隔 1 小时模型得学出两个分裂点才能把这段连续关系表达出来。sin/cos 编码把周期映射到圆上23 点和 0 点在二维空间里距离很近模型一次分裂就能捕捉到这种邻近关系。不过 sin/cos 也不是万能的它把原本一维的特征变成两维特征重要性会被摊薄。实践中我的做法是两者都留着让模型自己选。树模型对冗余特征的容忍度比对缺失信息高得多多几列不影响大局少一列可能就丢了关键信号。节假日的处理要单独提。如果数据覆盖的节假日数量少直接做成布尔标记意义不大模型学不到稳定规律。更好的做法是构造“距下一个节假日还有几天”这种距离特征或者干脆把节假日那几天的样本从训练集里剔掉让模型专心学常规日期的规律。案例里如果数据里没有节假日列这一块可以跳过不要硬造。3.3 切分策略TimeSeriesSplit 与留出法的组合时序数据的切分是最容易翻车的地方。随机打乱切分train_test_split 默认行为会让模型在训练时看到未来、预测过去指标虚高一大截这种错误在答辩现场被导师问一句“你怎么保证没用未来信息”就答不上来。正确的做法只有一种按时间顺序切。from sklearn.model_selection import TimeSeriesSplit def make_tscv(n_splits5, gap1): 时序交叉验证每折训练集都在验证集之前gap 留白防止窗口重叠 return TimeSeriesSplit(n_splitsn_splits, gapgap) def holdout_split(df, time_col, split_ratio0.8): 留出法按时间点切前段训练后段测试 df df.sort_values(time_col).reset_index(dropTrue) cut int(len(df) * split_ratio) return df.iloc[:cut].copy(), df.iloc[cut:].copy()gap 参数值得单独说。构造滑窗样本时训练集最后一条样本的窗口可能延伸到验证集的前几个时间点验证集第一条样本的窗口同理。两段样本共享了原始数据的同一截验证结果就会偏乐观。gap 设成 horizon 或者 window 的大小把这段重叠区域挖掉是更严谨的做法。两种切分方式各有用途一般搭配着用。TimeSeriesSplit 做多折交叉验证用来选超参、比较不同特征组合的效果因为只有一折的评估结果波动太大靠它定模型结构不靠谱。留出法的那一段测试集全程不参与任何训练和调参只在最后跑一次用来出报告里的数字。测试集只碰一次这条规矩要守住反复在测试集上调参等于把它变成了验证集最后那个指标就没什么说服力了。切分完还要检查两件事训练集和测试集的时间区间有没有重叠测试集的目标值分布和训练集差多少。如果测试期正好撞上一段异常波动模型指标全面下滑不要急着回去改模型先确认是不是数据本身的问题。4. 模型实现回归器与分类器的训练、调参与评估4.1 回归任务XGBRegressor 的配置与早停回归任务的目标是预测未来一个时间点的数值。XGBoost 的回归接口配置项不少但真正影响结果的就那么几个。from xgboost import XGBRegressor from sklearn.metrics import mean_squared_error, mean_absolute_error import numpy as np def train_regressor(X_train, y_train, X_valid, y_valid, feature_names): model XGBRegressor( n_estimators1000, # 上限靠早停决定实际轮数 learning_rate0.05, # 学习率越小越稳但轮数越多 max_depth6, # 树深控复杂度 min_child_weight3, # 叶子最小样本权重防过拟合 subsample0.8, # 行采样 colsample_bytree0.8, # 列采样 reg_lambda1.0, # L2 正则 objectivereg:squarederror, random_state42, early_stopping_rounds50, eval_metricrmse, ) model.fit( X_train, y_train, eval_set[(X_valid, y_valid)], verboseFalse, ) print(f最佳迭代轮数: {model.best_iteration}) return modeln_estimators 给 1000 是个上限实际用多少轮由早停决定。早停的逻辑是验证集指标连续 50 轮没有改善就停回退到最优那一轮。这个机制在时序任务里特别有用因为不同项目的收敛速度差别很大靠手动试轮数太费时间。learning_rate 和 n_estimators 是一对需要联调的参数。学习率调小模型收敛更稳但需要的轮数上去训练时间变长学习率调大收敛快但容易在最优解附近震荡。0.05 是个比较中庸的起点样本量大的时候可以再降到 0.03样本量小的时候 0.1 也够用。max_depth 控制树的复杂度默认 6 已经能表达大部分特征交互。深度加到 10 以上训练集误差会明显下降验证集误差反而上升这是典型的过拟合信号。min_child_weight 和 reg_lambda 都是防过拟合的前者限制叶子节点的最小样本量后者惩罚叶子权重。数据噪声大的时候这两个参数往大调数据干净的时候可以放松。subsample 和 colsample_bytree 是采样参数作用相当于给模型加随机性减少对特定样本或特定列的依赖。0.8 是个常见起点特征列特别多的时候 colsample_bytree 可以压到 0.6。训练完直接看特征重要性这一步对交付很关键# 输出前 15 个重要特征直接放进汇报材料 imp model.feature_importances_ order np.argsort(imp)[::-1][:15] for i in order: print(f{feature_names[i]:28} {imp[i]:.4f})特征重要性排前面的如果全是滞后项说明模型基本在靠最近的历史值做推断这时候要检查是不是还有别的信号没被利用上如果时间特征排得很靠前说明周期性是主要驱动因素节假日的处理值得再花点力气。4.2 分类任务XGBClassifier 与类别不平衡处理分类任务的流程和回归类似差别在目标列和评估指标。多分类用multi:softprob输出每个类别的概率。from xgboost import XGBClassifier from sklearn.utils.class_weight import compute_sample_weight def train_classifier(X_train, y_train, X_valid, y_valid, num_class): # 类别不平衡时给样本加权少数类权重更高 sample_weight compute_sample_weight(class_weightbalanced, yy_train) clf XGBClassifier( n_estimators800, learning_rate0.05, max_depth5, # 分类任务树可以浅一点 min_child_weight2, subsample0.8, colsample_bytree0.8, objectivemulti:softprob, num_classnum_class, eval_metricmlogloss, random_state42, early_stopping_rounds40, ) clf.fit( X_train, y_train, sample_weightsample_weight, eval_set[(X_valid, y_valid)], verboseFalse, ) return clfsample_weight 用balanced模式按类别频率的倒数给权重。数据里三类样本比例如果是 8:1:1不加权的话模型会倾向于全预测成多数类准确率看着有 80%实际少数类一个都没识别出来这种模型交上去就是自欺欺人。分类任务的树深可以比回归浅一点max_depth5 通常够用。原因是分类的决策边界相对简单太深的树容易把训练集里的噪声样本单独圈出来验证集上泛化不了。预测的时候要拿概率而不是硬标签predict_proba输出每一类的置信度后面做阈值调整或者人工复核都用得上proba clf.predict_proba(X_test) pred proba.argmax(axis1) # 置信度低于 0.6 的样本单独标记交人工复核 low_conf proba.max(axis1) 0.6低置信度样本单独拎出来这是工程上很实用的一招。模型不确定的部分不让它硬猜交给人处理整体准确率反而更高。4.3 评估指标与结果解读指标选错前面所有工作都白费。回归和分类各有一套指标体系不能混着看。任务指标适用场景注意点回归RMSE对大误差敏感量纲与目标值一致好解释回归MAE关注平均偏差对异常值不敏感回归MAPE相对误差目标值接近 0 时会爆表分类准确率类别均衡不均衡时严重失真分类宏平均 F1类别不均衡少数类表现一目了然分类混淆矩阵看具体错在哪汇报时最有说服力MAPE 这个指标要特别小心。目标值里有接近 0 的点分母一小百分比误差直接飞到几百把整体指标拉得没法看。这种场景换成 sMAPE 或者干脆只用 MAE。我一般会在评估脚本里加一层保护分母小于某个阈值的样本跳过 MAPE 计算同时在报告里注明跳过了多少条。分类任务只看准确率是最常见的坑。混淆矩阵要打出来看重点看少数类被误判成了哪一类——如果少数类全被吞进多数类说明权重没加对或者特征里根本没有区分这两类的信息得回去补特征。评估还有一步经常被忽略残差分析。把预测值减真实值的残差按时间画出来如果残差在某段时间系统性偏正或偏负说明模型没捕捉到那个阶段的规律可能是趋势没处理也可能是数据分布变了。这一步比看一个总指标有用得多。5. 避坑与排查五个让时序项目白干的坑5.1 随机切分导致数据泄漏现象交叉验证分数很高RMSE 比基线低一大截换到测试集或者上线之后指标断崖式下跌。原因用了train_test_split的默认随机切分。时序数据随机打乱之后训练集里混进了测试集时间点之后的样本模型在训练阶段就见过“未来”评估结果自然虚高。这种错误特别隐蔽因为代码跑起来不报错指标还很好看。解决所有切分必须按时间顺序。交叉验证用TimeSeriesSplit留出法手动按时间点切。切完之后加一行断言检查时间区间不重叠养成习惯之后这类问题基本不会再有。assert train_df[timestamp].max() test_df[timestamp].min(), 训练集时间晚于测试集5.2 滚动特征没有 shift现象训练集上的指标好得不真实R² 能到 0.99模型重要性排行第一的特征是某个滚动均值。原因构造 rolling 特征时直接对目标列开窗窗口包含了当前时刻的值等于把答案混进了特征。模型学到的是“目标值约等于它自己的滚动均值”这个关系在训练集上永远成立在真实预测时不存在。解决rolling 之前先shift(1)把当前点排除出窗口。写完特征函数之后做一个强制自查把目标列整体往后挪一位重新算一遍特征如果模型指标基本不变说明特征里没有泄漏如果指标暴跌说明之前确实偷看了答案。这个检查我每次写新特征都会跑一遍。5.3 时间戳重复、乱序与缺失现象特征矩阵行数和原始数据对不上或者滑窗样本里出现时间倒挂模型训练时报出莫名其妙的索引错误。原因原始数据采集环节可能产生重复时间戳同一秒多条记录、乱序多源合并、缺失采集中断。这些问题在数据量大时不明显一旦进入滑窗构造就被放大因为 shift 和 rolling 都依赖行序。解决进特征工程之前先做三步清洗。按时间列排序、按时间列去重保留规则要写进文档通常是保留最后一条或取均值、检查时间间隔是否均匀。间隔不均匀的话先重采样到固定频率再补缺失值。df df.sort_values(timestamp).drop_duplicates(timestamp, keeplast) df df.set_index(timestamp).asfreq(h) # 重采样到小时级缺失处变 NaN df[value] df[value].interpolate(methodtime, limit3) # 最多补 3 个点limit 参数要设不能无限插值。连续缺失超过 3 个点的区间插值出来的数没有意义宁可标记成缺失让模型自己处理。5.4 训练与推理特征不一致现象线下评估一切正常推理脚本跑出来的结果明显偏离或者直接报特征维度不匹配。原因训练时特征列的顺序、缺失值填充方式、类别编码规则在推理脚本里被重新实现了一遍两边的逻辑有了细微差异。最常见的是特征列顺序不同——XGBoost 按列位置匹配特征顺序错了不会报错只会静默地算错。解决特征工程的函数只写一份训练和推理都调用它。特征列清单在训练结束时存成文件推理时读回来按清单顺序重排。import json # 训练结束 json.dump(feature_names, open(models/feature_names.json, w)) # 推理之前 feature_names json.load(open(models/feature_names.json)) X_infer X_infer.reindex(columnsfeature_names, fill_value0)reindex 这一步是后悔药缺列补 0、多列丢掉、顺序拉齐三件事一次做完。5.5 指标选错与单点指标陷阱现象汇报时被问“你这个 MAPE 是 300%怎么回事”或者“准确率 85% 但少数类一个没识别出来这模型能用吗”。原因只盯一个总指标没看分布。MAPE 在目标值接近 0 时天然会爆准确率在类别不均衡时天然会虚高。这两个指标单独拿出来都能骗人。解决回归至少报 RMSE 和 MAE 两个MAPE 作为补充并注明剔除了多少条接近 0 的样本分类至少报宏平均 F1 和混淆矩阵准确率放在最后当参考。评估脚本里把这几个指标固定输出不给“只挑好看的报”留空间。6. 验收与答辩用一套指标表和复现流程证明方案有效验收这件事说白了就是让别人在没参与过项目的情况下照着你的材料能跑出一样的数。我一般准备一张验收表逐项打勾缺一项就不算交付完成。验收项检查内容通过标准数据可追溯raw 目录未被修改清洗脚本可重跑从 raw 重跑能得到一致的 processed切分正确训练集时间全部早于测试集断言检查通过无重叠区间特征可复现特征列清单落盘推理按清单重排训练与推理特征顺序完全一致回归指标RMSE、MAE 相对基线有下降至少优于“用上一个点”的朴素基线分类指标宏平均 F1 与混淆矩阵少数类召回率不为 0推理入口predict.py 单文件可独立运行输入原始格式数据输出预测结果依赖锁定requirements.txt 版本固定换机器安装后结果一致答辩现场的提问基本集中在三块数据怎么切的、特征有没有偷看未来、指标为什么这么选。前两个问题在 3.3 和 5.1、5.2 里已经埋好答案第三个问题把 4.3 那张指标表拿出来讲就行。有个小技巧提前把残差图和混淆矩阵打印出来放在手边被问到“模型哪里不行”的时候直接展示比临场解释有说服力得多。复现流程要现场演示一遍从跑通 predict.py 开始到输出一张预测曲线图结束。这条链路能跑通说明前面所有环节都是连着的不是一堆散落的 notebook。演示之前在自己机器上清空环境重装一遍依赖这一步能提前暴露 80% 的环境问题。从那以后我每次交方案都会在验收前强制走一遍“换机器重跑”找一台没装过项目依赖的机器。因为我看过太多在自己电脑上跑得好好的项目换台机器就崩在版本差异上。希望这套结构能帮到你照着搭一遍剩下的就是把数据换成自己的。本文还有配套的精品资源点击获取