自動駕駛數據閉環的理想與現實

近年來，數據閉環成了自動駕駛行業的熱門話題，許多自動駕駛公司都在試圖打造自己的數據閉環系統。

實際上，資料閉環並不是一個新的概念。在傳統軟體工程領域，資料閉環被用來作為改善使用者體驗的重要方式。相信大家都有過這樣的經歷，在使用軟體時，螢幕上跳出一個彈窗，詢問你“是否允許該軟體收集你的數據”，如果你同意相關條例，那這些數據便會被用來改進用戶體驗。

當用戶端軟體捕捉到一個問題時，後台能抓取相應數據，然後由開發團隊分析此問題後對軟體做修復和完善，交由測試團隊測試好新版本軟體，之後會將新版本軟體放在雲端，並由使用者更新到終端，這是軟體工程中資料閉環的流程。

在自動駕駛場景中，問題數據通常是在試驗車上收集，極少數車輛能實現在量產車上收集。收集後需要對資料做標註，然後工程師在雲端用新的資料訓練神經網路模型，重新訓練後的模型通常會透過OTA的方式部署到車端。

一個完整的資料閉環通常包括資料收集、資料回流、資料處理、資料標註、模型訓練、測試驗證這幾個環節。

Momenta資料閉環流程示意

以特斯拉為例，配置了自動駕駛硬體的車隊採集通過規則及影子模式下的觸發器篩選的數據，經過語意篩選後的數據被回傳到雲端。此後，工程師在雲端用工具對資料做一些處理，再把處理好的資料放入資料集群，然後再利用這些有效資料訓練模型。模型訓練好之後，工程師會把訓練好的模型部署回車端做一系列的指標偵測，經過驗證的新模型會被部署到車端供駕駛者使用。

在這種模型下，會有新的資料來源來源不斷被觸發回傳，從而形成循環。此時，一個完整的由資料驅動的迭代開發循環便形成了。

目前，採用資料閉環來驅動演算法迭代，幾乎已經被公認為是提升自動駕駛能力的必經之路。很多主機廠和自動駕駛Tier1都在搭建自己的資料閉環系統，甚至還特別設定了資料閉環架構師的職位。

資料閉環的意義是什麼？數據閉環能夠在量產車上落地的背景是什麼？數據閉環在量產車上落地的過程中有哪些痛點以及如何應對？

接下來，本文將圍繞這些主題逐一討論。

01 資料閉環的意義

#根據智駕科技MAXIEYE的介紹，「資料閉環對於產品的性能，不僅僅是某個功能的效能提高，還能以影子模式的形式驗證新功能。同時根據資料觸發的類別，對於系統的其他方面也可以幫助優化，例如radar/camera blockage 的檢測，可以根據回傳資料優化閾值。在效能層面，資料回傳基本上可以優化所有的效能，例如AEB，LKA，ELK，ACC，TJA，NOA等。MAXIEYE已透過資料回傳OTA不斷升級AEB, ACC, TJA 等系統功能，而且預埋了新功能的影子模式。」

如今，各家公司紛紛打造自己的資料閉環系統，主要希望實現的效果包括提升corner case資料擷取效率、提升模型的泛化能力以及驅動演算法的迭代。

1.1 蒐集corner case的資料

只要是L2及L2以上的產品，都需要具備持續進化的能力。要讓自動駕駛系統持續進化，就需要不斷獲得corner case的數據。而隨著越來越多的corner case從“未知”轉換成“已知”，通過數量有限、形式路線也有限的測試車輛挖掘出新的corner case的難度越來越大。

透過在場景覆蓋度更廣的量產車上部署資料擷取系統，在遇到目前的自動駕駛系統處理地得不夠好的情況時，觸發資料回傳，是一種比較好的獲取corner case的方法。

例如，可以在搭載L2輔助駕駛的量產車上部署AEB系統，然後收集駕駛猛踩煞車、猛踩油門、猛打轉向、猛打方向盤等的數據，分析為什麼駕駛員在做這些操作的時候AEB系統沒有任何回應。針對AEB系統應對地不夠好的問題做相應改進，提升AEB系統的能力。

1.2 提升模型的泛化能力

