「chatbot + AI = 下一代操作模式」

在上一篇([42]回顧整個系列 - 開發Chatbot的整個生命周期)把整個系列文章review完了之後，算是把整個系列寫下了一個句點。

不過，下一步是什麽？依照關注的方向點不同可以往不同的地方鑽研。這篇將介紹接下來可以看的不同方向。

在上一篇([41]使用Chatdown做Chatbot的UI Prototyping)，介紹完了可以用來做Prototyping的UI工具Chatdown之後，這個系列想要介紹的東西都介紹完了。

這篇想要整個重新在review一次整個開發chatbot的開發流程（lifecycle），并且看看再每一個環節這個系列都介紹了什麽可以使用。

2018-09-01 Saturday
「chatbot + AI = 下一代操作模式」 bot framework chatbot cognitive service ai azure custom-vision qna-maker computer-vision speech-service

在上一篇([40]Visual Studio Tools for AI - 用VS管理Cognitive Service的服務)介紹完了管理Cognitive Service的好工具Visual Studio Tools for AI，這篇來看看另外一個協助開發Chatbot的工具Chatdown。

來看看這個工具能夠提供什麽功能，并且如何協助Chatbot的開發。

在上一篇([39]Video Indexer - 讓影片可以被搜索和分析出影片的重點)介紹完了Cognitive Service的整合服務Video Indexer了之後，這篇來介紹微軟怎麽讓開發著使用Cognitive Service便的更加的容易。

看看管理Cognitive Service的好工具：Microsoft Visual Studio Tools for AI能夠做到什麽。

在上一篇([38]用Application Insight看使用者都在QnA Maker查什麽)介紹完了QnA Maker之後，接下來來看看另外一個也很有意思的服務 Video Indexer。

這個服務和QnA Maker一樣，他是一個用很多服務整合出來的Solution。和QnA Maker整合的都是Azure服務不同的是，Video Indexer整合的都是Cognitive Service的服務爲主。

這篇來看一下Video Indexer是什麽，并且看看能夠做到什麽。

在上一篇([37]維護QnA Maker的知識庫 - 設定url或者檔案為來源、多人維護以及離綫定義知識庫)介紹完了如何更容易的去維護Knowledge Base了之後，這篇來看另外一個問題：就算再怎麽維護Knowledge Base，如果裡面内容不符合使用者的查詢，那麽一點意義都沒有。

因此瞭解到使用者怎麽詢問這些Knowledge Base非常的重要。

在這一篇將來看看如何透過Application Insight看看使用者都在搜索什麽問題。

上一篇([36]Chatbot整合QnAMaker - 使用對話查找知識集)介紹完了如何把QnA Maker整合到Bot Builder SDK裡面，讓使用者可以透過問答的方式去搜索設定好的Knowledge。

這篇要來介紹維護Knowledge Base這件事。如何透過設定截取網頁内容或者截取檔案内容來設定Knowledge、怎麽多個人維護和怎麽Offline 透過LUDown這個工具來Offline備份以及設定。

在上一篇([35]使用QnA Maker打造問答知識類型資料集服務)介紹了QnA Maker的主要目的，以及如何使用之後，下一個問題就是要怎麽把QnA Maker整合到程式裡面。

在這一篇將介紹如何把QnA Maker的服務整合到Chatbot裡面。

在上一篇([34]賦予Chatbot用語音下指令以及翻譯的功能)介紹完了Translator Speech Api之後，基本上這個系列想要介紹的Cognitive Service基本服務都介紹完了，這些服務包含了文字、圖片以及語音的智能處理。

在這系列接下來的部分將在介紹幾個Cognitive Service的進階服務、以及管理和維護這些Cognitive Service工具以及微軟在AI這方面還提供什麽樣的未來藍圖。

這篇先介紹知識庫類型的服務QnA Maker，看看這個服務能夠做什麽。

