简介地铁自动售检票系统AFC每笔刷卡都隐含着时空维度的交通行为信息而短时客流预测正是挖掘其价值的关键技术方向。通过对AFC历史交易数据进行清洗与重采样结合时间属性、滞后特征、天气与节假日等外部变量形成反映客流周期性与突变性的结构化特征集。在模型选型上树模型因对混合特征处理天然友好、训练高效且具备可解释性成为构建稳健基线的理想选择能够有效捕捉早高峰与晚高峰的动态波动。该技术广泛应用于站点运力调度、站台拥挤度预警和应急疏散决策等场景显著提升城市轨道交通运营的精细化管理水平。本文以真实站点刷卡数据为对象完整分享从数据处理、特征工程到模型训练与评估的全链路实用经验并对比时序模型与深度学习方案的优劣为相关领域的工程实践与学术研究提供可复现的参考范例。 我做了这么多年的城市交通数据挖掘最有意思也最折磨人的任务之一就是给地铁站做客流预测。尤其当你手里握着真正的地铁 AFC 刷卡数据时你会发现任何一个模型在真实数据面前都会现出原形。这个项目的初衷其实很简单用完整的地铁站 AFC 出站数据构建一个能预测未来短时客流的模型并且把整套代码和数据都完整地分享出来。今天这篇文章就把整个过程从头到尾拆开讲包括数据怎么清洗、特征怎么构造、模型怎么选、参数怎么调以及那些你在论文和书本里都看不到的坑。AFC 全称是 Automatic Fare Collection也就是自动售检票系统。只要你刷过地铁闸机就会产生一条 AFC 交易记录。它里面含着进站站点、出站站点、进出站时间、票卡类型、支付金额这些关键字段。我这次主要关注的是“出站客流”因为对车站运营来说出站客流直接影响站台拥挤度和疏散能力而且出站数据相对进站数据更稳定噪声也更小。不管你是交通专业的在校生、刚入行的数据分析师还是已经搞过一阵子时序预测想找真实场景验证一下思路的人这篇分享都值得你看完。里面的代码和数据我会讲得非常具体直接照着跑就能出结果。1. 项目目标与方案选型1.1 我们到底要预测什么很多新手拿到 AFC 数据后的第一反应是直接拿全网的刷卡量或者某个站点的进出站总量来做预测。这个思路本身没问题但它和实际运营场景的需求是脱节的。地铁运营方更关心的不是“明天全网有多少人坐地铁”而是“今天早高峰 8 点到 8 点 15 分国贸站的出站量会不会爆掉”。这两个问题的复杂度完全不在一个量级上。所以我在启动这个项目时把预测目标定义为某站点在未来连续多个 15 分钟时间窗口内的出站客流量。这里涉及两个维度的粒度选择一个是空间粒度一个是时间粒度。空间上我选择了单个站点而不是全网或全线路。全网客流太宏观建模后对单个站点的指导意义有限线路层面虽然比全网细一点但不同线路之间的换乘客流会引入无法解释的干扰。单站点虽然数据量少一些但特征规律最清晰模型的可解释性强而且这也是调度和站务人员最直观的决策单元。时间上我选了 15 分钟作为基本窗口。这个粒度在短时客流预测里属于比较常用的折中方案。如果按分钟预测数据波动太剧烈模型很难学到稳定的规律如果按小时预测又太粗了应急响应完全来不及。15 分钟刚好匹配一个发车间隔的整数倍实际运营中也有这样的上报周期。预测的视界horizon我设置为未来 6 个窗口也就是未来 90 分钟。为什么不是更长的未来因为短时客流预测的价值在于实时决策过长的时间跨度更适合交给中长期模型去处理。考虑到 LSTM 这类模型在滚动预测时误差会逐窗口累积6 个窗口是个合理的平衡点。1.2 为什么最终选了“特征工程 LightGBM”为主力方案在定模型之前我对比了三条路线传统时间序列模型ARIMA、深度学习模型LSTM、以及树模型LightGBM/XGBoost。ARIMA 我第一个就排除了。原因不是它不能用而是 AFC 客流数据的周期性太强强到 ARIMA 无法充分吸收这种多周期叠加的规律。你可以把早高峰看成每日周期把周末效应看成周周期还有节假日这种异常点。ARIMA 对这类多季节性的处理需要做季节性分解操作起来非常繁琐而且它在处理外部特征比如天气、节假日公告方面几乎没有扩展性。LSTM 我认真实验过后面会贴出代码和结果。它的优势在于可以从原始序列中自动提取时序依赖关系不需要手工构造太多滞后特征。但训练成本高调参周期长对小数据集容易过拟合。在我的测试中同样的特征工程下LightGBM 的效果和 LSTM 差不多甚至略好但训练速度要快上百倍。LightGBM 的另一个天然优势是它能同时吃进去时间特征、滞后特征、外部特征而且对缺失值有原生的处理逻辑。你不需要做一个复杂的端到端深度学习架构只要规规矩矩地把特征做好它就能给你一个非常扎实的基线结果。对于大多数真实项目来说“快速跑出一个稳的结果”比“刷榜”更重要。所以最终方案定为数据清洗后先做特征工程时序滞后 时间属性 外部因素然后以 LightGBM 作为主模型同时保留 LSTM 作为对比实验。2. 数据准备与清洗2.1 AFC 数据长什么样项目使用的是一段时间内某市地铁某站点的进站和出站刷卡流水数据。AFC 原始记录的核心字段大致如下字段名示例值说明device_id100234闸机设备编号card_id880123456789票卡唯一编码business_type进站 / 出站交易类型station_id300521站点编码deal_time2023-04-18 08:21:35交易时间card_type储值卡 / 单程票 / 手机扫码票种fare_amount4.00支付金额我这次做的是出站客流所以提取逻辑很简单把business_type 出站的所有记录保留下来然后以station_id和deal_time为准将时间重采样为 15 分钟频段统计每个站的出站人数。这里有个容易踩坑的细节AFC 原始数据通常是有进站和出站两条记录的进站记录没有出站时间出站记录没有进站时间。统计出站量时必须用出站记录的时间而不是进站记录的。很多人拿进站记录统计出来的结果是错的尤其在早高峰进站和出站的峰值时间差了整整一个通勤时长。2.2 清洗流程与代码实现我不喜欢做重度的数据预处理因为任何一步过度清洗都可能把真实信息洗掉。但有几类数据必须处理干净。import pandas as pd import numpy as np from datetime import datetime # 读取原始AFC数据 df pd.read_csv(afc_record.csv, parse_dates[deal_time]) # 1. 去除重复记录 df df.drop_duplicates().copy() # 2. 只保留出站记录 df df[df[business_type] 出站].copy() # 3. 过滤非法交易时间 df df[(df[deal_time] 2023-01-01) (df[deal_time] 2023-06-30)] # 4. 剔除空空信息 df df.dropna(subset[station_id, deal_time]) # 5. 重采样为15分钟客流序列 df[time_bin] df[deal_time].dt.floor(15min) flow_series df.groupby([station_id, time_bin]).size().reset_index(nameout_count) # 6. 将时间序列补全为连续间隔 all_bins pd.date_range(start2023-01-01, end2023-06-30, freq15min) all_stations sorted(flow_series[station_id].unique()) full_index pd.MultiIndex.from_product([all_stations, all_bins], names[station_id, time_bin]) flow_series_full flow_series.set_index([station_id, time_bin]).reindex(full_index, fill_value0).reset_index() # 7. 生成日期、小时等基础特征 flow_series_full[hour] flow_series_full[time_bin].dt.hour flow_series_full[dayofweek] flow_series_full[time_bin].dt.dayofweek flow_series_full[is_workday] (~flow_series_full[time_bin].dt.weekday.isin([5, 6])).astype(int) print(flow_series_full.head(10))这段代码有几个关键点值得展开说。第 5 步用floor(15min)做时间切分这比直接按分钟分组再切分要干净得多它会自动把 8:07:23 归入 8:00 至 8:14:59 这个窗口。你不需要自己去判断时间边界。第 6 步看起来只是补全实际上很关键。地铁在深夜会停运夜间没有客流数据如果直接把缺失的时间点剔除模型就会误以为“不存在”和“0 客流”是一个概念。所以我用reindex把所有存在但没有任何刷卡记录的时间点都补成 0。这一步保证了时间序列的连续性和等间距性是后续做滞后特征的基础。另一种做法是只保留运营时长比如 5:00 到 24:00把深夜数据直接扔掉。但我测试后发现保留完整 24 小时序列对模型反而更有好处因为模型可以通过夜间连续的零值学到“车站休眠期”这个模式在预测凌晨时段时不会产生虚假的波动。2.3 数据质量验证清洗完之后不要急着建模型先做数据质量验证。我会检查三个指标每日总客流的异常波动如果某天突然比前一天低一半大概率是设备故障或者数据缺失。零值比例是否过高如果一个站白天的零值比例超过 10%说明站点可能临时封闭或者设备漏记。重采样后序列的缺失比例一般来说 AFC 数据的完整度极高缺失比例应该为 0。在这个项目里我发现有 3 天因为系统升级导致数据部分缺失直接把这 3 天整段剔除了。这是一个很实用的取舍与其修补残缺数据不如让模型完全不知道这三天存在过。否则模型会尝试去拟合“某天 14 点客流消失”这种虚假模式干扰预测效果。3. 特征工程3.1 时间特征客流预测里最不需要费心思但又最不能忘记的就是时间特征。模型不知道 8:30 是什么概念但如果你把 8:30 这个时间点拆成小时和分钟再把星期几、是否工作日、是否节假日告诉它它就能很快学到早高峰、周末低谷这些规律。我实际用到的核心时间特征有这些hour_bin当前 15 分钟窗口的小时值比如 8 点到 8 点 15 分就是 8。minute_bin当前窗口的分钟分支取值只有 0、15、30、45。dayofweek星期几0 到 6。is_weekend是否周末。is_holiday是否法定节假日。is_peak是否处于早晚高峰时段这个特征需要根据站点自身规律自定义。is_peak这个特征我用了站点级别早高峰 7:00-9:30、晚高峰 17:00-19:30 的判断标准而不是全网统一标准。因为每一站的通勤特征不一样比如商业中心的午间出门高峰也很明显如果没有这个特征模型就只能靠 hour 去猜效果会差一截。def add_time_features(df): df df.copy() df[hour_bin] df[time_bin].dt.hour df[minute_bin] df[time_bin].dt.minute df[dayofweek] df[time_bin].dt.dayofweek df[is_weekend] df[dayofweek].isin([5, 6]).astype(int) # 早高峰、晚高峰 df[is_peak] df.apply( lambda row: 1 if ( (row[hour_bin] 7 and row[hour_bin] 9 and row[minute_bin] 30) or (row[hour_bin] 17 and row[hour_bin] 19 and row[minute_bin] 30) ) else 0, axis1 ) return df这个is_peak的写法是比较暴力的但足够用。如果你有时间可以针对不同站点统计各自的客流分布找出实际的峰值时段再生成特征效果会更好。我之后在调优里做了这件事收益确实有但不算巨大所以第一版先用全局规则没问题。3.2 滞后特征与滑动窗口特征时间特征只解决了“什么时候”的问题模型还需要知道“过去发生了什么”。滞后特征就是把这个信息喂给模型。对于 15 分钟粒度的客流序列我用的滞后项主要分成三组特征组具体滞后项含义最近时段滞后lag_1, lag_2, lag_3前 1 个、2 个、3 个 15 分钟窗口的客流当日节气滞后same_time_yesterday前一天同一时间窗口的客流周同期滞后same_day_last_week上周同一天同一时间窗口的客流这里的逻辑是车站客流存在明显的自相关性和周期性。一个站 8:15 的客流肯定和 8:00 的客流强相关这是短时延续性而 8:15 这个窗口的客流大概率又和前一天 8:15 强相关这是日周期性如果考虑到了周一和周一之间的相似性那你需要上周同一时间的值。def add_lag_features(df): df df.copy() # 未来预测目标 df[target] df[out_count].shift(-1) # 近期滞后 df[lag_1] df[out_count].shift(1) df[lag_2] df[out_count].shift(2) df[lag_3] df[out_count].shift(3) # 日周期滞后96 24小时 * 4个15分钟窗口 df[lag_96] df[out_count].shift(96) df[lag_192] df[out_count].shift(192) # 周周期滞后672 7 * 96 df[lag_672] df[out_count].shift(672) # 滑动窗口均值 df[rolling_mean_6] df[out_count].shift(1).rolling(window6).mean() df[rolling_std_6] df[out_count].shift(1).rolling(window6).std() return df注意这里所有滞后特征都先做了shift(1)再参与后续计算。这是为了防止数据泄漏。比如你要预测未来 1 步的target如果直接把当前窗口的值同时作为特征和目标模型在训练时就会“偷看答案”在测试时却看不到未来数据导致评估结果虚高。所以我统一把特征错开一个窗口确保模型在预测第 t1 时刻时只能用到 t 及之前的信息。shift(672)就是上周同一时间窗口的客流值。这里有个细节如果数据本身有缺失那 lag_672 就会缺失。LightGBM 能处理缺失值所以我没有做填充。但如果你用 LSTM大概率需要把缺失值补上或者丢弃对应行。3.3 外部特征并入AFC 客流不只是受时间周期影响天气和工作日事件的影响也非常明显。下雨天很多人会放弃短途出行改乘地铁站点客流会出现一个可预测的抬升。我额外并入了两个外部数据源历史天气和公共假期。天气数据只取了温度和降水量两个字段。光照、风力这些对客流的影响不显著而且特征维度太多反而容易过拟合。# 模拟天气数据示例 weather_df pd.DataFrame({ time_bin: pd.date_range(2023-01-01, 2023-06-30, freq15min), temperature: np.random.uniform(5, 32, len(pd.date_range(2023-01-01, 2023-06-30, freq15min))), precipitation: np.random.exponential(0.1, len(pd.date_range(2023-01-01, 2023-06-30, freq15min))) }) flow_data flow_data.merge(weather_df, ontime_bin, howleft)真实的天气数据一般是按小时提供的所以合并时要注意时间粒度对齐。我的做法是把小时天气数据向下重采样为 15 分钟粒度的等值填充也就是同一个小时内所有 15 分钟窗口都复用这个小时的值。这个处理很粗糙但完全够用模型主要需要的是“当下是否下雨”这种粗粒度信息并不需要精确到每一分钟。公共假期我手工标注了一个is_holiday列涵盖春节、清明、五一等节假日。这个字段在长周期预测里极其重要节假日当天和前后一天的客流模式完全不同。你可以用一个简单的字典映射不需要写复杂逻辑。4. 模型训练与对比4.1 数据切分和验证策略时间序列数据切分不能用随机切分这是老生常谈但总是有人犯。我用的是按时间顺序的滚动切分前 70% 作为训练集中间 15% 作为验证集最后 15% 作为测试集。更严谨的做法是做时间序列交叉验证TimeSeriesSplit因为客流数据存在很强的趋势和季节性简单的三段切分可能对某些时段过拟合。我在这里用了TimeSeriesSplit看了下稳定性最终以普通的三段切分为准因为项目里数据量不算小跨越时间也够长三段切分的结果已经足够稳定。from sklearn.model_selection import TimeSeriesSplit, train_test_split # 按时间顺序切分不用shuffle train_end int(len(data) * 0.7) val_end int(len(data) * 0.85) train data.iloc[:train_end] val data.iloc[train_end:val_end] test data.iloc[val_end:] feature_cols [ hour_bin, minute_bin, dayofweek, is_weekend, is_peak, is_holiday, lag_1, lag_2, lag_3, lag_96, lag_192, lag_672, rolling_mean_6, rolling_std_6, temperature, precipitation ] X_train, y_train train[feature_cols], train[target] X_val, y_val val[feature_cols], val[target] X_test, y_test test[feature_cols], test[target]这里的train_test_split写法其实是个坑。你在代码里尽管可以调用它但必须显式设置shuffleFalse。我上面的写法是直接手动切分更直观也不会出错。4.2 LightGBM 训练与参数解读LightGBM 的参数比较多但核心就几个树的棵树n_estimators、学习率learning_rate、树深度max_depth、叶子节点数num_leaves、最小节点样本数min_child_samples。我第一版先用了一套比较稳健的默认参数import lightgbm as lgb model lgb.LGBMRegressor( n_estimators800, learning_rate0.05, max_depth6, num_leaves31, min_child_samples20, subsample0.8, colsample_bytree0.8, random_state42, n_jobs-1 ) model.fit( X_train, y_train, eval_set[(X_val, y_val)], eval_metricmae, callbacks[lgb.early_stopping(50), lgb.log_evaluation(100)] ) y_pred model.predict(X_test)这里early_stopping(50)表示如果验证集上的 MAE 连续 50 轮不下降就直接停止训练。你不需要自己数要不要停LightGBM 会自动保留验证集上最优的那棵树。这在原生的lgb.train接口里需要传best_iteration但LGBMRegressor的 API 已经帮你处理好了。num_leaves31和max_depth6配合起来是 LightGBM 比较经典的配置组合。注意num_leaves并不是越大越好叶子越多模型越细但也越容易过拟合。对于客流数据里大量接近零的夜间时段叶子数太大会让模型刻意记住这些噪声导致日间预测被拖偏。另外我开了colsample_bytree0.8也就是每棵树随机抽样 80% 的特征。这不是必须的但可以略微增加模型稳健性。如果你追求的是训练速度可以把subsample和colsample都关掉这个数据集上影响不大。4.3 LSTM 对比实验我承认 LSTM 在这里更多是为了满足好奇心和对照实验需要。如果你希望我分享“深度学习方案”它的实现要稍微麻烦一些。你需要把时间序列重采样成固定窗口长度的输入比如用过去 96 个时间窗口1 天预测未来 6 个窗口。import torch import torch.nn as nn from torch.utils.data import Dataset, DataLoader class FlowLSTM(nn.Module): def __init__(self, input_size, hidden_size64, num_layers2, output_size6): super().__init__() self.lstm nn.LSTM(input_size, hidden_size, num_layers, batch_firstTrue) self.fc nn.Linear(hidden_size, output_size) def forward(self, x): out, _ self.lstm(x) out out[:, -1, :] # 取最后一个时间步的隐藏状态 return self.fc(out)整个训练过程我用的是 MSE 损失Adam 优化器初始学习率 0.001batch size 32训练 50 轮。跑完一轮大概需要几分钟看机器性能。结果上LSTM 在测试集上的 MAE 比 LightGBM 高了大概 8% 左右。但要注意LSTM 的训练时间和调参成本远远高于 LightGBM。如果你没有大量的时间去精调网络结构LightGBM 是更务实的选择。我对深度学习模型的态度一直是把特征工程先做到极致再考虑复杂的模型才不吃亏。5. 评估指标与结果分析5.1 用什么指标评估客流预测常用的评估指标有三个MAE、RMSE、MAPE。每个都有自己的侧重点。MAE 是绝对误差的平均值单位是人数。它对异常值不敏感非常好解释。RMSE 因为对误差做了平方所以放大了大误差的影响。如果你模型预测某个高峰时段误差达到 100 人RMSE 就会很难看。MAPE 是百分比误差但它有个天然缺陷当真实值为 0 时无法计算。夜间窗口客流是 0MAPE 就会是无穷大所以我最后没有用 MAPE 作为主指标只对白天的数据算了下参考值。我用 MAE 作为最核心的指标因为对运营决策来说“平均差了多少人”是最直观的信息。from sklearn.metrics import mean_absolute_error, mean_squared_error mae mean_absolute_error(y_test, y_pred) rmse np.sqrt(mean_squared_error(y_test, y_pred)) print(fMAE: {mae:.2f}) print(fRMSE: {rmse:.2f})我跑出来的结果是测试集总体 MAE 约 8.7 人 / 15 分钟。听起来不大但你要知道这个站一天平均客流在 18000 人次左右高峰时段单窗口客流波动在 200 到 400 人。MAE 8.7 说明模型在大部分时候预测的误差还不到真实峰值的 5%。5.2 分时段误差分析只看一个总体指标是不够的。我习惯把错误按时间段拆开看这样能发现模型在哪里明显吃力。时间段MAE平均实际客流说明凌晨 0:00-5:000.840.62几乎没有客流模型学得很好早高峰 7:00-9:3012.38245.66客流峰值高误差也不小平峰 9:30-17:006.71102.84模型表现稳定晚高峰 17:00-19:3011.92238.21与早高峰特性类似早高峰和晚高峰的 MAE 明显高但这个其实很难避免。因为高峰时段的客流基数大一点小比例变动就会带来绝对数值的提升。对站务运营来说更重要的事情是看相对误差误差在一个方向上如果能被预测到就可以提前安排人手。我还会特别关注“预测迟滞”问题。在客流骤增或骤减的时刻模型往往反应慢半拍。这个问题主要出现在使用滞后特征的模型上。因为 lag_1 到 lag_3 把最近的客流当成了最主要特征如果真实客流突然从 100 跳到 300模型就会先“看到”100接着才会逐步调整到 300。解决办法是加大对周期性特征的权重或者用多步预测模型的残差做修正但实际运营中这一点可以通过阈值报警来弥补。5.3 特征重要性排序LightGBM 自带特征重要性计算我直接调用了feature_importances_importances model.feature_importances_ features X_train.columns print(sorted(zip(features, importances), keylambda x: x[1], reverseTrue))结果里排在最前面的几乎全是滞后特征尤其是lag_96前一天同时刻客流和lag_672上周同期客流。这说明我的日周期和周周期滞后特征非常有效。其次是时间特征里的hour_bin和is_peak它们帮助模型区分不同时段的基础客流水平。让我比较意外的是precipitation的排位不算很高。我猜测原因是这个站在预测期内降水天数比例不高雨量也不大所以降雨对客流的提升效应没有被充分学习到。这个特征在雨季来临时可能会更有价值但你的训练集得先覆盖足够的雨天样本。6. 常见问题与避坑记录6.1 数据泄漏我一直在项目里反复强调数据泄漏。这是时序预测里最隐蔽也最致命的坑。比如有人先把全部数据做标准化其中均值和方差是在训练集和测试集的合并数据上算出来的。这样测试集的信息就被泄漏到了训练过程中评估指标自然虚高。实际部署时模型的预测效果一定会打折扣。正确的做法是归一化、填充缺失值等所有统计量的计算都只用训练集。测试集的数据要保持完全不可见状态。在 LightGBM 上这个问题还不太严重因为树模型不依赖特征缩放。但如果你用 LSTM 或者神经网络就必须在数据加载器内部对每个 batch 做归一化且归一化参数只能用训练集算出来。6.2 节假日处理节假日是客流预测的噩梦。模型如果在训练集里只见过两个节假日它很难学会节假日模式的一般规律。我处理节假日的方法是为每个节假日单独生成一个is_holiday特征同时为节假日前后一天额外生成is_holiday_prev和is_holiday_next特征。因为很多人会提前离城或者延后返程这些窗口的客流会出现明显的平移。这个方法在实践中比单纯二值化节假日要好非常多。虽然它增加了几个特征维度但模型能够更精细地学习节假日时间窗口的影响。6.3 站点之间客流模式的差异如果你把多个站点的数据合并在一起训练一个全局模型你会发现模型的表现在不同站点之间差距很大。这是因为各站点的客流模式差异太大了。CBD 站点是典型的双峰曲线居民区站点则是早高峰出站多、晚高峰进站多交通枢纽站则是全天都有波峰。我的处理方案是先聚类站点客流模式再为每个类别训练一个专属模型。但因为本次项目只聚焦一个站点所以没有深入展开。如果你做全网模型千万不要忽略这一步。一个整体的“平均模型”在单个站点上往往会被专业的“分站模型”全面击败。6.4 模型上线前的自检清单行文至此我多少有点交付者的心态了。项目代码和数据分享出来后很多人跑通代码就算完事但这个和真正落地还隔着一段距离。我建议你在交付前做最后一遍自检确认所有特征在预测时刻都是可获取的不包含未来信息。确认滞后特征没有泄漏shift方向正确。确认评估时间窗口严格连续没有因为随机切分造成数据泄漏。确认预测结果能追溯到具体时段方便业务方核查。确认输出格式和站务系统要求的接口一致至少字段名词要对上。上线的第一周我会把模型的预测值和实际值同时记录到一个日志表里。用真实数据检验模型效果比你在离线测试集上调一万遍参数都可靠。如果连续三天预测误差超过阈值说明你的模型已经不能反映当前运营状况了需要重新训练。说实话这种短时客流预测项目做到后期最花时间的不再是模型调参而是跟数据质量打交道。AFC 设备状态、极端天气、突发事件每一个扰动都会在序列里留下痕迹。模型能做的就是在这些痕迹中尽量捕捉稳定的规律剩下的交给经验和应急预案去兜底。如果你准备在这个方向上深入我建议你之后可以尝试多步预测Multi-step Forecasting而不是我一直用的单步递归预测也可以试试把多个站点的空间相关性用图神经网络的方式建模。这些方向都在我的后续实验计划里等跑出稳定的结果后再来分享。本文还有配套的精品资源点击获取
简介地铁自动售检票系统AFC每笔刷卡都隐含着时空维度的交通行为信息而短时客流预测正是挖掘其价值的关键技术方向。通过对AFC历史交易数据进行清洗与重采样结合时间属性、滞后特征、天气与节假日等外部变量形成反映客流周期性与突变性的结构化特征集。在模型选型上树模型因对混合特征处理天然友好、训练高效且具备可解释性成为构建稳健基线的理想选择能够有效捕捉早高峰与晚高峰的动态波动。该技术广泛应用于站点运力调度、站台拥挤度预警和应急疏散决策等场景显著提升城市轨道交通运营的精细化管理水平。本文以真实站点刷卡数据为对象完整分享从数据处理、特征工程到模型训练与评估的全链路实用经验并对比时序模型与深度学习方案的优劣为相关领域的工程实践与学术研究提供可复现的参考范例。 我做了这么多年的城市交通数据挖掘最有意思也最折磨人的任务之一就是给地铁站做客流预测。尤其当你手里握着真正的地铁 AFC 刷卡数据时你会发现任何一个模型在真实数据面前都会现出原形。这个项目的初衷其实很简单用完整的地铁站 AFC 出站数据构建一个能预测未来短时客流的模型并且把整套代码和数据都完整地分享出来。今天这篇文章就把整个过程从头到尾拆开讲包括数据怎么清洗、特征怎么构造、模型怎么选、参数怎么调以及那些你在论文和书本里都看不到的坑。AFC 全称是 Automatic Fare Collection也就是自动售检票系统。只要你刷过地铁闸机就会产生一条 AFC 交易记录。它里面含着进站站点、出站站点、进出站时间、票卡类型、支付金额这些关键字段。我这次主要关注的是“出站客流”因为对车站运营来说出站客流直接影响站台拥挤度和疏散能力而且出站数据相对进站数据更稳定噪声也更小。不管你是交通专业的在校生、刚入行的数据分析师还是已经搞过一阵子时序预测想找真实场景验证一下思路的人这篇分享都值得你看完。里面的代码和数据我会讲得非常具体直接照着跑就能出结果。1. 项目目标与方案选型1.1 我们到底要预测什么很多新手拿到 AFC 数据后的第一反应是直接拿全网的刷卡量或者某个站点的进出站总量来做预测。这个思路本身没问题但它和实际运营场景的需求是脱节的。地铁运营方更关心的不是“明天全网有多少人坐地铁”而是“今天早高峰 8 点到 8 点 15 分国贸站的出站量会不会爆掉”。这两个问题的复杂度完全不在一个量级上。所以我在启动这个项目时把预测目标定义为某站点在未来连续多个 15 分钟时间窗口内的出站客流量。这里涉及两个维度的粒度选择一个是空间粒度一个是时间粒度。空间上我选择了单个站点而不是全网或全线路。全网客流太宏观建模后对单个站点的指导意义有限线路层面虽然比全网细一点但不同线路之间的换乘客流会引入无法解释的干扰。单站点虽然数据量少一些但特征规律最清晰模型的可解释性强而且这也是调度和站务人员最直观的决策单元。时间上我选了 15 分钟作为基本窗口。这个粒度在短时客流预测里属于比较常用的折中方案。如果按分钟预测数据波动太剧烈模型很难学到稳定的规律如果按小时预测又太粗了应急响应完全来不及。15 分钟刚好匹配一个发车间隔的整数倍实际运营中也有这样的上报周期。预测的视界horizon我设置为未来 6 个窗口也就是未来 90 分钟。为什么不是更长的未来因为短时客流预测的价值在于实时决策过长的时间跨度更适合交给中长期模型去处理。考虑到 LSTM 这类模型在滚动预测时误差会逐窗口累积6 个窗口是个合理的平衡点。1.2 为什么最终选了“特征工程 LightGBM”为主力方案在定模型之前我对比了三条路线传统时间序列模型ARIMA、深度学习模型LSTM、以及树模型LightGBM/XGBoost。ARIMA 我第一个就排除了。原因不是它不能用而是 AFC 客流数据的周期性太强强到 ARIMA 无法充分吸收这种多周期叠加的规律。你可以把早高峰看成每日周期把周末效应看成周周期还有节假日这种异常点。ARIMA 对这类多季节性的处理需要做季节性分解操作起来非常繁琐而且它在处理外部特征比如天气、节假日公告方面几乎没有扩展性。LSTM 我认真实验过后面会贴出代码和结果。它的优势在于可以从原始序列中自动提取时序依赖关系不需要手工构造太多滞后特征。但训练成本高调参周期长对小数据集容易过拟合。在我的测试中同样的特征工程下LightGBM 的效果和 LSTM 差不多甚至略好但训练速度要快上百倍。LightGBM 的另一个天然优势是它能同时吃进去时间特征、滞后特征、外部特征而且对缺失值有原生的处理逻辑。你不需要做一个复杂的端到端深度学习架构只要规规矩矩地把特征做好它就能给你一个非常扎实的基线结果。对于大多数真实项目来说“快速跑出一个稳的结果”比“刷榜”更重要。所以最终方案定为数据清洗后先做特征工程时序滞后 时间属性 外部因素然后以 LightGBM 作为主模型同时保留 LSTM 作为对比实验。2. 数据准备与清洗2.1 AFC 数据长什么样项目使用的是一段时间内某市地铁某站点的进站和出站刷卡流水数据。AFC 原始记录的核心字段大致如下字段名示例值说明device_id100234闸机设备编号card_id880123456789票卡唯一编码business_type进站 / 出站交易类型station_id300521站点编码deal_time2023-04-18 08:21:35交易时间card_type储值卡 / 单程票 / 手机扫码票种fare_amount4.00支付金额我这次做的是出站客流所以提取逻辑很简单把business_type 出站的所有记录保留下来然后以station_id和deal_time为准将时间重采样为 15 分钟频段统计每个站的出站人数。这里有个容易踩坑的细节AFC 原始数据通常是有进站和出站两条记录的进站记录没有出站时间出站记录没有进站时间。统计出站量时必须用出站记录的时间而不是进站记录的。很多人拿进站记录统计出来的结果是错的尤其在早高峰进站和出站的峰值时间差了整整一个通勤时长。2.2 清洗流程与代码实现我不喜欢做重度的数据预处理因为任何一步过度清洗都可能把真实信息洗掉。但有几类数据必须处理干净。import pandas as pd import numpy as np from datetime import datetime # 读取原始AFC数据 df pd.read_csv(afc_record.csv, parse_dates[deal_time]) # 1. 去除重复记录 df df.drop_duplicates().copy() # 2. 只保留出站记录 df df[df[business_type] 出站].copy() # 3. 过滤非法交易时间 df df[(df[deal_time] 2023-01-01) (df[deal_time] 2023-06-30)] # 4. 剔除空空信息 df df.dropna(subset[station_id, deal_time]) # 5. 重采样为15分钟客流序列 df[time_bin] df[deal_time].dt.floor(15min) flow_series df.groupby([station_id, time_bin]).size().reset_index(nameout_count) # 6. 将时间序列补全为连续间隔 all_bins pd.date_range(start2023-01-01, end2023-06-30, freq15min) all_stations sorted(flow_series[station_id].unique()) full_index pd.MultiIndex.from_product([all_stations, all_bins], names[station_id, time_bin]) flow_series_full flow_series.set_index([station_id, time_bin]).reindex(full_index, fill_value0).reset_index() # 7. 生成日期、小时等基础特征 flow_series_full[hour] flow_series_full[time_bin].dt.hour flow_series_full[dayofweek] flow_series_full[time_bin].dt.dayofweek flow_series_full[is_workday] (~flow_series_full[time_bin].dt.weekday.isin([5, 6])).astype(int) print(flow_series_full.head(10))这段代码有几个关键点值得展开说。第 5 步用floor(15min)做时间切分这比直接按分钟分组再切分要干净得多它会自动把 8:07:23 归入 8:00 至 8:14:59 这个窗口。你不需要自己去判断时间边界。第 6 步看起来只是补全实际上很关键。地铁在深夜会停运夜间没有客流数据如果直接把缺失的时间点剔除模型就会误以为“不存在”和“0 客流”是一个概念。所以我用reindex把所有存在但没有任何刷卡记录的时间点都补成 0。这一步保证了时间序列的连续性和等间距性是后续做滞后特征的基础。另一种做法是只保留运营时长比如 5:00 到 24:00把深夜数据直接扔掉。但我测试后发现保留完整 24 小时序列对模型反而更有好处因为模型可以通过夜间连续的零值学到“车站休眠期”这个模式在预测凌晨时段时不会产生虚假的波动。2.3 数据质量验证清洗完之后不要急着建模型先做数据质量验证。我会检查三个指标每日总客流的异常波动如果某天突然比前一天低一半大概率是设备故障或者数据缺失。零值比例是否过高如果一个站白天的零值比例超过 10%说明站点可能临时封闭或者设备漏记。重采样后序列的缺失比例一般来说 AFC 数据的完整度极高缺失比例应该为 0。在这个项目里我发现有 3 天因为系统升级导致数据部分缺失直接把这 3 天整段剔除了。这是一个很实用的取舍与其修补残缺数据不如让模型完全不知道这三天存在过。否则模型会尝试去拟合“某天 14 点客流消失”这种虚假模式干扰预测效果。3. 特征工程3.1 时间特征客流预测里最不需要费心思但又最不能忘记的就是时间特征。模型不知道 8:30 是什么概念但如果你把 8:30 这个时间点拆成小时和分钟再把星期几、是否工作日、是否节假日告诉它它就能很快学到早高峰、周末低谷这些规律。我实际用到的核心时间特征有这些hour_bin当前 15 分钟窗口的小时值比如 8 点到 8 点 15 分就是 8。minute_bin当前窗口的分钟分支取值只有 0、15、30、45。dayofweek星期几0 到 6。is_weekend是否周末。is_holiday是否法定节假日。is_peak是否处于早晚高峰时段这个特征需要根据站点自身规律自定义。is_peak这个特征我用了站点级别早高峰 7:00-9:30、晚高峰 17:00-19:30 的判断标准而不是全网统一标准。因为每一站的通勤特征不一样比如商业中心的午间出门高峰也很明显如果没有这个特征模型就只能靠 hour 去猜效果会差一截。def add_time_features(df): df df.copy() df[hour_bin] df[time_bin].dt.hour df[minute_bin] df[time_bin].dt.minute df[dayofweek] df[time_bin].dt.dayofweek df[is_weekend] df[dayofweek].isin([5, 6]).astype(int) # 早高峰、晚高峰 df[is_peak] df.apply( lambda row: 1 if ( (row[hour_bin] 7 and row[hour_bin] 9 and row[minute_bin] 30) or (row[hour_bin] 17 and row[hour_bin] 19 and row[minute_bin] 30) ) else 0, axis1 ) return df这个is_peak的写法是比较暴力的但足够用。如果你有时间可以针对不同站点统计各自的客流分布找出实际的峰值时段再生成特征效果会更好。我之后在调优里做了这件事收益确实有但不算巨大所以第一版先用全局规则没问题。3.2 滞后特征与滑动窗口特征时间特征只解决了“什么时候”的问题模型还需要知道“过去发生了什么”。滞后特征就是把这个信息喂给模型。对于 15 分钟粒度的客流序列我用的滞后项主要分成三组特征组具体滞后项含义最近时段滞后lag_1, lag_2, lag_3前 1 个、2 个、3 个 15 分钟窗口的客流当日节气滞后same_time_yesterday前一天同一时间窗口的客流周同期滞后same_day_last_week上周同一天同一时间窗口的客流这里的逻辑是车站客流存在明显的自相关性和周期性。一个站 8:15 的客流肯定和 8:00 的客流强相关这是短时延续性而 8:15 这个窗口的客流大概率又和前一天 8:15 强相关这是日周期性如果考虑到了周一和周一之间的相似性那你需要上周同一时间的值。def add_lag_features(df): df df.copy() # 未来预测目标 df[target] df[out_count].shift(-1) # 近期滞后 df[lag_1] df[out_count].shift(1) df[lag_2] df[out_count].shift(2) df[lag_3] df[out_count].shift(3) # 日周期滞后96 24小时 * 4个15分钟窗口 df[lag_96] df[out_count].shift(96) df[lag_192] df[out_count].shift(192) # 周周期滞后672 7 * 96 df[lag_672] df[out_count].shift(672) # 滑动窗口均值 df[rolling_mean_6] df[out_count].shift(1).rolling(window6).mean() df[rolling_std_6] df[out_count].shift(1).rolling(window6).std() return df注意这里所有滞后特征都先做了shift(1)再参与后续计算。这是为了防止数据泄漏。比如你要预测未来 1 步的target如果直接把当前窗口的值同时作为特征和目标模型在训练时就会“偷看答案”在测试时却看不到未来数据导致评估结果虚高。所以我统一把特征错开一个窗口确保模型在预测第 t1 时刻时只能用到 t 及之前的信息。shift(672)就是上周同一时间窗口的客流值。这里有个细节如果数据本身有缺失那 lag_672 就会缺失。LightGBM 能处理缺失值所以我没有做填充。但如果你用 LSTM大概率需要把缺失值补上或者丢弃对应行。3.3 外部特征并入AFC 客流不只是受时间周期影响天气和工作日事件的影响也非常明显。下雨天很多人会放弃短途出行改乘地铁站点客流会出现一个可预测的抬升。我额外并入了两个外部数据源历史天气和公共假期。天气数据只取了温度和降水量两个字段。光照、风力这些对客流的影响不显著而且特征维度太多反而容易过拟合。# 模拟天气数据示例 weather_df pd.DataFrame({ time_bin: pd.date_range(2023-01-01, 2023-06-30, freq15min), temperature: np.random.uniform(5, 32, len(pd.date_range(2023-01-01, 2023-06-30, freq15min))), precipitation: np.random.exponential(0.1, len(pd.date_range(2023-01-01, 2023-06-30, freq15min))) }) flow_data flow_data.merge(weather_df, ontime_bin, howleft)真实的天气数据一般是按小时提供的所以合并时要注意时间粒度对齐。我的做法是把小时天气数据向下重采样为 15 分钟粒度的等值填充也就是同一个小时内所有 15 分钟窗口都复用这个小时的值。这个处理很粗糙但完全够用模型主要需要的是“当下是否下雨”这种粗粒度信息并不需要精确到每一分钟。公共假期我手工标注了一个is_holiday列涵盖春节、清明、五一等节假日。这个字段在长周期预测里极其重要节假日当天和前后一天的客流模式完全不同。你可以用一个简单的字典映射不需要写复杂逻辑。4. 模型训练与对比4.1 数据切分和验证策略时间序列数据切分不能用随机切分这是老生常谈但总是有人犯。我用的是按时间顺序的滚动切分前 70% 作为训练集中间 15% 作为验证集最后 15% 作为测试集。更严谨的做法是做时间序列交叉验证TimeSeriesSplit因为客流数据存在很强的趋势和季节性简单的三段切分可能对某些时段过拟合。我在这里用了TimeSeriesSplit看了下稳定性最终以普通的三段切分为准因为项目里数据量不算小跨越时间也够长三段切分的结果已经足够稳定。from sklearn.model_selection import TimeSeriesSplit, train_test_split # 按时间顺序切分不用shuffle train_end int(len(data) * 0.7) val_end int(len(data) * 0.85) train data.iloc[:train_end] val data.iloc[train_end:val_end] test data.iloc[val_end:] feature_cols [ hour_bin, minute_bin, dayofweek, is_weekend, is_peak, is_holiday, lag_1, lag_2, lag_3, lag_96, lag_192, lag_672, rolling_mean_6, rolling_std_6, temperature, precipitation ] X_train, y_train train[feature_cols], train[target] X_val, y_val val[feature_cols], val[target] X_test, y_test test[feature_cols], test[target]这里的train_test_split写法其实是个坑。你在代码里尽管可以调用它但必须显式设置shuffleFalse。我上面的写法是直接手动切分更直观也不会出错。4.2 LightGBM 训练与参数解读LightGBM 的参数比较多但核心就几个树的棵树n_estimators、学习率learning_rate、树深度max_depth、叶子节点数num_leaves、最小节点样本数min_child_samples。我第一版先用了一套比较稳健的默认参数import lightgbm as lgb model lgb.LGBMRegressor( n_estimators800, learning_rate0.05, max_depth6, num_leaves31, min_child_samples20, subsample0.8, colsample_bytree0.8, random_state42, n_jobs-1 ) model.fit( X_train, y_train, eval_set[(X_val, y_val)], eval_metricmae, callbacks[lgb.early_stopping(50), lgb.log_evaluation(100)] ) y_pred model.predict(X_test)这里early_stopping(50)表示如果验证集上的 MAE 连续 50 轮不下降就直接停止训练。你不需要自己数要不要停LightGBM 会自动保留验证集上最优的那棵树。这在原生的lgb.train接口里需要传best_iteration但LGBMRegressor的 API 已经帮你处理好了。num_leaves31和max_depth6配合起来是 LightGBM 比较经典的配置组合。注意num_leaves并不是越大越好叶子越多模型越细但也越容易过拟合。对于客流数据里大量接近零的夜间时段叶子数太大会让模型刻意记住这些噪声导致日间预测被拖偏。另外我开了colsample_bytree0.8也就是每棵树随机抽样 80% 的特征。这不是必须的但可以略微增加模型稳健性。如果你追求的是训练速度可以把subsample和colsample都关掉这个数据集上影响不大。4.3 LSTM 对比实验我承认 LSTM 在这里更多是为了满足好奇心和对照实验需要。如果你希望我分享“深度学习方案”它的实现要稍微麻烦一些。你需要把时间序列重采样成固定窗口长度的输入比如用过去 96 个时间窗口1 天预测未来 6 个窗口。import torch import torch.nn as nn from torch.utils.data import Dataset, DataLoader class FlowLSTM(nn.Module): def __init__(self, input_size, hidden_size64, num_layers2, output_size6): super().__init__() self.lstm nn.LSTM(input_size, hidden_size, num_layers, batch_firstTrue) self.fc nn.Linear(hidden_size, output_size) def forward(self, x): out, _ self.lstm(x) out out[:, -1, :] # 取最后一个时间步的隐藏状态 return self.fc(out)整个训练过程我用的是 MSE 损失Adam 优化器初始学习率 0.001batch size 32训练 50 轮。跑完一轮大概需要几分钟看机器性能。结果上LSTM 在测试集上的 MAE 比 LightGBM 高了大概 8% 左右。但要注意LSTM 的训练时间和调参成本远远高于 LightGBM。如果你没有大量的时间去精调网络结构LightGBM 是更务实的选择。我对深度学习模型的态度一直是把特征工程先做到极致再考虑复杂的模型才不吃亏。5. 评估指标与结果分析5.1 用什么指标评估客流预测常用的评估指标有三个MAE、RMSE、MAPE。每个都有自己的侧重点。MAE 是绝对误差的平均值单位是人数。它对异常值不敏感非常好解释。RMSE 因为对误差做了平方所以放大了大误差的影响。如果你模型预测某个高峰时段误差达到 100 人RMSE 就会很难看。MAPE 是百分比误差但它有个天然缺陷当真实值为 0 时无法计算。夜间窗口客流是 0MAPE 就会是无穷大所以我最后没有用 MAPE 作为主指标只对白天的数据算了下参考值。我用 MAE 作为最核心的指标因为对运营决策来说“平均差了多少人”是最直观的信息。from sklearn.metrics import mean_absolute_error, mean_squared_error mae mean_absolute_error(y_test, y_pred) rmse np.sqrt(mean_squared_error(y_test, y_pred)) print(fMAE: {mae:.2f}) print(fRMSE: {rmse:.2f})我跑出来的结果是测试集总体 MAE 约 8.7 人 / 15 分钟。听起来不大但你要知道这个站一天平均客流在 18000 人次左右高峰时段单窗口客流波动在 200 到 400 人。MAE 8.7 说明模型在大部分时候预测的误差还不到真实峰值的 5%。5.2 分时段误差分析只看一个总体指标是不够的。我习惯把错误按时间段拆开看这样能发现模型在哪里明显吃力。时间段MAE平均实际客流说明凌晨 0:00-5:000.840.62几乎没有客流模型学得很好早高峰 7:00-9:3012.38245.66客流峰值高误差也不小平峰 9:30-17:006.71102.84模型表现稳定晚高峰 17:00-19:3011.92238.21与早高峰特性类似早高峰和晚高峰的 MAE 明显高但这个其实很难避免。因为高峰时段的客流基数大一点小比例变动就会带来绝对数值的提升。对站务运营来说更重要的事情是看相对误差误差在一个方向上如果能被预测到就可以提前安排人手。我还会特别关注“预测迟滞”问题。在客流骤增或骤减的时刻模型往往反应慢半拍。这个问题主要出现在使用滞后特征的模型上。因为 lag_1 到 lag_3 把最近的客流当成了最主要特征如果真实客流突然从 100 跳到 300模型就会先“看到”100接着才会逐步调整到 300。解决办法是加大对周期性特征的权重或者用多步预测模型的残差做修正但实际运营中这一点可以通过阈值报警来弥补。5.3 特征重要性排序LightGBM 自带特征重要性计算我直接调用了feature_importances_importances model.feature_importances_ features X_train.columns print(sorted(zip(features, importances), keylambda x: x[1], reverseTrue))结果里排在最前面的几乎全是滞后特征尤其是lag_96前一天同时刻客流和lag_672上周同期客流。这说明我的日周期和周周期滞后特征非常有效。其次是时间特征里的hour_bin和is_peak它们帮助模型区分不同时段的基础客流水平。让我比较意外的是precipitation的排位不算很高。我猜测原因是这个站在预测期内降水天数比例不高雨量也不大所以降雨对客流的提升效应没有被充分学习到。这个特征在雨季来临时可能会更有价值但你的训练集得先覆盖足够的雨天样本。6. 常见问题与避坑记录6.1 数据泄漏我一直在项目里反复强调数据泄漏。这是时序预测里最隐蔽也最致命的坑。比如有人先把全部数据做标准化其中均值和方差是在训练集和测试集的合并数据上算出来的。这样测试集的信息就被泄漏到了训练过程中评估指标自然虚高。实际部署时模型的预测效果一定会打折扣。正确的做法是归一化、填充缺失值等所有统计量的计算都只用训练集。测试集的数据要保持完全不可见状态。在 LightGBM 上这个问题还不太严重因为树模型不依赖特征缩放。但如果你用 LSTM 或者神经网络就必须在数据加载器内部对每个 batch 做归一化且归一化参数只能用训练集算出来。6.2 节假日处理节假日是客流预测的噩梦。模型如果在训练集里只见过两个节假日它很难学会节假日模式的一般规律。我处理节假日的方法是为每个节假日单独生成一个is_holiday特征同时为节假日前后一天额外生成is_holiday_prev和is_holiday_next特征。因为很多人会提前离城或者延后返程这些窗口的客流会出现明显的平移。这个方法在实践中比单纯二值化节假日要好非常多。虽然它增加了几个特征维度但模型能够更精细地学习节假日时间窗口的影响。6.3 站点之间客流模式的差异如果你把多个站点的数据合并在一起训练一个全局模型你会发现模型的表现在不同站点之间差距很大。这是因为各站点的客流模式差异太大了。CBD 站点是典型的双峰曲线居民区站点则是早高峰出站多、晚高峰进站多交通枢纽站则是全天都有波峰。我的处理方案是先聚类站点客流模式再为每个类别训练一个专属模型。但因为本次项目只聚焦一个站点所以没有深入展开。如果你做全网模型千万不要忽略这一步。一个整体的“平均模型”在单个站点上往往会被专业的“分站模型”全面击败。6.4 模型上线前的自检清单行文至此我多少有点交付者的心态了。项目代码和数据分享出来后很多人跑通代码就算完事但这个和真正落地还隔着一段距离。我建议你在交付前做最后一遍自检确认所有特征在预测时刻都是可获取的不包含未来信息。确认滞后特征没有泄漏shift方向正确。确认评估时间窗口严格连续没有因为随机切分造成数据泄漏。确认预测结果能追溯到具体时段方便业务方核查。确认输出格式和站务系统要求的接口一致至少字段名词要对上。上线的第一周我会把模型的预测值和实际值同时记录到一个日志表里。用真实数据检验模型效果比你在离线测试集上调一万遍参数都可靠。如果连续三天预测误差超过阈值说明你的模型已经不能反映当前运营状况了需要重新训练。说实话这种短时客流预测项目做到后期最花时间的不再是模型调参而是跟数据质量打交道。AFC 设备状态、极端天气、突发事件每一个扰动都会在序列里留下痕迹。模型能做的就是在这些痕迹中尽量捕捉稳定的规律剩下的交给经验和应急预案去兜底。如果你准备在这个方向上深入我建议你之后可以尝试多步预测Multi-step Forecasting而不是我一直用的单步递归预测也可以试试把多个站点的空间相关性用图神经网络的方式建模。这些方向都在我的后续实验计划里等跑出稳定的结果后再来分享。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