目前，高等級的輔助駕駛正從高速向城市進軍。要解決高速這樣相對簡單的場景，基本上，僅靠測試車採集的數據來訓練模型就夠了，而不是一定要回傳量產車的數據；然而，城市場景的複雜度大幅提升了，而且不同城市的路況也有很多差異。例如，在廣州，隨處可見拉著貨物的三輪車在道路上疾馳，而在上海就很少見到這種情況。

因此，許多自動駕駛Tier1以及車企對場景打通的訴求很強烈－即車輛的輔助駕駛系統可妥善應對各主流城市的各種路況。因為車企無法限制用戶的行駛範圍，假如只針對很小的區域做好輔助駕駛功能，會大大縮小用戶群的範圍，這顯然不是車企希望看到的。

要達成場景打通的目標，模型的泛化能力就需要大幅提升。要大幅提升模型的泛化能力，就要盡可能地把各種各樣的場景對應的資料都收集到。而只有基於大規模真實人駕數據的乘用車輔助駕駛才有能力累積到足夠規模和足夠多樣化的數據。

1.3 驅動演算法迭代 

前文提到，基於深度學習的人工智慧演算法發展已經超過十年。這段期間，隨著模型的演進以及算力的發展，自動駕駛系統對大數據的消化成為可能。此外，自動駕駛系統要升級，感知、規劃等環節都需要在能力上有相應的提升，而採用數據驅動，讓演算法持續不斷地進化，是提升感知、規劃等環節能力的一個高效的方式。

城市NOA－也就是城市內的點對點導航輔助功能是許多主機廠以及自動駕駛Tier1接下來的發力點，要實現點對點的導航輔助駕駛功能，感知系統的語意辨識、障礙物辨識、可行駛區域的辨識都需要具備一定的精確度，然而目前這項標準尚未實現。

目前主流的感知系統網路架構是基於BEV Transformer模型，單純依賴軟體工程師或演算法架構師來優化，模型可以提升的空間不太多，而BEV Transformer的架構可以容納大量的數據，進而有望讓模型效果提升。

在規劃層面，資料驅動也可以發揮作用。特斯拉早先使用部分限制下的最優方案作為初值，然後採用遞增的方式不斷加入新的約束，再求解增加約束後的最佳化問題，最終得到規劃問題的最適。特斯拉工程師針對此方法離線做了很多預生成，並在線上做了並行優化，這樣每個候選路徑的計算時間仍然長達1～5ms。而根據特斯拉在2022年9月30日的AI day上揭露的內容，特斯拉的工程師現在使用了一套資料驅動的決策樹產生模型來幫助自動駕駛系統快速產生規劃路徑。這個資料驅動的決策樹生成模型使用特斯拉車隊中人類駕駛員駕駛資料和無時間約束下的最優路徑作為真值進行訓練，能夠在100us內產生一個候選規劃路徑，大大縮短了生成候選規劃路徑的時間。

綜上可見，建置好資料閉迴路系統是自動駕駛系統能力提升的重要方式。

02 數據閉環的背景

#目前，許多量產車上都搭載了輔助駕駛系統，人們可以在量產車上採集數據，自動駕駛系統的路測里程超過1億公里已非難事。此外，晶片算力進一步增強－例如英偉達的OrinX晶片算力可達254TOPS，因此大模型開始被應用於感知系統，自動駕駛系統對大數據的消化成為可能。另一方面雲端技術較成熟，自動駕駛開始慢慢進入數據驅動的時代。

MAXIEYE公司方面的解釋是：「確切地說，現在不只是數據驅動，而是AI演算法和數據共同驅動。AI演算法解決的是學習效率的問題，數據解決的是學習內容的問題，演算法和資料是共生關係。」

「基於深度學習的人工智慧演算法的發展已經超過了十年，在這十年間的早期階段，監督學習是學術界和工業界的主流，而監督學習有一個致命的缺陷，就是需要大量的人工標註，這大大的限制了AI的進步空間，但在近幾年，無監督和半監督學習演算法慢慢地開始興起，電腦可以透過自學習的方式不斷地對資料進行清洗以及對演算法進行自我迭代，因此，透過資料驅動的方式開發自動駕駛技術的條件已經成熟。」 

