在和身邊的人溝通自動駕駛的資料閉環時,會碰到兩類典型的人:第一類,當你給他講資料閉環的時候,他的眼神是迷茫的,好像沒有引起太多的重視和共鳴,甚至有人會反饋:“嗯,這個沒什麼,我們以前乾的差不多”;第二類,他會覺得資料閉環,能解決一切問題,而且,資料閉環是一種全新的工作方式。
第一類人低估了資料閉環的重要性,第二類人高估了資料閉環的重要性。
圖1 特斯拉AI高階總監Andrej Karpathy 2020年2月提到的Data Engine引起熱議
雖然,特斯拉AI高階總監 Andrej Karpathy 2020年2月“AI for Full-Self Driving”的演講,是資料閉環熱潮的起點,引起汽車行業的熱議,但是,實際上,資料閉環是一直是軟體工程領域的一種成熟的工作方式,在人工智慧時代,資料閉環並沒有從根本上改變“整體”軟體工程的工作方法,但是,對管理、運營和工具帶來了全新挑戰,因此,我們必須比以前更加重視資料閉環。
傳統資料閉環已經被應用了超過20年
無論是早期的windows,還是最近的安卓,我們在系統使用的過程當中,都會被問到是否允許微軟或者是谷歌收集你的資料[1],幫助改進使用者體驗。這就是傳統的資料閉環。
圖3 Google Fixel 2 Android手機的收集資料的選項介面
在微軟Office軟體崩潰(Crash)後,你也能夠看到一個彈出對話方塊,問你是否允許上傳本次崩潰的資訊,幫助微軟改進Office。那這就是最經典的資料閉環。
我們可以看一下,經典的資料閉環是一個什麼樣的工作流程?
比如,終端產品(Office)捕捉到一個崩潰的問題後,軟體上傳現場資料。
然後,軟體廠商的工程師根據這些資料,分析和解決問題。
只有有了這些現場資料,軟體廠商的工程師才能夠了解這到底是什麼問題,才能夠解決這樣的崩潰問題。我們在傳統的軟體工程當中,常說的一句話就是,復現一個問題,等於解決問題的50%。主要是因為傳統的軟體程式碼,太過複雜,使用者操作可能會引發各種Corner Cases,對於各種Crash的異常行為,是無法透過閱讀程式碼來發現問題的。最有效的解決方法,就是能夠復現問題,然後依賴除錯資訊,發現問題所在的模組,然後找到了對應的問題的位置,解決它就相對比較容易了。
軟體工程師解決問題之後,然後要進行測試。因為,軟體程式碼解決問題,也常常會導致其他地方產生新問題,這主要是因為軟體的複雜度大,規模上升。
測試透過之後,釋出新軟體版本:更新檔案複製,或者OTA升級。然後,終端產品驗證問題和繼續反饋資料。
這就是傳統軟體的資料閉環,我們已經應用了這種方法超過了20年(從2000年網際網路大規模應用開始)。
人工智慧時代,資料閉環發生了什麼改變?
我們來看一個例子,在人工智慧時代,資料閉環的工作流程是怎麼樣的?
小鵬P7曾經有一起事故,在開啟NGP模式下以120碼時速無減速撞到了前方約60時速的載物板車[2]。我們以這個例子,看看資料閉環如何幫助小鵬汽車改進。
圖7 小鵬P7在開啟NGP模式下以120碼時速無減速撞到了前方約60時速的板車
首先,在汽車終端設定一個觸發程式,在特定情況時,比如說撞車的時候,把汽車的現場的資料,上傳到伺服器端。除了影象之外,還有地理位置、速度、剎車等資料資訊。
然後仍然需要一位工程師,在後臺分析這些資料,看看這些問題到底在哪裡。因為,問題不一定是AI模型的問題,也可能是邏輯程式碼的問題。比如說前處理、後處理、規劃控制演算法出了問題(規劃控制演算法現在大部分仍是傳統軟體)。
如果這個工程師分析問題的原因不是模型的問題,而是邏輯程式碼的問題(如前處理、後處理、傳統規劃控制程式碼),那麼,資料閉環的使用方式,和傳統的資料閉環完全一致,100%一致。解決問題的成本也是類似的。
這種情況是完全有可能發生的。比如說某造車新勢力汽車的一次撞車事故當中,據悉分析出的原因,Mobileye的感知演算法沒有問題,而是某造車新勢力汽車自己的控制演算法有問題。
但是有另一種可能性,就是經過這個工程師的分析後,發現在這個問題是感知模型的問題。如在小鵬汽車的這起事故中,參考文獻3認為,因為視覺感知系統不能檢測到前方異形車,導致了這次撞車事故。也就是說,要解決這個問題,必須重新訓練人工智慧模型。在這種情況下,人工智慧的資料閉環和傳統的資料閉環在流程上就會有區別。
由於小鵬汽車的自動駕駛系統不能檢測到這種板車,所以,系統之前是沒有上傳這種板車的資料的。小鵬的工程師要把這個問題反饋給自動駕駛產品經理,產品經理要做出資料採集計劃:這個異形車是什麼型號?在中國市場,類似的車哪些常用?從哪些渠道可以採集到資料?採集速度怎麼樣?自動和人工採集各佔多大比例?
再下一步,是根據資料採集計劃,去採集這種異形車的資料。
然後,對採集到的資料安排標註。一般標註環節是少不了人工參與的,雖然機器輔助標註的方法,在後期可能會提高效率。
標註之後,把資料提交給演算法工程師,演算法工程師訓練新的模型。理想情況下,新訓練的模型就具備了識別這樣的異形車的能力。
但是現實世界中,都是非理想情況。所以,和特斯拉的Data Engine一樣,小鵬汽車經過上面的步驟,只能得到一個“初步的檢測器”(approximate detector),即這個模型仍然有很多“板車”不能識別(Corner Cases),這個時候,仍然需要資料閉環,把“初步的檢測器”判定為“疑似板車”的資料上傳到伺服器,作為“自動”的資料採集,經過篩選後,進入到資料標註環節。
注意,即使有了“初步的檢測器”,小鵬汽車的產品經理仍可能計劃人工資料採集,加快專案進度。因為,有可能小鵬汽車不能識別“板車”的輿論壓力很大,等待“初步的檢測器”自動上傳足夠的資料來不及。
大家可以看到,人工智慧資料閉環和傳統資料閉環比較,多了一個分支,在這個分支下,需要透過資料解決模型的問題,包含資料採集計劃、資料採集、資料篩選、資料標註、模型訓練、生成“初步的檢測器”、生成量產模型等步驟。
我們把這個分支叫做“模型迭代分支”。
所以,人工智慧資料閉環,就是在傳統資料閉環上,增加了一個“模型迭代分支”,和傳統資料閉環的“工程師解決問題(修改程式碼或引數)”並列,這就是人工智慧的資料閉環的完整流程圖。
人工智慧資料閉環對管理、運營和工具帶來了全新挑戰
以前,所有的問題、程式碼的質量,都是由軟體工程師的能力決定的。現在,有很大比例的問題,要靠資料閉環的運營效率決定了。
人工智慧資料閉環對我們的影響很大,因為對管理、運營和工具帶來全新的挑戰。
對於傳統資料閉環的分支,解決問題的是“工程師”。對於“模型迭代分支”,解決問題的變成了“資料採集人員+資料標註人員+工程師”。由於“資料採集人員+資料標註人員”的數量是工程師的數倍,這不光要求團隊招聘新的角色,還徹底改變了團隊的人員結構,給管理、運營和工具帶來全新挑戰。
比如,在2020年特斯拉CEO馬斯克的採訪中,他指出,整個 Autopilot 團隊軟體端不到 200 人,但是,“光是打標籤這項工作,我們都投入了 500 多名熟練工”,並且,“我們準備將打標籤的團隊擴充到 1000 人,而且人人都是行內高手。”
即Autopilot團隊軟體端(注意不只是“演算法工程師”)和標籤團隊的人數比例是2:5到1:5之間。
第一個挑戰,是管理。就像一個以前做研發的團隊,突然增加了70%人數的生產線工人,如何有效管理(組織架構、激勵、考核)對這個團隊的領導帶來全新的挑戰,整個團隊的心態也要進行調整(高科技團隊To資料工廠)。
圖10 如何有效利用資料採集、資料標註員工,是管理人員面臨的新挑戰
團隊的領導要回答2個問題:
- 新增人員的實體組織怎麼安排?是彙報給研發領導,還是成立獨立的部門?是否異地辦公?是否用臨時工?是大量使用外包員工?是否設立自己的子公司?招聘、日常管理、激勵和考核都要重新安排。
- 新增人員和在專案維度怎麼管理?原來的專案經理直接管理標註團隊,還是增加一個子專案經理,專門作為新增團隊的介面人?
第二個挑戰,是運營。團隊領導怎麼確保團隊的工作量穩定?避免有時忙不過來,有時沒活幹?
以前,傳統資料閉環沒反饋資料時,工程師就去寫新程式碼、開發新功能了,沒有人力浪費。現在,人工智慧資料閉環沒反饋資料,團隊大量人員就沒活幹了。
這要求裝置端上傳的資料量要較平穩,不要忽多忽少,資料量和人員的規模匹配。對於自動駕駛,這主要是要求規劃好車隊數量,運營好車隊的駕駛里程、路線、和配置好觸發器。
第三個挑戰,是工具。工欲善其事必先利其器。如果工具不穩定、不高效,就會直接導致資料採集、資料標註團隊效率低下。
所以,人工智慧資料閉環,要求管理分層,運營穩定,工具高效。
有2個方案:
方案一:循序漸進
在從0到1的階段,研發團隊和採集、標註團隊都在研發體系,此時採集、標註的人數也較少(10人左右),雙方密切溝通,頻繁迭代工具,直到把工具打磨好,工作效率達到業界一流。
現在很多公司都有專門的團隊做工具開發,這塊的工作量不小。
方案二:引進方案
透過購買其他公司的資料採集、資料標註方案,在第一步時,就建立獨立的資料採集、資料標註團隊(數十人)。
這種方案的優勢是避免了重複造輪子,大大縮短了建立人工智慧的資料閉環的時間。
所以,由於管理、運營和工具上的挑戰,人工智慧的資料閉環的運營成本大大增加。這導致人工智慧資料閉環,只能在“輔助駕駛”和“自動駕駛”類似的附加值較高的行業,得到運用。如果是價值較小的行業,比如考勤系統的人臉識別系統,通常軟體出廠前,集中採集或標註幾批資料就夠用了,軟體出廠後,廠家使用資料閉環“持續”進行效能改善、體驗提升的動力不足,因為經濟上投入產出比(ROI)小。
這裡要特別提示一下,技術壁壘並不是人工智慧資料閉環的廣泛應用的障礙。有兩個原因:
- “模型迭代分支”需要的工程師水平,並不一定比傳統資料閉環的更高。因為,在傳統的資料閉環當中,要解決客戶上報的問題,作出正確的分析和判斷,並有效的解決,也需要非常資深的工程師,也需要較高的成本。比如,微軟或谷歌解決Office、Android問題的工程師同樣要求水平高。
- 理論上,神經網路模型的運用,會降低對於工程師經驗的要求。也就是說,如果資料閉環有效運用,“模型迭代分支”的工程師要求,應該大大低於運營傳統資料閉環的工程師要求,甚至可能不需要工程師。
人工智慧的資料閉環,完全自動化仍然不可能
第一,任何一個軟體系統,都不可能只有神經網路(2.0 code),必須還有邏輯程式碼(1.0 code),只要有邏輯程式碼,就需要依賴於傳統的資料閉環,就需要人工參與。
人工智慧的任務,比如影象的檢測分割,都包含資料的前處理、後處理,神經網路只是中間的骨幹網路(backbone)。而前處理和後處理都是傳統軟體的邏輯程式碼,也是最關鍵和核心的環節之一,包含很多的技巧,可能需要最佳化。
無論是智慧駕駛還是智慧座艙,要形成一個完整的使用者體驗,還不能只有人工智慧的任務,還需要有其他程式碼,如規劃控制、安全兜底邏輯、人機互動應用。這部分現在還沒有辦法完全透過人工智慧任務處理,還是需要有一些的傳統的軟體程式碼(邏輯程式碼)。這一點在特斯拉FSD的公開演講當中講得很清楚。隨著時間的流逝,神經網路(2.0 code)的比例會越來越大,但是,目前很大部分程式碼是傳統的程式碼,下面的圖中看的很清楚。在人類科學取得本質突破前,無法做到完全替代。
圖11 2020年2月特斯拉Full-Self Driving的軟體棧中,邏輯程式碼(1.0 code)仍然佔較大比例[4]
所有從客戶端上報的問題,首先要依賴於傳統資料閉環的工作流程,進行問題的區分,是神經網路的模型問題,還是非神經網路的模型問題。
有的公司,這個步驟叫“分鍋”。
這個特點,是人工智慧時代的資料閉環沒有脫離傳統資料閉環的工作方式的根本原因之一。
如果等到有一天,人工智慧時代的資料閉環能夠能夠跳過這一步,那我們可以認為人類的人工智慧科學進入到了一個全新的階段,所有的程式碼都是2.0 code了。
第二,即使在資料閉環的“模型迭代分支”,資料採集、資料標註的工作,無論怎樣提升自動化率,總體規劃、冷啟動、檢查和監督的工作,仍然需要人工參與。
目前,業界也在努力提升資料採集、資料標註的自動化程度,以降低成本。比如透過資料埋點自動收集有價值的資料,透過預訓練模型(初步模型)提高標註效率。但是無論怎樣,仍然需要人工參與的。
圖12 特斯拉資料閉環透過“初步的檢測器”收集“長尾資料”仍需要人工參與
第三,雖然“自動化測試”比例不斷提升,但是,對於量產軟體版本的釋出,仍然需要人工參與測試和把關。
第四,資料閉環本身絕大部分是邏輯程式碼(1.0 code)。
那麼,為什麼仍然有人堅稱,資料閉環不再需要工程師,能完全自動化了呢?因為這是“演算法工程師視角”。演算法工程師接觸的模型訓練、模型測試,完全自動化是可能的(實際上,只是工作轉移到了資料採集、資料標註工程師和測試工程師)。但是,當你把視角放到整個資料閉環,就會發現,完全自動化仍然不可能。
資料閉環並不能解決所有問題
人工智慧的資料閉環必不可少,但並不是救命稻草,不能指望資料閉環解決所有問題。
第一,Windows和Office都採用了資料閉環,但是,我們可以看到,Windows的藍色畫面崩潰,Office的閃退崩潰,仍然經常出現。
第二,神經網路自身的特性決定了準確率不能做到100%。
所以,我們在自動駕駛等實際產品中遇到的問題,需要透過資料閉環、軟體規範、合理的軟體和硬體架構、法律法規等,協同和立體的解決。
總結
有人說,對於只工作在神經網路領域的人,通常高估人工智慧資料閉環作用,因為對軟體工程整體缺乏認知;對於只工作在軟體工程領域的人,通常低估人工智慧資料閉環作用,因為對於資料和模型的效能之間的關係、資料採集和標註帶來的挑戰還缺少深刻的體會,所以,導致人工智慧時代的資料閉環,要麼被低估了,要麼被高估了。
這樣的觀點肯定是以偏概全,但是我們可以引以為戒。
如果你只工作在神經網路演算法領域,那麼你對資料閉環的期望要降低50%。因為,資料閉環並不會解決所有問題。資料閉環在傳統的軟體工程領域早已運用了超過20年,人工智慧時代的資料閉環仍然沒有脫離傳統資料閉環的流程,有部分問題仍然需要走傳統的資料閉環的流程解決。
如果你以前工作在軟體工程領域,那麼你對資料閉環的重要性認知要提升10倍。因為在人工智慧時代,資料的質量,直接決定了人工智慧模型的質量,決定了軟體質量。而高質量資料的獲取,對管理、運營和工具帶來了全新挑戰,我們必須認真對待。
參考文獻:
- 多出 20 倍?Android 收集的使用者資料量遠超 iPhone,谷歌官方對測試結果提出質疑 https://zhuanlan.zhihu.com/p/361285373
- 蔚來之後,小鵬汽車輔助駕駛也出事了 https://m.thepaper.cn/baijiahao_14706745
- 輔助駕駛又出事故?小鵬汽車高速公路撞上前方掛車,車主:差點沒命 https://page.om.qq.com/page/OMZj0kBYCcc3K3Pt7C-gUKjw0
- 雙語字幕 特斯拉AI高階總監 Andrej Karpathy 2020年2月演講:AI for Full-Self Driving https://www.bilibili.com/video/BV1GA411B7V7
- 使用者思維與資料閉環的威力 https://xueqiu.com/5189737826/157401195
- 蔚來ES8開L2撞人又撞車,為啥裝24個感測器都躲不開? https://xueqiu.com/5669246763/170896540
- 貨拉拉攜⼿神策資料,資料賦能企業,實現顛覆式創新 https://www.sensorsdata.cn/blog/20190212/
注:本文僅代表個人觀點,與任何組織和單位都無關。