[對話式AI-4] Chatbot的挑戰與發展趨勢

雖然電腦視覺（Computer Vision）透過深度學習（Deep Learning）技術取得了重大進展，但在自然語言處理（Natural Language Processing）領域，深度學習的導入仍然處於發展初期。

以聊天機器人（Chatbot）來說，自從圖靈測試在2014年被聊天機器人Eugene通過後，加拿大學者改進測試的缺失提出了威諾格拉德架構挑戰賽（Winograd Schema Challenge），也是目前最具權威的AI競賽。

該競賽的第一輪是代詞消歧問題（Pronoun disambiguation problems）。舉例來說，當人類分析句子時，會用經驗來理解指代的對象：

  • 市議會拒絕示威者，因為他們害怕暴力。
  • 市議會拒絕示威者，因為他們提倡暴力。

而這個選擇題只有兩個答案，代詞”他們”是指”市議會”還是”示威者”，AI應該要指出在第一句說的是市議會，第二句說的是示威者，從問題上可以發現，系統無法透過這段話的上下文進行理解得到答案，這在傳統實作上必須透過知識圖譜（Knowledge Graph）進行推理，或使用深度類神經網路模型，要通過比賽拿到獎金25,000美金，準確率（Accuracy）必須達到90%以上，但目前最好的成績只有58%，遠比人類低得多。

除了上述根本影響Chatbot問答品質的問題，還有幾個難題仍未被突破：

  1. 通用的模型架構（Universal Model Architecture）：為了整合語音辨識、詞法分析、句法分析、語意分析、深度學習，答案搜尋，對話管理、自然語言生成和語音合成等模組，確保其相容性，當前Chatbot架構與模型相當複雜，管理較為困難，如何研發通用的架構與模型，是未來所有同業的發展目標。
  2. 情感計算（ Affective Computing ）：從分析文本的情感 （Sentiment Analysis）到辨識人類情緒的情感計算，例如開心、生氣、哀傷等；可以讓Chatbot與人交互時更有溫度，是目前產學界熱門研究方向。
  3. 開放領域（Open Domain）：現在的Chatbot只能做好特定領域的工作，如何建構開放領域的知識，甚至不需要人工建構知識，讓機器自學習，也是產學界正在努力的方向。
  4. 端對端 （ End to end ） ：不經過傳統的模組串聯，利用深度學習 （ Deep Learning ） 建立端對端的簡潔模型；達到輸入原始資料後，可直接得到想要的輸出結果，但與此同時還要支援多輪對話管理、上下文情境及知識圖譜推理，避免安全回答，甚至是保持Chatbot個性的一致性，正確的進行指代消解，這些挑戰都是產學界近期的目標。
  5. 基於生成的模型（Generative Model）：目前自然語言生成技術 ，可分為基於檢索、基於範本及基於生成兩種方法，三者都可以導入深度學習技術，目前以基於檢索及基於範本為業界主流；雖然深度學習Seq2seq模型非常適合產生文字，但此基於生成方法尚處早期的發展階段，空間和時間複雜度高，實際應用效果不佳。

[對話式AI-7] 預訓練語言模型比較（ELMO、BERT、GPT-2）

預訓練（Pre-train）語言模型可用於自然語言理解（Natural Language Understanding）的命名實體識別（Named Entity Recognition）、問答（Extraction-based Question Answering）、情感分析（Sentiment analysis）、文件分類（Document Classification）、自然語言推理（Natural Language Inference）等任務。

以及自然語言生成（Natural Language Generation）的機器翻譯（Machine translation）、自動摘要（Automatic summarization）、閱讀理解（Reading Comprehension）、資料到文本生成（Data-to-Text Generation）等任務。

本文透過列舉時下主流預訓練語言模型的特點，介紹最具代表性的ELMO、BERT及GPT-2模型；用最簡短的文字敘述，讓大家能夠輕易比較出差異。

