前言
大家好，我是 Edward，目前在 LINE Data Dev 擔任 Data Scientist。
最近我們很榮幸接待了 清大設計思考與數據分析社（NTUH DTDA） 以及 臺大人工智慧應用社（NTU AI） 兩個社團到LINE參訪。能夠以講者的身份與兩校同學交流，對我來說也是很寶貴的經驗。
這篇文章把當時兩場分享的內容整理起來，總結我在LINE做資料相關開發的心得、面對模糊需求時如何拆解問題，以及 Agentic AI 時代下資料科學工作可能出現的變化。希望不論你是否有參加企業參訪，都能從這篇文章中得到一些啟發。
Data Dev 團隊在做什麼？把LINE的大量資料轉化成真正能上線的服務
在 Data Dev 的工作可以用一句話概括：
把 LINE 上數以千萬計的 raw data，轉化成能真正落地、並讓使用者實際體驗到價值的服務。
這個過程並不是單一路徑，而是一段需要多種專業協作的過程。
在不同階段，我們會運用到：
- Data Engineering：建立資料 pipeline、確保資料可靠可用
- Data Science：進行分析、萃取資訊、提出洞見
- Machine Learning：挖掘資料隱藏的特徵，協助我們全面地解決問題
- Software Development：把邏輯或模型真正整合到軟體服務之中
你可以把它想像成：
我們收到的是「資料相關或 AI 相關的需求」——而我們的任務就是把落地成一個能在產品端被使用者體驗到的功能。
這中間會遇到很多挑戰：資料是否足夠？邏輯如何落地？模型如何部署？跨團隊如何協作？而這些正是 Data Dev 團隊每天都在面對、也最有成就感的部分。
我怎麼設計一個 Data-Driven 專案？從模糊到落地的方法
面對一個模糊的需求，到底該怎麼開始？資料專案往往看起來很複雜，但真正的挑戰通常來自一開始的「不確定性」。
在處理這類需求時，我自己有個一貫的習慣：
先把問題拆解。
我會透過不停問自己問題的方式，把原本模糊的需求逐漸拆成可理解、可測量、又能真正落地的子問題。只要拆解得夠細，就能開始一步步逼近可實作的解法。
以下以一個實際在工作中遇到的任務為例：
「想偵測每日 KPI 是否異常。」
需求只有這樣一句話，沒有定義 KPI、也沒有說什麼叫「異常」。
而這正是許多 data-driven 專案的起點。
Step 1：定義指標
我會先從釐清問題開始。
-
KPI 到底指的是什麼？
是日活躍用戶？每日瀏覽數？還是某個行為事件的發生量？
-
「異常」又該怎麼定義？
是用 二元分類模型？還是用 outlier detection？
這一步看似簡單，但非常關鍵。
若問題或是指標定義不清楚，後面所有分析與模型都無法真正滿足需求。
Step 2：收集資料
指標確定後，我會開始確認資料層面的可行性：
- 有沒有資料？量夠不夠？
- 是否乾淨、可靠？
- 如果拿不到資料，該調整指標還是換方法？
Step 3：萃取資訊
這裡就進入大家比較熟悉的領域了，包括：
- 看資料分佈、做視覺化
- 建立特徵
- 訓練模型、觀察 pattern
回頭看過去，我發現學生時期的我常常會直接從這裡開始做起——
但實際在工作裡，前面的問題釐清和資料確認，往往會更決定專案能不能順利進行。
Step 4：產生洞見
身為資料科學家／工程師在說明專案內容時難免會被半開玩笑地提醒一句：
「可以講人話？」
這句話聽起來有點好笑，但背後其實是在說：
模型的準確率、特徵權重、係數大小……這些對我們來說很重要，但對商業或產品團隊來說不一定能直接轉化成意義。
他們真正想知道的是——
- 為什麼今天會出現這個異常？
- 會對產品或營運造成什麼影響？
- 這代表我們需要提前調整策略嗎？
所以這一步的關鍵在於：
如何把技術性的結果，轉譯成商業場景真的能用、能理解的 insight。
Step 5：擴展應用
做到前面四步後，一個 data-driven 專案基本上已經可以落地了。
但我會再問自己：
「這個 solution 有沒有可能變成一個更通用的 service？」
例如：
- 套到不同服務會需要改動哪些功能？
- 設計邏輯哪些能抽象化、模組化？
- 能不能讓它支援更多不同類型的商業場景？
這一步常常決定：
一個 solution 能不能真正升級成可長期使用、並且規模化的 service。
Agentic AI 對資料科學帶來的影響
近年 AI 的發展速度非常快，也讓資料科學的工作方式開始出現明顯變化。
若從模型能力的角度來看，整體演進可以簡單分成三個階段
-
ML/DL 模型：輸出可能性有限
輸出為分類、分數、機率、迴歸數值等固定格式。
-
Generative AI：有限輸出組成無限可能
將有限 token 輸出，透過排列組合生成文字、圖片、語音等無限的可能性。
-
Agentic AI：透過外接工具取得「決策能力」
能主動決策、使用工具、發 API、跑 SQL、解讀文件並執行任務。
而當 Agentic AI 技術越來越成熟，我開始重新檢視自己前面拆解的資料科學流程：
哪些步驟可以交給Agent？交給 Agent 之後會帶來什麼 trade-off？
我自己的觀察是
依照 Agent 所看到的資料「處理程度」不同，可以分成三個層次，從 洞見 → 結構化資料 → 原始資 料，資訊越往前越 raw，Agent 的自由度也越高、不穩定性及風險也越高。
在這一層，AI Agent 看到的是已經處理好的資訊，例如：
- 模型輸出
- 統計指標
- 已整理過的分析結果
它的角色像是：
- 幫忙解釋模型
- 將技術語言翻成商業洞見
- 自動生成報告或摘要
- 根據結果通知利害關係人（搭配 messaging tool）
這其實是我最常把 Agent 鑲嵌進 data solution pipeline 的地方。
因為資訊已經整理過，所以 AI 更容易理解，也比較不容易出現預期之外的結果。
第二層：萃取資訊（AI 看 structured data）
接著往上推一層。
這時 AI 看到的是：
- 已整理好的 structured data
- 乾淨的欄位、特徵、表格
它能做的事情也更多，例如：
- 覺得資料適合用哪種模型（classification / clustering / anomaly detection…）
- 主動決定特徵該怎麼處理
- 自動跑 baseline、比較不同方法
- 依照目的選擇我事先準備好的工具列（toolbox）
這一層 agent 的自主性更高，但也更需要：
- 給它好的工具
- 清楚定義任務邊界
- 謹慎監控它的決策過程
第三層：收集數據（AI 看 raw database）
再往上推一層，就是最 raw 的層級——
讓 AI 直接面對 原始資料庫（raw database）。
AI 可能做的事情包括：
- 根據任務需求自己寫 SQL
- 決定 join 哪些表
- 選擇要拉哪些欄位
- 挖掘它認為有用的資料片段
這邊的挑戰也最多：
- raw data 非常雜，AI 容易錯誤理解
- 欄位之間的意義需要 domain knowledge
- 權限一定要嚴格限制（AI 只能讀、不能寫）
從洞見 → 結構化資料 → 原始資料庫，AI Agent 能看到的信息越來越 raw，能做的事情越來越多，但 trade-off 也更明顯：
- 越前面的階段（產生洞見）越安全、越容易落地
- 越往後的階段（收集原始資料）越需要小心權限、驗證與邊界設定
透過這樣的分層，我在實際專案中會更容易釐清：
- 該把 AI 用在哪裡最有效？
- 哪些地方要給 AI 自由？
- 哪些地方一定要有人的判斷？
當天同學們的提問：兩個讓我印象很深的問題
在兩場企業參訪中，同學們提了非常多深入又有趣的問題，從 AI 技術到產品決策都有。
其中有兩題讓我印象特別深刻，我也在這裡簡單分享我的想法。
Q1. 在做新功能或整合服務時，背後的思考邏輯是什麼？
以 Data Dev 這種比較中央的團隊來說，我們會收到來自不同服務的資料或 AI 相關需求。
在真正把一個 idea 做成產品時，我個人的做法是採用 MVP（最小可行性產品）思維：
- 先做出最小版本
- 快速得到回饋
- 再逐步微調與迭代
我喜歡用 攀岩比喻：
每次移動時，都會固定住三個點，只移動其中一個。
穩定地前進，不需要每一步都大突破，但每一步都能更加接近目標。
這種做法能確保速度與品質取得平衡，也讓專案更容易持續推進。
Q2. 在導入 AI 到產品時，團隊如何做決策與優先順序評估？
AI 很強，但不代表所有問題都適合用 AI 解決。
我在評估「要不要用 AI」時，通常會優先思考：
- 錯誤風險低嗎？
- 任務重複性高不高？
- 適不適合模糊化處理？
例如近期有在開發一套能整合內部服務文件知識的搜尋工具。
由於各服務的文件格式都不同，單靠 coding parse 其實很難做到統一格式；
但 LLM 的強項剛好是語意整理與模糊化處理，因此在這類場景中導入 AI 的效果就很好。
結語
這兩次企業參訪活動，對我來說是非常有收穫的經驗。
除了能與清大 DTDA 以及台大 AI 社的同 學交流，也讓我重新整理了自己在LINE做資料開發、設計 data-driven 專案、以及面對 Agentic AI 時的思考方式。
也很感謝 Developer Relations 團隊籌辦這兩次活動，讓我有機會把這些經驗分享給大家。
