1. 端到端算法到底在解决什么问题

1.1 从模块化堆叠到单一网络：一场架构范式的迁移

过去做自动驾驶感知决策，主流思路是模块化流水线：感知模块负责检测障碍物、车道线、交通标志，预测模块推断其他交通参与者的未来轨迹，规划模块生成自车路径，控制模块输出油门刹车转向。这套架构跑了很多年，工程上成熟、可解释性强、每个模块可以独立调试和验证。但它的痛点也很明显——模块之间的接口是人工定义的，信息在传递过程中不断被压缩和丢失。感知模块输出的是目标框和类别，预测模块拿到的是这些框的轨迹，规划模块再基于预测结果做决策。每一层都在做有损压缩，上游的微小误差会在下游被放大，而且各模块的优化目标并不完全一致，感知追求检测精度，规划追求行驶平顺性，两者之间没有直接的梯度回传。

端到端算法的核心思路就是把这些模块全部塞进一个神经网络，输入是原始传感器数据（摄像头图像、激光雷达点云、毫米波雷达信号），输出直接是控制指令或者规划轨迹。中间不再有人工定义的接口，所有特征表示由网络自己学习。这样做的好处是信息无损传递，梯度可以从最终的控制损失一路回传到感知层，整个系统朝着同一个目标优化。你可以把它理解成从“流水线分工”变成了“全栈工程师一个人干到底”，少了沟通成本，但對这个人的能力要求极高。

我刚开始接触这个方向的时候，最直观的感受是：端到端不是简单地把模块拼在一起，而是彻底改变了问题的建模方式。模块化时代，每个子问题都有明确的输入输出定义，你可以单独评估一个感知模型的mAP，也可以单独测试规划模块的舒适度指标。端到端之后，你只有一个整体损失函数，中间发生了什么很难说清楚。这既是它的魅力，也是它的风险。

1.2 为什么现在端到端突然火了

端到端这个概念其实不新，早在几年前就有学者尝试过用CNN直接输出转向角。但当时没有火起来，原因很现实：数据不够、算力不够、模型容量不够。一个端到端网络要学到从像素到控制的映射，需要海量的驾驶数据覆盖各种场景，需要足够大的网络来拟合这个复杂函数，还需要足够的算力来训练和推理。这三个条件在几年前都不成熟。

现在情况变了。各家车企和自动驾驶公司积累了数百万甚至上千万公里的驾驶数据，GPU集群的算力也上来了，Transformer架构让模型可以处理长时序和多模态输入。更重要的是，行业发现模块化架构的瓶颈越来越明显——长尾场景下，感知模块的漏检和误检会直接导致规划模块做出错误决策，而模块之间的误差累积很难通过单独优化某一个模块来解决。端到端提供了一种可能性：让网络自己学会处理这些长尾场景，因为它看到的是原始数据，没有被人工接口过滤掉的信息。

另一个推动因素是消费者对自动驾驶体验的期望在提高。模块化系统在简单场景下表现不错，但遇到复杂路况时，车辆的行为往往显得犹豫、不自然，因为每个模块都在自己的局部最优解附近工作，整体行为缺乏连贯性。端到端网络可以学到更接近人类驾驶风格的决策，因为它是在整体驾驶数据上训练的，而不是在人工定义的子任务上。

1.3 端到端不是万能药：先搞清楚它的边界

在深入技术细节之前，有必要先泼一盆冷水。端到端算法目前还远没有到可以完全替代模块化架构的程度。它的优势在于整体优化和信息无损传递，但它的劣势同样突出：可解释性差、调试困难、对数据质量和分布极其敏感、安全验证难度大。

我见过一些团队在端到端项目上的尝试，有的成功，有的踩了大坑。成功的案例通常有一个共同点：他们没有一上来就追求完全端到端，而是从部分端到端开始，比如感知和预测联合训练，或者预测和规划联合训练，逐步扩大端到端的范围。踩坑的案例则往往是直接抛弃模块化架构，结果发现模型在训练集上表现很好，一到实际路测就出现各种莫名其妙的行为，而且很难定位问题出在哪里。

