企业官网建设流程全解析

在自动驾驶的道路实测里，最让人心跳加速的瞬间往往不是前方车辆急刹，而是路沿上一个行人突然往外迈的那一小步。那一小步的背后，是一个专门的研究方向：行人运动预测。它回答的不是“现在谁在哪”，而是“接下来三到五秒这个人可能出现在哪、以什么方式出现”。这篇文章我打算用一份研究提案的视角去拆这个课题——怎么把问题定义得足够精确，怎么选数据、搭模型、定指标，以及在复现和评估中会遇到哪些论文不会写的坑。如果你是刚入这个方向的研究生、工程师，或者只是好奇自动驾驶为什么总在“行人”上格外谨慎，这篇内容应该能帮你省下不少绕弯的时间。

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。它们各自的优势差异很大，不能无脑选最火的。

如果是做自动驾驶方向，我一般建议先尝试 Argoverse 或 Waymo，因为它们更接近真实车载传感器条件下的输入。Argoverse 的高精地图里有人行道、车道线、停车线这些语义元素，做场景上下文很方便；Waymo 数据量大，但轨迹采样频率和遮挡情况需要好好处理。如果只是想在模型结构上快速验证 idea，ETH/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 曲线有用得多。

最后再分享一个我的操作习惯：拿到这类研究课题，我不会一上来就去复现最新模型。先拿一个公开数据集做可视化，观察一百条真实行人轨迹长什么样；再跑通常量速度模型，做出第一版答辩用的指标表；然后才开始加交互、加场景、加多模态。这套流程看起来慢，但后面吃的亏最少。如果你也准备写自动驾驶行人运动预测的研究提案，不妨从这一步开始。