ELMO（Embeddings from Language Model）

  • RNN-based Language Models
  • 透過一堆句子訓練，不需要標註
  • 預測下一個Token
  • 從RNN的hidden layer取得Contextulize word embedding
  • 從正反向embedding接起來就是上下文的embedding
  • 最後把每一層的embedding都加起來，再由後續任務學習到加權參數
  • 94M個參數

Source: https://arxiv.org/abs/1802.05365

BERT（Bidirectional Encoder Representations from Transformers）

  • 屬於Transformer的Encoder
  • 只需要訓練Transformer的Encoder（輸入輸出一對一）
  • 透過一堆句子訓練，不需要標註
  • 給一個詞序列，每一個詞都會吐embedding
  • 中文更適合用字為單位，因為用one-hot encoding詞太多了；常用中文字約4800個，中文詞則比這個高數倍
  • Masked LM: 輸入詞序列中隨機15%的詞被換成特殊的Token [Mask]，並做預測
  • 預測下一個句子: 引入[SEP]代表兩個句子的交界，及[CLS]代表輸出分類結果的位置
  • 上述兩種方法都是把抽出來[Mask]或[CLS]的Vector丟到Linear Multi-class Classifier去預測詞
  • 以上兩種方法要同時使用
  • 340M個參數

Source: https://arxiv.org/abs/1810.04805

GPT-2（Generative Pre-Training）

  • 屬於Transformer的Decoder
  • 預測下一個Token
  • 40GB的文本訓練出來的
  • 可以做到Zero-shot Learning，不需訓練資料，做到Reading Comprehension（F-score=55接近Dr.QA）、Summarization（跟隨機差不多）、Translation（跟隨機差不多）
  • 1542M個參數

Source: https://d4mucfpksywv.cloudfront.net/better-language-models/language_models_are_unsupervised_multitask_learners.pdf

[對話式AI-6] 模組化的任務導向對話系統實作方法

# 自然語言理解 (Natural Language Understanding)
問句 = input("請輸入你的問題: ") 
使用者動作.意圖 = 意圖識別(問句)
使用者動作.一組槽位 = 槽位填充(問句, 使用者動作.意圖)

# 對話狀態追蹤 (Dialogue State Tracking)
if (使用者動作.意圖 == Null)
　　對話狀態.意圖 = 得到意圖(對話歷史)
　　對話狀態.一組槽位 = 更新對話狀態(使用者動作.一組槽位, 對話歷史)
else
　　對話狀態 = 使用者動作
　　填充個性化槽位(對話狀態.一組槽位, 使用者畫像)
　　意圖所缺的槽位填入預設值(對話狀態)

# 對話策略學習 (Dialogue Policy Learning)
if (對話狀態.意圖 == Null)
　　系統動作.意圖 = "不明"
else if (對話狀態.意圖 == 特定服務)
　　if (槽位是否缺失(對話狀態))
　　　　系統動作.意圖 = "對空白槽位提問"
　　　　系統動作.一組槽位 = 對話狀態.一組槽位
 　 else
　　　　系統動作.意圖 = 特定服務
　　　　系統動作.一組槽位 = 查詢服務API(系統動作.意圖, 對話狀態.一組槽位)

# 自然語言生成 (Natural Language Generation)
if 系統動作.意圖 == "不明"
　　問句 = input("我不懂你的意思，請換個方式告訴我: ")
else if 系統動作.意圖 == "對空白槽位提問"
　　系統提問 =  提問生成(系統動作)
　　問句 = input(系統提問)
else if 系統動作.意圖 == 特定服務
　　print(回答生成(系統動作, 回答模板))

[對話式AI-5] 基於知識庫的問答系統實作方法

# 問句分析 (Question Analysis)
問句 = input("請輸入你的問題: ") 
代表問句的一組資訊詞 = 問句分析(問句)
使用者意圖 = 意圖識別(代表問句的一組資訊詞, 知識圖譜)