在上一篇([33]C#使用Translator Speech API服務達到語音轉文字加翻譯)瞭解了如何用C# Console使用Translator Speech Api的服務達到語音轉文字加翻譯。那麽要整合到Chatbot就更加沒有問題了。

這一篇將介紹如何把Translator Speech Api整合到Chatbot裡面，語音能夠轉文字就能夠達到用說來叫Chatbot做事，并且提供一些多國語言的使用情景，例如不會說中文的客戶，可以透過chatbot達到及時語音翻譯。

在上一篇([32]Cognitive Service語音服務相關介紹)介紹了Cognitive Service裡面對於語音相關的服務介紹，在接下來將會關注在語音轉文字加翻譯的服務上面。

上篇提到有兩個服務在做這件事情，分別為Speech Service以及Translator Speech API。個人使用經驗是Translator Speech API比較準確，因此在這篇將環繞在如何在C#使用Translator Speech API。

在上一篇([31]Custom Vision Train好的Model匯出離線和給app使用)介紹完了把Custom Vision的Model匯出并且用Docker File版本讓他本地執行之後，在Cognitive Service裡面的圖片相關就介紹到一個段落。

在接下來的篇幅將來介紹另外一種常見的輸入方式，也就是透過語音的方式。任何科幻電影的指令輸入模式都是語音，例如《鋼鐵人》裡面的助理系統Jarvis，想象一下如果可以用説的就讓電腦做事有多方便。

這邊就來看看Cognitive Service裡面對於語音這塊處理有什麽幫助。

上一篇([30]Confusion Matrix - 用來衡量Classifier Model的方式 Precision和Recall)介紹了Confusion Matrix并且如何使用Precision和Recall這兩個指標來衡量一個Classifier Model的好壞。

這一篇又回到了Custom Vision。在Custom Vision Train好的Model是否能夠拿來離線和或者別的應用例如app裡面使用呢？

Custom Vision有提供匯出Model的功能，這篇將對這個部分介紹。

在上一篇([29]維護Custon Vision Model - 使用歷史查詢記錄做訓練以及如何版控)看完了如何用歷史的搜索結果來持續training Model(模型)并且透過iteration做到Model的測試訓練以及版控，不過上一篇也遺留了一個問題，怎麽看目前的Model是好還是壞？

這裡面就牽扯到了一些數學概念，因此在這一篇將介紹怎麽評判一個Classifier Model是好還是壞，透過Confusion Matrix以及Precision和Recall來瞭解一個Classifier Model的情況。

在上一篇([28]整合Custom Vision到chatbot - 拍照就可以識別價錢)把Custom Vision Training好的Model和Chatbot結合達到了拍照就可以辨識飲料價錢的功能。

這一篇來看看如何透過歷史查詢的圖片持續精進Model，讓他的準確度越來越高，并且透過Iteration做版控避免更糟糕的Model不小心上綫。

在上一篇([27]Custom Vision - 自己的Model自己Train 建立圖片的分類模型)瞭解了如何使用Custom Vision去train一個圖片的classifier模型，并且用了一些測試照片去測試模型的準確度。

是時候把這個功能整合到chatbot裡面了。這一篇將來實作整合進入chatbot的功能并且實現上篇提到的情景 - 透過拍照就可以知道這個飲料是多少錢。

上一篇([26]賦予chatbot OCR的能力 - 加入對發票的功能)介紹完了Computer Vision裡面的OCR服務整合到Bot Builder SDK的程式了之後，來看看另外一個和Vision有關的服務，Custom Vision。

在這一篇將介紹Custom Vision是一個什麽樣的服務，并且如何用Custom Vision來建立一個之後會用到的模型。

在上一篇([25]使用Computer Vision - 如何設定、看文件以及使用REST API測試)看完了如何建立Computer Vision的Key，瞭解如何看REST Api的文件并且用Postman做服務測試。

這一篇將把OCR的功能整合到chatbot裡面，看看實際開發起來是個什麽感覺。

在上一篇([24]圖像識別的服務 - Computer Vision概觀介紹)看完了Cognitive Service 裡面和 Vision 有關的服務，以及Computer Vision的一些簡單的功能介紹了之後，在這一篇將來看看實際上怎麽使用Computer Vision。

這篇將會先介紹如何建立Computer Vision需要的Key，再來用Postman呼叫OCR服務的REST API作爲測試。

在上一篇([23]LUIS管理工具 - luis-api和LUDown介紹)瞭解完了LUIS管理工具之後，基本上文字處理方面的神器LUIS介紹完了。當然，文字相關的處理還有一些服務可以介紹，例如QnA Maker，不過這個在之後的篇幅再來説明。

接下來的篇幅將來看看另外一種越來越常見的輸入方式：圖像。有沒有什麽可以讓開發者處理圖像變得簡單？

這篇先來介紹一下微軟Cognitive Service裡面和視覺（Vision）有關的服務，并且概觀瞭解已經Training好的圖像識別服務Computer Vision，看一下這個服務是什麽并且能夠做到什麽。

在上一篇([22]LUIS管理及維護 - 持續加强app、多人維護、備份以及加入別的region key)看了一些luis.ai的portal裡面提供維護LUIS app的功能，透過web界面這個讓一般使用者可以很容易的進行一些微調。

不過如果從開發者的角度，如果我想要透過script的方式去維護可不可以？然後在定義intent、utterance以及entities的時候是否可以不直接透過web界面就做到？

這篇，將來看看luis-apis以及LUDown這兩個小工具。

在上一篇([21]LUIS深入使用 - 如何在Bot Builder SDK使用entities)介紹完了如何在程式碼裡面使用LUIS截取的Entities之後，基本上LUIS的設定以及和程式碼如何搭配使用就基本上介紹完了。

程式最困難不是在開發，而是上綫之後的維護，LUIS的app也是如此，怎麽樣讓LUIS的app越來越好是接下來幾篇要介紹的部分。

這篇先從四個部分開始：依照使用者輸入内容來加强app、如何使用不同region的LUIS、多人維護 app和備份/匯入 app。

在上一篇([20]LUIS深入使用 - 定義Entities來截取參數)看完了如何定義entities之後，在這篇將來看看如何把定義的entities在程式裡面使用起來。

這一篇將先從加入訂房的intent，并且會依照使用者輸入的内容解析出來的entities作爲初始的表單值。

一起來看看如何在程式使用entities。

上一篇([19]把LUIS和Bot Builder SDK整合)看完了如何把LUIS model發佈出來并且在Bot Builder SDK怎麽整合在一起之後。

接下來在更深入的看看如何把LUIS使用到最大化。先從Entities開始介紹起。

在上一篇([18]在LUIS建立app - 概念變成實作)看完如何建立一個app，然後定義intent以及utterance。

這篇將來看看如何把上篇建立好的model發佈出去，并且用在實際的程式裡面。這篇將整合LUIS建立出來的Model到目前的chatbot裡面，讓chatbot的判斷不再是呆板的if else。

在上一篇([17]語義識別服務 - LUIS概念介紹)介紹完了微軟的語義識別服務LUIS的概念之後，在這一篇將把理論變成實作。

來看一下怎麽實際建立出一個符合目前chatbot的模型。

在上一篇([16]Bot Builder SDK開發總結 - 下一步是搭AI服務)快速的總結了目前爲止的内容以及接下來的重點，Cognitive Service的AI服務包含的内容。

這篇將來看看最會被用到的服務，語義識別的AI 服務 LUIS的基本概念介紹。

在上一篇([15]上綫 - 透過Direct Line把chatbot和任意程式做連接)介紹完了Direct Line Channel之後，Azure Bot Service 和 BotBuilder 搭配開發chatbot的部分就到了一個尾聲。當然，裡面還有很多細節可以介紹，但是以目前介紹的内容來説，要開發出一個能用的chatbot已經不是什麽問題。

那下一步是什麽？在介紹Bot Builder SDK的過程會發現，開發chatbot其實蠻死板的，有沒有辦法讓他更加智能一些？如果搭上最近幾年很火的AI服務就可以。

這篇將快速回顧一下目前Bot Builder SDK所學到的内容，以及下一步如何搭配AI服務來增加可用性。

在上一篇([14]上綫 - 把facebook粉絲頁和chatbot接上)介紹了如何把chatbot和Facebook Messenger做了連接。bot channel registration還有好幾個内建的其他channel可以設定做關聯，至於怎麽設定可以透過google的方式去找到相關資料，因此其他内建的channel 這邊不在做介紹。

不過，雖然任意網站可以用web control channel來連接，并且有些内建的channel，可是如果想要在不是内建的channel關聯chatbot怎麽辦？舉例來説，如果今天想要和Line關聯或者微信怎麽辦？或者如果想要在任何程式和chatbot 做關聯？

這就是Direct LIne Channel的目的，只要可以用程式來控制，那麽就可以透過Direct LIne Channel來和chatbot關聯。

這篇將會透過開發一個console程式和chatbot程式溝通。

在上一篇([13]上綫 - 開啓web control channel)看了如何開啓web control的channel，透過iframe讓chatbot可以在任意網站出現。

這篇將看看如何把chatbot和別的平臺的聊天工具整合，這邊將介紹内建有支援的channel，Facebook Messenger。

透過上一篇([12]準備上綫 - 用Bot Channel Registration注冊chatbot)，chatbot已經和bot channel registration設定好了，可以上綫了。

接下來需要做的就是設定對應的channel。

這篇將來看看最容易的channel，web control。看如何取得相關的資訊讓chatbot可以在任意網站上面出現。

在上一篇([11]準備上綫 - chatbot發佈到Azure App Service)介紹了如何用visual studio把chatbot部署到了Azure的PaaS服務，App Service。

這一篇將來看另外一個部分，也就是如何把chatbot和不同的channel連接在一起的服務，Azure Bot Service裡面的Bot Channel Registration (以下簡稱Channel Registration)。

在上一篇([10]用IDialog全部重構 - 階段性總結)我們把所有的程式用Dialog重構了之後，對於chatbot開發暫時到了一個段落。當然，目前功能還非常的雛形，但是以目前介紹的東西已經足夠寫出一個好的chatbot，因此各位可以自由發揮。

接下來我們要開始看看上綫的部分。當chatbot開發完了之後，該怎麽讓他上綫？需要搭配什麽服務。這篇將會看第一個部分，把chatbot先host在azure的app service上面。

在上一篇([09]使用IDialog來實現SoC)介紹了怎麽使用IDialog來拆分邏輯，并且一步一步的用取得名字的邏輯拆成為一個NameDialog。

在這一篇我們將會把所有的邏輯重構成爲IDialog，并且對於目前學習到的Bot Builder SDK做一個階段性的總結。

在上一篇([08]如何微調FormFlow讓使用上更流暢)介紹完FormFlow之後，我們需要回來看一下目前最大的問題，也就是程式碼都寫在一隻RootDialog裡面。

Bot Builder SDK有考慮到這件事情，因此内建用IDialog來解決這個問題。

這篇來看看IDialog怎麽做到SoC (Seperation of Concern)。

在上一篇([07]使用FormFlow讓Chatbot搜集表單資訊更容易)我們瞭解了如何透過使用建立Model然後搭配FormFlow的方式讓我們的chatbot可以從使用者那邊搜集到表單類型的資訊。

不過我們也開始遇到一些問題，舉例來説，欄位名稱是英文，如果中途退出就gg了等等的細節問題。這些問題需要我們對Model或者FormFlow建立的時候做一些調整。

這篇將和大家介紹一下，如何做這些調整。

在上一篇([06]不只能輸出文字 - 看看各種内建卡片模式以及可自定的Adaptive Card)介紹了如何透過Rich Card把bot輸出的内容變成更加漂亮的卡片樣式。

到目前爲止，所有的邏輯都在一起，作爲開發人員會開始覺得程式碼已經開始有些味道了（smell）了。如果今天我們想要透過交談對話中取得一些使用者的資訊，例如填寫表單，那可以想象要寫更多的if/else來處理。感覺程式碼會更加臟。

還好Bot Builder SDK在表單類型的溝通有一個模組叫做FormFlow，在這一篇將來介紹如何使用FormFlow來設計從使用者收集資料。

在上一篇([05]深入IDialogContext - 處理上下文、對外的聯係和state)看了IDialogContext的作用以及如何用3個主要作用的state的部分來儲存使用者相關的訊息。

到目前爲止我們的機器人回復的内容都是文字。如果今天我的内容比較豐富，例如有圖片+文字怎麽辦？有沒有更好的呈現方式。

這篇將來看看Activity裡面的Attachment搭配Card呈現多元樣式的概念。

在上一篇([04]瞭解Bot Builder SDK的組成)完整看了EchoBot的程式碼組成，并且瞭解了Bot Builder SDK一些常見的物件。并且依照所學調整了部分程式碼。

這一篇將會聚焦在其中一個管理上下文以及對來連綫的物件IDialogContext。

在上一篇([03]建立第一個chatbot - EchoBot)透過使用Project Template建立出一個EchoBot出來，并且透過了bot emulator瞭解了如何和chatbot做測試。

這篇將會深入一些，看看Bot Builder SDK的組成以及一些比較重要的class。

在上一篇([02]微軟的Bot Framework是什麽？)以一個high level的角度看了微軟的Bot Framework的CaaP解決方案，接下來就要看看細節的地方。

這篇將會以建立一個chatbot的hello world來看看開發chatbot會用到什麽工具，并且整體的感受是如何。

在上一篇([01]開篇 - CaaP是什麽，爲什麽應該學)瞭解了下一個時代的操作模式：CaaP (Conversation as a Platform)，那麽微軟的解決方案是什麽？這個解決方案的架構是什麽？

這一篇將會從high level的角度來看看微軟的整體解決方案，Microsoft Bot Framework。

Chatbot (聊天機器人) 并不是一個新奇的東西，從微軟2016年的build大會提出了CaaP (Conversation as a Platform)的概念之後，并且出現了Bot Framework，在2017年的時候在台灣火紅了一段時間。

那個時候我雖然知道，但是并沒有很深入去理解過，其中一個很大原因我個人覺得是被聊天機器人這個詞以及一些電商平臺的智能客服給誤導了。

但是當我實際深入進去看的時候，我發現微軟提出CaaP不是沒有道理，因此有了這個系列的文章出現。

學東西都有成本，爲什麽要學并且這個系列會有什麽内容，將會在這篇像大家介紹。