所以我的建议是：端到端是一个方向，但不是一步到位的方案。你需要根据自己团队的数据积累、算力资源、工程能力来选择合适的端到端程度。下面我会详细拆解端到端算法的核心技术点、实操要点和常见坑。

2. 端到端算法的核心技术拆解

2.1 输入表示：原始传感器数据怎么喂给网络

端到端网络的输入通常是多模态的：前视摄像头、环视摄像头、激光雷达点云、毫米波雷达、IMU、GPS等。怎么把这些不同频率、不同坐标系、不同数据格式的传感器数据融合成一个统一的输入表示，是第一个技术难点。

摄像头图像是最常用的输入，因为它包含丰富的语义信息。但单目图像缺乏深度信息，所以通常需要多摄像头拼接成鸟瞰图（BEV）表示。BEV的好处是把透视视图转换成了俯视图，车辆周围的空间关系一目了然，而且不同摄像头的数据可以在同一个坐标系下融合。BEV的生成方式有几种：一种是基于LSS（Lift-Splat-Shoot）的方法，先预测每个像素的深度分布，然后把像素特征投影到3D空间再拍扁到BEV平面；另一种是基于Transformer的方法，用可学习的查询向量去注意力采样图像特征。两种方法各有优劣，LSS计算量大但几何关系明确，Transformer灵活但对训练数据要求高。

激光雷达点云的处理方式通常是体素化或者柱状化，然后用3D卷积或者PointNet类网络提取特征。点云的优势是深度信息准确，不受光照影响，但成本高、分辨率有限。毫米波雷达的数据更稀疏，但穿透雾霾和雨雪的能力强，通常作为补充模态。

注意：多模态融合的时机很关键。早期融合（在输入层拼接）信息保留最完整，但对齐要求高；晚期融合（各自编码后再融合）工程上简单，但信息损失大。实际项目中，中期融合（在特征层融合）是比较平衡的选择。

我个人的经验是，如果你的团队摄像头数据质量好、标注充分，可以优先考虑纯视觉BEV方案，成本低且易于扩展。如果激光雷达数据积累足够，可以尝试视觉加激光雷达的中期融合，在恶劣天气和远距离场景下会有明显优势。但不要一上来就搞五模态融合，数据对齐和时序同步的复杂度会让你怀疑人生。

2.2 网络架构：Transformer怎么就成了主流

端到端网络的骨干架构经历了从CNN到RNN再到Transformer的演变。CNN擅长提取局部特征，但感受野有限，难以建模长距离依赖。RNN理论上可以处理任意长度的时序，但训练时存在梯度消失和并行化困难的问题。Transformer的自注意力机制可以同时看到所有位置的信息，而且可以并行训练，天然适合处理驾驶这种长时序、多模态的任务。

目前主流的端到端架构通常包含几个部分：骨干网络（如ResNet、EfficientNet、ViT）负责提取单帧特征，时序融合模块（如Transformer的self-attention或cross-attention）负责整合历史帧信息，任务头（如检测头、预测头、规划头）负责输出最终结果。有些方案还会加入记忆模块，把之前的驾驶经验存储下来，在遇到相似场景时直接调用。

Transformer在端到端里的一个关键应用是BEV时序融合。单帧BEV只能看到当前时刻的环境，但驾驶决策需要考虑其他车辆的运动趋势。通过把历史帧的BEV特征用self-attention聚合起来，网络可以学到其他车辆的运动模式，从而做出更合理的预测和规划。这里的一个实操细节是位置编码的设计——BEV特征已经有了空间位置信息，但时序位置编码需要额外设计，常用的方法是可学习的时间嵌入或者正弦位置编码。

另一个关键点是查询向量的设计。在基于Transformer的端到端架构中，通常会用一组可学习的查询向量来代表不同的任务或不同的交通参与者。比如一部分查询向量负责检测车辆，一部分负责检测车道线，一部分负责规划自车轨迹。这些查询向量通过cross-attention从BEV特征中提取信息，然后各自经过FFN输出结果。这种设计的好处是任务之间可以共享特征，同时保持一定的独立性。