長城沙龍智慧化中心負責人楊繼峰在一次演講中提到：「從整車角度上，2022年完成了L2到L4的架構閉環和資料閉環，車端架構和雲端架構的進一步統一。接下來的競爭是資料探勘、資料的有效利用以及整個技術堆疊對資料的理解，以及如何在大規模的基礎設施上平衡整個運算效率。」

03 資料閉環落地的痛點及對策

目前，大家關於數據閉環對於自動駕駛系統的意義已達成共識，數據閉環在量產車上的落地的時機也基本成熟。那麼，各家的數據閉環實際落地的情況如何？我們如何評判一家公司資料閉環系統搭建的效果呢？

筆者從智駕科技MAXIEYE了解到，對於自動駕駛Tier1來講，技術上實現數據閉環其實不是難題，本質上看的是該Tier1的產品實力——是否能透過數據閉環賦能車廠。其次，資料閉環的效果還要看產品的迭代是否由資料閉環驅動，是否能基於回傳資料實現軟體及演算法的最佳化，並定期透過OTA部署到終端。

目前，根據資料閉環能力的高低，自動駕駛Tier 1可分為三類：第一種是已經實現規模化量產的資料閉環，第二種是透過採集車實現閉環，第三種是還沒有實現數據閉環的能力。目前來看，第一種還屬於少數。

根據筆者和業內人士交流得到的訊息，目前大部分公司的資料來源都是採集車。由於用戶隱私、基礎設施、成本等種種因素，在量產車上大規模採集資料用於自動駕駛系統的迭代升級尚未實現。有的公司尚未搭建好在量產車上採集數據用於數據閉環的流程，有的公司雖然搭建好了流程，也採集了一些數據，但尚未將數據很好地用起來。

據悉，少數公司會從量產車上收集一些數據，但業內人士反映目前採集這些數據主要是用來診斷當前的自動駕駛系統存在的故障等，而非用於深度學習模型的迭代。

也即是說，目前很少有公司真正實現了規模化量產的數據閉環——即用好從大規模量產車上採集的數據來實現自動駕駛系統能力的提升。那麼，數據閉環的量產落地究竟有哪些痛點呢？針對這些痛點，有什麼樣的因應策略呢？

量產落地的實務上需要考慮的問題包括但不限於：如何保證資料收集與使用的合規性、資料確權問題如何解決、資料擷取功能如何與自動駕駛系統共存、資料處理難度高、資料驅動的軟體系統複雜度高、模型訓練難度高等。

3.1 資料擷取與所使用的合規性問題

分為測繪合規和隱私合規：測繪合規主要涉及到收集國家地理資訊時的合規，隱私合規主要涉及到收集使用者隱私相關資料的合規。

測繪合規方面，近幾年，國家對資料安全的管理趨嚴，推出了相關法律法規來對回傳資料的範圍進行限制。 2022 年 「830 新規」之後，車輛在道路上收集的資料都屬於測繪​​資料。企業要使用測繪數據，後續的數據加密、數據合規的環節不可或缺。

首先，在道路上採集資料的時候，企業需要具備國家測繪資質，並且要做相應的備案，否則採集過程中會被國安等部門阻止。目前，國內總共有約30家機構具備相關資質，有的企業具備國家電子導航甲級資質，適用範圍較廣，在國內多個城市都可以採集，而有的企業具備乙級資質，適用範圍就會更小，只能在特定的城市採集。

由於測繪資質很難獲取，需要有長期的業務積累，並且，要保有測繪資質，企業就需要有相應的測繪業務。因此，主機廠以及自動駕駛Tier1一般會委託有資格的供應商或單位，例如現在有些雲廠商會幫助客戶圍繞數據的獲取、加工、使用來設計一個合規方案。

採集到資料後，還需要在車端脫敏、加密，上雲之後（一般來講是私有雲），還需要做一些合規工作，這一部分會由有資格的供應商或單位來幫忙做測繪的合規。對於部分很敏感的數據，需要由圖商來做採集，而且數據需要在脫敏之後儲存在圖商監管的伺服器裡。

