2018年12月13日 星期四

使用Dailogflow建立APS Q&A聊天機器人

前言
Dialogflow(前身為Api.ai)被google買下並開放給一般用戶,本身服務為處理NLP的自然語言
處理引擎,包含理解上下文會話的能力。
講白點其實就是聊天機器人(chatbot)的後台,目前比較耳熟能詳的服務例如Siri,卡米狗,google
助理等,其它像是淘寶文字客服,FB,Line,Skype等聊天機器人都算是此類的應用,大家應該都不
陌生。
那要怎樣建立聊天機器人? Google下會發現有非常多的Open Source的程式範例可參考,
前提是你需要寫程式,不管是後台前台都要。
那Dialogflow可以幹麻? 他可以允許用戶不需要寫程式就建立NLP引擎,只需要在網站上
建立多組QA,即可設計出屬於自己的交互式交談服務。

Dailogflow的基本組成:
Intent:使用者的意圖。
Entity:語句關鍵字。
Fulfillment:通過設置webhook,串API完整你設置的服務。


讓我們開始吧!
打開Dialogflow網站,新增一個agent命名為APSQQ,如下圖需要設定預設語言與時區。
我們會使用google提供的agent打造一個交談式服務,提供用戶問答並回饋基於業務規則的
回覆給用戶。







服務機器人流程圖
我們希望agent提供回覆訂單為何會遲交的原因? 假設用戶會問『請問訂單規劃交期為何?』,
『可以問訂單遲交原因嗎?』,『訂單遲交分析?』等,可以發現一個問題可以用很多種方式
表達,但是可以發現這些表達的語句都有相似的名詞在其中,這些名詞就是Entity
我們可以抽取entity為訂單及遲交兩個名詞,抽取的動作仰賴於業務規則,很需要人的domain know-how

先建立[訂單]的entity,如下圖,同時要定義訂單的相關同義詞(小技巧:可以用google翻譯
取得同義詞)


建立[遲交]的entity



接著建立Intent(意圖)
在Training phrases可以輸入用戶可能會問的語句,最好可以提供10~20組讓Dialogflow可以
學習,這邊要特別說明,交談式問答每個問題都算是一個Intent,其實滿囉唆的。
下圖中可以看出『可以幫我查訂單的遲交原因嗎?』, Dialogflow會自動標示其中對應的entity,
這些entity可能是我們自己建立的(如訂單,遲交原因),也可以是系統內建的,
像是時間,日期,區域等。

有標示到的entity會出現在Action and parameters區塊,這些parameters會傳遞給後台處理,
等於用戶用自然語言問的問題其實會拆解成intent+parameters給後台,會寫程式的人看到這邊
應該就知道是怎麼回事。



接著建立Intent對應的回覆(Responses)
預設提供文字回覆,也可以使用Custom payload自訂回覆的內容(Json格式)。
如下圖,這邊我們只需要回覆『請提供訂單單號』文字即可,在圖中還可以看到
set this intent as end of conversation是指此回覆後是否就結束整個交談。


接著建立提供訂單單號後的下一個交談(Intent),如下圖紅框。


可以看到此交談是期待用戶提供訂單單號,所以這邊要解析可能的訂單單號格式,如下圖提供
很多種不一樣格式供後台識別。


上面每個輸入的單號都要辨識為order_number(parameter),有時系統會辨識錯誤,像是
打12345678就會辨識成內建的號碼,這時可以手動辨識(更改)為order_number,可以看
到上面輸入的單號都是粉紅色底,表示都是辨識為同一個order_number。


這個Intent我們期望後台可以回覆訂單遲交的原因,很明顯後台必須根據傳入的
參數(order_number)查詢資料庫,然後回覆結果。文字回覆的內容無法滿足這項需
求,所以要改程式處理,Dailogflow提供Fulfillment可以讓你在線上寫程式(Node.js)
回覆結果,也可以使用外部網站提供的Webhook做這件事。這裡我們選擇用線上寫程式。


我們在FireBase(google提供的雲端資料庫)建立測試資料,如下圖


Fulfullment的線上編輯器如下圖,根據用戶提供的訂單單號查詢資料庫後回覆結果




模擬交談示意圖

2018年11月19日 星期一

OptaPlanner可以做什麼?


OptaPlanner可以做什麼?

網址:https://www.optaplanner.org/

