設計聊天機器人

 

自2017年起由AlphaGO興起的人工智慧浪潮，從最初的車牌、人臉辨識，到自動翻譯和對話機器人，各種改變大家行住坐臥的AI服務，已經深深融入到你我的日常生活情境中。其中對話機器人或稱為聊天機器人被許多公司行號用來執行每日的客服事務，或是當做基本的品牌行銷渠道。而設計、開發與維運聊天機器人，卻有著和傳統資訊系統截然不同的流程與思維，這便是這本設計聊天機器人的主題，帶讀者們以產品經理或簡稱PM的觀點，用全方位的角度，好好瞭解聊天機器人到底是什麼？

從市面主流的聊天機器人平台談起，再介紹主要的各種應用情境。先從策略面的角度切入聊天機器人能為企業帶來怎麼樣的創新。接著強調設計機器人時的個性塑造要符合企業、組織的品牌形象，並補充由技術面剖析聊天機器人的系統架構等資訊。談完大方向，內容就落實到實作面的各種技術議題。最核心的當然是達成自然語言理解的人工智慧、其次是對話資訊流與多元互動使用者介面，這些都和一般網頁與應用程式開發有所不同。書中最後幾章手把手帶著讀者，從無到有地規劃、設計一個聊天機器人產品。其中撰寫對話腳本和系統測試相信對絕大多數的開發者來說，都是充滿新奇的一種體驗。

相信絕大多數的消費者對於時下所謂的智能對話機器人並沒有正向的體驗。書中預測的對話經濟風潮，對照的卻是各家大廠陸續退出智能語言服務市場，像是狠狠地打了作者一巴掌。追究原因或許有三，一是由機器學習的監督式分類模型，要處理複雜、充滿例外的自然語言理解課題，仍是力有未逮。二是對話機器人系統的維運，必須不斷地投入心力爬梳對話記錄，用以調校、優化腳本和模型，以維持智能服務的高品質，但大多數的企業、組織仍習慣以建好就結案的思維來建置資訊系統，讓八成以上的智能對話服務變成了雷聲大雨點小。最後，許多應用情境一開始都是出於過度樂觀的猜想，實際問世後不被消費者買單。像是購買流程，對照網頁操作的直觀、迅速，有多少比例的消費者願意花時間和機器人對話，只為了購買一個簡單的商品？

大型語言模型或簡稱LLM的出現，肯定會對聊天機器人相關產業產生天翻地覆的震撼。畢竟藉由生成式AI的協助下，就連非資通本科生也能輕鬆打造出能打敗專營打造對話機器人服務的科技公司。在技術力不再是發展門檻的大環境下，對話式應用能否實際開創出有如APP市場的另一片天？讓家家戶戶都能使用像電影鋼鐵人裡的智能服務賈維斯，或許是指日可待的未來。

大數據架構和算法實現之路：電商系統的技術實戰

 

工作上是管理大數據平台和建置其上的個人化推薦系統，目前在系統設計、開發和維運算是得心應手。不過資訊技術進展一日千里，為此我總會買些大數據、推薦系統的專書來溫故知新。翻閱過數本推薦系統的好書後，和本書作者黃申在序中出提的想法一樣，這些專論推薦系統的書目分別處於理論和技術的兩個極端。不是純粹介紹理論、演算法、數學公式和學術進程，像是一本大學院校的教科書，另一種是過於微觀地介紹單一技術工具、框架，從安裝設定到開發、操作步驟，像是常見的Hadoop實戰、Spark入門等。

「大數據架構和算法實現之路」的作者以全然不同的角度切入「推薦系統」這主題，用電商營運中的大數據資訊處理需求當主軸貫穿全書，在各子章節中詳述設計思維、系統架構，並提供可實際運作的完整程式碼，讓讀者「知其然，又知其所以然」。隨著章節進行，範例程式逐步演進變成強大的運算模組，完成度極高的程式碼，徹底揭開大數據技術如何落地實作的神秘面紗。

這一兩年有關心IT產業動向的人，應該能感受到先前刮起的機器學習/人工智慧風潮開始消褪。我認為原因有二，一是資本市場和資訊同業的大舉投入，讓AI技術以十倍速成長而達到高原期，相關工具、框架汗牛充棟、舉手可得。同時AWS、GCP等IT領頭羊也極積推廣AI雲端服務，這些因素造成AI技術平價化，喪失成為公司營運上做為技術壁壘的優勢。其次，在僅扮演AI供應商的角色，無法獲取高利潤的情況下(AI普及化的負作用)，目前又缺乏能將AI技術在市場中變現的商業模式。不論是強調未來能降低人力成本，或是主打可以提升既有服務的精準度，都無法直接對業績帶來顯著的高成長，因此從投資者/市場的觀點來看，AI技術是言過其實。

