2019 年下半年，我們成立了資料工程團隊，開始專注於人工智慧技術在旅宿業中的應用。我自 2016 年加入旅宿產業後，籌組了公司的資訊研發團隊，並先後投入 PMS 系統（Property Management System）及無人化智慧旅店的開發。然而，隨著市場需求的變化和公司發展方向的調整，我們逐漸意識到，僅僅依靠傳統的旅宿管理系統已不足以維持競爭力。公司開始將重點轉向「以數據營運」與「自動出價功能」這兩個核心目標。
這兩項需求對於公司而言是關鍵。旅宿業經常面臨人力短缺和高流動率的問題，這使得依賴人工處理的定價策略和數據解讀變得困難。此外，市場波動加劇，如何在短時間內做出準確的營運決策成為我們急需解決的問題。因此，我在產品規劃的方向逐漸聚焦於如何透過人工智慧技術建立一個可以自動累積知識、提供營運數據和策略參考的系統，讓人力資源能夠集中在更具價值的項目上。
◎技術探索與前期研究
在正式進行系統設計前，我們進行了一系列的小型技術研究，來驗證技術的可行性。我們首先分析了過去三年內的營運數據，包括旅店的銷售數據及其產品的銷售表現。通過機器學習技術，我們建立了多個預測模型，像是「旅客預訂時間」（Lead Time）的預測模型，這類技術能幫助我們更準確地預測未來的需求，從而優化定價策略，這些預測能力在旅宿業和其他行業中都極具價值。
此外，我們開始研究資料探勘技術，並構建了自動化爬蟲系統，從政府開放數據中提取市場相關的營運資訊。我們進一步利用分群技術，對數據進行彙整並自動分類。這些初期研究不僅為後續系統的開發奠定了技術基礎，還推動了我們其他相關產品的開發，如「問題通報系統」和「AI 智慧客服系統」。
◎系統規劃與功能設計
在思考如何產品化這些技術時，我首先通過魚骨圖分析，系統性地梳理了旅宿業及中小型企業普遍面臨的問題。這些問題包括銷售數據不足、對銷售渠道的掌控力薄弱、價格無法隨市場波動即時調整、缺乏合適的管理工具、以及人力與專業資源不足等。
我們的系統功能設計以這些困境為出發點，反向構建了解決方案。例如，我們利用數據分析和機器學習技術來為公司提供完整的銷售管道監控、競爭對手的市場動態分析、以及即時定價的策略建議。這一系列功能構成了營運策略輔助系統的框架，使得企業經營者能夠根據精準的數據做出即時決策，從而提升市場應變能力。
◎研發補助與疫情挑戰
在這一產品規劃的初期階段，新冠疫情正開始對全球旅遊業帶來衝擊。面對國內旅宿業的經營困難，我們主動申請了政府的研發補助計劃。2020 年，我們成功通過了經濟部「研發固本」的產業創新補助案，並在 2021 年獲得A+企業創新研發淬鍊計畫的「前瞻技術研發」資助。這些補助不僅幫助我們在疫情期間維持了公司的研發進度，還促使我們在 2024 年完成了該產品的正式開發，目前正推廣給其他旅店使用。
政府的資金支持讓我們能夠繼續推進人工智慧和數據分析的創新技術，並保持我們在市場中的競爭力。
在上一篇文章中，我分享了「AI 智慧客服系統」的產品開發經驗，並提到透過 LLM 技術來優化客戶問答系統的可能性。在這個過程中，我進一步發現，LLM 不僅能應用於客服對話，還可以在專業數據的解讀和分析上發揮重要作用，這啟發了我另外的想法，透過 LLM 來產生專業報表分析工具的思路。
◎商業智慧與 AI 的結合
商業智慧（Business Intelligence，BI）一直是企業決策的重要工具，透過數據探勘、分析及視覺化，企業得以掌握營運狀況。然而，隨著 AI 技術的快速發展，BI 系統迎來了新一輪的升級。特別是在大數據分析、時序數據處理和市場預測中，AI 能夠提高數據的準確性和預測的精度，讓企業能夠更迅速地應對市場變化，進而提升競爭力。
不過，除了數據分析與預測，BI 最大的挑戰在於如何從數據中提取有價值的「洞見」。這往往是數據分析師或資料科學家通過專業知識進行的工作，然而許多中小型企業並不具備這些專業資源與人力，甚至購買了 BI 工具或服務後，也面臨數據解讀的瓶頸。
以我之前服務的旅宿業為例，大多數經營者依賴「經驗」進行決策，對於收益管理的相關理論可能只是一知半解。雖然統計分析數據可以提供一些指引，但數據背後的策略可行性卻常常難以解讀。這正是多數產業都面臨的一大難題。
◎LLM 在數據解讀中的應用
LLM 技術為這個困境提供了一個突破口。在 LLM 技術中，提示詞（Prompt）是關鍵。提示詞的設計影響 LLM 如何解讀輸入數據並生成有意義的回應。然而，LLM 也會出現「幻覺」（Hallucinations），即當 LLM 缺少對應資料時，它會生成不準確的答案（畢竟它就是一個文字接龍）。這常常讓初次使用者感到失望。
透過精心設計與不斷修正的提示詞，我嘗試將 LLM 應用於數據解讀中，並取得了一定的成果。雖然 LLM 對於處理過於複雜的數據存在挑戰，但通過分層彙整數據、簡化數字資訊後，再引導 LLM，能夠生成具有參考價值的策略建議。
前置研究裡我進行了超過兩百次的數據分析實驗，並不斷調整提示詞來觀察 LLM 的反應。當確認 LLM 能夠提供具有參考價值的數據解讀後，我們的團隊開始開發一個專業報表分析系統，通過預先設置的提示詞餵給 LLM 並保留其輸出結果，再進行人工審查，確保數據解讀的準確性。
圖片中所顯示的是我以 GPT 模擬顯示的範例，不論是提供圖片，或是直接將要分析的數值透過 API 傳到 LLM，都可以藉由設計好的 Prompt 產出數據分析與策略建議。而我採用的這個範例，是某個收益管理書籍提到的旅店營運數值分析的長條圖，這四個圖形各自解讀有各自代表的意義，但綜合進行分析又能得出表面看不到的觀點。從 GPT 的輸出可以看出 LLM 能夠給予一些分析跟策略的參考。
◎專業報表分析工具的運作原理
如上所述這個專業報表分析工具基於 LLM 的運算能力，能夠透過 API 直接傳送數據進行分析，或是藉由視覺化圖表進行數據展示。例如，在收益管理的長條圖數據分析中，單獨看每個圖形代表的意義雖然清晰，但 LLM 可以在綜合分析後提供更深層的洞察，揭示數據背後的潛在趨勢與策略建議。
為了確保數據的準確性，我採用了一些技巧：
1. 數據簡化：對於大量數據，LLM 容易出現幻覺，因此我們將數據簡化，例如給出平均值或關鍵指標，避免過於複雜的計算。
2. 名詞處理：某些行業專有名詞容易讓 LLM 混淆，因此我們使用代碼取代具體名詞，減少誤解，並在輸出時再進行還原。
3. 分層處理：對於過於複雜的分析，我們將數據分層處理，再逐步餵給 LLM，讓其按層次進行分析後再彙整。
4. Prompt 設計：提示詞的設計需要經過多次測試，確保 LLM 對每個輸入能給出具體且有用的回應。為了避免 LLM 生成不必要的內容（如冗長的前言或結語），我們會在提示詞中設置限制條件。
5. 結果濃縮：有時分析生成的內容過於冗長，我們會進行二次處理，讓 LLM 濃縮輸出，提供更具體的策略建議。
◎LLM 應用的挑戰與建議
開發這樣的 LLM 專業報表分析工具也面臨一些挑戰：
1. 延遲問題：由於 LLM 需要時間處理大量數據，因此我認為盡量避免即時數據的分析，轉而使用固定圖表數據進行解析（例如日報表、週報表、月報表於離峰時段生成解析），這樣不僅能減少運算延遲，也能控制成本。
2. 專業領域的提示詞設計：在特定領域的應用中，我們會在提示詞中預設一些專業背景設定，讓 LLM 更貼合具體領域的需求。
3. 風險提示：使用 LLM 給出的策略建議時，必須讓用戶了解其風險，畢竟每次的輸出都是獨立生成的，存在一定的不確定性。
◎結語
透過這些技術與策略，我們團隊成功將 LLM 應用於專業報表的數據解讀，並將其開發為市場上較少見的應用功能。這項技術的潛力遠不止於此，隨著 LLM 的進一步發展，我很期待它能為更多企業帶來決策上的便利。
下一篇我將開始介紹我如何利用 AI 技術來開發營運策略的輔助系統，這是一個規模更大、技術應用更為複雜的產品，敬請期待。
在前篇文章中，我提到從內部問題通報系統的開發經驗，延伸至對外部客戶服務的 AI 智慧客服系統。
不論是線上客服還是語音客服系統，傳統的客服系統多依賴樹狀的問答結構來解決問題。我在 2007 年時，曾經基於 MSN 即時通訊開發過一款問答機器人，當時的技術核心就是通過樹狀結構分類問題，串接了 Wakema 這個 B2C 的平台，並回傳相應的答案。而語音客服系統如銀行業的應用，也是依靠類似的模式來提供預錄解答或導引客戶至合適的服務人員。
然而，隨著人工智慧技術的快速發展，特別是近年來大型語言模型（LLM）的突破，客服系統有了質的飛躍。這並不是完全顛覆原有結構，而是通過 LLM 的技術來優化前端的輸入與後端的輸出，使得系統能夠處理更複雜的對話，並提供更靈活的解決方案。
◎知識庫在客服系統中的應用
知識庫的建立是智慧客服系統的關鍵。回顧早期搜尋引擎的發展，例如 Google 的 Pagerank 演算法，它是通過知識庫的概念來提升搜尋結果的準確性。早期搜尋BMW關鍵字排名第一的是區域型的經銷商，而搜尋NIKE出現的是盜版商的電子購物網站。因此搜尋引擎透過這些知識庫，包含了對網站的人工審查與分類，讓搜尋結果更加精確。
我在 2007 年時也負責過 B2B Search Engine 的開發，當時的困境是如何定義製造商，而非混入零售商跟貿易商。當時我們也建立了知識庫，進行的方法是利用十年 B2B 平台的搜尋紀錄，取排名前十萬筆的關鍵字，進行適當清理後，帶入其他搜尋引擎的查詢結果，取這些結果前三十筆有效資訊，可以說知識庫的建立就是 Dirty Work。這也表示這種辛苦的髒活通常不太有人想負責。與搜尋引擎相同，智慧客服系統也需要一個可靠的知識庫，來解答使用者的各類問題。
題外話科普一下，當年除了 Yahoo 或是 Business.com 這類目錄網站外，還有 DMOZ 這個由人工維護的開放目錄網站，我也是編輯者之一，但這個服務在 2017 年停止了。
以旅館業為例，每家旅館都會面臨類似的基本問題，如入住時間、退房時間和停車位等，但每家旅館的周邊景點與交通資訊卻有所不同。因此，建立一個涵蓋所有這些資訊的知識庫，並能夠自動更新和擴展，是關鍵的項目。可以說要有人工智慧之前，必定先有工人智慧在前。
在這方面，LLM 技術提供了很大的幫助。我們可以利用 LLM 生成更多的問題與答案，進而形成豐富的知識庫。而這些知識庫的內容不僅限於文字回應，也可以包含語音回覆，解決多種形式的使用者查詢。2024 年 10 月，Open AI 推出的 Realtime API 更進一步解決了語音延遲的問題，使得語音交互更加即時自然。
◎知識庫的整合與應用
除了常見的問題與答案知識庫，有時智慧客服系統還需要與企業原有的平台服務進行深度整合。例如，Open AI 的 Plugin 讓 OTA 平台可以提供房間預訂服務，但其查詢僅限於單一時間段（意思是無法進行複雜項目的查詢），當查詢時間無法滿足需求時，使用者需要手動尋找替代選項。真正能稱為人工智慧的系統應該能自動給出替代方案，如推薦相近時間的可用房間，或是推薦相似的旅館。
這樣的整合性知識庫並不僅僅是靜態的問答集合，而是與企業平台透過 API 互串的的智慧查詢系統。它不僅能回答簡單的問題，還能將問題轉化為具體的查詢指令，並能夠進行連貫的多層次查詢。以旅宿業為例，整合了線上訂房系統的智慧客服可以自動處理訂房、修改、取消等操作，並為使用者提供延伸的選擇，如推薦其他日期或相似的房型。
◎專家知識庫與 LLM 的限制
除了基本的問答型知識庫，企業還可以建立專家知識庫，涵蓋內部技術文件與專業領域知識。這類知識庫相對固定，能有效避免 LLM 產生不正確的回應（幻覺現象）。雖然自建 LLM 可以提供更專屬的解決方案，但對中小型企業來說，訓練與維護的成本過高。因此，限制通用 LLM 的回應範圍，讓其根據企業內部知識庫進行回答，是更為實際的做法。
這種模式可以想像為將 PDF 文件餵給 LLM（例如 GPT），然後在固定範圍內進行查詢，避免無關內容的生成。例如，當使用者查詢某技術文件時，系統可以直接從已知的知識庫中提取正確資訊，而不會生成臆想的回應。而查詢不到近似的內容時，則直接輸出沒有對應的解答。像 Google Gemini 就用了許多限制，避免系統回答觸犯道德問題或產生其他風險。
◎開發過程中的挑戰
開發這類 AI 智慧客服系統並非有技術就能一帆風順，以下是幾個常見的挑戰：
多方協作問題：這類系統的開發需要多方人才，包括該領域的專家來建立知識庫、資料科學家、機器學習專家，以及前後端開發人員（甚至是APP開發者）。協作的難度不容小覷，特別是跨領域的溝通和協作。當然領導這些協作者的 PM，是一個非常困難的作業。
對知識庫建立的忽視：許多企業或開發者在建立智慧客服系統時，過於依賴 LLM 的即時生成能力，忽視了知識庫的建立與維護，這往往導致系統回答不夠精確或無法處理複雜查詢，多元的知識庫是實現跨系統串接很重要的一環。
系統延遲問題：多層過濾器與模型會導致回應時間的延遲，尤其是當系統需要與多個知識庫還有外部平台交互時，延遲問題會更加明顯。當我們希望系統可以更智慧的提供客戶服務，這也代表它的堆疊架構越多。
開發時間與成本：應用系統的開發與整合可能看似簡單，但知識庫的建立、模型的調教、以及情境測試會大幅增加開發時間與成本，這往往被低估。情境測試的規劃，應該在知識庫建立的同時，就先處理。
敏感資料的困境：企業內部的敏感資料如何處理是一大挑戰，尤其在面向內部使用時，通用的 LLM 雖然成本低，但可能無法保障企業的數據安全與營業秘密。
◎總結
AI 智慧客服系統的開發是多層次的挑戰，從知識庫的建立到多模態的模型運行，都需要謹慎的規劃與管理。我們在內部已經成功開發了為開發人員服務的 AI 智慧客服系統，而這些相關的技術也同樣為我們帶來了新的產品創意，我將在後續分享。
自 2019 年起，我推動 AI 技術在旅宿產業內的應用，成功實現了四大類產品，並且有效提升了企業的自動化流程及營運效率。這篇文章將簡單總結我的技術應用理念，並分享產品化的過程與挑戰。由於篇幅關係，將分篇說明。
我們企業的核心目標是利用自動化技術，提升商業流程的效率，尤其在少子化的趨勢下，技術的應用能大幅減少重複性工作，讓員工專注於更具價值的任務。同時，我們面臨人力異動頻繁的挑戰，因此降低教育訓練成本、累積知識並轉化為企業內部知識庫，也成為我在產品規劃中的主要思維。
基於這些目標，我們開發了四大技術應用產品，分別是問題通報系統、AI 客服系統、AI 營運策略輔助系統（結合自動出價功能）、以及專業報表分析工具。在這些產品中，我們使用了多種技術來進行數據處理和預測模型的優化，例如 CatBoostRegressor、LSTM、隨機森林以及 ARIMA。
◎問題通報系統
首先介紹問題通報系統的技術應用與產品化過程。我們自營的五十多家旅店都使用自研的 PMS 系統來管理營運，這是一套基於雲端架構的系統，串接了各種外部與內部服務，如金流、發票、簡訊、Line Notify （附帶一提，免費的 Line Notify 服務將於2025年3月底關閉）、Channel Manager......等。然而，由於操作流程複雜且人員更替頻繁，員工在遇到系統不熟悉或技術問題時，經常需要即時通報技術部門或其他後勤單位來解決問題。這是典型的維運挑戰之一。
傳統的問題通報流程通常採用工作聯繫單的模式，無論是紙本還是電子化，流程都需要經過多個關卡，這不僅拖延了解決問題的時間，也導致處理人員需要隨時待命。這種問題通報造成不少困擾，雖然會有輪值機制來因應，但等待機制會導致輪值人員無法適當休息，造成開發人員的損耗（離職），為了改善這些問題，我們開發了一個 AI 支持的問題通報系統，利用自動化技術來即時分類和分派問題，降低人力負擔。
我們的系統設計讓使用者可以透過 Line 平台提交問題，系統會使用 AI 模型來進行問題分類，並將問題自動分派給相關單位處理。為了建立這樣的分類模型，我們先累積了一定的歷史通報數據，並使用分群技術對這些問題進行整理和分類。透過這樣的過程，我們建立了第一版的知識庫，並利用大規模語言模型（LLM）生成更多的問題與答案，進一步優化了分類準確度。
使用 LLM 技術來生成多樣化的問題與解答，可以有效應對不同使用者對於同一問題的不同描述，並且也能確保解決方案能以簡潔的方式呈現，提升了分類模型的訓練效果與準確度。
◎系統的優勢
這個問題通報系統的核心在於 24 小時不間斷運作，透過檢索增強生成（RAG）技術，系統能精準地調取過去的解決方案，並自動回覆相關問題。如果知識庫中有對應的解答，問題通報的人員可以依照系統指示自行解決問題，而無需等待技術支援，進一步減少了處理時間。
我們的系統不僅提升了問題處理的即時性與準確性，還為企業內部建立了一套完善的知識管理流程。這套系統在內部成功運行三年後，成為我們對外智慧客服產品的基礎，也大大提升了服務質量與效率。
待續......
本次課程接續「工作團隊與團隊協作」的內容，延伸到「夥伴關係與衝突管理」的處理方式，同樣由四海老師分享，帶給我們團隊很充實的內容，並且能應對目前我們正面臨的內部團隊溝通，以及與其他單位協作上的困難。
◎工作夥伴關係
課程一開始就提到夥伴與人際關係的差異點，許多工作者並不理解這兩者的不同，所以常會以單純的人際關係來看待工作夥伴關係。這兩者最大的差異在於人際關係我們可以選擇接近或遠離，而工作夥伴關係我們只能選擇經營或逃避。
所有的關係都需要「經營」，而「經營」其實是一種投資，投資就會有「賺」有「賠」。後面的投資與賺賠是我自己的延伸。我認為不只是工作夥伴需要經營，平常的人際關係以及家人間的關係也都要經營。至於如何讓工作夥伴或人際關係經營得好，重點在於「互助」與「互惠」。如何主動而適當地伸出援手或橄欖枝，就是其中的關鍵。我們單位內部常提醒同事，如果意識到某件事應該有人做，但沒人出面，那你就去執行吧！不用觀望、不要等待，去做了再說。有了回饋後，再回過頭來檢討與修正。
要建立關係要先從角色扮演開始。我們需要先願意扮演幫助他人、鼓勵他人的角色，不論是否能夠或願意，都要讓自己融入這樣的角色中。久而久之，戲假情真，原本可能不那麼真誠的互動，最後也會是真誠的互動模式。具體實施方式從尊重、讚美、認同這三件事開始，這包括微笑、鼓勵、肯定、助人、分享知識與經驗、支援、請教、歸屬感等方式，這些都是在建立互信與交情。一開始做不到的話，可以讓自己角色扮演，做久了就會成為真實的行為。
老師提到工作者應該主要幫助我們的主管，我認同這個說法，但認為應該更廣義地看待這件事。幫助同事、讓團隊的價值真正展開，也是幫助主管的一種方式。與其處理主管單一的任務，更高的價值是讓團隊解決公司的問題，帶給公司更大的利益，這是我一直以來的堅持與看法。當然也因為這樣，我不是一個逢迎拍馬的人，可能不一定能彰顯出個人的價值。
:: 下一頁 >>
