[對話式AI-9] 2020 Chatbot Framework Comparison 聊天機器人框架對比

這是經過數個月的調查與更新,所做的2020年聊天機器人框架對比。本表整理了10個知名的Chatbot框架,幾乎涵蓋時下Chatbot所有的Feature;經過一輪基本的驗證後,針對模糊之處再深入使用,藉此得到詳盡的對比。今年10月做了一次修正與更新,為了將資料整合到部落格的AI專欄上,也克服網誌呈現表格的問題,在此分享給各位業界先進與同好。

TypeFeatureDescriptionGoogleMicrosoftXiao-i Robot小i機器人IBMDYDUSAPFlow XOMeyaGupshupHubspot
DialogflowAzureBotiBot Enterprise
/ Pro
iBot International
/ Express
WatsonDYDURecast.aiFlow XOMeyaGupshupHubspot
Operation & appearanceCode-free backend透過後端介面拖拉流程圖就能建立chatbot,不須寫程式××
Structure & logicKnowledge-independent assistantknowledge(skills)的編輯與assistant的創建彼此獨立×××××××
Bots collaboration可以定義一系列彼此knowledge不相關的bot,然後通過組合bot來構建一個assistant的整體輸出××××
FAQ-based intent支援FAQ格式的intent與答案,而每個intent的答案是固定的×××××××
Multi-languageMulti-language支援多語言對話×××
Auto-language detection系統自動偵測語言,使用者不需自行選擇×××××
Pre-build contentKnowledge預置常用的一般或行業知識,允許客戶快速構建chatbot
Knowledge editIntent -- intent conflict resolution利用AI技術偵測人工填寫intent/user samples時產生的錯誤和衝突××××××××
Intent -- utterance對某個intent編輯不同的問法(擴展問)×××
Entity -- my entity可自行定義entity(例如通過同義詞)××××
系統可自動推薦同義詞×××××××
Multi-turn Dialog若問句資訊不足,系統可以反問使用者(多輪對話)√(ibot ui)√ (scene)√(5)
× (workflow)√(50)
Dialog -- slots系統可自動擷取與填充槽位
Dialog -- disambiguation當使用者的問句匹配到dialog中2個以上的intent節點時,assistant會請使用者決定正確的intent××××××××
Dialog -- 意圖推薦當使用者的問題超出服務範圍,或無法識別意圖時,系統可以推薦相關的意圖給使用者×××××××
Dialog -- multi slots filling對intent缺失的多個資訊,進行一次性的提問,讓使用者可以一次補充所有資訊,而非逐條詢問與回覆×××××××
Dialog -- multi reply對同一intent有多種回答,讓系統可以隨機選擇,產生更自然的對話效果××
Dialog -- Digression允許用戶在dialog中,進行話題(node)的切換,例如從某個流程節點跳轉到另一節點,並允許跳回等。×××
Dialog -- interruptions可讓使用者在對話中暫時討論不同的主題,然後再返回原來的主題××××√ (quit keyword)×××
Knowledge map顯示不同knowledge之間的關係和聯繫×××××××
Answer - variable提供特定參數,讓系統獲取相關資訊,如使用者名稱、IP、URL等內容,也可以直接用variable的形式添加在答案中。×××
Sentiment允許系統對正反及不同程度的情感狀態,做出對應的回應××××××××
Import/export支援knowledge匯出及匯入×××××
DashboardAnalytics dashboard提供報表讓客戶進行數據分析√ (7 D)√ (2 WK)√ (30 D)
√ (30/90 D)√ (3 M)√ (increase)
TestingTester提供測次問句的各種工具
Batch test支援問句的批次測試××××××××
ImproveDeep learning model支援深度類神經網路模型×××××
Active learning從日誌中收集待確認的對話,經客戶確認後學習到知識中××××
Intent recommendation根據已有的對話數據推薦意圖,從而實現更快地訓練××××××
IntegrationCustom plug-in可以客製化整合其他API××
Preview link可提供預覽chatbot的連結××××
Service desk integrations支援無縫轉人工服務××
Versioning允許對assistant的編輯結果,進行版本控管××××××
AuthorizationAccess control可以允許添加訪問人員和管理相應的權限××××××
Search skill支援透過搜索非結構化數據來擴展assistant的knowledge×××××××
DataLog data across instances將正式環境中的insights整合到開發環境中×××××××
Data isolation××××××××
ServiceSLA 99.9%服務等級協議達到99.9%的可用時間×××××××××
Mail subscription支援透過郵件訂閱comments等資料×××××××××
Survey可設立問卷調查模板(對內部或外部調查)×××××××××
對話預處理通過預設的對話匹配規則,可快速自訂簡單的場景××××××××
Matching strictness可調整匹配的閾值××××××××
定時任務支援知識和詞的定時同步××××××××
前後綴處理可自動忽略位於句首或句末的特定詞語或短句××××××××
停用詞可自動忽略句中任意位置的特定詞語×××××××××
Table QA可動態載入結構化數據,並通過自然語言交互,轉換成SQL語句,對資料庫進行查詢×××××××××
質檢自動分析交互日誌,將可能的錯誤應答的對話,提供給維運人員審核××××××××
地區維度根據使用者所在地區給出不同答覆××××××××
知識編輯鎖一位編輯人員操作某個知識時,系統將鎖定該知識群組,使其他人員無法編輯,藉此防止衝突的產生×××××××××