相對地，雖然大數據早先AI已步入高原期，已是十分普及的資訊技術。但它具體回應電商在不同層面所遭遇的問題，改善它們在營運管理中的痛點。推出推薦系統、精準行銷和網站追蹤等資訊服務，今日也都成為各大電商平台的系統標準配備。AI和大數據在商業價值上反映的此消彼長，如同波紋般擴散到資訊書市。開始有專書在講述如何運用機器學習/深度學習打造出電商的推薦引擎。在在證明，雖然商品推薦系統不如人臉/聲音辨識那般具有話題性，卻是電商運用資訊科技促進業務成長的最佳實踐做法。

「大數據架構和算法實現之路：電商系統的技術實戰」一書分成四部份，包含大數據、搜尋引擎、機器學習和網站行為追蹤。而前三項技術恰好吻合我在打造電商推薦系統過程中，獨自摸索、拼湊找到的核心組件。我認為一個完善的推薦引擎，必然是倚靠在大數據、搜尋引擎和機器學習這三根基柱上。雖然和書中節章順序略有不同，但看到自己一路來的領略心法，是從他人之筆成為篇篇書頁，不免讓我拍案叫絕，對黃申有千里遇知音的感觸。

書中先介紹機器學習在電商的應用，從分類、分群再到迴歸分析。全書先以故事中角色的互動帶出技術需求，再說明理論、架構，展示完整的程式碼，後續各章的綱要都是如此。雖然本章用的是較早期的Apache Mahout開源框架，但只要舉一反三，讀者可以自行改用其它開源框架(例如Apache Spark)。迴歸分析的部份，點出了機器學習如何用來進行商品銷售預測。能正確預測未來的銷售數字是個大問哉，實務上不會像書中描述地這麼簡單，但畢竟它還是成功破題，讓有志於此課題的讀者，能對技術實踐有個粗略的印象，用來踏出第一步。

全書花了近半的篇幅講解搜尋引擎的核心和應用，包括最基本的逆排索引觀念到進階的分散式搜尋架構，同時一併介紹了各據半邊天的開源Solr和ElasticSearch。當然後續重心是放在如何整合大數據分析和機器學習算法，用來優化搜尋結果頁的排序，最終達成個人化搜尋。光是這些內容，「大數據架構和算法實現之路」就能充當為一本搜尋技術專書，可見黃申在搜尋領域的專精與經驗。

在錙銖必較網頁回應效率的電子商務，推薦系統一方面要滿足特定演算法的需求，另外也得遵守整體網站訂定的系統回應速度。為此絕大多數的推薦系統都會導入搜尋引擎做為核心模組。武斷地說，想打造大數據導向的個人化推薦系統，必須具備可以靈活使用搜尋引擎的技術力。換個角度看，推薦系統就像是個不需要消費者主動輸入關鍵字的商品搜尋引擎，可見得兩者有多相似，關係有多密切。

在推薦系統的章節，意料之中地提到了耳熟能詳的協同過瀘法，這個算法已經是每書必提、婦孺皆知。令人驚豔的是，黃申居然使用搜尋引擎來實作此算法，而不是採用開源的機器學習框架。他活用了TF/IDF和逆排索引的特性，以開創的做法，簡單、迅速地完成了基於物和基於人的協同推薦服務。黃申描述的個人化商品推薦，和我這些年摸索打造的推薦引擎不謀而合，是藉由大數據的運算能力，混合群眾和會員個人的商品偏好，即時呈現給消費者最感興趣的商品。

電商經營不可或缺的數據追蹤，本書當然沒有遺漏。它先比較第三方方案(例如GA)和自行打造平台的優缺點，再具體而微地展示利用大數據技術該怎麼打造出客製的網站行為追蹤系統。裡面採用的Apache Storm也是我目前採用的開源框架，再一次讓我直呼好巧。

在建置推薦系統時累積的許多想法和技術巧門，曾經動心起念要書寫成冊。畢竟推薦系統這個主題涵蓋大數據、搜尋引擎和機器學習三個當下十分火紅的資訊領域，而且還能跨足數位行銷的範疇，也是行銷資料科學中一個重要的應用。在實務操作中，除了滿足算法需求，得克服效能瓶頸，更要關注消費心理學，與公司商業策略相互呼應。