2.3 损失函数：怎么让网络学会开车

端到端网络的损失函数设计是另一个核心难点。模块化时代，每个模块有自己的损失函数：感知用分类损失和回归损失，预测用轨迹误差损失，规划用舒适度和安全性损失。端到端之后，你需要把这些损失整合成一个整体损失，或者设计一个全新的损失函数直接监督最终输出。

最常见的做法是模仿学习：收集人类驾驶数据，把人类的方向盘转角和油门刹车作为标签，让网络学习从传感器输入到控制输出的映射。损失函数就是预测控制和人类控制之间的L1或L2距离。这种方法简单直接，但存在一个根本问题：人类驾驶数据只覆盖了人类认为安全的场景，网络学到的只是人类的平均行为，遇到人类也没见过的极端场景时，网络不知道该怎么处理。

另一种做法是结合规则约束的损失函数。比如在规划输出上加入碰撞惩罚、车道偏离惩罚、舒适度惩罚等，让网络在模仿人类的同时也满足一些硬性约束。这种方法的挑战在于如何平衡不同损失项的权重——碰撞惩罚太大会导致车辆过于保守，舒适度惩罚太大会导致车辆反应迟钝。

提示：损失函数设计没有标准答案，需要根据你的数据特点和场景需求来调整。建议先用纯模仿学习跑通baseline，然后逐步加入规则约束，每次只调整一个损失项的权重，观察路测表现的变化。

我试过的一种有效策略是分阶段训练：第一阶段用纯模仿学习让网络学会基本的驾驶行为，第二阶段加入碰撞和车道偏离惩罚让网络学会规避风险，第三阶段加入舒适度惩罚让驾驶风格更平滑。每个阶段训练完成后都要做充分的路测验证，确保新加入的损失项没有引入意外的行为。

2.4 训练数据：端到端最容易被低估的环节

端到端网络对数据的依赖程度远超模块化架构。模块化架构中，每个模块可以用相对较小的数据集训练，因为任务定义明确，网络只需要学习特定的映射关系。端到端网络需要学习从原始传感器到控制输出的完整映射，这个映射的复杂度极高，需要海量、多样、高质量的数据才能覆盖。

数据量方面，我个人经验是至少需要几十万段驾驶片段才能让端到端网络达到可用的水平。每段片段通常几十秒到几分钟，覆盖不同的道路类型、天气条件、光照条件、交通密度。数据多样性比数据量更重要——一万段高速公路数据不如一千段高速公路加一千段城市道路加一千段乡村道路加一千段停车场。

数据标注是另一个大问题。端到端网络理论上不需要人工标注中间结果，只需要最终的驾驶控制信号。但实际训练中，纯控制信号监督往往不够，网络学得很慢。所以通常需要加入一些辅助监督信号，比如检测框、车道线、可行驶区域等。这些辅助标注的成本很高，但可以显著加速训练收敛。

注意：数据清洗比数据标注更重要。驾驶数据中充满了各种噪声：传感器故障导致的异常帧、驾驶员分心导致的异常操作、标注错误导致的错误标签。这些噪声数据如果不清理，会严重干扰端到端网络的训练。建议在训练前做严格的数据清洗，包括异常帧剔除、驾驶行为平滑、标签一致性检查等。

还有一个容易被忽视的点是数据分布平衡。端到端网络在训练集上的表现往往远好于实际路测，因为训练集的数据分布和实际驾驶的数据分布不一致。比如训练集中直行和缓弯占绝大多数，急弯和紧急避让很少，网络就会偏向于输出直行和缓弯的控制，遇到急弯时反应不足。解决办法是做数据重采样，对稀有场景过采样，或者用数据增强生成更多稀有场景。

3. 实操落地：从零搭建端到端系统的关键步骤

3.1 环境准备与工具链选型

搭建端到端自动驾驶系统，工具链的选择直接影响开发效率和最终效果。深度学习框架方面，PyTorch是目前学术界和工业界的主流选择，动态图机制调试方便，社区生态丰富。TensorFlow在部署端有一定优势，但研究阶段用起来不如PyTorch灵活。我个人的建议是研究阶段用PyTorch，部署阶段根据目标硬件选择对应的推理框架。

