飞机先生唠唠｜到底该不该去高精地图？_话题文章

飞机先生

原创话题文章

日榜 TOP{{detailStore.day_rank}}

月榜 TOP{{detailStore.week_rank}}

飞机先生唠唠｜到底该不该去高精地图？

新出行原创 · 精品文章

智能驾驶，该不该去高精地图呢？

当我们讨论无图化的时候，其实更多讨论的是去高精地图，而不是去地图本身。

高精地图就像一个给火车铺设的轨道，我们只要沿着轨道就能到达目的。
地图更多是提供指引，比如我们开车听到的“前方两百米右转”，我们还是需要自行完成行车规划。

现如今大家对无图的边界，是寻找一张感知系统“能自己画”（认知）同时也“能看得懂”（感知）的地图，它不需要高精地图的高精信息与绘制流程，但也需要具备一定的数据信息。Harry Wong 把它定义为 “智能驾驶增强数据地图” ，非常认同。

高精地图该不该“去”

当一个功能开始涌现的时候，我们这时候该讨论的就不再是功能本身了，我们还需要看功能背后的商业模式或者运营形式。

高精地图自有三种特性，需要具备资质、具备高精度、具备高频的更新率。当这三个属性单纯放在智能驾驶功能上，无疑非常好用。

这就像你遮着眼睛，高精地图牵着你走。

而且前面如果有坑，地图还会跟你说，“诶，5米后，我说一二三你就跳哈。”

高精地图怎么会不好用呢？

但去高精地图化不是功能本身出问题，而是这背后的运营模式。

高精地图的制作顺序一般是：

图商投人、投钱先做一遍采图
车企买图
车企开始用自己车队先验证图
最后交付用户

特殊的点在于，验证完地图交付用户后，高精地图的能力才刚刚开始，而不是一个产品周期的结束，同时高精地图的成本也在增加。

这时候运营顺序开始变化：

各地的用户率先发现道路更新反馈
车企收到问题后开始交给图商
图商开始头疼，因为它服务维护的车企也不是只有一家，bug 反馈也越来越多

所以当一份高精地图最好用的时候是刚刚交付的时候。同时伴随着的是它的成本不断增加、无法跟上用户体验的更新频率，车企解决部分 bug 有时候也只能通过降级，用户体验也会越来越差。

是谁带来了无图化？

但无图化思路的提起，并不是因为大家看清了这种矛盾关系，其实是得益于 BEV 大模型网络和大计算平台的发展。

所以我们需要解决两个容易混淆的问题：

到底什么是 BEV 大模型？
为什么以前 BEV 不可以取代高精地图，现在却可以？

BEV 也就是 Bird's Eye View（鸟瞰视角）的简称，所以字面意思非常容易理解，就是上帝视角。背后的技术是将传感器的信息转换为一个统一的俯视视角。

那为什么以前 BEV 不可以取代高精地图，现在却可以？

BEV 原理并不复杂，它也不是一个新的技术，只是给了系统一个看世界的角度，实际上是新的算法赋予了新的生命力。

BEV 会历经两个阶段：

第一阶段就是先通过 2D 图像中目标检测，然后再通过摄像头投射到 3D 视角里。它利用上帝视角解决了空间检测的问题，但难以泛化、难以训练。

第二阶段开始先直接在 BEV 初始化特征形成 3D 空间，结合 transformer 将图像信息特征化。通过融合更多传感器，比如激光雷达、毫米波等一起融合，通过一个新的网络编码后再投入到 BEV 。

这时候 BEV 带来了几个核心的变化，它的精度变高、变得可训练可泛化、场景也变得可理解，也就是一个完整的端到端的感知大模型。

BEV 算法通过在环境提取特征，并且把不同传感器的特征映射到统一的坐标系里，在做融合后在做相应的学习分类。而 transformer 给感知带来了一个更大的视野，它不再像传统神经网络一样机械化的流水线处理，transformer 擅长挖掘不同元素之间的相关信息。

系统可以直接获得多传感器融合后的 3D 空间信息，利用一个网络直接输出感知结果，更为关键的是如果在这个基础上我们加入了时间序列，也就是给传感器加入了时间流，这时候我们就可以获得一个完整的具备前后时间线的感知架构。

这时候系统开始：

多传感器能够融合并且在统一视角内表达；
具备推理、预测能力；
成为一个端到端的能力，能够开始积累数据、具备泛化能力（满足不同车型、不同平台）；
构建语义地图，逐步取代高精地图。

所以 BEV + transformer 开始用一个端到端的大模型来取代过去基于大量人工、无法泛化的 2D 时代，让它的架构变得更加简洁，同时大家可以基于这个新的框架积累更多的数据，形成所谓的端到端闭环。

BEV 就像是一个提供全局视角，transformer 开始基于全局思路找到相对应的词组关系，最后形成一句环境相应的“句子”给到下游规划， transformer 和 BEV 做了结合之后大大提升了感知的性能。

所以 BEV 只是一个结果，怎么用好它，才是这几年技术变革的关键。

无图化有哪些“难”

上面可以和大家聊到 BEV + transformer 解决了空间问题，在这基础上如果我们加入时间序列，就可以得到类似视频流的体验。

这就像我们过去基于图片的视角去收藏、回忆，如今我们以电影的形式呈现，开始加入了故事线，有前因后果的关系，这在自动驾驶中让系统去场景理解一样重要。

有了结合前后时间的关系，更多的场景能够被理解，例如道路与道路、路口之间的逻辑关系，也可以对动态目标做未来轨迹预测。

这时候我们既掌握了动态目标的检测与预测，同时对道路的表达形式也开始变化，开始对环境具有逻辑感知能力，这也给无图的思路提供了可能。

所以利用 BEV 所生成的语义地图，也就是无图化会有两个重点：

第一个通过车端的算法，能不能重构成系统可用的地理信息变得非常关键。

第二目前的通勤模式以及无高精地图化的城市级 NOA ，其中的地图是两个概念，前者是局部地图，后者是全局地图，这两者在采集难度、监管问题上都存在不同。

同时衡量一个系统能力也开始有所变化：

第一是感知变成一个端到端的工具，不再是基于规则类算法，它可以直接输出 3D 检测、车道逻辑关系、车辆预测甚至是占用网络。但也因为它成为一个端到端的系统，就更需要一套成熟的数据驱动系统。

如何低成本获得数据，同时如何给大量“没有规律”的数据做好自动标注，将自动化的能力完成可持续的迭代训练，满足长期的持续迭代能力。

第二是 BEV + transformer 不仅只是网络算法的升级，它对硬件芯片、传感器、数据闭环能力都有新的要求。比如当 transformer 模型越来越大时这时候对芯片有效算力、功耗、带宽需要也更大。

第三是激光雷达的必要性。激光雷达和实现 BEV 没有必然联系。但激光雷达提供一个原生的 3D 视角空间，所以激光雷达本身可以作为一个天然的 3D 特征，能够容易做对齐，更为准确稳定。同时也能给训练数据不足时候提供一个补充。如果我们的模型有了数据量支撑，可以接近激光雷达的精度，激光雷达的必要性相应就会变低。