凌晨两点半还盯着交通指挥大屏的人大概率不关心模型里的注意力权重长什么样他只想知道一件事明天早高峰哪几个路口会红、要不要提前把信号配时改掉。这个落差就是交通预测领域最真实的痛点——模型在测试集上的 MAE 做得再漂亮摆到决策桌面上依然会被一句你这数是怎么来的问住。TF-LLM 这类把大语言模型拉进交通预测的方案盯的正是这道鸿沟它不只吐出未来 60 分钟的流量曲线还要用自然语言把为什么这么预测讲清楚。可解释性和大语言模型放到交通预测里不是赶时髦而是这个行业憋了十几年的需求——从 ARIMA 到时空图神经网络精度涨了信任度没涨。这篇内容适合三类人看正在做时序预测想引入 LLM 的算法同学、需要给决策方交付能解释的预测的工程同学以及只想搞明白 TF-LLM 到底新在哪里的技术管理者。我会把架构拆开、把数据坑列全、把复现路径和显存账本算给你看也会讲清楚可解释性这件事怎么验收——毕竟让模型编一个听起来很顺的理由比让它预测准容易得多。1. 交通预测的老毛病算得准但没人敢照着它做决策先说清楚问题本身不然讨论 TF-LLM 就是空中楼阁。交通流量预测的经典设定是这样的给定路网上 N 个检测器过去 T 个时间片通常是 12 个点、5 分钟粒度也就是过去 1 小时的速度或流量序列预测未来 H 个时间片的值。METR-LA、PEMS-BAY 这两个加州高速数据集基本是这个方向的标准靶场一个 207 个传感器、一个 325 个传感器很多人从研究生做到工作都在跟它们打交道。问题在于这个任务在学术界被压缩成了一个纯数值回归问题而在真实场景里它从来不是。真实场景里还有为什么。1.1 精度上去了信任度为什么没跟上从 ARIMA、VAR 这类统计模型到 LSTM、Seq2Seq再到 DCRNN、STGCN、Graph WaveNet、ASTGCN 这些时空图神经网络再到近两年基于 Transformer 的 Informer、PatchTST模型结构一路豪华METR-LA 上的 MAE 从最早的 5 以上压到了 2.8 上下。数字很好看但工程落地的时候你会发现一个尴尬的现实调度员看到模型说15 号路口 17:30 会堵第一反应是凭什么而这个凭什么很难从一张热力图或者一组 attention 权重里读出来一旦模型给出反直觉的预测比如某个平时必堵的匝道显示畅通没人知道该信还是不该信只能靠人去赌出问题时无法定责也无法快速判断是数据脏了、还是模型漂移了、还是真发生了异常事件。这三条加起来就是最后一公里问题预测系统的价值不在模型内部在于它能不能被下游的人采纳。一个 MAE 3.0 但能说清理由的模型在实际调度里的价值往往高于 MAE 2.7 的黑箱——这不是情怀是决策链条的现实。1.2 可解释性在交通场景里不是锦上添花我见过不少团队把可解释性当成论文里的加分项做完可视化就收工。但在交通这个领域它其实承担了四个很硬的功能作用具体表现缺了会怎样建立信任给出因为上游发生了事故 下游匝道限流这类理由预测结果被直接忽略快速归因模型异常时定位是数据问题还是事件问题排障周期从小时级拉到天级支撑决策理由本身可转成信号配时、诱导屏文案预测只停留在报表里满足审计关键调度动作需要留下可追溯依据无法通过内部评审注意第二行和第三行。理由不只是给人看的它本身就是可执行的中间产物。上游事故导致下游 40 分钟后拥堵这句话可以直接转成一条分流诱导策略。而黑箱模型吐出的一个 62.3什么也转不了。1.3 TF-LLM 想同时解决的三个问题理解了上面的背景TF-LLM 的设计动机就清楚了。它想一口气解决三件事这也是我判断这类方案是否成立的标准精度不能掉引入 LLM 不是为了讲故事MAE 至少要打到和强基线同一档否则解释得再好也没意义解释要能对得上预测解释不能是生成完预测之后随便补的一段话必须和数值输出有因果或结构上的绑定要能吃进多源异构信息天气、节假日、事件通告、路网语义这些以文本或类别形式存在的信息传统时序模型处理起来很别扭而这恰好是大语言模型的主场。第三条特别值得强调。传统模型想融合明天是节假日 气象台发布了大雨预警这类信息通常要靠人工构造特征、再做 embedding流程长且脆。而 LLM 天然就是吃文本的把这些信息写成一段提示丢进去是它最舒服的姿势。这就是 TF-LLM 这类方案真正的差异化空间——不是用 LLM 替代 GNN而是让 LLM 去承担语义融合 理由生成这两块传统管线最难做的活。2. TF-LLM 的骨架把时间序列翻译成模型能读的句子架构这一层我不打算复述论文里的公式而是按你自己要复现的话每一块该怎么搭来讲。TF-LLM 的整体链路可以拆成四段时序编码、时空结构注入、提示构造、双头输出。2.1 时序分块与投影让浮点数变成 tokenLLM 的输入是 token 序列交通数据是浮点数组中间必须有一座桥。目前主流做法是分块投影patching projection思路和 PatchTST 一致把单个检测器的时间序列按窗口切成长度为 P、步长为 S 的 patch比如 P12、S6过去 12 个点1 小时切成 2 个 patch每个 patch 经过一层线性映射投到 LLM 的隐层维度7B 模型通常是 4096投影后的向量当作软 token拼进输入序列前面再挂一段自然语言提示。这里有个容易踩的细节投影层的学习率必须比 LLM 主干高一个数量级。原因是随机初始化的投影层和预训练好的 LLM 主干处在完全不同的参数空间尺度上如果按同一个学习率训练要么投影层学不动要么主干被拽崩。我实测下来主干用 1e-5 到 2e-5投影层用 1e-3 到 3e-3是比较稳的配置。另一个选择是数值离散化把速度值分箱比如每 5 mph 一档映射到词表里的数字 token。这个方案的好处是纯文本、可以零样本推理坏处是精度损失明显MAE 通常会掉 10% 到 20%。我的建议是如果你的目标是发论文或者做原型验证离散化更快出结果如果目标是上线老老实实用软 token 投影。2.2 时空结构注入邻接矩阵怎么进 Transformer交通数据和普通时序最大的区别是空间依赖。DCRNN、Graph WaveNet 那套是靠图卷积显式建模的到了 LLM 这里注入方式主要有三种图编码器前置先用一个 GNN 或图注意力层把邻居节点的信息聚合把聚合后的表示投给 LLM。这是最稳的做法本质上是GNN 提特征、LLM 做推理职责分明节点 token 拼接把目标节点和它的 K 个邻居的时间 patch 按顺序拼成一个长序列让 self-attention 自己去学空间关系。实现最简单但序列长度会乘以 K7B 模型下显存压力很大文本化邻接把节点 A 与节点 B 距离 1.2 公里、拓扑相邻这类信息写成文本塞进提示。看起来很美好但实测效果一般——LLM 对数值型的空间关系推理能力远不如它对语言的推理能力。我倾向第一种。原因很实际GNN 部分是成熟的调参经验一大堆LLM 部分负责语义和解释。把一个已经解决的问题重新交给 LLM 去学属于自找麻烦。顺带说一句邻接矩阵的构建。物理距离邻接高斯核是最基础的但真实路网里拓扑邻接和功能邻接往往不是一回事——一条主干道和它旁边的辅路物理距离 20 米但流量模式完全不同两个相距 5 公里的商圈入口早晚高峰的形态却高度同步。把语义邻接基于历史序列相似度做动态图和物理邻接加权融合这个改动本身通常就能带来 3% 到 5% 的 MAE 下降性价比很高。2.3 解释分支预测和理由必须绑在一起这是 TF-LLM 最核心的设计也是我认为最容易做歪的地方。常见的三种结构结构做法优点风险先解释后预测LLM 先产出分析文本再把文本编码用于预测头解释与预测强绑定解释错了会带偏预测并行双头共享主干一个头出数值、一个头出文本训练稳定、易实现解释可能和预测脱钩先预测后解释先出数值再把数值和隐状态喂给 LLM 生成理由解释可读性最好容易变成事后找理由如果目标是上线我建议走并行双头 一致性约束的路子。具体做法是在共享主干之后接两个头同时加一个额外的损失项约束文本解释的隐状态和数值预测的隐状态之间保持相关性比如用余弦相似度或对比学习损失。这样既保住了训练稳定性又不会让解释彻底放飞。再补一个实操经验解释的粒度要控制。让模型生成一段 200 字的分析实际信息量往往不如三句话主要影响因子是上游 3 号传感器的事故该影响预计持续 40 分钟置信度中等因为该路段历史样本较少。短解释的可验证性强得多人工审核成本也低得多。我见过太多项目解释文本写得很长很漂亮但没人真的去读。3. 数据管线才是分水岭交通流数据的清洗与对齐模型结构的差距往往只有几个点数据管线做得好坏能差出十几个点。这一节是我个人觉得最值钱的部分因为它没什么论文会细写。3.1 公开数据集和真实卡口数据的差距先看对比很多人从公开数据集切换到真实数据时会严重低估工作量维度METR-LA / PEMS-BAY真实城市卡口/地磁数据缺失率约 8% 到 10%已做线性插值15% 到 40%且缺失成段采样稳定性严格 5 分钟存在时钟漂移、断传、重复上报异常值已清洗传感器故障导致的恒定值和脉冲值大量存在空间拓扑高速公路结构简单城市路网含大量短路段和交叉口假期效应相对弱极强节假日模式和周末都不同这个表的意思很直白你在 METR-LA 上调出来的超参搬到真实数据上大概率全线失效尤其是缺失处理相关的部分。3.2 缺失值、异常值和假高峰三个具体坑我一个个说。第一个是缺失填充方式对 LLM 输入的影响。传统做法是线性插值或前向填充简单有效。但要注意如果缺失段超过 6 个时间片30 分钟线性插值会造出一条明显不真实的平缓曲线模型学到的是插值模式而不是真实模式。我的做法是加一个缺失掩码通道同时在输入提示里明确写该路段 14:00-15:00 数据缺失已插值让模型知道这段信息的可信度低。这一点在生成解释的时候特别有用——模型会主动降低对应时段的置信度。第二个是异常值。交通数据里最典型的异常是传感器卡死表现为连续几十个点数值完全一样。这个用滑窗方差检测最直接窗口内标准差小于阈值的直接标记为可疑。另一类是脉冲值比如单车道上突然出现 200 km/h 的速度用分位数截断比如 0.1% 和 99.9%就能压掉。这里提醒一句不要直接用 3σ 法则交通流本身是重尾分布高峰期和低谷期方差差异巨大全局 3σ 会把真实的高峰切掉。第三个是假高峰。这个最隐蔽。比如某个检测器因为通信中断恢复后把缓存的数据一次性补传导致某个时间片出现异常高的计数。或者是节假日免费通行期间高速入口的流量形态完全不同于工作日如果训练集里节假日样本很少模型会把这种形态当成异常处理。解决办法是在特征里显式加入节假日标志和日期类型并且检查训练集的日期覆盖度——如果训练数据只覆盖了三个月且不含长假别指望模型能处理好春节。3.3 空间邻接与多源信息的融合邻接矩阵的构建我在上一节提过这里补充一个工程细节邻接矩阵要归一化。DCRNN 用的是随机游走归一化Graph WaveNet 用的是自适应邻接。如果你自己搭最简单的对称归一化就够用import numpy as np def build_adj(dist_matrix, sigma0.1, threshold0.5): # 高斯核构造物理邻接 adj np.exp(-np.square(dist_matrix / sigma)) adj[adj threshold] 0 # 对称归一化避免度数大的节点主导聚合 d np.sum(adj, axis1) d_inv_sqrt np.power(d, -0.5, whered 0) d_inv_sqrt[d 0] 0 d_mat np.diag(d_inv_sqrt) return d_mat adj d_mat至于多源信息TF-LLM 的优势就在这里。天气、事件、节假日这些信息用一行代码就能拼进提示场景上下文: 日期类型: 工作日 天气: 中雨 气温: 12摄氏度 能见度: 中等 已知事件: 15号路段 08:20 发生两车事故占用一条车道 特殊说明: 该路段 07:00-09:00 为早高峰管控时段这种结构化的上下文描述比把天气 one-hot 成 4 维向量然后指望模型自己悟效果好得多。原因也简单one-hot 丢失了语义而中雨 能见度中等这两个词之间的关系LLM 在预训练阶段已经学过了。4. 复现路线基座选型、微调策略与显存账本到了动手环节。这一节我给一条我验证过的复现路线以及每一步的取舍理由。4.1 基座模型该怎么选这一步的决策逻辑我一般按三个约束排序显存预算 序列长度需求 语言能力。基座规模单卡最低显存LoRA 微调适合场景备注1B 到 3B16 GB只要数值预测解释需求弱解释质量明显不够7B 到 8B40 GBA100或 24 GB4bit QLoRA主流选择精度与成本平衡推荐起点13B80 GB 或 48 GB4bit多任务、解释质量要求高收益边际递减70B多卡一般不建议自训推理成本不可接受我给大多数团队的建议是从 7B 级别的开源模型起步用 QLoRA 在单卡 24 GB 上跑通全流程然后再根据效果决定要不要往上加。原因很实在——TF-LLM 这类方案里模型规模带来的收益远小于数据管线质量带来的收益。我见过有人一上来就上 13B结果数据没洗干净效果还不如 7B 加个干净的缺失掩码。还有一个容易被忽略的点基座模型的中文/英文能力要和你的提示语言匹配。如果你的提示模板是中文写的用中文语料占比高的模型会明显更顺如果提示是英文随便挑一个主流英文模型都行。混着用经常会出现解释文本突然夹杂英文、或者格式错乱的情况。4.2 LoRA 还是全参微调结论先给时序预测任务上没有理由做全参微调。原因有两层。第一层是成本7B 全参微调要 8 卡 A100 起步LoRA 单卡 24 GB 就能跑而效果差距在时序任务上通常小于 1%。第二层更重要全参微调对时序数据这种窄领域数据极易过拟合而且会破坏模型的自然语言能力——你辛辛苦苦练完发现它不会好好说话了解释质量断崖式下跌。LoRA 的配置我一般用这套from peft import LoraConfig, TaskType lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r16, # 秩8-32 之间交通任务 16 够用 lora_alpha32, # 通常取 2r lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj], biasnone, )target_modules只打注意力层的四个投影是最省显存的方案。如果效果不够再考虑加上 MLP 层但要注意加上 MLP 层后显存占用会明显上升而且过拟合风险变大。r的选择上我在交通任务里试过 8/16/32/6416 和 32 差不多64 开始过拟合。别迷信大 r。4.3 两阶段训练和提示模板设计训练分两阶段是比较稳的做法阶段一冻结 LLM 主干只训时序编码器 投影层 预测头。这一阶段的目标是让时序表示和 LLM 的隐空间对齐。学习率给到 1e-3跑 20 到 30 个 epoch 通常能收敛。这一步很重要跳过它直接联合训练前期梯度会非常混乱。阶段二解冻 LoRA 适配器联合训练预测头 解释头。学习率降到 2e-5batch size 尽量往大了开梯度累积也行。解释头的损失函数建议用标准的语言建模损失权重给 0.1 到 0.3 之间——给太高会牺牲预测精度给太低解释质量上不来。提示模板的设计我踩过几次坑总结下来几条把统计摘要写进去比如该路段过去 1 小时平均速度 45 km/h较昨日同期下降 12%这类相对变化量比绝对数值有信息量得多明确输出格式直接告诉模型先输出 12 个数值用逗号分隔再输出三行解释能显著降低格式错误率别塞太多背景我试过把整条路段的历史统计全塞进去结果模型注意力被稀释效果反而变差。控制在 200 字以内比较合适。4.4 显存和吞吐的实测账本给一组我实测的数字方便你估算硬件7B 模型、序列长度 1024、batch size 8配置训练显存推理显存单样本推理延迟全精度 LoRA约 60 GB约 18 GB约 220 msbf16 LoRA约 38 GB约 15 GB约 150 ms4bit QLoRA约 22 GB约 6 GB约 180 ms4bit 量化推理引擎不支持训练约 5 GB约 90 ms最后一行的关键是推理引擎的量化加速训练的时候还是得用 QLoRA。注意 QLoRA 推理比 bf16 慢一点因为反量化有开销——如果终于要上线建议训练用 QLoRA、推理把适配器合并后用 bf16 或专门的量化格式。5. 可解释性验收怎么判断模型给的理由不是编的这一节是全文我最想强调的部分。可解释性最容易自欺欺人的地方在于一段听起来很有道理的解释和一段真正忠实的解释在肉眼层面几乎无法区分。你必须设计能证伪的测试。5.1 三档评估法一致性、忠实性、可用性我把评估分成三层从上往下越来越严格第一层一致性Consistency。解释里提到的因素是否真的在数据和模型里起作用比如模型说因为上游事故那检查一下输入里是否真的带了事故信息以及如果把这条信息删掉预测会不会变。这一层用自动化脚本就能测成本最低。第二层忠实性Faithfulness。这是最核心的一层。做法是对输入做扰动观察解释和预测是否同步变化。举例模型说主要影响因子是 3 号传感器那么把 3 号传感器的值改掉预测应该发生明显变化如果改了没反应说明这句解释是编的。第三层可用性Actionability。把解释交给真实的调度人员看他们能不能据此做出决策、决策是否正确。这一层只能人工做成本最高但它是唯一能证明可解释性有业务价值的证据。我的建议是至少做一轮小规模人工评测10 到 20 个样本找 3 个有经验的调度员盲评通常就能暴露出大部分问题。5.2 扰动测试和反事实测试的具体做法忠实性测试我通常写成一个可复用的函数def faithfulness_score(model, x, node_idx, explain_text, top_k3): 对解释中提到的关键节点做扰动看预测变化是否显著 base_pred model.predict(x) scores {} for n in range(top_k): x_perturbed x.clone() # 把该节点整段序列替换为历史均值抹掉信息 x_perturbed[:, node_idx[n], :] x[:, node_idx[n], :].mean() pert_pred model.predict(x_perturbed) # 预测变化幅度 scores[node_idx[n]] (base_pred - pert_pred).abs().mean().item() return scores判据很简单解释里点名的节点扰动带来的预测变化幅度应该显著高于未被点名的节点。如果两者差不多说明解释没有定位能力。反事实测试是另一个维度构造一个和当前场景相似、但结果不同的历史样本看模型能不能说出差异点。比如取两个同样天气、同样时段、但一个拥堵一个畅通的日子把两者的输入都喂给模型好的解释会指出差别在于上游是否有事件或者该日下游匝道进行了限流。这个测试对说明模型是否真的学到了因果结构特别有效。5.3 典型失效模式和对应处理失效模式表现处理方式解释幻觉提到输入里根本没有的因素提示里限定只依据给定上下文加一致性损失解释泛化所有样本的解释几乎一样检查解释头是否退化成常量输出加多样性约束解释与预测脱钩预测说畅通解释却说会拥堵并行双头结构下必须有联合约束否则必然出现过度自信任何情况都给出确定语气在提示里要求输出置信度并校准置信度数据泄漏式解释解释里出现未来信息严格检查提示模板确保只含历史窗口数据第三行特别值得说。并行双头结构如果不加约束跑一段时间后几乎必然出现预测和解释各说各话的情况因为两个头的梯度方向天然不一致。我最早做的时候就没加这个约束结果演示的时候被抓了个正着——预测值是畅通解释文本写着预计出现中度拥堵。那次之后我加了余弦相似度约束项权重 0.05 到 0.1问题基本消失。6. 上线之后延迟、成本和漂移监控原型跑通和上线之间还有一大段路。这一节讲工程侧我踩过的坑。6.1 推理延迟的拆解和压榨手段一个 7B 模型在单卡上生成 12 个数值加三行解释端到端延迟通常在 200 到 400 ms。听起来还行但如果你的路网有几千个检测器、每 5 分钟要全量预测一次这个量级就完全撑不住了。先看延迟都花在哪输入编码时序部分占 10% 到 20%LLM 前向计算占 50% 到 60%文本生成逐 token占 20% 到 30%。文本生成是逐 token 的这是最贵的一段。压榨手段按性价比排序批处理多个检测器的输入拼成一个 batch吞吐能提升 5 到 10 倍这是最有效的一招一定要先做KV Cache 复用如果所有样本共享同一段系统提示比如场景上下文描述可以把这段的 KV cache 缓存下来省掉重复计算限制解释长度把解释限制在 3 句话以内生成阶段的开销能砍掉一半以上量化推理4bit 量化能把显存降下来延迟也能降 30% 到 40%但精度会有小幅损失需要实测分级调度不需要全量都生成解释。可以让模型对预测值偏离历史均值超过阈值的样本才生成解释其余只输出数值。实测下来解释生成量能压到 20% 以下成本骤降。第 5 条是我个人最推荐的。因为解释的价值本来就在于异常场景——一切正常的时候没人会去读解释。6.2 把 LLM 蒸馏回小模型的思路如果你的场景对延迟极其敏感比如要求 50 ms 以内那 LLM 无论怎么优化都不够。这时候可以考虑蒸馏回小模型的思路用 LLM 在大量历史数据上生成伪解释作为监督信号训练一个小的时序模型比如几层的 TCN 或轻量 Transformer同时预测数值和解释标签解释标签可以是用 LLM 生成解释的关键因子编码成多标签分类任务。这样做出来的小模型跑起来是毫秒级解释能力虽然比不上原生 LLM但能覆盖大部分常见场景。我的经验是关键路网用大模型、一般路网用小模型这种混合架构在成本和效果之间平衡得最好。6.3 监控指标和回滚条件上线之后的监控除了常规的 MAE 漂移还要专门监控解释相关的指标指标计算方式告警阈值建议预测 MAE 漂移滚动 7 天 MAE 与基线对比上升超过 15%解释一致率解释指向因素与扰动测试结果吻合比例低于 70%解释模板率完全相同的解释占比超过 30%置信度校准误差预测区间覆盖率与标称值的差超过 10 个百分点格式错误率输出无法解析的样本占比超过 1%第三行解释模板率是我自己加的一个指标很说明问题。如果模型开始对大量样本输出一模一样的解释比如都是受通勤高峰影响那基本可以判断解释分支退化了。这个指标一旦超过 30%就该考虑重新训练解释头或者检查提示模板是不是被改动了。回滚条件一定要提前定死。我的建议是预测 MAE 连续两个评估周期恶化超过 15%或者解释一致率跌破 60%自动回滚到上一个稳定版本然后人工介入。上线前把这条写进配置里别等到出问题再临时讨论。最后再分享一个小技巧。TF-LLM 这类方案在演示的时候最容易翻车的不是数值预测而是解释文本的格式稳定性——模型偶尔会输出一段自由发挥的散文导致解析失败。我的做法是在推理阶段加一层轻量后处理用正则先抽数值部分抽不到就重试一次重试还失败就降级只输出数值、不输出解释。这个小兜底能挡掉 95% 的线上格式问题很便宜也很管用。