為美好的數據獻上祝福！

多數人談「跟 AI 一起寫程式」，很容易把注意力放在 Prompt：怎麼問得更精準、怎麼讓 AI 產生更好的程式碼。 但在這個專案的第一階段走完幾個 Task 之後，我得到了一個有點不一樣的答案： 「真正影響 AI 協作品質的，不只是你怎麼問 AI，而是你替 AI 建立了什麼樣的工作環境。」 這個環境裡，有規則、有任務邊界、有測試，也有獨立的檢查與驗證。而我自己真正需要做的，反而不是一直「教 AI 寫程式」，而是在它給出一個看似合理的答案時，多問幾次： 「你確定嗎？」 以及： 「我們真的驗證過了嗎？」 這五個 Task，最後留給我的，不只是一批程式碼，而是五個我認為值得帶進下一個專案的工程習慣。 ________________________________________ # 第一課：讓「能不能跑」當裁判，而不是「讀起來對不對」 專案早期，我曾經非常相信文件。一份設定檔看起來合理，一份規格也寫得完整，AI 審查過、我自己也看過，似乎就應該沒問題。 直到有一次，我們把容器真正建置起來，結果掛了。問題不是某一行設定寫錯，而是建置方式讓原始碼在開發環境中只是被「連結」進去，到了正式映像檔的階段，原始碼目錄消失，連結自然也跟著失效。 如果只看設定檔，很難發現這件事情。但只要真的建置、真的執行，問題立刻就出現。那次之後，我開始把一個很簡單的原則放進專案： 「凡是可以透過執行驗證的事情，就不要只靠閱讀來相信。」 一段寫在註解裡的限制，可能永遠沒有人注意；但如果它變成一個會失敗的測試，系統就會主動告訴你。所以後來遇到「這個東西應該可以跑」的說法，我不再把它當成結論。 實際跑一次！ 讓執行結果說話。 ________________________________________ # 第二課：連你手上的尺，都要先量過一次 當我開始依賴測試之後，又遇到另一個問題： 「如果測試本身就不可靠呢？」 於是我們開始用變異測試，故意把程式改壞，再看看測試能不能抓到，結果真的抓到問題了——但不是我們原本想測的問題。 有些測試單獨執行時可以正常失敗，連續執行卻偶爾會放過錯誤。一 路追查後，才發現底層的快取機制會依賴檔案修改時間；在特定情況下，系統誤以為檔案沒有改變，於是繼續使用舊版本。 換句話說： 「我們用來量品質的尺，本身量錯了。」 另一個例子也很有意思。獨立審查 AI 曾經判斷某個日誌工具...

  一開始，我以為這會是一個很單純的 專案設計過程 …… 先把需求與架構想清楚，再把規格文件整理完整，接著按照 Task 一個一個實作。尤其在 AI 開始大量參與開發之後，我更相信前期規劃的重要性：既然 AI 可以很快幫忙整理、比對、分析，那麼先把規格打磨得完整一些，後面的實作應該會更順利。 結果，我和 AI 一起把這件事情做得太認真了。最後甚至認真到，差點忘了我們原本是要做一個可以運作的系統。 ________________________________________ # 🏗 起點：我以為把規格做好，專案就會更穩 為了還有機會能夠實現「跨足半導體產業」的這個職涯發展目標，我在近期展開了一項以「半導體晶圓廠的數位孿生模擬系統建構」為主軸的技術展示專案。 在真正開始寫程式之前，我先花了大量時間整理既有設計。這些內容原本也是我在另一段長期 AI 協作過程中逐步建立起來的，涵蓋資料庫、事件定義、派工邏輯、部署方式等。 問題是，多輪討論留下來的設計，難免會有前後不一致、細節缺漏，甚至某些地方只是為了讓文件看起來完整，而被暫時補上的內容。 所以我的第一個想法很自然： 先請 AI 把文件好好審一遍。第一輪發現問題，就修正；修完，再審；再發現問題，就再修。每一輪看起來都很合理，直到後來，我開始發現，這套流程正在悄悄改變自己的目的… 原本我們想確認的是： 「這個系統到底怎麼做？」 後來卻變成： 「這份文件和另一份文件，是不是完全一致？」 # 🌀 當品質控管開始檢查自己 最麻煩的地方是，每一次審查都真的有成果。AI 找出了矛盾，我們修掉它；補上缺漏，我們又增加對應的規則與紀錄。於是文件越來越完整，審查機制也越來越細緻。 可是回頭看最後幾輪時，我發現一個很不舒服的現象： 後面的很多問題，其實不是原始設計造成的，而是前面的審查與修正自己製造出來的。 我們建立了一套自我檢查、自我糾錯的機制，最後卻開始花大量時間檢查自己昨天留下來的東西。 更尷尬的是，真正需要被實作的程式，依然沒有因此更接近可以執行。 那一刻我才意識到，文件的「完整度」和專案的「進度」其實是兩件完全不同的事情。 有些工作看起來很像品質控管，但如果它不能幫助系統更接近可驗證的狀態，就值得重新檢查它存在的理由。 ________________________________________ # 😶 ...

  「那你現在算全端了嗎？」  「不不，還差得遠！😅」  # 前言  在應用系統開發實務上，就算你把前端刻得出來、後端 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 等大廠雖然也都有推出自己的數位...