為美好的數據獻上祝福！

  「那你現在算全端了嗎？」  「不不，還差得遠！😅」  # 前言  在應用系統開發實務上，就算你把前端刻得出來、後端 API 也設計得有模有樣，頂多只是做出了一個「能動的東西」。但「能動」跟「能活」，是兩件差很多的事。  一個能活的系統，需要有人（或者一套機制）負責讓它在對的環境裡跑起來、確保它跑歪了有人知道、更新它的時候不會順便把什麼東西搞壞、以及保護它不被奇奇怪怪的人亂戳。  這些，就是本篇文章要聊的後半場課題：DevOps、資訊安全、系統分析與設計、還有系統整合。    # DevOps  在開始接觸 DevOps 之前，我對它的理解大概是：「寫個 script 讓程式自己更新，這樣就不用手動了。」這個理解沒有大錯，但它只抓到了 DevOps 的皮，沒有抓到骨。  DevOps 的核心其實是一個問題的解答：「開發者做出來的東西，怎麼讓它穩定、可重複地到達使用者手上，而且出了問題能夠快速恢復？」  這個問題的背後，牽涉到的不只是 CI/CD pipeline 的設定，而是整個開發、測試、部署、監控的流程設計。乍聽之下很簡單，但當你開始細想，就會發現問題一個接著一個冒出來：  新版模型訓練完之後，怎麼確認它比舊版好再換上去？  如果新版上線之後發現結果不對，怎麼快速退版？  模型更新的過程中，服務要繼續提供預測還是先暫停？  這整個流程有沒有日誌記錄？  有沒有人在監控這些日誌？  每一個問題，都指向一個需要設計的環節，而不只是寫一段程式碼就能解決的事。一直到我在業界當中，實際參與應用佈署流程，親自接觸 GitLab + Harbor + Rancher + Argo CD 等 Kubernetes  生態系工具來實作 DevOps，才更加深刻地體認到 DevOps 當中「可重現的環境」這個概念的重要性。    # 跨越 Windows / Linux 的系統鴻溝 大多數資料科學家的日常開發環境是 Windows、公司配的筆電是 Windows，Excel 是 Windows，連 Jupyter Notebook 大概也是在 Windows 上跑的。一切都很和平，直...

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

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

 2024 的最後一天，就以這篇文章作結！ 先講結論，直接拿標題下去網路搜尋，或者直接問ChatGPT、Gemini 等生成式AI，可能都能夠獲得比這篇文章還要詳細完整的答案。而筆者在這篇文章要分享的，是在過去一年來，所應徵過的 LLM 相關工作職缺時，被問到的問題。 雖然筆者本身過去幾年的確都在製造業當中從事演算法相關的應用開發工作，但因為部門屬性、專案的應用場景、公司的數位轉型政策、以及其他大人們的因素。筆者一直沒有機會真正接觸到生成式 AI 的開發工作。 打從 ChatGPT 一砲而紅之後，各家科技巨擎的生成式 AI 模型宛如軍備經賽般地快速發展，乃至今日，無論是功能強大的商業型生成式AI服務平台、完整的開源生成式AI開發工具生態系、各種新興的商業模式與應用等等，都不斷推陳出新、日新月異！ 技術領域當個早期進入者當然有其風險與優勢，想想兩年前那些還在燒腦如何 fine-tuning LLM的前輩們，看到現在隨便一個LLM搭配個 Multi-Agents、RAG 的效能與功能完整性都比當年度燒肝燒薪水出來的玩意還要簡單易用，大概滿肚子辛酸血淚XD 現在才打算踏入 LLM 應用開發的求職者們，也不見得要灰心，因為現在要真正做LLM的應用開發，跟兩年前比起來可方便且快樂多了，但那也表示，這個就業市場也差不多一片紅海了XD 但總之，LLM 的相關整合應用，在未來幾年勢必仍舊會是一項趨勢，要不要踏上這條路，就看每個人如何權衡了🍵 好，感言說完了，以下就逐條羅列筆者在前述所提到的求職技術題目。題目的答案，就不占篇幅了，留給各位讀者們做功課： 『在 NLP 的領域中，請解釋什麼是「Language understanding」？』 『在 NLP 的領域中，請解釋什麼是「Question Answering」』 『在LLM 的 RAG 應用當中，如何評估 Retrieve 的正確率？』 『在LLM 的 RAG 應用當中，面對較大的知識庫時，有什麼可以優化 Retrieval 效能的方法？』 『假設你所隸屬的公司所使用的線上會議工具是 _______（基於大人們的因素，這裡以空格替代，讀者們可以自行想像是哪一套線上會議軟體），用戶想要把線上會議的內容，以自動化的方式產出摘要提供給會議召集人，請問如何應用 AI 技術作為解決方案？需要多少工時完成此需求？請簡單列出專案計...