另外，測繪的數據不得洩漏，尤其是不得將數據挪到國外，非中國國籍的人既不能取得測繪數據，也不能在公司內操作測繪數據。

一般來說，主機廠和自動駕駛Tier1會建立自己的資料中心，出於安全考慮，這些資料中心都比較封閉。主機廠和自動駕駛Tier1需要使用這些資料中心儲存的資料來做一些訓練、模擬等工作的時候，基於合規要求，需要將相關模型部署到資料中心來使用。

有業內專家表示，「測繪的合規流程太複雜，資質也很難獲取，大家希望盡可能減少對高精地圖的依賴，這是目前業界流行'重感知輕地圖'方案的一部分原因。但實際上，輕地圖不一定就是'更好'，因為有地圖數據效果肯定比沒有好。目前這個趨勢不一定是最終的形態，也不一定是最好的，只是大家希望能做得更簡單一點。」

隱私合規方面，企業在量產車上採集數據，需要用戶授權。類似於用微信的時候，企業需要使用者在一開始簽署授權協議，並告知使用者哪些資料會被收集，哪些使用行為會被記錄下來。

目前在隱私合規方面，國家尚未出台特別具體的方案規定哪些數據可以採哪些不可以，而是僅有一個相對寬泛的條款來規定數據採集方“不得洩漏用戶隱私」。

實際操作中，涉及到使用者資訊的資料需要做脫敏，例如車牌號碼需要隱去等。

3.2 資料確權問題

#我們是否可以在車上採集自動駕駛產業所需的攝影機、激光或毫米波形成的數據呢？

魔視智慧產品經理蘇林飛介紹道：「根據中國的《個人資訊保護法》相關規定，非法律允許的資料收集受到隱私保護。在德國，原德國聯邦資訊保護局有這樣的規定，如果司機不是受害者，未經對方同意就記錄其他司機的臉和車輛，是違反個人資訊保護法的。也就是說，即使是車主記錄別人資訊也可能屬於違法。但由於和新能源車伴生的自動駕駛行業很新，法律規定目前尚屬空缺，所以我們按照基本法學理念推導，量產車採集的數據應該由車主擁有。」

那車主使用自己的車輛所收集的資料是否可以授權給其他單位使用呢？

目前並沒有相關法律規定與約束。但在其他行業，如手機、網路領域，是廣泛允許的。

誰可以拿到車主上傳的資料？

從汽車產業鏈分工看，2種主體可以拿到，第1種是無人車隊營運公司，例如百度的無人駕駛計程車，第2種是主機廠。但由於前者規模較小，所以我們將重點放在後者。

由於主機工廠離使用者最近，所以最容易拿到使用者上傳的資料。在全球範圍看，Tesla是在這方面做地最好的主機工廠。 

#

目前，主機廠很少對外開放數據，導致自動駕駛Tier1在幫助主機廠實現了主機廠定制的功能後，很難收集到用戶在使用這些功能時的反饋數據，除非Tier1自己有很多測試車。那麼，自動駕駛Tier1就難以根據使用者回饋的資料對相關功能做後續的優化，資料閉環就難以實現。

魔視智慧產品經理蘇林飛告訴筆者：「我們在幫主機廠做完一個專案之後，假如主機廠不開放資料接口，我們就很難拿到使用者的回饋數據，進而針對此車型進一步迭代產品性能。最後大部分自動駕駛系統供應商成為了以項目運作為核心的公司，進而隨著產品性能的落後慢慢被淘汰。

#更糟的是，由於自動駕駛系統原始碼開源的趨勢已經顯現，有的主機廠會希望自己搭建數據閉環系統來實現自動駕駛的功能，因而也不願意把數據分享給供應商。但主機廠這樣做我認為並不合理，我認為從自動駕駛整體的生態來講，最好還是大家各司其職，專業的人做專業的事。只是目前行業還處於比較早期的發展階段，可能大家都會想嘗試，從而把握更大的主動權。」

