1. 被误读的“无图化”一场关于自动驾驶底层逻辑的认知纠偏“无图化”这个词在过去两年里被反复提及几乎成了智能驾驶行业的流量密码。但凡哪家车企或方案商发布新版本智驾系统如果不提一句“我们实现了无图化”就好像技术落后了一个时代。但我在跟多位一线感知工程师、规控算法工程师以及做空间数据标注的朋友深聊之后发现一个很尴尬的事实大多数人对“无图化”的理解从根子上就跑偏了。有人以为无图化就是车端把高精地图模块删掉靠几个摄像头和雷达就能跑遍全国有人觉得无图化意味着图商要完蛋高精地图采集车可以全部报废还有人把无图化和“端到端”混为一谈觉得只要上了大模型地图就是累赘。这些说法不能说全错但都只摸到了大象的一条腿。我写这篇东西的目的很简单把“无图化”这件事从营销话术里捞出来放回工程现实的地面上讲清楚它到底在解决什么问题、技术上是怎么演进的、车端和云端各自承担了什么角色、以及为什么我说“无图化”这个叫法本身就是一种误读。如果你是从业者这篇能帮你理清技术脉络如果你是刚入行的新人这篇能帮你避开那些听起来很酷但经不起推敲的概念陷阱。2. 拆解“无图化”的真实含义不是不要图而是换了一种用图的方式2.1 高精地图的黄金时代与它的死穴要理解无图化得先知道有图时代是怎么玩的。大概在2016到2020年那几年高精地图是自动驾驶的标配。那时候做L4的公司谁手里没几张高精地图都不好意思跟投资人讲故事。高精地图的精度可以做到厘米级路上每一条车道线、每一个路沿、每一根电线杆、每一个红绿灯的位置和高度都被提前采集好做成一个先验知识库塞进车里。车开在路上感知系统只需要做“定位比对”把实时看到的和地图里存的做匹配就能知道自己在哪、前面是什么。这套逻辑在高速和城市快速路上跑得挺顺因为道路结构相对固定采集一次能用很久。但问题很快就暴露了。高精地图的更新速度跟不上现实世界的变化。今天这条路在施工明天那个路口改了标线后天又新开了一个匝道地图如果没及时更新车就会做出错误决策。更麻烦的是成本采集一辆高精地图车的硬件成本动辄上百万覆盖一个城市需要几个月全国铺开就是个无底洞。而且不同图商的数据格式还不统一车企换一个供应商就得重新适配一遍。我认识一个做地图采集的朋友他跟我说过一句话让我印象很深“我们辛辛苦苦采了三个月的路结果市政一施工全废了。”这就是高精地图的死穴——它试图用静态数据去描述一个动态世界本质上是个不可能完成的任务。2.2 “无图化”到底去掉了什么现在说无图化很多人第一反应是“把地图删了”。但如果你去问真正做无图方案的工程师他们会告诉你去掉的不是地图本身而是对高精地图的强依赖。具体来说去掉了三个东西。第一去掉了对厘米级先验数据的依赖。以前的系统如果没有高精地图连自己在哪条车道都判断不了。现在的方案靠车端感知实时构建局部空间关系结合导航地图的粗粒度信息就能完成定位和决策。第二去掉了对地图鲜度的苛刻要求。导航地图可能一个季度更新一次但车端感知是每时每刻都在工作的。路变了车能看到不需要等地图更新。第三去掉了对特定图商的绑定。以前车企得跟图商深度合作数据格式、接口协议都得定制。现在用标准导航地图加自研感知灵活性高了很多。但注意导航地图还在用。无图化不是把地图彻底扔掉而是把地图从“核心决策依据”降级为“辅助参考信息”。这个区别非常关键后面我会展开讲。2.3 为什么说“无图化”这个叫法本身就是误读我之所以说“无图化”是误读是因为它把一件复杂的系统工程简化成了一个非黑即白的口号。真实情况是图没有消失只是从车端前装的高精地图转移到了云端的数据闭环和车端的实时感知里。你可以这样理解以前是“地图告诉我前面有什么”现在是“我自己看到前面有什么同时云端告诉我其他车看到过什么”。地图的角色从“剧本”变成了“参考资料”从“必须遵守”变成了“可以参考”。而且无图化方案对空间数据的需求不是减少了而是换了一种形式。以前需要的是结构化高精地图现在需要的是海量的、多模态的、带时空标签的感知数据。这些数据用来训练模型、做仿真、做验证本质上还是在“用图”只不过这个“图”是动态的、分布式的、由车队实时贡献的。所以我在跟团队内部沟通时从来不说“无图化”而是说“轻图化重感知云端数据闭环”。这个表述更准确也更能指导工程实践。3. 无图化背后的技术栈从感知到规控的全链路重构3.1 车端感知从“比对地图”到“理解世界”有图时代感知系统的压力其实没那么大。因为地图已经告诉你前面是直道还是弯道、有没有红绿灯、车道线在哪感知只需要做验证和补充。但无图化之后感知系统得从零开始理解周围环境这就对算法提出了完全不同的要求。首先是在线建图能力。车端需要实时构建一个局部语义地图包括车道线、路沿、交通标志、路口拓扑关系等。这个局部地图的精度不需要达到厘米级但必须足够稳定和一致。我见过一些方案单帧感知看起来没问题但连续多帧之后车道线就飘了导致规控模块无所适从。其次是多模态融合。纯视觉方案在逆光、大雨、夜间等场景下容易失效所以现在主流的无图方案都是视觉毫米波雷达激光雷达的融合。但融合不是简单地把数据堆在一起而是要在特征层面做对齐和互补。比如视觉擅长识别语义雷达擅长测距和测速激光雷达擅长构建三维结构三者怎么加权、怎么仲裁是个非常考验工程能力的事情。第三是时序一致性。车是在运动的感知系统必须保证前后帧之间的空间关系是连贯的。我踩过的一个坑是在路口转弯时由于视角变化剧烈感知模块输出的车道线出现了跳变导致规控模块误判为车道变更差点引发危险。后来我们引入了时序滤波和滑窗优化才把这个问题压下去。3.2 规控模块从“循迹”到“博弈”有图时代规控模块的工作相对简单地图告诉你车道线在哪你就沿着车道线走地图告诉你前面有路口你就减速观察。但无图化之后规控模块得自己判断“哪里是车道”“能不能变道”“要不要让行”。这就引入了博弈问题。在没有高精地图先验的情况下车必须像人一样通过观察其他交通参与者的行为来推断意图。比如前面那辆车突然减速是因为要转弯还是因为堵车旁边那辆车打转向灯了它是真的要变道还是只是忘了关灯这些问题在有图时代可以通过地图信息辅助判断现在只能靠感知和预测。我参与过的一个项目里规控团队和感知团队吵得最凶的就是责任边界。感知说“我只能告诉你那里有个障碍物它要干嘛我不知道”规控说“你不告诉我它要干嘛我怎么决策”。后来我们达成了一个共识感知输出的是“物理属性”位置、速度、朝向预测模块输出的是“意图属性”可能的行为规控模块综合两者做决策。这个分工看起来简单但实际落地时接口定义、置信度传递、异常处理都花了大量时间打磨。3.3 云端数据闭环无图化的隐形支柱很多人聊无图化只聊车端忽略了云端。但在我看来没有云端数据闭环的无图化就是耍流氓。为什么这么说车端感知再强也有它没见过的东西。比如一个从未出现过的异形障碍物、一种特殊的交通标志、一段临时改道的施工区域。这些长尾场景如果只靠车端模型很难保证不出问题。云端的作用就是把这些场景收集起来标注、训练、验证然后通过OTA推送到车端。这就涉及到一个关键概念空间数据。无图化方案需要的不再是传统的高精地图数据而是带有空间标签的感知数据。每一帧数据都要记录车辆的位置、姿态、周围环境的三维结构这样才能在云端重建出可复现的仿真场景。我见过一些团队车端跑得挺好但数据回传之后发现没有空间对齐信息根本没法用来训练这就是前期设计没做好。另外云端还承担着地图要素的动态更新。虽然无图化不依赖高精地图但导航地图的粗粒度信息还是需要的。如果某条路改了单行道、新增了红绿灯云端可以通过车队数据感知到变化然后更新导航地图。这个过程不需要厘米级精度但需要及时性和覆盖面。4. 实操中的关键环节从数据采集到模型部署的完整链路4.1 数据采集怎么采、采什么、采多少无图化方案的数据采集跟有图时代完全不同。有图时代主要采集道路几何和标牌信息无图时代需要采集的是全要素感知数据。具体来说一辆数据采集车需要配备前视广角摄像头、侧视摄像头、后视摄像头、激光雷达、毫米波雷达、高精度组合导航系统。采集的内容包括原始图像、点云、雷达目标、车辆位姿、时间戳。这些数据要严格同步时间对齐误差不能超过几毫秒否则后续融合会出问题。采多少我的经验是覆盖一个城市的核心区域至少需要十万公里级别的有效数据。注意是“有效数据”不是随便跑跑就算。有效数据的要求是场景多样白天/夜间/雨天/雾天、交通参与者的行为丰富加塞/cut-in/鬼探头、道路结构完整直道/弯道/路口/环岛。我见过一些团队为了凑里程在同一个区域反复跑结果数据同质化严重训练出来的模型泛化能力很差。还有一个坑是数据标注。无图化方案对标注的要求比有图时代高得多。以前只需要标注车道线和标牌现在需要标注所有交通参与者、可行驶区域、路沿、甚至路面上的坑洼。标注成本占整个项目预算的比例从以前的10%左右涨到了30%以上。我建议在项目初期就建立标注规范和质检流程否则后期返工的成本会让你怀疑人生。4.2 模型训练从单任务到多任务联合无图化方案的感知模型通常是多任务联合训练的。一个骨干网络同时输出车道线、可行驶区域、障碍物、交通标志等多个任务的结果。这样做的好处是共享特征提取减少计算量但难点在于任务之间的冲突。比如车道线检测需要关注细长的结构障碍物检测需要关注块状区域两者的感受野和特征偏好不一样。如果简单地把损失函数加起来可能会出现一个任务涨点另一个任务掉点的情况。我们的做法是动态调整损失权重在训练过程中根据各任务的收敛情况自动平衡。另外任务之间的一致性约束也很重要比如车道线和可行驶区域不能矛盾障碍物不能出现在可行驶区域之外。训练数据的管理也是个大学问。无图化方案的数据量通常是TB级别的怎么存储、怎么索引、怎么采样都需要专门设计。我们用的是分层采样策略先按场景类型分层高速/城区/泊车再按难度分层简单/中等/困难最后按时间分层确保时序多样性。这样训练出来的模型在各个场景下的表现比较均衡。4.3 仿真验证无图化方案的试金石无图化方案在上车之前必须经过大量的仿真验证。因为实车测试的成本太高而且很多危险场景没法在现实中复现。仿真的核心是场景重建也就是把采集到的空间数据还原成可交互的虚拟环境。这里有个关键点仿真的保真度。如果仿真环境跟现实差距太大验证结果就没有意义。我们通常从三个维度评估保真度几何保真度道路结构、障碍物位置是否准确、视觉保真度图像纹理、光照条件是否真实、行为保真度其他交通参与者的行为是否合理。几何保真度靠空间数据保证视觉保真度靠渲染技术行为保真度靠行为模型。我踩过的一个坑是仿真里跑得好好的场景实车一跑就出问题。后来排查发现是仿真里的传感器模型太理想化了没有模拟噪声和遮挡。后来我们在仿真里加入了传感器噪声模型和遮挡模型才把仿真和实车的差距缩小到可接受的范围内。4.4 部署与OTA从实验室到量产的最后一步模型训练好了怎么部署到车端这里涉及模型压缩和推理优化。车端的算力是有限的通常只有几十到几百TOPS而训练时的模型可能有好几亿参数。我们常用的手段包括剪枝去掉不重要的连接、量化把浮点运算转成定点运算、知识蒸馏用大模型教小模型。这些手段各有利弊剪枝可能损失精度量化可能引入误差蒸馏需要额外的训练成本。我的经验是先量化再剪枝最后用蒸馏微调这样能在精度和速度之间取得比较好的平衡。OTA升级也是个容易出问题的环节。无图化方案的模型更新频率比较高可能每个月甚至每周都要推新版本。如果OTA失败车端可能处于不可用状态。我们的做法是双分区备份灰度发布。新版本先推给1%的用户观察一周没问题再逐步扩大范围。同时保留旧版本分区一旦新版本出问题可以快速回滚。5. 常见问题与排查技巧实录5.1 感知层面的典型问题问题一车道线在路口区域丢失这是无图化方案最常见的问题之一。路口没有明确的车道线感知模块容易输出混乱的结果。排查思路检查路口区域的训练数据是否充足是否覆盖了各种路口形态十字、丁字、环形、异形。解决方法在路口区域引入虚拟车道线根据对向车道和路口拓扑推断出合理的行驶轨迹。问题二逆光/夜间场景下感知性能下降纯视觉方案在极端光照条件下容易失效。排查思路分析失效场景的光照条件检查训练数据中是否包含足够的逆光/夜间样本。解决方法增加红外摄像头或毫米波雷达的权重在视觉置信度低时切换到雷达主导的感知模式。问题三异形障碍物漏检无图化方案对未知障碍物的检测能力有限。排查思路收集漏检场景的数据分析障碍物的特征尺寸、材质、运动状态。解决方法引入开集检测能力让模型能够识别“未知障碍物”并输出低置信度告警而不是直接忽略。5.2 规控层面的典型问题问题一频繁的急刹和点刹这通常是因为感知输出的障碍物位置抖动导致规控模块误判为危险。排查思路检查感知输出的时序一致性分析障碍物位置的方差。解决方法在规控输入端加入滤波和迟滞对小幅度的位置变化不敏感对持续的变化才做出反应。问题二变道决策过于保守或激进这跟规控模块的博弈策略有关。排查思路分析变道场景下的决策日志看看是感知误判还是策略参数不合理。解决方法调整博弈权重在安全性和通行效率之间找到平衡点。我的经验是城区场景偏保守高速场景偏激进泊车场景最保守。问题三路口通行效率低无图化方案在路口往往过于谨慎导致通行效率下降。排查思路分析路口场景下的决策延迟看看是感知处理慢还是规控犹豫。解决方法引入路口通行意图预测提前判断其他车辆的动向减少决策等待时间。5.3 数据闭环层面的典型问题问题一数据回传失败或丢失这通常是网络或存储问题。排查思路检查车端存储空间、网络连接状态、回传策略。解决方法采用断点续传和优先级队列确保关键数据优先回传。问题二标注质量不稳定标注质量直接影响模型训练效果。排查思路建立标注质检流程定期抽查标注结果。解决方法采用多轮标注交叉验证对争议样本进行专家仲裁。问题三模型更新后性能回退新模型在某些场景下不如旧模型。排查思路对比新旧模型在验证集上的表现找出回退的场景类型。解决方法采用模型集成或场景自适应切换在不同场景下使用不同的模型版本。问题类型典型表现排查思路解决方法感知丢失车道线在路口消失检查路口训练数据引入虚拟车道线感知失效逆光下性能下降分析光照条件多模态融合加权感知漏检异形障碍物未识别收集漏检场景开集检测能力规控抖动频繁急刹检查时序一致性滤波和迟滞规控保守变道犹豫分析决策日志调整博弈权重数据丢失回传失败检查网络和存储断点续传标注不稳质量波动建立质检流程多轮标注仲裁模型回退新版本变差对比验证集模型集成6. 具身智能与空间数据无图化技术的延伸思考6.1 从自动驾驶到具身智能的技术迁移最近“具身智能”这个词很火xbotics 具身智能开源社区里也有很多讨论。我观察到一个有趣的现象无图化方案里积累的很多技术正在被迁移到具身智能领域。比如具身智能机械臂在抓取物体时也需要实时构建周围环境的空间关系。它不能依赖预先扫描好的三维模型因为物体可能被移动、遮挡、或者根本没见过。这跟无图化方案里“在线建图实时感知”的思路是一脉相承的。再比如具身智能学习路线里强调的“仿真到现实”迁移跟自动驾驶的仿真验证逻辑也很像。都是在虚拟环境里训练然后迁移到物理世界。区别在于自动驾驶的仿真场景是道路具身智能的仿真场景是桌面或房间。6.2 空间数据物理世界编译器的燃料“物理世界编译器”这个概念最近被提得很多。我的理解是它是一套把物理世界的感知数据转化为可计算、可推理、可决策的结构化信息的系统。自动驾驶是无图化方案是物理世界编译器的一个典型应用具身智能是另一个。空间数据在这个系统里扮演的角色就像是编译器的输入源代码。没有高质量的空间数据编译器就编译不出正确的“物理世界程序”。这也是为什么我一直强调无图化不是不要数据而是需要更高质量、更多模态、更带时空标签的数据。欧卡2自动驾驶这类模拟游戏其实也在产生大量的空间数据。虽然游戏场景是虚拟的但里面的道路结构、交通规则、车辆动力学模型都可以用来训练和验证自动驾驶算法。我认识一些团队就是用游戏引擎做仿真环境成本比真实采集低得多效果也不错。6.3 自动驾驶数据集的新要求传统的自动驾驶数据集如KITTI、nuScenes主要是为有图时代设计的标注内容以车道线和障碍物为主。无图化方案需要的数据集要求更高全要素标注不仅标注车道线和障碍物还要标注可行驶区域、路沿、交通标志、路面标线等。时序一致性连续帧之间的标注必须保持一致不能出现跳变。空间对齐每一帧数据都要有精确的位姿信息方便在云端重建三维场景。场景多样性覆盖各种天气、光照、交通状况确保模型泛化能力。我建议在做无图化项目时尽早建立自己的数据集规范不要直接套用公开数据集的标准。因为公开数据集的目标和你的项目目标可能不一致强行套用会导致后期返工。7. 我踩过的坑与实操心得7.1 不要低估数据标注的复杂度我刚开始做无图化项目时以为标注就是画框框。结果发现无图化方案需要的标注类型比有图时代多得多而且标注规范很难统一。比如“可行驶区域”的边界怎么定义路沿算不算可行驶区域施工区域的临时标线怎么标注这些问题如果没有提前定义清楚标注团队会给出五花八门的结果。我的建议是在项目启动前花两周时间专门做标注规范。找几个典型场景让标注团队试标然后一起讨论争议点形成文档。这个前期投入绝对值得。7.2 仿真和实车的差距比想象中大我们曾经在仿真里跑了一个月各项指标都很漂亮。结果实车一跑发现完全不是那么回事。后来分析发现仿真里的传感器模型太理想化了没有考虑镜头畸变、雷达噪声、激光雷达的反射率问题。后来我们在仿真里加入了传感器误差模型才把差距缩小。我的经验是仿真验证通过只是及格线实车测试才是真正的考试。不要把仿真结果当成最终结论一定要留出足够的时间做实车验证。7.3 云端数据闭环的优先级要提前定无图化方案的数据回传量非常大如果所有数据都回传带宽和存储成本会爆炸。我们的做法是按优先级回传。高优先级数据包括接管场景、危险场景、新场景中优先级数据包括常规场景但标注质量高的低优先级数据包括重复场景、简单场景。这个优先级策略要在项目初期就定好并且写到车端的数据回传逻辑里。否则后期数据量上来之后再想调整就很麻烦。7.4 模型更新要留回滚余地我们有一次推了一个新模型结果在某些场景下性能下降。幸好我们保留了旧版本分区及时回滚了。从那以后我们规定任何模型更新都必须保留至少一个旧版本并且灰度发布周期不少于两周。另外模型更新的评估指标不能只看平均值要看最差场景的表现。平均值好看但某些场景崩了这种模型不能上。7.5 团队协作比技术本身更重要无图化方案涉及感知、规控、数据、仿真、部署等多个团队协作成本非常高。我见过很多项目技术方案没问题但团队之间接口定义不清、责任边界模糊导致进度一拖再拖。我的建议是在项目初期就明确各团队的接口和责任并且用文档固化下来。每周开一次跨团队对齐会及时解决接口问题。另外建立统一的日志和监控体系让问题可以快速定位到具体团队。8. 关于无图化的一些个人判断我在这个行业待了这么多年见过太多概念被捧上天又被摔下地。无图化不是第一个也不会是最后一个。我的判断是无图化是一个阶段性方案不是终极方案。为什么这么说因为无图化解决的是“高精地图更新慢、成本高”的问题但它自己也带来了新问题车端感知压力大、云端数据闭环复杂、长尾场景处理难。未来可能会出现新的方案比如“轻图化车路协同”或者“端到端世界模型”把无图化的优点保留缺点用其他技术补上。但不管技术怎么演进有一个原则是不变的安全永远是第一位的。无图化方案再酷如果不能在各种场景下保证安全就没有量产的价值。我见过一些团队为了追求“无图化”的标签把安全冗余砍得太狠结果实车测试时频繁接管最后不得不回退到有图方案。这种教训值得所有人警惕。最后分享一个小技巧如果你在做无图化方案的评估不要只看“无图化率”这个指标。要问清楚无图化之后哪些场景的性能下降了下降了多少有没有补偿措施这些问题比一个简单的百分比有意义得多。