Where Skills Meet Impact: My LINE Internship Experience_ 台科大管院企業參訪

前言

大家好，我是 Amber Chen，目前在 Data Dev, Data & ML Platform Team 擔任 Intern。

從校園走向真正的產品開發環境，這段轉變充滿挑戰，也讓我第一次深刻感受到「把技術落地到真實世界」所需要的責任與思維。在 LINE 這個高手雲集、節奏迅速且講求品質的環境中，我從一名對企業級流程仍懵懂的新手，逐步學習如何參與大型系統、資料平台與 AI 服務的開發。透過實際體驗 DevOps 與 MLOps 的完整流程，我看見了工程師在系統背後，為可靠性與可擴展性所進行的長期工程投入。

今天想透過這篇文章，分享我在 LINE 的學習旅程，包括參與的專案、面對的挑戰，以及在團隊協作、技術能力與開發思維上的成長。希望能為即將步入職場、或對資料與 AI 工程領域感興趣的讀者，帶來一些實用的觀點與啟發。

Data Dev Team 負責的任務

在 LINE 的產品與服務背後，每天都會產生大量多元的資料，包含文字、影像、使用者操作行為等。而 Data Dev Team 的核心使命，就是支援這些資料從原始收集到最終成為 AI 應用的完整生命週期。

在 Data Processing 階段，我們整理並清洗來自不同來源的資料，確保其可用性；在 Data Utilization 階段，團隊會進一步分析整理後的資料，並建立模型，讓資料能夠轉化為具體且可行的洞察與預測；最後在 AI Applications 階段，將模型整合到產品中，讓生成式模型、推薦系統或偵測服務落地，為 LINE 使用者帶來實際價值。

透過這樣從資料處理、分析、建模到應用的完整流程，Data Dev Team 確保 LINE 的資料與 AI 能力能持續推動產品創新，並在各項服務中發揮最大效益。

我參與過的專案

LINE SHOPPING：Object Detection Service Development

我加入 LINE 後參與的第一個專案，是 LINE SHOPPING 中以圖搜圖功能的 Object Detection Service 開發。我在這個專案負責的部分涵蓋了整個開發流程，包括模型研究與選擇、資料處理、流程建置，和完整的模型訓練及部署。最具挑戰性的部分，是我們的原始資料並未經過標記。而在資料缺乏標註的情況下，我們如何訓練出高效能的模型，是一大難題。為了解決這個問題，我們採用了 Auto-Labeling 與人工互動輔助的方式來生成訓練資料，最終顯著提升了模型的整體準確度。

OA: Image Forgery Detection

在 LINE 生態系中，有大量官方帳號供使用者取得資訊或服務。然而，隨著詐騙行為日益猖獗，不肖人士可能會偽裝成官方帳號進行不法活動。為了阻擋這類風險，我們著手進行圖片偽造識別與相似度偵測的研究。希望能透過模型比對申請者所上傳的圖片，當相似度達到一定門檻時，便對該申請帳號採取相應的處置，以降低偽冒官方帳號的可能性，保障使用者安全。

Internal Service: Image & Text Generation

除了面向使用者的服務之外，Data Dev Team 同時也負責內部工具開發，提升其他開發團隊的工作效率。這個專案的核心目標是協助大家生成文案與圖片，並打造一個 Agent，將現有工具串接起來，讓使用者能更便捷地操作。我主要負責 Agent 的研究與後端開發工作。

如何真正把專案做「穩定」：DevOps 與 MLOps 的價值

剛開始實習時，我就體悟到，在公司開發與在學校做 Side Project 或課堂作業，完全是不同層次的世界。

在學校，我們常見的開發方式往往缺乏完整的版本管理與持續測試，並且通常在交付前才一次性整合程式碼，也較少要求一致的程式碼風格。

這樣的方式在小規模專案中或許尚可運作，但若直接套用到企業環境，往往會造成團隊協作困難、品質不一致且維護成本高昂、錯誤容易在一次更新中集中爆發，並讓每次部署都充滿不確定性，系統也更容易在高負載或複雜情境下失效。

因此，在 LINE 的開發流程中，透過 DevOps 與 MLOps 建立穩定、可持續的工作流程，成為確保產品品質與服務可靠性不可或缺的一環。

DevOps：讓軟體工程從「完成」走向「可持續」

