菸酒生在 LINE Taiwan 的後端雙刀流

Speaker: Allen Chang
Event: LINE TECH FRESH 畢業分享會 2025

Transcript

1. AI 菸酒生在 LINE Taiwan の 後端雙刀流
2. Allen TECH FRESH @ LINE Education • Computer Science • Computer Science Experience • Software Engineer Intern • System Administrator • Tutorial Speaker @ NCHU @ NTOU @ LINE @ NCHU NLP LAB @ ROCLING 2024
3. 01 02 03 什麼是 Retriever? 跟 LLM 有什麼相關？ LLM 協助開發 Mind the Gap – Black-Box AI vs. Industrial Needs 我在 LINE 做了什麼？ AI 落地產業應用的困難 我在研究什麼？ CONTENT
4. SECTION 01 什麼是 Retriever? 跟 LLM 有什麼相關？ 我在研究什麼？
5. LLM 神奇的萬事通
6. LLM 神奇的萬事通
7. 秘月期 POPOO 與 Andy老師 RAG 知識過時 / 專業落差 誰是家寧跟Andy? 眾量級，一對關係很 好的YT情侶… Using RAG 誰是家寧跟Andy? … 分手後，雙方爆發多 起爭議，包括感情不 忠、財務糾紛和頻道 經營權問題。 ….
8. RAG (Retrieval Augmented Generation)
9. RAG (Retrieval Augmented Generation)
10. RAG (Retrieval Augmented Generation) Retriever
11. RAG (Retrieval Augmented Generation) Retriever
12. SECTION 02 LLM 協助開發 我在 LINE 做了什麼？
13. 接到一張票的我 be like 如何使用 AI 加速我的開發流程 Coding Study Planning Writing Test
14. 接票只是冰山一角 開發流程 Plan • 與 PM 開會確 認需求 • PBR 估點 • Planning 接票 • Daily Standup Meeting
15. 接票只是冰山一角 開發流程 Plan Code • 與 PM 開會確 認需求 • PBR 估點 • Planning 接票 • Daily Standup Meeting • 撰寫可維護高 品質程式、測 試程式
16. 接票只是冰山一角 開發流程 Plan Code Build • 與 PM 開會確 認需求 • PBR 估點 • Planning 接票 • Daily Standup Meeting • 撰寫可維護高 品質程式、測 試程式 • Formatting • 相依性檢查
17. 接票只是冰山一角 開發流程 Test Plan Code Build • 與 PM 開會確 認需求 • PBR 估點 • Planning 接票 • Daily Standup Meeting • 撰寫可維護高 品質程式、測 試程式 • Formatting • 相依性檢查 • 執行測試 • 程式碼覆蓋率
18. 接票只是冰山一角 開發流程 Test Plan Code Build Deploy • 與 PM 開會確 認需求 • PBR 估點 • Planning 接票 • Daily Standup Meeting • 撰寫可維護高 品質程式、測 試程式 • Formatting • 相依性檢查 • 執行測試 • 程式碼覆蓋率 • 管理Secret • 管理資源
19. 接票只是冰山一角 開發流程 Test Plan Code Build Deploy Monitor • 與 PM 開會確 認需求 • PBR 估點 • Planning 接票 • Daily Standup Meeting • 撰寫可維護高 品質程式、測 試程式 • Formatting • 相依性檢查 • 執行測試 • 程式碼覆蓋率 • 管理Secret • 管理資源 • 檢查系統健康 狀況 • Logging Track
20. 撰寫 BDD 測試 – Chain of Thought 你是一位熟悉 BDD 測試框架的程式開發者。請依照以下 步驟完成需求： a. 先閱讀我提供的「程式碼」與「既有測試說明」。 b. 找出程式中的流程控制（if、else、for…）會產生的所 有路徑，並以條列方式說明每條路徑需要覆蓋的測試案例 （case1、case2、case3…）。 c. 說明你選擇的 BDD 測試框架中，對應到哪些 describe / context / it 區塊。 d. 確認邏輯與覆蓋率無遺漏。 以下是輸入資料： ——— 程式碼 ——— {Code} ——— 既有測試程式碼 ——— {Test_Code} 以下我將為您生成一個範例程式碼與對應的測試說明，並依照 您的指示進行分析。 function processOrder(order) { if (!order) { return 'No order provided'; } … 請付費解鎖 付費 QR Code
21. 撰寫 Loki Query – Chain of Thought 你是一個 Loki 查詢語法專家。請根據用戶的自然語言描 述，分以下步驟思考並產生對應的 Loki 查詢語法： 1. 分析需求，明確查詢條件（如時間範圍、日誌來源、關 鍵字等）。 2. 提取關鍵元素（job 名稱、關鍵字、欄位等）。 3. 組合並輸出正確的 Loki 查詢語法（只需語法本身，其 他解釋不用）。 輸出時請只用程式碼區塊格式呈現 Loki 查詢語法。 User Query：「查找過去1小時內，job名稱為nginx且包 含error字樣的日誌。」 思考步驟： 1. 需求是查找過去1小時的日誌。 2. 日誌來源 job="nginx"。 3. 包含關鍵字 error。 4. 時間範圍為過去1小時。 生成的 Loki 查詢語法： `{job="nginx"} |= "error”` 以下我將為您生成一個範例程式碼與對應的測試說明，並依照 您的指示進行分析。 function processOrder(order) { if (!order) { return 'No order provided'; } … 請付費解鎖 付費 QR Code
22. SECTION 03 Mind the Gap – Black-Box LLM vs. Industrial Needs LLM 落地產業應用的困難
23. 01 透過“好的” Retriever 給模 型看答案 RAG 02 給模型武器 MCP 03 讓模型擁有武器的同時，拆解 任務，大家一起合作 Agent
24. RAG – 依賴 Retriever 強度 如果找不到你要的，甚至找錯，會導致結果完全不一樣 幫我找一張白雲的照 片
25. RAG – 依賴 Retriever 強度 如果找不到你要的，甚至找錯，會導致結果完全不一樣 幫我找一張白雲的照 片 搜尋中 …
26. RAG – 依賴 Retriever 強度 如果找不到你要的，甚至找錯，會導致結果完全不一樣 幫我找一張白雲的照 片 搜尋中 …
27. RAG – 依賴 Retriever 強度 如果找不到你要的，甚至找錯，會導致結果完全不一樣 幫我找一張白雲的照 片 搜尋中 …
28. RAG – 依賴 Retriever 強度 如果找不到你要的，甚至找錯，會導致結果完全不一樣 幫我找一張白雲的照 片 搜尋中 …
29. Retriever 發展 2019~2022 ICT REALM DPR ColBERT 2000~ 2014 2018 Transformer BERT Word2Vector Glove FastText BM25 TF-IDF Inverted Index 2023 HyDE 2024 LLM Embedding Transformer 前 Transformer 後 越強，也越需要龐大資源(GPU)
30. Retriever 發展 2019~2022 ICT REALM DPR ColBERT 2000~ 2014 2018 Transformer BERT Word2Vector Glove FastText BM25 TF-IDF Inverted Index 2023 HyDE 2024 LLM Embedding Transformer 前 Transformer 後 越強，也越需要龐大資源(GPU) LLM 等級 超高資源
31. RAG 資源需求
32. Resource Is All You Need
34. LLM 問題？ 幻覺，幻覺，還是幻覺 套上 RAG 後，還是會有錯誤以及幻覺 可怕的不是他不會，而是他自以為會
35. Agent
36. 安全權限 • Prompt Injection 可以攻擊 server 無限迴圈 可觀測性 • CoT, 中間狀態非 持久化 • Trace 太長 行為不可預測 • 模型升版、Prompt 改 動、工具回傳格式變動 • 今天能跑、明天失靈 Agent 問題 • Agent 瘋狂自我反 思，停不下來
37. Black Box is Magic
38. Black Box is Magic
39. Final 面對 Black Box LLM 持續進化 產業究竟要繼續堆疊愈發複雜的工程 pipeline，還是回歸更小、更專精且可 解釋的模型設計？ 大家可以一起來思考