# 片語映射 (Phrase Mapping)
if (使用者意圖 == Null)
　　問句 = input("我不懂你的意思，請換個方式告訴我: ")  
else if (使用者意圖 == 特定服務)
　　服務所需的一組資訊詞 = 所缺的資訊詞填入預設值(代表問句的一組資訊詞)
　　問句資訊詞的本體 = 自然語言映射到本體(服務所需的一組資訊詞, 知識圖譜)

# 查詢建構 (Query Construction)
　　答案的關鍵內容 = 查詢(問句資訊詞的本體, 各種API服務)
　　答案的本體 = 服務映射到本體(答案的關鍵內容, 知識圖譜)
　　一組候選答案 = 產生答案(答案的本體, 知識圖譜)

# 消歧 (Disambiguation)
　　  一組候選答案 = 消歧(一組候選答案, 服務所需的一組資訊詞)

# 答案生成 (Answer Generation)
　　一個答案 = 排序(一組候選答案)
　　回答 = 轉換成自然語言(一個答案, 回答模板)
print(回答)

[對話式AI-1] Chatbot的類型與對比（問答、對話與閒聊系統）

由於常常跟客戶和外部工程師雞同鴨講，最後發現大家對聊天機器人的定義都不一樣；你知道Chatbot可以分成三類嗎？對話式AI專欄的第一篇，就來介紹一下「各類Chatbot的用途」，並針對「開發方法」、「特點」、「關鍵評價指標」及「應用場景」等進行深入對比，讓你一次搞懂Chatbot，不再一知半解。

類別問答系統任務導向對話系統閒聊系統
英文Question Answering systemTask-Oriented Dialogue systemChit-Chat Dialogue system
功能回答使用者問題代替使用者完成任務陪伴使用者閒聊
領域特定領域特定領域 開放領域
方法基於Web檢索、基於知識庫、基於社群模組化（基於規則、資料驅動）、端對端（資料驅動）基於檢索、基於生成
特點單輪對話，著重問句分析（識別資訊詞）多輪對話，著重對話管理多輪對話，著重個性化及情感分析
關鍵指標召回率（Recall）、精確率（Precision）、F-Measure任務完成率、對話耗時、對話輪數、機器模擬使用者評分詞重疊率、詞向量距離、機器模擬使用者評分
應用場景FAQ、教育助理、訂票閒聊、陪伴
知名案例IBM WatsonSiri、Google Assistant微軟小冰、SimSimi
實作方法基於知識庫的問答系統模組化的任務導向對話系統應用搜尋引擎檢索，或訓練Seq2seq模型生成

[對話式AI-8] 研發部門與開發流程介紹

本文以筆者所任職的公司為例；在不涉及公司機密的前提下，介紹人工智慧產品研發的「相關部門、開發流程及工作內容」，為大家揭開AI產業的神秘面紗。

公司主要業務是為電信、金融、政府及電商等領域，導入AI技術、自然語言處理（Natural Language Processing, NLP）技術、系統整合及平台建置，最常幫一些大型機構建置Chatbot及呼叫中心等系統，協助提升客戶服務，並降低人力需求。

AI公司的組織架構

一般AI公司研發中心可以分為下列部門（舉例），橫向為各部門名稱，縱向為組織架構:

  • 研究院 / 知識研究部（理論及算法研究）
  • 自然語言理解NLU研發部 / 語音引擎研發部（算法研究及應用）
  • 基礎產品研發部 / 雲端平台研發部（引擎應用）
  • 產品測試部
  • 解決方案部（產品包裝）
  • 專案實施部（產品應用及二次開發）

