.NET Walker

如果你實際開發過Chat bot，就會發現NLP(自然語言分析)本身就是一個很大的問題，即便現在有LUIS可以幫助我們做語意分析，但實務上分析結果要100%符合用戶(或開發人員)的心意不是易事，倘若可行，在商務應用時，Chat bot與用戶之間的一問一答對談，想要提高可用率，讓用戶以選項的方式回答還是比自然語言對談來的好很多。 舉例來說，在 上一篇 我們介紹的CIC類別當中，如果我們的chat bot要問用戶要請哪一種假別，與其讓用戶自己回答，不如讓用戶用選的乾脆一些。 原本對談的設計是: 但這風險很高，因為我們開放用戶自己用輸入的方式回答。 如果用戶偏偏要回答: 我今天想請事假     或 請婚假     或 什麼根本沒聽過的假… 對Chat bot來說都要做自然語言分析，就算分析的再正確，在開發上難度也提升不少，但如果用底下這樣的ButtonsTemplated Message詢問用戶，用戶只能在底下的選項中擇一回答，那就容易多了: 上一篇 說過，我們要透過繼承自ConversationEntity的LeaveReuqest類別來處理這對話邏輯，而這一版我們加上了支援ButtonsTemplate Message，你只需要使用ButtonsTemplateQuestion這個Attribute即可(注意第3行): 我們新建立的這個LeaveRequestV2，跟上一篇的LeaveRequest很像，但第一個詢問假別的問題，改用了ButtonsTemplateQuestion Attribute(注意，你必須把LineBotSDK升級至 0.5.7-beta )，程式碼就只需要做這一個小小的調整即可。 由於加上了ButtonsTemplate Message，chat bot WebApi Controller主程式碼也小幅修改一下: 只需要配合ButtonsTemplate Message在59-59行針對CIC的Process result，取得ResponseButtonsTemplateCandidat(64行)進行Reply即可。 其他的程式碼跟上一版幾乎完全一樣沒變。 而24-29行只是加了一小段判斷，規定用戶只能選擇事假、病假、公假其中之一…純粹只是寫著玩測試一下。 執行這段對話之後，chat bot可以蒐集用戶的回答，結果如下: 想要在Conv

開發對談機器人，一直有一個很關鍵的議題，就是如何處理連續性的對話。 這個問題，上課時學員問過、研討會時聽眾問過、公司同事問過、客戶問過、學校老師問過、差不多連路人甲(我是說對開發chat-bot不熟但剛好聽到chat-bot開發的路人甲)都很關心… 舉例來說 舉一個典型的例子，如果我們要開發一個聊天機器人來處理請假，那這對話大約是底下這樣： 請注意用戶開始跟chat-bot說：『我要請假』之後，chat bot進入了一個連續對談模式，在這個連續對談模式中，chat bot以一問一答的方式，跟用戶蒐集請假資訊，依序詢問用戶請假假別、代理人、時間…等資訊。 最後，蒐集完所有資訊之後，進行請假動作(上面的例子是以JSON方式把蒐集到的資訊顯示出來，沒有真的請假，但意思到了)。 需求就是這樣。這有什麼難的?  其實，還真的不很容易。 首先，如果你不想把程式碼寫死，想用同一套框架或邏輯來處理同性質的會話(conversation)，這本身就有不低的難度。其次，每一個一問一答的對談之間，由於是同一個WebHook來處理的，因此要記錄狀態(state)，諸如:這次問的是什麼、用戶回答的答案是對應到哪一個問句、目前的交易是屬於哪一個用戶…，這是第二層難度。 接著，用戶回答的型別如果不符合? (例如問’請假時間’，結果用戶回了一句’事假’) 該怎麼辦?  還有，就算用戶回答的資料型別正確，但邏輯上不合理(例如代理人用戶寫Tom，但公司就明明沒有Tom這個人)，又該怎麼處理? 想起來，如果chat-bot要寫這種會話對談，將會是一段很恐怖的程式。 但，我實在被問過太多太多太多次這個問題了，因此，索性，找了一個心情很差的周末，我嘗試寫一個能夠處理這樣對談的框架。 怎麼用? 假設，你要處理上面這樣的對談，你可以建立一個類似底下這樣繼承自ConversationEntity的類別: 先別指摘我上面這個範例中的類別怎麼會用中文當屬性名稱，這是故意的。這是為了讓讀者更好理解，正式環境你當然可以換成英文。 但，這類別真的很好懂，是吧? 這類別表示了『請假(LeaveRequest)』這個對話將會有五個問句，第一句是問用戶『請問您要請的假別是?』，用戶回答的結果會被放入『假別』這個屬性中。第二句是是問用戶『請問您的代理人是誰?』，用戶回答的結果會被放入『代理人』這個屬性中。 其他的應該不需要解釋