数据处理工具链方面，需要一套完整的数据管道：数据采集、数据存储、数据清洗、数据标注、数据增强、数据加载。这套管道通常基于开源工具搭建，比如用ROS做数据采集和同步，用HDF5或LMDB做数据存储，用OpenCV做图像处理，用Albumentations做数据增强。如果团队规模较大，可以考虑用Apache Arrow或Parquet做列式存储，提高数据读取效率。

训练框架方面，单机多卡训练可以用PyTorch的DistributedDataParallel，多机多卡训练可以用Horovod或者PyTorch的RPC框架。端到端网络的参数量通常很大，训练时间以天甚至周为单位，所以分布式训练的效率很关键。我踩过的一个坑是数据加载成为瓶颈——GPU利用率只有30%不到，大部分时间在等数据。后来把数据预处理做成离线完成，训练时只做轻量级增强，GPU利用率才提上去。

仿真环境是另一个重要工具。端到端网络在实车上测试成本高、风险大，所以大部分训练和初步验证都在仿真环境中完成。常用的仿真平台有CARLA、LGSVL等，可以生成各种场景和天气条件，还可以注入其他交通参与者。仿真环境的局限性在于真实感不足，网络在仿真中学到的行为不一定能迁移到实车。所以仿真主要用于算法开发和初步验证，最终还是要上实车测试。

3.2 模型训练：参数配置与调优经验

端到端网络的训练是一个极其耗时的过程，参数配置的合理性直接决定训练能否收敛。以下是我在实际项目中总结的一些关键参数配置经验。

学习率方面，端到端网络通常用较小的初始学习率，比如1e-4到1e-5，配合余弦退火或者阶梯下降。学习率太大会导致训练不稳定，损失震荡；学习率太小会导致收敛太慢，训练时间成倍增加。我通常先用1e-4跑几个epoch观察损失曲线，如果震荡明显就降到5e-5，如果下降太慢就升到2e-4。

批量大小方面，受限于GPU显存，端到端网络的批量大小通常不会太大，比如8到32。批量太小会导致梯度噪声大，训练不稳定；批量太大又放不下。一个折中方案是用梯度累积，在多个小批量上计算梯度再累加，模拟大批量的效果。我试过用梯度累积把有效批量从16提升到64，训练稳定性有明显改善。

优化器方面，Adam和AdamW是端到端训练的主流选择，收敛快且对学习率不敏感。SGD理论上可以找到更好的局部最优解，但训练时间太长，实际项目中很少用。权重衰减通常设1e-4到1e-2，防止过拟合。梯度裁剪是必须的，端到端网络的梯度容易爆炸，通常把梯度范数裁剪到1.0或0.5。

训练轮数方面，端到端网络通常需要几十到上百个epoch才能收敛。判断收敛的标准不是训练损失降到多低，而是验证集损失不再下降。我通常会保留验证集损失最低的checkpoint，而不是最后一个epoch的checkpoint，因为端到端网络很容易过拟合。

提示：端到端训练中，损失曲线的形态比绝对值更重要。健康的损失曲线应该是先快速下降，然后缓慢下降，最后趋于平稳。如果损失曲线出现剧烈震荡或者突然上升，通常是学习率太大或者数据有问题。

3.3 实车部署：从训练到上车的工程挑战

端到端网络在实车上的部署面临几个工程挑战：推理延迟、计算资源、功能安全。

推理延迟方面，端到端网络的参数量通常在几千万到几亿之间，在车载计算平台上推理一次可能需要几十到几百毫秒。对于自动驾驶来说，控制指令的延迟必须控制在100毫秒以内，否则会影响车辆响应。所以模型压缩和加速是必须的，常用的方法有量化（把FP32转成FP16或INT8）、剪枝（去掉不重要的权重）、知识蒸馏（用大模型教小模型）。我试过把模型量化到INT8，推理速度提升3倍，精度损失不到1%，效果很划算。

