在自动驾驶的道路实测里最让人心跳加速的瞬间往往不是前方车辆急刹而是路沿上一个行人突然往外迈的那一小步。那一小步的背后是一个专门的研究方向行人运动预测。它回答的不是“现在谁在哪”而是“接下来三到五秒这个人可能出现在哪、以什么方式出现”。这篇文章我打算用一份研究提案的视角去拆这个课题——怎么把问题定义得足够精确怎么选数据、搭模型、定指标以及在复现和评估中会遇到哪些论文不会写的坑。如果你是刚入这个方向的研究生、工程师或者只是好奇自动驾驶为什么总在“行人”上格外谨慎这篇内容应该能帮你省下不少绕弯的时间。1. 研究提案第一步把“行人运动预测”从直觉变成精确问题做研究提案最容易犯的第一个错误不是模型选错而是问题本身没定义清楚。很多人口口声声说“我要做行人运动预测”但问到底层输入是什么、输出是什么、预测多久、评估用什么答案往往是一团浆糊。所以我不急着谈网络结构先聊聊怎么把一个模糊直觉变成一个可计算的课题。1.1 为什么预测不是感知也不是规划很多刚接触这个方向的人会把行人运动预测和感知、规划混在一起。感知的任务是检测、分类和跟踪它给你的是“现在这个时刻的边界框、类别、速度”规划的任务是找一条从当前位置到目标点的可行轨迹而预测在中间负责把感知输出的状态延展到未来一段时间。如果预测模块定义不清楚感知模块会不得不把“未来猜测”也塞进来规划模块也会被迫做很多不必要的概率对冲。我在看提案的时候最怕看到一句话“我们在感知模块里顺便把预测做了。”这句话听起来省事实际会引发一连串问题感知输出的检测框噪声很大直接外推会放大误差感知模块也不关心道路结构所以它给出的速度向量很可能把人行道方向算错。反过来如果规划模块直接去“猜”行人意图规划器就会被各种概率分布的噪点淹没最后输出一条谁都看不懂的曲线。正确做法是让预测模块有独立的输入输出接口和感知、规划解耦各司其职。这里还要提一下语义分割。感知里的语义分割结果比如哪块区域是人行道、哪里是马路牙子恰恰是预测模块用来判断“行人下一秒更可能往哪走”的重要输入。研究提案里如果能把语义分割当作场景上下文的一部分而不是仅仅当作感知结果的装饰会显得你真正理解了系统架构。1.2 用形式化语言定义预测目标我建议在研究提案里开门见山写清楚条件概率形式给定历史观测 ( X )预测未来轨迹 ( Y ) 的条件分布 ( P(Y|X) )。( X ) 可以包含目标行人过去 1 到 2 秒的位置序列、速度、朝向也包括周围行人、车辆的位置和速度包括道路结构、红绿灯状态、语义分割图甚至天气。( Y ) 一般是未来 3 到 5 秒的轨迹序列采样间隔 0.1 秒。这里有两个容易让提案显得不专业的坑。一是没有明确预测时域因为 3 秒和 5 秒预测难度完全不同模型可能在一个时域上领先另一个时域上反而落后。二是没有明确输出形式是输出单条轨迹还是多条带概率的候选轨迹。这两点不写清楚后面的一切实验都缺乏锚点。状态表示也要定义清楚。对行人来说比较常见的状态向量是 ( (x, y, \theta, v) )即平面位置、朝向和速度。但要注意行人不是刚体朝向和速度之间往往不一致有人侧着身走有人先转头再改变方向。所以有的工作会额外引入“身体朝向角速度”或者“视觉注意力方向”这些信息在数据标注里不一定都有但如果你用的数据集里面有相机图像可以通过姿态估计补出来。1.3 一个可行的问题边界样例举个例子我要做一个“交叉路口行人过街意图预测”的研究提案。我会这样写输入过去 2 秒、20Hz 采样的行人历史轨迹配合同一坐标系下的地图、红绿灯时序和行人身体朝向输出未来 3 秒内5 条候选轨迹以及每条轨迹的概率要求预测频率不低于 10Hz单帧推理延迟小于 30ms。这样定义后数据采集、模型设计、评价指标全都有了明确的边界评审人也不会觉得你在画饼。你甚至可以继续加一个条件把“行人是否会在未来 2 秒内开始过街”作为一个二分类辅助任务和轨迹预测联合训练。这个辅助任务在系统落地时非常有用因为它可以直接连到红绿灯控制或者车辆 AEB 策略上。2. 数据集与评测基线没想清楚这两件事模型再新也站不住研究提案里最容易被评审人一眼看穿的水分是对数据集和基线的态度过于随意。模型写得很花哨但数据选得不对或者拿一个不知名的“自定义数据集”做评测这样的提案基本没有说服力。我一般会先在数据集和基线上花掉不少时间这两件事定了后面模型迭代才有安全感。2.1 公开数据集选哪个几个主流数据集对比做行人运动预测现在绕不开的公开数据集大概有这么几个ETH/UCY、SDD、NuScenes、Argoverse、Waymo Open Dataset还有交互相对复杂的 InterAction。它们各自的优势差异很大不能无脑选最火的。数据集主要传感器/标注优势适合场景ETH/UCY俯视相机轨迹数据小、迭代快适合人-人交互算法验证学术探索期的模型设计SDD无人机俯视视频轨迹场景多样轨迹长密度高长时程行为建模NuScenes多传感器3D检测框地图传感器丰富适合多模态融合自动驾驶多传感器方案Argoverse高精地图轨迹带高清地图适合地图辅助预测地图特征与轨迹结合的研究Waymo Open Dataset激光雷达相机轨迹规模大、场景丰富大规模训练和评测InterAction交叉路口多智能体轨迹交互密集适合多智能体交互交互建模方法论研究如果是做自动驾驶方向我一般建议先尝试 Argoverse 或 Waymo因为它们更接近真实车载传感器条件下的输入。Argoverse 的高精地图里有人行道、车道线、停车线这些语义元素做场景上下文很方便Waymo 数据量大但轨迹采样频率和遮挡情况需要好好处理。如果只是想在模型结构上快速验证 ideaETH/UCY 依旧是好选择数据小、迭代快跑一个 Social LSTM 只要几十分钟比在大数据集上反复调参舒服得多。2.2 数据预处理中三个最容易被忽略的细节数据处理看起来枯燥但这里面的坑最多。第一个坑是坐标系统一。相机给的是像素坐标激光雷达给的是传感器直角坐标高精地图给的是大地坐标。如果不统一到同一个车身或全局坐标系后面画栅格图时所有轨迹都会错位。我在第一次做多传感器融合时光是对齐坐标就花了一周最后发现是雷达外参标定的符号方向反了。第二个坑是时间对齐。相机帧和激光雷达帧的时间戳不是天然同步的尤其跨传感器做特征融合时需要插值到统一时间戳否则你会发现预测轨迹和真值之间有一帧以上的系统性偏移。这个偏移在 ADE 指标上可能只体现为几厘米但在可视化时非常明显轨迹会呈现“锯齿状”。第三个坑是标签构建。行人的运动轨迹常因为遮挡被断开有的算法直接把断帧丢弃但这种做法会在行人重新出现时造成“凭空出现”的假象。更稳妥的做法是只保留连续轨迹片段并对短暂遮挡做合理性插值。你可以在提案里明确写出“保留连续长度不超过 N 帧的片段”这样的预处理规则数据清洗的可复现性会更强。2.3 建立自己的 baseline先跑通一个最简单的预测器我强烈建议任何研究提案里都保留一个“常量速度模型”作为 baseline。它假设行人保持当前速度直线往前走代码半小时就能写完但它能帮你做三件事。第一验证你的数据预处理流水线正确因为一个人在匀速直线运动时CV 模型应该给出接近完美的预测如果 CV 模型的误差也很大说明坐标系、时间戳或者轨迹采样出了问题。第二给后面的深度模型设置一个最低标准如果深度学习模型连 CV 都打不过说明模型结构或输入特征出了问题这时候别急着改 network先回去检查数据和 loss。第三作为实车安全兜底当神经网络因为输入异常不可用时切回 CV 模型至少还能撑一两秒。有人会觉得常量速度模型太简单放进提案显得没水平。我的观点恰恰相反一个干净的 CV baseline 是衡量复杂模型增益的标尺。你后面无论是加交互模块还是加地图编码器都要能回答“相比 CV 模型涨了几个点”这个问题。3. 模型方案设计从常量速度到交互感知每个层次解决什么问题这一章是研究提案的重头戏也是大家最想看的部分。但我不想直接贴一个端到端网络了事我更愿意把模型方案拆成几个层次来讲。因为行人运动预测不是一个单一问题它同时包含物理约束、意图推断和交互建模每个层次解决的东西都不一样。3.1 第一层基于运动学模型的预测为什么至今仍是安全底线运动学模型不关心行人的意图只把行人当成一个刚体用运动方程外推。最简单的恒速模型恒转弯率和速度模型考虑角速度恒加速度模型适合描述跑步者。这些模型的优点是推理开销极小、行为可解释但缺点也很明显它无法预测一个行人在看到绿灯后突然加速也无法表达多个行人之间的彼此避让。所以运动学模型在提案里的定位往往不是主模型而是安全底线和安全兜底。自动驾驶系统在极端情况下需要有一个“不会崩”的模型运动学模型就是这种角色。你深度学习模型推理延迟超标、输入传感器出现异常系统应该自动降级到运动学预测而不是硬撑着输出一个乱猜的轨迹。研究提案里如果能明确写出“运动学模型作为降级策略”的架构设计会比只堆模型更能打动做系统的评审人。3.2 第二层概率图模型如何表达多目标交互在深度学习霸屏之前行人预测常用社会力模型。社会力模型把每个行走的人受到来自目标的吸引力、来自其他行人和障碍物的排斥力建模成合力由此生成下一步运动方向。它解释性强数据需求量小但参数敏感一旦场景中出现非常规行为就容易崩。概率图模型如动态贝叶斯网络则把预测问题看作状态估计与推理问题可以显式建模行人是否将要穿过马路这样的隐状态。你可以在模型里定义“等待—起步—行走—奔跑”这几个离散状态然后通过观测序列去推断状态转移概率。这种方法的优势是透明出了问题能回溯到某个隐状态不像深度学习那样黑盒。现在很多论文不太提概率图模型但我觉得它在研究提案里仍然有位置尤其是在数据量很小的场景下。你可以把社会力模型的输出作为先验信息输入给后面的深度模型让网络不用从零开始学“行人会互相避让”这个常识。3.3 第三层以深度轨迹生成模型为主力的当代方案当代方案大家应该很熟悉把历史轨迹向量和场景栅格图输入一个编码器再用解码器输出未来轨迹。注意两个关键组件交互建模和场景建模。早期 Social LSTM 用 LSTM 编码轨迹再用一个 social pooling 层让相邻行人共享隐藏状态能学出基本的避让行为。后来注意力机制和 Transformer 把无序的智能体交互变成了一个 set-to-set 问题效果更好。同时用语义分割图或栅格地图作为场景特征再用 CNN 或 Transformer 编码就能让模型知道“斑马线”和“车道边缘”在哪里。输出部分通常用混合密度网络或条件变分自编码器生成多条候选轨迹每条配一个概率。这类模型的问题是训练成本高、可解释性弱需要通过可视化注意力来确认它学到了什么。我见过不少论文模型在交互场景里分数很高但你把它可视化到具体帧上会发现它根本没在“看”旁边的行人只是在拟合数据集里的统计规律。所以在提案里我建议计划加入“注意力可视化与失败案例展示”这一工作项这会让模型的可靠性论证更完整。至于热词里的“pso 自动驾驶”我猜是想说用粒子群优化去搜模型超参或规划参数。我的态度是这种无梯度的优化方式在调参领域可以做辅助但研究提案里不要把核心贡献放在 PSO 调参上评审人会认为贡献太薄。它更适合用来做轨迹规划器在特定场景下的参数标定而不是替代梯度下降训练深度网络。3.4 多模态输出既要“大概率对”也要“小概率不撞人”行人的未来轨迹本质上是多模态的。停在路口的行人下一秒可能是继续等也可能突然起步你没法用一个单峰的高斯分布去描述所有可能。自动驾驶系统不能只依赖一条最高概率轨迹做决策更合理的做法是让模型输出若干条候选轨迹和概率然后把概率较低但风险较高的轨迹也用于安全包络。这里有个常见误解多模态输出就是模型预测 5 条轨迹然后选一条和真值最近的算 minADE。这其实只是表达能力的评测方式真正在实车上的用法是把概率非零的轨迹都送进下游碰撞检查模块如果其中任意一条可能导致碰撞车辆就要提前减速或者鸣笛提示。正因为如此模型不仅要会“猜中”还要会“覆盖”这是多模态预测和单模态预测的本质区别。4. 实验设计与评价指标决定提案能不能被评审信服的关键模型写完了下一步就是怎么证明它有效。实验设计这部分我看到太多提案只放一张总指标表然后说“我们的方法取得了 SOTA”。这种说服力非常弱。真正扎实的实验设计至少要包含三个层面的东西分层指标、公平基线、系统消融。4.1 指标不只是 ADE/FDE还要看预测场景分布在数据集排行榜上最常见的两个指标是 ADE 和 FDE。ADE 计算预测轨迹中每个时刻与真值的平均欧氏距离FDE 只看最后一个时刻。多模态模型还会用 minADE/minFDE也就是从多条预测轨迹中选一条离真值最近的来计算用来衡量模型表达能力的上限。但这两个指标都不足以评估概率质量所以还要看负对数似然 NLL 和 miss rate。NLL 考察的是模型对概率分布的估计是否准确简单说就是“模型嘴上说很自信的轨迹是不是真的比不太自信的轨迹更准”。miss rate 评估的是在给定阈值下预测轨迹集合有没有覆盖到真值附近的区域。对自动驾驶安全来说miss rate 往往比 ADE 重要因为漏覆盖比位置误差大更危险。更重要的要按场景分层统计。比如“过街意图切换前后”的 FDE“被遮挡后重新出现”的 miss rate“雨雪天气”下的 ADE。在提案里写清楚分层指标比只追求平均指标显得严谨。评审人最怕的就是你用一个平均数掩盖了极端场景的失败。4.2 实验设计的对照组怎么搭才公平对照组是研究提案的脸面。最不考察公平性的做法是只对比自己的最新模型和论文里报告的“性能数字 1”却忽略了两者用的数据集划分、预处理、训练策略不一致。你看着你的数字比他人高 0.05实际上可能只是数据划分方式不同带来的假象。我常用的对照设计是这样的固定同一种数据划分固定同一个预处理脚本然后依次跑常量速度模型、卡尔曼滤波、Social LSTM、Trajectron、你的模型。如果条件允许还要保证每个模型的输入特征一致。比如你的深度模型用了高精地图和语义分割那基线模型里也应该有对应的地图条件或者你明确说明这个对比的目的就是检验“加入地图特征是否有用”。此外设定固定随机种子、用不同初始化跑多次取均值和标准差避免一次结果撞大运。深度学习训练本身有随机性单次实验里差个 0.01 可能只是运气跑 5 次取平均会可靠很多。4.3 消融实验的次序也有讲究消融实验用于证明每个模块的必要性。推荐做法是“从完整模型往下去掉模块”而不是从零开始逐个添加。为什么因为从完整模型开始每去掉一个组件你都能清楚看到该组件在完整系统中的边际贡献。如果是逐个添加最后一个加进去的组件往往沾了前面所有组件的光贡献会被高估。比方说完整模型含交互编码器、场景栅格编码器和多模态输出头。第一步去掉场景栅格编码器保留其余部分看 FDE 涨了多少第二步再去掉交互编码器看进一步涨了多少第三步把多模态输出改成单峰看是不是多模态的增益最大。每一步都用同样的数据、同样的训练步数最好把推理耗时也列出来让评审知道每个模块大概付出了多少计算成本。5. 实际落地中的坑我在跑行人预测实验时反复踩过的几个问题前面讲的是研究提案里的“书面正确”这一章我想说说那些真正跑实验时才会遇到的问题。这些问题不在论文里却可能让你多花几周甚至一两个月。我捡几个印象最深的坑。5.1 坐标与坐标系毫米波雷达、相机、全局地图各说各话我在第一次做 Argoverse 数据时踩过最大的坑是坐标对齐。数据集给的轨迹位置是全局坐标而场景栅格图需要把行人坐标转成以目标车辆为中心的局部坐标。转换公式很简单但那个偏航角是从组合导航来的如果标定少旋转了一个符号轨迹在栅格里就会偏出半米。这个误差在指标上可能看不出来因为全局坐标下的绝对值还是准的但一到连续帧可视化就会出现预测轨迹忽左忽右的奇怪现象。解法也很朴素做一份统一预处理脚本把转换后的轨迹叠加到栅格图上人工检查几帧直到视觉上完全重合再继续下一件事。自检这一步会帮你避免后面所有模型都建立在一个错误坐标系上的灾难。5.2 数据泄漏别让小样本的“巧合”变成高分数据泄漏是行人预测里特别隐蔽的一个坑。很多户外数据集里同一个人会出现在连续多个场景片段中。如果你随机划分训练集和验证集同一个行人的不同片段可能同时出现在两边模型相当于开卷考试分数会虚高。我在一次小规模实验中随手按帧随机划分得到一个看起来非常漂亮的 ADE换了按场景 ID 严格划分后那个数字立刻掉了 0.2 米。从此这类任务我再也不随机划分了要么按场景 ID要么按行人 ID而且会检查训练集和验证集之间是否还有共同行人。另一个泄漏来源是特征构建。有的人为了提升模型表现把未来一小段检测框信息也偷偷塞进历史特征里哪怕只提前了零点几秒也属于泄漏。这个操作在论文里几乎不会主动写出来但如果你复现某个结果却怎么都达不到可以检查一下是不是有类似问题。5.3 轨迹预测的评估到底该不该考虑反应时间真实车辆不是预测模块输出一个轨迹规划器就能瞬间执行。从预测到控制有一个延迟窗口包括模型推理、规划计算、执行机构响应。如果设计研究提案只考虑预测精度不考虑这个时间窗口就很难说服做系统的工程师。比如一辆以 60km/h 行驶的车1 秒就能跑 16 米。预测模块说“行人可能在前方 15 米处出现”但等你规划完轨迹、发出刹车指令、制动系统建立压力行人可能已经走到正前方了。研究中可以引入一个简单的反应延迟模型把预测结果先延迟一个控制周期再交给下游避撞逻辑评估碰撞率。这样能让你的预测算法和决策框架之间的耦合变得更可信。5.4 车辆控制接口对预测频率的隐性约束很多发表的深度学习模型在单张 A100 上推理一次可能需要 20 毫秒看起来很快但部署到车载计算平台上再加上前后处理的耗时可能就变成 50 毫秒。而车辆底盘控制往往要求轨迹更新频率到 20Hz 甚至 50Hz模型的推理频率如果只有 20Hz规划器就只能拿着旧轨迹做插值。研究提案里我建议写清楚目标平台。如果只是想发论文可以不用太纠结推理时延但如果目的是落地最好在提案里计划一个模型轻量化阶段用 TensorRT 或 ONNX 把模型量化到 FP16把单次推理时延压到 30 毫秒以内并说明在什么硬件上测的。这种对系统约束的敏感度会让提案的工程价值一下子上一个台阶。6. 研究提案的价值主张怎么让一个方向看起来既有深度又有落地可能最后想聊一下价值主张。单纯把行人运动预测当作一个“排行版刷分”的课题很容易把研究做窄。评审人和工程负责人真正关心的是这个预测能不能让自动驾驶系统更安全、更高效你能不能把预测算法放进完整的自动驾驶规划控制算法框架里证明它的价值这一章就是回答这个问题。6.1 从“更好预测”到“更好决策”的闭环设计评估指标再漂亮如果预测结果不能转化成更低的碰撞风险或更高的绕障成功率研究提案的价值就会打折。我建议将提出来的预测模型放进一个闭环模拟器里和下游规划器耦合评估。具体做法是同一个规划算法分别接“只输出最大概率轨迹的预测器”和多模态预测器然后在同一批场景里跑比较紧急刹车次数、路径平滑度、任务完成时间。你会看到多模态预测往往会减少突然刹停因为规划器提前知道了低概率但高风险的轨迹。这种闭环结果比单点指标更能说明问题也是研究提案里最有说服力的图。6.2 安全关键场景的失衡问题现实道路中最危险的行人场景往往是长尾的鬼探头、雨天打伞、夜间突然奔跑、小孩子从两辆车中间钻出来。公开数据集中这些样本占比很小深度学习很容易把它们当作噪声忽略。针对这种情况研究提案可以专门设计一个“危险场景挖掘”步骤先用基线模型在大规模数据上预测把 miss rate 最高的场景片段挑出来再做困难样本重加权或数据增强。甚至可以用策略梯度生成一些对抗性的“行人运动轨迹”去测试预测模型的鲁棒性边界。这个方向的价值不亚于把平均 ADE 降低几厘米但论文里少有人系统性地做。6.3 单目相机和激光雷达之外的传感器玩法除了相机和激光雷达现在很多车还装了 4D 毫米波雷达、鱼眼相机和 V2X 路侧单元。把这些传感器的输出融合进预测模块能在雨雾天气或遮挡场景下多拿一些线索。比如 4D 毫米波雷达在恶劣天气下比相机稳定虽然点云稀疏但配合视觉语义分割能提供更强的底层特征。另一个有意思的方向是增强现实把预测轨迹直接叠加到驾驶员或路测工程师的 AR 眼镜、车载 HUD 上人就能直观看到系统预测的行人路径是否合理。这个方向虽然偏可视化但能让算法工程师在开发阶段快速发现问题。我在做路测数据回放时也经常用类似工具——把预测结果画在视频上一眼就能看出模型在哪一帧开始“犯傻”比盯着 ADE 曲线有用得多。最后再分享一个我的操作习惯拿到这类研究课题我不会一上来就去复现最新模型。先拿一个公开数据集做可视化观察一百条真实行人轨迹长什么样再跑通常量速度模型做出第一版答辩用的指标表然后才开始加交互、加场景、加多模态。这套流程看起来慢但后面吃的亏最少。如果你也准备写自动驾驶行人运动预测的研究提案不妨从这一步开始。