【玉山金2022科技新戰略：MLaaS 2.0】關鍵技術平臺大換裝，改用K8s邁向AI維運不間斷

玉山嵌入式金融服務背後的技術力，是一套捲起袖子自建的機器學習即服務（MLaaS）平臺。它是執行各種AI應用不可或缺的工具，舉凡0.1秒就能揪出異常的信用卡盜刷偵測、解放人力的千萬張票據手寫辨識功能，甚至是疫情間加速紓困專案申請的RPA應用，都靠MLaaS驅動。

這個平臺，在去年中從1.0蛻變為2.0，第二代不只擁抱Kubernetes（簡稱K8s）、容器等主流開源工具，還引進多項自動化機制，來提供99.9%可用性的API服務，實現玉山7x24小時金融服務目標。他們如何做到？

MLaaS平臺：執行AI推論的重要引擎

在玉山，AI已深化至各營運層面，光是執行中的專案，就超過半百個。玉山AI力靠兩大平臺支撐，一是AI研發雲，是一個供資料科學家嘗試創新的「遊樂園」，另一則是MLaaS平臺，是一個講求快狠準的服務平臺，營運著各式各樣的AI應用，更具備1秒內給出預測結果的能力。

這2大平臺關係緊密，當資料科學家在AI研發雲完成模型開發後，會將成熟穩定的模型部署到MLaaS平臺上，來執行實際任務。此時，MLaaS有3個重要工作要做，也就是資料ETL、模型訓練、以及部署API執行AI推論。可以說，MLaaS是實現AI解決業務問題的重要橋樑，必須又快又準，但隨著玉山AI應用的擴大與深化，MLaaS更多了資源彈性調度和維運穩定的需求。

面對這個要求，從零打造MLaaS平臺的玉山銀行智能金融處（簡稱智金處）曾透露，2019年MLaaS 1.0上線後，團隊就開始思考下一代架構。因為，從平臺上線第一天起，他們就知道，未來平臺的使用複雜度只會越來越大，不只得落實AI上線後的監控維運，面對大量資料處理和推論需求，資源調度還得更細緻、更有彈性才行。

2.0用微服務拆分3大功能，採K8s更彈性調度資源

這是因為，MLaaS 1.0採裸機（Bare Metal）架構的設計，執行AI推論用的運算資源以虛擬機器（VM）為主，比如，可以很方便的指派3臺VM來執行一個AI推論工作。但是，在1.0的平臺中，無法根據尖峰、離峰用量自動調整用於執行AI推論的運算資源，因此得一開始就以尖峰用量來配置，缺乏了調度彈性。

再來，MLaaS 1.0採取了「一條龍式」的部署管線設計，只靠相同的一條部署管線從頭執行到尾，涵蓋了從資料ETL處理、模型訓練到部署推論API的程式碼，將3項工作整合到一條部署管線的做法。想要修改其中一項工作的程式碼，比如要調整推論API，就得從第一步的資料ETL開始，全數執行部署一次，才能重新部署新的模型推論API。這對模型重新訓練或更新推論API來說，就產生許多時間成本。

MLaaS 2.0改善了這些缺點。智金處改用了微服務架構開發，拆分原本綁在一起的3種功能，各自以輕量級容器打包，部署在K8s上。這麼做的好處是，使用者可直接修改其中一個功能，比如直接重新部署API，或是更新資料，而不必跑完所有流程。

再來，採用容器和K8s，就能善用K8s平臺的自動擴充機制，能根據當下流量需求，即時調度運算資源，比起裸機架構綁死VM資源的做法，更有彈性。同理，這個資源調度還能依需求量調整，比如，有些AI專案的資料量大，但模型訓練工作相對簡單，就能將額外運算資源調度給ETL處理，若模型資料量不大、但模型訓練需大量運算，也能將動態將運算資源分配到模型訓練上。玉山的影像和語音辨識模型，就以這個方式來操作。

開始搬遷舊專案，還要整合影像辨識模型

去年7月，MLaaS 2.0正式上線，此後新加入的AI專案，就都部署在MLaaS 2.0上，而1.0的舊專案，則陸續搬遷至2.0，特別是所有影像相關專案，將在今年全數搬遷至新平臺。