現有命名方法彙整及比較

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

在程式設計的命名上,當變數、函式及類別等名稱由兩個以上的單字組合,就可以使用現有的命名方法,增加識別和可讀性。目前已經出現的命名方法,可以分為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,更容易被誤讀成其他意思,也難以透過猜測關鍵字搜尋。

主流通訊協定介紹(RPC、SOAP、REST)

Remote Procedure Call (RPC)

起源於1976年,允許Client遠端呼叫Server的子程式,然後將執行結果返回給Client;當時的傳輸資料常使用二進制格式,為了統一資料傳輸格式,隨後出現了XML-RPC, XML作為資料交換語言的RPC機制。

Simple Object Access Protocol (SOAP)

起源於1998年,由於RPC經常被Firewall及Proxy Server阻擋,為解決兼容及安全性問題,採用HTTP(起源於1989)是更好的方法,SOAP還提供了一套標準方法讓程式間可以互相通信。可以簡單把SOAP當作RPC+XML+HTTP(POST only)+有狀態的通信方法。

Representational State Transfer (REST/RESTful)

起源於2000年,由於SOAP過於複雜且依賴狀態,REST提倡使用標準的HTTP中的四種動作GET、PUT、POST及DELETE,以及Uniform Resource Identifier (URI)來指定資源,降低開發的複雜性。可以簡單把REST當作PRC+XML+HTTP(GET,PUT,POST,DELETE)+URI+無狀態的通信方法。

發展趨勢

REST風格相比XML-RPC及SOAP更加簡潔易用,而JSON資料交換語言相較XML更加輕量,目前大多數的Web Service都採用REST+JSON作為傳輸方法。

CI/CD筆記

流程

  • 持續整合(Continuous Integration)
    • Code Repository
    • Version Control
    • Build
    • Integration
  • 持續交付(Continuous Delivery)
    • Release
    • Delivery
  • 持續佈署(Continuous Deployment)
    • Production

評比指標

  • 佈署頻率(Deployment Frequency)
  • 變更前置時間(Change Lead Time)
  • 服務恢復時間(MTTR)
  • 變更失敗比率(Change Fail Rate)

常用工具

  • CI / CD
    • Jenkins
    • Gitlab CI
    • Travis CI
    • Circle CI
    • Drone
  • Version control
    • Bitbucket
    • GitHub
  • POM
    • Maven
  • Code Quality and Security
    • SonarQube
  • Unit Test
    • TestNG
  • Test Automation
    • Selenium
    • Appium

軟體設計模式筆記

  • 裝飾者模式:包裝一個物件,以提供新的行為。
  • 適配器模式:封裝物件,並提供不同的介面。
  • 模板方法模式:由子類決定如何實現一個演算法中的步驟。
  • 工廠方法模式:由子類決定要創建哪個類別的實體。
  • 單件模式:確保有且只有一個物件被創造。
  • 策略模式:封裝可以互換的行為,並使用委託來決定要使用哪一個。
  • 組合模式:客戶用一致的方式處理物件集合和類別物件。
  • 狀態模式:封裝了基於狀態的行為,並使用委託在行為之間切換。
  • 疊代器模式:在物件的集合之中游走,而不是暴露集合的實現。
  • 外觀模式:簡化一群類的介面。
  • 裝飾者模式:包裝一個物件,以提供新的行為。
  • 抽象工廠方法:允許客戶創建物件的家族,而無需指定他們的具體類。
  • 觀察者模式:讓物件能夠在狀態改變時被通知。
  • 代理模式:包裝物件,以控制該物件的訪問。
  • 命令模式:封裝請求成為物件。