AI產品的開發流程

  1. 研究院負責與大學院校合作，閱讀論文並研究前瞻技術後，將研究成果提供給NLU / 語音研發部。同時通報專利申請單位，將有價值的技術註冊成專利。
  2. NLU / 語音研發部將研究成果，實作成底層引擎，並將其轉交給基礎產品研發部。同時通報專利申請單位，將有價值的技術註冊成專利。
  3. 基礎產品研發部負責市場調查、設計產品，並撰寫前後端邏輯，將引擎包裝成Chatbot / 推薦系統（Recommender system）等產品。同時通報專利申請單位，將有價值的技術註冊成專利。
  4. Chatbot / Recommender等產品的基本內容及行業知識，由知識研究部負責建置，如標註資料、建置知識、知識圖譜、預置行業包等。
  5. 解決方案部負責將Chatbot / Recommender產品的各項能力，打包成各個行業的解決方案，提供給業務單位兜售。
  6. 如果客戶有興趣，專案實施部會使用該Chatbot / Recommender等產品 / 解決方案，為客戶無償做POC（Proof of Concept)；如果客戶滿意其成果，就會為後續開發簽約付錢。
  7. 專案實施部再根據合約內容完成Chatbot / Recommender等系統建置及介接API等二次開發工作，並提供售後維護服務。公司每年再收取License、維護及再開發費用。

AI產業的工作內容

若你有志投入AI相關產業，可以往以下幾種部門走，但著重的技術都不同：

研究院

一般使用Python語言及TensorFlow、PyTorch及SKlearn等框架研究算法（Algorithm），如語音辨識（Automatic Speech Recognition）、分詞（Word Segmentation），詞性標註（Part of Speech)、句法分析（Syntactic Analysis）、語意分析（Semantic Analysis)、對話管理（Dialogue Management）、自然語言生成（Natural Language Generation）及語音合成（Text to Speech）等。

NLU / 語音研發部

由於Python不適合用於大規模平行計算（Parallel Processing），這裡常使用Java語言，Mahout、Deeplearning4j等框架在Hadoop及Spark上實現算法、引擎、訓練及部署模型。

基礎產品研發部

這裡就比較沒有局限了，什麼語言和框架都可以用，譬如使用Go語言及Gin框架，撰寫後端邏輯，將底層引擎包裝成產品；以及使用Javascript語言、React或Vue等框架開發前端。

專案實施部

根據客戶需求選擇語言及框架，透過Chatbot / Recommender等產品 / 解決方案為客戶二次開發，並提供售後維護服務。

RSC修錶及驗錶過程分享

母親大人的OP26是香港購入的，因不慎從口袋掉出摔破鏡面送修；Batman是歷史高點在玩錶舍購入的，全新有膜沙烏地阿拉伯18年11月保卡，雖然說現在賠了一些，但畢竟停產了相信跌幅有限，購入至今也戴了半年多。

送驗及送修過程:

由於平常會用清水軟刷洗錶，本次趁著幫母親大人送修摔破鏡面的OP26，想檢測Batman的防水性能，但RSC要收2000元檢測費，因此改為利用免費的送驗服務，檢測一下錶況，若防水圈有問題，應該也會藉此發現。

OP26因為殘留的玻璃碎削，RSC小姐要求強制洗油；基本檢測後，師傅發現龍頭有磨損，怕影響防水性能，所以可自費更換。費用分別是藍寶石鏡面NT$2800+龍頭2000+洗油保養11800，總計16600。

最後得到兩張綠色的工作單據，送修的手錶寫明20天後取件，領錶時再付費；送驗的則是待通知。

取回過程:

等待約20天後，接到RSC通知，已可取回手錶；送驗的Batman僅簡單告知沒有問題，但使用數日後發現變準了，本來誤差是+4秒/日，現在接近0秒/日，不知道是調校過，還是消磁所帶來的效果；修好的OP26則是發現錶盤有被玻璃碎屑輕微刮傷，如果在意的應該可以要求換面盤，經過測量得到誤差+2.38秒/日。付費方式可以使用現金或刷卡，本次選擇刷卡。

最後得到了刷卡單據、統一發票、印有Logo的收納紙套、送驗的Batman付塑膠錶套，送修洗油的OP26贈原廠皮套。

基於深度學習的推薦算法調研