這是因為，玉山打算藉這個機會，將所有影像模型整合為一個完整的大模型，來支援跨業務需求。比如，智金處過去開發了票據影像辨識應用、財力證明影像辨識等影像辨識應用，這些應用包含多種辨識模型，如所得稅清單辨識模型、存摺辨識模型、薪資證明辨識模型等。

這些模型，都得按個別業務需求來執行辨識，但現在，玉山要整合這些模型，重新設計API，讓前端呼叫時，不必先區分上傳的是何種文件，而是直接辨識、產出結果。

這麼做的好處是，一套模型就可支援不同業務。比如，信用卡處辦理信用卡申請時，可使用財力證明辨識，其他消金業務如信貸申辦、房屋貸款等，也可使用財力證明辨識模型。

MLaaS 2.0亮點：比較不同版本模型更簡單了

這個引進新工具的MLaaS 2.0平臺，最讓團隊有感的是，比較不同版本的模型更容易了。因為，在1.0時代，若要比較不同版本模型，部署在不同環境的成效，就得費一番功夫調整流量資源，很難進行比較。

而在2.0平臺，團隊可將不同版本的模型，打包為不同的容器，再將模型推論包裝成API，就可利用K8s的流量分配工具Ingress來分配流量到不同的版本的API來試驗。比如要比較3個模型版本，版本1分配10份流量，版本2分配30份，版本3則是15份，或是，3個版本都可分配相同的流量，來進行測試。

接著，為了評估實驗結果，團隊先是收集日誌（Log），彙整到搜尋引擎Elasticsearch中比較，再將結果回饋到MLaaS平臺的模型訓練工作來比較，作為判斷是否需要重新訓練的參考。

這是MLaaS 2.0利用K8s特性，實現的里程碑之一。

MLaaS 2.0實例1：內部Chatbot

不只資源調度更有彈性，搭配微服務架構還大幅縮短模型訓練時間。像是，智金處在MLaaS 1.0時代開發一套內部專用Chatbot，能回答內部員工的各種人資相關問題。但這也意味著，這套Chatbot需要大量語料來訓練，並隨著法令、公司制度調整，得不定時以新資料重新訓練模型。比如，去年下半年規定，2022年陪產假改為7天，而這只是答案，使用者還會有各種問法，因此，智金處得利用相關語料訓練模型，再重新部署。

由於MLaaS 1.0平臺將資料ETL、模型訓練、推論API部署這3個工作流程集中到單一程式，光是重新訓練，就花了2周時間，執行完所有流程才算大功告成。但MLaaS 2.0平臺，將這3項工作流程拆開，個別在容器中處理。因此，當模型需要重新訓練時，直接在模型訓練執行特定一項流程的容器即可，不必走過所有流程。

MLaaS 2.0利用K8s彈性調度資源，重新訓練這套Chatbot，1天就能完成。

MLaaS 2.0實例2：Smart Channel

另一個例子是推薦系統Smart Channel。這個系統會根據使用者檔案、瀏覽紀錄和交易資料，在使用者登入行動銀行App時，推薦相應的金融產品。

Smart Channel是MLaaS 2.0原生專案，直接部署在2.0平臺上。透過K8s自動擴充機制，可在上午11點至下午1點的尖峰時段，當大量請求湧入時，自動開啟更多Pod叢集來因應需求。

若是MLaaS 1.0平臺裸機架構，缺乏運算資源彈性調度機制，一開始就得配置尖峰規模的資源來因應，往往會造成資源浪費。

MLaaS 2.0實例3：數存秒開

另一方面，MLaaS 2.0還有一個數存秒開的原生專案。數存秒開是玉山近期上線的金融服務，用於即時開設數位存款帳戶。這個專案是跨部門、多流程的專案，比如開戶過程中，需要判斷各種資料，像是身份證件、駕照、健保卡等，前端資料審核流程採用RPA進行，並部署在2.0上。

團隊建立了不少AI模型來判斷各種資料，也用來判斷顧客風險，最後再利用RPA技術來串接整個流程，成為數存秒開服務。

用Airflow工具拆分工作流程，調整更有彈性

既然玉山將MLaaS平臺定調為服務平臺，從服務角度來看，MLaaS 2.0的可用性就得非常高，玉山智金處訂出的目標是「得達到99.9%」。為此，他們不只將MLaaS 2.0改用資源調度更彈性的容器工具，也引進不少自動化機制，來維護服務品質。

