Line運用MLOps的概念,設計了AI開發的關鍵基礎架構平臺ML Universe(簡稱MLU),建立起如生產線般緊密分工的作業流程,要讓Line集團中的所有AI與IT團隊成員都能發揮所長,共同協作來提升AI開發的速度與品質。
這個由Line韓國總部建置的MLU平臺,Line臺灣團隊也參與了一部分的協作開發,去年中更正式導入了這套平臺,將各種ML應用遷移到MLU平臺中來加強協作。不過,在運用這套平臺之前,就如同所有剛起步的AI團隊,Line臺灣也經歷了一段摸索開發AI的時期。
從導入開發工具到採用ML協作平臺,Line臺灣資料工程部資深經理蔡景祥更進一步分享,Line臺灣如何從零開始逐步實現MLOps。
一人團隊:AI開發過度個人化成後續協作挑戰
蔡景祥回憶,Line臺灣在AI團隊成立之初,當時的團隊成員就只有自己一人,因此,他得身兼多種角色,同時擔任資料工程師、ML工程師、ML服務工程師,除了開發ML模型,更得開發API將模型部署上線。
雖然當時,所有的開發任務都只能靠蔡景祥自己完成,但也因此,他能清楚了解在ML開發的每一階段中,都做了什麼設置,也就不存在協作過程可能產生的溝通壁壘問題,「完全可以無縫接軌。」他說。
不過,儘管一個人開發ML的過程中,不存在協作挑戰,蔡景祥仍遇到了一些難題。比如在開發ML的前三個月,他就開發出第一版ML模型,卻在接下來調校模型時,發現成效不如預期,往後9個月甚至沒有前三個月來的有效率,「因為我要手動把ML Pipeline每一段都開發出來,非常花費時間。」
也是這時,他開始意識到,當前的開發方法有太多手動的操作,無法提高AI開發效率,且就算沒有他人插手,隨著開發時間不斷拉長,從第12個月回頭檢視第3個月所開發的程式碼,還是會忘記當時所做的事情。
不只如此,蔡景祥獨自開發AI約一年後,Line臺灣研發工程部資深資料工程師孫韻如成為AI團隊的第二位成員,隨著AI團隊從一人變為兩人,模型開發的複雜度也更加提升,因為兩人開始分工協作後,各有自己的開發方法,對彼此開發的程式碼也不了解,徒增了許多溝通成本。
「我們兩個開始分工後,就開始思考,是不是有一些方法論,能去較好的定義每個ML工作階段,以及是否有些工具,能輔助每個階段的進行?」蔡景祥發現,當前的AI開發過於個人化,對兩種角色以上的AI團隊來說,尤其帶來挑戰。
兩人團隊:根據協作痛點導入AI開發工具
面臨了協作需求後,Line臺灣決定開始實作MLOps。當時,孫韻如負責研究這類解決方案,發現市面上已經有些開源工具或軟體,能在不同開發階段促進不同角色的協作,於是,針對實作ML過程中遭遇的痛點,Line臺灣逐步將相應的開發工具導入ML開發工作流中。
比如剛開始,Line臺灣遇到的最大問題,是參數調校的版本控管問題。蔡景祥解釋,要提升模型的準確率,哪怕只是1%而已,都需要歷經多次的參數調校與實驗過程。不過,Line臺灣剛開始,是用Excel來抄寫每一個版本的實驗資料、參數及模型表現,隨著實驗次數增加,這種手抄記錄方法逐漸不敷使用,造成效率低、易出錯的問題,且角色分工時,更會礙於無法充分解釋每一步驟的用意,導致分工難以進行。
為此,Line臺灣導入了模型訓練的版本控管的工具MLFlow,來自動記錄實驗記錄,讓開發者可以輕易比較每一個版本實驗結果,更容易進行版本控管。
而後,Line臺灣面臨到另一個問題,是在進入模型部署階段時,團隊需要將模型服務打包成API,或是進行其他工程端的開發,但是,這對資料科學家來說,具有一定的開發門檻,若交由工程人員協作,又會產生額外的溝通成本。
「所以我們開始研究,有沒有工具能將模型快速打包成API來部署,同時又能兼顧穩定性?」蔡景祥表示,Line臺灣後來導入了KFServing,讓資料科學家能較輕易的自行部署模型,讓資料科學家能更專注在模型開發的工作上。
談到這裡,孫韻如特別指出,MLOps沒有一種標準化的導入方式,而是強調AI協作的概念,Line臺灣選擇的導入方法,是針對AI開發遭遇的痛點或協作挑戰,導入輔助的開發工具來克服,但不同企業的AI團隊,可能發展出不同的MLOps實作方法,「因為他們的痛點不一樣,就會導入不同的工具來因應。」
與總部協作,共同實踐MLOps
就在Line臺灣花費了一段時間,導入了版本控管與模型部署的工具後,臺灣AI團隊在一次與韓國總部的會議中,發現總部也同樣面臨了AI開發過於客製化的挑戰。當時,總部正著手導入相關開發工具,也更全面的規劃了ML Pipeline的角色分工與工具支援。在了解到彼此都有導入MLOps的需求後,雙方也一拍即合,展開了更進一步的協作。
蔡景祥表示,協作過程中,由總部作為主導的一方,將雙方在ML開發工作流各階段導入的工具,進行整合,也參考外部的最佳實例,內化為自身的作法,來打造一個整合多項工具的ML開發平臺,「我們希望,透過各種開發工具的輔助,能將參與到AI開發的所有角色,全部在平臺中串連起來。」
這套ML平臺,除了整合多項開發工具,能在平臺上直接呼叫來使用,而不用擔心個別軟體工具的部署與環境設定,更將部分工程端的程式開發環節,透過使用者介面的編輯器功能來取代,讓使用者能透過拖拉設定的方式來建立ML Pipeline,減少AI與IT人員的協作成本,可說是MLOps更進一步的體現。
ML平臺建置完成後,從原先的專案名Jutopia,正式命名為MLU,更與Line先前建置的資料平臺IU(Information Universe),共同作為AI開發的關鍵基礎建設。Line臺灣大約在去年年中,正式導入這個ML平臺,除了韓國之外,其他如日本、中國、泰國等地的AI團隊,也都逐步將ML專案轉移到該平臺上,截至去年7月,超過30個團隊、上百名工程師都已經採用。
擴散到各地AI團隊採用後,若各團隊發現,有些需求仍無法被滿足,也能向總部回報,由總部持續完善整個平臺。孫韻如就舉例,雖然MLU平臺已經與IU平臺串接,能取得各類經去識別化的資料來運用,但在實際的ML開發場景,仍有些資料並非來自於IU,而是其他的儲存空間,這時,就得請總部擴大整合更多資料儲存空間,以便開發者能直接從MLU設定,來取得所需的資料。
「因為每個ML專案的資料來源與服務性質都不一樣,如何讓平臺更加通用,就是MLU平臺的開發挑戰。」孫韻如表示,MLU建立的目的,就是要滿足各種各樣的AI開發需求,讓Line開發的AI應用,都能透過MLU實現。
Line建置了資料平臺(IU)與ML平臺(MLU),作為AI開發的關鍵基礎建設,來建立大多Line服務背後支持的AI應用,比如從Line Today、Line TV、Line Music到Line購物的個人化推薦,聊天訊息的事實查核機制,照片轉文字的OCR辨識功能都在其中。圖片來源/臺灣Line
MLOps協作還需納入業務端,成MLU平臺下一步挑戰
儘管MLU平臺已經整合了多項工具,加強AI開發與維運端的協作,但是對於開發端與業務端的協作仍有精進空間。蔡景祥認為,現行的ML開發流程中,對於ML模型的解釋度還不夠。
「AI開發跟一般軟體開發的最大不同,在於實作出ML模型後,模型表現會產生偏移,」蔡景祥指出,這是AI開發的特性,但也正因這種不確定性,會讓資料科學家難以解釋模型決策的原因,尤其,在向非技術專業的應用端人員解釋模型預測成效時,若沒有工具來輔助解釋,就可能帶來溝通上的挑戰。
雖然,目前MLU平臺已經整合了相關工具,能進一步分析訓練資料的特徵對模型決策的權重,來試圖解釋ML模型做出不同決策的原因。但蔡景祥仍認為,在模型表現的解釋上,技術上還是有其挑戰性,MLU平臺也還能未整合更多可解釋性AI工具,來提供業務單位更直觀的洞察。
「AI開發的本質,是要解決一個商業問題,」蔡景祥反問,要如何證明,透過ML模型真的解決了一個商業問題?或是向業務單位交代,這個問題是礙於哪些原因而無法解決?這才是業務單位真正關心的事。
因此,蔡景祥期許在未來,MLU平臺能整合更多模型分析工具,來增進技術人員與業務人員的協作,除了提供解釋模型預測力的視覺化工具,甚至能量化使用ML後的成效數據,比如能增加多少瀏覽量、降低多少成本,來進一步說服業務單位使用該預測服務。
熱門新聞
2024-11-10
2024-11-12
2024-11-10
2024-11-11
2024-11-11
2024-11-11