年底因為工作任務，調研了幾篇推薦系統 （ Recommender System ，以下簡稱RS） 的論文；我寫碩論時還不流行深度學習（Deep Learning，以下簡稱DL），轉眼間DL已經成為顯學，近年發表的推薦算法也都是基於DL的研究，我也已經應用在業界的專案中，並獲得了一些進展，但對DL應用在RS的普遍成效，我也是相當好奇。

趁著還記得調研的內容，在此以ACM RecSys 2019最佳論文「Are We Really Making Much Progress? A Worrying Analysis of Recent Neural Recommendation Approaches」為基礎，跟大家分享一些心得：

讀後總結：

  • DL應用在電腦視覺CV和自然語言處理NLP領域相當成功，但在其他方面不如預期。
  • 2015到2018年RecSys, WWW, KDD, SIGIR頂級會議共有18篇DL論文與top-n推薦有關，可重現的實驗有7篇，比例約39%；也就是61%的實驗無法重現。
  • 通常做為baseline的方法有非個性化TopPopular、協同過濾CF的ItemKNN、UserKNN、P3alpha、RP3beta，混合的ItemKNN CF + CB，以及機器學習ML的SLIM。
  • 論文作者重現這7個實驗，驗證其進展是否真實，發現DL方法，效果並沒有上述經典的啟發式方法好，在7篇論文中只有1篇優於上述baseline方法，但只是在部分情況下超越。
  • 論文作者認為導致此結果的原因，是這7篇論文挑選了較差的baseline方法和參數、所選擇的測試資料epoch次數不同，甚至有實驗程序不同導致評估錯誤。

個人心得：

  • 為了驗證這幾年的進展，論文作者使用公開資料集作為可重現條件之一，從18篇論文中挑選了7篇重現實驗，但目前的公開資料集有資料量不夠大，矩陣比較不稀疏，以及特徵少等特色；此種資料集並非DL的強項。
  • 公開資料集大多出於學術界，其大小與特徵豐富程度遠低於業界的系統；所以論文作者的結論，以及DL在商用資料集的表現，還有待進一步的驗證。

參考資料：
https://dl.acm.org/authorize?N684126
https://arxiv.org/pdf/1907.06902.pdf

現有命名方法彙整及比較

命名規則是為了增加識別和可讀性，沒有強制的規定，但一旦選擇其中一種，會建議編寫時統一格式；而化學、天文、生物也有其慣用的命名方法；大部分的程式語言也有對此進行建議，以統一風格。

在程式設計的命名上，當變數、函式及類別等名稱由兩個以上的單字組合，就可以使用現有的命名方法，增加識別和可讀性。目前已經出現的命名方法，可以分為Underscore（底線式）、Camel-case（駝峰式）及Hungarian notation（匈牙利命名法）三大類。此文進行彙整，並以個人經驗，探討其優缺點。

一、Underscore（底線式）：

單字之間使用底線分隔，GNU/Linux環境中最常見，例如：string_name。

優點：

使用底線取代空格，閱讀上比較直覺易懂。

缺點：

比起Camel-case使用字首大寫取代空格，底線比較少在日常輸入，因此需要適應。

二、Camel-case（駝峰式）：

單字之間使用大寫分隔，又可以分為Lower Camel-case（小駝峰式），或Upper
Camel-case（大駝峰式），而後者又稱為Pascal-case（帕斯卡式）。

Lower Camel-case（小駝峰式）：
第一個字母用小寫，此變化常用在變數名稱上，例如stringName。

Upper Camel-case（大駝峰式）：
第一個字母用大寫，此變化常用在函數、類別、屬性及命名空間上，例如StringName。

優點：

  • 可以利用名稱前綴的大小寫，區分變數，以及函數、類別等其他型別。
  • 單字之間使用大寫取代底線，能夠減少名稱的長度，減少程式碼超出視窗被遮擋的情況。

缺點：

  • 比起Underscore使用底線取代空格，閱讀上較不直覺易懂。

三、Hungarian notation（匈牙利命名法）