像是導入熱門的開源流程工具Airflow，將原本龐大的資料ETL工作流程和AI專案，拆分為多個小工作來執行，更彈性管理。

以Smart Channel推薦系統專案來說，這個專案用途是，當使用者登入行動銀行App時，自動推薦相應的金融產品。而Smart Channel推薦所參考的資料，包括了使用者個人檔案、瀏覽記錄（點擊資料）、交易記錄。

在MLaaS 1.0時代，所有工作流程都是一條龍式進行，要是其中一個環節出問題，就得從頭來過。比如，MLaaS平臺要進行Smart Channel的資料ETL，就得先處理瀏覽資料，再處理交易資料，最後才是個人檔案資料。要是交易資料出問題，就得重新從瀏覽資料處理開始，再執行一次。

但，採用Airflow提供了用流程圖來安排工作組合的機制，可以將不同的工作拆開成更小單位的工作，並且畫出一張流程圖，稱為DAG（Directed Acyclic Graph），來組合這個流程中的多項任務的程式，比如，可以將瀏覽資料的過程，製作出一張DAG，涵蓋了瀏覽資料的多項任務，以及跟這些任務之間的執行順序或關聯，而交易資料又可以製作成另一個DAG流程。如此，其中一個環節出問題，直接修改該張DAG流程圖即可，不必按照順序重新來過。最後在按照這些DAG上安排的任務先後順序和關係來執行每一個任務的程式。

特別的是，Airflow採事件驅動（Event-driven）機制，當新資料出現，就會自動觸發特定的DAG流程，隨後展開一系列的資料或模型更新。比如，Smart Channel的部分交易資料會採用行銷部門資料，這些資料與行銷活動相關，是季節性的。不過，只要這部分資料更新，就會觸發專門處理行銷資料的DAG，隨後進行模型訓練，自動更新運算結果。要是行銷資料未更新，模型就延用舊資料來運算。

這種將龐大的工作切分為小任務的處理方式，讓資料處理不被一條產線綁住，各種任務組合可彈性調度，就算其中一個出問題，也能跳過由另一個替代任務接手，這就像是故障自動切換機制一樣。而且，將工作流程設計成一個個DAG流程圖，還能重複利用，當其他業務有需要，可取用現有的DAG來運算，比如前述的行銷資料。

不只如此，Airflow還有一個特性，能讓智金處將工作管理權限，下放給分析團隊。分析團隊不只是查詢運算工作的執行狀態，還能自行直接處理故障問題，不需如MLaaS 1.0時代般，還得自己請系統管理員查明原因。這個管理權限下放，讓團隊工作更有效率。

用FastAPI快速開發API，自建API型錄讓平臺標準化

不只用Airflow彈性管理工作流程，玉山還在MLaaS 2.0中，導入了FastAPI開發框架。這個API開發框架，可根據程式快速產生符合OpenAPI標準的規格文件，並生成API。這些API文件，詳述了請求參數數量、參數型態，以及回應的內容說明等規格。可供前端開發者，來理解這一支API的規格要求。

就算程式碼有所變動，前端開發者也能馬上得知。比如，原本請求參數有5個，現在新增了第6個，FastAPI框架就會根據變動，自動產生新的規格文件，再加上玉山搭配Git版本控制系統來管理程式碼，因此FastAPI產出文件後，直接儲存到內部共用的網站上，讓開發者查詢新版文件，也能先做簡單的測試。

這種將API規格文件和程式碼結合的做法，讓開發者更容易聚焦在邏輯討論上。再來，以往智金處都以Email傳送規格文件，收件者的版本未必是最新版本，改用FastAPI，可以解決版本同步的需求。

除了自動產生規格文件，FastAPI還有型別檢查的功能。假設前端系統呼叫出錯，傳送錯誤的參數型別資料，FastAPI就會自動告知前端系統，傳送錯誤資料了。可以說，FastAPI框架統一處理錯誤管理，讓開發者更專注於程式開發。

為了有效管理API，智金處也在內部網站，打造一個API型錄中心：API Document Hub，開發者可從中找到智金處出品的所有API，包括上百支API的詳細規格。這種管理機制，減少了開發者之間的溝通成本，讓專案開發更有效率。搭配FastAPI這個標準化工具，MLaaS平臺更像是一個具備通用、標準規範的產品，來服務玉山內部使用者。

