1. 时间序列特征到底难在哪一次失败的复盘先说个我印象很深的事。早几年接手一个销量预测的活儿手上有一张按天记录的长表字段干净、量级也不小我按做常规表格特征的思路走了一遍缺失值填充、类别编码、标准化然后随手train_test_split切了个 8:2跑梯度提升树验证集上的误差指标漂亮得让人心里发毛。模型上线之后前两周还算正常第三周开始明显偏了预测值整体虚高业务方直接找上门。回去翻代码才发现两个要命的地方一是随机切分把未来的样本混进了训练集模型等于提前“看过答案”二是滑窗均值忘了shift(1)当天特征里包含了当天的标签信息。这两处都属于时间序列特征工程里最典型的坑跟模型本身一点关系都没有。所以这篇想聊透一件事时间序列特征和普通表格特征表面看都是往 DataFrame 里加列骨子里的逻辑完全是两套。普通表格特征假设样本独立同分布打乱顺序不影响任何东西而时间序列的每一个观测点都挂着一个时间戳前后之间天然存在依赖今天的数据里藏着昨天的影子明天又不能拿来用。这个“依赖”既是信息的来源也是泄漏的入口处理好是金矿处理不好就是自欺欺人。这篇东西适合谁看如果你正在做销量预测、流量预测、用户行为预测、设备指标预警、金融序列建模这类活儿手里有一张带时间戳的长表正准备往上堆特征那这篇基本能覆盖你 80% 的场景。刚入门的朋友可以照着代码段直接跑已经做过几轮的人可以重点看第 4 章和第 5 章那两块是我踩坑踩出来的。我不打算讲成教科书就按实际做一个项目的顺序从坑、到骨架、到代码、到验证、到排查一路捋下去。1.1 时间序列特征和普通表格特征的根本区别最本质的区别在样本之间的顺序不可交换。表格数据里你把第 3 行和第 900 行对调模型学到的东西一模一样时间序列里这么干等于把因果链条剪断了。这就带来两个直接后果特征的构造必须严格遵循“只用当前时刻及之前的信息”验证集的切分必须按时间先后。第二个区别是特征本身会随时间漂移。一个用户过去 90 天的平均下单金额在促销季和非促销季的分布完全不是一回事。表格特征里我们顶多关心训练集和测试集的分布差异时序特征里这个差异是持续演化的你昨天算出来的“用户活跃度分位”今天可能已经失效。第三个区别是缺失的处理方式完全不同。表格里缺失往往意味着“没记录”可以填均值、填中位数时序里缺失可能是“这段时间真的没有发生”比如某门店某天零销售你把它填成历史均值等于凭空造了一个不存在的观测后面所有滑窗统计全部被污染。这个判断只能靠业务理解没有通用解法。注意时序特征的“正确性”不是看它在训练集上表现多好而是看它在时间上能不能稳定复现。离线指标虚高的模型十有八九是特征里混进了未来信息。1.2 三类最常见的时序特征陷阱第一类是随机切分导致的评估失真。这是最普遍的问题很多人默认train_test_split(shuffleTrue)在时序场景下等于把未来样本喂给训练。正确的做法是时间序列交叉验证第 4 章会展开。第二类是滑窗与聚合函数的方向错位。rolling(7).mean()默认窗口是包含当前行的如果你要预测的就是当前行的值那这个特征里直接含了标签。必须rolling(7).mean().shift(1)把窗口整体往后挪一格。expanding()、cumsum()、groupby().transform(mean)全都有同样的问题一个都不能漏。第三类是全局统计量污染。比如对整列做StandardScaler、用全量数据算用户历史均值、用全量数据做目标编码这些操作都把未来分布带进了训练。标准化要改成在训练窗口上fit、在验证窗口上transform用户历史均值要改成expanding().mean().shift(1)让它随时间为每个点只看到过去。2. 特征骨架设计按信息层级拆成四层我现在的习惯是先不写代码拿张纸把特征按“信息从哪来”分成四层再逐层落地。这么做的原因很实际分层之后哪一层引入了泄漏、哪一层贡献最大一目了然排查时不用在一百多列里瞎找。2.1 第一层时间戳自身携带的日历特征时间戳本身就是特征源而且这一层几乎零成本、零泄漏风险因为它是确定性的。从dt属性里能拆出来的东西小时、星期几、月中第几天、年内第几周、是否周末、是否月初月末、是否季度末。这些东西看着朴素但在很多业务里解释力极强比如用电负荷的日内双峰、零售的周末效应、财务类指标的月末冲量。两个需要留意的点。一个是周期编码星期几是 1 到 7 的循环量直接当数值喂给线性模型或者基于距离的模型是错的7 和 1 明明只差一天数值上却差了 6。正确做法是正弦余弦编码第 3 章会给公式。另一个是节假日特征这类信息必须靠外部日历表打进来而且要区分“节前”“节中”“节后”很多品类是节前冲量、节中归零粗暴地打一个“是否节假日”标签反而误导模型。我通常还会加一列“距上一个特殊日的天数”和“距下一个特殊日的天数”这两个连续量比 0/1 标签更能表达梯度效应。比如大促前 3 天、前 2 天、前 1 天的流量爬坡形态是连续的用两个距离列就能让模型自己学出来。2.2 第二层历史值与滞后特征滞后特征就是shift(k)把过去第 k 个时刻的值搬过来当特征。这是时序特征里信息密度最高的一层也是最容易出问题的一层。之所以重要是因为它直接把“上一期发生了什么”明明白白摆给模型看。滞后阶数怎么定不能拍脑袋。我的做法是先画自相关图看 ACF 在哪些滞后处显著超出置信带。一般日频序列在 lag 1、lag 7、lag 14、lag 28 上会有明显峰值分别对应短期惯性和周周期、双周周期、月周期。把 ACF 显著的几个滞后点选进来剩下的交给模型自己去组合。选太多滞后列会造成严重的共线性尤其是 lag 1 到 lag 7 全放进去相邻列相关系数经常在 0.95 以上树模型还能扛线性模型会明显不稳。还有一个细节滞后特征在序列开头必然产生缺失。前 7 行做shift(7)之后全是 NaN。这些行不能简单填 0因为 0 在业务上可能有真实含义比如真实销量为零填 0 会让模型把“数据还没开始”和“真的没有”混为一谈。我的处理方式是加一列“历史可用长度”标记或者在窗口统计时用min_periods控制让早期样本的统计量基于更短的窗口计算同时把它标记出来。2.3 第三层窗口聚合统计这一层是把过去一段时间“压缩”成一个数均值、标准差、最大最小、中位数、分位数、计数、非零天数、唯一值个数。它的价值在于表达“水平”和“波动”两个维度很多业务判断依赖的是波动而不是绝对值——一个销量稳定在 100 的店和一个在 0 到 300 之间来回跳的店平均一样但补货策略完全不同。窗口长度的选择有个经验法则至少覆盖 2 到 3 个完整周期。日频数据、周周期明显的话7 天、14 天、28 天、56 天各来一套分别对应“一周”“两周”“一个月”“一个季度”。别只放一个窗口多尺度的组合能让模型看到不同时间跨度上的形态差异。我一般固定 4 到 5 个窗口太多了特征维度爆炸收益递减得厉害。标准差、最大值这类统计量对异常值极其敏感一个刷单的极端值能在 28 天均值里留一个月。所以我习惯同时放均值和中位数让模型自己选或者对原始值先做一次分位数截断比如裁到 1% 和 99% 分位再做窗口统计。这个截断的阈值必须只用训练窗口的数据算这点在第 4 章还会提。2.4 第四层变化率、差分与趋势前三层描述的是“状态”第四层描述的是“动作”。差分diff(k)表达绝对变化变化率pct_change(k)表达相对变化两者在不同量级的实体之间表现差异很大。比如两个门店A 日均 1000B 日均 10同时增长 5A 的差分是 5、变化率是 0.5%B 的差分也是 5、变化率是 50%。如果你的业务关心的是“增长势头”变化率更合适关心的是“绝对缺口”差分更合适。再往上一层是趋势特征我常用的有两种。一种是线性拟合斜率取最近 N 个点做一元线性回归把斜率当特征这个量对“持续上升还是持续下降”非常敏感。另一种是当前值相对窗口均值的偏离度(x - rolling_mean) / rolling_std本质是个滚动 z-score用来表达“现在这个点有多反常”。还有一类容易被忽略的累计类特征。expanding().sum()、expanding().count()、距上次事件的天数。这类特征在用户行为建模里特别好用“注册至今累计下单次数”“距上次登录多少天”往往比近期滑窗更有解释力因为它承载的是长期偏好。3. 实操从原始长表到特征宽表的完整流程下面这段流程是我现在做时序特征的标准动作按顺序走基本不会出大问题。假设手上是一张(entity_id, ds, y)的长表一家店一天一行。3.1 数据准备与时间轴对齐第一步永远是把时间轴补齐。原始数据往往是不连续的某天没订单就整行缺失。如果不补shift(1)拿到的就是“上一个有记录的日子”而不是“昨天”所有滞后特征的时间语义全错。import pandas as pd import numpy as np df df.sort_values([entity_id, ds]).reset_index(dropTrue) df[ds] pd.to_datetime(df[ds]) # 为每个实体生成完整日期轴并左连接 full_idx ( df.groupby(entity_id)[ds] .agg(lambda s: pd.date_range(s.min(), s.max(), freqD)) .explode() .reset_index() ) df full_idx.merge(df, on[entity_id, ds], howleft) df[y] df[y].fillna(0) # 仅当业务上无记录零发生时才这样填这里那个fillna(0)是个业务判断题不是技术题。零售销量、页面曝光这类没记录基本等价于零但如果是传感器读数、库存余额缺就是缺得用前值填充或者标记缺失绝对不能填零。我见过把库存缺失填成 0 导致模型学出“库存归零就大卖”这种荒谬规律的上线后补货建议直接失控。补齐之后还要检查频率一致性。原始数据可能是天级但业务上真正有意义的粒度是周。这时候应该先resample(W).sum()聚到周再做特征而不是在天级上做特征然后硬凑到周。粒度和特征窗口必须匹配一个 7 天的滑窗放在天级数据上和放在周级数据上含义差得远。3.2 滞后与滑窗特征的批量生成核心就一条铁律任何用到 y 的统计必须整体shift(1)。我习惯写成一个函数把 shift 统一放在最后做避免漏。def make_lag_features(g, lags(1, 2, 3, 7, 14, 28), windows(7, 14, 28, 56)): out g[[ds]].copy() y g[y] # 滞后 for k in lags: out[flag_{k}] y.shift(k) # 滑窗统计先 rolling再整体 shift(1) for w in windows: r y.rolling(w, min_periodsmax(2, w // 3)) out[fmean_{w}] r.mean().shift(1) out[fstd_{w}] r.std().shift(1) out[fmed_{w}] r.median().shift(1) out[fmax_{w}] r.max().shift(1) out[fmin_{w}] r.min().shift(1) out[fnz_{w}] (y 0).rolling(w, min_periods1).sum().shift(1) # 差分与变化率 for k in (1, 7, 28): out[fdiff_{k}] y.diff(k).shift(1) out[fpct_{k}] y.pct_change(k).replace([np.inf, -np.inf], np.nan).shift(1) # 滚动 z-score m y.rolling(28, min_periods7).mean().shift(1) s y.rolling(28, min_periods7).std().shift(1) out[zscore_28] (y.shift(1) - m) / s.replace(0, np.nan) # 趋势斜率 out[slope_14] y.rolling(14, min_periods7).apply( lambda a: np.polyfit(np.arange(len(a)), a, 1)[0] if len(a) 1 else np.nan, rawTrue).shift(1) return out feat (df.groupby(entity_id, group_keysFalse) .apply(make_lag_features) .reset_index(dropTrue))min_periods这个参数值得单独说一句。默认情况下rolling(28)前 27 行全是 NaN等于白白浪费一个月的样本。设成w // 3之后窗口内只要有 9 个点就算早期样本也能用上代价是早期统计量的方差偏大。我的做法是加一列history_len该实体到当前点的累计天数让模型知道这个统计量是基于多长的历史算的它自己会调整信任度。rolling.apply的斜率计算比较慢数据量大时建议换成向量化的方式预先算好cumsum(x)和cumsum(x * t)用最小二乘的闭式解算斜率速度快一个量级以上。我做过对比百万行规模下.apply要跑几分钟向量化版本不到一秒。3.3 参数怎么定滞后阶数、窗口长度与半衰期滞后阶数的确定我一般看 ACF。具体做法是对每条实体序列算自相关取所有实体 ACF 的平均曲线找显著峰。判断标准是|ACF| 1.96 / sqrt(n)n 是序列长度。日频销量数据通常会在 7、14、28 上出峰偶尔在 364年周期上也有一个弱峰那就把 1、2、3、7、14、28 放进去再补一个 364 看效果。窗口长度按“覆盖 2 到 3 个周期”来定我一般给 7 / 14 / 28 / 56 四档。窗口太短噪声大太长则反应迟钝——一个 90 天均值在突发断货时几乎察觉不到变化。多档并行是性价比最高的做法让模型自己在不同尺度上分配权重。指数加权EWM是个很实用的替代方案它对近期给更高权重、对远期衰减比等权滑动平均更贴近“记忆随时间淡化”的直觉。关键是halflife和alpha的换算$$\alpha 1 - e^{-\ln 2 / \text{halflife}}$$反过来说如果你心里想的是“大约 7 天前的数据权重降到一半”那 halflife 就是 7换算出来alpha ≈ 0.0943ln2 ≈ 0.69310.6931 / 7 ≈ 0.0990e 的 -0.0990 次方约 0.90571 减即 0.0943。这个值比常见的alpha0.3平缓得多在实际的日频业务序列里通常更稳。alpha 1 - np.exp(-np.log(2) / 7) # 0.0943 out[ewm_7] y.ewm(alphaalpha, adjustFalse).mean().shift(1)注意ewm()同样会包含当前点必须.shift(1)。adjustFalse在数据量较小时更接近标准递推定义一般用它。3.4 编码与降维周期性特征的正弦余弦编码周期量的编码公式不复杂第 t 个时刻、周期为 T$$\text{sin_enc} \sin\left(\frac{2\pi t}{T}\right), \quad \text{cos_enc} \cos\left(\frac{2\pi t}{T}\right)$$星期几用 T7小时用 T24月份用 T12。这么编码的好处是保留了循环距离——星期日和星期一在嵌入空间里是相邻的而直接当整数用则把它们拉到了最远。d df[ds].dt df[dow_sin] np.sin(2 * np.pi * d.dayofweek / 7) df[dow_cos] np.cos(2 * np.pi * d.dayofweek / 7) df[hour_sin] np.sin(2 * np.pi * d.hour / 24) df[hour_cos] np.cos(2 * np.pi * d.hour / 24)如果周期信号不是单一正弦形态比如一天里早高峰、午高峰、晚高峰三个峰单靠 sin/cos 不够可以叠加傅里叶项按周期 T 展开 k 阶谐波k 取 3 到 5 基本能拟合绝大多数日内形态。做法是用sin(2πkt/T)和cos(2πkt/T)k 从 1 到 K每个 k 贡献两列。K 太大容易过拟合我一般从 K3 起步看验证集指标再往上加。还有一种非常实用的降维用历史同期分位替代原始值。比如“去年同一天的值”“上月同一天的值”直接放进模型容易受异常值影响改成“当前值在过去 3 年同一天的分位”就更鲁棒。这个特征在季节性极强的业务里电力、农业、旅游效果显著。4. 验证与防泄漏时序特征工程的生死线特征做得再花哨验证不严谨就是自娱自乐。这一章是整篇里我最想强调的部分。4.1 时间序列交叉验证的正确切法时序交叉验证的核心是训练窗口始终在验证窗口之前且中间最好留一个间隔gap。为什么要有 gap因为很多特征用了滞后和滑窗训练集最后几行的特征里其实已经“看”到了验证集前几天的值不留 gap 就等于让训练集偷偷摸到了验证集的边界。from sklearn.model_selection import TimeSeriesSplit tscv TimeSeriesSplit(n_splits5, test_size28, gap28) for tr_idx, va_idx in tscv.split(X): Xtr, Xva X.iloc[tr_idx], X.iloc[va_idx] m model.fit(Xtr, y.iloc[tr_idx]) pred m.predict(Xva)gap28的意思是训练集末尾砍掉 28 行不看用这 28 行当缓冲。这个值设成和最大特征窗口一致最稳妥——你的最大窗口是 56 天gap 就设 56保证训练集最后一行用到的历史信息全部落在验证集之前。还有一种更贴近生产的验证法滚动回测。固定一个起点每次向前滚一天或一周用过去所有数据训练、预测下一天滚动 N 次取平均。这玩意儿算起来慢但对模型上线后的表现估计最准。我在正式定版前一定会跑一次滚动回测跟交叉验证的结果对比如果差异很大说明模型对时间位置敏感得回去查特征。多实体场景还有个额外的坑按实体切分还是按时间切分。如果你要预测的是全新实体那应该留出一批实体完全不参与训练如果是预测已知实体的未来那就在时间上切。这两个评估口径给出的分数经常差很远一定要跟业务方确认上线后是哪种情形。4.2 特征泄漏的四种典型形态与排查方法第一种滑窗方向错误。前面说过凡是用到 y 的聚合必须 shift。排查方法很机械写完特征之后人为把验证集最后一段的 y 全部改成 NaN 或者极大值重跑特征生成如果训练集的特征值发生变化说明有数据穿越。这个“污染测试”我每次都会做一遍五分钟的事能揪出大部分隐蔽问题。第二种目标编码的全局计算。类别型字段做目标编码时如果用的是全量数据的 y 均值那就是赤裸裸的泄漏。正确做法是按时间做 expanding 编码每个时刻的编码值只用该时刻之前的数据算同时加平滑项(sum prior * m) / (count m)m 一般取 10 到 50防止小样本类别编码值极端。第三种标准化的全量 fit。StandardScaler().fit_transform(X)这种写法在时序里是错的因为 fit 用到了未来的均值和方差。必须改成滚动标准化或者至少只在训练窗口上 fit。树模型对单调变换不敏感这个问题影响相对小但线性模型、神经网络上会明显吃亏。第四种补齐与插值时越界。interpolate()默认是线性插值在序列末尾的缺失会用前面的值外推看着没毛病但interpolate(methodpolynomial)或者bfill()就会把未来的值搬到过去。我踩过bfill的坑某次数据清洗时顺手加了一个fillna(methodbfill)整个特征集的泄漏率飙升还是靠污染测试才发现的。泄漏形态典型写法排查手段修正方式滑窗方向错rolling(7).mean()后不 shift污染测试末尾统一.shift(1)目标编码全局算groupby(cat).y.transform(mean)检查编码列与 y 的相关性是否异常高改 expanding 编码加平滑标准化全量 fitfit_transform(X)检查是否在切分前做变换训练窗 fit验证窗 transform插值越界bfill()、多项式插值污染测试 检查首尾行只用前向填充或标记缺失4.3 特征筛选与稳定性检查时序特征很容易堆到几百列其中一大半是高度共线的。我一般分三步筛。第一步看特征重要性在时间上的稳定性。把验证集按时间切成几段每段单独算一次特征重要性排名如果某个特征在早期重要、晚期完全不重要说明它捕捉的是阶段性噪声可以直接砍。我做过一个粗暴但有效的实现算每个特征在 5 个时间片段里重要性的排名方差方差大的优先剔除。第二步看PSI群体稳定性指数。把特征值按训练期分布分箱算验证期与训练期在各箱上的占比差异PSI 超过 0.1 就要留意超过 0.25 基本可以考虑删掉或者做变换。时序特征里 PSI 高的往往是那些绝对量级的特征比如“上个月总销量”遇到业务规模变化就会漂移而分位、比率类特征稳得多这也是我更偏爱比率特征的原因之一。第三步做消融对比。按层级拆开跑只有日历特征、加滞后、加滑窗、加差分一层层加上去看每层的边际贡献。如果加完第四层指标反而掉了说明过拟合回头砍特征而不是加特征。这个流程走一遍心里对“哪层在真正起作用”会非常清楚后面做特征迭代也有方向。5. 常见问题与排查速查表这一章是我平时速查用的基本覆盖了 90% 的翻车现场。5.1 高频报错与异常现象预测值整体平移。最常见原因是训练集和验证集的 y 分布不一致比如中间做过一次业务口径调整。另一类原因是滞后特征的时间对齐错了——shift是按行移的如果时间轴没补齐移一行不等于移一天。排查办法随便挑一个实体把这个实体某几天的原始值、lag_1、lag_2 打出来肉眼对一遍十秒钟就能确认。模型在验证集上极好但上线后崩。九成是泄漏。跑污染测试检查所有transform、groupby、fillna的位置。还有一个隐蔽来源如果特征生成和模型训练在同一个脚本里跑很容易不小心在全量数据上做了一次 groupby 聚合再切分这种顺序错误肉眼极难发现建议把特征生成和切分严格拆成两步中间落盘。训练集损失很快降到很低验证集不收敛。时序数据里这通常是特征量纲差异过大导致的比如有的列是 0 到 1 的比率有的是几十万的累计量。树模型还能扛神经网络基本必崩。处理方式比率、分位、z-score 这类无量纲特征优先用原始量级特征做 log 变换注意 log(0) 要给log1p。不同实体的特征分布差异巨大。集团型客户和零散客户的日销量差三个数量级直接混在一起训练模型会把大部分容量花在拟合大客户上。两种处理一是对每个实体做局部标准化把特征转成该实体历史分位二是分群建模按规模分层各训一个。我倾向于前者维护成本低效果也够。加入新特征后指标反而变差。先别急着删检查是不是特征里有大量 NaN 导致样本被整行丢掉。rolling产生的 NaN 如果没处理dropna()一执行训练样本可能少了一大半剩下来的全是有长期历史的老实体样本选择偏差就出来了。现象高概率原因快速验证离线好、线上崩特征泄漏污染测试预测整体偏移时间轴未补齐 / 口径变化单实体逐日核对收敛慢或发散量纲差异大检查各列分位数跨度大客户主导实体规模未归一按实体做分位变换样本量莫名变少NaN 导致整行丢弃统计 dropna 前后行数5.2 上线后效果衰减的排查路径线上效果随时间衰减是时序模型的常态关键是分清是“正常漂移”还是“结构性故障”。我按这个顺序查先看特征分布的 PSI 曲线。把上线后每周的特征分布跟训练期比如果只有少数几列 PSI 超标那大概率是业务侧发生了变化比如新增了一个渠道针对性调整那几列就行。如果大部分列都在漂说明整体业务形态变了得重新训练。再看残差的时间结构。把预测残差按时间画出来如果残差在某个时间点之后出现系统性偏移一直是正或一直是负说明模型漏掉了某个结构性变化常见的是节假日表没更新、新增了周期性活动。如果残差是随机分布的但方差变大那是噪声水平上升考虑加正则或者缩短训练窗口。最后看滞后特征的时效性。有些业务的数据回传有延迟比如 T1 才拿到昨天的真实值上线初期数据源正常某天开始延迟变成 T2滞后特征就全部错位一天。这种问题的特征是“指标突然掉一截然后稳住”因为它不随机是系统性的。对策是在特征生成环节加一个数据新鲜度校验当日志里最新数据日期落后预期就告警别等模型指标掉了才发现。注意训练窗口的长度也需要定期重新评估。业务稳定的场景用长窗口没问题业务快速变化的场景长窗口反而拖后腿。我的经验是日频数据保留 1 到 2 年、周频保留 2 到 3 年同时配一个 3 个月的短窗口模型两个模型的结果做加权兼顾稳定性和敏捷性。6. 我个人在这块的一点体会做了这么多轮时序特征最大的感受是特征工程的收益八成来自把时间语义理清楚两成来自花哨的算法。我见过太多人在傅里叶项、小波变换上折腾很久收益还不如老老实实把shift修正、把时间轴补齐来得大。还有一个习惯值得分享每加一批特征我都会留一份“特征字典”记清楚每一列的生成逻辑、用到的时间范围、依赖了哪些原始字段。这个习惯救过我好几次——线上出问题时能在几分钟内定位到是哪一列的特征生成逻辑有问题而不是对着几百列猜。字典不需要多正式一个 Markdown 表格就够列名、口径、时间窗口、是否用到 y、是否需要 shift五行信息写的时候多花十分钟排查时省几小时。最后说个具体的小技巧。如果你不确定某个窗口长度该取多少别猜直接跑一个网格把 7、14、21、28、42、56、90 都做一遍用同一套交叉验证跑看指标随窗口长度的变化曲线。这条曲线通常是有峰值的峰值位置就是你这个业务的最优尺度而且它往往跟你凭直觉猜的不一样。我做过好几次直觉给的 7 天实际最优在 21 天附近原因很简单——业务的下单决策周期本来就是两三周。数据比直觉靠谱这句话在时序特征上体现得格外明显。