「模型開發完了，然後呢……？」 # 前言 在本系列的第一篇文章，我摘要了「從單點應用邁向整體系統」這個過程當中，各種歷歷在目的難題 你的常識不是你的常識 。從第二篇文章開始，就分別從幾個不同的技術層面，漫談的蛻變過程 不能只有我痛苦。 # 現實的前後包夾 為了讓我們絞盡腦汁開發出來的模型能夠真正派上用場，無論是專案早期要做個POC呈現、還是專案中後期真正的系統整合，自然會有一系列的前後端工程出現在隊伍裡面。到這邊為止，我們都知道，得有人去做這件事，要馬是公司的專門的IT單位、或者外包的資訊服務商、或者是我們自己來。 「出來混，遲早要還的」，以台灣的業界實況，我相信是模型開發人員被要求身兼前後端工程師（或者反過來，前後端工程師被要求身兼資料分析跟AI開發人員）的情況，應該比較普及，也才會有這一系列懺悔文XD這邊也沒有要談技術細節，而是我自己開始慢慢把守備範圍往前後端擴張的心得。 #「過度類比」的路徑依賴 這是作為一名統計與商業分析背景的資料科學家，在嘗試跨足前後端開發時時最容易踩的陷阱。因為我們習慣建立模型，習慣用一套已知的框架去解釋新的現象，所以當我們碰到一個陌生的技術概念時，很容易會說「啊！這個就像統計裡的 XXX 一樣嘛！」，然後在一個『不完全成立』的類比上繼續往下推論…… 資料庫的 index 跟統計的 index 不一樣、API 的 request/response 跟函數的 input/output 不完全一樣、前端的 state management 跟統計模型的 parameter 不一樣。這種『我以為是這樣，但不是這樣』的狀態很危險，因為它讓你在一個錯誤的基礎上繼續建構，而且很難察覺路已經慢慢偏掉了。 # 團隊合作精神 除此之外，為了能夠將模型端的玩意，能夠更順暢的與前後端串聯，也自然而然會開始去思考模型預測成效以外的事情。例如：從資料庫讀取資料進行訓練或推論的時候，為了節省運算資源，最好別暴力地將整張資料表讀進去，而是讀取我們需要的資料範圍就好。 又例如：為了讓預測結果能夠更方便地讓使用者做各種進階查詢應用，我們得將預測結果做更多地後處理。 再例如：每一次模型的預測結果圖片，為了降低前端負載，我們得想方設法找到一個使用者可以接受，但又不會讓前端超重的圖片格式與大小。種種案例族繁不及備載。 說到底，其實都是十分講求跨團隊合作與工程配合的事...