夜雨聆风
感知告诉自动驾驶系统"周围有什么"，预测要回答的是更难的问题——"它们接下来会去哪"。
一个以120km/h行驶的障碍车，3秒后在哪里？变道还是直行？在路口是左转还是右转？这些问题如果不能在100毫秒内给出带概率的答案，规划模块就是在盲开。
我翻了一遍Apollo的预测模块源码，发现它的做法跟我想的不一样。不是端到端大模型一把梭，而是老老实实拆成了四步流水线：Container收数据，Scenario分场景，Evaluator打分，Predictor生轨迹。每一步都绑死在高精地图的车道模型上。
这种做法有它的道理，但代价也很大——没有高精地图，预测直接瘫痪。
四步流水线
Apollo预测模块的入口在prediction_component.cc，Cyber RT回调触发后，所有逻辑在MessageProcess::OnPerception里串行执行。整条链路不长，但每一步的信息密度很大：
第一步，Container收数据。 三个容器各司其职。ObstaclesContainer从感知消息里提障碍物，用LRU Cache缓存最近10帧历史——这个数字不是随便定的，Apollo认为10帧（约1秒）的运动历史够判断意图了。PoseContainer存自车位姿，把自车也当id=-1的障碍物塞进ObstaclesContainer。ADCTrajectoryContainer存上一帧规划轨迹，这是交互预测的关键输入——你得知道自车想往哪走，才能猜别人会怎么应对你。
第二步，Scenario分场景。ScenarioManager只认两种场景：Cruise和Junction。判断依据很简单——自车离路口小于10米就是Junction，否则就是Cruise。同时给每个障碍物打优先级：Ignore、Normal、Caution。Ignore的标准比较粗暴——不在扫描框（前方80米、左右6米）内、不在车道上、不在路口附近，直接忽略。Caution更严格：离自车近且在路口内、是自车前方第一个障碍物、或者车道序列与自车规划轨迹重合。7.0版本还新增了Interaction等级，介于Caution和Normal之间，专门给那些可能和自车发生博弈的障碍车。
第三步，Evaluator打分。 这是最核心的步骤，后面单独拆开讲。
第四步，Predictor生轨迹。 拿到Evaluator输出的车道序列概率，按概率筛选，生成最终的可行驶轨迹点。
四步串完，一个障碍物从"被感知到"到"3秒后的预测轨迹"就算走完了。整个过程在单帧里对所有障碍物批量执行，支持多线程——按障碍物优先级分组，Caution的走一个线程池，Normal的走另一个。
Evaluator：比我想的更"朴素"
我本来以为Apollo的评估器会用什么高端架构，翻开源码一看——主力居然是MLP。
JunctionMLPEvaluator，路口场景专用。它把路口出口离散化成12个扇区——以障碍物为中心，车头朝向为参考方向，360度切成12份，每份30度。然后用一个MLP做12分类，输出每个扇区的概率，再映射到对应的车道序列。特征向量不长：障碍物特征4维+历史2×5维，自车特征4维，路口出口特征12×8维，总共不到120维。一个三层的MLP就能跑。模型文件在prediction/data/目录下，TorchScript格式，C++直接调用libtorch推理。
CruiseMLPEvaluator，巡航场景专用，但比路口的复杂。它同时维护两个MLP模型：torch_go_model_处理正常车道保持，torch_cutin_model_处理加塞场景。特征维度也更高：障碍物23+5×9维，交互特征8维，车道特征4×20维。为什么要把go和cutin拆成两个模型？因为加塞行为的特征分布和正常跟车完全不同，一个模型很难同时学好两种模式。这是工程上很务实的做法，代价是多维护一个模型。
LaneScanningEvaluator，思路又不一样。它不输出概率，直接输出短期轨迹点。做法是沿车道扫描——前进方向100个点，后退方向50个点，转换到障碍物坐标系，喂给模型。这个评估器主要用于直道场景，省去了车道序列概率这个中间步骤。
SemanticLSTMEvaluator，7.0版本为Caution级障碍物引入。CNN提取语义地图特征，LSTM建模时序依赖，输出带不确定性的短期轨迹。模型参数按障碍物类型区分——车辆和行人用同一个架构但不同权重。
PedestrianInteractionEvaluator，行人专用。Social LSTM方案：先算位置嵌入和社会嵌入（social embedding，编码周围行人的交互影响），过LSTM，输出短期轨迹。每4帧更新一次LSTM隐状态，兼顾精度和计算量。
JointlyPredictionPlanningEvaluator，这是7.0新增的交互评估器，用VectorNet+LSTM。关键区别在于它把自车规划轨迹（ADCTrajectoryContainer）作为输入，考虑自车和障碍车的博弈关系。在Apollo的设计里，只有Interaction等级的障碍车才会走这个评估器。
整个Evaluator的选型逻辑是这样的：障碍物类型（车/行人/自行车）× 场景（Cruise/Junction）× 优先级（Normal/Caution/Interaction）→ 对应评估器。配置写在prediction_conf.pb.txt里，按obstacle_type和obstacle_status匹配。
所有模型统一用TorchScript格式，C++端libtorch推理。启动时LoadModel加载，还有一步warmup——模型第一次推理会慢，提前跑一遍避免线上卡顿。如果开了FLAGS_use_cuda，模型会走GPU。
Predictor：从概率到轨迹
Evaluator输出的是"走哪条车道序列的概率"，Predictor要把这个概率变成一串可行驶的轨迹点。
Apollo实现了9种Predictor：Empty、SingleLane、LaneSequence、MoveSequence、FreeMove、Regional、Junction、Interaction、Extrapolation。常用的是三种：
MoveSequencePredictor，最常用。它先过滤掉低概率车道序列——FilterLaneSequences函数会根据概率阈值砍掉不太可能走的路线。然后对每条保留的车道序列，按障碍物的运动学模式生成轨迹点。如果车道上有停止标志，判断自车是否需要停车，需要的话用匀减速模型DrawConstantAccelerationTrajectory；否则用运动学模型DrawMoveSequenceTrajectoryPoints。
ExtrapolationPredictor，配合SemanticLSTMEvaluator使用。LSTM只输出短期轨迹（约2-3秒），ExtrapolationPredictor要把它外推到8秒。外推分两路：如果短期轨迹能匹配到车道（SearchExtrapolationLane，按搜索半径和角度阈值找最近车道），就沿车道匀速外推；匹配不到就按自由运动外推。外推速度由ComputeExtraplationSpeed计算，取轨迹尾部几个点的平均速度。
InteractionPredictor，7.0交互预测器。在所有评估器跑完之后执行，计算后验概率。它把自车轨迹按固定间隔采样，计算每条障碍物短期轨迹的总代价——代价是加速度、向心加速度和碰撞代价的加权和：
total_cost = w_acc * cost_acc + w_centri * cost_centri + w_collision * cost_collision
然后用指数函数算似然：likelihood = exp(-alpha * total_cost)。最后用贝叶斯公式算后验：posterior = prior * likelihood。prior来自Evaluator的概率输出，likelihood来自与自车轨迹的交互评估。这是一个经典的贝叶斯更新——先给一个先验概率，再根据交互代价修正。
争论一：没有高精地图，预测直接瘫痪
Apollo预测最大的假设是：所有障碍物的未来轨迹都锚定在高精地图的车道序列上。
JunctionMLPEvaluator的12扇区要映射到车道出口，CruiseMLPEvaluator的特征提取依赖车道几何，MoveSequencePredictor沿车道线生成轨迹——整条链路从输入到输出，每一步都需要车道信息。如果你在一个没有高精地图覆盖的区域，或者地图数据过期了，预测模块只能降级到FreeMovePredictor——用卡尔曼滤波做匀速直线外推，精度上限就在那里。
这不是Apollo独有的问题，所有基于车道模型（lane-based）的预测方案都一样。TNT（Target-driveN Trajectory Prediction）也是先在车道上撒候选目标点再评分，离不开地图。但近年纯学习方案开始冲击这个假设。MultiPath++用Transformer编码场景上下文，直接在BEV空间生成多模态轨迹，不绑定车道锚点。MTR（Motion Transformer）更激进，意图查询（intention query）替代了车道序列，轨迹在自由空间生成。
纯学习方案在nuScenes和Argoverse的benchmark上确实更准，但Apollo坚持车道模型有它的理由：
可解释性。 一条车道序列概率为0.8，你知道为什么——因为障碍物在这个车道上、速度匹配、没有加塞意图。一个Transformer的attention score，你能解释给安全审计员听吗？
实时性。 MLP+车道模型的推理延迟在毫秒级，Transformer方案动辄几十毫秒。预测模块在100毫秒的处理窗口里要跑完所有障碍物，容不得半点延迟。
约束保证。 沿车道生成的轨迹天然满足道路拓扑约束——不会出现穿越隔离带的预测。自由空间生成需要额外的后处理来保证物理可行性。PRIME论文做过统计，纯学习方案在Argoverse数据集上有16.5%以上的预测轨迹在物理上不可行。
但现实是，越来越多公司开始在两者之间找折中。用车道模型做粗粒度锚定，用学习模型做细粒度修正。理想汽车6月刚发布的马赫VLA模型，响应速度0.28秒，用视觉-语言-动作联合建模，本质上就是在摆脱对高精地图的依赖——它的预测不再锚定车道，而是从视觉输入直接推理未来轨迹。这条路能走多远，目前还是未知数。
争论二：分治架构，信息在哪里丢了
Apollo把预测拆成Evaluator和Predictor两步：先评出车道序列概率，再按概率生成轨迹。这个分治架构在工程上很干净——评估器专注意图识别，预测器专注轨迹生成，各自独立迭代。
但问题在于，两步之间有一个信息瓶颈。
Evaluator输出的只是"走这条车道序列的概率"，比如0.8。Predictor拿到0.8之后，按概率分配轨迹权重，然后沿车道线生成轨迹点。但0.8这个数字压缩了大量信息——障碍物在车道内的横向偏移趋势、微小的速度波动、与前车的间距变化，这些在意图评分阶段就被丢弃了，Predictor拿不到。
更严重的损失在交互信息上。JointlyPredictionPlanningEvaluator确实考虑了自车轨迹，但它输出的还是车道序列概率，交互信息被压缩成了一个标量。Predictor生成轨迹时，再想利用交互细节已经来不及了——它只看到概率，不知道这个概率是怎么来的。
对比PRIME的做法：模型驱动的轨迹生成器先在地图上搜索所有可达路径，对每条路径采样物理可行的轨迹，然后学习评估器对所有候选轨迹统一评分。评分不是给车道序列打分，而是直接给轨迹打分——轨迹的加速度、横向偏移、与前车距离这些细节都能被评估器看到。没有中间压缩，没有信息瓶颈。
还有更极端的联合方案：把预测和规划放在一起优化。自车的规划和障碍物的预测不再是串行关系，而是共同求解一个优化问题。Apollo的JointlyPredictionPlanningEvaluator取名里有"jointly"，但实际上只是把自车轨迹当特征输入了，远没到联合优化的程度。
分治的好处是每步可验证、可独立调优。但代价是两步之间的信息损失，这个损失在复杂交互场景下尤其明显。路口里一辆车到底是让行还是抢行，0.1秒的犹豫就是完全不同的轨迹。一个概率数字装不下这种细微差别。
我的判断
翻完预测模块的源码，我的感受是：Apollo的预测是一个工程上非常成熟的方案，但架构上已经开始暴露代差。
车道模型+MLP评分+运动学生成的组合，在结构化道路上稳定可靠，延迟可控，可解释性强。这是2018年的设计思路，放在今天仍然能用——但只是"能用"，不是"领先"。
真正的问题是：当你在城规道路上遇到一个不守规矩的三轮车逆行，或者路口里行人和车辆混行的复杂博弈，车道模型假设开始崩塌，MLP的特征表达能力不够用。这时候你需要的是更强的场景理解能力和交互建模能力，而这两样东西，纯靠加更多MLP评估器是堆不出来的。
7.0版本引入JointlyPredictionPlanningEvaluator是个信号——Apollo自己也意识到了交互建模的重要性。但目前的实现还只是在Evaluator层面加了一个VectorNet+LSTM，没有触及架构的根本。
下一个代际的变化，大概率是从车道锚定走向BEV空间，从分治走向联合优化。这个变化已经在学术圈发生了，工程落地只是时间问题。但在那之前，Apollo这套方案还能撑多久——这取决于你跑的场景有多复杂。
源码路径：modules/prediction/
