企业官网建设流程全解析

简介：这是一份围绕网约车订单数据开展需求特征分析与预测研究的毕业设计开题报告，适合交通运输领域研究者、网约车平台数据分析师及机器学习与数据挖掘方向的技术开发者参考。报告系统梳理了课题目的、研究意义与国内外现状，涵盖从数据收集、数据清洗、特征提取到CNN、LSTM组合预测模型构建与评估的完整技术路线，并给出基于pandas、matplotlib等工具的具体设计方案，有助于读者快速掌握运力调度、供需平衡与精准营销场景下的需求预测思路。资源为1个docx文档，压缩包仅19KB，内容精炼、结构完整，可作为开题汇报、论文写作或项目立项的参照模板。目前已有177人学习下载，对于正在筹备网约车需求预测相关课题的读者具有较高参考价值。

1. 基于订单数据的网约车需求特征分析及预测：先回答「预测什么」再谈模型

基于订单数据的网约车需求特征分析及预测，第一眼看去像是个纯时序任务，很多开题把 LSTM、Transformer 挑了一遍，最后困在预测精度上打转。我做过两轮类似的项目，最反直觉的体会是：误差大头从来不在模型，而在订单数据的清洗粒度、需求口径和特征对齐上。这个方向要解决的是网约车运力调度里最实际的问题——未来 15 分钟到 1 小时，某个网格会出现多少订单；适合做算法岗作业、部门预研或者毕业设计选题。它用一份订单数据，把特征工程、时序建模、评估验证串成一条完整闭环，落地性强，可解释的部分也多。

2. 订单数据如何变成需求序列：清洗、去重与 15 分钟粒度聚合

网约车原始订单表通常有几十个字段，但做需求特征分析真正用到的不到十个。字段越多，排查数据质量问题时越容易被牵着走，所以第一步是把口径收窄。要保留的是订单号、乘客脱敏 ID、车型、状态、下单时间、起点经纬度、终点经纬度，其余字段先放一边。

2.1 需求口径：下单、取消、无应答都算需求

很多人一上来只统计 status='completed'，把取消订单和无应答订单剔掉，这在「已成交订单分析」里是对的，但题目是需求分析——乘客的下单行为本身就是需求信号，哪怕它最后被取消或者没有司机应答。如果只用成交单，预测结果天然低估繁忙时段的真实需求，调度策略会跟着出错：你以为某个网格只需要 10 个运力，实际乘客发了 15 单。

这个表里最容易被忽视的是 order_time。很多订单表里 create_time 是服务端接收到请求的时间，order_time 才是乘客真正按下下单按钮的动作时间，两者在高峰期可能相差几分钟。需求预测的粒度是分钟级，这几分钟会把序列整体偏移，后面所有特征对齐都会跟着错。

2.2 清扫重复订单与脏坐标：SQL 脚本与逐行解读

一个高频问题是用户网络抖动连点两次，或者乘客端取消后重试，同一乘客在同一地点同一分钟内出现两条订单。不去重，峰值会凭空放大，晚高峰 18:00 那个时间桶的样本会被连点行为污染。

WITH deduped AS ( SELECT order_id, COALESCE(order_time, create_time) AS demand_time, status, start_lat, start_lng, end_lat, end_lng, ROW_NUMBER() OVER ( PARTITION BY passenger_id, start_lat, start_lng, order_time ORDER BY order_id ) AS rn FROM order_raw WHERE status IN ('completed', 'cancelled', 'no_answer') AND start_lat BETWEEN 22.0 AND 39.5 AND start_lng BETWEEN 100.0 AND 117.0 ) SELECT order_id, demand_time, status, start_lat, start_lng, end_lat, end_lng FROM deduped WHERE rn = 1;

这段把清洗逻辑压在一个 CTE 里。ROW_NUMBER 按乘客、起点、下单时间分组，保留第一条订单，去掉用户连点和重试产生的重复；状态过滤保留了 completed、cancelled、no_answer 三类，取消和无应答也是真实需求；经纬度范围过滤只保留目标城市，把测试数据或海外订单的脏点排除。COALESCE 是兜底逻辑，如果接入阶段发现两个时间字段都有值，优先以 order_time 为准。

