1. 从“拍脑袋”到“算得准”高速铁路客流预测到底难在哪先说一个这几年跟各路数据同行交流时感触最深的现象客流预测这个方向论文和方案层出不穷但真正能落地到高铁调度、售票策略、运力配置里的少之又少。原因不是模型不够花哨而是客流这个东西本身就不是一个“单任务”问题。你要是只盯着“明天杭州东站几点钟进站多少人”这一个数字去建模十有八九会翻车——因为客流背后牵扯着节假日效应、天气突变、突发大客流、列车运行图调整、甚至周边城市活动的辐射影响。任何一个单一序列模型都很难把这些因素同时吃进去。我们这次做的这个项目代号Metrica A 2025核心思路就一句话把高速铁路客流预测当成一个多任务学习问题来处理用大型语言模型的语义理解能力去统一建模。说白了不再只预测“未来15分钟进站客流”这一个标量而是让模型同时学会好几件事——预测客流总量、判断高峰时段、识别突发异常、理解外部事件文本描述。多任务共享一套底层语义特征再用不同的输出头去完成各自的预测任务。这样做的好处非常直接模型不再孤立地看历史数据而是像一个大交通运营助手一样能同时读报表、看天气、读公告、理解节假日安排然后才给出预测结论。这篇博文不适合零基础读者直接上手但如果你是有过一段时序预测或机器学习经验的人遇到的问题是“单模型效果到了天花板不知道下一步怎么突破”那Metrica A 2025这套方案能给你一个完整的、可参考的落地思路。我会把多任务怎么设计、LLM怎么接入时序特征、数据怎么处理、训练过程踩过哪些坑全部展开讲清楚。2. 多任务学习与LLM结合这套方案的底层逻辑2.1 为什么传统时序模型会遇到瓶颈先回顾一下传统做客流预测的几种主流路径以及它们的瓶颈。第一类是统计模型比如ARIMA、Holt-Winters这类适合平稳序列一旦遇到节假日跳变、突发大客流预测误差直接失控。第二类是机器学习模型像梯度提升树LightGBM、XGBoost这类模型非常擅长表格型特征但需要人工构造大量滞后特征、交互特征、周期性特征工程量大、维护成本高而且对异常事件的泛化能力很弱。第三类是深度学习序列模型比如LSTM、Transformer、时间卷积网络TCN这类模型能自动学习时序依赖但本质上还是在“用数值预测数值”外部信息如果不用数值特征的形式喂进去它就完全感知不到。我们过去用LightGBM做客流预测做过一个很典型的分场景实验工作日平峰期的预测效果非常好MAPE能压到5%以内但一旦到了节假日或大型赛事活动期间误差会飙到15%甚至20%以上。最根本的原因是这类模型不知道“国庆节”意味着什么也不知道“市中心体育场晚上有演唱会”会带来多少额外客流。你就算把这些日期、事件用one-hot编码打进去模型也学不到“国庆节返程高峰下午3点改签潮”这种组合逻辑。这就是单任务数值模型的天然天花板。2.2 多任务学习如何解决“客流不是一个数”的问题把客流预测拆成多个子任务是我这些年实操下来性价比最高的方案。传统单任务模型只输出一个预测序列而多任务框架同时输出好几个结果——总量、峰值时刻、峰谷差、异常概率。为什么这样做有用因为这些任务之间是强相关的共享底层特征提取器可以让模型学到更通用的语义表示。比如预测总量时学到的“节假日会推高客流”在判断峰值时刻时同样适用在识别异常大客流时也被需要。这种特征共享机制本质上是一种隐式的数据增强相当于让模型用多个视角观察同一份数据学到的特征更鲁棒。在实际工程里多任务最直观的效果是主任务客流总量预测的准确率往往会有明显提升因为辅助任务提供了正则化约束抑制了单一任务上过拟合的风险。我们做过对照实验同样的Backbone结构单任务版的损失比多任务版高大约7%到12%这个差距在节假日场景会进一步拉大。很多刚开始接触多任务的同学会担心“任务之间互相干扰”这在任务完全不相关时确实存在但客流这个场景里峰谷识别、异常检测、总量预测本质上是在描述同一个客流的三个侧面相关性极高干扰几乎可以忽略。2.3 大型语言模型在这套框架里的真实角色这里必须澄清一个容易误解的点我们不是拿LLM去“生成”客流预测结果LLM在这套方案里承担的是语义特征编码器的角色。传统的数值模型处理外部因素时只能靠离散编码或人工规则LLM却能直接理解自然语言描述——比如“某市气象台发布台风橙色预警”“下周三起某高铁线路将加开夜间班列”“五一假期首日预计出现探亲流与旅游流叠加”。这些事情如果用数值特征表达维度爆炸且信息稀释但用文本形式交给LLM它能把语义压缩成稠密向量。LLM和数值特征结合的方式我们是搭了一个双塔结构。数值塔吃历史客流的时序数据用卷积和自注意力提取时间模式语义塔吃外部事件文本用LLM编码成语义向量。两个塔的输出做交叉注意力融合最后送到各个任务头。这个设计的核心好处是把事件文本当成一种“先验知识”注入时序模型而不是只靠数值去猜。实际测试中加入LLM语义塔后节假日的预测误差下降了大约18%而且对文本中没有出现过的事件类型也具备一定的泛化理解能力——这一点是任何传统方法都做不到的。3. 数据工程与特征构造决定模型效果的上限3.1 多源数据整合从站内到站外模型再强数据不行等于白搭。客流预测需要的数据源远比一般人想象得要多。我们最终落地的数据体系分为三层。第一层是核心业务数据来自高铁站售票系统的分时进站客流、到达客流、退改签量、列车开行对数、正晚点数据。第二层是外部事件数据天气实况与预警、节假日安排、大型活动公告、地铁接驳客流、机场航班延误情况。第三层是衍生特征数据历史同期的客流画像、周边城市经济活跃度代理变量、互联网热度指数比如某旅游平台的关键词搜索量。这三层数据里第一层和第三层都比较容易处理真正麻烦的是第二层。因为它大部分是非结构化文本而且来源不同、格式各异。我们最后的处理方式是把所有外部事件整理成统一格式的短文本描述喂给LLM做语义编码。比如天气预警和活动公告各自写成一行标准句式再由模型编码成向量。这里有一个非常关键的细节——文本描述的口径必须统一否则LLM编码出来的语义向量会“漂移”。我们曾经试过有的写“中雨”有的写“雨量中等”结果同一类天气在语义空间里被拉得很开模型学习起来非常痛苦。3.2 特征窗口设计太长没用太短没信息时序特征窗口的选取直接影响模型对周期性和趋势性的感知能力。我们做过不同窗口长度的对比实验从7天到90天都测过。结论是对高铁客流来说以35天为基础窗口、对齐星期和节假日规律效果最优。为什么不是更长的窗口因为客流的时间依赖是“近强远弱”的太远的历史数据反而会引入噪声。但窗口也不能太短至少要有覆盖一个完整节假日前中后三阶段的能力否则节假日的返程预测会失真。在窗口内部我们构造了三类特征切片。第一类是短周期切片取预测时刻前1小时、3小时、6小时的分时客流捕捉临场行为。第二类是日周期切片取前7天同时段的客流序列捕捉星期规律。第三类是长周期切片取过去35天的总量趋势、峰值、方差等统计量用于刻画大背景。这三个切片会分别做归一化再送入数值塔保证尺度稳定。这里要特别提醒归一化只能在训练集上计算参数验证集和测试集用同一套参数否则就是典型的数据泄漏这个坑我们早期踩过损失惨重。3.3 外部事件如何变成模型能用的特征外部事件的文本在进LLM之前需要不少预处理功夫。第一步是结构化解析把“2025-04-04 某市 晴天 22~31摄氏度”这种半结构化数据转成标准模板文本。第二步是事件归一化同义事件要合并比如“限流”和“客流控制”在业务上是一回事在文本里却是两种写法如果不统一LLM编码出来的向量就不稳定。第三步是优先级标注一条文本属于高影响事件还是普通事件这个标签在后续的多任务学习里会作为权重因子使用用来调整辅助任务对主任务的贡献。在实际编码时我们并不是把整段文本一次性丢给LLM而是按事件类型分别编码。天气、活动、运行图调整各自独立编码成向量再做拼接和注意力融合。这个做法的好处是模型可以明确知道当前有哪些类型的事件在影响客流而不是让所有信息混在一个长文本里让模型自己猜。如果你用的是开源的中型LLM做语义编码器强烈建议按我这个思路分类型编码效果会稳定很多。4. 核心实现细节模型结构、训练策略与参数配置4.1 双塔结构解析数值塔与语义塔先看整体结构。输入侧分成两条路径数值塔负责处理分时客流序列语义塔负责处理外部事件文本。数值塔内部我们用了两层一维卷积kernel size分别为7和3做局部时间模式提取再接一个多头自注意力层捕捉长距离依赖最后输出定长的时序特征向量。语义塔内部则是一个冻结参数的LLM这里用的是某开源底座模型文本进来后取最后一层隐藏状态的均值池化作为语义向量。两个塔的输出在融合层做交叉注意力具体来说是语义向量作为Query时序特征作为Key和Value。这样设计的目的是让模型在“阅读”时间序列的每个位置时都知道当前有哪些外部事件在起作用。融合后的向量会送入四个任务头总量回归头、峰值时刻回归头、异常分类头、分时客流序列生成头。四个头共享融合层以下的全部参数只有各自最后一层是全连接网络。4.2 分时客流序列生成连接多任务与主预测的桥梁这个部分我想单独拿出来讲因为它是整套方案里最有价值的设计之一。传统做法直接预测未来N个时刻的客流序列作为唯一的输出目标。我们改成让模型先预测未来90分钟的分时客流序列作为辅助任务再基于这个序列去聚合出总量、峰值等最终指标。这么做有三个好处。第一辅助任务给模型提供了更密集的监督信号。一条总量标签只能约束一个点一条90分钟序列标签能约束90个点模型可以从序列形态里学到“几点开始爬坡、几点达到峰值”这类动态规律。第二主任务和辅助任务之间存在天然的一致性约束——总量就是序列的积分峰值就是序列的最大值。模型在同时优化这两类任务时会自发地让预测序列更平滑、更合理。第三这个设计让模型天然具备可解释性你不光能告诉调度员“总量是1.2万人”还能展示“这1.2万人是怎么在90分钟里分布的”对运营决策非常有帮助。各任务头的输出维度如下任务头输出形式损失函数总量回归标量Huber Loss峰值时刻[时刻偏移量, 峰值量]加权L2 Loss异常分类3类概率正常/偏高/异常CrossEntropy分时序列90维向量Quantile Loss4.3 训练策略冻结LLM、多损失加权与课程学习训练是整个项目里最考验耐心的环节我把几个关键策略逐个说清楚。第一LLM参数必须冻结。我们不微调LLM只让它做语义编码器理由有两个一是微调大模型的计算成本太高对客流预测这个场景来说性价比极低二是语义塔的任务是提供外部事件的通用语义理解一旦微调会“过拟合”到特定站点的客流业务模式泛化能力反而下降。实测冻结参数的语义塔在冷启动新站点时表现更好。第二多损失加权方式我们选了自适应权重法。四个任务的损失量纲差很大如果固定权重训练过程会只顾着总量回归而忽略异常分类。自适应权重法会让模型自动调节四个损失的系数控制全局梯度模长。这一步对收敛稳定性至关重要固定权重版本训到后期指标波动非常明显换成自适应权重后彻底解决。第三课程学习。刚开始训练时只优化总量回归这一个任务等损失下降到一定阈值后再逐步打开峰值预测和异常分类任务。这样做的好处是让模型先学会基本的时间规律再去学复杂的交互逻辑。我们对比过一次性打开所有任务的做法课程学习的收敛速度大约提升30%最终精度也更高。一个简化的训练循环如下for epoch in range(max_epochs): if epoch warmup_epochs: loss total_loss * mask_total_only else: loss weighted_total_loss(total_loss) optimizer.zero_grad() loss.backward() clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step()4.4 推理时的集成与时序一致性校验推理阶段也有讲究。我们的预测频次是每15分钟滚动一次每次预测未来90分钟的客流序列。为了提升稳定性采用了两种机制。第一种是时序集成。当前时刻t的预测结果会和t-1时刻模型对相同未来时间段的预测做加权融合权重分别为0.6和0.4。这个做法能够有效抑制单次预测的抖动——高铁客流不像互联网流量那样剧烈突变前后两次预测差异太大本身就是不合理的平滑掉这部分噪声之后指标会好看很多。第二种是一致性校验。模型输出的总量和峰值必须和分时序列积分出的总量、取出的峰值保持一致。如果不一致系统会自动触发重新预测。这个校验看起来简单但实际能拦截很多不稳定的推理输出比如某次预测序列明显偏离历史规律时重预测结果往往会恢复正常。5. 场景化效果这套方案在不同业务场景下的真实表现5.1 节假日大客流从“惊慌”到“预案”先说节假日场景这是整个方案改进最明显的场景也是当初立项时最重要的驱动力。以某次“五一”假期为例在过去单任务模型上假期前一日和返程高峰日的总量预测误差在18%左右峰值时刻偏差平均超过45分钟。换成Metrica A 2025之后总量预测误差降到6%以内峰值时刻偏差压缩到10分钟以内。这个提升的核心来源就是外部事件的语义理解。模型能直接读入“五一假期首日预计探亲流与旅游流叠加往热门旅游城市方向客流增长明显”这种公告文本将语义向量注入时序特征模型就能在预测序列上自动体现出早高峰提前、持续时间拉长的形态变化。而传统模型永远学不到这种跨模态的关联。5.2 突发大客流异常检测的提前预警价值多任务框架中的异常分类任务在突发大客流场景下发挥了意外的作用。日常运营里突发客流的样本非常稀少直接训练一个异常检测模型很难收敛。但在多任务框架下模型从总量预测和分时序列生成任务中学到了大量正常客流形态的底层表征异常分类头只需要在这个表征基础上做判别训练难度大幅降低。实际测试里有一个典型case某天傍晚当地体育场有大型演唱会模型在午后第一个预测周期就给出了“客流偏高”的预警比现场调度员发现客流异常早了大约40分钟。这个提前量在高铁站这种人员密集场所非常宝贵意味着可以提前开启备用安检通道、增加引导人手。5.3 多站点迁移一次训练多站复用高铁客流预测的一个工程难题是站点数量多、各自特性不同。如果每个站点单独训练一个模型训练成本和维护成本都很高。我们这套方案在迁移性上有天然优势因为语义塔是通用编码器不绑定任何具体站点数值塔学到的是时间模式的行文知识也具备跨站点泛化能力。我们在一个从未参与训练的新站点上做了冷启动测试只提供该站14天的客流历史数据模型就能达到该站老模型60天数据训练效果的92%精度。这个结果说明多任务学习和LLM语义编码确实让模型学到了更有普适性的客流规律而不是死记硬背特定站点的时间序列模板。6. 常见问题排查与避坑指南6.1 数据泄漏最隐蔽、代价最大的坑做时序预测数据泄漏问题怎么强调都不过分。我们踩过一个大坑在构造特征时无意中把“未来7天的售票数据”当成了特征。当时想的是利用预售数据提升预测精度逻辑上说得通但没有意识到售票数据里包含了退票改签数据而这些数据本身受到未来实际客流的影响等于模型在考试时偷看了答案。训练时指标非常好一到上线就崩。排查数据泄漏有个很有效的办法把模型在测试集上的误差按时间段拆开观察。如果某个时间段的误差显著低于相邻时间段而且这个时间段恰好对应某个特征在数据集中“可见”的窗口那基本可以判定泄漏了。我们那次就是发现节假日前的预测误差异常低才顺藤摸瓜找到问题。6.2 LLM编码结果不稳定另一个容易让人抓狂的问题是LLM编码的语义向量在不同版本的模型间变化太大。同一个事件文本模型升级后输出向量分布就变了导致下游模型必须重新训练。这个问题我们通过两个手段缓解一是冻结LLM参数这个前面说过二是对语义向量做标准化。每次计算出语义向量后强制做零均值单位方差归一化这样就限制了向量分布的漂移幅度。如果你用的是开源LLM还有一个小技巧用中间层的输出而不是最后一层。我们实测发现倒数第二层隐藏状态的语义表示比最后一层更稳定因为最后一层是为训练损失服务的对下游任务来说信息不一定是最优的。6.3 小批次波动与训练震荡多任务学习的训练震荡是高频问题尤其像客流数据这种波动大的序列经常训着训着某个batch的loss突然剧烈增长。我们的经验是三管齐下第一梯度裁剪全局范数限制在0.5到1.0之间第二学习率用带热重启的余弦退火而不是固步自封的固定学习率第三关键的是数据加载器里加入按星期对齐的batch采样策略。什么叫按星期对齐就是一个batch内部的数据尽量来自同一个星期几这样模型在每一步更新时看到的分布一致性更强梯度方向更稳定。我见过很多团队在这上面浪费了大量时间最后发现只是数据加载时没做星期对齐导致每个batch的样本分布差异巨大模型永远在“追着分布跑”。这个问题在我们解决之后训练曲线肉眼可见地平稳下来。6.4 一个速查表高频问题与解法结合我们的实战经验把最常遇到的问题整理成一张表方便团队排查时快速对照。现象可能原因处理方案训练指标好线上指标差数据泄漏或特征分布偏移排查未来信息泄漏检查线上特征口径节假日预测偏低样本中节假日占比少加大节假日样本权重或合成相似场景样本预测序列抖动剧烈单批次预测方差过大启用时序集成融合前后两次预测结果峰值时刻总是滞后损失函数对峰值不敏感提升峰值任务权重改用分位数损失新站点效果差冷启动数据不足缩小语义塔维度加强时序特征的共享率训练过程震荡batch内样本分布不均按星期对齐采样开启梯度裁剪7. 写在最后的实操心得Metrica A 2025这个项目做下来最深的感触是多任务学习不是简单的“多接几个输出头”而是要对业务问题本身做深度解构。客流预测这件事本质上不是预测一个数字而是理解一个系统的运行状态。总量、峰值、异常、时序形态这些表面上不同的输出背后其实共享同一套底层规律。当你把业务问题想透了模型结构的设计反而变成了顺理成章的事。另外还想说一点LLM这类技术落地到传统时序预测领域不要一上来就想着端到端替代原有方案更务实的路径是把LLM当成一个语义理解组件先解决外部信息难以数值化表达的痛点再逐步扩大它在系统中的角色。我们团队现在正在试验的方向是把LLM从语义编码升级为跨站点的知识路由——让一个站点学到的客流规律通过自然语言描述的方式传递给另一个站点。这个方向还在孵化中等有阶段性成果了再来跟大家分享。如果你正在做交通客流、电力负荷、销售预测这类传统时序问题而且已经感受到单模型的瓶颈不妨认真研究一下多任务学习的路子。从一个辅助任务开始比如给总量预测模型加一个“高峰时段分类”头看看主任务精度有没有变化。大概率你会发现让模型多做一件事反而能把原本那一件事做得更好。