计算资源方面，车载计算平台的算力通常远小于训练用的GPU集群。所以训练时用的模型规模不能直接搬到车上，需要在训练阶段就考虑部署约束。一个实用的做法是训练时用大模型，部署时用小模型，用小模型去蒸馏大模型的知识。这样可以在有限算力下达到接近大模型的性能。

功能安全方面，端到端网络的黑盒特性给安全验证带来了很大困难。模块化架构中，每个模块可以单独做故障树分析和失效模式分析，端到端网络很难做类似的分解。目前的实践是加入安全监控模块，实时监测网络的输出是否在合理范围内，如果超出范围就切换到备用控制策略。这个安全监控模块通常是基于规则的，不依赖神经网络。

3.4 路测验证：怎么判断端到端系统是否靠谱

路测是端到端系统开发中最关键也最耗时的环节。仿真环境再逼真，也无法完全模拟真实世界的复杂性和不确定性。路测的核心目标是发现网络在哪些场景下表现不好，然后针对性地补充数据和调整模型。

路测的指标体系通常包括：接管次数（每千公里需要人工接管的次数）、碰撞次数、车道保持率、速度控制平顺性、乘坐舒适度等。接管次数是最核心的指标，因为它直接反映了系统处理不了的情况有多少。我个人的经验是，端到端系统在路测初期的接管次数会很高，每几十公里就需要接管一次，随着数据补充和模型迭代，逐渐降到每几百公里一次，最终目标是每几千公里一次。

路测数据的回传和分析是另一个关键环节。每次接管都要记录当时的传感器数据、网络输出、人工接管操作，然后离线分析网络为什么做出了错误的决策。常见的原因有：训练数据中没有类似场景、网络对某些输入过于敏感、损失函数没有正确引导网络行为。针对不同的原因采取不同的改进措施。

注意：路测安全永远是第一位的。端到端系统在路测时必须配备安全员，随时准备接管。安全员需要经过专门培训，了解系统的能力边界和常见失效模式。路测路线要提前规划，避开施工路段、学校区域等高风险场景，等系统成熟后再逐步扩大测试范围。

4. 常见问题与排查技巧实录

4.1 训练不收敛：损失震荡或下降太慢怎么办

训练不收敛是端到端项目中最常见的问题，表现有两种：损失剧烈震荡，或者损失下降极其缓慢。

损失震荡的常见原因包括：学习率太大、批量太小、数据噪声太大、网络初始化不合理。排查顺序应该是先降学习率，通常降一个数量级就能明显改善。如果降学习率后仍然震荡，检查数据中是否有异常样本，比如传感器故障帧或者标注错误帧。如果数据没问题，检查网络初始化，端到端网络的初始化对训练稳定性影响很大，建议用预训练权重初始化骨干网络。

损失下降太慢的原因通常是：学习率太小、网络容量不够、数据量太大但多样性不足、损失函数设计不合理。我遇到过一次损失下降太慢的情况，排查后发现是损失函数中模仿学习项和规则约束项的权重比例不对，规则约束项权重太大，网络花了很多时间在满足规则上，模仿学习的效果很差。调整权重比例后，损失下降速度明显加快。

还有一个容易被忽视的原因是数据加载管道的问题。如果数据加载太慢，GPU经常处于等待状态，训练效率会大幅下降。用nvtop或者nvidia-smi查看GPU利用率，如果低于50%，基本可以确定是数据加载瓶颈。解决办法是把数据预处理做成离线完成，训练时只做轻量级增强，或者用更高效的数据格式（如LMDB）替代原始文件读取。

4.2 过拟合：训练集表现好但路测表现差

过拟合是端到端网络的另一个常见问题。训练集上的损失持续下降，但验证集损失开始上升，路测表现也不如预期。过拟合的根本原因是训练数据的分布不能代表实际驾驶的分布，网络学到了训练集中的特定模式，但这些模式在实际驾驶中不成立。

