為美好的數據獻上祝福！

  「模型開發完了，然後呢……？」 # 前言 在本系列的第一篇文章，我摘要了「從單點應用邁向整體系統」這個過程當中，各種歷歷在目的難題 你的常識不是你的常識 。從第二篇文章開始，就分別從幾個不同的技術層面，漫談的蛻變過程 不能只有我痛苦。 # 現實的前後包夾 為了讓我們絞盡腦汁開發出來的模型能夠真正派上用場，無論是專案早期要做個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...

本系列的前五篇文章談到的，幾乎都是單一變數的時間序列資料。也就是假設每一樣產品的需求為獨立，彼此互不影響，每一項產品的預期需求完全分開來預測。但在業界實務當中，我們手頭上的時間序列資料，可能有群組與階層的隸屬關聯，而本系列的最後一篇文章，就是要聊聊具有這種結構關係的需求預測難題。 # 簡單的群組與階層拆分與整併預測 以筆記型電腦為例，假設某品牌商旗下有兩個不同系列的筆記型電腦（姑且就稱為 A 款與 B 款），假設這兩款都可以依照螢幕尺寸再分成 14 吋與 15 吋好了，該品牌的 A 與 B 兩款筆電都銷售全球（就粗略分成亞太、北美洲、歐洲、與新興市場四大地區好了）。有了上述的類別標籤，我們就能依照這些標籤，將過往的銷售數據進行群組與階層的拆分或整併。而在進行需求預測時，無論我們是「由下而上」（Button-up）先將切到最細層級的個別序列資料（例如 A 款的 14 吋筆電在亞太地區的未來預期需求）分別預測之後，再逐層往上堆疊；抑或是「由上而下」（Top-down）先使用彙總到最頂層的序列資料進行預測之後，再依照特定比例拆分到底下各層，這種兩分預測流程，從技術面而言都說得通，相關細節可以參考 該電子書的章節頁面 ，裡頭有十分詳盡的觀念談。 # 同時預測多條時間序列 若我們採行的是「由下而上」的預測方式，且假設我們明確知道同階層或同群組的序列資料當中，彼此具有一定程度的關聯性存在。這種時候就可以使用 向量自迴歸模型 （Vector Autoregression），針對同一階層或者同一群組的時間序列資料來進行預測。然而，就跟其他基於統計學的時間序列預測模型一樣，該方法的使用上要留意一些的限制與假設前提，否則用起來的預測成效也不會好到哪裡去，甚至根本用不起來。 例如最簡單的：當你一次把太多條時間序列綁成一個龐大的矩陣來求解……那麼求解的複雜度指數上升，甚至模型會因為無法收斂而直接跳 Error 給你看。又或者是，你綁在一起預測的這些時間序列壓根沒有統計上的關聯性，那麼為了圖方便性而向量自迴歸模型來做預測的結果，就跟你拿一串隨機序列的資料說要用 ARIMA 模型來準確預測下一步，是一樣的概念。 # 群組與階層的陷阱 延續上個段落所提到的，既然都特地寫了這篇文章，當然不是請讀者們把上面那本電子書的章節看過而已。雖然在業界當中的許多產品需求資料，都能夠依照上述方式來進行群組與階層...