bot framework

在今年參加DevDaysAsia 2019的時候，一不小心就推坑了公司的幾個夥伴參加了微軟Teams的Hackathon。

小弟我其實從來沒有參加過Hackathon，所以也是一個非常有意思的體驗。

這篇快速記錄一下做了什麽，以及一些參考資源讓大家如果對於Teams有興趣可以去玩玩。

在上一篇([09]使用waterfall建立表單式填寫)介紹了使用watfall的方式達到建立一個表單式搜集的chatbot。

裡面爲了簡化把取得姓名的部分暫時拿掉了，但是在實務上不同邏輯的dialog可能會存在，那怎麽辦呢？

這篇將介紹透過Dialog來做Branching以及Looping。

在上一篇([08]改用TextPrompt詢問使用者姓名)使用TextPrompt來取得使用者的姓名，感覺起來好像和自己維護狀態沒什麽兩樣，因爲還是需要透過if else來呼叫。

這樣Dialogs還有意義嗎？

這篇將會介紹另外一種使用情景，有時候需要搜集使用者的資料，例如説他要訂房的話會需要搜集他要訂什麽時間，住幾個晚上等等，這個時候Dialog就變得更加方便。

這篇將介紹如何透過waterfall來達到這個效果。

在上一篇([07]Dialog - 控制流程的元件介紹)介紹了Dialog的原件之後，接下來就是要實際使用看看是什麽感覺。

這篇先用最基本的TextPrompt，看看如何簡化詢問姓名的邏輯。

在上一篇([06]使用BotState儲存使用者的相關信息)透過ConversationState記錄狀態的方式，來控制整個對話流程，然後透過把使用者信息儲存在UserState達到可以記錄每個使用者的個人信息。

開發當然可以透過這個方式繼續做下去，但是一個問題就冒出來，簡單的流程用這種方式當然沒問題，但是當流程很複雜怎麽辦？是不是變成需要自己建立一個機制能夠知道目前在整個流程的那個部分？

這個問題肯定Framework有考量到，那這個機制是什麽？作爲開發者怎麽使用呢？

這篇將介紹V4裡面的機制，Dialog。

上一篇([05]搞懂Bot的State Management - 怎麽儲存信息)看完了一堆理論了之後，相信對於整個V4的BotState有個比較清楚的概念 - 爲什麽要用Accessor，整體的串接以及需要哪些原件。

這一篇將在加深這個部分的印象，如果Bot能夠記得使用者的姓名將會給一個不同的使用者體驗。

看看怎麽在UserState裡面儲存内容。

在上一篇([04]瞭解EchoBot的程式碼結構)看了整個EchoBot的骨架之後，相信對於整個Chatbot的撰寫有了一些基本的概念了。

接下來要做的就是進入細部看細節。看看每一個環節實際怎麽撰寫。

先從State開始，如果説Bot沒辦法記得使用者的習慣以及設定，那麽整個使用體驗會很差。舉例來説，如果沒有state，那麽每一次都要問使用者的姓名，就太笨了。

這篇來看看V4裡面的Bot State Management。

在上一篇([03]搞懂關鍵字以及信息的處理流程)瞭解了整個V4版本的關鍵字以及信息是怎麽流動。

這篇來看看實際code的結構 - 使用之前建立出來的EchoBot，看一下整體的結構。

在上一篇([02]建立第一個V4 Chatbot - EchoBot)看了如何建立出一個Hello World等級的Chatbot：EchoBot并且使用了Bot Emulator對他做了測試，看起來也沒什麽問題。

那麽下一個問題就來了，Bot Framework到底是怎麽組成的？整個信息的流是怎麽動起來？

這篇將來介紹Bot Framework裡面用到的一些關鍵字，以及整個是如何搭起來，未來不管是在看文件還是深入研究才不會搞得糊里糊塗。

上一篇([01]開篇)快速的介紹了這個系列的目的以及内容。

這篇就來實際看一下建立一個V4的Hello World Bot，EchoBot，看看如何建立并且怎麽透過Emulator做測試。

還記得沒多久之前介紹的另外一個系列(「chatbot + AI = 下一代操作模式」)，那個時候介紹了新一代的操作模式俗稱的Chatbot，以及看Chatbot結合Cognitive Service這種AI API所帶來的另外一種使用者體驗。

那時候因爲V4還在Preview，所以介紹了使用Bot Framework V3(準確一點說是Bot Builder SDK V3)。

而V4在9月底的時候正式發佈GA了(進入Stable)，因此有了這個系列的開始，來看看V4改變了什麽。

在上一篇([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的開發。

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

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

在上一篇([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。

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

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

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

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

在上一篇([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。

在上一篇([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不是沒有道理，因此有了這個系列的文章出現。

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