智能城市交通流量预测揭秘未来城市智慧出行的5大核心技术做智慧城市相关的项目也有七八年了交通流量预测这块算是其中落地难度最高、但回报也最明显的一个方向。前两天团队在做季度复盘翻出我们从最早用简单的时间序列模型做路口流量预测到现在融合深度学习、边缘计算做全域态势推演的全过程感触挺多。正好最近不少朋友在问智能城市里的交通流量预测到底怎么做用了哪些技术值不值得投入今天我就结合自己的实际项目经验把这套系统背后的5大核心技术掰开揉碎讲清楚。这篇内容适合刚入行的算法工程师、智慧城市项目负责人也适合想了解技术本质的产品经理——我会尽量避开那种“名词堆砌却什么都没说”的讲法把每项技术解决什么问题、怎么落地都讲透。1. 内容整体设计与思路拆解1.1 交通流量预测到底在预测什么先别急着谈技术。很多人一上来就聊LSTM、Transformer但连“预测什么”都没搞清楚。交通流量预测本质上是在回答三个问题某个区域在某个未来时段会有多少车路况会堵到什么程度什么时候开始堵、什么时候恢复我们做项目时把这三个问题拆成了三个子任务分别对应流量预测、速度预测和拥堵持续时间预测。流量预测解决“有多少车”用的是历史检测器数据和卡口数据速度预测解决“走得快不快”依赖GPS轨迹和浮动车数据拥堵持续时间预测则是“什么时候能通畅”这个最难因为它高度依赖事件的突发性——一场事故、一次临时管制都会让模型瞬间失效。搞清楚预测对象的粒度也很关键。是做路口级、路段级、还是区域级时间粒度是5分钟、15分钟还是1小时这些决策直接决定了数据采集方案和模型选型。我们最开始贪大求全想直接做全市路网预测结果数据稀疏、效果稀烂。后来收缩到主干道关键路口先把单点做准再考虑面状扩展。这个教训做这类项目的一定要记住先做窄而深再求宽而广。1.2 技术选型背后的三个核心矛盾搭建预测系统时你会发现所有技术选择本质上都是在平衡三个矛盾。第一个矛盾是精度与速度。复杂的深度学习模型预测精度高但推理时间长简单的统计模型速度快但精度有限。交通预测很多场景是实时性的比如信号灯自适应控制需要秒级响应这时候就必须在精度上做妥协或者用知识蒸馏把大模型压缩成轻量模型。第二个矛盾是数据量与数据质量。深度学习模型需要大量高质量历史数据但现实情况是检测器经常故障、数据缺失率高、异常值多。我们遇到过某个关键路口的数据完整率只有60%的情况直接用原始数据训练出来的模型预测结果跟随机猜差不多。这个矛盾没有完美解法只能通过数据清洗和补全技术尽量缓解。第三个矛盾是通用性与场景适配。学术界喜欢做一个通用模型解决所有问题但工程上不同路段、不同时段、不同天气条件下的交通规律差异极大。一个在全时段表现良好的模型到了早晚高峰可能完全失效。我们的做法是训练“基础模型场景微调”先在大规模数据上训练通用模型再针对拥堵时段、恶劣天气、节假日等特殊场景做二次微调。理解这三个矛盾你就能明白为什么交通流量预测系统从来都不是“一个模型打天下”而是一套组合拳。接下来我要讲的5大核心技术每一块都是为了解决这些矛盾中的某一面。2. 核心细节解析与实操要点2.1 核心技术一多源异构数据采集与融合很多人以为交通预测的第一步是选模型其实第一步是搞定数据。智能城市交通数据来源极其多样我把它们分成静态数据和动态数据两大类。静态数据包括路网结构、车道数、限速信息、信号灯配时方案等这些数据变化频率低但决定了交通运行的基本物理约束。动态数据则是实时变化的包括线圈检测器数据、地磁传感器数据、视频识别数据、GPS浮动车轨迹、手机信令数据、卡口过车数据、互联网地图路况数据等。这些数据源各有优劣。线圈和地磁检测器精度高但覆盖范围有限维护成本也高视频识别覆盖广但受天气和光照影响大雨雪天气识别准确率明显下降GPS数据覆盖最广但存在采样稀疏和漂移问题手机信令数据量大但空间精度粗糙。没有一种数据源能独立支撑高质量预测必须走多源融合的路子。实际操作中我们按三级架构做融合。第一级是时间对齐不同数据源的时间戳精度不同需要统一到同一个时间基准上第二级是空间匹配把不同坐标系、不同空间粒度的数据映射到统一的路网模型上第三级是置信度评估对不同数据源在特定条件下的可靠性打分动态调整融合权重。这里给你一个很实用的技巧做融合时千万别用简单加权平均。我们试过在晴天效果还行一到雨天视频识别置信度下降但GPS数据相对稳定如果还用固定权重预测误差会显著上升。后来改用基于实时质量评估的动态加权效果立刻提升了一个档次。动态权重是数据融合的关键。2.2 核心技术二基于深度学习的时序预测模型讲交通流量预测深度学习是绕不开的核心。但要说明白的是深度学习不是唯一答案也不是最优答案它是在数据量足够大时最强大的答案。我先说大家最熟悉的LSTM长短期记忆网络。它解决的核心问题是传统RNN的梯度消失/爆炸问题通过门控机制实现长期依赖建模。在交通预测中我们用LSTM建模流量在时间维度上的变化规律——比如早高峰的流量爬升模式、工作日的周期性模式。我们的实测经验LSTM相比ARIMA传统模型在15分钟粒度的流量预测上MAPE平均绝对百分比误差可以降低15%-20%。但LSTM有个天然短板——它只建模时间维度很难直接捕捉路网的空间关联。比如一个路口拥堵会影响相邻路口的流量分布这种空间上的传播效应纯时序模型学不到。这就引出了**图神经网络GNN**的应用。GNN的核心思想是把路网看作一张图路口是节点路段是边流量是节点属性。通过图卷积操作信息在节点之间传播模型就能学到“相邻路段的拥堵会如何互相影响”这类空间规律。实际应用中我们常用的是时空图卷积网络STGCN它同时包含时间卷积和空间图卷积一体两翼。再进一步是Transformer架构。近两年Transformer被应用到交通预测它的优势在于通过自注意力机制可以捕捉更远距离的时空依赖关系。比如东三环的拥堵可能会在40分钟后影响到北四环这种长距离、长时延的关联传统GCN很难建模但Transformer的注意力机制天然适合。我们最新的版本就在用时空Transformer做主干模型效果比STGCN又有明显提升。模型选型建议数据量小少于3个月历史数据优先用LR或GBDT这类传统模型数据量中等3-12个月用LSTM或STGCN数据量大超过1年且算力充足上时空Transformer。模型没有绝对的好坏只有适合不适合。2.3 核心技术三时空图网络建模空间依赖前面提到了GNN这里我单独拎出来重点讲讲时空图建模因为这是交通预测最区别于其他时序预测如股票预测、天气预测的核心技术。空间依赖建模的难点在于路网结构不是规则的网格像图片像素那样而是不规则图结构。CNN卷积神经网络是为规则网格设计的不能直接用在路网上——你不能拿一个3x3的卷积核去扫一个不规则的路口拓扑。图神经网络就是为了解决这个问题而生的。具体怎么做我们的做法分几步第一步构建路网图结构。每个路口或路段是图的一个节点相邻节点之间连边。边的权重代表两个节点之间的关联强度可以用距离、通行时间、历史流量相关性来定义。这一步非常关键直接决定后面模型效果的天花板。我们踩过坑一开始用简单的地理距离定义边权重模型表现一般。后来改为用“历史流量互相关性”作为边权效果提升非常明显。原因很简单交通数据的相关性不完全遵循地理距离比如高架入口和地面道路相距很近但相关性高两个平行路口虽然地理位置近但流量模式差异很大。第二步图卷积操作。图卷积的本质是让每个节点的特征融合邻居节点的信息。最简单的方式是加和邻居的特征更常用的是带权聚合——用邻接矩阵和度矩阵做归一化防止节点度数差异导致特征尺度不均衡。第三步时空联合建模。空间建模和时间建模不能割裂因为交通状态在时空上同时演化。我们的做法是两个分支并行——一个分支做时间卷积捕捉流量变化趋势另一个分支做图卷积捕捉空间影响——然后通过门控机制融合两个分支的输出。这样模型既能学到“这个路口早高峰有固定爬坡模式”也能学到“隔壁路口一旦堵死这个路口的流量 15分钟后会明显上升”。空间依赖建模还有一个值得关注的点动态图结构。传统STGCN用的是静态图——路网结构不变、边权不变。但交通中很多空间关系是动态的。比如发生事故时原本通畅的应急路线会突然拥堵这种动态变化静态图建模不了。现在比较前沿的做法是用注意力机制动态计算节点之间的隐含关联让模型自己“发现”这种突变的空间依赖。我们实测动态图结构在突发拥堵场景下的预测精度能提升25%以上。2.4 核心技术四边缘计算与端边云协同部署模型再准如果推理速度跟不上业务需求也是白搭。智能交通场景对实时性的要求非常高——信号灯自适应控制在秒级、V2X车路协同在毫秒级。如果把所有数据都传到云端再推理网络延迟和数据量都是灾难这就是边缘计算在交通预测系统中不可或缺的原因。边缘计算的核心思路是把推理能力下沉到离数据源最近的地方。在我们的系统中边缘节点部署在路口或区域机房直接对接路侧感知设备承担实时性要求高的推理任务比如信号灯优化、事件检测。云端则负责全局性、长周期的任务比如全域路网态势预测、模型训练和更新。端边云协同有一个非常关键的机制——模型下发与在线更新。边缘设备算力有限跑不了大模型所以我们需要把云端训练好的大模型压缩成轻量级版本下发到边缘。目前常用的压缩技术有三种知识蒸馏让小模型学习大模型的输出、剪枝去掉冗余的神经网络节点、量化把32位浮点数降到8位整数。我们实践中用得最多的是知识蒸馏量化的组合压缩效果能到80%以上精度损失控制在5%以内。再聊一下延迟数据帮助你建立直觉。我们的实测结果纯云端的推理链路数据上传-云端计算-结果返回平均延迟在300-500ms仅传输层就占了200ms。而边缘计算节点上的推理延迟可以压到30ms以下提升了一个数量级。对于信号灯控制这类场景这个差距是决定性的。但边缘计算不是万能的它在带来低延迟的同时也带来新的挑战——模型失活和漂移。边缘节点看到的只是局部数据长期不更新模型预测效果会逐渐变差。我们采取的策略是中央云端负责全局模型训练定期比如每天一次把更新后的模型下发到边缘节点边缘节点则会在本地做增量学习用实时数据微调模型参数适应本地特有的交通模式变化。2.5 核心技术五可视化交互与数字孪生呈现做了这么多预测最终要让决策者“看得见、看得懂、用得上”。这一环节做不好再牛的模型也等于零。可视化交互的核心载体是数字孪生。所谓数字孪生就是把物理世界中的交通系统在数字世界里建一个“镜像”这个镜像不仅长得像三维路网建模而且行为也像接入实时数据驱动。我们结合高精地图和三维建模把城市核心区的路网、建筑物、信号灯、车辆全部映射到数字空间中然后叠加预测结果。具体到可视化设计我强调三个关键点第一预测结果要与历史基线对比。光显示“预测路况拥堵指数7.5”没有意义决策者不知道这个7.5意味着什么。我们的做法是同时展示“当前实际值”和“预测值”以及“历史同期基准值”让预测的相对偏离程度一目了然。第二预测要有置信度表达。交通预测本质上是概率估计不是确定性结论。我们给每条预测曲线带上置信区间带让使用者知道这个预测有多可靠。置信区间窄决策可以更大胆区间宽就需要保留预案。第三交互要支持“白盒化”归因。算法给的预测结果如果能解释“为什么预测这里会堵”使用者就会更信任系统。我们实现了一个简单的归因模块能够显示哪些相邻路段的异常状态对当前路段的预测产生了主要影响。现在的高层管理者不只看结果更看依据。数字孪生还有一个附加价值是沙盘推演。决策者可以在孪生世界里面做假设测试——比如如果在这里新增一条车道对周边路网的流量分担会有什么影响把预测模型嵌入到孪生环境里配合场景编辑器就能变成一个交通规划沙盘。这块我们还在持续开发但已经能看到巨大的应用前景。3. 实操过程与核心环节实现3.1 数据采集与预处理从原始数据到可训练样本这一步在论文里永远是最简略的但在项目中永远是最耗时的。我们的经验是项目周期的50%以上都会花在数据上不是开玩笑。第一步是数据接入与质量体检。不同数据源来自不同的系统格式五花八门先要做格式统一。拿到数据后立即做质量体检字段缺失率、数值范围合理性速度有没有超过200km/h这种明显异常、时间连续性有没有超过N分钟的断档。这些体检结果会形成一张数据质量看板你后面会反复回看这张板因为数据质量差的时候模型效果差是必然的。第二步是数据清洗与补全。交通数据缺失太常见了——线圈坏了、网络断了、设备维护都会导致数据缺失。清洗策略分两层第一层是剔除明显异常值比如某时刻流量突增10倍多半是设备故障第二层是补全缺失值。补全方法从简单到复杂排序线性插值、历史同期均值填充、基于KNN的相似时段填充、基于矩阵分解的填充。我们实测下来KNN相似填充的效果最好但计算量也最大实际使用中可以按数据重要性来选择方法关键路口用高精度方法次要路段用简单插值即可。第三步是特征工程与时序样本构造。这是最能体现工程师经验的部分。除了基本的流量、速度、占有率外我们构建了这些高价值特征时间特征时刻0-23、星期1-7、是否节假日、是否特殊活动日历史窗口特征过去N个时间步的流量/速度序列周期性特征同时刻前两天/前一周的历史值捕捉周相似性空间特征相邻路段的流量均值、上游路段的拥堵状态外部特征天气温度、降水、能见度、温度、是否有事故事件样本构造方式很简单也很有讲究用[T-t, T]时刻的数据预测[T, Tt]时刻的数据。我们用的是滑动窗口方式窗口长度设为24个时间步如果粒度是15分钟就是6小时的历史预测步长设为4步即接下来1小时。预测步长超过1小时误差会快速放大这点要有心理准备。3.2 模型训练与评估一套可复用的技术栈我们的技术栈比较标准你直接参考即可框架PyTorch动态图方便调试生态丰富 PyTorch Geometric图神经网络专用库数据处理Pandas NumPy大数据量时用Dask并行模型结构GCN层LSTM层Attention层模块化组合训练策略Adam优化器初始学习率0.001余弦退火调整Early Stopping设为20个epoch评估指标MAE平均绝对误差、RMSE均方根误差、MAPE平均绝对百分比误差这里给一个关键的实践建议训练集/验证集/测试集划分不能随机切必须按时间顺序划分。否则会出现数据泄漏——模型“偷看”了未来数据验证时效果虚高上线就现出原形。我们的划分比例是6:2:2训练集在前段验证集中段测试集最后段。训练过程中要重点盯两条曲线训练Loss和验证Loss。如果验证Loss先降后升说明模型过拟合了需要增加正则化或减少模型复杂度如果训练Loss和验证Loss都居高不下说明模型欠拟合需要增加模型容量。我们常用的一招是梯度裁剪把梯度范数限制在5.0以内能有效防止梯度爆炸特别是在训练LSTM时。评估不止看指标数值。我们要求每次评估按场景做分层工作日/周末、高峰期/平峰期、晴天/雨雪天分开计算指标。你会发现一个普遍现象工作日高峰期和恶劣天气下的误差远高于其他场景。这些场景就是后续优化的重点——单独收集更多数据单独调参甚至用专门的小模型来兜底。3.3 部署与上线从离线模型到在线服务部署环节是算法工程师最容易忽视但也是最容易翻车的环节。实验室里跑得飞起的模型一上线就各种问题我见的太多了。模型上线前要做的第一件事是性能压测。用线上真实数据回放测试模型的推理速度和并发能力。我们有一个不成文的指标单次推理延迟不能超过实时性需求的1/3。比如信号灯场景要求500ms响应那模型推理就不能超过150ms剩下的时间要留给数据传输和业务逻辑处理。第二件事是部署容灾设计。模型服务要支持降级策略——当模型服务不可用时系统能自动切换到备用方案比如直接用历史均值预测保证业务不中断。我们在K8s集群上部署模型服务配置了多副本主副切换时间控制在秒级。第三件事是在线监控与模型漂移检测。模型上线只是开始不是结束。我们建立了一套实时监控每15分钟对比一次“预测值 vs 实际值”计算滚动误差。当误差连续异常升高时触发告警自动化评估是否需要重新训练或回滚到上一版本。这个监控机制非常关键因为交通模式不是静止的——路网改了、居民出行习惯变了、网约车多了都会造成模型失效。上线初期建议做灰度发布先用小流量跑几天对比新模型和旧模型在相同输入下的输出差异和实际效果指标确认没有劣化后再全量切换。这个过程能帮你躲掉不少坑。4. 常见问题与排查技巧实录4.1 预测结果总是“偏高”或“偏低”的系统性偏差现象预测值和真实值整体存在趋势性偏差比如预测流量总比实际高10%-15%。排查思路这种情况多半是数据层面的系统性偏差不是模型问题。我们遇到过一个典型case某个路口的线圈检测器校准不准记录值一直比真实流量高10%左右模型学了这个偏差预测自然一直偏高。解决办法是在预处理阶段做偏差校正或者换一个更可信的数据源做交叉验证校准。另外也要注意训练样本和线上数据的分布漂移。比如训练数据里天气多为晴天但上线后下雨天变多模型的预测就会出现系统偏高或偏低。解决办法是持续收集新数据并做周期性重新训练。4.2 高峰期的预测误差突然暴涨现象模型平时效果不错但早晚高峰时段误差急剧上升严重时MAPE超过30%。排查思路高峰期交通处于高度非线性状态小扰动会被放大——一个路口缓行会导致相邻路口流量变化剧烈。这种情况下全局通用模型往往力不从心。我们最终使用了分时段专家模型训练普通模型覆盖全天再专门训练2个高峰模型早高峰、晚高峰在高峰期自动切换到专家模型推理。这个方案上线后高峰期MAPE降低了18%左右。还有一个容易被忽视的问题高峰期的异常事件频率高而异常事件事故、临时管制、违规停车的数据样本太少模型学不到。建议建立事件特征标签训练专门的“事件影响系数”来修正高峰期的预测。4.3 恶劣天气下模型“失灵”现象雨雪天预测效果显著下降误差比晴天高出一倍。原因分析天气对交通的影响高度非线性小雨几乎无影响中雨开始有影响暴雨影响剧增这个阈值效应模型本身很难学到。加上恶劣天气样本少模型对这类极端条件的拟合能力天然不足。我们的解决方案第一数据侧做天气类型分层采样保证训练集中各种天气都有足够样本第二特征侧加入天气强度特征降水量、能见度、风力等级第三模型侧在天气模式下引入乘性修正因子——把天气的影响建模为与基准路况相乘的关系而不只是相加的关系。三者结合雨天预测的MAPE从28%降到了19%左右。4.4 新开通道路的冷启动问题现象新道路开通没有历史数据模型无法预测。解决思路这是典型的冷启动问题我们从两个方向入手。一是时空迁移学习——在具备相似路网结构和相似功能区比如都是住宅区到CBD的连接线的旧道路上预训练模型把学到的知识迁移到新道路上。二是基于仿真数据补充——用交通仿真软件比如SUMO、Vissim生成新道路的理论流量数据作为训练样本的补充。这个方法虽然无法做到高精度但至少能在冷启动阶段给出一个合理的baseline后续随着真实数据积累逐步替换。4.5 数据时延导致预测“滞后”现象模型输入的基础数据本身就有延迟导致预测结果虽然往前走了一步但有效信息还是15分钟前的。排查思路这是我们项目中真实遇到的性能瓶颈。某种数据源的上游处理链条很长从设备采集到进入模型输入中间经过了清洗、入库、ETL、特征计算才能进入模型服务而这些环节都引入了延迟。解决办法是建立实时数据管道用流式计算框架替代批量处理把端到端的数据链路延迟压缩到1分钟以内。这也是为什么我们逐渐把特征计算下沉到边缘节点——尽可能在数据源头做计算减少往返时延。常见问题典型表征排查方向解决方案系统偏差预测整体偏高/偏低数据质量、样本分布偏差校正、数据源校准高峰期误差激增早晚高峰MEPE30%非线性强化、异常事件干扰分时段专家模型、事件修正恶劣天气失灵雨天误差倍增非线性阈值效应、样本不足分层采样、天气特征、乘性修正冷启动困难新路无历史数据样本缺失迁移学习、仿真数据补充数据延时滞后预测有效信息陈旧数据管道过长流式计算、边缘特征计算5. 技术演进与项目实战复盘5.1 从LCSS到BERT交通预测模型的演进脉络回头看交通流量预测模型的发展能清楚看到一条从线性到非线性、从浅层到深层、从单点到图结构的进化路径。最早期的模型是统计时间序列方法ARIMA差分自回归移动平均模型和卡尔曼滤波是代表。ARIMA把流量序列拆解成自回归项和移动平均项用差分处理平稳性在数据波动不大时效果尚可但面对突发状况事故、天气突变几乎无能为力。然后是经典机器学习方法——支持向量回归、随机森林、梯度提升树GBDT/XGBoost/LightGBM。这类方法把预测问题转化为特征拟合问题优点是训练快、可解释性相对好缺点是模式表达能力有限特别是对时空关联特征需要大量人工构建。深度学习的爆发给交通预测带来质变。从2015年前后RNN/LSTM类方法成为主流到2018年左右图神经网络开始兴起再到2020年之后Transformer架构全面入侵。每个阶段的突破都指向同一个方向模型的结构设计越来越接近交通系统本身的物理特性。LSTM建模时间依赖GCN建模空间依赖Transformer同时处理长短依赖。结构越拟真效果越好。最近一年开始受到关注的趋势是大模型与基础模型。交通预测领域也开始尝试用预训练加微调的范式在许多城市的海量交通数据上预训练一个大模型然后在特定城市、特定场景上微调达到“一个模型适配多城”的效果。这种思路本质上借鉴了NLP领域BERT的成功经验非常值得关注。5.2 单体模型到多模型融合——我们的演进路线我们自己的系统演进路线很有代表性从简单到复杂大致经历了五个版本V1版本单一LSTM模型预测所有路口结果差强人意。问题很明显不同路口的流量特征差异大一个模型很难通吃。V2版本分路口建模每个路口训练独立模型效果提升但训练维护成本极高路口多时有几百个模型要训练和更新。V3版本共享骨干网络路口Embedding即共享大部分参数每个路口只学习少量的特定参数兼顾了个性化和可维护性。V4版本引入图神经网络从独立路口预测走向路网关联预测空间信息开始被利用。V5版本当前时空Transformer分时段专家模型外部特征修正形成了一套多模型融合的预测体系。这条演进路线的核心体会是不要急着上最复杂的技术。在数据、算力、业务需求逐步成熟的过程中逐步升级模型复杂度每一步都要能验证价值增量确实存在。一步到位往往导致项目失控。5.3 数据治理比算法调优更重要说实话做了多年交通预测我越来越认识到一句话“算法决定上限数据决定下限”。再好的模型喂进去一堆脏数据输出的也是垃圾。这背后有一个经常被忽视的逻辑交通流量预测的误差来源往往不是模型不够强而是数据本身的问题。数据缺失率高、噪声大、时空不同步、数据源之间冲突这些问题不解决算法层面的优化再多也无力回天。所以我现在特别强调数据治理体系的建设。一方面是自动化数据质量检测工具对所有接入数据源做实时质量打分另一方面是数据血缘追踪每一条进入模型的数据都能追踪到源头设备出了问题能快速定位。这些看起来不“高大上”的工作反而是整个预测系统能持续稳定运行的基石。另外数据治理不是一次性工程而是持续的运营工作。设备在老化、数据源在更新、业务场景在变化数据质量会不断波动治理机制必须持续运转。6. 写在最后的体会聊了这么多最后说几点我个人在实际项目中最深的体会。第一交通流量预测不是单纯的技术问题它必须与业务场景深度耦合。技术团队如果闭门造车做出来的模型再漂亮落到信号控制、交通诱导、公交调度这些实际业务中可能根本不匹配。我的建议是技术团队一定要花时间去现场——看真实路口怎么运转听交警和司机怎么描述拥堵这些“非技术”的信息往往会给你关键的设计启发。第二预测系统永远不要追求100%准确。交通系统本身存在混沌特性蝴蝶效应明显任何模型都无法做到完美预测。工程上应该做的是建立“预测-监控-反馈-修正”的闭环模型给出预测实时数据持续校验偏差超出阈值时自动修正或告警。把预测当动态过程而非一次性结果才是务实的做法。第三从“预测”到“决策”是下一步的蓝海。预测本身不是目的优化交通运行才是。当预测精度足够高之后系统应该给出“应该怎么做”的建议——信号灯配时怎么调、诱导屏发布什么信息、公交车要不要加班次。我们的系统正在从“预测平台”向“决策辅助平台”演进这条路还很长但方向肯定是明确的。做智能交通这么多年最让人开心的时刻不是模型精度达到多少而是亲眼看到预测系统提示了即将到来的拥堵而交通管理者根据预测提前调整了信号配时实际拥堵时间和程度真的减轻了。技术的价值最终要落到这些实实在在的业务收益上。交通流量预测的坑还有很多这篇先写到这里。如果你正在做相关项目或者对某个环节有疑问欢迎一起交流。后面我打算再整理一篇关于多城市复用经验的实操笔记把城市之间模型迁移的坑和方案详细聊聊。