芯耀
2705
編輯 |?蘇清濤
真正影響Mapless技術路線落地的最大難點在于規(guī)控——大多數公司的規(guī)控方案基于高精地圖，容不得一絲差距。
本文所涉及的內容，有一部分來自筆者在4月份的上海車展期間的一系列觀察與思考，其余部分來自筆者在車展前后這兩個多月參加個別企業(yè)的發(fā)布會以及跟數十位在自動駕駛產業(yè)一線的朋友一對一交流后的收獲。
嚴格地說，這并不能算作是一篇正兒八經的“文章”，而是對一些碎片化觀察與思考的“東拼西湊”。
本文涉及的話題主要有：
一、芯片公司需要向算法公司“反向支付”開發(fā)費
二、地平線J3不能做行泊一體？
三、大模型：在自動駕駛車端場景的應用尚存在爭議
四、艙駕一體面臨的挑戰(zhàn)
五、“要不要跟地平線合作？”“早合作早受益。”
六、從“輕高精地圖”到“去高精地圖”
七、感知算法訓練或將受到數據合規(guī)政策的影響
八、“中國研發(fā)，德國應用”
一、芯片公司需要向算法公司“反向支付”開發(fā)費
通常來說，算法公司在向芯片廠商尋求支持時，需要支付一部分開發(fā)費；但現在還有一種現象：那些入局比晚的芯片廠商在跟算法談合作時，非但不能向后者收取開發(fā)費，反而很容易遭遇后者的高姿態(tài)，“我們的資源有限，暫時不會基于新的芯片平臺做開發(fā)，除非你們愿意支付開發(fā)費?！?/p>
在研發(fā)預算被削減的主機廠那里，也存在同樣的現象。
由此延伸出的一個話題是：現階段，主機廠對芯片、激光雷達是否要采取“AB供模式，跟主機廠的研發(fā)資源、研發(fā)部門和采購部門之間話語權的力量對比有很大關系——采購有動力追求平衡，他們一定希望有“B供”；但研發(fā)部門會對抗，如果研發(fā)資源不夠，并且，研發(fā)的話語權確實很大的話，他們就不希望引入“B供”。
二、地平線J3不能做行泊一體？
“地平線J3的GPU比較弱，圖像渲染表現不佳，因而，不能單獨用來做行泊一體，需要搭配TDA 4才可以。”去年上半年，多家算法公司在跟九章智駕的交流中都提到了這一點。
不過，去年年底到今年年初，福瑞泰克和宏景智駕兩家公司卻先后宣布用單J3行泊一體了。這里面有何玄機呢？在這次上海車展期間，九章智駕向宏景智駕聯合創(chuàng)始人兼軟件算法副總裁董健博士提出了這個問題，對此，董健博士的回答是：
我們遇到的客戶，基本上沒有人吐槽過J3“不能做行泊一體”，因為大家普遍都是通過座艙域里的GPU來做圖像渲染，“把環(huán)視的圖像數據一分為二，一路傳到J3里面，另一路傳到座艙中的GPU里”。
實際上，在開啟行車功能的時候，你是不太會泊車的，而在開啟泊車功能的時候，你也不在行車場景中，所以，我們就利用這個特質，對座艙域的GPU算力做了一個分時復用，即在行車的時候會把環(huán)視關掉，到泊車的時候再打開。
對此，宏景智駕CEO劉飛龍博士補充道：
在很多車型中，座艙系統(tǒng)的渲染能力是非常好的，并且算力是過剩的，很容易被浪費，而我們在基于J3的智駕預控中把渲染模塊拿掉，讓它復用座艙域的算力，對客戶來說，成本就節(jié)省了不少。
一位芯片產業(yè)資深人士說：如果在產品設計的時候就把GPU做得強一些，當然就不存在“渲染能力不夠，不能做行泊一體”的爭議了，但在座艙里本身就有算力很大的GPU（還用不完）的情況下，智駕域再配一個很強大的GPU，這對客戶來說，意味著他們花了不少冤枉錢。
座艙域和智駕域這兩個盒子天然是聯通的，所以，算力復用本來就是天經地義的，之所以“J3不能用來做行泊一體”會成為一個話題，是因為在很多主機廠里面，座艙和智駕隸屬于兩個部門，算力復用涉及到兩個部門之間的協(xié)作，有的人為了避免跨部門溝通帶來的麻煩，寧可花更多的錢去浪費一部分算力，也不愿意提出將座艙域的算力復用到智駕域。
從這個意義上來說，所謂的“J3不能用來做行泊一體”更多地是一個組織架構造成的問題、是“多一事不如少一事”的企業(yè)文化造成的問題，而非技術問題。
三、大模型：在自動駕駛車端場景的應用尚存在爭議
毫末在4月11號發(fā)布了自動駕駛生成式預訓練Transformer大模型DriveGPT雪湖·海若。
DriveGPT雪湖·海若的一個關鍵設計，就是場景的Token化表達，一連串的Token拼在一塊就是一個完整的駕駛場景時間序列，包括了未來某個時刻整個交通環(huán)境的狀態(tài)以及自車的狀態(tài)。
這是在云端的數據訓練中，給出的策略?，F在，毫末是把車端的模型效果和云端DriveGPT的決策效果做比較。大概思路就是將DriveGPT作為云端測評模型，用來評估車端小模型的駕駛效果，讓車端的認知決策模型學習云端的策略。
毫末把這種方式叫做Drive Language。Drive Language基于毫末的CSS場景庫理論，將駕駛空間進行離散化處理，每一個Token都表征場景的一小部分，目前Token的詞表空間是50w個左右。
如果輸入一連串過去已經發(fā)生的場景Token序列，那模型就可以根據歷史，去生成未來所有可能的場景，DriveGPT雪湖·海若就像一部推理機器，你告訴它過去發(fā)生了什么，它按概率推理出未來多個可能。
一直對算法演進趨勢保持密切關注的芯片廠商，當然也不會錯過大模型這一新趨勢。
在車展期間，地平線發(fā)布了新一代BPU架構Nash。Nash架構結合了智能計算發(fā)展的最新趨勢。
宏景智駕董健博士提到，參數量級達千億的大模型在自動駕駛場景的應用目前主要集中在云端，比如數據標注、場景挖掘、場景重建。
不過，如果把參數的量級從千億級裁剪到百億級，大模型還是有可能部署在車端的。在車展現場，輝羲智能市場部的一位工作人員告訴九章智駕：大模型在參數裁剪后上車，反應速度會比在云端慢不少，但等我們的大算力芯片出來后，反應就會越來越快。
ARM中國的一位朋友說，大模型應用于車端的前提是，車端芯片需要參照服務器芯片的標準進行重構，例如打開i-cache的一致性、NoC直連等等，這需要芯片架構團隊下很大的決心。
不過，筆者畢竟是外行，是外行，就總會有一種“我是不是被別人洗腦了”的恐懼。因此，在跟很多業(yè)內人士交流時，筆者會反復提到一個問題：大模型要能給自動駕駛帶來質的提升，應該是在它大范圍應用于規(guī)控環(huán)節(jié)之后，那么，當前，大模型是否已開始應用于規(guī)控環(huán)節(jié)了呢？
對這個問題，諸多受訪者們的答案非常接近：當前階段，大模型在自動駕駛場景中的應用，還集中在感知、數據標注這些環(huán)節(jié)。
在跟某智能座艙公司總經理交流時，筆者拋出了一個疑問：大模型在自動駕駛車端場景真能行得通嗎？基于第一性原理看，全知全能的人就不存在，那我憑什么相信大模型就可以呢？
而且，就算存在這樣的大模型，那它對算力的消耗會超級大，而放在任何一個不需要這么多功能和算力的場景中，它又是一個極大的浪費。
對這個問題，這位朋友的解釋是：從第一性原理來說，所有東西其實都是基于生物去做的仿真和拆解。人是怎么思考的？其實就是大腦+小腦，小腦負責應激反應，大腦是負責理論和綜合的漫反射，并非視覺就只是視覺、語音就只是語音的感知，很多時候，其實是“一邊看一邊聽”的。所以，人的交互及思考方式，就接近大模型、多模態(tài)。
不過，當前階段，大模型只擅長泛處理、模糊處理，像自動駕駛這種對安全、對處理精度要求比較高的場景，大模型應對起來確實會比較吃力。因此，我們的判斷是，大模型在智能座艙場景中的落地會很快，但在自動駕駛車端場景的落地是非常難的。
目前，在自動駕駛/ADAS場景用的一些大模型，只是訓練參數多了，但它仍然是單模的，而不是多模，因此，它跟“通用人工智能”并不是一回事。所以，您對大模型在自動駕駛車端場景的應用有質疑，這是合理的。
還有一位自動駕駛公司的感知算法工程師說：大模型目前的這個水平跟自動駕駛還是八竿子打不著。
自動駕駛很多模塊里面，無論感知、預測還是規(guī)控，用得比較好的深度學習網絡有一個特點，它可能用了一些 AI 的子網的技術，輸出集合都是封閉的，也只有在輸出的集合是封閉的情況下，我才能去評測這個網絡輸出怎么樣；相比之下，大模型輸出的東西就是開放的、很難被自然語言解釋，這種東西我們沒有辦法去做評測。
沒法做評測的東西，放在座艙里面玩玩可以，但要用到智駕里面，我還是不太放心——智駕需要的是一個確定性的東西。
在圖森未來CTO王乃巖看來，我們首先得定義清楚究竟什么是“大模型”:什么模型都可以叫做“大模型”，對吧？如今在車上跑的模型，很多在 5 年之前也叫做“大模型”。但視覺里面的“大模型”是什么？現在還沒有共識。
某自動駕駛公司產品經理說：真正的自動駕駛大模型，應該是能從傳感器輸入到控制中間只有一個統(tǒng)一的模型，即“端到端”的模型。目前堆參數甚至是將小模型合并的方式整理出來的模型，只能稱為“模型大”，而算不上真正的“大模型”。
某自動駕駛公司規(guī)控算法工程師說：可以實現“端到端”的大模型，聽上去很高大上，但其實并不完美：一旦出了問題，你根本不知道問題具體出現在哪個環(huán)節(jié)。當前 感知、預測、規(guī)劃、控制分開做，盡管出事后團隊之間也會扯皮，但真正要想追蹤的話，在技術上是可以實現的；然而，一旦采用了“端到端”的大模型，要追蹤問題究竟出現在哪里，在技術上也難以實現了。
CHATGPT的很多回答是“一本正經的胡說八道”，那在自動駕駛場景，如何保證大模型在關鍵時候比人類駕駛員更安全、更靠譜，就是個問題。
化名“本諾”的自動駕駛工程師在近日的《當我們在談論端到端自動駕駛時，我們在談論什么？》一文中提到：??在黑盒效應下，端到端的大模型是無法保證在正確的道路上持續(xù)優(yōu)化的，因為無法保證對未見過的物體的魯棒性，也無法對某一個具體的 Bug 進行定向改進。
如何對一個具體的 Bug 進行改進？
假設出現了一次誤剎，經典的自動駕駛技術棧會分析：剎車指令的來源，是前方動態(tài)障礙物，還是靜態(tài)物體？或者是規(guī)劃模塊的速度規(guī)劃出現問題？或者是控制模塊在輸出正確的情況下，控制指令出現了問題？
然后再根據這些進行定向優(yōu)化。
但是，完全端到端，就失去了這種定向優(yōu)化的能力，甚至都無法知道，具體應該提供哪種數據進行定向優(yōu)化。
不過，也并非全部都是悲觀的聲音。某擔任過無人駕駛公司感知算法負責人的投資機構人士稱：端到端大模型的落地，就是3年內的事情。
他提出這一觀點的原因有三點——? ? 1.特斯拉FSD12.0版本架構切換已經驗證可行；? ? 2.目前，幾個主要功能模塊的深度學習模型化已經相對趨于成熟；? ? 3.深度學習模型采用多頭方案對提取特征進行監(jiān)控的技術在很多任務中（尤其是圖像分割，風格遷移等領域）目前已經有比較多的案例，使得看似黑盒的中間層其實并沒有那么“黑”。
四、艙駕一體面臨的挑戰(zhàn)
在車展第一天的一場媒體溝通會上，有媒體問地平線CTO黃暢和副總裁余軼男對艙駕一體趨勢的看法。
對此，黃暢的回復是：地平線還是比較專注在自動駕駛上，因為這件事情還沒有解決。
整車EE架構的演進過程不是一蹴而就的，雖然很多人已經在勾勒這樣的一個中央計算平臺，用一顆主芯片干所有的事情，但客觀地講，今天很少有產品能做到將艙駕行泊都整合在一起；哪怕整合在一起，到底是在一塊板子上的多顆芯片里，還是放在一顆芯片里，還不確定。
我們深切地知道，座艙和自動駕駛對芯片的要求差異是蠻大的，真正要把兩者整合到同一顆芯片上做，坦率地說，很難平衡好。所以對于完全all in one芯片，我們持謹慎樂觀的態(tài)度。
我們當然也會在未來考慮艙駕一體，但首先還是要先聚焦，把自動駕駛做得足夠好才行。
余軼南的回復是：我們其實從三年前就開始思考艙駕是否要整合在一顆芯片上，也認為艙駕一體的出現是必然的，但它究竟能占有多大的市場份額，其實還是一個巨大的問題。因為，直到今天，也很少有人能講清楚，艙駕一體究竟能帶來怎樣的附加值。
從這幾段回答來看，地平線對艙駕一體的態(tài)度是相對比較務實的。
其實，這也不難理解。要不要艙駕融合，本質上還是主機廠說了算，而不是芯片廠商說了算。那么，在思考“要不與艙駕融合”這個問題的時候，主機廠最關注的點是什么呢？是技術架構的統(tǒng)一嗎？不，是成本。
艙駕一體能否真如芯片廠商所規(guī)劃的那樣幫主機廠降本，其實是存在一定爭議的。
用單soc芯片實現艙駕一體，最關鍵的點并不在芯片的算力，而在于如何通過硬件的隔離和虛擬化實現對計算資源的動態(tài)分配——要分幾個核給儀表用，分幾個核給IVI用，分幾個核給智駕用，而這幾個核對功能安全等級的要求就不一樣。
那可以將每個核的功能安全等級都做到最高嗎？
可以做高，但如此一來，成本肯定上升了啊。
如果不能接受成本的增加，就得接受這樣一個事實：對功能安全等級要求高的智駕域更看重芯片的系統(tǒng)調度能力和數據吞吐能力，而對功能安全等級要求相對較低的座艙更強調芯片的線程，而系統(tǒng)調度能力、數據吞吐能力和線程之間是一個“不可能三角”——在資源有限的情況下，提高座艙域的功能安全等級，就會導致它的線程減少，線程減少就會影響到通信、計算資源的分配及協(xié)議棧等。
此外，哪怕單soc本身的價格低于之前的兩個soc，但如果加上開發(fā)費之后綜合成本上升了，那主機廠也沒有動力采用。
此外，用單soc做艙駕一體時，這顆soc上需要運行兩套中間件，一套給座艙用，一套給智駕用，而這兩條對通信穩(wěn)定性、功能安全等級的要求也是不一樣的。
艙駕一體面臨的另一個挑戰(zhàn)在組織架構方面：目前，在主機廠內部，智駕和座艙，是兩個部門，那么，在走向艙駕一體的過程中，是智駕部門整合座艙部門呢，還是座艙部門整合智駕部門呢？
總體上來說，現階段，座艙部門的規(guī)模要比智駕團隊大，并且，座艙業(yè)務目前是賺錢的，是公司的“利潤中心”，而智駕部門不僅規(guī)模更小，而且在當前及未來相當長一段時間里都是虧錢的，是公司的“成本中心”。從這個角度來說，現階段，座艙部門整合智駕部門“天經地義”。
然而，還有一個現實是：由于智駕的難度要高于座艙，因而智駕部門的人才密度也遠高于座艙部門。
那我們試想一下，如果大boss決定由座艙部門來整合智駕部門，智駕部門的人心里肯定會是各種“不服氣”——你的簡歷都沒老子牛逼，竟然還好意思來整合老子？因而，即便是被強行整合了，他們可能也無法真正跟原座艙部門的人“力出一孔”。
也許，隨著智駕技術發(fā)展成熟，以及智駕團隊不斷地發(fā)展壯大，會出現由智駕部門整合座艙部門的情況。
某智能座艙公司總經理認為，在傳統(tǒng)主機廠里，座艙部門的話語權比智駕部門大，如果要做艙駕一體，應該是座艙部門來整合智駕部門；在新勢力中，智駕部門的話語權更大，因此，由智駕部門整合座艙部門的概率更大。
但由智駕部門來整合座艙部門，又會出現我們前面所說的“不賺錢的部門來整合賺錢的部門”的尷尬局面，那座艙部門的人會服氣嗎？
這么看來，艙駕融合的處境就很尷尬了。它似乎并不是一個主機廠的“頂層設計”，而是高通這樣的芯片廠商對主機廠的人說：哥們兒，我有這個技術（支持艙駕融合的芯片），你們去融合吧。
或許，有的主機廠會跳過艙駕融合，直接進入中央計算時代。
五、“要不要跟地平線合作？”“早合作早受益?！?/strong>
3月份，某自動駕駛公司的一位技術高管問筆者：“最近，地平線正在跟我們談合作，在您看來，我們有必要跟他們合作嗎？”當時，筆者的答案是：“早合作，早受益?！痹蛉缦隆?/p>
1.從我們了解到的情況來看，芯片選型的決定權，并不在這種算法公司手里，而是在主機廠手里。
目前，國內多數主機廠都有使用地平線J3或J5的規(guī)劃，并且，在選擇J3或J5項目的算法供應商時，他們也會要求算法公司之前有過使用該芯片平臺的經驗。有很多算法公司選擇跟地平線合作的動機，正是希望地平線能在主機廠那里推薦他們，幫他們拿到訂單。
還有一個反面的例子是：某在行業(yè)里排名非?？壳暗拿餍撬惴ü疽驗橹皼]有使用地平線芯片的經驗而錯過了幾個主機廠項目。?后來，為了能拿到更多主機廠的定點，他們開始改變主意，積極跟地平線合作。
可以看到，2021年下半年及2022年上半年，還有很多算法公司對地平線“不屑一顧”，但到了2022年下半年，他們紛紛官宣了跟地平線的戰(zhàn)略合作。
可見，生態(tài)真正的C位是主機廠，在主機廠的偏好前，算法公司的偏好就沒那么重要了。
2.通過跟地平線深度合作，你們會更了解底層硬件的性能極限在哪里，從而把底層的潛力都做出來。
一個可借鑒的例子是前地平線早期員工都大龍創(chuàng)辦的鑒智機器人公司?，F在，行業(yè)里很多人對鑒智的評價都是“核心團隊是從地平線出來的，他們最懂地平線的算法邏輯，因而他們最有能力把地平線的芯片用好，將其價值最大化”。這種評價，顯然對他們拿訂單是有好處的。
3.由于大多數算法公司都在嘗試跟地平線合作，而地平線能投入的支持資源并沒有那么多，甚至，隨著合作伙伴的增加，往后，他們能夠給合作方提供支持的資源可能會越來越少。從這個角度來說，如果在搶占主機廠定點方面最后要拼的是“誰能在J5上將算法跑得更好”，那么越早與地平線合作競爭優(yōu)勢就越明顯。
前段時間，某算法公司市場部負責人問筆者：“你怎么看地平線的生態(tài)？”
筆者答道：我在過去幾個月跟很多人聊，大家都會說：地平線的生態(tài)建得挺好，你缺一個什么東西，地平線線馬上就給你推一個相關公司。在這個過程中，地平線也不賺你的錢，他就是幫助你。
此前，筆者還了解到一個現象：有時候，合作伙伴A需要某個模塊的產品或服務，地平線自己也有，但生態(tài)部門可能會優(yōu)先推薦合作伙伴B給A，這是因為他們認為，在當前 ，B的這項技術比地平線自己做得更好，能更好地服務A。生態(tài)部門這么做，可能會影響到公司內部其他部門的利益，但從生態(tài)伙伴的利益出發(fā)，他們必須這么做。
上述算法公司市場部負責人說：“我們覺得地平線的格局確實是比較大的，在很多時候真會不計較得失地幫助合作伙伴。”
這事給筆者的啟發(fā)是：公司跟公司之間長期的戰(zhàn)略合作，不能把賬算得太細，不能過于計較在這個事情上我吃虧多少、你占便宜多少。
六、從“輕高精地圖”到“去高精地圖”
除了個別敏感區(qū)域，城區(qū)高精地圖在3月份已經放開，主機廠只要跟有資質的圖商合作，高精地圖就已不再成為城市NOA功能商用的障礙。不過，即便如此，在上海車展上，諸多的自動駕駛公司及一些主機廠仍然將“輕/去高精地圖”作為重點技術推出。
1.“去高精地圖”的最關鍵原因，究竟是成本，還是合規(guī)？
對這個問題，一位在主機廠負責自動駕駛戰(zhàn)略研究的朋友是這么解釋的：
我們首先要區(qū)分“誰的成本”和“誰的合規(guī)”這兩個問題。
目前，自然資源部放開的是城區(qū)審圖號，但是審圖申請仍然需要圖商發(fā)起，因為主機廠沒有甲級資質，雖然全國的城區(qū)地圖都可用了，但是如果圖商不去申請或者不覆蓋，那雖然合規(guī)，主機廠也沒有辦法在沒圖的城市落地。
也就是說，合規(guī)指有甲級資質的公司能從高速擴大到城區(qū)的審圖號申請了，但是沒有甲級資質的公司仍然會受牽制——即主機廠城市NOA功能的拓展受到了圖商的約束。
主機廠要想合規(guī)使用高精地圖，就得找圖商買，但買圖得花錢，而且地圖要一直更新，潛在也要一直花錢，這就有了成本問題。主機廠是不想被卡脖子的，也需要實現真正的數據閉環(huán)，那就選擇了兩條腿走路——
一是，自己申請甲級資質，自己采集更新制作地圖，但這個口子自然資源部是不會傾向于放開的。
二是，采用“輕/去高精地圖”方案，降低對圖商的依賴。
至于圖商到底能不能在產業(yè)鏈里持續(xù)分這杯羹，答案是肯定的。因為，不是所有的主機廠都把自動駕駛作為核心壁壘的，大部分公司不會有這個動力和能力砸錢。
也就是說，只有對希望建立起自動駕駛強核心壁壘的頭部玩家（如頭部新勢力），高精地圖才會“真正”受到“合規(guī)問題”的影響；對于其他玩家來說，反而是沒啥“合規(guī)問題”了，只要買得起圖就能落地，他們更關注的就是“成本問題”了。
但這個“成本問題”其實也只是暫時的。
因為，現在圖商賣地圖的方式是，一部分自己主動采集，一部分按照車廠需求采集，但這些審圖號只要字段是包含關系都是可以復用的，現在就是由于落地的主機廠太少才貴；如果最后變成市場上幾十個車型share一個審圖號的基礎成本，那價格很快就不會有這么大的負擔了，越來越多的車也都能用起來，形成正向循環(huán)。
2.“輕高精地圖”不等于“輕地圖”
大家都知道，“重感知、輕/去高精地圖”的風潮是特斯拉帶起來的。其實現路徑主要是利用Transformener + BEV來理清道路元素之間的關系。如紅綠燈紅燈與哪一個道路關聯，左轉線跟左轉的那邊所有的三根線里面哪一根是關聯的。在這種方案中，除道路拓撲結構信息外，其他信息都可以被感知代替。
在國內，走“重感知、輕高精地圖”這一路線的，大多數是L4出身的公司，以及雖然沒喊過L4、但感知算法能力很強的地平線、商湯科技等。
“輕高精地圖”方案，有的公司是先從城區(qū)場景開始，有的是先從高速場景開始。
在高速場景，多家公司的方案在“輕高精地圖”的同時，還實現了“去高精定位”（省去了高精RTK），使系統(tǒng)成本降低了20%以上。
（據Robotaxi公司的說法，去高精地圖，主要適用于高階版的ADAS，而L4還是需要高精地圖作為冗余。）
當然，“輕高精地圖”不等于“輕地圖”——新方案對導航地圖的依賴度還是挺高的。當前，“輕高精地圖”后，感知環(huán)節(jié)有三種“補償方案”：
（1）純視覺眾包建圖
即完全數據驅動的視覺建圖，駕駛過程中視覺識別標志牌、車道線標識，識別特征點從而實時建圖，向系統(tǒng)反饋導航情況。這種方案對視覺感知要求高，門檻較高。目前，采用這一方案的典型公司是特斯拉。
（2）車機導航地圖
將現有標配的車機導航地圖，通過ADAS V2或V3的協(xié)議，得到導航地圖的更多、更細致的信息，從而取代高精地圖。
（3）SD Pro導航地圖
SD Pro地圖不像高精地圖里面有詳細的車道線等方面的信息，但比普通的導航地圖信息更豐富——會有車道數、車道屬性變化點，并以點的形式表達復雜的車道和路口連通信息、并以屬性的方式表達車道寬度等相關信息，作用就是在復雜路口、道路分歧合流等復雜駕駛場景提供關鍵定位和規(guī)控所使用的地圖信息，也可以幫助BEV算法來建圖。
我們可以將SD Pro導航地圖理解為一種簡化版的高精地圖或傳統(tǒng)ADAS車機導航地圖的升級版；但由于沒有更詳細的幾何信息，所以，SD Pro地圖的制作和發(fā)布要比HD地圖快。
SD Pro地圖的代表性玩家有騰訊和美行科技。其中，美行在本次上海車展期間官宣了跟地平線和領駿科技的合作。
美行的SD Pro是通過利用眾源數據生成的。所謂眾源數據，不僅包括攝像頭采集的數據，還包括來自路端的數據、來自衛(wèi)星的數據。這種方案的最大優(yōu)勢是成本低、便于落地。
對取得甲級測繪資質比較晚的圖商來說，如果做全國范圍的傳統(tǒng)模式的高精度地圖采集，無論時間上還是投入上，跟老牌圖商都沒法競爭。因此，美行將自己定義為新圖商，選擇眾源方案作為當前的最優(yōu)路徑，眾源采集的數據歸屬于主機廠，美行負責搭建平臺、數據采集處理以及合規(guī)存儲使用等。
美行方面稱，其眾源地圖系統(tǒng)已于2022年完成商業(yè)化首單的簽署，并于當年內完成全功能。
與SD Pro類似的一個概念是“輕量級高精地圖”（LD map）——不做路燈牌等不影響行車功能的因素，只做車道線、停止線等必備的地圖要素。
無論叫SD pro還是LD map，本質上都是把自動駕駛對地圖的關鍵信息提取出來，然后又不依賴于全面的建圖和生產，成本上比HD地圖降低了不少。
不過，這個SD Pro導航地圖或“輕量級高精地圖”也需要甲級測繪資質。
3.去高精地圖與輕高精地圖的區(qū)別
說到這里，我們需要澄清兩個概念：輕高精地圖（多數公司都在提），去高精地圖（代表性公司有華為、小鵬、元戎啟行）。?那么，在技術上，這兩個概念有區(qū)別嗎？
某自動駕駛公司感知部門一位技術人員的答案是：沒有本質區(qū)別。
那為什么會有“輕高精地圖”和“去高精地圖”這兩個不同的說法呢？區(qū)別在，導航地圖、感知數據中的道路拓撲信息算不算“高精地圖”的一部分？如果算，那就是“輕高精地圖”，如果不算，那就是“去高精地圖”。
據此，究竟是“輕高精地圖”還是“去高精地圖”，完全取決于你怎么定義什么是“高精地圖”。
不過，來自某高精地圖公司的一位專家的說法卻是：有區(qū)別。
“輕高精地圖”是去除高精地圖中的桿、路燈等非必須拓撲要素，其實只是將高精地圖的一些內容去掉，將數據存儲和傳輸減少，做到輕量，可以降低高精地圖作業(yè)成本，但本質上還是有數據回傳、需要有個離線建圖的“生產線”和流程；
“去高精度地圖”本質上是基于靜態(tài)元素的感知數據直接在車端還原出道路拓撲要素，但這些數據在車端“閱后即焚”（用完就丟掉），沒有數據回傳、沒有離線建圖流程和存儲維護。
去年9月份，某科技媒體發(fā)布的《特斯拉看不上的高精地圖，華為當個寶》一文據說在一些部委里引起了很大反響。當時，有高精地圖領域的朋友問筆者怎么看，筆者的回答是：
從標題非要加個定語“特斯拉看不上”來看，這篇文章的作者已經默認自己的目標用戶是外行（似乎作者擔心，如果不加這個定語，他那些外行讀者們根本就無法理解“什么是高精地圖”。我不太理解，這種“默認讀者是外行”的文章，我有什么打開的必要？
結果，被啪啪打臉了吧。在各家都嚷著“重感知，輕高精地圖”的上海車展前后 ，華為是第一家推出了“去高精地圖”方案的公司。
4.“輕/去高精地圖面臨的挑戰(zhàn)”
看上去，“去高精地圖”方案可以繞開高精地圖資質的限制，也大幅度降低成本，但要實現起來卻特別難。
挑戰(zhàn)首先來自感知算法的工程化環(huán)節(jié)。比如，通過8~11個攝像頭完成實時建圖，要求車道線連續(xù)且平滑，這對感知系統(tǒng)的準確度及穩(wěn)定性提出了很高的要求。
而據36氪及HiEV此前的報道，小馬CTO樓天城就認為，擺脫高精地圖，不僅僅是感知板塊的挑戰(zhàn)，而是預測、規(guī)控等所有模塊的同步提升。
在36氪此前的報道中，一位智能駕駛算法工程師舉了個例子，去高精地圖后，需要車輛的感知模塊能實時判斷哪個紅綠燈，控制的是哪條對應車道，“人有時候都會弄錯，更何況是車輛。
此外，36氪的報道中還提到，去高精地圖意味著自動駕駛系統(tǒng)對于車道線、可通行區(qū)域等的獲取結果變差了，比如車道線的精度沒有那么高了、識別的距離變短了，因此，下游的決策和控制環(huán)節(jié)就要有為感知不準確“兜底”的能力，這對決策控制環(huán)節(jié)提出了更高的要求。
九章智駕在最近的行業(yè)交流中也了解到，真正影響Mapless技術路線落地的最大難點在于規(guī)控——大多數公司的規(guī)控方案基于高精地圖，容不得一絲差距。
某自動駕駛公司項目經理告訴九章智駕：“我跟做算法的同事在聊‘重感知，輕高精地圖’話題時，大家都支支吾吾的，所以，我一直不清楚這個方案的置信度到底有多高。”
七、感知算法訓練或將受到數據合規(guī)政策的影響
前段時間，筆者從高精地圖公司寬凳科技的官方微信公眾號上看到這么一句話：感知的結果，一旦存儲或回傳，就需要有相應地圖資質的單位管理，而圖商一般都擁有對應的地圖資質。
按照這個說法，受數據合規(guī)相關法規(guī)政策影響的，就不限于高精地圖數據了，還有用于感知算法的數據回傳。?這是真的嗎？
帶著這個疑問，九章跟多家主機廠及自動駕駛公司負責政策研究、GR的朋友確認了一下，得到的答案是：真的。
還有人特別補充了一句，只要數據被認定為“測繪數據”，不管用途是什么，其收集、回傳、處理等活動都需要有資質企業(yè)實施，或委托有資質企業(yè)實施——感知結果會包含自車周邊環(huán)境信息，如實景影像、空間位置坐標等，一旦含測繪法定義的地理信息，則都屬于“測繪數據”范疇。
一位測繪領域資深專家稱：感知里面有動態(tài)數據和靜態(tài)數據，其中的靜態(tài)數據其實就是地圖數據。
他還提到，自然資源部里有專家就認為，激光雷達的數據（可以據此還原出車輛的地理坐標信息——哪怕只回傳了局部信息，最終仍然有辦法還原出全局信息）一定算“測繪數據”；至于攝像頭數據算不算“測繪數據”、視覺感知數據中的道路拓撲信息算不算“高精地圖”的一部分，目前尚無定論。
這位專家還稱：“假如攝像頭的數據也被認定為‘測繪數據’（畢竟，BEV感知“再往前一步就能做高精地圖”），純外資的算法公司，以及希望涉足到感知環(huán)節(jié)的芯片廠商，就會遭遇很大挑戰(zhàn)。”
可見，用真實道路數據做算法訓練的難度是越來越大了——不是沒法做，關鍵是對車端脫敏的要求太高了，甚至可能還需要跟有測繪資質的圖商合作。
或許，在今后，感知算法訓練環(huán)節(jié)對合成數據的需求會比之前更旺盛了。實際上，一些嗅覺靈敏的創(chuàng)業(yè)者已開始涉足該領域。
比如，前蔚來仿真負責人謝晨于今年初創(chuàng)辦的光輪智能——光輪智能的定位是利用生成式AI技術與仿真結合來生產合成數據。自動駕駛感知訓練是這些合成數據的第一個應用場景。不同于大多數公司的仿真只能用來做測試，光輪通過仿真和生成式AI的結合還可用于算法訓練。
之前，筆者曾向某頭部新勢力的資深自動駕駛感專家請教：“我之前跟很多仿真公司做過交流，大多都說目前還‘不能用仿真做訓練’，這背后的原因是什么？”
對方的解釋是:“用仿真做訓練，對圖像渲染能力要求很高，在這方面最擅長的公司是英偉達。前蔚來的仿真負責人謝晨你認識嗎？謝晨在加入蔚來之前是英偉達的仿真負責人，在國內，能用仿真做算法訓練的，估計就只有謝晨的新公司光輪了?！?/p>
目前，光輪的合成數據已經被應用于某L4背景的自動駕駛公司的算法訓練及“去高精地圖”方案中——“去高精地圖”需要感知系統(tǒng)熟悉各種小樣本的結構化地圖信息，比如特殊的交通路口、指示燈、車道線、路況、清晰度等等，而合成數據將小樣本地圖特征大規(guī)模泛化的優(yōu)勢很好地幫助到了“去高精地圖”。
八、“中國研發(fā)，德國應用”
車展第二日，在地平線組織的一場生態(tài)沙龍上，均聯智行中國區(qū)CTO陳遠提到，以前，自動駕駛、智能座艙等相關技術都是先在德國研發(fā)，然后引入到中國應用；但從兩年前開始，他們的很多自動駕駛相關技術都是在中國研發(fā)，然后再出口到海外。
陳遠還特別強調，現在，他們所有項目的軟硬件研發(fā)基本都在中國，不在德國了。
或許，接下來，在德國本土研發(fā)自動駕駛受挫的大眾等主機廠也可能這么干？
下載ECAD模型