如果用一句話形容 DevOps，它是一種讓軟體可以持續、可靠被開發和部署的工作方式。

它透過版本管理、自動化測試與部署流程，讓團隊在多人協作時，能安心地修改程式碼、不用擔心一個改動就影響整個系統。DevOps 的核心目的不是追求速度而已，而是確保每一次更新都是可預期、可追蹤、可回溯的，讓軟體能在長時間運作與頻繁更新的情況下，依然維持品質與可靠性。

在這樣的 DevOps 流程中，CI/CD（Continuous Integration / Continuous Delivery）扮演著關鍵角色。每當程式碼有更新時，系統會自動進行建置與測試，確保新修改不會破壞既有功能，並透過自動化的部署流程將變更安全地推送到不同環境。透過 CI/CD，團隊能降低手動操作帶來的風險，讓部署不再是一件高壓且充滿不確定性的事情，而是成為一個可預期、可重複的日常流程。

在實習之前，我對 DevOps 的印象只有 CI/CD、部署流程之類的名詞，但真正看到 LINE 的開發模式後，我才理解它的價值。

DevOps 解決的是這些現實問題：

每次更新會不會不小心把別人的功能弄壞？
部署到底安不安全？可不可以不用半夜守著？
多人一起改同一份 codebase，要怎麼維持品質？
出了 bug 要怎麼快速找到原因？

在 DevOps 的流程裡，這些事情都變得「有制度、有依據、有工具」：

版本追蹤清楚
自動化測試會確認修改沒有破壞現有功能
部署流程可預期、可回溯
系統運作狀況有完整監控

對我來說，DevOps 帶來的不只是技術工具，而是一種工程文化：任何人寫的任何一行程式，都應該能被安全地維護和更新。

從 DevOps 到 MLOps：當程式碼不再是唯一的變數

在前面提到的 DevOps 與 CI/CD，主要解決的是一般軟體工程中的穩定性問題。然而，對 Data Dev Team 來說，事情並沒有這麼單純。我們開發的不只是程式碼，還同時需處理 Data 與 Model，而這正是傳統 DevOps 無法完全涵蓋的地方。

如果直接把 DevOps 的流程套用在機器學習專案上，很快就會遇到瓶頸。因為在 AI 系統中，即使程式碼完全沒有改動，只要資料分布發生變化，模型的表現就可能明顯下降，甚至在不知不覺中失效。也就是說，對模型而言，資料本身就是變動最快、風險最高的因素。這種「Code 沒變，但模型卻壞了」的情況，在實務上其實非常常見。

也正因如此，我們需要的是一個比 DevOps 更進階、能同時管理資料與模型生命週期的工程方法，這便是 MLOps 的角色。

MLOps：讓 AI 服務可維護、可重現、可擴展

如果 DevOps 解決的是軟體本身的穩定性，那 MLOps 就是讓 AI 模型能夠真正「活在真實世界」的方式。

以前的我認為，只要模型訓練成功、效果看起來不錯，就代表專案完成了。直到開始實習，我才真正看到一個模型要上線，還必須面對各種現實挑戰：

資料會隨時間改變，需要持續監控模型表現
推論速度必須符合產品需求
模型與訓練資料的版本需要清楚管理，才能在效能下降時快速 rollback
在實際服務流量放大後，模型是否仍能穩定運作

這些問題，其實都不是模型本身能解決的，而是 MLOps 所要處理的範疇。

MLOps 的核心，是負責模型的整個生命週期管理，從資料處理、模型訓練、版本管理，到部署與上線後的監控。透過這樣的流程，團隊能確保模型與環境是可追蹤、可回溯的，推論服務在真實流量下仍能維持效能，並在模型表現異常時及早發現並調整。也因此，模型不再只是存在於實驗環境中，而是真正成為產品的一部分。

也正是在接觸這些流程後，我開始真正理解：模型的生命不是停在訓練完成，而是從成功部署到真實環境後才正式開始。

從實驗到上線的 MLOps 實踐

我第一個參與的 LINE SHOPPING Object Detection Service 開發，即是完整實踐 MLOps 理念的專案。

