Category: programming

2019 LINE Developer Day – Face Recognition Check-in Mechanism

人臉辨識是近年來非常流行的技術,如今幾乎已是深度學習的天下了,而這門技術的應用上,現在還是非常的火紅的話題。這次參加的 LINE DevDay,就採用人臉辨識當做報到的機制。

2019/11/20 報到現場實況

而在第二天,也安排了議程來說明 LINE (NAVER)是如何開發、設計與導入到 LINE DevDay 2019 會場的報到流程。

Speaker: Seungyoun Yi

由於我們自己也有在研究人臉辨識,也有用在 check-in 上(我們叫刷臉打卡),所以在第一天報到的時候,就有特別注意一下偵測的時間,以我報到的經驗,大約花了3~4秒(兩天都是),並沒有像官方宣稱的不到一秒,但搭配一直轉圈圈的 UI ,也並不會讓我感覺到等很久。實際體驗的時候, iPad App 上的圈圈會跟著你的臉部範圍動,所以可以推測時間是花在臉部特徵擷取(Facial feature extraction)或是特徵比對上。既然講到此,我們就先由講者的第二段(Face Engine)說起。

人臉辨識目前的作法都是 1) 偵測人臉 2) 對齊人臉 (alignment) 3) 臉部特徵擷取 4) 人臉特徵比對 。通常步驟 1/3 是相對容易的,而 2/4 就比較難了。 2 的問題是人臉的角度通常不會剛剛好,要正確定位眼鼻口眉毛並不是像一張面膜一樣貼上去就好(為了說明方便,實際上不是去定位這個是眼睛這個是嘴巴)。而 4 的問題在於,當資料庫愈大的時候,需要比對的資料就更多,計算量也就更大,要在短時間就做完,沒有硬體(如 GPU )的幫忙,通常就要在演算法上鑽研很深才行。所有會需要上線深度學習模型的團隊,都會想辦法去做 model size reduction/compression (without losing too much accuracy), NAVER 團隊同樣地也花了不少時間在做深度學習模型的優化。團隊的目標就是在行動裝置(也表示不見得有 GPU )上能達成即時的人臉辨識:Our standard is real-time in mobile CPU environment。由投影片的 16~55 頁有團隊的實驗成果,在此並不贅述。不過不像 Clova team ,並沒有看到團隊的論文發表,不太確定實際的成果為何?

回頭來講臉部辨識應用,不外乎 1:1 、 1:N 的應用場景,而即時辨識的場景對於 UX 的要求更是重要,對於刷臉報到來說,如果節省等待時間、辨識時的過場畫面(不會讓人感到不耐煩)、辨識不出的解決流程,其實這考驗主辦單位的場控能力,有 UI 呈現的地方,就會需要排演 SOP 。這次的報到入場我覺得還蠻順的,但是也可以感到 LINE 官方對於這個的重視,許多工作人員也跟在旁邊引導。

由演講可知,講者也是在第三段接著討論臉部辨識的核心實作到服務應用。這次的報到是有 App 的,配著投影片也可以看出是 Client/Server 架構的,由 Client (App) 負責做 Feature Extraction ,接著再傳到後端 Server 做比對。

由上面幾張投影片可以了解透過好的 UI/UX 設計,可以降低錯誤率,為什麼呢?因為對於臉部辨識引擎本身,它就是 API 有傳進來的臉部特徵就會去比對,如果前端的介面設計是什麼都往後面丟,那整體的效果就不會太好了,所以實務上不需要處理太多 corner case 的情況,就是把這些可能會出錯的,由前端的 UI/UX 來避免。當然,這不是說 UI/UX 就不用寫程式,像上面寫的眨眼偵測啦,或是角度,那些也是要開發程式的。以 LINE 在這次 DevDay 之前,也是做了幾次實地測試(Field Test),可以感覺出來他們是愈來愈有信心了。

已經有不少經驗了

照舊,放上一張圖當結尾(雖然我認為還要加上 UI/UX 才更恰當)。

Goal of AI

2019 LINE Developer Day – Project Management and Agile

近十年來(其實應該超過十年了),敏捷開發逐漸在軟體工程中佔有一席之地,這個的定義大概就是如果有人說他做軟工的,那你可能會回一句「所以你對 Agile 應該很熟吧」

Speaker: Minoru Yokomichi

在 LINE DevDay 的第二天下午,有個議程也是在分享 LINE 內部是如何進行專案管理的。講者所在的部門很特別,稱作「Effective Team and Delivery Department」,由名稱可以看出來這個部門的重心。通常接著的關鍵字就是 Project Management 、Product Management 、 Agile 或 Scrum,果然講者的背景也是如此,不過多了 Engineering ,這也是符合 LINE 的企業文化。

To make “Teams” and “Delivery Processes” more effective

左邊的子部門 Delivery Management Team 中,是由一群 TPM (Technical Project Manager) 組成的。 LINE 的文化認為 Project Management 對於 Product delivery 是很重要的,但 Project Manager 這個角色並不是那麼地被需要;也就是說,LINE 的 TPM 負責的並不只是 Project Manager 這個角色任務。

產品開發的三環相扣

上圖可以看出他們對於產品開發中,對於 Product/Project Management 與 Development 各自的角色工作定義,一般而言對於前兩者的角色也就是稱為 PM (Product Manager/Project Manager) ,而後者就包含了 Engineer / QA 。

LINE 的 TPM 組成
彼此工作是有區隔,但沒有明確界限

而講者藉由 R & R 的示意圖,說明 PM/Eng 雖然工作是有各自的職責,但在實際上的產品開發合作上,卻不會那麼壁壘分明。當彼此的界限模糊的時候,就不容易有事情掉在地上沒人做的時候了,不過以我自己的經驗,我認為要達成這個目標,除了企業文化能支撐之外,團隊的成員心態也非常重要。而心態的養成,也與主管甚至高階主管的支持有非常大的關係。以這個角度看,也許 LINE 做的很成功?(因為沒有在 LINE 任職,有些內部衝突是看不到的)

談完了左邊的,接著拉到右邊的子部門 Lean & Agile Team。在這方面, LINE 的 Agile 也奉行「Be Agile, not just do Agile」,以落實 Agile 的價值與原則為主,而非一昧採用其方法論。

支持性的工作為目標

整個部門工作重心是以 Support 其他部門為主,這中間包括了提供訓練、協助解決問題以及建立內部跨域的社群(這點就跟目前很多的社群 meetup 是一樣的意思)。

簡介完了之後,搭配而來的就是實際例子,講者是以 LINE News 的產品開發為例,但我想組織圖應該是可以通用的。

初始的組織圖

通常一間大公司的組織也就大概長的像這樣子,這類的組織特性是有管理者們層層把關,做一個既有產品的優化是很容易的,因為管理者(或是資深的老鳥)可以靠著過去的經驗來判斷;但若是產品還在初期的階段,從這個角度看上去,就是看到層層的山頭了。

從組織圖迭代的演變,我們可以看得出來,工程師永遠是最好講話的(笑)。目前看起來,左方的管理群們一時之間是很難拆開的,這個我想工作個十年的人大概都可以理解是怎麼一回事吧(茶)。

接下來,講者也介紹了以前述三個核心為本的,各式各樣 LINE 提供的 Training / Workshop / Team Building / Community ,這些建議直接連到投影片去看。個人覺得這些文化養成雖然不見得能讓 LINE 變的強大,但是很有機會能讓 LINE 變的偉大的。

最後,放一張 Product Management 的 global view 為結尾(其實我不知道為什麼寫了個 Thailand 卻什麼都有啊)

Global view of LINE Project Management