這幾年做教育訓練、顧問服務、和系統導入，發現一件有趣的事情。 有幾次碰到一些客戶(有商業公司、非營利組織、學校…都有)，在開會或課程之後私下跟我說，希望我們在提供建議的時候，可以『直接』告訴我們的team member，這件事情該怎麼做，而不用花太多時間告訴我們這些事情的原則，或是背後的邏輯或原理。因為team member只需要快速地得到答案，加上事情很緊迫，他們也沒有時間去學，說多了徒增困擾(這句話有個潛台詞，建議讀者細想，很有趣…)，顧問(講師)直接告知做法之後，我們就可以比較快進入下一個問題(議題)。 可能有人看了上面這段話不明白意思，我舉其中一個比較具體的例子。 有一次碰到一個軟體開發的資安問題，我花了幾個小時解釋為何程式碼這樣寫不行，為何這有可能帶來風險，從這樣的程式碼我們可以得知外包的開發人員應該有哪些問題…，幾個小時下來，我發現，客戶唯一關心的事情只有一個: 那現在這行程式要怎麼改? 直接告訴我就好。 至於其他的，大夥兒絲毫不在意。 這類的例子最近層出不窮。由於樣本數雖然多但我沒徹底研究，因此目前我無從取得確切的證據，證明背後的原因是什麼? 但推敲之後，能猜個大概。 可能是因為這年頭大家都很忙，碰到問題，只想快速知道答案。而網路的便利性讓許多人變成只願意(也似乎可以)迅速的取得結果，久而久之，慢慢地不願意也沒耐心花太多時間深入理解問題背後的成因。 也就是說，大家並不真的在乎(到願意付上代價、例如時間)來面對問題、或學習解決問題的能力。 許多人變得只想知道，當下眼前這問題怎麼解決。 『告訴我解法就好，其餘的我不想多知道。』似乎已經是網路速食時代的寫照。 這是最近幾年碰到的，以往，大概十年前，這情況比較不常發生。但不用我說大家應該也知道，長久下來這(對企業、或團隊)會導致什麼結果。 再加上，網路時代很多流傳文章，標題長這樣：『OOO的原因原來是XXX』、『解決XYZ的N種方法』、『想要OOO就得XXX』這類的文章都很紅。標題看似一針見血，但內容往往很武斷。大部分的文章(或課程)中提出的見解或解決方案，其實都隱含著一個假設前提，就是你的環境和他(作者)相同，然而你也知道，真實世界中哪有環境都相同的? 礙於篇幅(也礙於其實讀者也沒興趣知道)，因此大多數文章的作者，也不太會詳細敘述案情的成因與環境的背景，導致部分憨直的讀者以為，我照著做就會有一樣的結果，其實不