約莫三個月前，我完成了 Coursera上面的這幾項課程。想透過這邊文章來記錄一下這個學習歷程。 Q：「為什麼再進修以及選擇這些課程？」 A：「作為一名資料科學應用開發人員，持續學習新理論與新技術是理所當然的事情！」 而這不限於新東西，哪怕是已經十分成熟的技術，但先前自己沒碰過，現在或者未來需要用，那當然教學！現實社會當眾討生活，不進則退，理所當然。由於我自己的工作內容主要專注於製造與供應鏈管理應用場景的演算法開發設計，對於資料工程、資料架構設計、開發過程的測試與驗證…… 等等，較少有著墨。為了提升自己工作技能的廣度與就業彈性，才選擇了這些課程。 IBM Applied DevOps Engineering Professional Certificate https://www.coursera.org/professional-certificates/ibm-applied-devops-engineering IBM Data Warehouse Engineer Professional Certificate https://www.coursera.org/professional-certificates/data-warehouse-engineering IBM AI Engineering Professional Certificate https://www.coursera.org/professional-certificates/ai-engineer NoSQL, Big Data, and Spark Foundations Specialization https://www.coursera.org/specializations/nosql-big-data-and-spark-foundations Q：「為何選擇 Coursera？而不是其他綜合學習平台，或者 M$、Google、提供的官方學習平台？」 A：「技能的廣度與通用性、CP 值高！」 要選擇哪一個線上平台或者數位學習工具？這是使用者自己最先要面對的問題。對我而言，選擇 Coursera 的最大原因，正是上述這三點，這部份就可以細一點來談了！ # 技能的廣度與通用性 首先是「課程內容的技能通用性」這一點，M$、Google、AWS 等大廠雖然也都有推出自己的數位...

圖源：Seq2Pat: Sequence-to-pattern generation to bridge patternmining with machine learning. |  AI Magazine Volume 44, Issue 1, Mar 2023, Pages1-130.  # 前言 筆者在 前一篇文章 當中提到了關聯規則分析在製造業當中的相關應用場景，而在本篇文章當中，筆者提到一些關聯規則的變體。正如標題的提問：「關聯規則分析，除了 Apriori   之外還有什麼？」，不外乎正是因為 Apriori 演算法的地位就相當於迴歸分析當中的 簡單線性迴歸 。因為它實在太經典，理論簡單清晰且樸實無華，談到關聯規則分析的演算法不外乎一定會想到 Apriori。但也因為如此，其實用性必定然不如後續各種改良版的演算法。本篇文章依舊不討論理論細節，只聊聊若考量了更多分析要素的情況下，關聯規則演算法可以怎麼玩？ # 階層與類別 Multidimensional and Multilevel Association Rules。這是資料分析實務上幾乎會存在的議題，以超市商品銷售分析為例，商品的用途分類、品牌、價位、供應商、是否有打折？是否為當季商品？這些類別屬性本身就是重要的統計資訊來源，而有了類別屬性就能夠依此來賦予階層的資料劃分。經典的購物籃分析當中只到啤酒跟尿布，但若我們將上述屬性給納入分析當中，那麼可能資料本身就要經過更嚴謹的標記處理，甚至是調整演算法本身，才能使分析結果更具詮釋性。 相關參考文獻： Comparison of New Multilevel Association Rule Algorithm with MAFIA. | International Journal of Intelligent Systems Technologies and Applications 6(11):75-81, October 2014, 6(11):75-81. Mining Multi-Dimensional and Multi-Level Sequential Patterns. |  ACM Transactions on Knowledge Discovery from Data (TKDD), ...

# 前言 關聯規則分析（ Association Rule Analysis ） 大概可以列入所有入門資料科學、數據分析的朋友們，都聽過的一門分析方法，最常見的應用不外乎就是購物籃分析（ Basket Analysis ） 與推薦系統，尤其是那個經典的美國超市的「 啤酒與尿布 」 的案例。 這幾乎是筆者現在每次聽到的時候都會直接腦袋放空的案例，直到筆者在某一次的相關技術分享當中聽到有人提到「月餅與烤肉架、柚子與木炭」這項範例，筆者才發自內心一笑 XD 而誠如標題，這篇文章要討論的關聯規則在購物籃分析之外的應用。 白話來說，關聯規則分析，就是計算在資料集當中不同「項目」（item）共同出現的頻率，藉以找出「具有一定統計顯著關聯」的「規則」。而這個「項目」的定義，自然就根據應用的領域而有所不同。例如各位可能也在教科書或者各大教學網站當中看過，關聯規則分析在醫療生技、投資組合、網路資安控管等等的應用。筆者本身所處的產業是電子製造業，理所當然地要來跟各位簡單聊聊關聯規則在電子製造業的相關應用。 # 異常事件偵測 這類的應用與資安控管、金融詐騙等應用相似，都是將關聯規則分析作為「異常檢測」（ Anomaly detection ）的方法。而製造業常見的異常檢測議題有什麼呢？機台設備的保養檢查、產品品質檢驗、客戶的需求預測。都是常見的應用。 製造業本是高度實體資本集中的產業，任何可能影響產線正常運作與出貨的事件，都很可能造成公司損失。因此，確保產線能正常運作、產品品質無慮，是製造業無時無刻都在關注的事情。而客戶的需求預測，則就不限於電子製造業，日常營運當中包含實體進出貨作業、並且有庫存成本考量的產業，皆是如此。而「精準地預測客戶需求」本身就是一項艱難的任務，即便是大數據與人工智慧技術蓬勃發展的 2024 年也還是一樣 否則每一位資料分析師就都拿資料套個模型炒股發大財去了 。而關聯規則分析則有機會找到異常波動的一些蛛絲馬跡，提前做好防範措施。 相關 理論 應用範例： Interpretable failure risk assessment for continuous production processes based on association rule mining.｜Advances in Industrial and Manufacturing Engineeri...