Day 2・R1 產業應用
四位講者分享 LLM 產業應用全貌、音樂串流資料治理、零售推薦與 agent 佈局，以及企業 30 年 AI 落地經驗。
本場速覽
| 講者 | 講題 | 一句話重點 |
|---|---|---|
| 陳敦和（資拓宏宇 產品顧問） | Taxonomy of LLM Development and Applications in Industries | 用 open source／proprietary 兩條路梳理 LLM 生態全貌，並分享護理交班、Excel／SQL／Cypher 自然語言查詢等企業案例 |
| 官順暉（科科科技 KKTech） | Orchestrating the Future: AI Innovations in Music Streaming | 以 KKBOX 音樂資料為例，講資料品質治理、LLM 歌單 DJ、以及用聲音 embedding 直接做「聽歌辨曲」的實驗 |
| 李昆謀（91APP CPO） | Retail AI: from recommendation to agent | 從傳統機器學習分群、OpenAI embedding 模糊搜尋，講到人／商品／標籤三塔模型與零售 agent 生態的未來想像 |
| 林縣城（叡揚資訊 創新研究中心 CTO） | Enterprise AI Application Practices – Expect the Unexpected! | 回顧公司從專家系統到 LLM 的 30 年 AI 投入，展示對話機器人、商標以圖找圖、財報三表辨識、公文寫作等落地產品 |
顯示 4 / 4 場
1LLM 發展全貌與產業應用分類陳敦和（資拓宏宇 產品顧問；曾任職台灣人工智慧學校）
用 open source／proprietary 兩條主線梳理 LLM 技術全貌，並分享多個企業落地案例。
重點整理
- 開場先自我介紹：目前在資拓宏宇擔任產品顧問，之前曾在台灣人工智慧學校服務，協助業界教學與導入；更早前待過手機產業。
- 把 LLM 開發流程分成 pre-train → fine-tune → RLHF 三階段：fine-tune 又分 full fine-tune、continue pre-train（CPT，介於 full fine-tune 與 pre-train 之間，用於「TAIDE」模型）、以及 partial fine-tune（如 adapter、LoRA）。
- 提到 knowledge distillation：用其他模型（如 ChatGPT）產生問答資料回頭訓練自己的 base model，並指出 OpenAI 曾聲明此做法違反其使用條款；Alpaca、Vicuna 屬於這類基於 LLaMA 的學術研究。
- 將 proprietary 模型應用分成四大塊：Communication（prompt engineering，比喻成「與知識體溝通」）、Enhancement（多模態輸入如圖片/影片、Plugin 補足模型能力如數學、RAG 補足知識）、Interoperability（API 對外/對內）、Customization（如 ChatGPT 的 GPTs）。
- 分享「護理小幫手」產品：用 LLM 做病患健康問題分類，結合 RAG 撈護理資料，自動產生交班記錄，大幅節省護士時間。
- 展示「工具操作」概念：用自然語言操作 Excel（生成公式做客戶案例分析）、關聯式資料庫（自然語言轉 SQL 查詢碳盤查報告）、圖形資料庫 NEO4J（自然語言轉 Cypher 語法建立人物關係圖譜）。
- 提出「化學分子、程式碼、機器人控制、時序數值都可以被視為一種語言」的觀點：以 SMILES（Simplified Molecular Input Line Entry System）表示化學分子為例，說明 SenseTime 早在 ChatGPT 出現前就用類似的語言模型概念做藥物分子生成；同樣邏輯延伸到用 LLM 做工廠時序數值的「預測式生成式 AI」。
- 分享外送滿意度評估案例：把餐點溫度、包裝、服務態度等結構化評分與開放式文字意見都當成「語言」輸入，訓練模型生成客服回覆文字。
- 公司簡介：資拓宏宇為台灣大型資通訊公司，長期協助政府建構交通、金融、醫療等系統，並有整合式的深層式 AI 產品方案（對話機器人、知識管理、內容生成/摘要/轉換模組）。
提到的技術・產品・數據
- LLaMA、Mixtral
- 開源基礎模型（base model / foundation model）
- LoRA（Low-Rank Adaptation）
- 輕量化 fine-tune 技術，只調整外加的少量參數。原始論文：Hu et al., 2021,〈LoRA: Low-Rank Adaptation of Large Language Models〉（arXiv:2106.09685）；官方實作：microsoft/LoRA（GitHub）。
- Chain of Thought（CoT）
- 提示技巧，講者類比為「跟人溝通時的一步步說明」
- RLHF（Reinforcement Learning from Human Feedback）
- 讓模型輸出更符合人類價值判斷
- Alpaca、Vicuna
- 基於 LLaMA、透過知識蒸餾自 ChatGPT 訓練的學術模型。Alpaca 官方頁面：Stanford CRFM Alpaca 部落格、stanford_alpaca（GitHub）；Vicuna 官方頁面：LMSYS Org Vicuna 部落格。
- NEO4J + Cypher
- 圖形資料庫與其查詢語法，示範用自然語言生成 Cypher 建立人物關係圖。官方文件：Neo4j Cypher Manual。
- SMILES
- 化學分子的簡化文字表示法，SenseTime 用於藥物分子生成研究。技術背景：Simplified Molecular Input Line Entry System（Wikipedia）；原始論文：Weininger, 1988,〈SMILES, a chemical language and information system〉。
值得記下的觀點
「大型語言模型它是一個知識體，雖然它是沒有生命，但是它其實就是跟一般人一樣，你怎麼去跟它去做溝通。」
Q&A
- 無 Q&A 環節（主持人直接銜接下一位講者）。
查證註記
- 講者所屬公司「資拓宏宇」為台灣本土資通訊服務業者，股票代號 6614。來源：iisigroup.com資拓宏宇 Facebook
- 講者曾任職台灣人工智慧學校一事，與公開資料中「陳敦和／AIA 技術處副處長」的紀錄方向一致，但無法進一步查證其在資拓宏宇「產品顧問」職稱的公開來源（未能查證）。來源：台灣人工智慧學校 2020 meetup 頁面
2音樂串流中的 AI 創新官順暉（科科科技 KKTech；主持人介紹為「執行副總」，官方議程列為 Chief Scientist，見查證註記）
以 KKBOX 音樂資料為例，強調「先治理資料品質、再談 AI」，並展示純聲音 embedding 的音樂搜尋實驗。
重點整理
- 主持人介紹講者專長為串流技術、推薦系統與計算機圖學，是科科科技技術開發的重要奠基者；講者自嘲「今天大概是唯一一場跟音樂比較有關的分享」。
- 開場數據：十年前 KKBOX 一天上架約 800 首歌（一年約 30 萬首），去年（2023）已成長到一天約 25 萬首（一年約近 1 億首），凸顯規模已遠超過個人一輩子能聽到的歌曲數量。
- 把「一首歌的資料」拆成五類：音樂本身（波形）、歌詞（音樂的文字延伸）、Metadata（歌名、作者、演唱者、曲風、發行公司等）、商業/版權資料、User Behavior Data。
- 案例一（Metadata 品質）：以電玩配樂《對馬戰鬼》原聲帶為例，指出因 Metadata 錯誤導致同一位作曲家的其他作品在 KKBOX 搜尋不到；進一步分析發現曲風（Genre）分類混亂 —— 抽樣顯示「Pop」與變體（如 Mandarin Pop）過度集中、同一動漫類型被拆成多個不同 genre 標籤、巴西鄉村樂（Sertanejo，講者稱為當年拉美語系的「City Pop」等級熱門曲風）在資料庫中有 12 種不同拼法。
- 指出 Metadata 問題來源包含 typo、重複、分布不平均、aliasing（別名同義詞）、離群值（如年代欄位出現西元前 190 年或西元 9999 年的歌曲）。
- 團隊先與其他平台做基準比較（如 KKBOX genre 標籤數三萬多 vs. Spotify 僅約六千），確認確實是自身資料異常而非「雞蛋裡挑骨頭」，再用 Multilingual BERT + HDBSCAN 做 genre 聚類，重新收斂曲風分類（並提及 Spotify、ISMIR 學術界也在解決同樣問題）。
- 案例二（互動/推薦）：把 LLM 當成「你自己的 DJ」，讓使用者用自然語言描述情境（如「心情很低落」「週六下午想要有人陪」）取得歌單；作法是把資料轉成 embedding 做相似度檢索（fuzzy search）＋內容過濾（避免攻擊性或不當內容）；但也強調當使用者意圖已經很明確（如「我要 90 年代搖滾樂」）時，直接用關鍵字搜尋（old technology）比硬套 LLM／embedding 更準確、也更便宜。
- 案例三（純聲音 embedding 搜尋，與兩位政大實習生 6 週完成的概念驗證）：完全不使用文字/Metadata，只用歌曲聲音本身（waveform → embedding，模型講者稱為「mast」，見查證註記）做「聽歌找相似歌」的 demo，包含：用五月天〈倔強〉某高能量片段找到多首五月天其他歌曲；用陳綺貞〈太聰明〉去除人聲後只留伴奏搜尋，仍能找到聽感相近的伴奏；用「AI 孫燕姿」翻唱周杰倫歌曲測試系統，系統誠實地找不到孫燕姿本人作品（因曲庫沒有孫燕姿原唱），反而是被系統之外的人誤以為像；用《Beautiful in White》做婚禮歌單延伸推薦。
提到的技術・產品・數據
- Multilingual BERT、HDBSCAN
- 用於 genre 標籤語意聚類，收斂重複/相似曲風分類
- librosa
- Python 音訊處理函式庫，用於 energy-based 片段擷取
- 「mast」模型
- 講者用於產生音訊 embedding 的模型名稱，未能查證其確切全名（可能為音樂音訊表徵模型，如 MERT／MusicFM 等同類技術，但無法確認）
- Cosine similarity
- 用於 embedding 向量空間中的相似度比對
值得記下的觀點
「如果你的 data 是一個 kind of not ok，so you can expect that everything is not ok at all。」
「AI 孫燕姿太爛了⋯⋯如果有人會被騙呢，那是人的問題，不是 machine 的問題。」
Q&A
- 無 Q&A 環節（主持人直接銜接下一位講者）。
查證註記
- 官方議程列出的講者頭銜為「科科科技 KKTech Chief Scientist」，但主持人介紹時稱為「科科科技的執行副總」。另外查得一位「官順暉（Drake）」的公開職稱是 KKCompany 子公司 KKStream 的「資深技術總監」（曾任 KKStream 技術長）。三個來源（官方議程、主持人介紹、外部報導）職稱彼此不一致，且無法確認三者是否指向同一人事時間點，故三種說法均照實併陳，未能判定何者為準（未能查證）。來源：官方議程頁 conf2024.aiacademy.tw/agendaKKStream 案例報導，AI Foundry Edge
- KKBOX 為科科科技（KKCompany）旗下音樂串流服務。來源：數位時代報導kkcompany.com
- 「mast」音訊 embedding 模型名稱維持「未能查證」標記：未能找到對應的公開模型文件或論文，不排除為其他模型名稱之簡稱（如 MERT、MusicFM 等同類技術僅為推測，非查證結果）。
- KKBOX 每日上架歌曲數（十年前約 800 首、去年約 25 萬首）、genre 標籤數量（KKBOX 三萬多 vs. Spotify 約六千）等內部數據，均為講者自述，無外部來源佐證。
3零售 AI：從推薦到 Agent李昆謀（91APP CPO）
從傳統機器學習分群走到 embedding 模糊搜尋，最終提出零售業「人／商品／標籤」三塔模型與多 agent 協作的未來圖像。
重點整理
- 主持人介紹講者為 91APP 產品長，講題聚焦零售業如何用 AI 解決「人找商品、商品找對的人」的根本配對問題。
- 回顧公司 5–6 年前（約 2018–2019）就已投入傳統 machine learning：用購買次數、瀏覽次數、分類標籤等 20–30 個特徵值做商品分群；並用點擊行為序列（clickstream pattern）分析使用者「瞎逛」「對特定商品有興趣」「湊免運」等意圖模式，做出稱為「DCIU」的購買意圖分群模型 —— 高購買意圖客群僅占約 1% 的會員，但行銷活動觸及後可貢獻整體活動業績約 50%。
- 生成式 AI 出現後，嘗試用 OpenAI 的 embedding 模型（ADA；講者口述維度數為「一千三百五十六」，OpenAI 官方文件確認為 1536 維，見下方技術欄位連結）做商品 embedding，用 cosine similarity 找相似商品，並曾在 ChatGPT Plugin Store（已下架，後續演化為 GPTs）上架一個電商推薦 plugin。
- 純粹用文字 embedding 模糊比對商品曾遇到問題：例如用戶指定「白色」商品，比對結果語意相近但顏色不符（因為零售業商品描述常用「珍珠白、雪亮白、霧面白、夢幻白」等行銷詞彙，傳統斷詞抓不到但 embedding 空間能讓這些詞語意聚合），後續作法改為先用關鍵字/標籤做過濾、再做 embedding 標籤擴展搜尋，準確率明顯提升。
- 展示 2023 年上架的 ChatGPT Plugin demo：輸入「中秋節送禮、不要傳統月餅、要有創意」，系統推薦掛耳咖啡包、鳳梨酥、造型如糕餅的手工皂等。
- 提出零售業真正的難題是「消費者往往不會講出自己要什麼」（買的是「想要」而非「需要」），因此需靠收集外部標籤與行為建立 persona，並發展出「雙塔模型」（Two-Tower Model，YouTube／Spotify／Netflix 推薦系統的共同架構）延伸為「人、商品、標籤」三個向量空間互相檢索（用人找商品、用商品找標籤、用標籤找人等六種組合）。
- 應用場景：千人千面推薦系統、商品自動貼標（同時參考 Google SEO 優化）、廣告受眾包（用人找標籤→找相似潛在受眾→再找可能商品作為動態素材）；並提到不同版位目標不同（首頁重 CTR、購物車頁重轉換率），需在向量檢索（retrieval）之後再做一層依目標排序的 re-rank（傳統 machine learning，非 GenAI）。
- 公司內部把整套向量檢索＋LLM 代言人的架構命名為「Joy」（因發音接近 91，為諧音命名），可組成客服問答、商品推薦等 agent。
- 對未來零售場景的想像：消費者端與銷售端都會出現 agent（如智慧音箱幫消費者下單），最終可能出現「agent 對 agent」的交易型態（類比為外人聽不懂內容的批發市場議價），零售業組織將走向 headless（服務 API 化）以因應各種 channel 與 agent 的接入。
提到的技術・產品・數據
- OpenAI Embedding 模型 ADA
- 講者口述維度數為 1356，OpenAI 官方文件確認為 1536 維。官方文件：OpenAI〈New and improved embedding model〉、OpenAI Vector embeddings guide、text-embedding-ada-002 模型頁。
- ChatGPT Plugin Store
- 2023 年短暫存在的第三方外掛商店，後續演化為 GPTs
- Two-Tower Model（雙塔模型）
- YouTube、Spotify、Netflix 等推薦系統常用架構，此處擴充為人／商品／標籤三塔。技術源頭一般追溯至 YouTube 推薦系統論文：Covington et al., 2016,〈Deep Neural Networks for YouTube Recommendations〉（ACM RecSys）；架構說明另見 Google Cloud Blog：Scaling deep retrieval with TensorFlow Two Towers。
- Retrieval + Re-rank（RR 架構）
- 先做向量檢索、再依業務目標（CTR／轉換率）重新排序
值得記下的觀點
「消費者買的其實不是需要，買的是想要。」
「你不能只是賣他的需要，你要賣他，他自己不知道的需要。」
Q&A
- 無 Q&A 環節（主持人直接銜接下一位講者）。
查證註記
- 官方議程與公開資料確認講者為「李昆謀」（英文名 Happy Lee），現任 91APP 產品長／CPO。來源：91APP 產品長專訪，關鍵評論網LinkedInhappylee.blog
- 講者口述 OpenAI ADA embedding 維度數為 1356 維，OpenAI 官方文件（見上方技術欄位連結）確認為 1536 維；內文依官方文件核對後註記，非另行捏造數字。
- DCIU 購買意圖模型「高意圖客群占比約 1%、貢獻活動業績約 50%」為講者自述的公司內部數據，無外部來源佐證。
4企業 AI 應用實務：Expect the Unexpected林縣城（叡揚資訊 創新研究中心 CTO）
回顧公司從專家系統到 LLM 的 30 年 AI 佈局，展示多項已落地的企業應用產品。
重點整理
- 開場致敬 Transformer 論文〈Attention is All You Need〉，並類比公司理念為「Application is All We Need」。
- 個人職涯回顧：1990 年進入職場第一份工作就是知識庫系統／推論引擎（專家系統時代），曾做中鋼鍋爐故障診斷、疾病診斷等專家系統，後因「知識取得與表示」的瓶頸經歷 AI 寒冬；之後歷經 Data Mining（推薦引擎，曾率隊赴美研發）、類神經網路／遺傳演算法、深度學習，直到近年生成式 AI。
- 表達企業導入 AI 的普遍心情是「既期待又怕受傷害」：期待新技術能做到過去做不到的事，又怕剛投入資源新技術就被取代（「打水漂」的焦慮）；主張沒有萬用技術，應依問題本身、資源與需求選擇合適方法。
- 公司過去十年投入四大技術領域：文本辨識（NLP）、Computer Vision（圖形辨識）、對話機器人、以及近一兩年的 LLM 應用；組織上採「中央廚房」式技術研發，再賦能到公文系統、知識管理、淨零碳排等各產品線。
- 企業導入 AI 分五階段：概念驗證（POC）→ 落地實作 → 流程優化 → 成為公司 DNA → 產生競爭力影響。
- 展示多項產品 Demo：
- 對話機器人平台：應用在醫院場景，以及業務人員 call report 語音/文字轉知識管理平台資產。
- 商標以圖找圖檢索系統：已在智慧財產局實際上線使用，具 feedback loop（人工標註相似與否）持續 retrain 提升準確率。
- 手寫三聯式表單／發票辨識：印刷體辨識率接近 100%，手寫中文辨識率較低但仍具實用性；高鐵票辨識近乎 100%。
- 財報三表（資產負債表、損益表等）自動辨識：用於中小企業貸款審核流程，準確率超過 90%，客戶回饋可節省 80% 以上人工輸入時間，並用紅字標示疑似異常數字（結合業務規則後處理，如小計加總校驗）。
- 知識管理平台導入 LLM：強調 RAG 場景中「檢索（Retrieval）」品質比「生成（Generation）」更關鍵（講者估計功能佔比約五分之四在前處理與檢索，而非生成本身），文件多模態（含圖表）的萃取品質直接影響後續檢索可用性。
- 公文系統：最早導入中文文法糾錯（Spelling/Grammar Check，技術歷經多代演進到 BERT），並強調通用模型（如直接丟給 ChatGPT）在企業特定術語、更高容錯要求下不一定夠用；目前系統可協助推薦公文範本、生成公文/會議通知草稿。
- 對未來趨勢的個人觀察（列點但受限時間未逐一展開）：open source vs. proprietary 之爭將持續存在、企業客製化模型不一定需要大模型、多模態文件將成關鍵應用、知識圖譜（公司 5 年前已投入）結合 LLM 產生更精準的複雜情境應用、agent 發展、MLOps/LLMOps 工程化需求、資料質與量仍是最大瓶頸、運算資源限制、AI 治理與評估標準（如何客觀證明自家模型優於他人）、模型架構持續演進（Transformer 目前最佳但未必是終點）。
提到的技術・產品・數據
- BERT
- 用於公文中文糾錯與 Entity 辨識（NER），講者指出非所有任務都需要動用 LLM
- RAG（Retrieval-Augmented Generation）
- 企業知識管理最主要應用模式，講者強調前端檢索/文件萃取品質是關鍵瓶頸
- 知識圖譜（Knowledge Graph）
- 公司 5 年前已投入，結合 LLM 做更複雜情境應用
- 財報三表辨識、商標圖像檢索、手寫三聯式表單 OCR、公文系統
- 皆為公司已落地的實際產品/客戶案例
值得記下的觀點
「我們既期待，又怕被傷害。期待有新的東西出來，讓我們過去沒有辦法做到的事情能夠做；但是怕傷害是說，我投入了，那過兩天他又一個新的東西出來，那我投入是不是要打水漂。」
「Attention is all you need，事實上來講，以叡揚或以這個產業來講，我們其實來講 Application is all we need。」
Q&A
- 無 Q&A 環節（講者結束後直接進入下一場）。
查證註記
- 講者所屬公司「叡揚資訊」股票代號 6752。來源：gss.com.tw公司簡介頁
- 查得林縣城現職為「叡揚資訊研發長／副總經理」，與官方議程所列「創新研究中心 CTO」職稱不完全一致，但同屬叡揚資訊技術研發資深主管方向，判斷應為同一人於不同時間點/不同資料來源的職稱差異。來源：叡揚大事紀
- 講者展示的商標以圖找圖檢索、財報三表辨識、公文系統等 demo 均為客戶案例／內部產品簡報畫面，經查叡揚官網僅公開列出 Vital 系列雲端服務（如 Vital CRM、Vital Finance、Vital BizForm、Vital Knowledge 等），未找到與講者展示畫面直接對應的公開產品頁面，故商標檢索、財報三表辨識、公文寫作三項 demo 的細節（辨識率、上線範圍等）均為講者自述，無外部來源佐證。來源：公司簡介頁