2024年春运期间我在调度台旁边蹲了三个晚上，发现一个很有意思的现象：系统预测的某枢纽站次日客流和实际到发量差了三成，但第二天早上的交班会没人能提前看出问题。后来把问题推到数据层回头看，发现模型并没有崩溃，而是它压根“不知道”那天发生了什么——周围的临时限流、暴雨预警、热门演唱会散场、临时加开列车，这些信息全部躺在公告和调度日志里，没有任何一个传统预测模型读得进去。
这个痛点直接催生了Metrica A 2025项目：用基于多任务学习的大型语言模型（LLM）做高铁客流预测。简单讲，就是把“客流预测”从一道纯粹的数值拟合题，改造成一道模型能够“阅读理解+推理”的语义题。过去我们告诉模型的是“昨天1000人、前天1200人、上周一900人”，现在我们还会告诉它“明天是长假最后一天、北方有强冷空气、某博览会在闭幕日上午散场”，让模型像人一样把数字和事件放在一起判断。
这篇文章把我们从立项、数据清洗、模型设计到上线验证的完整链路整理出来，包括为什么用多任务学习、数据怎么准备、Token怎么处理、任务头怎么挂、调参踩过哪些坑。适合正在做交通预测、时序预测，或者想把大语言模型真正落到业务场景里的团队参考。不吹效果，只说我们实际做到的和没做到的事。
1. 为什么高铁客流预测值得用LLM重做一遍
1.1 传统预测方法的瓶颈
客流预测不是一个新问题。经典的ARIMA、季节性分解、指数平滑，在平稳客流场景下表现不差；后来深度学习流行，LSTM、GRU成为序列建模主力，再后来图神经网络被用来建模路网结构，效果进一步提升。我们团队前几年就在生产环境里跑过一整套“XGBoost + LSTM + 规则兜底”的混合方案，平峰期预测误差基本可控，真正的问题集中在“突变场景”。
什么叫突变场景？长假返程高峰、大型赛事散场、恶劣天气导致列车晚点、热门新线开通后的客流爬坡、临时限流公告引发的改签潮。这些事件的共同特征是：历史数据里出现的次数极少，但影响幅度极大，而传统模型本质上是在用“过去平均值”推断未来。XGBoost能记住“国庆节客流是平时的1.8倍”，但它学不会“明天体育场有八万人演唱会，且地铁末班车提前到22点，所以21:30会有一波离场客流叠加进站”。这不是特征工程能简单解决的，因为关键信号以文本、事件、公告的形式存在，不在标准表格里。
1.2 LLM给时序预测带来了什么新变量
大语言模型最核心的能力是语义理解、长上下文建模和跨领域迁移。我们当时内部讨论时打过一个比方：传统模型像一把精确但是盲目的尺子，LLM像一个读过很多书、见过很多世面的实习生——你给它一张数据表，它可能算得不如尺子快，但你能跟它对话，告诉它“今天有雨，大家可能提前出发”，它能理解这句话对客流意味着什么。
放在高铁客流预测的场景里，这意味着三件事：
第一，非结构化数据可以直接进来了。天气预警、路局公告、社交平台上的活动信息，不用再费力转成数值特征，而是以文本形式作为Prompt的一部分喂给模型。第二，模型具备对“罕见事件”的类比能力。它没直接见过某场馆的万人演唱会，但在预训练阶段读过大量类似事件对交通影响的文章，知道“大型活动散场+交通管制=瞬时客流尖峰”这种因果链条。第三，长序列建模能力让我们能利用更久的上下文——过去30天甚至90天的客流形态，而LSTM受梯度问题影响，真正有效利用的历史窗口往往只有几天。
1.3 多任务学习解决的三个实际问题
单任务预测模型在数据充足时够用，但高铁客流预测有几个现实约束必须面对：新开通线路历史数据少、突发事件样本稀疏、单站预测容易忽略全网联动。我们最终采用多任务学习，主要是为了三个目的。
第一个目的是共享表征。主任务是“未来一小时客流曲线预测”，辅助任务包括“当日客流总量预测”“未来15分钟短临预测”“客流事件类型识别（日常通勤/周末休闲/小长假峰值/恶劣天气扰动）”。多个任务共享底层的语义编码器，相当于让模型在训练时同时从细粒度、粗粒度、分类视角看同一批数据，学到的特征表示更鲁棒。
第二个目的是缓解冷启动。某条新开城际线运营不到3个月，主任务可用训练样本很少，模型很容易过拟合。但辅助任务里包含大量跨线路通用的模式知识（比如“节假日最后一天下午会返程高峰”），多任务联合训练让新线路也继承了这些归纳偏置。
第三个目的是给模型可解释的行为约束。辅助任务中的事件类型分类，相当于在模型内部建立了一个“先判断今天是什么日子，再预测客流”的中间变量。它不能保证模型一定按这个逻辑推理，但分类梯度会持续强化这种结构，比单纯输出数值更符合业务专家的认知。
2. 数据准备：从购票记录到结构化训练集
2.1 数据源与字段设计
训练一个多任务LLM预测模型，数据准备的工作量比模型搭建还要大，这块在整个项目周期里占了将近一半的时间。我们最终整合了五个数据源，统一落在离线数仓里：
| 数据源 | 主要内容 | 粒度 | 用途 |
|---|---|---|---|
| 票务闸机流水 | 进出站记录、OD区间、票种 | 单条记录 / 15分钟聚合 | 主任务真值 |
| 列车运行图 | 计划到发时刻、临时加开、晚点信息 | 单列车 | 上下文特征 |
| 气象数据 | 温度、降水、风力、能见度、预警等级 | 1小时 | 辅助特征 |
| 日历与事件库 | 节假日、调休日、大型活动日程 | 单事件 | 语义特征 |
| 公告与调度日志 | 限流通知、设备故障、突发大客流记录 | 文本 | Prompt语义输入 |
一张表要能同时服务数值特征和文本语义，所以每个样本不是简单的一行记录，而是一个结构化的“情境包”：以预测目标为中心，向前取14天历史客流序列和7天天气序列，再加上目标日的节假日属性、事件文本和调度公告。这样的设计方便后面对齐构造Prompt。
关键细节是预测粒度的选择。我们一开始尝试过按“日”预测，但业务方反馈日粒度对运力调整帮助有限。最终主任务定在15分钟粒度、未来4小时（16个预测点），同时辅助任务覆盖15分钟短临和日总量两个尺度，形成“三档时间尺度”体系，让模型在不同视野下都能学到东西。
2.2 时间序列Token化的两种路线
LLM输入是离散Token，但客流量是连续数值。怎么把数值变成模型能吃的形态，我们试了两条路线，也踩了第一轮坑。
路线A是分桶离散化：把客流值按分位数切成200个桶，每个桶对应一个Token ID。这么做的好处是思路简单，和文本Token天然对齐。但实验下来问题很明显：分桶丢掉了数值间的顺序关系——桶150和桶151之间差一个人，但模型看到的是两个完全无关的Token；而当实际客流落在桶边界附近时，预测结果会在相邻桶之间来回跳，输出曲线抖动严重，业务方完全不能接受。
路线B是Patch Embedding：把连续的客流序列切成固定长度的小块（Patch），每个Patch做完归一化和编码后，通过一个线性投影层映射成一条向量，再与文本Token的Embedding拼在一起送进模型。Patch的方案在近期时序预测里被验证得比较多，它把“预测”变成“对最近一段模式的续写”，而不是一个个Token去猜。
我们最终采用的是Patch Embedding，配合残差回归修正。具体来说，主序列按每4个时间点（即1小时）切一个Patch，24小时上下文得到24个Patch，每个Patch内部做LayerNorm，投影到模型隐藏维度。模型输出不再是离散Token预测，而是对后续16个时间点的连续值回归。数值头的输出经过反归一化还原为实际客流，同时在最后一层额外加一个小的残差全连接层，用来修正Patch化带来的局部细节损失。这套组合在测试集上比纯分桶离散化MAE降低了11.3%，输出也平滑得多。
2.3 辅助任务标签怎么构建
多任务学习不是把几个Loss加一块就完事，标签的质量决定了辅助任务到底是在帮主任务还是帮倒忙。我们对四个辅助任务的标签做了不同的构造策略。
当日客流总量预测属于回归任务，标签直接就是当日所有站点的进站客流加和，简单可靠。未来15分钟短临预测同样来自闸机流水，和主任务共用真值，只是预测步长更短，相当于给模型提供一个“易学任务”作为梯度的锚点。客流事件类型识别是一个四分类任务，但标签不能直接由运营人员手工打——几千个站点、一年数据，人工标不过来。我们用的是一种自监督式的生成方式：先用聚类算法把历史日客流曲线分成四类，再结合日历和气象数据人工校验簇的语义，打上“日常通勤日”“周末休闲日”“小长假峰值日”“恶劣天气扰动日”这四个标签。最后一类是异常事件标记，二分类，判断当日是否发生过突发大客流，标签来源于调度日志里的关键词匹配加上人工复核。
这里有个很重要的原则：辅助任务标签宁可粗糙也不能乱。我们遇到过某站点因为闸机故障导致日总量标签少了20%，模型在这个站点上的主任务预测误差同步飙升，最后追溯起来发现是脏数据污染，白折腾了一周。所以多任务标签的质量，至少要和主任务真值一样被严格对待。
3. 模型架构：把预测任务改写成LLM能理解的语言
3.1 输入序列怎么组装
模型选型上，我们用的是某个参数量约10B级别的开源底座模型，基于Transformer解码器结构、在英文和中文语料上做过预训练。选择这个体量是综合考虑了效果和推理成本，再大号的模型在单机推理上根本扛不住实时预测需求，再小号的语义理解能力又明显打折扣。
输入序列的组装分三层。第一层是数值序列，历史14天、每天96个15分钟点，按小时切Patch后投影为向量序列。第二层是结构化上下文，包含目标日的日期信息、节假日类型、天气数值（温度、降水量等），这部分同时走数值Embedding和文本投影两条路——数值嵌入用于保留精确量级，文本描述用于激活语义知识。第三层是非结构化文本，把调度公告、活动信息整理成简短的陈述句，比如“2025年2月2日，本站因轨道检修，安检口临时关闭2小时”“晚上8点XX体育场有演唱会，预计散场客流约3万人”。
最终输入序列是“数值Patch Token（24个）+ 时间特征Token（8个）+ 文本Token（视长度而定，通常控制在128个以内）”。这里有个实践教训：文本不是越长越好，我们把公告里和客流无关的信息（比如具体的设备编号、负责人联系方式）全部去掉，只保留事件、时间、影响范围三要素，模型效果反而更稳定。
3.2 多任务头挂在哪里
多任务架构里一个容易犯错的地方是“任务头怎么挂”。如果直接把主任务和辅助任务全部接到模型最后一层输出上，任务的梯度会互相打架——分类任务要求特征空间线性可分，回归任务要求精确的数值精度，二者对中间表示的偏好不完全一致。
我们的做法是把底座模型分为两部分：主干部分用LoRA做低秩微调，任务相关的部分则放在浅层的Adapter和独立的Task Head上。四个任务头共享主干输出的前96层隐藏状态，但从第88层开始分出两个分支：一个分支通向主回归头，用于15分钟粒度客流预测；另一个分支经过一个轻量Adapter后，通向三个辅助头。LoRA的秩我们设的是64，Adapter的隐藏维度是256，这样微调的参数量只占模型总量的不到1%，训练成本可控。
通常主回归头只需要最后一个时间步对应的隐藏状态就够了，我们实际测试后发现把最后四个Patch位置的状态做加权平均，效果比单点更好——因为短临预测对最近几小时的形态很敏感，单点状态容易丢失局部信息。
3.3 Prompt设计与上下文窗口
多任务学习里的Prompt不只是给模型看的一段话，它是用来对齐任务和约束输出的脚手架。我们最终使用的模板大致长这样：
你是一名高铁客流预测专家。请根据以下历史客流数据和环境信息，预测[站点名称]未来4小时、以15分钟为间隔的进站客流序列。 历史客流（按小时）：[数值序列][数值序列]... 日期信息：[2025-02-02，周日，春节法定假期第4天] 天气情况：[小雨，东风3级，温度2-6摄氏度] 近期事件：[2月2日22:00 车站周边有大型灯会活动，预计21:00起散场客流逐步进场] 请输出未来16个时间点的客流值。这里有个细节：Prompt里显式写出“你是高铁客流预测专家”并不是玄学，它确实让模型的输出更贴近业务约束，因为底座的预训练目标里包含大量“角色设定影响输出风格”的语料依赖。我们把日期信息放在中间而不是末尾，也是测试出来的结果——放在开头时模型会过度关注日历属性，放在末尾时又容易被长文本稀释，中间位置最合适。
上下文窗口我们控制在512个Token以内。尝试过扩大到1024，但效果没有显著提升，反而推理延迟增加、显存压力变大。这说明有效上下文不等于最大上下文，当前任务所需的信息总量本身有限，过多历史细节带来的收益边际递减。
3.4 损失函数与权重设计
多任务总Loss不能简单平均，因为不同任务的量纲和难度差异太大。主任务是MSE（预测值和真实客流值），辅助任务里分类任务用的是交叉熵，短临回归也用MSE，但绝对值比主任务小一个数量级。如果直接相加，主任务梯度会被辅助任务淹没。
我们最后采用的是不确定性加权（Homoscedastic Uncertainty Weighting）的思路。公式上是让模型自己学习不同任务的可信度：
L_total = (1 / (2σ1^2)) * L_main + (1 / (2σ2^2)) * L_aux1 + (1 / (2σ3^2)) * L_aux2 + ... + log(σ1 * σ2 * ...)其中σ是对每个任务的可学习参数。初看有点反直觉，但实际效果很好：训练初期σ自动把分类任务的权重压得很低，让主任务先收敛，后期再逐步放大辅助任务影响。相比之下，手工调固定权重至少需要十几组实验才能匹敌这个效果，而且不同数据规模下最优权重还会漂移。
4. 训练与调参实录
4.1 训练策略：先分后合，避免梯度打架
多任务模型最怕一开始就联合训练所有任务头。我们第一次实验就是直接从零联合训练，结果主任务指标比单任务LSTM还要差，辅助任务倒是学得飞快。后来复盘发现，模型在早期把几乎所有容量都用来拟合更容易的辅助任务（比如事件分类准确率蹭蹭往上走），主任务的回归精度被牺牲了。
最终采用的策略是“先分后合”三个阶段。第一阶段只训练Patch Embedding层和主回归头，用单任务Loss做15个Epoch，让模型先掌握基本的数值映射。第二阶段冻结主干，只训练辅助任务头和Adapter，让辅助任务信号不干扰主任务回传。第三阶段解冻LoRA和所有任务头，用总Loss联合微调，这一步是精调，学习率比前两个阶段低一个数量级。
这套策略让训练时间增加了约40%，但最终主任务的MAPE比直接联合训练低了1.8个百分点，稳定性也更好。如果资源有限只能选一种方案，我会建议跳过第二阶段，但千万不要跳过第一阶段，那种“一步到位”的想法在多任务场景里基本行不通。
4.2 关键超参数速查表
调参过程是按步实验推进的，我这里把一组实测下来效果不错的配置整理成表，方便参考，可以直接作为起点：
| 超参数 | 配置值 | 备注 |
|---|---|---|
| 底座模型 | 10B级开源Decoder | 冻结主干，LoRA微调 |
| LoRA秩 | 64 | 秩再大提升有限，显存翻倍 |
| Patch长度 | 4个时间点（1小时） | Patch过短序列太长，过长丢细节 |
| 上下文长度 | 512 Token上限 | 超出部分裁掉事件文本 |
| 批次大小 | 128（梯度累积16步等效2048） | 显存不够时的等价方案 |
| 优化器 | AdamW | β1=0.9，β2=0.999 |
| 峰值学习率 | 1e-4（第三阶段为1e-5） | 配合线性Warmup，比例5% |
| 权重衰减 | 0.01 | 只作用于LoRA参数和解码层 |
| 训练Epoch | 第一阶段15，第二阶段10，第三阶段5 | 早停阈值见下 |
| 标签平滑 | 分类任务用0.05 | 防止四分类过拟合 |
批次大小这块多说一句：我们最初用256的批次训，收敛很快但验证集MSE在后期震荡明显，换成梯度累积模拟的大批次后，曲线平滑了很多。大模型微调时，批次大小本质上影响的是梯度噪声，多任务场景下梯度来源多，更小的噪声对稳定多任务平衡是有帮助的。
4.3 时间序列验证集怎么划分
时序预测和普通机器学习最大的区别是：不能用随机划分。我们把某一天的数据随机抽到验证集，模型在训练时其实已经见过同一天的早高峰，验证时预测晚高峰自然显得很准——这是典型的标签泄露，好在内部实验阶段及时发现。
正确做法是按时间连续切分：训练集用的是某区域内过去10个月的数据，验证集取紧随其后的第11个月，留出第12个月做最终测试。这样保证验证集所有时间点都晚于训练集，模拟真实上线后的预测场景。但这样也会牺牲一部分训练数据，应对方法是给训练集末尾三个月更高的采样权重，让模型更关注近期分布。我们管这个叫“时间衰减采样”，效果类似加权，但比手动调权重直观。
早停策略上，我们用的指标是验证集上的综合指标——主任务MSE（70%）加分类准确率（30%），设定连续5个Epoch不改善就回滚到最佳检查点。为什么不只看主任务MSE？因为单看MSE容易早停在辅助任务还没学好的阶段，后面联合微调时主任务还能再涨，但如果辅助任务没学好，联合阶段反而会拖累主任务。
5. 评估结果与业务落地的差距
5.1 评估指标怎么定
评估阶段我们用了三组视角的指标。业务视角重点是MAPE（平均绝对百分比误差），这高层的业务领导能懂；算法视角用RMSE（均方根误差），更容易放大异常尖峰的惩罚；运营视角加了P90分位误差，专门看高峰时段的极端表现，因为运力配置最怕的是低估峰值。
对比基线我们选了5个：历史同期均值（业务现状）、ARIMA（经典统计方法）、LightGBM（传统机器学习代表）、LSTM（深度学习基线）、单任务LLM（去掉多任务头的同结构模型）。所有模型用同一份训练数据，在测试月数据上验证，确保公平。
5.2 我们实际测到的结果
在某个客流规模中等的枢纽站测试集上，我们拿到了这样一组结果（已脱敏，相对值）：
| 模型 | MAPE（整体） | RMSE | P90误差（高峰时段） |
|---|---|---|---|
| 历史均值 | 18.6% | 3420 | 17.4% |
| ARIMA | 15.2% | 2890 | 14.8% |
| LightGBM | 12.9% | 2330 | 14.1% |
| LSTM | 11.8% | 2150 | 13.2% |
| 单任务LLM | 10.6% | 1910 | 11.5% |
| Metrica A 2025（多任务LLM） | 9.8% | 1740 | 10.1% |
整体来看，多任务LLM比传统LSTM的MAPE降低了约17%，比历史均值提升接近一半。但这个平均值掩盖了更重要的现象：把结果按日期类型拆开后，差距主要体现在“小长假峰值日”和“恶劣天气扰动日”这两天类型上——这两个场景下多任务LLM比LSTM的MAPE低了近30%，而在普通工作日差距只有5%左右。这说明LLM的价值不在高频稳定的常规场景，而在低频不确定的边缘场景，恰好是运力调度最需要提前预判的部分。
5.3 几个必须泼冷水的发现
一是推理成本确实高。10B模型单次预测在单张专业级显卡上大约需要400-600毫秒，LSTM在同一任务上只要几毫秒。我们最终上线方案是“大模型管重点，小模型管常规”——只有预测到未来时段可能触发大客流事件时才调用大模型，日常预测继续用轻量模型，整体成本下降了80%以上。
二是新鲜数据依赖重。这个模型的输入里有大量新闻事件、公告文本，一旦某地出现极低概率事件（比如大型活动临时取消），模型只能靠类比推测，效果不如人工加规则干预。因此系统保留了人工修正入口，调度人员的判断始终优先。
三是模型对数据质量比传统模型更敏感。文本数据里一个错别字、一个日期格式错乱，都可能让模型输出完全跑偏，而LSTM遇到脏数据最多是数值抖动，不会出现“像话的胡言乱语”。这要求我们在数据处理环节做得比以往更细。
6. 踩坑记录与排错速查
6.1 数值离散化导致的预测输出抖动
第一次实验我们天真地用了分桶离散化，模型输出的客流曲线在时间维度上频繁跳变：8:15预测920人，8:30预测3100人，再下一个点又掉回1500人。排查后确认不是数据问题，是离散化把连续数值的邻近关系抹掉了。这个问题后来换成Patch Embedding加连续回归头才彻底解决。
类比一下就知道为什么：离散化相当于把人按身高分成十档，模型知道“1米7”和“1米8”只是两个不同标签，但没法理解这两个标签数值上的远近关系。而客流预测本质是一个连续量估计问题，强加离散化等于给问题人为制造了障碍。
6.2 多任务Loss权重失衡拖垮主任务
经验不足时最容易踩的坑。我们曾经把四个任务的固定权重设为1:1:1:1，训练到第8个Epoch时主任务MSE不降反升，但辅助任务的各种指标持续变好——模型已经把容量几乎全部分配给更简单的问题。解决方案就是前面提到的不确定性加权，让模型自己调节任务权重，实测收敛速度和最终精度都有明显提升。
6.3 推理延迟让实时预测变成笑话
上线时我们遇到一个很现实的尴尬：预测接口要求P95延迟小于2秒，但模型单次推理就要600毫秒，加上前后处理，峰值并发下根本顶不住。第一反应是换小模型，但效果掉得厉害；后来做了四件事才算解决：一是把文本Token数量从128压缩到64，去掉空话，推理时间省了15%；二是用批量推理将多个车站的预测请求打包，同一个输入Batch并行处理，吞吐量提升3倍；三是给模型加了一层“快通道”——如果轻量模型预测结果与历史同期偏差小于5%，直接返回快通道结果，只有偏差大的场景才走大模型；四是做INT8量化，推理时间压到300毫秒左右。最终上线版本在标准单卡服务器上P95延迟是1.5秒，勉强达标。这一趟走下来，最大的体会是：模型效果好只是第一步，工程上能不能实时跑起来是另一条战线。
6.4 常见问题速查表
| 现象 | 可能原因 | 排查步骤 | 解决方案 |
|---|---|---|---|
| 预测值在相邻时段剧烈跳动 | 数值离散化或输出头不合适 | 检查输出头是否是回归头 | 改为Patch Embedding + 连续值回归 |
| 主任务指标不升反降 | 多任务Loss权重失衡 | 看辅助任务是否收敛过快 | 换不确定性加权 / 分阶段训练 |
| 长上下文效果差 | 无效信息过多 / 有效上下文不足 | 检查Prompt文本长度与裁剪规则 | 精简事件文本，只留三要素 |
| 推理延迟打不过SLA | 模型过大、并发过高 | 压测定位瓶颈在编码还是解码 | 量化 / 蒸馏 / 多请求Batch |
| 验证集效果好但线上效果差 | 时间泄露 / 数据漂移 | 核查验证集是否含未来信息 | 按时间连续切分，更新近端采样 |
| 添加了辅助任务后主任务变差 | 辅助任务标签质量差 | 拿掉该任务跑A/B实验 | 修复标签或放弃该辅助任务 |
6.5 经验总结：多任务LLM在业务侧的适用范围
在高铁客流预测这个场景里，多任务LLM并不适合替换所有旧系统，它更像一个“情景推演副驾驶”。它的强项是理解语义环境、应对低频事件、从多个任务维度共同约束预测结果；它的弱项是成本高、推理慢、对数据质量要求苛刻。
我个人在实际操作中最深的体会是：不要一上来就想着用LLM重写所有预测逻辑。最稳妥的路径是先用一个轻量模型守住常规场景，让LLM只在可能出现异常的时间窗口介入，用多任务和信息增强去解决传统模型解决不了的那块顽疾。这既控制了成本，也让业务方更容易接受——他们需要的是一个能解释“为什么今天预测这么高”的系统，而不是一个整天说不清理由的黑盒子。
这个项目后续还可以继续扩展的方向很明确。一是把多站点协同预测做到一个模型里，让相邻站点的客流通过共享注意力机制互相影响，这比单站独立预测更符合路网运营逻辑。二是把OD流（起终点配对）预测纳入多任务体系，让模型不仅预测“有多少人到站”，还预测“他们从哪里来、到哪里去”，这对运力分配意义更大。三是引入实时事件流，比如刚发生的晚点信息、正在演变的天气预警，让模型具备在线学习能力。可能等我们完成了这些再回头看，Metrica A 2025才真正算得上是一个成熟的高铁客流预测系统。