在資料層面，模型所使用的圖片主要來自公司內部資料庫。由於資料量龐大且會持續成長，我們採用了 Auto-Labeling 搭配人工輔助標註的方式：先透過模型進行初步標註，再串接 Label Studio 讓人工進行修正與補強。這樣的流程不僅能提升標註效率，也讓資料能夠穩定地隨著時間累積，成為模型持續優化的基礎。

在模型開發與實驗階段，我們使用主流的 Object Detection 模型，並針對不同設定與資料版本進行反覆實驗與比較。為了讓這些實驗不只是「跑過就算」，團隊透過 Airflow 建立完整的訓練流程，將模型訓練自動化，同時把每一次實驗的指標與結果系統性地記錄在 MLflow 上。這讓模型的效能變化、參數設定與版本差異都能被清楚追蹤，也為後續的決策提供依據。

當模型準備好投入實際使用時，便會被包裝成可被呼叫的服務並正式上線。模型本身具有清楚的版本管理機制，確保在更新或調整模型時，能夠有跡可循，並在必要時快速回溯或切換版本。這使得模型部署不再是高風險操作，而是可控且可預期的流程。

模型上線後，工作並不會就此結束。為了確保模型在真實流量與實際資料分佈下仍能維持良好表現，我們透過 Grafana 與相關工具持續觀察服務與模型相關的指標，掌握模型是否出現效能下降或異常狀況。也正是透過這樣的監控與回饋機制，模型才能在實際產品環境中長期穩定運作。

透過這個 Object Detection Service 的實際案例，我也更加深刻地體會到，MLOps 並不是額外的負擔，而是讓模型能夠從實驗環境順利走進產品、並長期發揮價值的關鍵基礎。

在 LINE 的成長與收穫

回顧這十個月的實習旅程，我在 LINE 的收穫可以分成三個面向：技術能力、開發思維，以及團隊合作，而這三者也構成了我作為工程師逐漸成長的重要基礎。

技術能力：從問題分析、工具運用到程式品質的全面提升

最直接的成長當然是技術層面。在實際參與專案的過程中，我學到的遠遠超過課堂或個人專案所能帶來的經驗。

在問題分析上，我學會如何拆解問題、找出核心原因、提出可行解法，並透過數據驗證方案的有效性。面對大型資料量時，也更熟悉如何設計合適的處理流程、如何與大型資料庫與分散式系統互動，確保效率與穩定性。

在程式品質方面，Code Review 是一個讓我成長非常快的環節。我逐漸理解什麼樣的程式碼才算「好的程式碼」，不只是能運作，還要具備可讀性、結構清晰，並且維護成本低。透過與前輩的交流與回饋，我學會了如何讓程式碼真正達到工程級別的標準。

除此之外，我也接觸到許多原本不熟悉的工具與框架，這些工具讓我能更有效率地完成開發，也對整體工程流程有更完整的理解。

開發思維：從「把功能做出來」到「能長期運作」

另一個重要的成長，是思維上的轉變。過去面對問題時，我的目標通常只是把功能成功做出來，但在 LINE 工作後，我開始真正理解「可維護性」的重要。

我學會在動手寫程式之前，先思考：

這段程式未來好維護嗎？
有哪些 Edge Cases 可能會發生？
是否需要考慮更完善的錯誤處理？
能不能讓未來接手的同事更容易理解？

這些思考原本並不習慣，但逐漸成為我現在開發時的預設流程。此外，我也開始有意識地把 Ops 相關理念、可靠性、流程自動化等觀念納入開發考量，不再只關注模型或功能本身，而是整個系統的運作方式。

團隊合作：主動、溝通與跨國協作的寶貴體驗

最後，也是我覺得最特別的收穫，是團隊合作與溝通能力的成長。

一開始我以為實習生能做的事情有限，但在 LINE，我深刻感受到，只要願意主動，實習生能參與的事情其實非常多。只要敢提出想法，團隊都會非常願意傾聽與討論，也非常重視每位成員的意見。

遇到問題時，更不用擔心被貼上「不會」的標籤。只要願意發問，不論是同團隊或跨團隊，大家都會非常熱心地提供協助。我甚至遇過某些專案問題是台灣同事也不曾經歷的情況，最後透過跨國溝通，與國外的同事一起合作解決。這樣的跨國協作經驗，也是我在實習期間非常特別的收穫。

這些互動讓我真正體會到，「主動溝通」比「什麼都自己悶著做」更能帶來有效的成果。

前言