解决过拟合的方法有几种。增加数据量是最直接的，但驾驶数据的采集和标注成本很高。数据增强是更经济的方法，可以对图像做随机裁剪、旋转、颜色抖动，对轨迹做随机扰动。正则化方法如Dropout、权重衰减、早停也可以缓解过拟合。我个人的经验是，端到端网络的过拟合往往不是单纯的数据量问题，而是数据多样性问题。增加一万段高速公路数据对过拟合的缓解作用，远不如增加一千段城市道路加一千段乡村道路。

另一个容易被忽视的过拟合来源是数据泄露。如果训练集和验证集中有来自同一段驾驶片段的数据，验证集损失会被低估，因为网络已经见过类似的数据。解决办法是按驾驶片段划分训练集和验证集，而不是按帧划分。这个细节看似简单，但很多团队在初期都会犯这个错误。

4.3 实车表现与仿真差异大：域适应问题

仿真环境中表现良好的端到端网络，到了实车上可能表现很差。这种仿真到实车的差异称为域适应问题，根源在于仿真环境的视觉外观、传感器特性、交通行为与真实世界存在差异。

视觉外观差异方面，仿真环境的图像通常过于干净，缺乏真实世界中的噪声、光照变化、天气影响。解决办法是在仿真数据中加入域随机化，随机改变光照、天气、纹理等，让网络学会忽略这些表面差异。另一种方法是风格迁移，把仿真图像转换成真实图像的风格，或者把真实图像转换成仿真图像的风格，缩小两个域之间的差距。

传感器特性差异方面，仿真中的摄像头和激光雷达通常是理想模型，没有噪声和畸变。真实传感器有镜头畸变、运动模糊、点云噪声等。解决办法是在仿真数据中加入传感器噪声模型，模拟真实传感器的特性。这个噪声模型的参数需要根据实际传感器的标定结果来设置。

交通行为差异方面，仿真中的其他车辆通常按照规则行驶，而真实世界中的驾驶行为更加多样和不可预测。解决办法是在仿真中引入随机化的交通行为，让其他车辆做出各种不规则的驾驶动作。但这又带来了新的问题：仿真中的随机行为可能过于极端，网络学到的应对策略在真实世界中不适用。

4.4 常见问题速查表

提示：这张表是我在实际项目中反复踩坑后总结的，但每个项目的情况不同，具体问题的根因可能不一样。建议把这张表作为排查的起点，而不是终点。遇到问题时，先收集足够的数据和日志，再做判断，不要凭直觉瞎调参数。

4.5 几个容易被忽视的实操细节

第一个细节是随机种子的固定。端到端网络的训练对随机种子很敏感，不同的随机种子可能导致完全不同的训练结果。所以在对比不同模型或不同参数时，一定要固定随机种子，否则对比结果没有意义。我通常会在代码里固定Python、NumPy、PyTorch的随机种子，并在实验记录中注明。

第二个细节是checkpoint的保存策略。端到端网络训练时间长，中间checkpoint很重要。我通常会保存三种checkpoint：最新的、验证集损失最低的、每隔一定epoch的。最新的用于恢复训练，验证集损失最低的用于最终部署，每隔一定epoch的用于分析训练过程中的变化。

第三个细节是日志记录的完整性。端到端网络的调试难度大，需要详细的日志来定位问题。我通常会记录每个epoch的训练损失、验证损失、学习率、梯度范数，以及每个损失项的单独数值。路测时还会记录每次接管的传感器数据、网络输出、人工操作。这些日志在排查问题时非常有用。

第四个细节是版本管理。端到端项目涉及数据、代码、模型、配置多个版本，管理不善很容易混乱。我建议用DVC管理数据版本，用Git管理代码和配置版本，用MLflow或Weights & Biases管理实验记录。每次路测都要记录对应的数据版本、代码版本、模型版本，确保结果可复现。

5. 端到端算法的未来方向与个人思考

5.1 从模仿学习到强化学习：端到端的下一个台阶

目前端到端算法的主流训练范式是模仿学习，网络学习人类驾驶数据中的输入输出映射。模仿学习的局限性在于它只能学到人类演示过的行为，对于人类也没有遇到过的极端场景，网络不知道该怎么处理。强化学习提供了一种可能性：让网络在仿真环境中通过试错来学习驾驶策略，不依赖人类演示数据。

