基于LSTM的共享单车需求预测：从数据清洗到模型部署

简介基于长短期记忆网络LSTM的共享单车使用情况预测项目面向高校学生、数据分析初学者及需要完成课程设计或毕设的开发者通过历史骑行数据构建LSTM模型辅助调度决策解决地铁口车辆堆积或无处可寻的常见问题。压缩包共32个文件约8.06MB内容主要包含Python源码、csv数据集、json标准化参数、h5模型权重、十余张png分析图表以及说明文档和依赖清单结构清晰便于直接运行与扩展。已有141人学习下载代码测试通过答辩平均分96分支持私聊远程教学。使用者可获得完整LSTM建模流程、数据预处理与特征相关性分析思路、预测结果可视化模板以及基于真实共享单车数据的实验方案适合在源码基础上改造用于其他时序预测课题或课设作业交付。1. 共享单车预测为什么非得用 LSTM先想清楚“这个值能不能用昨天直接推”如果你接触过共享单车运维一定见过调度员的这种状态凌晨盯着后台曲线判断早高峰哪个地铁口会“爆桩”哪个小区门前会“空桩”。这不是运气的活而是一个典型的时间序列预测问题——基于历史骑行数据预测未来某个时间段、某个站点的租车量或还车量。传统做法是拿 ARIMA 或者简单的多元线性回归硬拟合但效果往往在下午五六点的晚高峰和周末的中午彻底翻车因为共享单车数据有几个非常不友好的特性强周期性但周期不稳定、天气扰动明显、节假日规律完全不同于工作日、还有大量突发性异常峰值。这些特征恰好是 LSTM也就是长短期记忆网络最擅长处理的场景。本文用一个完整可跑的 Python 项目来拆解整套流程从 CSV 数据清洗、滑窗序列样本构建到 PyTorch 或 Keras 的 LSTM 模型搭建训练再到评估指标怎么选、踩坑怎么排。如果你手里有一份共享单车历史订单数据想用深度学习做一个“能用、能答辩、能写进简历”的预测模型下面这套方案可以直接照着做。2. 从一堆钟表记录到 LSTM 能吃的时间序列数据清洗与滑窗样本构建2.1 原始骑行记录先做“时间聚合”按小时还是按天取决于你要预测什么共享单车平台的原始数据通常是一张订单表每条记录包含起止时间、起止站点、车辆 ID 等信息是典型的事件流水。LSTM 做序列预测不能直接拿这张表往模型里塞必须先把事件流聚合到固定的时间间隔上。聚合粒度取决于你要预测的目标如果预测“明天全城总用车量”按天聚合就够了如果预测“某个地铁站下一小时租车量”一定要按小时聚合——因为共享单车的潮汐效应在小时级别表现最强早高峰 8 点到 9 点往往是一天中租车量的最高点按天聚合会把这个信息完全抹掉。常见做法是先把租车记录按小时分组统计每个小时窗口内的租车次数。用 pandas 的 resample 方法就能完成聚合关键是要先把时间列转成 datetime 类型并设为索引import pandas as pd # 原始订单表start_time 是字符串格式的起始时间 df pd.read_csv(trips.csv, parse_dates[start_time]) # 设置时间索引按小时重采样统计每小时的租车订单数 df_hourly df.set_index(start_time).resample(H).size().to_frame(count) # 补充缺失的小时段共享单车夜间可能零订单但索引要连续 df_hourly df_hourly.asfreq(H, fill_value0) print(df_hourly.head(24))这一段代码里resample(H) 的作用是把时间戳对齐到整点size() 统计每个桶里的行数asfreq(H, fill_value0) 很关键凌晨两三点常常没有订单记录直接 resample 会留下空洞不填充会导致后续构造序列样本时时间轴错位。如果平台数据里有站点维度可以在聚合时加上 groupby比如 df.groupby(station_id).resample(H).size()这样就能得到“每个站点每小时租车量”的面板数据后续可以做单站预测或者站点聚类后再预测。做后文模型输入之前请先明确你要做的是“全城总量预测”还是“站点级预测”前者数据稳定容易出效果后者更有业务价值但难度大一个量级。2.2 构建滑窗训练集每一条样本截取过去 N 个小时来预测下 1 个小时LSTM 不是拿一整段历史去训练而是“看过去一定长度的序列预测下一个时刻的值”这个“一定长度”就是滑窗大小通常叫 lookback 或 time_steps。窗口大小直接决定模型能学到多长的依赖关系。窗口取太小比如 24 小时模型只能看到一天内的起伏学不会“今天是周六所以和上周六像”这种周周期性窗口取得太大比如 720 小时样本数量骤减训练成本翻倍而且 LSTM 对过长序列的记忆能力也有限。一个比较稳妥的起步值是 168也就是 7 天 × 24 小时覆盖完整的周周期。你的想法若是让模型预测下一个小时每个样本就是「连续 168 个历史值 → 第 169 个小时的值」。import numpy as np def create_sequences(data, lookback168): X, y [], [] for i in range(lookback, len(data)): X.append(data[i - lookback:i]) # 过去 lookback 个小时 y.append(data[i]) # 当前时刻的值 return np.array(X), np.array(y) # data 是一维的 numpy 数组例如 df_hourly[count].values X, y create_sequences(data, lookback168) print(X.shape, y.shape) # 输出形如 (12345, 168, 1) 和 (12345,)这段代码是整套预测流程的地基。X 的形状是(样本数, 时间步长, 特征数)LSTM 要求输入必须是三维张量第一维是样本第二维是序列长度第三维是每个时间步的特征。这里每个时间步只有一个特征用车数量所以第三维是 1。如果你要把天气、温度、是否节假日作为附加特征构造方式是在遍历时把每小时的多个特征一起放进 X把 data 换成形状为(总时长, 特征数)的二维数组然后把窗口内的数据整体截取下来X 的形状就会变成(样本数, 168, 特征数)。另外创建序列之前务必把原始数据随机打乱 —— 不能直接顺序切。因为训练集和测试集要用时间点切分如果先打乱再切未来信息就会泄漏进训练集。正确的顺序是先按时间顺序切出训练段和测试段再分别在各段内创建滑窗样本。这一点我见过很多人在交大作业时做错虽然模型也能跑但验证集指标会虚高到不合理。2.3 归一化不能全局一把梭训练集测试集必须分开 fitLSTM 内部的激活函数对输入数值的尺度很敏感共享单车骑行量数值波动大工作日早高峰可能冲到 2000 多辆每小时凌晨只有个位数跨度悬殊。直接喂原始数值训练过程极易震荡不收敛。数据归一化是必须做的但归一化的实现方式有讲究很多入门教程会犯一个隐蔽性很强的错误对全部数据做 MinMaxScaler 后再划分训练集和测试集。这一步会导致测试集的尺度信息在训练阶段已经暴露给模型验证指标的“可信度”大幅缩水。正确做法是先切分再对训练集调 fit然后用同一套参数 transform 验证集和测试集。以下代码演示正确的切分和归一化流程也是本项目中最后用作模型输入的基准数据from sklearn.preprocessing import MinMaxScaler # 1. 按时间顺序切分用前 80% 数据做训练后 20% 做测试 split_idx int(len(df_hourly) * 0.8) train_raw df_hourly[count].values[:split_idx] test_raw df_hourly[count].values[split_idx:] # 2. 只对训练段 fit再用训练段的 min/max 去 transform 测试段 scaler MinMaxScaler(feature_range(0, 1)) train_scaled scaler.fit_transform(train_raw.reshape(-1, 1)).flatten() # 注意测试段 transform 时不能重新调用 fit test_scaled scaler.transform(test_raw.reshape(-1, 1)).flatten() # 3. 分别构建训练和测试序列测试集用于最终评估 X_train, y_train create_sequences(train_scaled, lookback168) X_test, y_test create_sequences(test_scaled, lookback168) print(f训练集样本数: {X_train.shape[0]}, 测试集样本数: {X_test.shape[0]})这部分最常见的报错是在测试集上调用 fit_transform而不是只调用 transform。表面看起来代码能跑预测结果也不差但这是虚假的“好成绩”因为模型在训练时已经知道测试集的数值范围等于提前看了答案。另外MinMaxScaler 对异常值比较敏感如果某天因为活动导致骑行量出现极端峰值归一化后正常数据会被压缩到一个很窄的区间。遇到这种情况可以换成 RobustScaler它按分位数缩放受极端值影响更小也是共享单车这类波动大的数据的一个更稳妥的选择。3. 用 Python 搭建 LSTM 预测模型网络结构、训练流程与关键参数3.1 选 Keras 还是 PyTorch大作业场景我选 Keras原因有三市面上 LSTM 的实现框架主要就两个阵营KerasTensorFlow 的封装和 PyTorch。如果你做的是课程设计、毕业设计甚至是想快速验证一个想法在 keras 上 LSTM 的代码量大约是 PyTorch 的 1/3 到 1/2不需要自己手写训练循环不需要手动管理张量在 GPU 和 CPU 之间的搬运模型结构像一个积木一样叠加层即可。PyTorch 的优势在于调试灵活可以随时在 forward 函数里打断点打印中间张量适合研究新型网络结构。但共享单车预测这种标准时间序列任务网络结构非常固定不需要这种灵活性。在源码与文档组织上Keras 代码也更短容易在一份 PDF 里解释清楚——这对高分大作业很重要。下面的实现统一用 TensorFlow/Keras 的接口来写。3.2 模型结构长这样一层 LSTM Dropout 全连接输出针对单变量时间序列预测最经典的结构是两层第一层 LSTM 提取时间依赖特征中间插入 Dropout 防止过拟合最后一层 Dense 输出预测值。层数和神经元数量先别贪多LSTM 层数超过两层训练难度成倍上升容易梯度消失预测效果不一定更好。先给出一个能用且稳定收敛的基准结构之后你可以在这个基础上做增减实验作为大作业的“对比实验”部分import tensorflow as tf from tensorflow.keras.models import Sequential from tensorflow.keras.layers import LSTM, Dropout, Dense model Sequential() model.add(LSTM(units64, return_sequencesTrue, input_shape(X_train.shape[1], X_train.shape[2]))) model.add(Dropout(0.2)) model.add(LSTM(units32, return_sequencesFalse)) model.add(Dropout(0.2)) model.add(Dense(units1)) model.compile(optimizertf.keras.optimizers.Adam(learning_rate0.001), lossmse, metrics[mae]) model.summary()逐步说明这里每个参数的选择。input_shape 是两个值时间步长 168 和特征数这里为 1不需要写样本数。第一层 LSTM 的 units64表示输出 64 维的隐状态这个数值在 32~128 之间通常能取得不错的平衡太大会严重拖慢训练速度并且容易过拟合。return_sequencesTrue 很关键因为后面还要接第二层 LSTM第一层必须输出完整的序列给第二层而不是只输出最后一个时间步第二层的 return_sequencesFalse 则只输出序列最后一个时间步的隐状态作为全连接层的输入。Dropout(0.2) 的含义是训练过程中每轮迭代随机丢掉 20% 的神经元输出这是防止过拟合的常用手段在时间序列任务里Dropout 放在 LSTM 层之间比放在 LSTM 内部效果好。损失函数用 mse 或 mae 都可以但要注意两个指标的性质mse 对大误差更敏感如果你不希望晚高峰那几十辆车的误差被放大到影响全局用 mae 更合适在大部分共享单车预测场景里mse 更常用因为它能让模型更专注于拟合峰值区域。这里的 Adam 优化器加学习率 0.001 是 LSTM 任务中一个广谱适用的默认配置不建议第一次训练就换成 SGD。3.3 训练要配三件套早停、检查点、历史记录模型训练不能拍脑袋决定跑多少个 epoch。共享单车这类数据波动大在某个 epoch 上 loss 降了不代表之后不会反弹。正确做法是设置 EarlyStopping 函数监视验证集 loss如果连续多个 epoch 没有改善就自动停止训练能节省大量时间再配合 ModelCheckpoint 保存验证集指标最好的那次权重这样即使后来过拟合了也有“后悔药”可以回滚。from tensorflow.keras.callbacks import EarlyStopping, ModelCheckpoint callbacks [ EarlyStopping(monitorval_loss, patience15, restore_best_weightsTrue, verbose1), ModelCheckpoint(best_model.h5, monitorval_loss, save_best_onlyTrue, verbose1) ] history model.fit( X_train, y_train, validation_split0.1, # 从训练集尾部切 10% 做验证集 epochs100, batch_size64, callbackscallbacks, verbose1 )validation_split0.1 表示自动从训练集末尾切 10% 作为验证集注意 Keras 的这个参数默认是取训练数据最后的部分这其实符合时间序列场景——验证集在时间上是训练集之后的数据不会发生未来数据泄漏。batch_size 设为 64 是训练速度和稳定性的折中如果你显存有限或者序列特别长可以调成 32。EarlyStopping 的 patience15 表示连续 15 轮验证 loss 没有变好就停止restore_best_weightsTrue 会在停止时自动把模型权重回滚到验证集指标最好的那次迭代这两者配合网格就没必要刻意追求最佳 epoch让早停去找就行。训练结束后用这段代码绘制 loss 曲线来判断模型有没有过拟合趋势import matplotlib.pyplot as plt plt.plot(history.history[loss], labeltrain_loss) plt.plot(history.history[val_loss], labelval_loss) plt.xlabel(epoch) plt.ylabel(loss) plt.legend() plt.show()一个比较理想的状态是训练 loss 和验证 loss 都平缓下降最后趋于稳定且两者之间的差距不大。如果训练 loss 持续下降而验证 loss 在某个 epoch 后反弹说明过拟合了此时应该去看模型收敛时的 EarlyStopping 点并适当增大 Dropout 或减小 LSTM 神经元数量。4. 模型评估与结果可视化损失函数低不代表预测准4.1 MAE、RMSE、MAPE 三个指标业务解释力完全不同训练结束接下来是评估阶段。直接把测试集喂给模型做预测再对比真实值就得到误差评估数据。但不要只看 loss 数值因为用 mse 作为 loss 训练出来的模型打印出的 val_loss 是一个经过归一化的数值业务人员没法理解这个数到底意味着“准还是不准”。常用的评估指标有三个它们在共享单车场景里的适用性各不相同MAE平均绝对误差结果单位是“辆/小时”最直观适合做报告里的主指标RMSE均方根误差对大误差敏感适合关注“极端情况是否预测得离谱”MAPE平均绝对百分比误差适合观测相对误差但在凌晨时段会出现严重失真因为真实值接近 0 时一点点误差都会导致百分比爆炸下面这段代码完成反归一化、计算三项指标、输出测试集上的真实误差方便直接截图放进报告里from sklearn.metrics import mean_absolute_error, mean_squared_error # 模型预测得到的是归一化结果必须反归一化才有业务含义 y_pred_scaled model.predict(X_test) y_pred scaler.inverse_transform(y_pred_scaled.reshape(-1, 1)).flatten() # y_test 当前形状是 (N,)并且也是归一化过的 y_true scaler.inverse_transform(y_test.reshape(-1, 1)).flatten() mae mean_absolute_error(y_true, y_pred) rmse np.sqrt(mean_squared_error(y_true, y_pred)) # MAPE 只在真实值较大时可靠先过滤掉真实值小于阈值的时间点 mask y_true 50 mape np.mean(np.abs((y_true[mask] - y_pred[mask]) / y_true[mask])) * 100 print(fMAE: {mae:.2f} 辆/小时) print(fRMSE: {rmse:.2f} 辆/小时) print(fMAPE(真实值50): {mape:.2f}%)在代码中尤其要关注反归一化这个动作——很多初学者拿归一化后的误差直接写进报告说“MAE 是 0.03”这其实只是一个没有意义的相对量业务方没法理解。把这个数值乘回原始量纲后他就知道模型平均每个小时的预测误差大约是 80 辆车这个才有对比意义。MAPE 过滤掉真实值小于 50 的数据点是必要的夜间共享单车订单数常常是 0 到 10 的量级真实值是 2 预测值是 5误差百分比是 150%这种离群值会把平均 MAPE 拉到一个看起来很吓人的高度但它不代表模型真实水平。写报告或答辩时主动说明这一点会显得你对指标敏感度有充分认知。4.2 预测值 vs 真实值可视化画图时别把整段全画上去一张对比图胜过十行指标。但画图有个技巧如果一次性把整个测试集的预测值和真实值全部画出来横轴跨度太大曲线会被压扁看不出早晚高峰的拟合细节。建议随机取测试集中连续 168 个小时一周的片段单独画一张对比曲线展示模型在峰值处的高低拟合情况import matplotlib.pyplot as plt # 随机选一个连续的 7 天片段 start np.random.randint(0, len(y_true) - 168) end start 168 plt.figure(figsize(14, 5)) plt.plot(y_true[start:end], label真实值, linewidth1.5) plt.plot(y_pred[start:end], label预测值, linewidth1.5, linestyle--) plt.xlabel(小时) plt.ylabel(租车量辆) plt.title(LSTM 预测结果与真实值对比连续 7 天) plt.legend() plt.grid(alpha0.3) plt.show()观察这张图有几个角度。一是相位峰值和谷值是否对齐如果预测曲线比真实曲线晚几个小时说明模型没有真正学到周期规律只是在“跟着前一天走”二是峰值早晚高峰的尖峰预测值是否明显被削平——这是一个很常见的现象因为模型在最小化 mse 时倾向于输出“保险的中间值”宁可低估峰值也不愿冒过度预测的风险三是整体偏移如果你的预测曲线整体比真实值低或者高检查归一化步骤里测试集 transform 的方式是否正确以及是否有季节趋势没有被差分掉。4.3 按小时分段评估晚高峰预测不准是模型的问题还是数据的问题把 MAE 按小时拆开统计是一个被大多数人忽略但非常有价值的分析手段。共享单车的数据规律是凌晨时段 MAE 非常低因为真实值接近于 0 的绝对值误差也很小早高峰和晚高峰时段 MAE 显著上升这是正常现象。但如果你发现某一天下午两点的误差比早高峰还大那多半不是模型的问题而是当天有降雨、大风等突发天气事件——模型在训练时没见过这个模式的输入预测自然对不上。# 假设测试集的起始时间已知用 test_timestamps 存储每个预测点的时间 errors np.abs(y_true - y_pred) hourly_mae pd.DataFrame({time: test_timestamps, error: errors}) hourly_mae[hour] hourly_mae[time].dt.hour hourly_mae.groupby(hour)[error].mean().plot(kindbar, figsize(10, 4)) plt.ylabel(平均绝对误差辆/小时) plt.show()用这个图可以在报告中写出很有价值的结论模型在凌晨 0 点到 5 点的平均误差只有 10 辆/小时而在傍晚 17 点到 19 点的误差达到 120 辆/小时说明模型对通勤潮汐的预测仍存在系统性偏差。顺着这个结论你可以顺理成章地提出改进方向比如加入“是否为工作日”作为额外特征或者针对早晚高峰单独训练模型。5. LSTM 训练与预测避坑指南翻车五次之后的排查清单5.1 预测结果是一条整体滞后一天平移的曲线问题出在“惰性预测”现象 画出预测曲线后发现它和真实曲线形状几乎一样但整体向右平移了大约 24 个小时也就是说模型预测的就是“昨天此时的值”。原因 LSTM 学到了一个捷径——把所有输入的历史值做一个加权平均然后输出一个和前一天几乎一样的结果这样在多步递推里误差最小因为共享单车数据本身就具有很强的自相关性。这是时间序列深度学习里最经典的“惰性预测”问题模型没有学到真正的“因果规律”只是在走捷径划水。解决 在构造训练样本时加入差分特征。具体做法是不直接用原始值而是计算当前时刻相对前一天的差值模型预测的是“变化量”而不是绝对值。这样模型必须从天气、周期等因素中寻找规律无法简单复制昨天。此外把 lookback 缩短到 24 或者 48减少模型对昨天同时段的直接依赖也能缓解这个问题。5.2 凌晨时段的 MAPE 高达 300%指标虚高吓人现象 模型整体效果不错但 MAPE 计算出来动辄 200% 以上报告里根本没法写。原因 凌晨时段真实租车量接近 0比如真实值 2 辆预测值 5 辆绝对误差只有 3 辆但百分比误差却是 150%。这些深夜离群点会把 MAPE 这个指标严重拉偏。解决 要么在计算 MAPE 前过滤掉真实值小于某个阈值的样本比如只统计单车使用量大于 50 辆/小时的时段要么干脆用 MAE 做主要评估指标把 MAPE 作为参考。答辩时主动说出这条限制并说明哪些时段模型真正有用比硬报一个虚高数字更能得到认可。5.3 输入带天气特征后效果反而变差现象 加入温度、湿度、风速后验证集 loss 不降反升训练时间还变长了。原因 天气数据是逐小时的外部特征但模型对序列内部的时间依赖已经建模得较好额外特征的加入一方面增加了模型复杂度另一方面天气数据本身有缺失值和噪声导致过拟合。另外如果天气数据来自不同采集源时间粒度没有精确对齐到整点等于往输入里加入了随机噪声。解决 先用单变量序列把基线模型跑通再加外部特征逐步做对比实验。加入时务必把天气数据与骑行数据按时间索引做严格对齐并对缺失值做插值填充。一个常用技巧是把“是否下雨”做成二值特征0/1比直接输入降雨量效果更稳定——因为模型更容易抓住“是否有雨”这个突变信号而不是去拟合降雨的具体毫米数。5.4 训练 loss 一直下降验证 loss 却一开始就飙升现象 训练 loss 在正常下降但验证集的 loss 从一开始就是巨大的数字甚至比随机预测还差。原因 数据泄漏或切分错误。常见情况是在构造序列样本时先把数据整体归一化再切训练测试集或者是没有按时间顺序切分直接把数据随机打乱后切分导致训练集里混进了“未来”的数据样本还有一种可能是验证集和训练集有重叠部分重叠区域模型已经见过而独立的新时间段样本又暴露了分布差异。解决 回到第 2.3 节严格按“先切分、再归一化、最后构建滑窗”的顺序执行并且用时间顺序切分而不是随机切分。同时打印出训练集和测试集的时间范围确认它们没有交集。5.5 模型在测试集上 MAE 是 30但实际部署到新数据上误差暴涨到 200现象 拿新一段时间的真实数据回测误差远大于测试集上的结果模型看起来完全失效。原因 数据漂移。共享单车骑行行为受季节、天气、城市活动影响极大。比如训练数据来自春秋季而新数据是冬天的骑行量整体下降均值本身就变了或者测试集和新数据之间有节假日分布的差异模型没见过这种分布模式。解决 在模型上线或做最终评估之前先查看新数据和训练数据的分布差异最直接的办法是分别画出两个时间段的小时平均骑行量曲线检查早晚高峰幅度是否明显不同。若差异显著建议在预测流程中定期用最近 1~2 个月的数据重新训练模型或至少做滑动窗口式的增量训练。此外共享单车项目里“用过去预测未来”本质上隐含了“规律不变”的假设这个假设在半年以上的跨度里经常不成立这也是很多时间序列项目“测试一时爽、上线火葬场”的根本原因。6. 让它从“能跑”变成“好用”多步预测与误差诊断的进阶办法最后一个值得做的进阶点是别再满足于预测下一个小时去挑战“预测未来 24 小时”的多步输出。共享单车调度场景里调度员最需要的是明天一整天每个小时的需求曲线而不是只有一个小时。多步预测有三种常见方案递归预测把上一步预测值当作下一步输入反复迭代、直接预测模型一次输出未来 24 个小时的序列、以及序列到序列Seq2Seq结构。从工程角度在已有代码基础上改动最小、效果也相对可控的是“直接预测模型输出多步”做法只把最后一层 Dense 的 units 从 1 改成 24同时把训练标签从单值改成未来 24 个时刻构成的向量。但注意直接预测 24 个值会让模型的任务难度变大测试集误差通常会比单步预测高 50% 以上这是正常现象不是模型坏了。另一个值得投入的小技巧是误差诊断——把测试集上的大误差样本单独筛出来检查这些时间点是否集中在某些特定时刻比如工作日早高峰、恶劣天气、节假日前后。我通常会把每天 24 小时的误差画成热力图横轴是星期纵轴是小时颜色代表平均误差。如果“周日晚 8 点”的格子颜色特别深那说明模型对“周末晚归潮”理解不够下一步就该针对这类时段做特征增强比如加一个“明天是否工作日”的倒计时特征。这个方法比盲目调参有效得多。LSTM 预测共享单车这条路入门容易但做精很难希望这篇笔记能帮你少踩几个我当年踩过的坑顺利交出一份既跑得通又讲得清楚的高分作业。本文还有配套的精品资源点击获取