某新能源主機廠專家表示：「以前主機廠不願意把數據給供應商是沒想明白供應商可以怎麼回饋自己，可能給了資料之後對方也不知道要如何使用。但是現在，對於合作的供應商，例如給主機廠提供自動駕駛解決方案的，主機廠是可以開放資料使用權的。當然了，開放資料使用權的前提是合規，供應商在接收主機廠提供的資料以及在使用資料時都需要保證整個流程是合規的。」

對主機廠來說，假如不把資料開放給供應商，那麼就自己發掘這些資料的價值。早期的時候，大家都不太知道這些數據具體有什麼價值，需要用起來才能慢慢發現價值。主機廠可以把資料先給供應商使用，同時自己留一份，供應商發掘出資料的價值之後再回饋主機廠。

現在有的主機廠會要求供應商在sop之後仍能持續地幫助他們迭代軟體，而供應商也可以以此為契機獲得數據，如此一來主機廠和供應商可以實現雙贏。當然了，站在主機廠的角度，目前這種方式仍然存在一些瑕疵，因為供應商很難保證迭代後效果一定會變好。主機廠也很難驗證迭代效果，所以主機廠常常反向要求供應商開放中間結果（例如感知目標識別結果）資料的接口，這樣主機廠就可以透過針對中間結果的統計指標來驗證供應商的迭代效果。

目前，主要需要雙方本著互相信任，真誠合作的心態，主機廠開放資料使用權給供應商，然後供應商定期更新軟體，並且能看到相應的效果，這樣合作就能持續下去。只是目前這個模式尚未被廣泛接受，因為大家尚未看到明顯的效果。

3.3 資料收集會佔用系統資源 

在量產車上採集資料會佔用一些系統資源，比如運算、儲存等。理論上，可以假設運算資源、網路頻寬等都不受限制，但在實際落地過程中，如何保證擷取資料不會影響量產車上自動駕駛系統的正常運行，例如，如何不影響自動駕駛系統的延遲等等，這是一個需要解決的問題。

當然了，有的公司會在自動駕駛系統不運作的時候再上傳數據，這樣就不存在資源佔用的問題。但也有業內人士認為，光是自動駕駛系統不運作的時候上傳資料就會限制資料的採集量，現階段還是要盡量採集資料。那麼，在設計的時候，就需要考慮到採集資料等對自動駕駛系統運作的影響。

3.4 資料標註及後續處理的難度大

據估計，從量產車回傳資料後，單車每日回傳的數據量大概是百兆級。研發階段，車輛總數可能只有幾十輛或幾百輛。但到了量產階段，車輛數目的量級可以達到上萬、幾十萬甚至更多。那麼，量產階段，整個車隊日產生的資料量就是很大的數字。

急劇增加的資料量為儲存空間以及資料處理的速度都帶來了挑戰。量產之後，資料處理的延遲需求和研發階段維持在同一個量級。但如果底層的基礎設施跟不上，資料處理的延遲就會隨著資料量的成長而相應地增加，這會大大拖慢研發流程的進度。對於系統迭代來講，這種效率的降低是不可接受的。

一位業界專家告訴筆者，「目前，我們還沒有看到哪家公司具備處理量產車上回傳的大規模數據的能力。即使是某家在數據閉環層面做得比較前沿的造車新勢力，即便是每輛量產車每天只回傳5分鐘的數據，他們也難以應付這樣的數據量，因為目前的儲存設備、文件讀取系統、計算工具等都還無法應付極大的資料量。」

要應付越來越大的資料量，底層的基礎設施以及平台的設計都需要相應升級。

工程團隊需要開發完善的資料存取SDK。由於視覺資料、雷達資料的檔案尺寸都非常大，資料的存取、查詢、跳轉、解碼過程都需要效率夠高，否則會大幅拖慢研發進度。 

車端資料回傳到雲端後，工程團隊需要及時給予大量資料標註。業界目前會藉助預訓練模型來做輔助標註，但資料量很大時，標註仍需要大量的工作量。

在做資料標註的時候，還需要確保標註結果的一致性。目前，業界尚未實現全自動資料標註，仍需要人工完成部分工作量。在手動操作的時候，如何在資料量極大的情況下，確保標註結果的一致性也是一大挑戰。

