沃卡惠近年來，數據閉環成了自動駕駛行業的一個熱門話題，很多自動駕駛公司都在試圖打造自己的數據閉環系統。
實際上，數據閉環并不是一個新的概念。在傳統軟件工程領域，數據閉環被用來作為改進用戶體驗的一種重要方式。相信大家都有過這樣的經歷，在使用軟件時，屏幕上跳出一個彈窗，詢問你“是否允許該軟件收集你的數據”，如果你同意相關條例，那這些數據便會被用來改進用戶體驗。
當用戶端軟件捕捉到一個問題時，后臺能抓取相應數據，然后由開發團隊分析此問題后對軟件做修復和完善，交由測試團隊測試好新版本軟件，之后會將新版本軟件放在云端，并由用戶更新到終端，這是軟件工程中數據閉環的流程。
在自動駕駛場景中，問題數據通常是在試驗車上收集，極少數車輛能實現在量產車上收集。收集后需要對數據做標注，然后工程師在云端用新的數據訓練神經網絡模型，重新訓練后的模型通常會通過OTA的方式部署到車端。
一個完整的數據閉環通常包括數據采集、數據回流、數據處理、數據標注、模型訓練、測試驗證這幾個環節。
Momenta數據閉環流程示意
以特斯拉為例，配置了自動駕駛硬件的車隊采集通過規則及影子模式下的觸發器篩選的數據，經過語義篩選后的數據被回傳到云端。此后，工程師在云端用工具對數據做一些處理，再把處理好的數據放入數據集群，然后利用這些有效數據訓練模型。模型訓練好之后，工程師會把訓練好的模型部署回車端做一系列的指標檢測，經過驗證的新模型會被部署到車端供駕駛員使用。
在這種模型下，會有新的數據源源不斷被觸發回傳，從而形成循環。此時，一個完整的由數據驅動的迭代開發循環便形成了。
目前，采用數據閉環來驅動算法迭代，幾乎已經被公認為是提升自動駕駛能力的必由之路。很多主機廠和自動駕駛Tier1都在搭建自己的數據閉環系統，甚至還專門設置了數據閉環架構師的職位。
數據閉環的意義是什么？數據閉環能夠在量產車上落地的背景是什么？數據閉環在量產車上落地的過程中有哪些痛點以及如何應對？
接下來，本文將圍繞這些話題逐一討論。
根據智駕科技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內生成一個候選規劃路徑，大大縮短了生成候選規劃路徑的時間。
綜上可見，搭建好數據閉環系統是自動駕駛系統能力提升的一個重要方式。
當前，許多量產車上都搭載了輔助駕駛系統，人們可以在量產車上采集數據，自動駕駛系統的路測里程超過1億公里已非難事。此外，芯片算力進一步增強——例如英偉達的OrinX芯片算力可達254TOPS，因此大模型開始被應用于感知系統，自動駕駛系統對大數據的消化成為可能。另一方面云端技術較為成熟，自動駕駛開始慢慢進入數據驅動的時代。
MAXIEYE公司方面的解釋是：“確切地來說，現在不僅僅是數據驅動，而是AI算法和數據共同驅動。AI算法解決的是學習效率的問題，數據解決的是學習內容的問題，算法和數據是共生關系。”
“基于深度學習的人工智能算法的發展已經超過了十年，在這十年間的早期階段，監督學習是學術界和工業界的主流，而監督學習有一個致命的缺陷，就是需要大量的人工標注，這大大的限制了AI的進步空間，但在近幾年，無監督和半監督學習算法慢慢地開始興起，計算機可以通過自學習的方式不斷地對數據進行清洗以及對算法進行自我迭代，因此，通過數據驅動的方式開發自動駕駛技術的條件已經成熟。”
長城沙龍智能化中心負責人楊繼峰在一次演講中提到：“從整車角度上，2022年完成了L2到L4的架構閉環和數據閉環，車端架構和云端架構的進一步統一。接下來的競爭是數據挖掘、數據的有效利用以及整個技術棧對數據的理解，以及如何在大規模的基礎設施上平衡整個計算效率。”
目前，大家關于數據閉環對于自動駕駛系統的意義已達成共識，數據閉環在量產車上的落地的時機也基本成熟。那么，各家的數據閉環實際落地的情況如何？我們如何去評判一家公司數據閉環系統搭建的效果呢？
筆者從智駕科技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“卡脖子”。
同時，還要有充足的算力。提高算力的方式通常是打造多卡并行的集群，那么，如何在訓練時保持高效的卡間通信來減少數據傳輸的延遲從而充分有效地利用每張卡的算力也是需要考慮的問題。
為應對模型訓練對算力的需求，有主機廠專門打造了自己的智算中心。然而，打造智算中心的成本很高，對于中小企業來說，這幾乎是一件不可能的事情。
盡管當前仍存在諸多痛點，但我們仍然可以預期，假以時日，目前存在的問題會被逐個解決。屆時，數據閉環能在量產車上真正落地，在量產車上落地后采集的數據將反哺數據閉環系統，推動自動駕駛系統走向更高階。
