简介这份PDF是一篇来自《大连理工大学学报》的学术论文聚焦单向共享电动汽车站点间车辆库存不平衡问题适合新能源汽车、共享出行领域的研究人员、硕博学生及运营从业者参考。资源共1个PDF文档压缩包大小3.32MB。论文系统提出基于长短期记忆神经网络的需求预测方法从人口特性、交通通达性、土地使用属性和时间属性4类因素建模站点需求并构建以调度成本、库存成本和潜在损失收益最小为目标的多目标调度模型采用遗传模拟退火混合算法求解最优方案同时通过实证研究验证了方法的合理性与优越性能够有效缓解出行需求不均衡性和潮汐性带来的车辆库存失衡提升车辆利用率与运营收益。已有124人学习浏览对理解共享电动汽车调度策略、需求预测建模思路以及混合智能算法在实际场景中的应用具有直接参考价值可作为相关课题研究和论文写作的专业文献支撑。1. 单向共享电动汽车的调度难题需求预测到底在预测什么做共享汽车调度的人最早都会踩同一个坑凭经验挪车。调度员看哪个站点没车了就调几辆过去看哪个站车堆满了就拉走几辆。这套打法在双向模式下勉强能用因为用户 A 地取 A 地还早晚高峰的潮汐是自发对冲的。但换成单向模式——用户 A 地取车、B 地还车——整个系统的车会不可逆地往热点区域流动。你白天把车从住宅区调到写字楼晚上写字楼的用户把车开回住宅区但数量和时段永远对不齐净流量才是真正要命的变量。基于需求预测的单向共享电动汽车车辆调度方法核心就是把「凭经验和事后补救」变成「用预测做前置调度」让车在用户产生需求之前就位。这类方案的价值不在于模型多花哨而在于解决一个具体问题单向模式下站点库存长期失衡服务率上不去挪车成本又居高不下。适合读这篇文章的人是手里已经有一摊运营数据、被调度成本压得喘不过气的运营团队或者是准备自研调度系统、想先搭一版能跑通闭包的算法工程师。本文按预测建模、调度决策、上线避坑的顺序把整套方案拆开讲重点放在能落地的最小实现上读完你可以直接照着一版一版迭代。2. 需求预测怎么建站点级分时订单特征与 LightGBM 最小方案2.1 为什么单向模式的需求预测必须拆成取车和还车两个目标单向共享汽车的需求预测最容易被误解成「预测每个站点的订单量」。如果只是预测订单量模型训练完你会发现自己做了一堆无用功——订单量预测只能告诉你「这里有人要用车」却没法告诉调度系统「这里需要补几辆车、挪走的车从哪来」。真正决定调度动作的是站点在当前时段的两件事取车需求用户从这里开走多少辆和还车需求用户在这里还回来多少辆。两者相减得到的净流量才是车辆净流入或净流出的方向。这里还有一个单向模式独有的隐性需求还车需求其实是「车辆容量需求」。站点车停满了用户到了地方还不了车这是比无车可取更伤体验的失败场景。所以建模时要把取车需求量和还车需求量分别作为两个目标变量而不是合起来预测一个总和。很多团队的第一版模型翻车就翻在这——预测总量做得漂漂亮亮上调度时发现站点容量约束根本没被喂进模型车调过去了但用户还不了车。2.2 站点粒度与时段粒度怎么定数据规范化的第一步做需求预测的第一步不是选模型而是确定数据的时空粒度。时间粒度上共享汽车的订单波动受通勤时段影响很大常见做法是把一天切成 30 分钟或 1 小时的槽位。30 分钟粒度更精细但样本噪声大1 小时粒度稳定但对调度响应来说偏粗。我一般先用 1 小时粒度跑基线确认特征逻辑没问题再细到 30 分钟。空间粒度上如果站点太多且分布稀疏按站点逐一建模会面临严重的数据稀疏——一个冷门站一天可能只有几单模型学不到任何规律。常见做法是先按站点周边的用地属性做聚类把站点分成「住宅型」「办公型」「商圈型」「枢纽型」几类模型对同一类站点共享参数冷启动时也能借用同类站点的数据。数据整理的目标是生成一张宽表每一行是「站点 时段」的组合特征包括时间特征星期几、是否节假日、小时、站点特征站点类型、周边 POI 密度、容量、历史需求特征过去 1 小时、2 小时、24 小时同段的取车量和还车量、外部特征天气、温度、降水、空气质量。这里要特别强调历史需求特征的重要性——共享汽车的订单有很强的近因效应前一小时的取车量对未来一小时的需求预测贡献往往比天气还大。2.3 特征工程代码从订单表到训练集的最小实现下面这段代码是把原始订单流水变成训练集的参考实现按「站点 时段」聚合生成上面提到的特征体系。数据源 orders 表长这样order_id、site_id、bike_type取车或还车、happen_time。注意单车订单和电动汽车订单结构没有本质差别站点容量换成充电桩空余数即可。import pandas as pd import numpy as np from datetime import timedelta def build_train_dataset(orders, sites, freq1H): # orders: 订单流水, 字段含 site_id, event_time, event_type(取车/还车) # sites: 站点表, 字段含 site_id, site_type, capacity orders[hour_slot] orders[event_time].dt.floor(freq) # 分别聚合取车量和还车量 pick (orders[orders[event_type] 取车] .groupby([site_id, hour_slot]).size() .rename(pick_cnt).reset_index()) drop (orders[orders[event_type] 还车] .groupby([site_id, hour_slot]).size() .rename(drop_cnt).reset_index()) # 生成站点 x 时段的完整笛卡尔网格缺数补 0 all_slots pd.date_range(orders[event_time].min().floor(freq), orders[event_time].max().floor(freq), freqfreq) grid pd.MultiIndex.from_product( [sites[site_id], all_slots], names[site_id, hour_slot]).to_frame(indexFalse) df grid.merge(pick, on[site_id, hour_slot], howleft) df df.merge(drop, on[site_id, hour_slot], howleft) df[[pick_cnt, drop_cnt]] df[[pick_cnt, drop_cnt]].fillna(0) # 时间特征 df[weekday] df[hour_slot].dt.weekday df[hour] df[hour_slot].dt.hour df[is_holiday] df[hour_slot].dt.date.isin(holiday_set).astype(int) # 滞后特征前 1、2、24 小时的取画/还车量 df df.sort_values([site_id, hour_slot]).reset_index(dropTrue) for lag in [1, 2, 24]: df[fpick_lag{lag}] (df.groupby(site_id)[pick_cnt] .shift(lag).fillna(0)) df[fdrop_lag{lag}] (df.groupby(site_id)[drop_cnt] .shift(lag).fillna(0)) df df.merge(sites[[site_id, site_type, capacity]], onsite_id, howleft) return df这段代码的要点在于先做笛卡尔网格再左连接而不是直接 groupby——很多初版脚本翻车是因为冷门时段根本没有订单直接 groupby 会把这些时段丢掉模型会误以为「没订单 该时段不存在」上线后预测在凌晨和深夜严重失真。用笛卡尔网格把缺失的时段补 0模型才能真正学到「这个时段就是没需求」的规律而不是学到「这个时段不在地表」。滞后特征的 shift 方式也很关键必须按 site_id 分组之后 shift不能全局 shift否则会把其他站点的数据串到当前站点上。这个错不好查因为模型指标不会立刻崩而是训练集和线上预测分布出现微妙偏差到上线后才会体现为预测值系统性偏移。2.4 训练 LightGBM为什么梯度提升树是单向下车的第一选择特征表建好后模型的选择建议直接上 LightGBM 或 XGBoost不要一上来就碰深度模型。共享汽车订单数据有几个特点特征维度不高十几个到几十个、有时间周期性、经常出现站点完全无单的零膨胀分布。梯度提升树对这类结构化数据的拟合效率远高于神经网络训练快、调参少、可解释性强——你需要向运营解释「为什么这个站明天上午预测只有 3 笔需求」时能直接输出特征重要性排行而不是打开一个黑匣子。等到基线跑通后如果要在分钟级粒度或数百站点规模上继续提精度再考虑上序列模型不迟。import lightgbm as lgb from sklearn.model_selection import TimeSeriesSplit # 目标变量可以选 pick_cnt取车需求也可以加一列 net_flow pick_cnt - drop_cnt # 调度侧同时需要这两个值建议分别训练两个模型 features [weekday, hour, is_holiday, pick_lag1, pick_lag2, pick_lag24, drop_lag1, drop_lag2, drop_lag24, site_type, capacity] # 按时间顺序切分防止未来数据泄漏 tscv TimeSeriesSplit(n_splits4) for train_idx, val_idx in tscv.split(df): train df.iloc[train_idx] val df.iloc[val_idx] model lgb.LGBMRegressor( n_estimators500, learning_rate0.05, num_leaves31, subsample0.8, colsample_bytree0.8, random_state42 ) model.fit(train[features], train[pick_cnt], eval_set[(val[features], val[pick_cnt])], callbacks[lgb.early_stopping(50)])参数里需要留意的是 n_estimators 配合 early_stopping 使用。共享汽车需求有明显的星期周期性直接留出最后一周做验证集的做法会高估模型表现——因为最后一周的星期分布与训练集重合度低。用 TimeSeriesSplit 按时间顺序做交叉验证每次都在前段训练、后段验证能模拟真实上线时的预测场景。eval_set 不能省略它是防止过拟合的保险丝若发现 early_stopping 后训练轮次极低比如小于 50先检查特征里是否混入未来信息常见问题是把「当天总订单量」这种事后统计量当特征放进去了。训练完成后把模型输出的 pick_cnt 和 drop_cnt 预测值相减就能得到每个站点下一时段的净流量预测。这一步产出就是调度模块的输入——它告诉调度算法哪里会空、哪里会满、程度如何。3. 调度决策怎么落地从预测值到调度指令的三层模型3.1 重平衡问题的数学建模单目标还是双目标拿到净流量预测后调度问题变成一个典型的库存重平衡问题。每个站点当前有车数、容量、未来一小时的预测取车量和还车量调度员的决策变量是「从哪些站点调多少辆车到哪些站点」。目标函数有两个最大化服务率让尽可能多的取车需求被满足、让尽可能多的还车需求有车位和最小化调度成本调度员人工费、车辆挪移的时间成本。这两个目标天然冲突——想让服务率达到 95% 以上意味着要在极早时段就把车布到所有可能产生需求的站点调度成本会爆炸。常见做法是设成主从目标第一优先满足服务率不低于某个阈值比如取车满足率 90%、还车拒绝率低于 5%第二优先最小化调度成本。运营侧对服务率有硬性考核时这个顺序能保证不触碰红线如果服务率没有硬指标可以改成加权和的形式但权重要由财务和运营一起拍单纯算法侧拍脑袋定权重上线后必然会有人喊成本失控。3.2 最小可用方案贪心调度器的代码实现第一版不需要上优化求解器。用贪心算法跑基线能让你在一个小时内得到整个调度流程的闭环后续再换优化器也有对比基准。贪心的逻辑很直接先算每个站点的预测净流量得出站点是「多余」还是「缺失」然后按缺车严重程度从高到低排序优先补给最缺的站取车站点按距离从近到远选择。import numpy as np from scipy.spatial.distance import cdist def greedy_rebalance(pred_df, current_inventory, capacity_df, dist_matrix, max_move_distance3.0, max_workers10): pred_df: 站点当前时段的预测净流量 drop_cnt - pick_cnt正为流入 current_inventory: 站点当前实时车辆数 dist_matrix: 站点间距离矩阵单位公里 max_move_distance: 调度半径超过则放弃这组配对 net (pred_df[drop_cnt].values - pred_df[pick_cnt].values current_inventory).astype(float) capacity capacity_df[capacity].values # 计算需补车辆数车辆数低于预测取车量安全库存 demand_gap np.maximum(0, pred_df[pick_cnt].values 1 - net) # 计算可调出车辆数净流入且超出安全库存的部分 supply_gap np.maximum(0, net - pred_df[drop_cnt].values - 1) moves [] while True: demand_idx np.argmax(demand_gap) if demand_gap[demand_idx] 0: break # 找最近的可调出站点按距离排序 sorted_supply np.argsort(dist_matrix[demand_idx]) found False for supply_idx in sorted_supply: if supply_gap[supply_idx] 0: continue if dist_matrix[demand_idx][supply_idx] max_move_distance: break move_num int(min(demand_gap[demand_idx], supply_gap[supply_idx])) # 不超过目标站剩余容量 move_num min(move_num, capacity[demand_idx] - net[demand_idx]) if move_num 0: continue moves.append((demand_idx, supply_idx, move_num)) demand_gap[demand_idx] - move_num supply_gap[supply_idx] - move_num net[demand_idx] move_num found True break if not found: demand_gap[demand_idx] 0 # 没有可用车辆放弃该站点 return moves这段代码的核心在安全库存的设计。第 6 行取车需求加 1、还车需求减 1是为了给站点留出一辆缓冲车——否则按均值预测调度一旦实际需求略高于预测站点立刻缺车。安全库存的数值要按站点类型差异化枢纽类站点流动性强缓冲可以放大住宅区站点在早高峰是净流出方向缓冲要小否则大量车闲置在住宅区。参数 max_move_distance 是调度半径初期建议设 3 公里超过这个距离的调度边际成本会急剧上升这套贪心的缺陷也明显它只考虑了当前时段、没有前瞻用一个时段跑出来勉强能用连续多个时段滚动跑时会出现「车被反复来回搬」的震荡问题。3.3 进阶用 OR-Tools 做滚动优化替代贪心贪心基线上线后下一步是把它换成整数规划求解器。常见做法是把时间维度展开把问题建模成一个多时段流网络节点是「站点 × 时段」边是「车辆留存」和「调度搬移」求解目标是最小化总调度次数与惩罚项之和。OR-Tools 的 CP-SAT 求解器能处理数百个站点、十几个时段的小规模实例求解时间在分钟级完全够用。from ortools.sat.python import cp_model def solve_rebalance(pred_matrix, init_inventory, capacity, dist_matrix, time_horizon6, max_distance3.0): pred_matrix: (site, time) 的净流量预测矩阵 init_inventory: 各站点初始车辆数 time_horizon: 滚动优化的时段数6 表示往后看 6 个时段 model cp_model.CpModel() n_sites pred_matrix.shape[0] # 决策变量x[i][j][t] 表示 t 时段从 i 站搬到 j 站的车数 x {} for t in range(time_horizon): for i in range(n_sites): for j in range(n_sites): if i ! j and dist_matrix[i][j] max_distance: x[(i, j, t)] model.NewIntVar(0, 10, fx_{i}_{j}_{t}) # 库存守恒约束当前库存 上时段库存 净流量 搬入 - 搬出 inv {} for t in range(time_horizon): for i in range(n_sites): inv[(i, t)] model.NewIntVar(0, capacity[i], finv_{i}_{t}) if t 0: model.Add(inv[(i, t)] init_inventory[i]) else: inflow sum(x[(j, i, t-1)] for j in range(n_sites) if (j, i, t-1) in x) outflow sum(x[(i, j, t-1)] for j in range(n_sites) if (i, j, t-1) in x) model.Add(inv[(i, t)] inv[(i, t-1)] int(pred_matrix[i, t]) inflow - outflow) # 目标最小化总搬车次数加惩罚项 total_moves sum(x.values()) model.Minimize(total_moves) solver cp_model.CpSolver() solver.parameters.max_time_in_seconds 60.0 status solver.Solve(model) return status, x, solver.ObjectiveValue()这段代码里需要解释的决策变量 x 的设计。每个时段在节点间搬移的车辆数设成整数变量范围 0 到 10是给单次调度设置的上限——一辆调度车一次最多拖移 10 辆超过要分多趟。库存变量必须约束在 0 到 capacity 之间这保证了任意站点不会出现「超容还车」的失败场景。用滚动时域的方式执行这套方案每个调度周期开始时用最新预测跑一次 6 时段规划但只执行第一时段的指令下一时段再重新预测、重新优化。这是生产环境中行业标准的做法能有效对冲预测误差在长时间尺度上的累积。OR-Tools 的 CP-SAT 对这类约束满足问题的求解质量远高于手写启发式代价是需要维护模型的约束逻辑新增运营规则时要同步改代码。3.4 调度执行的反馈闭环忽略这一点系统会越来越偏预测和调度做完很多团队就认为系统上线了结果跑了两周发现车辆位置分布和计算出的理论分布越差越远。原因几乎总是——没有做执行反馈。调度指令发出后调度员实际执行了多少调度过程中有没有车辆被用户中途租走站点表报的在线车辆数和真实物理车辆数是否一致最保险的做法是设计一张调度执行日志表每次下发指令、执行完毕、人工取消都要记录状态系统侧在下一次计算时用最新上报的库存数据做初始值而不是用理论推演值。这套反馈闭环的价值在于调度系统是控制论问题不是单纯的最优化问题预测、决策、执行三者之间任何一环的信息断层都会导致偏差被放大。在实际项目里因为这个原因翻车的团队不在少数。4. 避坑指南共享汽车调度系统上线的四个血泪教训4.1 晴天预测准确、雨天全崩天气特征不是可选项是必选项现象模型上线试运行两周晴天的取车需求预测偏差在 ±15% 以内看起来一切正常。第三天下雨当天所有站点的预测值系统性偏低 30% 以上调度完全没有准备早高峰多个站点无车可用。原因训练集里雨天样本占比不到 8%树模型在稀疏特征上没学到稳定的映射关系更隐蔽的是雨天的影响不是线性的——小雨影响小、大雨影响大而且对办公区站点和住宅区站点的方向还不一样。如果没有把降雨量分档只用一个「是否下雨」的布尔特征模型难以捕捉到这种非线性。解决把天气 API 的逐小时降水强度、温度、风速并入特征工程并且对降雨量做分档编码0 无雨、1 小雨、2 中雨、3 大雨、4 暴雨而不是用连续值。更重要的是模型上线前要专门抽雨天样本做验证如果验证集指标比晴天差很多需要给雨天样本加权或者单独训练一个雨天模型做集成。这类问题在前期数据探索阶段就可以发现只要按天气维度分组看需求分布不要只按时间维度看。4.2 仿真效果完美上路后调度指令执行率不到六成现象离线仿真里调度方案能把服务率从 78% 提升到 92%搬车次数还下降了 20%。试点上线后实际服务率只涨了 5 个百分点调度员反馈「给的指令根本做不完」。原因仿真里默认调度员是无限运力可以同时执行所有指令真实情况是调度员有上班时间、需要吃饭休息、一次任务往返有路程耗时根本不可能在一小时内完成 30 条跨站调度指令。系统分配给每个指令的距离和时间窗没有跟调度员的排班表打通。解决在目标函数和可行性约束里加上调度员的数量和单趟任务耗时常见做法是给每个调度员设置最大单班任务数超过这个数就放到下一轮滚动规划另一个补充手段是把调度指令按站点聚合成「一趟多站」的任务包减少调度员的空驶里程。这个坑的本质是先在模型里假设了不存在的廉价运力解决方式就是让模型尊重现实约束哪怕牺牲一点理论上的最优性。4.3 新站点预测永远为零调度系统永远不派车现象运营新开了几个站点系统对它们的取车需求预测一直输出 0 或接近 0 的数导致每次调度决策都跳过这些站点形成「无车 → 用户不用 → 维持无预测」的死循环。原因纯滞后特征模型对没有历史订单的站点没有任何信息量。滞后特征全是 0树模型学到的结论就是「没历史就没需求」这个推断对老站点是对的对新站点则是灾难。解决给新站点做空间聚合。把站点按地理位置聚成片区新站点用所属片区的平均需求曲线作为先验特征更稳妥的方式是引入冷启动专用特征——周边同类站点相同 site_type的历史需求均值。实施时注意给模型增加一个「站点年龄」特征让模型自己学会区分「老站点没需求」和「新站点还没数据」两种情况这样新上线站点的预测值会随着运营天数增加自动过渡。如果运营动作快也可以直接对新站点强制设置基础调度库存先让车过去停着等产生订单后再让模型接管。4.4 还车拥堵没进约束调过去的车用户还不了现象某个商圈站点下午时段取车需求很高调度系统持续往这个站补车结果到傍晚车辆堆积超过站点容量用户开车过去还不了车投诉暴增。原因调度目标函数里的「服务率」指标只统计了取车成功率没有统计还车失败率。树模型预测的还车量在下午时段其实也在涨但算法只看取了「净流量」为负流出多就拼命补车忽略了还有一波还车潮在后面。解决在目标函数里加入站点容量硬约束。前面 OR-Tools 代码里的「0 到 capacity」约束就是干这个的但如果采用贪心方案需要在调度落库前加一层校验当前站点库存 预测还车量 本次补充量不能大于容量 × 0.9留出 10% 的缓冲。这个 0.9 系数可以调但建议不要超过 0.95否则还车波峰来临时一定会溢出。这个坑的普遍性在于大多数团队的第一版调度都是只看取车供给的而单向模式的还车容量约束才是和双向模式区别最大的运营难点。5. 验证方法论与调度参数的敏感性分析5.1 上线前先做回放仿真不要拿真车试错调度系统改版最稳妥的验证方式是历史回放仿真而不是直接灰度上线。做法是取过去 4 到 6 周的真实订单数据和站点库存快照把预测模型和调度模型跑一遍模拟每个时段站点库存的演进对比指标只用两个取车服务率有车可取的订单占比和还车成功率到站有位的还车占比外加总搬车成本。回放仿真最大的优势是可以在几分钟内测试不同参数组合找到服务率和成本之间的可行边界。回放仿真要特别注意避免时间穿越——用 t 时段的真实订单去评估 t 时段的调度效果没问题但绝对不能把 t 时段之后的订单信息比如 t2 时段的实际需求用在调度决策里做参考。这个错经常在工程师图省事、复用整张订单表做特征时发生一旦发生回放结果会比真实上线时好出 20% 个点以上误导整个团队提前庆祝。5.2 必调的三个参数与敏感性分析方法调度系统可调参数多业务侧压力大但真正值得反复调的只有三个安全库存系数、调度半径、调度员单班任务上限。安全库存系数决定车分布冗余度建议按站点类型分开设初值调度半径影响成本和覆盖率的平衡可以先按 2、3、5 公里做三组回放实验观察服务率曲线是否在某个半径后进入平台期调度员单班任务上限则需要和运营排班表对齐超过上限的指令会积压。敏感性分析的执行方式是把三个参数各设三个档位低、中、高做 3×3×3 共 27 组回放实验画服务率-成本散点图。这套分析做完你基本能判断当前调度体系的提升瓶颈是在预测精度还是在调度运力——如果所有组合的服务率都卡在 85% 附近上不去问题在预测不是调度如果散点图显示服务率能到 95% 但成本失控则优先优化调度运力排班而不是继续砸模型精度。这个判断是上线后和老板谈资源投向的关键依据。做这套系统时我印象最深的教训是预测模型做到最后精度提升对服务率的影响微乎其微反而是把还车容量约束加进调度模型后服务率直接跳了 5 个点。调度系统是个木桶预测只是其中一块板千万别把精力全砸在模型调参上运营约束才是这个方向里决定天花板的部分。希望这几段经验能帮你少踩两个坑让这套方案在你自己数据集上少走一轮弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 21:43:26 · 阅读 1.2k 共享汽车调度实战：基于需求预测的车辆重平衡方案
简介这份PDF是一篇来自《大连理工大学学报》的学术论文聚焦单向共享电动汽车站点间车辆库存不平衡问题适合新能源汽车、共享出行领域的研究人员、硕博学生及运营从业者参考。资源共1个PDF文档压缩包大小3.32MB。论文系统提出基于长短期记忆神经网络的需求预测方法从人口特性、交通通达性、土地使用属性和时间属性4类因素建模站点需求并构建以调度成本、库存成本和潜在损失收益最小为目标的多目标调度模型采用遗传模拟退火混合算法求解最优方案同时通过实证研究验证了方法的合理性与优越性能够有效缓解出行需求不均衡性和潮汐性带来的车辆库存失衡提升车辆利用率与运营收益。已有124人学习浏览对理解共享电动汽车调度策略、需求预测建模思路以及混合智能算法在实际场景中的应用具有直接参考价值可作为相关课题研究和论文写作的专业文献支撑。1. 单向共享电动汽车的调度难题需求预测到底在预测什么做共享汽车调度的人最早都会踩同一个坑凭经验挪车。调度员看哪个站点没车了就调几辆过去看哪个站车堆满了就拉走几辆。这套打法在双向模式下勉强能用因为用户 A 地取 A 地还早晚高峰的潮汐是自发对冲的。但换成单向模式——用户 A 地取车、B 地还车——整个系统的车会不可逆地往热点区域流动。你白天把车从住宅区调到写字楼晚上写字楼的用户把车开回住宅区但数量和时段永远对不齐净流量才是真正要命的变量。基于需求预测的单向共享电动汽车车辆调度方法核心就是把「凭经验和事后补救」变成「用预测做前置调度」让车在用户产生需求之前就位。这类方案的价值不在于模型多花哨而在于解决一个具体问题单向模式下站点库存长期失衡服务率上不去挪车成本又居高不下。适合读这篇文章的人是手里已经有一摊运营数据、被调度成本压得喘不过气的运营团队或者是准备自研调度系统、想先搭一版能跑通闭包的算法工程师。本文按预测建模、调度决策、上线避坑的顺序把整套方案拆开讲重点放在能落地的最小实现上读完你可以直接照着一版一版迭代。2. 需求预测怎么建站点级分时订单特征与 LightGBM 最小方案2.1 为什么单向模式的需求预测必须拆成取车和还车两个目标单向共享汽车的需求预测最容易被误解成「预测每个站点的订单量」。如果只是预测订单量模型训练完你会发现自己做了一堆无用功——订单量预测只能告诉你「这里有人要用车」却没法告诉调度系统「这里需要补几辆车、挪走的车从哪来」。真正决定调度动作的是站点在当前时段的两件事取车需求用户从这里开走多少辆和还车需求用户在这里还回来多少辆。两者相减得到的净流量才是车辆净流入或净流出的方向。这里还有一个单向模式独有的隐性需求还车需求其实是「车辆容量需求」。站点车停满了用户到了地方还不了车这是比无车可取更伤体验的失败场景。所以建模时要把取车需求量和还车需求量分别作为两个目标变量而不是合起来预测一个总和。很多团队的第一版模型翻车就翻在这——预测总量做得漂漂亮亮上调度时发现站点容量约束根本没被喂进模型车调过去了但用户还不了车。2.2 站点粒度与时段粒度怎么定数据规范化的第一步做需求预测的第一步不是选模型而是确定数据的时空粒度。时间粒度上共享汽车的订单波动受通勤时段影响很大常见做法是把一天切成 30 分钟或 1 小时的槽位。30 分钟粒度更精细但样本噪声大1 小时粒度稳定但对调度响应来说偏粗。我一般先用 1 小时粒度跑基线确认特征逻辑没问题再细到 30 分钟。空间粒度上如果站点太多且分布稀疏按站点逐一建模会面临严重的数据稀疏——一个冷门站一天可能只有几单模型学不到任何规律。常见做法是先按站点周边的用地属性做聚类把站点分成「住宅型」「办公型」「商圈型」「枢纽型」几类模型对同一类站点共享参数冷启动时也能借用同类站点的数据。数据整理的目标是生成一张宽表每一行是「站点 时段」的组合特征包括时间特征星期几、是否节假日、小时、站点特征站点类型、周边 POI 密度、容量、历史需求特征过去 1 小时、2 小时、24 小时同段的取车量和还车量、外部特征天气、温度、降水、空气质量。这里要特别强调历史需求特征的重要性——共享汽车的订单有很强的近因效应前一小时的取车量对未来一小时的需求预测贡献往往比天气还大。2.3 特征工程代码从订单表到训练集的最小实现下面这段代码是把原始订单流水变成训练集的参考实现按「站点 时段」聚合生成上面提到的特征体系。数据源 orders 表长这样order_id、site_id、bike_type取车或还车、happen_time。注意单车订单和电动汽车订单结构没有本质差别站点容量换成充电桩空余数即可。import pandas as pd import numpy as np from datetime import timedelta def build_train_dataset(orders, sites, freq1H): # orders: 订单流水, 字段含 site_id, event_time, event_type(取车/还车) # sites: 站点表, 字段含 site_id, site_type, capacity orders[hour_slot] orders[event_time].dt.floor(freq) # 分别聚合取车量和还车量 pick (orders[orders[event_type] 取车] .groupby([site_id, hour_slot]).size() .rename(pick_cnt).reset_index()) drop (orders[orders[event_type] 还车] .groupby([site_id, hour_slot]).size() .rename(drop_cnt).reset_index()) # 生成站点 x 时段的完整笛卡尔网格缺数补 0 all_slots pd.date_range(orders[event_time].min().floor(freq), orders[event_time].max().floor(freq), freqfreq) grid pd.MultiIndex.from_product( [sites[site_id], all_slots], names[site_id, hour_slot]).to_frame(indexFalse) df grid.merge(pick, on[site_id, hour_slot], howleft) df df.merge(drop, on[site_id, hour_slot], howleft) df[[pick_cnt, drop_cnt]] df[[pick_cnt, drop_cnt]].fillna(0) # 时间特征 df[weekday] df[hour_slot].dt.weekday df[hour] df[hour_slot].dt.hour df[is_holiday] df[hour_slot].dt.date.isin(holiday_set).astype(int) # 滞后特征前 1、2、24 小时的取画/还车量 df df.sort_values([site_id, hour_slot]).reset_index(dropTrue) for lag in [1, 2, 24]: df[fpick_lag{lag}] (df.groupby(site_id)[pick_cnt] .shift(lag).fillna(0)) df[fdrop_lag{lag}] (df.groupby(site_id)[drop_cnt] .shift(lag).fillna(0)) df df.merge(sites[[site_id, site_type, capacity]], onsite_id, howleft) return df这段代码的要点在于先做笛卡尔网格再左连接而不是直接 groupby——很多初版脚本翻车是因为冷门时段根本没有订单直接 groupby 会把这些时段丢掉模型会误以为「没订单 该时段不存在」上线后预测在凌晨和深夜严重失真。用笛卡尔网格把缺失的时段补 0模型才能真正学到「这个时段就是没需求」的规律而不是学到「这个时段不在地表」。滞后特征的 shift 方式也很关键必须按 site_id 分组之后 shift不能全局 shift否则会把其他站点的数据串到当前站点上。这个错不好查因为模型指标不会立刻崩而是训练集和线上预测分布出现微妙偏差到上线后才会体现为预测值系统性偏移。2.4 训练 LightGBM为什么梯度提升树是单向下车的第一选择特征表建好后模型的选择建议直接上 LightGBM 或 XGBoost不要一上来就碰深度模型。共享汽车订单数据有几个特点特征维度不高十几个到几十个、有时间周期性、经常出现站点完全无单的零膨胀分布。梯度提升树对这类结构化数据的拟合效率远高于神经网络训练快、调参少、可解释性强——你需要向运营解释「为什么这个站明天上午预测只有 3 笔需求」时能直接输出特征重要性排行而不是打开一个黑匣子。等到基线跑通后如果要在分钟级粒度或数百站点规模上继续提精度再考虑上序列模型不迟。import lightgbm as lgb from sklearn.model_selection import TimeSeriesSplit # 目标变量可以选 pick_cnt取车需求也可以加一列 net_flow pick_cnt - drop_cnt # 调度侧同时需要这两个值建议分别训练两个模型 features [weekday, hour, is_holiday, pick_lag1, pick_lag2, pick_lag24, drop_lag1, drop_lag2, drop_lag24, site_type, capacity] # 按时间顺序切分防止未来数据泄漏 tscv TimeSeriesSplit(n_splits4) for train_idx, val_idx in tscv.split(df): train df.iloc[train_idx] val df.iloc[val_idx] model lgb.LGBMRegressor( n_estimators500, learning_rate0.05, num_leaves31, subsample0.8, colsample_bytree0.8, random_state42 ) model.fit(train[features], train[pick_cnt], eval_set[(val[features], val[pick_cnt])], callbacks[lgb.early_stopping(50)])参数里需要留意的是 n_estimators 配合 early_stopping 使用。共享汽车需求有明显的星期周期性直接留出最后一周做验证集的做法会高估模型表现——因为最后一周的星期分布与训练集重合度低。用 TimeSeriesSplit 按时间顺序做交叉验证每次都在前段训练、后段验证能模拟真实上线时的预测场景。eval_set 不能省略它是防止过拟合的保险丝若发现 early_stopping 后训练轮次极低比如小于 50先检查特征里是否混入未来信息常见问题是把「当天总订单量」这种事后统计量当特征放进去了。训练完成后把模型输出的 pick_cnt 和 drop_cnt 预测值相减就能得到每个站点下一时段的净流量预测。这一步产出就是调度模块的输入——它告诉调度算法哪里会空、哪里会满、程度如何。3. 调度决策怎么落地从预测值到调度指令的三层模型3.1 重平衡问题的数学建模单目标还是双目标拿到净流量预测后调度问题变成一个典型的库存重平衡问题。每个站点当前有车数、容量、未来一小时的预测取车量和还车量调度员的决策变量是「从哪些站点调多少辆车到哪些站点」。目标函数有两个最大化服务率让尽可能多的取车需求被满足、让尽可能多的还车需求有车位和最小化调度成本调度员人工费、车辆挪移的时间成本。这两个目标天然冲突——想让服务率达到 95% 以上意味着要在极早时段就把车布到所有可能产生需求的站点调度成本会爆炸。常见做法是设成主从目标第一优先满足服务率不低于某个阈值比如取车满足率 90%、还车拒绝率低于 5%第二优先最小化调度成本。运营侧对服务率有硬性考核时这个顺序能保证不触碰红线如果服务率没有硬指标可以改成加权和的形式但权重要由财务和运营一起拍单纯算法侧拍脑袋定权重上线后必然会有人喊成本失控。3.2 最小可用方案贪心调度器的代码实现第一版不需要上优化求解器。用贪心算法跑基线能让你在一个小时内得到整个调度流程的闭环后续再换优化器也有对比基准。贪心的逻辑很直接先算每个站点的预测净流量得出站点是「多余」还是「缺失」然后按缺车严重程度从高到低排序优先补给最缺的站取车站点按距离从近到远选择。import numpy as np from scipy.spatial.distance import cdist def greedy_rebalance(pred_df, current_inventory, capacity_df, dist_matrix, max_move_distance3.0, max_workers10): pred_df: 站点当前时段的预测净流量 drop_cnt - pick_cnt正为流入 current_inventory: 站点当前实时车辆数 dist_matrix: 站点间距离矩阵单位公里 max_move_distance: 调度半径超过则放弃这组配对 net (pred_df[drop_cnt].values - pred_df[pick_cnt].values current_inventory).astype(float) capacity capacity_df[capacity].values # 计算需补车辆数车辆数低于预测取车量安全库存 demand_gap np.maximum(0, pred_df[pick_cnt].values 1 - net) # 计算可调出车辆数净流入且超出安全库存的部分 supply_gap np.maximum(0, net - pred_df[drop_cnt].values - 1) moves [] while True: demand_idx np.argmax(demand_gap) if demand_gap[demand_idx] 0: break # 找最近的可调出站点按距离排序 sorted_supply np.argsort(dist_matrix[demand_idx]) found False for supply_idx in sorted_supply: if supply_gap[supply_idx] 0: continue if dist_matrix[demand_idx][supply_idx] max_move_distance: break move_num int(min(demand_gap[demand_idx], supply_gap[supply_idx])) # 不超过目标站剩余容量 move_num min(move_num, capacity[demand_idx] - net[demand_idx]) if move_num 0: continue moves.append((demand_idx, supply_idx, move_num)) demand_gap[demand_idx] - move_num supply_gap[supply_idx] - move_num net[demand_idx] move_num found True break if not found: demand_gap[demand_idx] 0 # 没有可用车辆放弃该站点 return moves这段代码的核心在安全库存的设计。第 6 行取车需求加 1、还车需求减 1是为了给站点留出一辆缓冲车——否则按均值预测调度一旦实际需求略高于预测站点立刻缺车。安全库存的数值要按站点类型差异化枢纽类站点流动性强缓冲可以放大住宅区站点在早高峰是净流出方向缓冲要小否则大量车闲置在住宅区。参数 max_move_distance 是调度半径初期建议设 3 公里超过这个距离的调度边际成本会急剧上升这套贪心的缺陷也明显它只考虑了当前时段、没有前瞻用一个时段跑出来勉强能用连续多个时段滚动跑时会出现「车被反复来回搬」的震荡问题。3.3 进阶用 OR-Tools 做滚动优化替代贪心贪心基线上线后下一步是把它换成整数规划求解器。常见做法是把时间维度展开把问题建模成一个多时段流网络节点是「站点 × 时段」边是「车辆留存」和「调度搬移」求解目标是最小化总调度次数与惩罚项之和。OR-Tools 的 CP-SAT 求解器能处理数百个站点、十几个时段的小规模实例求解时间在分钟级完全够用。from ortools.sat.python import cp_model def solve_rebalance(pred_matrix, init_inventory, capacity, dist_matrix, time_horizon6, max_distance3.0): pred_matrix: (site, time) 的净流量预测矩阵 init_inventory: 各站点初始车辆数 time_horizon: 滚动优化的时段数6 表示往后看 6 个时段 model cp_model.CpModel() n_sites pred_matrix.shape[0] # 决策变量x[i][j][t] 表示 t 时段从 i 站搬到 j 站的车数 x {} for t in range(time_horizon): for i in range(n_sites): for j in range(n_sites): if i ! j and dist_matrix[i][j] max_distance: x[(i, j, t)] model.NewIntVar(0, 10, fx_{i}_{j}_{t}) # 库存守恒约束当前库存 上时段库存 净流量 搬入 - 搬出 inv {} for t in range(time_horizon): for i in range(n_sites): inv[(i, t)] model.NewIntVar(0, capacity[i], finv_{i}_{t}) if t 0: model.Add(inv[(i, t)] init_inventory[i]) else: inflow sum(x[(j, i, t-1)] for j in range(n_sites) if (j, i, t-1) in x) outflow sum(x[(i, j, t-1)] for j in range(n_sites) if (i, j, t-1) in x) model.Add(inv[(i, t)] inv[(i, t-1)] int(pred_matrix[i, t]) inflow - outflow) # 目标最小化总搬车次数加惩罚项 total_moves sum(x.values()) model.Minimize(total_moves) solver cp_model.CpSolver() solver.parameters.max_time_in_seconds 60.0 status solver.Solve(model) return status, x, solver.ObjectiveValue()这段代码里需要解释的决策变量 x 的设计。每个时段在节点间搬移的车辆数设成整数变量范围 0 到 10是给单次调度设置的上限——一辆调度车一次最多拖移 10 辆超过要分多趟。库存变量必须约束在 0 到 capacity 之间这保证了任意站点不会出现「超容还车」的失败场景。用滚动时域的方式执行这套方案每个调度周期开始时用最新预测跑一次 6 时段规划但只执行第一时段的指令下一时段再重新预测、重新优化。这是生产环境中行业标准的做法能有效对冲预测误差在长时间尺度上的累积。OR-Tools 的 CP-SAT 对这类约束满足问题的求解质量远高于手写启发式代价是需要维护模型的约束逻辑新增运营规则时要同步改代码。3.4 调度执行的反馈闭环忽略这一点系统会越来越偏预测和调度做完很多团队就认为系统上线了结果跑了两周发现车辆位置分布和计算出的理论分布越差越远。原因几乎总是——没有做执行反馈。调度指令发出后调度员实际执行了多少调度过程中有没有车辆被用户中途租走站点表报的在线车辆数和真实物理车辆数是否一致最保险的做法是设计一张调度执行日志表每次下发指令、执行完毕、人工取消都要记录状态系统侧在下一次计算时用最新上报的库存数据做初始值而不是用理论推演值。这套反馈闭环的价值在于调度系统是控制论问题不是单纯的最优化问题预测、决策、执行三者之间任何一环的信息断层都会导致偏差被放大。在实际项目里因为这个原因翻车的团队不在少数。4. 避坑指南共享汽车调度系统上线的四个血泪教训4.1 晴天预测准确、雨天全崩天气特征不是可选项是必选项现象模型上线试运行两周晴天的取车需求预测偏差在 ±15% 以内看起来一切正常。第三天下雨当天所有站点的预测值系统性偏低 30% 以上调度完全没有准备早高峰多个站点无车可用。原因训练集里雨天样本占比不到 8%树模型在稀疏特征上没学到稳定的映射关系更隐蔽的是雨天的影响不是线性的——小雨影响小、大雨影响大而且对办公区站点和住宅区站点的方向还不一样。如果没有把降雨量分档只用一个「是否下雨」的布尔特征模型难以捕捉到这种非线性。解决把天气 API 的逐小时降水强度、温度、风速并入特征工程并且对降雨量做分档编码0 无雨、1 小雨、2 中雨、3 大雨、4 暴雨而不是用连续值。更重要的是模型上线前要专门抽雨天样本做验证如果验证集指标比晴天差很多需要给雨天样本加权或者单独训练一个雨天模型做集成。这类问题在前期数据探索阶段就可以发现只要按天气维度分组看需求分布不要只按时间维度看。4.2 仿真效果完美上路后调度指令执行率不到六成现象离线仿真里调度方案能把服务率从 78% 提升到 92%搬车次数还下降了 20%。试点上线后实际服务率只涨了 5 个百分点调度员反馈「给的指令根本做不完」。原因仿真里默认调度员是无限运力可以同时执行所有指令真实情况是调度员有上班时间、需要吃饭休息、一次任务往返有路程耗时根本不可能在一小时内完成 30 条跨站调度指令。系统分配给每个指令的距离和时间窗没有跟调度员的排班表打通。解决在目标函数和可行性约束里加上调度员的数量和单趟任务耗时常见做法是给每个调度员设置最大单班任务数超过这个数就放到下一轮滚动规划另一个补充手段是把调度指令按站点聚合成「一趟多站」的任务包减少调度员的空驶里程。这个坑的本质是先在模型里假设了不存在的廉价运力解决方式就是让模型尊重现实约束哪怕牺牲一点理论上的最优性。4.3 新站点预测永远为零调度系统永远不派车现象运营新开了几个站点系统对它们的取车需求预测一直输出 0 或接近 0 的数导致每次调度决策都跳过这些站点形成「无车 → 用户不用 → 维持无预测」的死循环。原因纯滞后特征模型对没有历史订单的站点没有任何信息量。滞后特征全是 0树模型学到的结论就是「没历史就没需求」这个推断对老站点是对的对新站点则是灾难。解决给新站点做空间聚合。把站点按地理位置聚成片区新站点用所属片区的平均需求曲线作为先验特征更稳妥的方式是引入冷启动专用特征——周边同类站点相同 site_type的历史需求均值。实施时注意给模型增加一个「站点年龄」特征让模型自己学会区分「老站点没需求」和「新站点还没数据」两种情况这样新上线站点的预测值会随着运营天数增加自动过渡。如果运营动作快也可以直接对新站点强制设置基础调度库存先让车过去停着等产生订单后再让模型接管。4.4 还车拥堵没进约束调过去的车用户还不了现象某个商圈站点下午时段取车需求很高调度系统持续往这个站补车结果到傍晚车辆堆积超过站点容量用户开车过去还不了车投诉暴增。原因调度目标函数里的「服务率」指标只统计了取车成功率没有统计还车失败率。树模型预测的还车量在下午时段其实也在涨但算法只看取了「净流量」为负流出多就拼命补车忽略了还有一波还车潮在后面。解决在目标函数里加入站点容量硬约束。前面 OR-Tools 代码里的「0 到 capacity」约束就是干这个的但如果采用贪心方案需要在调度落库前加一层校验当前站点库存 预测还车量 本次补充量不能大于容量 × 0.9留出 10% 的缓冲。这个 0.9 系数可以调但建议不要超过 0.95否则还车波峰来临时一定会溢出。这个坑的普遍性在于大多数团队的第一版调度都是只看取车供给的而单向模式的还车容量约束才是和双向模式区别最大的运营难点。5. 验证方法论与调度参数的敏感性分析5.1 上线前先做回放仿真不要拿真车试错调度系统改版最稳妥的验证方式是历史回放仿真而不是直接灰度上线。做法是取过去 4 到 6 周的真实订单数据和站点库存快照把预测模型和调度模型跑一遍模拟每个时段站点库存的演进对比指标只用两个取车服务率有车可取的订单占比和还车成功率到站有位的还车占比外加总搬车成本。回放仿真最大的优势是可以在几分钟内测试不同参数组合找到服务率和成本之间的可行边界。回放仿真要特别注意避免时间穿越——用 t 时段的真实订单去评估 t 时段的调度效果没问题但绝对不能把 t 时段之后的订单信息比如 t2 时段的实际需求用在调度决策里做参考。这个错经常在工程师图省事、复用整张订单表做特征时发生一旦发生回放结果会比真实上线时好出 20% 个点以上误导整个团队提前庆祝。5.2 必调的三个参数与敏感性分析方法调度系统可调参数多业务侧压力大但真正值得反复调的只有三个安全库存系数、调度半径、调度员单班任务上限。安全库存系数决定车分布冗余度建议按站点类型分开设初值调度半径影响成本和覆盖率的平衡可以先按 2、3、5 公里做三组回放实验观察服务率曲线是否在某个半径后进入平台期调度员单班任务上限则需要和运营排班表对齐超过上限的指令会积压。敏感性分析的执行方式是把三个参数各设三个档位低、中、高做 3×3×3 共 27 组回放实验画服务率-成本散点图。这套分析做完你基本能判断当前调度体系的提升瓶颈是在预测精度还是在调度运力——如果所有组合的服务率都卡在 85% 附近上不去问题在预测不是调度如果散点图显示服务率能到 95% 但成本失控则优先优化调度运力排班而不是继续砸模型精度。这个判断是上线后和老板谈资源投向的关键依据。做这套系统时我印象最深的教训是预测模型做到最后精度提升对服务率的影响微乎其微反而是把还车容量约束加进调度模型后服务率直接跳了 5 个点。调度系统是个木桶预测只是其中一块板千万别把精力全砸在模型调参上运营约束才是这个方向里决定天花板的部分。希望这几段经验能帮你少踩两个坑让这套方案在你自己数据集上少走一轮弯路。本文还有配套的精品资源点击获取