强化学习在端到端驾驶中的应用还处于早期阶段，面临几个挑战。一是仿真环境的真实感不足，网络在仿真中学到的策略迁移到实车效果打折。二是奖励函数设计困难，驾驶的目标是多维的（安全、高效、舒适、合规），如何把这些目标整合成一个奖励函数是个难题。三是训练效率低，强化学习需要大量的交互数据，仿真环境的运行速度限制了训练规模。

但我个人认为强化学习是端到端算法的必然方向。模仿学习让网络学会了“像人一样开车”，强化学习可以让网络学会“比人开得更好”。特别是在极端场景下，强化学习可以通过大规模仿真训练出超越人类的应对策略。目前已经有团队在探索用强化学习做端到端规划，初步结果令人鼓舞。

5.2 世界模型：让端到端网络学会预测未来

世界模型是另一个值得关注的方向。端到端网络目前主要是反应式的：看到当前帧，输出当前控制。但驾驶决策需要考虑未来，比如变道时需要预测目标车道的车辆是否会加速，转弯时需要预测对向车辆是否会让行。世界模型让网络学会预测未来的场景演变，从而做出更前瞻的决策。

世界模型的核心是学习环境的动态规律：给定当前状态和动作，预测下一时刻的状态。在驾驶场景中，状态包括自车位置、速度、周围车辆位置、交通信号等，动作包括转向、加速、刹车。世界模型可以用视频预测的方式实现，也可以用隐空间动力学模型实现。有了世界模型，端到端网络可以在隐空间中进行规划，想象不同动作会导致的未来状态，然后选择最优动作。

这个方向目前还在研究阶段，但已经有一些令人兴奋的进展。世界模型的一个关键优势是它可以无监督训练，不需要人工标注，只需要大量的驾驶视频。这意味着可以利用互联网上公开的行车记录仪视频来训练世界模型，数据成本大幅降低。

5.3 可解释性与安全验证：端到端落地的最后一道坎

端到端算法要真正落地，可解释性和安全验证是绕不过去的坎。目前的端到端网络是一个黑盒，输入传感器数据，输出控制指令，中间发生了什么很难说清楚。这在功能安全认证中是个大问题，因为无法证明网络在所有情况下都会做出安全决策。

可解释性的研究方向包括：注意力可视化（看网络关注了输入中的哪些区域）、概念激活向量（看网络学到了哪些人类可理解的概念）、反事实解释（看如果输入改变网络输出会怎么变）。这些方法可以帮助工程师理解网络的行为，但距离完全可解释还有很大距离。

安全验证方面，目前的做法是“黑盒测试加安全监控”：在大量场景中测试网络的表现，统计失效概率；同时加入基于规则的安全监控模块，在网络输出异常时接管控制。这种方法不能保证绝对安全，但可以在工程上把风险降到可接受的水平。未来可能需要新的数学工具来形式化验证神经网络的输出边界，但这还是一个开放的研究问题。

我个人在实际项目中的体会是，端到端算法的工程落地比学术研究复杂得多。学术论文关注的是在标准数据集上的性能指标，工程落地关注的是在真实道路上的安全性和可靠性。两者之间的差距需要大量的工程工作来填补，包括数据管道、训练框架、部署工具、测试验证等。如果你正在考虑进入这个方向，我的建议是先从部分端到端开始，积累数据和工程经验，再逐步扩大端到端的范围。不要一上来就追求完全端到端，那样很容易在工程细节上翻车。

最后分享一个小技巧：端到端网络的训练中，验证集的设计比训练集更重要。训练集可以大而全，但验证集必须精心设计，覆盖你关心的所有场景类型。我通常会把验证集分成几个子集：高速公路、城市道路、乡村道路、停车场、恶劣天气等，分别评估网络在每个子集上的表现。这样可以清楚地看到网络在哪些场景下表现好，哪些场景下需要改进。这个做法比只看一个整体的验证损失有用得多。