「大數據架構和算法實現之路：電商系統的技術實戰」的內文，很多和我個人的體悟如出一轍，其中還有不少目前我還未嘗試過的設計。有幸翻閱本書，一來感嘆資訊科技萬變不離其宗，自身的領悟與心法非舉世所罕見，已有行家立著成冊，不勞我費心落筆分享。二來慶幸，自己一路走來琢磨、堆積而成的推薦系統，在設計思維和整體架構上，和對岸名人大腕的做法相比也毫不遜色。可以說是「德不孤，必有鄰」嗎？

Storm應用實踐：實時事務處理之策略

 

提到大數據，黃色小象(Hadoop)的名號已是婦孺皆知。但在巨量資料處理的實務中，Hadoop(和後起之秀Spark)只是批次運算的領頭羊，在天平另一端則是串流/即時運算(簡體稱為流運算)。Apache Storm便是名氣響亮的串流運算開源碼解決方案。

巨量資料技術最適合應用在各式的網路機制與服務。而最佳的資訊流架構規劃，應該是融合批次運算和串流運算。以這樣的使用情境為例「隨著網站使用者的瀏覽歷程，網頁自動呈現最多人感興趣的內容」。就是藉由巨量資料收集進行的批次運算結果，得出「最多人感興趣的內容」的數據洞見。配合即時(更專業上應該說「近乎即時」)收集的「使用者瀏覽數據」，動態改變「網站的呈現內容」，至此才實作出前述的系統機制。

或許有人會提出疑問，覺得同樣的數據流處理也可以用傳統的網頁程式技術來完成。差別在如果採用的是串流運算，它會針對Web主機裡的access log進行後端非同步的資料處理，實踐了營運和分析程式分離的資訊架構。一方面減少前端網頁程式的複雜度，提升程式碼的可讀性。另方面即使未來增加更多的數據分析功能，也不會因此影響到網頁回應的速度，造成整體網站的效能不彰。

從事數據分析的資訊人員，在談到串流數據處理時，肯定會聯想到Splunk(商用)和ELK(開源碼)這兩個知名的時間軸式(time-based)大數據分析平台。Storm很明顯地和它們不同，Apache Storm完全是個數據處理運算平台(platform)，或更嚴格地說是一個數據處理開發框架(framework)。而Splunk和ELK是著重在巨量數據的即時分析，一條龍地提供「收集」、「處理」、「視覺化呈現」的分析工具。

拉回來說，細看Storm組成的元件和它在處理數據流時採用的架構，資深的工程師馬上會聯想到典型的訊息佇列(message queue)服務。猜的沒錯，Storm核心元件中的Spout和Bolt，對應的正是精典的「生產者/消費者」模式中「消費者」的角色。在架構Storm的解決方案時，也少不掉要安裝提供可靠數據來源的訊息佇列服務(如AcitveMQ、Kafka)。你可能會問，若是如此，又何必花費心思導入Storm方案，只要自行撰寫符合生產者/消費者模式的數據處理程式，不就可以打造出即時的數據分析功能？但是Storm平台能做的不僅是一般常見的多執行緒(multi-thread)消費者元件，它通透地提供跨主機(multi-server)、跨處理程序(multi-process)的消費者元件，理論上可以讓數據流處理的總吞吐量接近無上限(還是會卡在系統瓶頸點)。而導入Apache Storm也連帶著引進了管理介面、標準化的開發框架，這都能增進即時巨量資料處理解決方案的可維護性及穩定性。

這本「Storm應用實踐」的內容令我大為讚賞，一開始從最基礎的串流資料處理觀念說起，接著是核心元件Spout和Bolt的介紹。它以貼近IT實務的模擬案例來引導讀者打造可運作的程式原型，從中做學地逐漸讓人熟悉著手Storm開發的最佳程式範型(pattern)。

Storm的Spout和Bolt元件，如同Hadoop著名的Map/Reduce般，在極簡的類別設計下，展現出無窮潛能的實作空間。書中後半針對效能調校、程式除錯等進階議題詳加說明，還有比官網文件更深入淺出的Storm內部運作細節解說，當之無愧地可以說是「Apache Storm自學聖經」。終章作者介紹了Trident這個建基在Strom上的抽象框架，它提供了類似Spark Streaming一樣的「微批次/小批次」資料處理功能。老實說，Trident的複雜度足以獨自出版成冊，作者也言明只想粗淺介紹這個抽象框架，讓讀者有個印象，一般在開發Storm應用時不見得需要用到Trident。

「批次處理」和「串流處理」像是大數據工程師工具箱裡的十字和一字起子，兩者適用的情境和條件限制截然不同。透過妥善的規劃將兩者相互整合，會展現出一加一大於二的驚人成果。因此從事大數據工程的資訊人員，千萬要把握學習Apache Storm的機會，更別錯過「Storm應用實踐」這本值得典藏的傑作(還是有幾個勘誤處，細讀才會發現)。