编辑 | 苏清涛
真正影响 Mapless 技术路线落地的最大难点在于规控——大多数公司的规控方案基于高精地图，容不得一丝差距。
本文所涉及的内容，有一部分来自笔者在 4 月份的上海车展期间的一系列观察与思考，其余部分来自笔者在车展前后这两个多月参加个别企业的发布会以及跟数十位在自动驾驶产业一线的朋友一对一交流后的收获。
严格地说，这并不能算作是一篇正儿八经的「文章」，而是对一些碎片化观察与思考的「东拼西凑」。
本文涉及的话题主要有：
一、芯片公司需要向算法公司「反向支付」开发费
二、地平线 J3 不能做行泊一体？
三、大模型：在自动驾驶车端场景的应用尚存在争议
四、 舱驾一体面临的挑战
五、 「要不要跟地平线合作？」「早合作早受益。」
六、从「轻高精地图」到「去高精地图」
七、感知算法训练或将受到数据合规政策的影响
八、「中国研发，德国应用」
芯片公司需要向算法公司「反向支付」开发费
通常来说，算法公司在向芯片厂商寻求支持时，需要支付一部分开发费；但现在还有一种现象：那些入局比晚的芯片厂商在跟算法谈合作时，非但不能向后者收取开发费，反而很容易遭遇后者的高姿态，「我们的资源有限，暂时不会基于新的芯片平台做开发，除非你们愿意支付开发费。」
在研发预算被削减的主机厂那里，也存在同样的现象。
由此延伸出的一个话题是：现阶段，主机厂对芯片、激光雷达是否要采取「AB 供模式，跟主机厂的研发资源、研发部门和采购部门之间话语权的力量对比有很大关系——采购有动力追求平衡，他们一定希望有「B 供」；但研发部门会对抗，如果研发资源不够，并且，研发的话语权确实很大的话，他们就不希望引入「B 供」。
地平线 J3 不能做行泊一体？
「地平线 J3 的 GPU 比较弱，图像渲染表现不佳，因而，不能单独用来做行泊一体，需要搭配 TDA 4 才可以。」去年上半年，多家算法公司在跟九章智驾的交流中都提到了这一点。
不过，去年年底到今年年初，福瑞泰克和宏景智驾两家公司却先后宣布用单 J3 行泊一体了。这里面有何玄机呢？在这次上海车展期间，九章智驾向宏景智驾联合创始人兼软件算法副总裁董健博士提出了这个问题，对此，董健博士的回答是：
我们遇到的客户，基本上没有人吐槽过 J3「不能做行泊一体」，因为大家普遍都是通过座舱域里的 GPU 来做图像渲染，「把环视的图像数据一分为二，一路传到 J3 里面，另一路传到座舱中的 GPU 里」。
实际上，在开启行车功能的时候，你是不太会泊车的，而在开启泊车功能的时候，你也不在行车场景中，所以，我们就利用这个特质，对座舱域的 GPU 算力做了一个分时复用，即在行车的时候会把环视关掉，到泊车的时候再打开。
对此，宏景智驾 CEO 刘飞龙博士补充道：
在很多车型中，座舱系统的渲染能力是非常好的，并且算力是过剩的，很容易被浪费，而我们在基于 J3 的智驾预控中把渲染模块拿掉，让它复用座舱域的算力，对客户来说，成本就节省了不少。
一位芯片产业资深人士说：
如果在产品设计的时候就把 GPU 做得强一些，当然就不存在「渲染能力不够，不能做行泊一体」的争议了，但在座舱里本身就有算力很大的 GPU（还用不完）的情况下，智驾域再配一个很强大的 GPU，这对客户来说，意味着他们花了不少冤枉钱。
座舱域和智驾域这两个盒子天然是联通的，所以，算力复用本来就是天经地义的，之所以「J3 不能用来做行泊一体」会成为一个话题，是因为在很多主机厂里面，座舱和智驾隶属于两个部门，算力复用涉及到两个部门之间的协作，有的人为了避免跨部门沟通带来的麻烦，宁可花更多的钱去浪费一部分算力，也不愿意提出将座舱域的算力复用到智驾域。
从这个意义上来说，所谓的「J3 不能用来做行泊一体」更多地是一个组织架构造成的问题、是「多一事不如少一事」的企业文化造成的问题，而非技术问题。
大模型：在自动驾驶车端场景 的 应用 尚存在争议
毫末在 4 月 11 号发布了自动驾驶生成式预训练 Transformer 大模型 DriveGPT 雪湖·海若。
DriveGPT 雪湖·海若的一个关键设计，就是场景的 Token 化表达，一连串的 Token 拼在一块就是一个完整的驾驶场景时间序列，包括了未来某个时刻整个交通环境的状态以及自车的状态。
这是在云端的数据训练中，给出的策略。现在，毫末是把车端的模型效果和云端 DriveGPT 的决策效果做比较。大概思路就是将 DriveGPT 作为云端测评模型，用来评估车端小模型的驾驶效果，让车端的认知决策模型学习云端的策略。
毫末把这种方式叫做 Drive Language。Drive Language 基于毫末的 CSS 场景库理论，将驾驶空间进行离散化处理，每一个 Token 都表征场景的一小部分，目前 Token 的词表空间是 50w 个左右。
如果输入一连串过去已经发生的场景 Token 序列，那模型就可以根据历史，去生成未来所有可能的场景，DriveGPT 雪湖·海若就像一部推理机器，你告诉它过去发生了什么，它按概率推理出未来多个可能。
一直对算法演进趋势保持密切关注的芯片厂商，当然也不会错过大模型这一新趋势。
在车展期间，地平线发布了新一代 BPU 架构 Nash。Nash 架构结合了智能计算发展的最新趋势。
宏景智驾董健博士提到，参数量级达千亿的大模型在自动驾驶场景的应用目前主要集中在云端，比如数据标注、场景挖掘、场景重建。
不过，如果把参数的量级从千亿级裁剪到百亿级，大模型还是有可能部署在车端的。在车展现场，辉羲智能市场部的一位工作人员告诉九章智驾：大模型在参数裁剪后上车，反应速度会比在云端慢不少，但等我们的大算力芯片出来后，反应就会越来越快。
ARM 中国的一位朋友说，大模型应用于车端的前提是，车端芯片需要参照服务器芯片的标准进行重构，例如打开 i-cache 的一致性、NoC 直连等等，这需要芯片架构团队下很大的决心。
不过，笔者毕竟是外行，是外行，就总会有一种「我是不是被别人洗脑了」的恐惧。因此，在跟很多业内人士交流时，笔者会反复提到一个问题：大模型要能给自动驾驶带来质的提升，应该是在它大范围应用于规控环节之后，那么，当前，大模型是否已开始应用于规控环节了呢？
对这个问题，诸多受访者们的答案非常接近：当前阶段，大模型在自动驾驶场景中的应用，还集中在感知、数据标注这些环节。
在跟某智能座舱公司总经理交流时，笔者抛出了一个疑问：
大模型在自动驾驶车端场景真能行得通吗？基于第一性原理看，全知全能的人就不存在，那我凭什么相信大模型就可以呢？
而且，就算存在这样的大模型，那它对算力的消耗会超级大，而放在任何一个不需要这么多功能和算力的场景中，它又是一个极大的浪费。
对这个问题，这位朋友的解释是：
从第一性原理来说，所有东西其实都是基于生物去做的仿真和拆解。人是怎么思考的？其实就是大脑+小脑，小脑负责应激反应，大脑是负责理论和综合的漫反射，并非视觉就只是视觉、语音就只是语音的感知，很多时候，其实是「一边看一边听」的。所以，人的交互及思考方式，就接近大模型、多模态。
不过，当前阶段，大模型只擅长泛处理、模糊处理，像自动驾驶这种对安全、对处理精度要求比较高的场景，大模型应对起来确实会比较吃力。因此，我们的判断是，大模型在智能座舱场景中的落地会很快，但在自动驾驶车端场景的落地是非常难的。
目前，在自动驾驶/ADAS 场景用的一些大模型，只是训练参数多了，但它仍然是单模的，而不是多模，因此，它跟「通用人工智能」并不是一回事。所以，您对大模型在自动驾驶车端场景的应用有质疑，这是合理的。
还有一位自动驾驶公司的感知算法工程师说：
大模型目前的这个水平跟自动驾驶还是八竿子打不着。
自动驾驶很多模块里面，无论感知、预测还是规控，用得比较好的深度学习网络有一个特点，它可能用了一些 AI 的子网的技术，输出集合都是封闭的，也只有在输出的集合是封闭的情况下，我才能去评测这个网络输出怎么样；相比之下，大模型输出的东西就是开放的、很难被自然语言解释，这种东西我们没有办法去做评测。
没法做评测的东西，放在座舱里面玩玩可以，但要用到智驾里面，我还是不太放心——智驾需要的是一个确定性的东西。
在图森未来 CTO 王乃岩看来，我们首先得定义清楚究竟什么是「大模型」:
什么模型都可以叫做「大模型」，对吧？如今在车上跑的模型，很多在 5 年之前也叫做「大模型」。但视觉里面的「大模型」是什么？现在还没有共识。
某自动驾驶公司产品经理说：
真正的自动驾驶大模型，应该是能从传感器输入到控制中间只有一个统一的模型，即「端到端」的模型。目前堆参数甚至是将小模型合并的方式整理出来的模型，只能称为「模型大」，而算不上真正的「大模型」。
某自动驾驶公司规控算法工程师说：
可以实现「端到端」的大模型，听上去很高大上，但其实并不完美：一旦出了问题，你根本不知道问题具体出现在哪个环节。当前 感知、预测、规划、控制分开做，尽管出事后团队之间也会扯皮，但真正要想追踪的话，在技术上是可以实现的；然而，一旦采用了「端到端」的大模型，要追踪问题究竟出现在哪里，在技术上也难以实现了。
CHATGPT 的很多回答是「一本正经的胡说八道」，那在自动驾驶场景，如何保证大模型在关键时候比人类驾驶员更安全、更靠谱，就是个问题。
化名「本诺」的自动驾驶工程师在近日的《当我们在谈论端到端自动驾驶时，我们在谈论什么？》一文中提到：
在黑盒效应下，端到端的大模型是无法保证在正确的道路上持续优化的，因为无法保证对未见过的物体的鲁棒性，也无法对某一个具体的 Bug 进行定向改进。
如何对一个具体的 Bug 进行改进？
假设出现了一次误刹，经典的自动驾驶技术栈会分析：刹车指令的来源，是前方动态障碍物，还是静态物体？或者是规划模块的速度规划出现问题？或者是控制模块在输出正确的情况下，控制指令出现了问题？
然后再根据这些进行定向优化。
但是，完全端到端，就失去了这种定向优化的能力，甚至都无法知道，具体应该提供哪种数据进行定向优化。
不过，也并非全部都是悲观的声音。某担任过无人驾驶公司感知算法负责人的投资机构人士称： 端到端大模型的落地，就是 3 年内的事情。
他提出这一观点的原因有三点——
1.特斯拉 FSD12.0 版本架构切换已经验证可行；
2.目前，几个主要功能模块的深度学习模型化已经相对趋于成熟；
3.深度学习模型采用多头方案对提取特征进行监控的技术在很多任务中（尤其是图像分割，风格迁移等领域）目前已经有比较多的案例，使得看似黑盒的中间层其实并没有那么「黑」。
舱驾一体面临的挑战
在车展第一天的一场媒体沟通会上，有媒体问地平线 CTO 黄畅和副总裁余轶男对舱驾一体趋势的看法。
对此，黄畅的回复是：
地平线还是比较专注在自动驾驶上，因为这件事情还没有解决。
整车 EE 架构的演进过程不是一蹴而就的，虽然很多人已经在勾勒这样的一个中央计算平台，用一颗主芯片干所有的事情，但客观地讲，今天很少有产品能做到将舱驾行泊都整合在一起；哪怕整合在一起，到底是在一块板子上的多颗芯片里，还是放在一颗芯片里，还不确定。
我们深切地知道，座舱和自动驾驶对芯片的要求差异是蛮大的，真正要把两者整合到同一颗芯片上做，坦率地说，很难平衡好。所以对于完全 all in one 芯片，我们持谨慎乐观的态度。
我们当然也会在未来考虑舱驾一体，但首先还是要先聚焦，把自动驾驶做得足够好才行。
余轶南的回复是：
我们其实从三年前就开始思考舱驾是否要整合在一颗芯片上，也认为舱驾一体的出现是必然的，但它究竟能占有多大的市场份额，其实还是一个巨大的问题。因为，直到今天，也很少有人能讲清楚，舱驾一体究竟能带来怎样的附加值。
从这几段回答来看，地平线对舱驾一体的态度是相对比较务实的。
其实，这也不难理解。要不要舱驾融合，本质上还是主机厂说了算，而不是芯片厂商说了算。那么，在思考「要不与舱驾融合」这个问题的时候，主机厂最关注的点是什么呢？是技术架构的统一吗？不，是成本。
舱驾一体能否真如芯片厂商所规划的那样帮主机厂降本，其实是存在一定争议的。
用单 soc 芯片实现舱驾一体，最关键的点并不在芯片的算力，而在于如何通过硬件的隔离和虚拟化实现对计算资源的动态分配——要分几个核给仪表用，分几个核给 IVI 用，分几个核给智驾用，而这几个核对功能安全等级的要求就不一样。
那可以将每个核的功能安全等级都做到最高吗？
可以做高，但如此一来，成本肯定上升了啊。
如果不能接受成本的增加，就得接受这样一个事实：
对功能安全等级要求高的智驾域更看重芯片的系统调度能力和数据吞吐能力，而对功能安全等级要求相对较低的座舱更强调芯片的线程，而系统调度能力、数据吞吐能力和线程之间是一个「不可能三角」——在资源有限的情况下，提高座舱域的功能安全等级，就会导致它的线程减少，线程减少就会影响到通信、计算资源的分配及协议栈等。
此外，哪怕单 soc 本身的价格低于之前的两个 soc，但如果加上开发费之后综合成本上升了，那主机厂也没有动力采用。
此外，用单 soc 做舱驾一体时，这颗 soc 上需要运行两套中间件，一套给座舱用，一套给智驾用，而这两条对通信稳定性、功能安全等级的要求也是不一样的。
舱驾一体面临的另一个挑战在组织架构方面：目前，在主机厂内部，智驾和座舱，是两个部门，那么，在走向舱驾一体的过程中，是智驾部门整合座舱部门呢，还是座舱部门整合智驾部门呢？
总体上来说，现阶段，座舱部门的规模要比智驾团队大，并且，座舱业务目前是赚钱的，是公司的「利润中心」，而智驾部门不仅规模更小，而且在当前及未来相当长一段时间里都是亏钱的，是公司的「成本中心」。从这个角度来说，现阶段，座舱部门整合智驾部门「天经地义」。
然而，还有一个现实是：由于智驾的难度要高于座舱，因而智驾部门的人才密度也远高于座舱部门。
那我们试想一下，如果大 boss 决定由座舱部门来整合智驾部门，智驾部门的人心里肯定会是各种「不服气」——你的简历都没老子牛逼，竟然还好意思来整合老子？因而，即便是被强行整合了，他们可能也无法真正跟原座舱部门的人「力出一孔」。
也许，随着智驾技术发展成熟，以及智驾团队不断地发展壮大，会出现由智驾部门整合座舱部门的情况。
某智能座舱公司总经理认为，在传统主机厂里，座舱部门的话语权比智驾部门大，如果要做舱驾一体，应该是座舱部门来整合智驾部门；在新势力中，智驾部门的话语权更大，因此，由智驾部门整合座舱部门的概率更大。
但由智驾部门来整合座舱部门，又会出现我们前面所说的「不赚钱的部门来整合赚钱的部门」的尴尬局面，那座舱部门的人会服气吗？
这么看来，舱驾融合的处境就很尴尬了。 它似乎并不是一个主机厂的 「顶层设计」，而是高通这样的芯片厂商对主机厂的人说：哥们儿，我有这个技术（支持舱驾融合的芯片），你们去融合吧。
或许，有的主机厂会跳过舱驾融合，直接进入中央计算时代。
「要不要跟地平线合作？」「早合作早受益。」
3 月份，某自动驾驶公司的一位技术高管问笔者：「最近，地平线正在跟我们谈合作，在您看来，我们有必要跟他们合作吗？」当时，笔者的答案是：「早合作，早受益。」原因如下——
1.从我们了解到的情况来看，芯片选型的决定权，并不在这种算法公司手里，而是在主机厂手里。
目前，国内多数主机厂都有使用地平线 J3 或 J5 的规划，并且，在选择 J3 或 J5 项目的算法供应商时，他们也会要求算法公司之前有过使用该芯片平台的经验。有很多算法公司选择跟地平线合作的动机，正是希望地平线能在主机厂那里推荐他们，帮他们拿到订单。
还有一个反面的例子是：某在行业里排名非常靠前的明星算法公司因为之前没有使用地平线芯片的经验而错过了几个主机厂项目。 后来，为了能拿到更多主机厂的定点，他们开始改变主意，积极跟地平线合作。
可以看到，2021 年下半年及 2022 年上半年，还有很多算法公司对地平线「不屑一顾」，但到了 2022 年下半年，他们纷纷官宣了跟地平线的战略合作。
可见，生态真正的 C 位是主机厂，在主机厂的偏好前，算法公司的偏好就没那么重要了。
2.通过跟地平线深度合作，你们会更了解底层硬件的性能极限在哪里，从而把底层的潜力都做出来。
一个可借鉴的例子是前地平线早期员工都大龙创办的鉴智机器人公司。现在，行业里很多人对鉴智的评价都是「核心团队是从地平线出来的，他们最懂地平线的算法逻辑，因而他们最有能力把地平线的芯片用好，将其价值最大化」。这种评价，显然对他们拿订单是有好处的。
3.由于大多数算法公司都在尝试跟地平线合作，而地平线能投入的支持资源并没有那么多，甚至，随着合作伙伴的增加，往后，他们能够给合作方提供支持的资源可能会越来越少。从这个角度来说，如果在抢占主机厂定点方面最后要拼的是「谁能在 J5 上将算法跑得更好」，那么越早与地平线合作竞争优势就越明显。
前段时间，某算法公司市场部负责人问笔者：「你怎么看地平线的生态？」
笔者答道：我在过去几个月跟很多人聊，大家都会说：地平线的生态建得挺好，你缺一个什么东西，地平线线马上就给你推一个相关公司。在这个过程中，地平线也不赚你的钱，他就是帮助你。
此前，笔者还了解到一个现象：有时候，合作伙伴 A 需要某个模块的产品或服务，地平线自己也有，但生态部门可能会优先推荐合作伙伴 B 给 A，这是因为他们认为，在当前 ，B 的这项技术比地平线自己做得更好，能更好地服务 A。生态部门这么做，可能会影响到公司内部其他部门的利益，但从生态伙伴的利益出发，他们必须这么做。
上述算法公司市场部负责人说：「我们觉得地平线的格局确实是比较大的，在很多时候真会不计较得失地帮助合作伙伴。」
这事给笔者的启发是：公司跟公司之间长期的战略合作，不能把账算得太细，不能过于计较在这个事情上我吃亏多少、你占便宜多少。
从「轻高精地图」到「去高精地图」
除了个别敏感区域，城区高精地图在 3 月份已经放开，主机厂只要跟有资质的图商合作，高精地图就已不再成为城市 NOA 功能商用的障碍。不过，即便如此，在上海车展上，诸多的自动驾驶公司及一些主机厂仍然将「轻/去高精地图」作为重点技术推出。
「去高精地图」的最关键原因， 究竟是成本，还是合规？
对这个问题，一位在主机厂负责自动驾驶战略研究的朋友是这么解释的：
我们首先要区分「谁的成本」和「谁的合规」这两个问题。
目前，自然资源部放开的是城区审图号，但是审图申请仍然需要图商发起，因为主机厂没有甲级资质，虽然全国的城区地图都可用了，但是如果图商不去申请或者不覆盖，那虽然合规，主机厂也没有办法在没图的城市落地。
也就是说，合规指有甲级资质的公司能从高速扩大到城区的审图号申请了，但是没有甲级资质的公司仍然会受牵制 ——即主机厂城市 N OA 功能的拓展受到了图商的约束。
主机厂要想合规使用高精地图，就得找图商买，但买图得花钱，而且地图要一直更新，潜在也要一直花钱，这就有了成本问题。主机厂是不想被卡脖子的，也需要实现真正的数据闭环，那就选择了两条腿走路——
一是，自己申请甲级资质，自己采集更新制作地图，但这个口子自然资源部是不会倾向于放开的。
二是，采用「轻/去高精地图」方案，降低对图商的依赖。
至于图商到底能不能在产业链里持续分这杯羹，答案是肯定的。因为，不是所有的主机厂都把自动驾驶作为核心壁垒的，大部分公司不会有这个动力和能力砸钱。
也就是说，只有对希望建立起自动驾驶强核心壁垒的头部玩家（如头部新势力），高精地图才会 「真正」受到「合规问题」的影响；对于其他玩家来说，反而是没啥「合规问题」了，只要买得起图就能落地，他们更关注的就是「成本问题」了。
但这个「成本问题」其实也只是暂时的。
因为，现在图商卖地图的方式是，一部分自己主动采集，一部分按照车厂需求采集，但这些审图号只要字段是包含关系都是可以复用的，现在就是由于落地的主机厂太少才贵；如果最后变成市场上几十个车型 share 一个审图号的基础成本，那价格很快就不会有这么大的负担了，越来越多的车也都能用起来，形成正向循环。
「轻高精地图」不等于「轻地图」
大家都知道，「重感知、轻/去高精地图」的风潮是特斯拉带起来的。其实现路径主要是利用 Transformener + BEV 来理清道路元素之间的关系。如红绿灯红灯与哪一个道路关联，左转线跟左转的那边所有的三根线里面哪一根是关联的。在这种方案中，除道路拓扑结构信息外，其他信息都可以被感知代替。
在国内，走「重感知、轻高精地图」这一路线的，大多数是 L4 出身的公司，以及虽然没喊过 L4、但感知算法能力很强的地平线、商汤科技等。
「轻高精地图」方案，有的公司是先从城区场景开始，有的是先从高速场景开始。
在高速场景，多家公司的方案在「轻高精地图」的同时，还实现了「去高精定位」（省去了高精 RTK），使系统成本降低了 20%以上。
（据 Robotaxi 公司的说法，去高精地图，主要适用于高阶版的 ADAS，而 L4 还是需要高精地图作为冗余。)
当然，「轻高精地图」不等于「轻地图」——新方案对导航地图的依赖度还是挺高的。当前，「轻高精地图」后，感知环节有三种「补偿方案」：
（1）纯视觉众包建图
即完全数据驱动的视觉建图，驾驶过程中视觉识别标志牌、车道线标识，识别特征点从而实时建图，向系统反馈导航情况。这种方案对视觉感知要求高，门槛较高。目前，采用这一方案的典型公司是特斯拉。
（2）车机导航地图
将现有标配的车机导航地图，通过 ADAS V2 或 V3 的协议，得到导航地图的更多、更细致的信息，从而取代高精地图。
（3）SD Pro 导航地图
SD Pro 地图不像高精地图里面有详细的车道线等方面的信息，但比普通的导航地图信息更丰富——会有车道数、车道属性变化点，并以点的形式表达复杂的车道和路口连通信息、并以属性的方式表达车道宽度等相关信息，作用就是在复杂路口、道路分歧合流等复杂驾驶场景提供关键定位和规控所使用的地图信息，也可以帮助 BEV 算法来建图。
我们可以将 SD Pro 导航地图理解为一种简化版的高精地图或传统 ADAS 车机导航地图的升级版；但由于没有更详细的几何信息，所以，SD Pro 地图的制作和发布要比 HD 地图快。
SD Pro 地图的代表性玩家有腾讯和美行科技。其中，美行在本次上海车展期间官宣了跟地平线和领骏科技的合作。
美行的 SD Pro 是通过利用众源数据生成的。所谓众源数据，不仅包括摄像头采集的数据，还包括来自路端的数据、来自卫星的数据。这种方案的最大优势是成本低、便于落地。
对取得甲级测绘资质比较晚的图商来说，如果做全国范围的传统模式的高精度地图采集，无论时间上还是投入上，跟老牌图商都没法竞争。因此，美行将自己定义为新图商，选择众源方案作为当前的最优路径，众源采集的数据归属于主机厂，美行负责搭建平台、数据采集处理以及合规存储使用等。
美行方面称，其众源地图系统已于 2022 年完成商业化首单的签署，并于当年内完成全功能。
与 SD Pro 类似的一个概念是「轻量级高精地图」（LD map）——不做路灯牌等不影响行车功能的因素，只做车道线、停止线等必备的地图要素。
无论叫 SD pro 还是 LD map，本质上都是把自动驾驶对地图的关键信息提取出来，然后又不依赖于全面的建图和生产，成本上比 HD 地图降低了不少。
不过，这个 SD Pro 导航地图或「轻量级高精地图」也需要甲级测绘资质。
去高精地图与轻高精地图的区别
说到这里，我们需要澄清两个概念：轻高精地图（多数公司都在提），去高精地图（代表性公司有华为、小鹏、元戎启行）。 那么，在技术上，这两个概念有区别吗？
某自动驾驶公司感知部门一位技术人员的答案是：没有本质区别。
那为什么会有 「轻高精地图」和「去高精地图」这两个不同的说法呢？区别在，导航地图、感知数据中的道路拓扑信息算不算「高精地图」的一部分？如果算，那就是「轻高精地图」，如果不算，那就是「去高精地图」。
据此，究竟是「轻高精地图」还是「去高精地图」，完全取决于你怎么定义什么是「高精地图」。
不过，来自某高精地图公司的一位专家的说法却是：有区别。
「轻高精地图」是去除高精地图中的杆、路灯等非必须拓扑要素，其实只是将高精地图的一些内容去掉，将数据存储和传输减少，做到轻量，可以降低高精地图作业成本，但本质上还是有数据回传、需要有个离线建图的「生产线」和流程；
「去高精度地图」本质上是基于静态元素的感知数据直接在车端还原出道路拓扑要素，但这些数据在车端「阅后即焚」（用完就丢掉），没有数据回传、没有离线建图流程和存储维护。
去年 9 月份，某科技媒体发布的《特斯拉看不上的高精地图，华为当个宝》一文据说在一些部委里引起了很大反响。当时，有高精地图领域的朋友问笔者怎么看，笔者的回答是：
从标 题非要加个定语「特斯拉看不上」来看，这篇文章的作者已经默认自己的目标用户是外行（似乎作者担心，如果不加这个定语，他那些外行读者们根本就无法理解「什么是 高精地图」。我不太理解，这种「默认读者是外行」的文章，我有什么打开的必要？
结果，被啪啪打脸了吧。在各家都嚷着「重感知，轻高精地图」的上海车展前后 ，华为是第一家推出了「去高精地图」方案的公司。
「轻/去高精地图面临的挑战」
看上去，「去高精地图」方案可以绕开高精地图资质的限制，也大幅度降低成本，但要实现起来却特别难。
挑战首先来自感知算法的工程化环节。比如，通过 8～11 个摄像头完成实时建图，要求车道线连续且平滑，这对感知系统的准确度及稳定性提出了很高的要求。
而据 36 氪及 HiEV 此前的报道，小马 CTO 楼天城就认为，摆脱高精地图，不仅仅是感知板块的挑战，而是预测、规控等所有模块的同步提升。
在 36 氪此前的报道中，一位智能驾驶算法工程师举了个例子，去高精地图后，需要车辆的感知模块能实时判断哪个红绿灯，控制的是哪条对应车道，「人有时候都会弄错，更何况是车辆。」
此外，36 氪的报道中还提到，去高精地图意味着自动驾驶系统对于车道线、可通行区域等的获取结果变差了，比如车道线的精度没有那么高了、识别的距离变短了，因此，下游的决策和控制环节就要有为感知不准确「兜底」的能力，这对决策控制环节提出了更高的要求。
九章智驾在最近的行业交流中也了解到，真正影响 Mapless 技术路线落地的最大难点在于规控——大多数公司的规控方案基于高精地图，容不得一丝差距。
某自动驾驶公司项目经理告诉九章智驾：「我跟做算法的同事在聊‘重感知，轻高精地图’话题时，大家都支支吾吾的，所以，我一直不清楚这个方案的置信度到底有多高。」
感知算法训练或将受到数据合规政策的影响
前段时间，笔者从高精地图公司宽凳科技的官方微信公众号上看到这么一句话：感知的结果，一旦存储或回传，就需要有相应地图资质的单位管理，而图商一般都拥有对应的地图资质。
按照这个说法，受数据合规相关法规政策影响的，就不限于高精地图数据了，还有用于感知算法的数据回传。 这是真的吗？
带着这个疑问，九章跟多家主机厂及自动驾驶公司负责政策研究、GR 的朋友确认了一下，得到的答案是：真的。
还有人特别补充了一句，只要数据被认定为「测绘数据」，不管用途是什么，其收集、回传、处理等活动都需要有资质企业实施，或委托有资质企业实施——感知结果会包含自车周边环境信息，如实景影像、空间位置坐标等，一旦含测绘法定义的地理信息，则都属于「测绘数据」范畴。
一位测绘领域资深专家称：感知里面有动态数据和静态数据，其中的静态数据其实就是地图数据。
他还提到，自然资源部里有专家就认为，激光雷达的数据（可以据此还原出车辆的地理坐标信息——哪怕只回传了局部信息，最终仍然有办法还原出全局信息）一定算「测绘数据」；至于摄像头数据算不算「测绘数据」、视觉感知数据中的道路拓扑信息算不算「高精地图」的一部分，目前尚无定论。
这位专家还称：「假如摄像头的数据也被认定为‘测绘数据’（毕竟，BEV 感知「再往前一步就能做高精地图」），纯外资的算法公司，以及希望涉足到感知环节的芯片厂商，就会遭遇很大挑战。」
可见，用真实道路数据做算法训练的难度是越来越大了——不是没法做，关键是对车端脱敏的要求太高了，甚至可能还需要跟有测绘资质的图商合作。
或许，在今后，感知算法训练环节对合成数据的需求会比之前更旺盛了。实际上，一些嗅觉灵敏的创业者已开始涉足该领域。
比如，前蔚来仿真负责人谢晨于今年初创办的光轮智能——光轮智能的定位是利用生成式 AI 技术与仿真结合来生产合成数据。自动驾驶感知训练是这些合成数据的第一个应用场景。不同于大多数公司的仿真只能用来做测试，光轮通过仿真和生成式 AI 的结合还可用于算法训练。
之前，笔者曾向某头部新势力的资深自动驾驶感专家请教：「我之前跟很多仿真公司做过交流，大多都说目前还‘不能用仿真做训练’，这背后的原因是什么？」
对方的解释是：「用仿真做训练，对图像渲染能力要求很高，在这方面最擅长的公司是英伟达。前蔚来的仿真负责人谢晨你认识吗？谢晨在加入蔚来之前是英伟达的仿真负责人，在国内，能用仿真做算法训练的，估计就只有谢晨的新公司光轮了。」
目前，光轮的合成数据已经被应用于某 L4 背景的自动驾驶公司的算法训练及「去高精地图」方案中——「去高精地图」需要感知系统熟悉各种小样本的结构化地图信息，比如特殊的交通路口、指示灯、车道线、路况、清晰度等等，而合成数据将小样本地图特征大规模泛化的优势很好地帮助到了「去高精地图」。
「中国研发，德国应用」
车展第二日，在地平线组织的一场生态沙龙上，均联智行中国区 CTO 陈远提到， 以前，自动驾驶、智能座舱等相关技术都是先在德国研发，然后引入到中国应用；但从两年前开始，他们的很多自动驾驶相关技术都是在中国研发，然后再出口到海外。
陈远还特别强调，现在，他们所有项目的软硬件研发基本都在中国，不在德国了。
或许，接下来，在德国本土研发自动驾驶受挫的大众等主机厂也可能这么干？
