ai

在上一篇([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改變了什麽。

在上一篇([12]人臉識別的AI服務 - 用Face API Explorer看看Identify的應用)介紹完了Face API Explorer裡面的Identify功能之後，這個系列就已經到了一個尾聲。

雖然說并不是所有的Face API方法都有介紹，但是相信就算要使用的話，因爲有了其他方法的介紹做基底，要理解應該不會太難。

這篇將會對這個系列有介紹的服務做一個統整的介紹（像是一個目錄），并且留下一些參考資料。

上一篇([11]人臉識別的AI服務 - Identify 找出圖片的臉是誰)介紹完了如何透過Identify的方式找出圖片裡面的臉是屬於那個人之後，這個系列要介紹Face API的服務就差不多告一個段落。

介紹純API的呼叫是看看最底層的用法，當整合到Application裡面，用途就多了。

這一篇將用Face API Explorer這個工具，看看在裡面是如何整合Identify的功能。

在上一篇([10]人臉識別的AI服務 - Verify 驗證臉是不是屬於某個Person)介紹了PersonGroup train出來的Model的其中一個用途，也就是用來確認某個臉和某個person是否為同一人。

這一篇來看看另外一個用途：identify，也就是直接從臉找到是誰。

在上一篇([09]人臉識別的AI服務 - Face Api Explorer - GUI工具來建立Person Group Model)介紹完了Face Api Explorer這個工具之後，相信在建立PersonGroup Model就易如反掌啦。

建立好了Model，下一步當然是看如何使用這個Model。

總共有兩個方法：

1. Verify - 比對臉是否屬於某個人
2. Identify - 看看臉可能是屬於那個人

Verify之前介紹過([06]人臉識別的AI服務 - 使用Verify確認兩張圖片的人臉是否為同一人)，不過那個時候是兩張臉比較，這篇介紹一下如果拿人比較如何使用。

2018-10-05 Friday
「Cognitive Service之Face Api」 cognitive service ai azure face-api

在上一篇([08]人臉識別的AI服務 - 建立自己人物的臉Model - 瞭解PersonGroup、Person以及Face的概念)介紹了PersonGroup、Person以及Face之間的關聯，并且透過用直接呼叫API的方式建立出了一個myFriends的Model，下一步就是要看如何使用這個Model。

不過在進入如何使用這個Model之前，肯定是要先把Model Training好用起來才好用。但是要透過Postman一個一個建立Person以及加入Face有點不方便，尤其是看不出來目前那些person有哪些face （上篇沒有介紹取得的API，但是是可以取得建立的信息，但是畢竟都是文字看起來還是不容易看）

難道沒有GUI的界面嗎？這邊就來介紹一個大大所建立的Open Source專案，Face API Explorer。

在上一篇([07]人臉識別的AI服務 - C#整合Verify驗證兩張圖片的人是否同個人)介紹完了Face Api裡面的Verify功能，在介紹這個Api的時候遇到了其中一個呼叫方式的參數叫做personGroupId。

這個Person Group Id只得是什麽呢？如何建立呢？

這邊來看一下在Face Api裡面的Person Group、Person以及Face的概念，以及如何呼叫API來建立這些概念。

在上一篇([06]人臉識別的AI服務 - 使用Verify確認兩張圖片的人臉是否為同一人)介紹了如何使用verify這個功能來驗證兩個人臉（faceId）是否為同一人。

這篇將來看看再C#裡面如何呼叫verify這個方法。

在上一篇([05]人臉識別的AI服務 - 使用Python框出圖像裡面人臉的部分)看完了如何在Python裡面呼叫Face Api裡面的Detect服務，并且把圖片裡面的人臉部分用紅色框起來，然後把年紀用藍色列在了頭像下面，基本上識別相關的服務就介紹到這邊。 剩下的應用就是看想象力了。

能夠識別圖片裡面的人臉只是服務的一部分，另外一個常用情景是，能不能識別人臉是不是屬於同一個人？這種類型的應用非常的多，例如環安裡面當是同一個人門要開啓就可以使用到這個服務。

這篇來看看如何使用Verify這個服務，看看如何呼叫，并且回傳的内容是什麽。

在上一篇([04]人臉識別的AI服務 - 整合Face Api的Detect功能到C#程式裡面)看完了如何用C#呼叫Face Api取得圖像裡面人臉的資訊并且印在console上面之後，這篇連看看另外一個使用情景。

Python是一個最近很火紅（或者説一直以來都很火紅）的一個語言，可不可以用Python呼叫Face Api？

這篇來看看如何用Python把圖像裡面屬於人臉的部分框起來。

在上一篇([03]人臉識別的AI服務 - 用Postman測試Detect服務能做什麽)透過使用Postman的方式瞭解了Face Api裡面的Detect服務的所有功能之後，接下來就是要看看如何在程式裡面使用Detect服務。

這篇將使用C#搭配.NET SDK來看看在程式裡面呼叫Detect有多麽的簡單。

在上一篇([02]人臉識別的AI服務 - 要使用Face Api的準備)介紹完了要使用Face Api所需要準備的東西之後。

這篇來實際看看Face Api裡面的Detect服務能夠做到什麽。

在上一篇([01]人臉識別的AI服務 - Face API能夠做什麽？)介紹了什麽是Face Api，以及Face Api能夠做到什麽事情。

接下來就是要看看實際上如何使用Face Api。

Face Api是微軟的Cognitive Service(認知服務)Vision(視覺)裡面的一個服務。

最主要的目的是用來處理和人臉識別有關的AI功能。

這篇從Overview的角度來看看Face API能夠做什麽，然後這個系列會介紹什麽。

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

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

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

在上一篇([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服務來增加可用性。

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

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

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

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

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

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

這麽多年以來，參加活動有以學員的身份、講師的身份及現場工作人員的身份參加過活動，但是還真沒有以擺攤的身份參加過。

因此這篇更多是在周邊的介紹，話説這個應該是我見過免費裡面最大手筆的一次活動，主辦單位很用心，一起來看看吧。

在5/21的時候在北京剛舉辦過的微軟人工智能大會在今天深圳也舉辦了一次。上次北京沒參加到，這次在深圳當然要去學習學習。

這篇記錄一下今天發生的事情。