在Camel-case（駝峰式）的基礎上，在名稱前綴添加預先約定好的縮寫，例如約定如下：

b       boolean
c       character
str     C++ String
si      short integer
i       integer
li      long integer
f       floating point
d       double-precision floating point
ld      long double-precision floating point
sz      Old-Style Null Terminated String
if      Input File Stream
is      Input Stream
of      Output File Stream
os      Output Stream
S       declaring a struct
C       declaring a class

Source: http://web.mst.edu/~cpp/common/hungarian.html

根據縮寫用途的不同，又可分為Systems Hungarian，以及Apps Hungarian。

Systems Hungarian：
名稱前前綴代表的是實際的資料型別，例如：strName。

Apps Hungarian：
名稱前綴代表的是目的或其他提示，例如：usName，其中us代表unsafe，為了避免Code injection或XSS，之後必須進行過濾處理。

優點：

  • 不需要IDE支援，就能夠從名稱能看出型別。
  • 制定好的編碼規則，能夠在搜尋時更加統一易找。
  • 制定好的編碼規則，能夠在命名及輸入上更快。

缺點：

  • 需要另外學習編碼規則。
  • 現代IDE已經可以輕易的區分型別，在資料型別上，此方法稍嫌多餘。
  • 變數型別修改時，名稱也必須修正維護。
  • 採用縮寫來命名，對新手較不友善，例如szName，不如stringZeroName。
  • 也更容易造成歧義，例如szName，更容易被誤讀成其他意思，也難以透過猜測關鍵字搜尋。

Rolex百事圈與藍黑圈搜尋趨勢分析

最近一直在百事可樂與蝙蝠俠間猶豫不決，因此產生了一個疑問，鋼版百事圈和藍黑圈倒底誰比較紅？以及雜誌上的說法到底有沒有根據？


從Chrono24上可以發現新版藍黑圈平均售價63.4萬，比百事圈60.1萬還要來得高；但又觀察到台灣市場，百事圈售價略高藍黑圈約1萬，因此發揮科男的精神，特別做了一下調查。


從Google Trends可以發現，2018年3月鋼板百事圈發布以後，馬上爆款，之後逐步與舊版三板帶藍黑圈打平；而2019年3月新版藍黑圈發布以後，一併拉抬了舊版的聲勢，甚至高過新版。而在近兩個月內，全球新版藍黑圈詢問度52%略高於百事圈48%，但若加上舊版藍黑圈，則藍黑圈整體詢問度70%遠高於百事圈30%。


不看舊版藍黑圈的話，近兩個月在美國，藍黑圈詢問度52%百事圈48%；在日本，藍黑圈
47%百事圈53%。台灣數據過少無法判斷。


結論：
近期數據顯示，若只看新款，兩者持平；其中美國偏愛蝙蝠俠，歐洲持平，亞洲偏愛百事可樂。若納入舊款，蝙蝠俠整體熱門程度高於百事可樂，且舊款詢問度更高。

流言終結者：
Q: 百事圈更紅？
A: 2018年百事圈的聲勢，其實與2013年舊版藍黑圈相當；2019年新版藍黑圈走勢則有待觀察。
Q: 百事圈帶動藍黑圈銷量？
A: 舊版藍黑圈2013至2018年的搜尋量相當穩定，2018年3月百事圈的發布，並未明顯拉抬舊版藍黑圈的詢問度。
Q: 新版藍黑圈帶動舊版的銷量？
A: 2019年3月新版藍黑圈的出現，明顯拉抬了舊版的聲勢，但詢問度仍是舊版比較高，可能是因為五珠鍊接受度不如三板帶。

未來趨勢：
GMT Master II百事圈與藍黑圈等雙色陶瓷圈，在銷售上一直有相乘效應，在今年新版藍黑圈的宣傳推動下，估計已停產的舊版藍黑圈，還會在二手市場熱個幾年。

參考：
2012至2019年的搜尋概況 – Rolex GMT MasterII 鋼版 雙色陶瓷圈 相關型號