在用戶與你所設計的Linebot對談的過程中，我們常常會需要接收用戶傳遞過來的資料，除了文字之外，最重要的就是圖片(或照片)了。 用戶可以從手機或PC版的Line上面，輕易地上傳圖片給我們的linebot，這圖片來源可以是直接抓取相機拍照的照片，或是從手機上的相簿、圖庫裡面抓取，當然也可以從第三方的資料來源(像是Dropbox)把圖片傳遞給Line。 因此，圖片會有各種不同的格式，但慶幸的是，Line會幫我們把圖片做初步的處理(例如對太大的圖進行縮小、調整格式…等)，我們想要抓取處理好的結果，只需要簡單的使用API即可。 透過我們的SDK，可以輕易的使用底下這個API來取得用戶上傳的圖片，回傳的結果是bytes[] 陣列。 當然，從上面你不難發現，要取得圖片時，我們需要傳遞給API一個ContentID參數，這參數怎麼來呢? 透過這樣的方式，就可以順利的取得用戶上傳的圖片資料囉。 補充一: 別忘記一件事情，我們並不能假設用戶上傳的一定就是圖片(搞不好是文字?或是GPS座標位置啊…)，因此，採用上面那兩段程式前，你必須先判斷，用戶這次傳遞給我們的訊息是否為圖片: 補充二: 抓到圖片Bytes後，要怎麼辦? 一般來說，我們會在WebHook裡面抓取圖片，而WebHook在.net多半是以WebAPI的方式撰寫，因此，在你抓取到圖片Bytes之後，會有幾個考慮。 該圖片要不要讓其他系統使用?(例如azure影像辨識API，或是後端其他系統) 如果要，你多半需要把Bytes儲存為實體的檔案，這部分可以透過  System.IO.File.WriteAllBytes(路徑, bytes); 這樣的Method來完成，如果是圖檔，附檔名直接給png即可。 該圖片要不要讓用戶下載? 如果要讓用戶下載，則該圖檔不僅僅要儲存，還必須要有一個可公開的URL，這樣我們會建議你把圖檔存放到azure blob，或是在你的WebApi所屬網站上開一個folder，用上述WriteAllBytes指令存檔時，儲存到該公開folder中即可。當然，如果你要把圖檔放到資料庫中也行。 ------------------ 相關課程: http://www.studyhost.tw/NewCourses/LineBot LineBotSDK : https://www.nuget.org/

今天去剪髮，幫我剪髮的設計師和我認識了20多年(很神奇吧)，從她年輕的時候年輕的我就讓她剪髮，到現在，20年，在同一家店。 也因為如此，我每回去剪髮的時候，都會回想起20年前的自己，今天我想的是，20年前的自己和現在的自己，在意的事情有哪些不同? 我問她，她覺得自己這20年有何改變? 她說:『沒有啊，我沒想過這個問題。』『我從來都不會想這些奇奇怪怪的事情…』 我微笑『這樣很好啊...日子單純多了。』我說。 她回答:『對啊，反正想了也不會改變什麼，那幹嘛想?』 『你知道嗎?』我想起來。『有一本暢銷書，花了很長的一段篇幅，在告訴人們，多花點時間關注自己能改變的事情，而不要花太多時間去憂慮自己無法改變的事情上。』 她聽了笑著說：『這也要寫一本書跟大家講? 既然自己不能改變，那花時間去想幹嘛呢? 愈想愈煩悶而已。而且，花在這樣的事情上愈多時間，不就愈沒時間去做自己能改變、能帶來影響的事情嗎?』 『是啊，不過...』我說：『有時候這就是人的本性，雖然理智上知道，該專注在自己能施力、能造成影響的事情上，但大多數人總是對那些自己無法改變的，像是政治制度、經濟、疾病、外在環境、輿論、他人的看法...這些事情上，花了太多的時間，卻總是忽略了、或放棄去經營自己能造成改變、能發揮影響力的地方。』 『好在我沒這個困擾，可以洗頭囉...』她說。 洗頭的時候我在想，這個道理我十年多年前從書上看到，但一直到現在，這十多年來，我真的專注在自己影響範圍的事情又有多少呢? --------------------------------------- ref 1: 關切範圍 & 影響範圍 ref 2: The 7 Habits of Highly Effective People ref 3: How to stop worrying ＆ start living