「你過去做的這些模型,有實際落地嗎?」 # 前言 這應該是許多新手資料科學工作者,在轉職面試時,都被問過的問題。不外乎地,在分工體系明確、或者有友善的 IT 前輩照應的公司當中,菜鳥資料科學家們的確可以只專注在資料與模型上。但隨著職場閱歷漸長,我們 莫名理所當然地 被期望要會更多東西、懂更多技能、能做更多事情。尤其在這個人人都可以用生成式 AI 來建立模型的年代。 是故,為了生存,我們不得不跳脫舒適圈,開始學習如何自己刻前端、串後端、讓系統自動跑起來、還要有能力規劃整個系統方案架構。職場專業的分水嶺差不多就從這裡開始,們開始親身感受,一位「資料科學家」和「能做出系統的開發者」,到底差在哪裡? #「會寫程式」和「會做系統」是兩回事 我們姑且先不談「程式碼品質」與「設計模式」這些奢侈的玩意。「會寫程式」和「會做系統」的差異,並非只在技術層面,更多是在思維模式。 在資料科學的訓練環境裡,姑且不論應用領域,只要你的模型在生產環境/線上環境當中也能夠跑出好棒棒的結果,使用者與老闆讚譽有加,恭喜你就算成功了!👍 但對於系統開發而言,我們得看得更多更廣更深更遠…… 系統是否在所有預期的輸入條件下都能正確回應? 在非預期的輸入條件下是否能優雅地失敗? 在流量高峰時是否能維持可接受的回應時間? 在需要更新時是否能不中斷服務? 在出錯時是否能讓維護人員快速定位問題? 你不先去解決問題,問題就會來解決你(O) 有些資料科學家可能幸福一點,不必煩腦上面這些問題,但之所以我在這篇文章當中提到了,就是因為我是要面對的那一個 XD # 那些厲害的工程師在想什麼? 這邊也先不談辦公室政治與職場生態學那種高端的玩意 在這幾年的工作經驗當中,我觀察到,那些有一定年資的工程師,他們幾乎不太急著討論「要用什麼技術實作」,而是先花時間釐清幾件事: 這個系統的邊界在哪裡?它應該負責什麼,不應該負責什麼? 資料從哪裡來,要去哪裡?哪些上下游系統有介接? 輸入的資料是誰提供的,格式是什麼,品質有沒有保障? 輸出的結果要寫到哪裡,誰會讀它? 這個系統的使用者是誰,他們的技術能力如何? 他們能接受多複雜的操作流程? 他們看到錯誤訊息的時候,需要看到什麼才知道怎麼辦? 這個系統需要多可靠? 如果它停機一個小時,業務損失是什麼等級的? 這決定了你要花多少力氣在高可用性(High Availability)的...