圖片來源／FastAPI
玉山智金處在MLaaS 2.0中，導入FastAPI框架，可根據程式碼自動產出符合OpenAPI標準的API規格文件，一旦程式有所修改，也會自動更新文件，還能處理錯誤管理。

以普羅米修斯監控每天百萬筆Log，下一步要打造全自動監控

有了Airflow和FastAPI加速開發管理工作，接下來，在維運部分，玉山也採用開源監控工具普羅米修斯（Prometheus）搭配Grafana介面，來檢查系統產生的日誌，而機器學習服務所產生的日誌，則由搜尋引擎Elasticsearch搭配Kibana介面來處理。

對玉山來說，採用監控工具並不是一句話那麼簡單。要監控系統，系統首先得有日誌，智金處成員花了大量時間，來學習如何更有效率地產生日誌，來反應系統現況，才能讓開發者用工具查找狀況。他們也建立一套日誌撰寫指南，來確保日誌品質。

智金處透露，一個系統1天就會產出100萬筆日誌，雖然有這些工具輔助監控，但系統管理者還是需要花5分鐘，人工監看系統狀況。他們把這個工作稱為「巡田水」，雖然檢視工作並不耗時耗力，但他們正研究，如何將系統產生的日誌和機器學習服務產生的日誌集中起來，並利用這些日誌，訓練一套模型，來自動化監控系統。這是為了讓MLOps機制更完善，也是智金處團隊接下來的目標。

讓維運更完善，實行SRE的事後分析作法

機器學習維運除了採用平臺工具，還得有套維運機制。智金處早在2、3年前，就開始實行「Postmortem」（事故後分析）的做法，這是SRE維運的方法論，就像是進行驗屍報告般，來展開事後分析。

玉山導入Postmortem有2個目的，一是專案上線後，召集專案開發團隊、業管單位和系統部同仁，像是收集日誌的團隊和負責MLaaS平臺CI/CD的團隊等，每次約10至20人，由專案團隊攤開程式碼，來分享設計重點及原因，以及好處和可再精進之處。

另一個用意則是異常事件發生、問題解決後，透過Postmortem來回顧異常事件的發生近因及根本原因（Root cause）。這時，一樣會召集所有相關團隊，但智金處會要求負責團隊，要鉅細靡遺的執行Postmortem，不只要分析系統日誌、對比程式碼，還得走訪使用者單位當時的系統經歷，藉此來思考改善方案，避免下次踩雷。

比如，去年一次資料庫當機，團隊展開Postmortem分析，才發現根因是RedHat的Linux OS光纖網路卡有問題，這是平時難以察覺的問題，但過度使用資料庫的近因，才暴露了這個問題。在那次Postmortem之後，團隊開始改善系統架構，像是落實讀寫分離、調整AP程式存取資料庫的模式，來預防再次出現異常。Postmortem對維運很重要，不只能找出長期發展的痛點，還能讓團隊工作透明化。而且，它不只是玉山用來分析事件的方法，更是相關人員互動的場合，藉由互相問答，來讓業管單位了解，技術團隊種種技術背後的考量。

對玉山而言，這是成員學習的歷程，而非究責的歷程。

今年目標：朝7x24小時維運不中斷邁進

隨著玉山銀行董事長黃男州在年初法說會上宣示，接下來10年要成為亞洲的玉山，玉山也對打造關鍵技術的智金處，寄予更高的要求，維運要達到7x24小時不中斷。

為因應這個要求，智金處除了導入工具來強化ML監控，去年開始也打造一套模型維運平臺，來管理模型生命周期，目標是要建立一致、標準化的模型監控作業。

為了加快開發，他們採用商用模型效能管理應用程式，透過內建的模型量測評估指標，像是準確率、F1分數、靈敏性、特異性等，來追蹤模型是否偏移。蒐集到模型效能數據後，智金處再客製出視覺化儀表板，來追蹤上線模型的異常狀態，並自動發送通知，還能在數分鐘內產出監控報表。

不只引進各種工具，玉山對技術人才的尋求，也從未停止過。不論是系統開發、ML專家，還是今年所聚焦的MLOps、SRE維運好手，都是規模百人的智金處所渴求的。對他們來說，今年的目標是深化各項ML服務的開發、部署和維運，來支援玉山嵌入式金融服務。