在用戶定義的規則限制條件中,基於約束的限制,對被規劃對象進行排列組合,再對比各個組合(稱作解,或方案),並找出相對最優的解出來。
  • 生產排程
  • 路徑規劃
  • 人員排班
  • 裝箱問題
是一個計算引擎(lib)。
可以100%相容於java程式。
open source(可商業用)

 以下為簡單的說明簡報

2018年10月11日 星期四

3D裝箱問題

3D裝箱問題


最近遇到一家客戶的集批設備必須考慮容積限制,所以順便google下原來這有專
有名詞叫做裝箱問題(3D BIN Packing)。git上也有不少這類的程式,也看了不
少paper,最多應用的paper都是船舶貨櫃業,想一想也是,多裝一個櫃成本多
很多,才會衍生求解此問題的價值。

最後在google上找到一個神人用excel寫的,還附帶用excel話的3D圖(超屌)

以下是程式大概的邏輯

應用演算法:large neighborhood search

1.先排序itemtype,排完一種後再換一種堆疊

2.Itemtype要先依照可堆最多個原則選擇擺放哪一面(考慮6個面)

3.考慮長寬高,重量限制,某item與某item是否可在同容器的限制

4.效益高的item先放,成本低的容器先選

5.迭代:跑機率一半從最佳解開始變形,一半從目前解開始變

這個演算法針對特定行業問題有優勢,因為可以運用行業domain寫業務邏輯
再加上版身演算法的迭代求解過程通常可以找到不錯的解。

題外話,測試時發現一個簡單的問題100個A,100個B,如果箱子全部用A可以得
到最佳解,但只要混了B就有機率填不滿容器(箱子),這是此演算法的特性,
他會從目前的解一直變形,也就是說目前的解如果走錯路之後就會一直錯下去。
針對此問題的解法是增加業務邏輯,在迭代求解前先用單一item(A或B)是否
可以得到最佳解,不行再進入演算法的迭代過程。


最後花了3天的時間把exce的code移植成C#版本,畫圖的部份則改用WPF的
3D模型來實作內部有的寫法是因為vba的限制,其實搬到C#可以用更好的寫法,
目前列第二階段再調整

以下是目前的畫面。

這個3D模型也是google找來的,我只修改部份程式碼(丟要畫幾個圖形及座標)

雖然滿足率都是1,但是看圖形可以發現組合不一樣

2018年7月16日 星期一

比特幣是區塊鏈的應用

比特幣是區塊鏈的應用

每個block
    10分鐘內的交易紀錄+前個block的hash值+一個數值(nonce)產生一個hash值(很長)
   
礦工的工作
    找出未被確認的block(只有一個,大家競爭),block內含10分鐘的交易
    要用電腦找出數值(nonce),讓nonce+10分鐘內的交易紀錄+前個block的hash值可以小於dufficulty
    找到後可以廣播把結果給其他礦工核可(除了10分鐘交易外,還有礦工酬勞也一併在此block),
    各方核可後才把該block掛到鏈上
   
平常的交易
    交易通常由礦工的帳本可以檢查付款方是否有足夠的金額給付,檢查過了會放到
    交易池(未被確認的block)交給礦工去計算該block

2018年3月2日 星期五

Read Committed Snapshot與SNAPSHOT isolation差異

SQL2005隔離層級
Read Committed Snapshot與SNAPSHOT isolation差異

Read Committed Snapshot只是Read Committed的進化版本,本質上並一是一種事務隔離層級,
在此模式下select語句並不會等待該row commit,而是直接讀取上一個已經commited的資料
那跟select語句使用with nolock有什麼差異?簡單說nolock一樣不會等待row commit
但是可能取到uncommited的資料(垃圾)。

SNAPSHOT isolation呢
當第一個事務啟動此隔離層級,後續每個事務對同一筆資料讀到的都是當時commited的資料
假設有個值i=10,三個session同時啟動事務
第一個session讀到10,把10給為15,commit
第二個session讀到10,把10給為15,commit,
第三個session讀到10,把10給為100,commit

然後
第一個session commit成功,另外兩個session commit會失敗

為APS產品添加智慧問答助理

  痛點 在現今服務至上環境下 , 即時回覆客戶問題以提升顧客滿意度儼然成為企業、服務業不可或缺的服務之一。但即時回覆問題所需付出成本內、外部分析如下, 如何解決此問題為本報告所要說明的部分。 Ø  因客服團隊人力需求較高且基本工資持續上升,人力資源成本持續上漲。 Ø  排程系統...