完成这一步后，订单数据就从流水变成了需求事件。用同样的逻辑处理 OD 数据时，把终点经纬度为空的记录单独保留，不能直接丢弃——那些恰好是下了单但没人接的需求，常常是预测要捕获的高峰信号。我会在这一步导出两份表，一份是点需求，一份是 OD 需求，后面做特征分析时各有各的用处。

2.3 网格×15分钟聚合：最小可训练样本长什么样

开题报告里「需求特征分析」的落点，通常是把空间连续分布切到网格，把时间切到固定间隔，做成一个二维矩阵。网格我用 geohash 精度 6 或 7。精度 6 在城市大约 1.2km×0.6km，颗粒偏粗，适合看片区；精度 7 大约 150m×150m，接近一个街区，但稀疏网格会非常多。建议先做 6，把整个城市压成几百个网格，训练起来快，也容易跟运力调度的人对齐。

import pandas as pd import geohash df["bucket_ns"] = (df["demand_time"].astype("int64") // (900 * 10**9)) * (900 * 10**9) df["geohash6"] = df.apply( lambda r: geohash.encode(r["start_lat"], r["start_lng"], precision=6), axis=1 ) agg = df.groupby(["geohash6", "bucket_ns"]).size().reset_index(name="demand") grid_series = agg.pivot(index="bucket_ns", columns="geohash6", values="demand").fillna(0) grid_series = grid_series.resample("15min", label="left", closed="left").sum()

这里把时间戳按 900 秒对齐到时间桶起点，再用 groupby 产生每个网格在每个桶里的需求计数。pivot 之后会留下大量空列，fillna(0) 是刻意为之：凌晨没有订单的时段，需求是 0 而不是缺失，否则训练样本会随业务活跃度漂移。最后 resample 一次，用来把时区或毫秒精度不一致造成的边缘错位归位。

两个参数值得标注。时间桶的起点用 floor 取整到整 15 分钟，不要用 round，否则零点附近会出现边界漂移；geohash 编码后字符串即列名，同一城市相邻网格共享相同前缀，后续做空间邻域特征时可以用前缀截断快速找邻居。做完这一步，序列数据形状就是「时间×网格矩阵」，这是后面所有特征和模型的公共入口。我一般会把清洗前后的订单量、网格数、零值时间段占比记下来，开题报告里需要这几个数字来证明数据工作量。

聚合之后建议把结果落成一张宽表：每一行是一个网格在一个时段的需求，附带时间戳和网格 ID，这是后续特征工程的唯一入口。窄表变宽表时注意列爆炸，城市级网格几百个，宽表列数几百，内存问题不大，但导出 CSV 时时间桶用整数而不是 datetime 字符串，能省不少空间和转换时间。

网格粒度的选择可以结合订单密度做一次敏感性测试，同一套特征分别用精度 5、6、7 跑一遍基线，看业务解释和误差的平衡点，这个实验数据写进报告会很有说服力。

2.4 时间桶边界的快速检查脚本

时间字段的精度未必一致，有的精确到秒，有的只精确到分钟，还有的混入了 UTC 和本地时间。直接聚合会在每个整 15 分钟边界上出现 1 到 2 个订单的偏移毛刺，看起来不起眼，但对短时预测来说就是噪声。

edge_check = grid_series.groupby(grid_series.index.minute).sum() print(edge_check)

把每个分钟桶的订单总量打出来，如果 0、15、30、45 四个分钟位之外有大量订单，说明时间精度或时区混用，先修数据再进模型。这个脚本 10 秒跑完，能在项目一开始就发现时间字段的底层问题，远比最后靠模型调参补救省力。

3. 需求特征体系：时间、天气、节假日和空间邻域怎么进特征列

订单序列本身只是一个计数，预测模型能学到的东西有限。真正拉开差距的是特征对齐。这里的核心原则是：任何特征在预测时刻必须是「已知」的，不能混入未来信息，否则离线指标再漂亮，上线第一天就会被真实世界打脸。

3.1 用周期编码处理小时和星期，而不是塞一堆哑变量

小时特征直接作为数值喂给树模型，模型会学出「18 > 17」这种错误顺序。周期性信号要编码成 sin 和 cos 两个分量，让 23 点和 0 点之间的距离在特征空间里是相邻的，而不是横跨整个取值域。星期和月份同理。

import numpy as np def cycle_feature(ts): hour = ts.hour + ts.minute / 60.0 weekday = ts.weekday() return { "hour_sin": np.sin(2 * np.pi * hour / 24), "hour_cos": np.cos(2 * np.pi * hour / 24), "week_sin": np.sin(2 * np.pi * weekday / 7), "week_cos": np.cos(2 * np.pi * weekday / 7), "is_weekend": int(weekday >= 5), }

周期编码之后，树模型仍然能靠分裂近似出离散边界，但不会再小时当成线性量。is_weekend 单独保留，是因为周末的需求峰值形状和工作日差异很大，模型需要这个硬信号。开题报告里建议把上下班高峰判断也放进这个函数，早晚高峰本身不是周期编码能完全表达的，需要独立标记。

3.2 天气数据接入：按下单时刻对齐，超时走降级

天气对网约车需求的影响是结构性的：暴雨天的晚高峰需求会明显抬升，但雨停之后半小时内又会掉头向下。接入天气通常的做法是按城市和小时拉取温度、天气现象、降水量、风力四个字段。需要注意对齐口径：用「下单时刻所在小时」的天气，而不是预测时刻之后的天气，否则就是未来泄漏。

import requests def load_weather(city_id, ts): key = f"{city_id}-{ts.strftime('%Y%m%d%H')}" try: resp = requests.get( "https://example-weather-api/current", params={"city": city_id, "time": key}, timeout=3 ) data = resp.json() return { "temp": data["temp"], "precip": data["precip"], "wind": data["wind"], "code": data["code"], } except Exception: return last_valid.get(key[:11], climate_mean(city_id, ts.month))

这个函数的关键在降级逻辑。天气 API 在高峰期经常超时，直接抛出异常会让训练崩溃，返回 None 会让特征列中断。我一般用「前一时段有效值」和「月度气候均值」两层兜底，保证特征永远是实数。注意气候均值要按城市和月份算，不能全局取平均，否则一个南方城市的降水特征会长期失真。

3.3 节假日与特殊事件：样本少，但影响大

节假日和工作日是两种完全不同的需求模式，节假日样本量小，模型很难从普通训练集里学到，需要单独做特征和样本加权。我会生成一个日期表，把元旦、春节、五一、国庆、周末、工作日标成枚举；对春节这类长假期，还要把「节前第几天」「节后第几天」作为数值特征，因为返程高峰的出现有明显的前置滞后。

另一个容易被忽略的是大型活动：演唱会、球赛、展会的散场时间，会制造单个网格上的需求尖峰。这类事件在开题报告里不必用模型预测，目标是「可解释的特征」——把这些事件日期做成一张表，join 进特征即可。如果简历上写过出行预测，面试官大概率会追问活动事件的处理方式，提前准备会让方案完整度高不少。

3.4 空间邻域特征：让一个网格看到隔壁网格

需求有传播效应：商圈散场时，需求从中心网格向外围扩散。单网格特征只能抓住自身历史，抓不到这种空间相关性。常见做法是对每个网格取相邻区域的历史均值。实现上不需要真正计算地理距离，geohash 精度 6 的网格，截掉最后一位取前缀相同的前 5 位，就能圈出同一片区域。

grid_series["neighbor_mean"] = grid_series.rolling(6, min_periods=1).mean() \ .groupby(grid_series.columns.str[:5], axis=1).transform("mean", axis=1)

这行代码把每个网格过去 6 个时段（90 分钟）的订单均值，按前 5 位 geohash 前缀分组后求区域均值。参数 6 对应 90 分钟的窗口，适合捕捉短时传播；要捕捉小时级别的持续效应，改成 12 或 24。需要提醒的是，邻域特征也会带来泄漏风险，rolling 的 shift 不能省，如果直接用同时段邻居值，就相当于把未来抄进了特征。

3.5 特征验证顺序：先看泄漏，再看重要性

特征做完不要急着进模型。先用一个简单规则查泄漏：对每个特征计算它与目标变量的相关系数，滞后特征和目标高度相关是正常的，但如果「当天未来时段的天气」「活动散场后半小时标记」这类未来信息出现在特征列，相关系数也会异常地高。另一个更直接的检查是：把预测时段前后的特征值打印出来看，肉眼确认没有混入相邻时段的数据。

LightGBM 的特征重要性输出在这个阶段也有参考价值，但滞后特征的重要性天然偏高，不要因为 lag_1 排第一就把时间周期特征删掉。周期特征的重要性低，往往是信息被滞后特征覆盖了，而不是没有用。开题报告里特征重要性图可以放，但结论要写成「滞后特征主导短时预测，周期特征主导长时预测」，而不是简单删特征。

4. 预测模型选型：先跑 LightGBM 基线，再决定要不要上 LSTM

开题报告常见的毛病是上来就列一堆深度模型，最后跑不动的多半是数据规模撑不起复杂度。网约车订单数据按网格×15分钟切完，通常就是几万到几十万行，这个体量下树模型往往是性价比最高的选择，LSTM 更像一个需要谨慎验证的黑匣子。

4.1 模型选型的三层结构：基线、树模型、序列模型

我习惯把模型路线分成三层。第一层是简单基线，用「昨天同时段均值」或者「上周同时段均值」作为预测，这部分数字必须写进报告，它决定了所有模型是否有增量价值。第二层是 LightGBM、XGBoost 这类树模型，吃全部表格特征，训练快、可解释、调参点少。第三层才是 LSTM 或 Transformer，处理的是长序列依赖和多步输出的场景。

这张表想表达的是：LSTM 不是终点，而是「树模型处理不了的问题」的补充方案。如果 LightGBM 在验证集上的 WMAPE 已经比基线低 20% 以上，先把增量吃下来，再谈序列模型。

4.2 用 LightGBM 跑通单网格需求预测：滑窗特征与训练代码

单网格预测是最小可复现单位。先把一个网格的 15 分钟序列扩展成监督学习样本：用过去 N 个时段的订单值做滞后特征，再加时间特征和天气特征，预测未来 1 个或 4 个时段（15 到 60 分钟）的需求。

import pandas as pd import lightgbm as lgb import numpy as np def build_samples(series, horizon=1, lags=(1, 2, 3, 6, 12, 24), rolls=(3, 6, 12)): df = series.to_frame("demand") for lag in lags: df[f"lag_{lag}"] = df["demand"].shift(lag) for w in rolls: df[f"roll_{w}"] = df["demand"].shift(1).rolling(w).mean() df["hour_sin"] = np.sin(2 * np.pi * df.index.hour / 24) df["hour_cos"] = np.cos(2 * np.pi * df.index.hour / 24) df = df.dropna() X = df.drop(columns=["demand"]) y = df["demand"].shift(-horizon) # 最后 horizon 行没有真实值，截掉 X, y = X.iloc[:-horizon], y.iloc[:-horizon] return X, y X_train, y_train = build_samples(grid_series.iloc[:, 0]) X_val, y_val = build_samples(grid_series.iloc[:, 0], horizon=1) model = lgb.LGBMRegressor( n_estimators=600, learning_rate=0.05, num_leaves=31, subsample=0.8, colsample_bytree=0.8, random_state=42, ) model.fit( X_train, y_train, eval_set=[(X_val, y_val)], callbacks=[lgb.early_stopping(50)], )

两个细节值得展开。rolling 均值最容易被写错的是没有 shift(1)，直接在原始序列上滚动会把当前时段的真实值混进特征，造成训练和线上不一致；先 shift 再 rolling，才能保证只用历史信息。另一个是 lag 和 horizon 的关系，预测未来 4 个时段时，y 要 shift(-4)，同时把末尾 4 个样本截掉，避免把测试期未来值泄漏到训练集。

超参数上，n_estimators 用到 600 配合 early_stopping，learning_rate 0.05 是稳健起点。网格数量多的时候，每个网格单独训练会导致模型数量爆炸，常见的折中是：把网格 ID 作为类别特征，所有网格进同一个模型，让模型自动学习城市层面的共享规律。这样训练集能到百万行量级，树的深度可以适当加大，num_leaves 从 31 提到 63 也不会过拟合。

4.3 LSTM 路线的三个硬约束：归一化切分、序列长度、多步输出

如果用 LSTM，开题报告里最容易被指出问题的是数据处理流程。第一个约束是：归一化参数只能从训练集计算。很多教程对整个序列做 StandardScaler，再切训练测试，这在时间序列里是典型的未来泄漏。正确的顺序是切分，再 fit_transform 训练集，transform 测试集。

from sklearn.preprocessing import StandardScaler scaler = StandardScaler() X_train_norm = scaler.fit_transform(X_train) X_test_norm = scaler.transform(X_test) # 禁止重新 fit

第二个约束是序列长度。多网格联合预测时，我一般取 24 到 48 步（6 到 12 小时），更长并不会带来明显收益，反而把样本数急剧压小。第三个约束是多步预测的输出方式，直接让最后一层 Dense 输出 horizon 个值，比递归预测误差累积更小，训练也稳定。LSTM 单元数从 32 开始，加一层 Dropout(0.2)，超过 64 单元在这个量级的数据上就开始过拟合。

注意：归一化参数只允许在训练集上 fit，测试集和线上数据只能 transform，这是时间序列任务里最常见的泄漏来源。

4.4 评估指标：MAPE 会骗人，加权指标更可信

需求预测最忌讳把 MAPE 当成唯一指标。网格在凌晨时段的需求是 0，真实值为 0 时 MAPE 直接发散；真实值为 1、预测值为 2 时 MAPE 是 100%，但在运力调度的视角里，这个误差的代价远比高峰期的 10% 要小。

因此我的评估表至少放四个指标：MAE、RMSE、MAPE、WMAPE。WMAPE 用真实值做权重，计算方式是 sum(abs(y_true - y_pred)) / sum(y_true)，它天然让高峰时段的误差在总分里占大头，和业务损失函数一致，也是我在报告里最看重的数字。评估时还要用零需求掩码处理夜间时段：把真实值和预测值都为 0 的样本剔除，避免指标被人为拉低。

def wmape(y_true, y_pred): mask = ~(y_true.values == 0) return np.sum(np.abs(y_true[mask] - y_pred[mask])) / np.sum(np.abs(y_true[mask]))

这个函数里的 mask 是零值掩码，只排除真实值为 0 的样本。真实值为 1、预测为 2 的样本保留，因为那也是真实误差；只有两边都是 0 才没有评估意义，这类样本集中在凌晨 2 点到 5 点，直接剔除对业务判断没有影响。

5. 网约车需求预测常见问题排查：5 个高发翻车点与修正方法

这一章是回报率最高的部分。数据和模型的大多数失败，都不是模型参数问题，而是隐藏的字段口径和特征泄漏问题。下面这 5 个翻车点是从真实项目里踩出来的，写出来给后来者省点时间。

5.1 节假日预测值系统性偏低

现象：到了节假日，模型预测的订单量连续几天明显低于真实值，越是峰值时段偏差越大。

原因：训练集里节假日样本占比通常不到 10%，树模型在梯度提升过程中不会给少数类别足够的叶子，整体预测向工作日均值回归；假期当天的时间特征跟工作日重合，模型找不到足够的信号把预测拉高。

解决：把节假日类型做成单独的分类特征，而不是只用 is_holiday 布尔值；把「节前第几天」「节后第几天」这类相对时间特征加上，让模型感知长假前后的模式变化。另一个更彻底的做法是单独训练节假日模型，样本不够就拼多年同期数据和相似假期的数据，再用天气特征做修正。

5.2 只用成交订单，低估真实需求

现象：模型离线误差很低，但用预测结果去做运力调度，司机到场后经常发现实际需求比预测多很多，用户抱怨叫不到车。

原因：训练数据只取了 status='completed'，把取消、无应答、乘客主动取消全部丢弃。这等于把需求序列的尾部砍掉，而高峰期被砍掉的恰恰是运力不足的信号。

解决：定义需求口径为「所有下单行为」，取消、无应答订单同样计数。如果业务指标关心成交率，单独再训练一个成交率模型，两个模型配合：需求模型给运力投放的总量，成交率模型评估服务质量，不要把需求模型和成交模型混成一个。

5.3 全局归一化造成时序泄漏

现象：LSTM 模型训练损失一路下降，验证集表现也正常，但上线后线上预测值明显偏小，尤其是凌晨时段几乎输出全 0。

原因：对全量序列做了 fit_transform，测试期的均值和方差被算进训练数据，模型偷看到了未来统计量，离线验证自然虚高。这个问题在树模型里也存在，如果对全量数据做标准化后再切分，同一个特征在训练和测试里共享了一次统计信息。

解决：统一改成先按时间切分，再在训练集上 fit 归一化参数，测试集只用 transform。规则可以再严格一点：任何涉及全局统计的特征（均值、方差、分位数、气候均值）都先按训练集计算，保存成对象，测试时载入。

5.4 凌晨全零时段让 MAPE 爆表

现象：模型整体误差不大，但 MAPE 在凌晨段动辄几千，开题答辩时被问到为什么指标这么差。

原因：凌晨真实需求大量为 0，MAPE 分母为 0 时无意义，极端情况造成指标失真。另一个副作用是，模型训练时会花大量梯度去拟合这些低价值样本，反而削弱晚高峰的预测精度。

解决：评估时对真实值和预测值都为 0 的样本做掩码剔除，或者改用 WMAPE 作为主指标；训练时对样本按时间价值加权，凌晨样本降权，晚高峰样本升权。如果业务确实关心夜间时段，把它单独拆成另一个问题，取更长聚合粒度（如 1 小时）来降低稀疏度。

5.5 天气字段与下单时间错位

现象：雨天预测值不稳定，明明天气预报有暴雨，模型预测反而低于同期晴天水平。

原因：天气数据按「发布日期」而非「下单时刻」对齐，或者时区转换出错，导致把未来几小时的天气当成了当前特征。比如晚高峰 18 点的订单，特征里却填了 20 点雨停后的天气，模型学到的就是「雨停时需求低」。

解决：在特征构造里强制规定一个对齐函数，所有外部数据先转成统一的 UTC 时间戳，再按 timestamp 所在整小时对齐。对齐之后做一次抽查验证：随机抽取 20 个雨天时刻，人工比对天气原始记录和特征列的值，这是最便宜的泄漏检测手段。

5.6 快速自检清单

开题报告送审前，我会按这个顺序自查一遍，每条都有明确动作，不靠感觉。

先查时间：edge_check 脚本跑一遍，确认 0、15、30、45 分钟位之外没有异常订单量；再查口径：status 过滤条件里是否保留了取消和无应答；然后查特征：把所有特征按时间排序，人工看是否存在「当前时刻不可能知道」的列；最后查评估：WMAPE 和零值掩码是否已实现。这四步做完，大部分导致返工的问题已经被挡在门外，数据没留版本是最大的后悔药——脚本、特征、模型结果都要能回放。

6. 滚动回测与线上影子对比：把验证流程写进交付物

多数开题报告止步于划分训练集测试集，但需求预测这类强时间相关的问题，静态划分很容易高估模型：数据的季节性和周期性会让模型在某个特定区间表现好，换个区间立刻打回原形。滚动回测是更贴近业务的做法。

import numpy as np horizon = 96 # 预测未来一天：96 个 15 分钟 step = 96 # 每 96 个时段滚动一次，即隔一天重训一次 preds, trues = [], [] for start in range(0, len(series) - horizon - step, step): train = series.iloc[: start + step] test = series.iloc[start + step : start + step + horizon] pred = model_fit_predict(train, horizon) preds.append(pred) trues.append(test.values)

滚动窗口有两个可调参数。horizon 是预测长度，我一般分 4 档：15 分钟（1 步）、1 小时（4 步）、3 小时（12 步）、1 天（96 步），分别对应调度、定价、运力规划不同场景；step 是滚动间隔，用 96 意味着每 24 小时重训一次模型，保证参数跟得上近期趋势。不建议评估时频繁重训，时间和存储成本都会失控，报告里也只需要把这几档窗口的指标曲线画出来。

线上验证部分，我习惯在模型上线初期只开影子模式：模型照常输出预测值，但不参与派单决策，把预测值落表存档，等三天后再跟真实订单量做回流对比。影子模式的好处是零风险，且能积累线上环境下的真实表现数据。对比时重点看两类误差：平峰时段的 MAE 是否在可接受区间，以及高峰时段是否有持续低估或高估的偏置，只要偏置超过 15%，问题的优先级就高于调小参数。

我现在做这类需求预测，习惯把「评估口径先固定、再谈模型改进」写进文档最前面：没有统一的窗口、指标和零值掩码，任何两个模型的比较都是自说自话。整套流程从订单清洗到滚动验证是一条完整链路，开题报告阶段不用急着调参，把链路跑通、口径立住，后面的优化才有参照系。希望帮到你。

本文还有配套的精品资源，点击获取