把大模型放进交通系统，很容易出现一幅过于轻松的想象：模型读懂全城数据，自动调度车辆、改变信号，顺手回复乘客问题。现实中的交通运营却由时刻表、车辆位置、施工通知、维护工单、应急预案和人工决策共同组成。数据不断变化，错误还可能影响一群人的安全与出行。
因此，“AI21 在交通中的落地”首先要缩小问题。本文不是 AI21 已在某个城市投入生产的案例，也不证明其产品天然适合交通行业，而是根据 AI21 公开的 Jamba 模型与 Maestro 编排能力，构造一套可供本地验证的工程方法。真正上线前，仍需用本地语言、数据、流程和故障样本重新评测。
## 先看能力，不把品牌当答案
AI21 当前公开的 Jamba 系列采用 Transformer 与 Mamba 混合架构，文档列出了长上下文、文本生成以及开放权重或自行部署等选项。长上下文有利于阅读成套运营手册和连续工单，但“能放进上下文”不等于“能准确理解并执行”。模型文档也明确提示，输出可能不准确，并不具备对物理世界的真实感知。
Maestro 则被 AI21 定义为面向企业任务的编排层，可组合检索、工具、计划和验证步骤。它适合把模型限制在一个有输入、有检查、有预算的流程中。这里仍要保持清醒：供应商文档描述的是产品能力，不是交通现场效果。是否可用，要看自己的离线测试和影子运行。
## 最适合从“知识层”开始
交通系统里的大模型应先做低风险、可核查的文字工作，而不是做实时控制器。第一类场景是运营知识助手：值班人员输入“某车型雨天车门反复报警如何处置”，系统从维修手册、历史工单和内部通告中找出相关段落，给出带来源的排查清单。
第二类是记录整理。模型可以把交接班日志、热线摘要和现场记录归并成待确认的事件条目，减少重复录入。第三类是乘客服务告警草稿：当线路临时绕行时，系统根据已确认的事件数据生成不同语言和不同渠道的文案，再由调度或客服人员审核发布。
第四类是事后复盘。长上下文模型可以整理同一事件的时间线、引用相关预案，并标出记录之间的冲突。不过它只能帮助人找到材料，不能替代事故认定与责任判断。
## 把实时数据交给确定性工具
公共交通数据常使用 GTFS 描述站点、线路和计划时刻，使用 GTFS Realtime 发布车辆位置、预计到站、行程更新和服务告警。实时规范强调更新频率、数据新鲜度以及跨版本稳定的标识符，这些都是大模型容易忽略的细节。
稳妥架构不会让模型凭文本“算”下一班车。系统先用经过测试的解析器读取 GTFS，用路线算法或数据库计算站序、时间和受影响范围，再把结构化结果交给模型解释。每个实时字段都应带来源时间、采集时间和有效期；过期、缺失或相互冲突时，系统应停止生成确定结论。
模型也不应直接控制信号灯、轨道联锁、车辆制动、方向或速度。凡是会改变物理系统状态的安全关键命令，都应留在经认证或专门验证的控制系统内。大模型最多生成供授权人员查看的建议，不进入自动执行链路。
## 一条可审计的系统链路
一个运营辅助请求可以经过七步：身份与权限检查；读取已批准的数据源；检查时间戳与版本；检索相关手册和事件；调用确定性工具计算路线或影响范围；生成含引用的草稿；执行规则校验并送交人工确认。
每一步都应保存运行轨迹，包括检索到了哪些片段、工具用了哪些参数、模型版本和提示版本是什么、谁最终批准。这样，错误答案出现后可以沿链路复盘，而不是只看到一段无法解释的文字。
若使用 Maestro 一类编排工具，应限制可调用工具、最大步骤、时间和成本。只读查询与发布动作必须分开：检索系统可以广泛读取获授权数据，真正发送服务公告则需要显式的人机确认，并记录批准者。
## 知识库的难点是版本和冲突
交通手册常有总则、线路补充说明和临时通告。较新的局部通告可能覆盖旧规则，也可能只在某个车队或时间段有效。知识库不能把所有 PDF 切成片段后混在一起，而应保存文件版本、适用组织、线路、车型、发布日期、生效期和替代关系。
检索结果中若同时出现相互冲突的规定，模型不应自行“折中”。它需要展示冲突来源，按预先定义的权威层级排序，仍无法判断时请值班人员确认。被撤回的文件还要从索引中同步失效，避免旧版本继续被召回。
维护记录也要区分事实与推测。“司机报告异响”是观察，“疑似轴承问题”可能只是初步判断。解析和摘要时保留说话人、时间与证据状态，能减少模型把猜测写成已确认故障。
## 用历史事件建立黄金测试集
上线前可从过去六到十二个月的真实事件中抽取代表样本，并去除不必要的个人信息。样本要覆盖正常查询、拼写错误、跨线路问题、资料缺失、数据过期、工具超时和来源冲突。每道题记录必要证据、允许的答案范围以及必须升级给人的条件。
评测要拆开看。检索阶段检查必要文档是否进入前若干条结果；生成阶段检查事实、引用、时间和数字是否与工具输出一致；流程阶段检查权限、人工确认和回退是否真的生效。平均正确率之外，还要看最慢请求、失败重试、单任务成本和最危险错误。
长上下文也需要压力测试。把关键规则放在文档开头、中间和末尾，加入相似但已失效的版本，观察模型会不会漏读或引用错误。供应商基准只能帮助选择候选模型，不能代替这套本地实验。
## 从影子模式走向有限试点
第一阶段只在离线环境回放历史事件，不接触生产发布。第二阶段进入影子模式：系统接收真实数据并生成建议，但工作人员看不到或不会据此行动，团队将输出与真实处置结果对比。这样可以发现数据延迟、接口异常和现场语言差异。
第三阶段只开放给一小组受训人员，限定一两个低风险任务，例如查询手册和草拟公告。界面应同时显示证据、数据时间和不确定状态，不能用流畅措辞掩盖来源缺失。人工修改要被记录，用来区分“内容错误”和“表达不合用”。
扩大范围必须有明确门槛：关键事实和引用达到预设目标，没有越权发布，延迟与成本可接受，用户确实节省时间。触发高风险错误、数据大面积过期或监控失灵时，应能立即关闭模型路径，退回原有检索和人工流程。
## 指标要连接运营结果
技术指标可以包括检索召回、引用准确率、工具调用成功率、无依据断言率、拒答是否恰当、响应时间和单位任务成本。但这些分数只有连接到运营结果才有意义。
团队还应观察查找手册所需时间、公告修改幅度、重复工单减少量、过期信息被拦截的次数，以及人员是否更容易发现冲突。任何安全相关事件都应单独复盘，不能被平均数稀释。
同时防止“看起来更快，实际多一道审核”。若工作人员需要逐字核对冗长答案，模型可能转移而非减少工作量。好的辅助系统应让证据更近、结构更清楚，并允许人快速否决。
## 结语：先成为可靠的副驾驶
AI21 的长上下文模型和编排能力，为交通运营中的知识检索、记录整理和文本草拟提供了候选工具，但它们并不自动构成行业方案。真正的方法论，是把实时计算交给确定性程序，把安全控制留在专用系统，把模型放进有来源、有权限、有人工确认的知识链路。
从窄任务、历史回放和影子模式开始，用本地数据证明价值，再逐步扩大。大模型在交通领域最现实的起点，不是接管方向，而是让一线人员更快找到可信信息，同时始终保留停止、核对和回退的权利。
## 参考资料