序
圖：How to build an AI application
當 AI 工程師也一年多了，由於 AI 中的深度學習領域極少真正的資深人員 (AlexNet 在 2012 奪下 ImageNet 比賽冠軍為歷史分水嶺)，一直覺得 AI 工程師是一個很特別的新興職業，無論是學術工作或是商業專案都有許多前人尚未探索的地方：感性的人覺得自己正在改變世界、學院派的人覺得自己在做學術工作、程式設計師覺得這是程式 2.0、務實的人覺得自己在用 AI 思維最大化公司收益、按表操課的人覺得自己只是調參工人......
到目前為止，在 AI 產業的熱門專案大部分都是學術機構或大公司實驗室的成果展示，而能有真正商業模式的 AI 專案寥寥無幾。因此，實際的 AI 專案落地就成為近年來業界大家最關注的問題。雖然這份工作的產業變化很快，分門別類的子領域也非常多[註1]，但總體來說，我覺得 AI 專案落地可以分成下面這四個方向做評估：
- 資料 (Data)
- 模型 (Model)
- 生產 (Productivity)
- 溝通 (Communication)
下面就以這四個方向來說說我這一年來的心得累積吧：）
[註1] 以較有名的例子來說，開啟深度學習時代的 VGG 和 ResNet 是屬於影像視覺問題 (CV)、棋類通用智慧 AlphaZero 是屬於增強學習 (RL)、最近很紅的 BERT 屬於自然語言處理 (NLP) 等等。
一、資料為王
圖：Amount of lost sleep over… (from karpathy's slide)
在 AI 領域的從業人員都知道，在學術界和業界做 AI 題目有非常大的差異，在學術界做模型通常是追隨前人的研究，拿同樣的資料集，以新的演算法提升準確度，如此才能確保不同的演算法得以嚴謹地比較；而在業界做模型並沒有固定資料集的限制，資料的收集方法五花八門：從相關論文收集學術資料集、撰寫爬蟲爬取資料、使用公司本身的資料源收集資料做標記...... 公司為了追求準確度，可以花很大的力氣整理資料集，建置更堅實的資料基礎設施，以驅動更大規模的模型訓練。
另外，學術成果和業界要解決的應用問題往往有一段不小的差距，學術上的資料通常較為理想化，而實際收到的資料常常有很多問題：資料特徵不佳、總資料量龐大、目標資料異常稀少、資料收集綁定特定感測器、資料有權限或隱私問題...... 因此在開始動手之前，一定要先看一下資料集長什麼樣子，不要埋頭就開始做模型！
在業界很多時候需要自己建構資料集，由於用自己的資料源建構出來的資料集往往表現會比標準資料集好上許多 (有點 in-sample 的味道)，因此雖然前期需要一些準備時期且成本較高，卻是非常值得的投資。實際執行後，我覺得標記的過程要考量到以下幾點：
- 標記品質審核流程：資料的標記品質將決定模型的學習難度，尤其是開發早期資料很少的時候更是如此，因此標記品質審核必不可少。
- 與領域專家的溝通：有些問題的資料標記非常難以掌握，只有受到高度訓練的專家可以區分（如醫學影像），因此與專家審慎討論，才能設計出讓模型容易訓練的標記規格。
- 注意資料不平衡問題：實際的應用問題中資料不平衡狀況非常常見，除了使用一些處理不平衡資料的技法或依靠深度模型的學習能力以外，能在資料面多收集極少數量種類的樣本，便能從根本上解決這個問題。
有了質量良好的資料，就算使用的模型不是學術上最卓越的模型 (SOTA)，通常也能取得很好的結果，也就是說，資料清洗和特徵最佳化的效益往往優於模型調整，因此對業界的 AI 專案來說，訓練資料的基礎建設佔有舉足輕重的地位。
二、研究與模型
1. 論文閱讀與研究
圖：塞繆爾·詹森 (Samuel Johnson) 和阿爾伯特·愛因斯坦 (Albert Einstein)
AI 領域的典範轉移如此之快，過去熱門的專業知識常常在新技術推出後變得乏人問津，而且投入在這個領域的人大多十分優秀，名校博士生和大公司科學家比比皆是，要能在這個競爭的場域中生存下來，養成閱讀論文的習慣是唯一方法；一個現實的情況是，那些領域內知名的論文，往往是競爭公司所發表，因此想要與之競爭，閱讀這些經典的論文著作真的是一件很基本的事。
由於大量的數學理論和實驗不確定性存在於 AI 模型開發中，因此 AI 模型開發需要某種與傳統軟體工程師完全不同的氣質，例如：在大家都在開 bug 解 issue 的辦公室裡拿起紙筆算數學、把最新的論文當早報看、覺得數學或邏輯表達式有一種美感 [註2]...... 這種關於研究的氣質，通常和業界傳統的軟體工程文化有不小差異，因此在公司文化上可能需要一段時間來磨合適應。
由於使用機器學習或深度學習模型的開發時間很長且投入資源較多，用模型解決問題之前一定要釐清目標問題的各種屬性和定義，例如：
- 目標問題是分類問題 (classification)、偵測問題 (detection) 或是語意分割問題 (segmentation)？
- 標籤是單標籤 (one-label) 、多標籤 (multi-label) 還是階層式樹狀標籤？
- 這個問題比較關心準確率 (precision) 還是召回率 (recall)？
- 資料是連續傳輸、定時傳輸或是事件驅動？
要問出這些問題其實不難，只是當專案繁忙的時候很容易輕忽它；藉由清楚的了解問題，重視每一次的實驗分析，可以避免許多研究和開發上的錯誤，釐清模型優化的方向，讓有限的資源投注在刀口上。
[註2] 私自喜歡的一個小測驗是：喜不喜歡 Lambda Calculus (Lisp) ?
2. 應用模型建構方法論
圖：主動學習成效示意圖
在應用模型建構中，有一些方法論可以節省大量的時間和金錢，例如遷移學習 (Transfer Learning) 和主動學習 (Active Learning)。遷移學習是近年來模型訓練的標準，將大型的訓練模型的訓練結果遷移成適合解決特定商業問題的子模型，使用遷移學習可以減少目標種類的資料收集量，使成本降低、省時省力，而且實際的預訓練模型 (pretrain model) 通常表現不錯，甚至時常比自己從頭開始訓練效果更好。
另一個常用的方法是主動學習，簡言之，就是標記「有價值」的資料；主動學習在這裡可以視作一種開發流程，首先先用較少資源建構初版模型，再藉由迭代的方式，用前一版的模型打撈有價值的難樣本，並做新一輪的標記和訓練，形成正向的循環，最終得以在使用較少資料下，成長為可以服務客戶的商用模型。主動學習的流程之所以可行，可以用下面這些概念來理解：
- 用機器學習的觀點來說，主動學習可以是一種難樣本探勘 (hard sample mining)，讓難樣本快速建構決策邊界 (decision boundary) 達到有效率的建模。
- 用深度學習的觀點來說，主動學習可以在深度模型訓練時創造更大的梯度，使訓練加快，收斂效果更好。
還有一個很重要的觀念，別輕忽古典的方法；雖然目前深度學習方法在時間和空間沒有限制之下通常有較好的表現，但現實是許多裝置 (如智慧型手機或物聯網設備) 的計算資源不及雲端伺服器，要把深度學習框架和模型放到晶片上且能順暢的執行其實並不容易；另外，深度學習模型的「黑箱作業」也為人所詬病，在除錯和更改需求時往往是一場災難。因此對開發流程來說，古典方法有一些顯而易見的優點：
- 通常證明較嚴謹，能給你關於目標問題更好的理解。
- 讓你對專案的掌握度更高，有新需求時功能比較好疊加實作，有臭蟲時也比較好修。
- 可以和 ML 類的方法搭配，很好的做特徵工程 (相比 DL end-to-end 方法而言)
很多情況下，深度學習方法相對於其它的演算法並沒有明顯優勢，尤其當問題本身簡單或資料樣本不足時更是如此；因此如何將古典方法、機器學習方法和深度學習方法適當的運用，來解決變化快速的商業需求，需要很多技術上的累積和實戰的經驗。
三、生產力與軟體開發
圖：CI/CD For ML/AI (from Paperspace)
對於要扎根的 AI 專案來說，AI 是一種工具，最終還是要有創造商業價值的明確目標。比如說，如果要在物聯網設備上做影像偵測，具體的專案目標就是要把技術已經成熟的物體偵測模型部署到機器上，而這個問題不需要一個熟稔於證明最佳化理論的大師，也不需要一個會重頭造輪子的演算法專家，而是需要一個有能力解決實際 AI 工程問題的工程師。
在工程上，系統層面對於 AI 專案的影響極其重要，業務規模會決定問題的難度，例如一天服務 10 萬個請求的模型，跟一天服務 1000 萬個請求的模型，在實作上有著天壤之別；另外，容易取得的計算資源也會決定你對模型的想像力，例如當手邊只有的少量的 GPU 計算力時，能用來解決問題的模型大多會依靠現有的預訓練模型，而不會是自己設計的大型網路。
因此，成為 AI 工程師之前，首先要是一個軟體工程師；為了面對實際的系統和軟體開發問題，一些軟體工程的老生常談依舊非常重要：版本控制 (Git)、雲服務 (AWS/GCP/Azure)、輕量虛擬化 (docker)、測試案例 (test cases)、持續交付與整合 (CI/CD)、任務追蹤管理 (Asana/JIRA/Trello)、知識文件分享系統 (wiki/confluence)...... 即使是做模型的原型 (prototype) 開發，也應該要有一些最基本的版控和測試。這些林林總總的軟體工程規範對於 AI 相關的程式碼有很大的影響力，唯有這些工程上一點一滴的累積，才能讓最初實驗性質的模型，轉變成可擴展、可靠的軟體服務呈現給客戶使用。
四、專案溝通
圖：How Projects Really Work (from project cartoon)
俗話說：「有人的地方就有江湖。」這句話在專案溝通上尤為適用。
大多數的公司在導入 AI 時，是創立一個獨立於生產流程的 AI 研究部門，而實際的 AI 模型部署時可以選擇放在物聯網裝置、行動裝置或是後端伺服器，因此跨部門乃至於跨公司的合作溝通幾乎是必要的一環。大家的技術背景不同，軟體部門、硬體部門、專案管理部門、測試部門和研究部門的運作模式差異非常大，要如何面對不同的人以適當的方式解釋 AI 專案，在未知的創新模式與部門利益拉鋸之中，磨合溝通出新的流程開發典範；這些關於「人」的課題，是我至今仍然花很多時間思索的事。
在溝通上，一個常見的利器是資料視覺化 (Data Visualization)，由於文字很難讓人直觀的了解模型內部含義，因此可以藉由適當的繪圖 (如折線圖、散點圖、柱狀圖，甚至是真實的樣本圖) 來呈現資料集或分類結果，適當的視覺化可以讓人一眼就了解模型的意涵，大大的增進溝通的效率。
另外，在創業圈有一個很有名的概念在溝通上也非常受用，叫做 MVP (minimum value product)，也就是說，我們給利益關係人 (stakeholder) 做非常多的 Demo，這個概念也呼應了駭客圈一句很有名的話：Talk is cheap, show me the code. 實作這些 Demo 要多寫不少程式，但是我認為這些工作非常值得，因為這些 Demo 不只可以更精準的提取需求，讓開發流程中有里程碑 (milestone)，更重要的是，讓大家有一種「安心」的感覺，從規格流程的字裡行間解放出來，實際感受到新產品或新功能的魅力。
結語
圖：榮星花園一隅
中午時分在公園散步，帶著涼意，微風輕拂在身上的感覺真的很舒適；在辦公室坐久了，容易忘記世界有多大。
時間過得很快，轉眼間也工作了一兩年，再幾年就三十歲了，我常常思考：我要過什麼樣的生活？我想成為什麼樣的人？這一年來我的能力有多少提升？有時會懷疑「我來、我努力、我成長」的敘事，會不會只是待在同一個地方一段時間後「媳婦熬成婆」的思考錯置？
在現實社會打滾後，愈來越不願面對自己當下寫下的文字，越修改越圓滑，被某種以和為貴的傳統敘事所收編，「喜歡 AI、喜歡寫程式」這種話，也變得難以啟齒，大量的心智勞動、繁複的人際關係、過度的感官愉悅、集體的競爭焦慮...... 有時不得不將自己的勞動成果看作是一個工作 (他者) 而不是一種本心的召喚。
但這並不是故事的全貌，我至今仍偏執地相信，做一件真正在乎的事情需要某種「昇華」和「感應」，事業是我們人生的重要組成，有時必須超乎常人的堅持一些事情，找到真正想努力的目標，跟隨自己真正的心意；全心全意的投入是看得出來的，我覺得這不只是一個 AI 工程師的品質，更是身為一個人重要的品質。
目前，在這個小而美的地方工作，雖然不敢說自己做了什麼了不起的 AI 專案，但比起社會上許多工作崗位的枯燥重複，能在吵吵鬧鬧的專案日常中，有一些有意義的反思與對話，那也就足夠了吧。
最後，感謝 Vs，對 AI 專案給予百分之百的協助和支持。
感謝 Hs，給我上台分享工作經驗的機會，並提供許多關於演講的建議和指導。
真的謝謝你們。
發表文章
沒有留言:
張貼留言