此外，與自動駕駛相關的數據不僅量大，而且種類龐雜，這也為數據處理增加了難度。資料類型依來源劃分包括車輛資料、位置資料、環境感知資料、應用資料、個人資料等等，依格式劃分包含結構化資料和非結構化資料，資料的服務類型涵蓋文件、物件等，如何統一標準，協調不同類型的儲存、存取介面也是一大難題。

3.5 資料驅動的軟體系統複雜度高

傳統的V字型開發模式很難適用於數據閉環。而且，目前業界還沒有形成統一的面向高等級自動駕駛的軟體開發平台及中間件。

某公司自動駕駛部門的技術專家告訴筆者，「以數據和深度學習模型驅動的自動駕駛功能迭代體係可以稱之為軟體2.0。在這樣的模式下，整個體系，包括團隊的建構、研發流程、測試方法、工具鏈都是圍繞資料建構的。」

在軟體1.0時代，每個人提交了什麼程式碼，預期的效果都是很容易評估的。但是，在軟體2.0時代，每個人貢獻的部分對整體效果的影響的衡量難度變大了，而且也很難事先預期，因為大家相互交流的不再是清晰可見的代碼，而是數據以及根據數據更新的模型。

在資料量很少的時候，例如我們之前做行動網路應用的AI視覺演算法，由於資料量很少，涉及的視覺模型工程師，大家基本上是Windows或Ubuntu的資料夾各自管理，團隊成員互相之間直接用各種重新命名的資料夾來回傳輸，非常低效進行資料交換或合作。

但是涉及到自動駕駛任務時，我們面臨的是幾十萬張圖片，而且是幾百人共同研發一個系統，每次改動涉及到的的模組可能都是上百乃至上千。如何評測每個模組的程式碼質量，如何檢驗各模組之間是否有衝突，這些都是較為複雜的任務。到目前為止，我認為這套系統仍較為糟糕，工程化部分還不夠成熟。

到了軟體2.0階段，還需要處理的問題是：如何衡量新增的資料對特定的場景和對全局的影響分別是什麼，如何避免基於新增資料重新訓練的模型在一些特定任務上效果變好但整體上效果下降。要解決這些問題，我們需要做單元測試，來檢驗新增部分資料後，對我們希望解決的細分場景有沒有幫助以及對全域有沒有幫助。

舉例來講，假如針對某個特定的任務，原始的資料集是2000萬張圖片，然後新增500張圖片，解決這個特定任務的能力提升了，但有時這也同時意味著模型在應對全局任務時得分降低。

此外，針對視覺任務，除了根據指標來判斷新增資料對模型的影響，我們還需要實際去看具體的影響是什麼，這樣才能知道最佳化是否符合預期。僅透過指標來看可能會出現雖然指標提升了但實際效果仍不符合預期的情況。

我們還需要有一套基礎設施，來確保每次做的更新是全域最優的。這套基礎設施會牽涉到資料的管理、訓練的評測等。特斯拉在這個方面是走在行業前列的，它關於數據驅動的整條鏈路從一開始的設計上就是領先全行業而且從2019到2022年，不需要太大的改變就能支撐產品的迭代。

3.6  模型訓練難度增加

#解決了資料收集、儲存、標註等問題後，後續的模型訓練、功能迭代仍是挑戰。

訓練量產車上回傳的大量數據，需要有高效的文件傳輸系統，保證訓練時不會被I/O「卡脖子」。

同時，還要有充足的算力。提高算力的方式通常是打造多卡並行的集群，那麼，如何在訓練時保持高效的卡間通信來減少數據傳輸的延遲從而充分有效地利用每張卡的算力也是需要考慮的問題。

為因應模型訓練對算力的需求，有主機廠專門打造了自己的智算中心。然而，打造智算中心的成本很高，對中小企業來說，這幾乎是一件不可能的事。

儘管目前仍有諸多痛點，但我們仍然可以預期，假以時日，目前存在的問題會被逐一解決。屆時，數據閉環能在量產車上真正落地，在量產車上落地後採集的數據將反哺式數據閉環系統，推動自動駕駛系統邁向更高階。

以上是自動駕駛數據閉環的理想與現實的詳細內容。更多資訊請關注PHP中文網其他相關文章！