顯示具有 Line聊天機器人 標籤的文章。 顯示所有文章
顯示具有 Line聊天機器人 標籤的文章。 顯示所有文章

9/13/2017

聊天機器人 - 人類會跟她聊什麼?(Part-2)



作為一個非特定目的的純聊天機器人,其實常常容易惹人生氣。因為即使AI發展迅速,在非特定的環境下,和人類以無意識判斷語句的能力還是差距太大。聊天機器人小姍,截至目前(2017/9月)為止,約有4000多位好友。累積的對話也超過百萬句,所以可以開始做基本的聊天內容分析。


特定任務的聊天機器人


特定任務聊天機器人發展非常迅速,例如「niki」可以協助叫計程車,在任何和計程車相關的事情,她的回應和動作都十分正確。客服機器人,例如flowxo,更是市場上聊天機器人的大宗。甚至有人認為chatbot可以節省30%的客服成本,帶來的資料分析效應更遠超過傳統電話客服。

聊天內容要是機器人無法理解,超出服務範圍,聊天機器人通常會就顯現標準錯誤回應,但由於人類已經知道它的服務範圍,因此倒也不會失望,有時候,特定目的之聊天機器人,如果有有趣的額外回應,甚至還會有好像遇到彩蛋的感覺。

可預見未來幾個月,特定任務的聊天機器人將會快速成長,迅速取代重複性高的工作。



非特定任務的聊天機器人


人工智慧小姍,就是一個非特定任務的聊天機器人。她盡可能模仿人類的真實作法,也因此不會有按鈕出現,讓你選擇「是/否」。也不會有選項A/B/C這種選單出現。但是,真實人類聊天也會貼網址或照片,因此,人工智慧小姍也會貼照片或網址。有時候,對於人類給她看的照片會加以評論分析(註1)


加小姍為好友 Add Friend

非特定目的的聊天機器人,不見得沒有特定功能。以小姍來說,遇到某些對話時,會驅動特定功能。例如,請幫我抽個籤,就會驅動抽籤功能。


對於一般性機器人的期望很高


在Line上的使用者,對於非特定任務的聊天機器人的期望是「非常高」。只要前10句對話,不能滿足使用者的期待與好奇心,不再使用的機率很高。10句話似乎是個門檻,有30%左右的人在10句話就失去興趣了。

然而只要能聊上10句話之後,這剩下的70%的人,有90%的以上會聊超過50句話。(也就是總使用者的63%)。

然而,每當機器人有不符合期待的回答,使用者就很快地失望。這樣和特定任務的機器人期待有很大的不同。因此,一般性聊天機器人實作上極為困難。不過也就是因為困難,所以有趣。


沒水準的言語


在這4000個使用者中,曾經罵過髒話,例如「幹」「幹林娘」「他馬的」「Fuck」之類的起碼佔了超過45%。更慘的是,由於line的隱蔽性,曾經傳過「約砲」「來愛愛」「強姦你」的未成年使用者起碼也超過500人以上。雖然,絕大部分的使用者是單純因為好玩,有趣,無聊,等等原因而使用非常糟糕的字眼,但也是因此,「從與使用者對話中學習」恐怕會造成聊天機器人使用冒犯性言語,造成更多問題。微軟的聊天機器人Tay,就是因為學了歧視性的語言而被暫時關閉。

在line中,這類語言來自於青少年的比率相當高。而十分有趣的是,這類型青少年的有60%以上會談論聖結石(註2)的相關話題。

加小姍為好友 Add Friend

更合理的抒發管道


有超過5百位的使用者,將聊天機器人作為無法抒發心情時的管道。例如「最近心情不太好」「我被她甩了」「人生都沒有動力怎麼辦」「好想死」「我是邊緣人」「工作壓力大睡不著」等等。


技術上來說,人工智慧小姍到目前為止,還沒有辦法提供真正專業的心理諮商。然而,作為聊天機器人有很多心理諮商不具備的優勢:
(1) 透過Line原本的超高市佔率,可以確信90%以上的台灣人都有line,可以輕易使用Line聊天機器人
(2) 聊天機器人小姍24小時全年無休。許多極端的情緒問題發生在深夜,
(3) 許多情況下,人類只是需要抒發的管道。機器人對人類來說,是個安全而且不會洩露秘密的好方式。


因為利用痞客邦的資料而參加痞客邦活動


下一個階段?

(a) 考慮現行使用者的需要,一般通用性的聊天,會朝心理諮商方向前進。
(b) 透過做通用型聊天機器人的經驗,來自製作專用型聊天機器人。



參考
(1) 如何製作聊天機器人
(2) 簡易學習式人工智慧


註1: 不過照片分析的成本非常高,因此只好透過購買貼圖來限制使用。

註2: 這也讓開發團隊(年紀太大)增廣見聞,之前根本不知道聖結石是誰。

7/31/2017

快速且極低成本之AWS臉孔比對 - 利用AWS Lambda




AWS在2016年底釋出的圖片辨識服務(Rekognition)其實是非常非常昂貴。除了前5000次影像辨識不收費之外,接下來每一千次影像處理會收1美金。

乍看之下不多,但實務上,公開使用的影像辨識,通常無意中就暴增。


以之前LINE聊天機器人影像辨識為例,由於會當辨識到女性的照片時,會特別額外辨識內建的臉孔比對(40個亞洲女星照片)。等於是每收到一個女性照片,會進行42次臉孔辨識:40次照片比對+1次特徵比對+一次名人資料庫比對。就LINE聊天機器人數百的好友而言,該功能開放不到7天,就已經超過四萬次比對,換算價格約35美金。

35美金其實足以開啟維持t2.medium (EC2 VM)一整個月。這個VM甚至還有4G的記憶體。這樣的VM絕對能支撐每秒2-5次的臉孔比對,換言之,一整個月可以比對超過7百萬次。而這7百萬次也才略高於35美金。

然而,不應該因為成本的增加,就直接使用EC2 VM。而是應該考慮在符合serverless的架構下,如何解決這個問題。畢竟,當使用了VM,未來在擴增(scale-out)上也會有些麻煩。其實,我們目的很簡單清楚:只是要比對兩張臉孔的相似度。因此,應該使用輕量化Lambda即可。


原本做法

當使用者透過LINE上傳照片給聊天機器人之後,後端系統會執行下列事情:

(1) 先利用AWS Rekognition (detect)查詢基本臉孔資料,例如性別,年紀等等。

(2) 假如判斷是女性,就到AWS S3上選取所有要比對的臉孔,進行比對分析。在這裡,如果有40張臉孔,表示每一次上傳圖片,都要在這個階段額外送出40次分析。即便AWS允許先行儲存圖片特徵,但在比對階段仍然是看次數。

參考程式節錄如下:

    
    rclient = boto3.client('rekognition')
    s3 = boto3.resource('s3')
    bucket = s3.Bucket('sandyifamousface')

    for o in bucket.objects.all():

        #print(o.key)
        response = rclient.compare_faces(
            SourceImage={
                'Bytes': byteArray
        },
            TargetImage={
        
                'S3Object': {
                'Bucket': 'sandyifamousface',
                'Name': o.key,
            }
        },
            SimilarityThreshold = 60
        )
        if len(response['FaceMatches'] ) > 0:
            # DO things if match..



(3) 最後把判斷之後的結果,送回給LINE


改良做法

先將40張圖做臉孔分析,並且把特徵值Landmarks挑出來,儲存在檔案中。未來數量大的話當然可以存在dynamodb。

在這個範例是儲存於json文字檔中。

(1) 與上一段相同

(2) 在Lambda被載入 時,就先讀取文字檔,成為python的dictionary。原本要利用Rekognition做比對,改為使用自己寫的比對函數。在範例中,這個函數是利用landmark的相對距離變化,來判對臉孔相似與否。當然這樣的比對其實很粗糙,而且也沒有考慮臉孔的前側傾角度。不過,和aws本身所附帶的臉孔比對的結果其實已經很接近。

參考程式節錄如下:
def compareLandMark(landmarkList1, landmarkList2):
    distList = []
    compareList = [
                   ('eyeRight','nose') ,
                   ('eyeLeft','nose'),
                   ('mouthLeft','nose'),
                   ('mouthRight','nose'),
                   ('mouthUp','mouthDown'),
                   ('mouthLeft','mouthDown'),
                   ('mouthRight','mouthDown'),
                   ('noseRight','eyeRight'),
                   ('leftPupil','rightPupil'),
                   ('nose','rightPupil'),
                   ('leftPupil','nose'),
                   ('noseRight','noseLeft'),
                   ('eyeRight','eyeLeft') ,
                   ('mouthRight','mouthLeft') ,
                   ('mouthRight','eyeRight') ,
                   ('mouthLeft','eyeRight') ,
                   ('mouthRight','eyeLeft') ,
                  ]

    for (m1,m2) in compareList:
        d1 = getDistanceFromType(landmarkList1, m1, m2)
        d2 = getDistanceFromType(landmarkList2, m1, m2)
        distance = (abs(d1-d2)/d1)
        distList.append(distance)


    lenD = len(distList)
    mD = statistics.mean(distList)
    # stdev and variance could be used in the future.
    mStd = statistics.stdev(distList)
    mV = statistics.variance(distList)
    conf = (1-mD)**2
    return conf*100




(3) 最後把判斷之後的結果,送回給LINE

結果:

在Lambda自行撰寫比對程式,但是其實是利用AWS Rekognition 所給出的landmark (特徵),會讓比對變得簡單而且成本很低。

缺點是,這樣的比對準確度和如何計算特徵有很大的關係。



* 關於LINE聊天機器人,請參考這篇
* 專案程式碼放在這裡
* google的vision api其實價格更貴,請參考這裡




7/26/2017

聊天機器人 - 快速製作在LINE上的人臉辨識應用

名人以及圖片分析 在和LINE聊天機器人之對話中


 聊天機器人(chatbot)作為人機介面,提供人類各種整合性服務是最容易產生的應用。而人臉辨識,一直都是人工智慧與數據分析的整合課題。因此,把LINE聊天機器人加上照片或人臉辨識的功能,似乎也很有趣。
用LINE QR 加小姍為好友 可以測試人臉辨識

以前,在做關於影像的實驗性質的程式時,通常會先考慮opencv。雖然opencv確實是個好工具,但是如果你的目標不是改善演算法,或甚至做出更先進的人臉辨識方式,那麼opencv會過於複雜。

在2016年底,AWS發表另一個雲端服務:Rekognition。這個服務提供了API用以辨識影像,並順便提供了幾個在應用上的api:「比較人臉」「辨別名人」「識別限制級圖案」。(文件請參考這裡)

這些api要運用的最簡單方式之一,就是使用AWS Lambda來驅動AWS內自己的API,再透過API Gateway跟外界 - 也就是chatbot整合。換言之,這仍然符合公有雲廠商(無論是AWS, google還是azure)的所謂serverless的未來方向。雖然這些公有雲廠商,其實只是為了讓客戶更難離開公有雲環境,但不可否認的是,這些api的確有用而且在初期成本也不高。

快速製作在LINE上的人臉辨識,需要幾個步驟:


(1) 對serverless的設計概念有些瞭解


請參考這裡這裡


(2) 對Line聊天機器人申請和製作,以及對AWS Lambda先有基本的瞭解。


可參考這裡這裡


(3) 在LINE webhook的event中處理image id。


在webhook的lambda程式中,特別挑出image的id。LINE的訊息傳遞給chatbot時,有分不同的type,要處理的是image type。LINE並不會真的傳圖片檔案到webhook中,他傳遞的是圖片id,透過這個id,可以用一個URL拿到圖片:


https://api.line.me/v2/bot/message/<id>/content

要取得這個圖片,當然要有Line token


(4) 讀取圖片URL並且以取得bytes


以python為例,首先以requests讀取URL,記得stream必須設為True,因為接下來需要將資料(影像的byte)直接讀取成bytearray。參考程式如下


    imageUrl = 'https://api.line.me/v2/bot/message/{}/content'.format(imageId)
    r = requests.get(imageUrl, headers=headers, stream=True)
    bArray = None
    with r.raw as data:
        f = data.read()

        bArray = bytearray(f)


(5) 使用各種AWS的Rekognition服務。

取得bytearray之後,剩下的事情就很簡單了。
以python為例,可以使用boto3 (最好是1.4.4版本)。先取得rekognition的client物件,直接使用裡面的方法(例如以下範例)。將Image參數都設定成{ 'Bytes': your_byte_array} 就可以取得分析的結果。


    rclient = boto3.client('rekognition')
    response = rclient.recognize_celebrities(
        Image = { 'Bytes':bArray }
    )

要注意的是,分析結果response是一個含有各種標籤與技術數值(例如信心程度)的dictionary物件,所有的標籤都還是英文,必須得自己轉換成中文才行。

範例中的「名人辨識」(celebrities)所查到的名字都是英文。可以利用wiki 英文api搜尋這個英文字,找到對應的中文網頁,在取得中文字。

wiki的英文api可參考這裡

(6) 存取S3之考量


如果看過AWS document應該會發現,使用recognize都可以設定image來源是S3。那麼範例為何不存取S3? 

事實上,的確可以將LINE的影像,先存在S3,然後再進行分析。然而,這樣會多了「存入」S3和取出S3的時間。並且,S3也是要收費的!影像如果只「分析一次」,那麼存在S3其實很不划算,存在Rekognition裡面更是貴。如果會反覆利用,那麼恐怕還是得存在S3中。



目前結果分享


用LINE將小姍加入好友,就可以試用一下目前LINE與AWS人臉辨識整合。


加小姍為好友 ID-> @opn2514f

加小姍為好友 Add Friend


下圖是辨識川普不同的表情,會被辨識出不同的年紀,和不同的心情。




6/20/2017

Serverless design for LINE AI Chatbot


Chatbot is one of the interesting application in AI area, it creates opportunities for enterprise to serve customers only with very low cost or even generate new revenue.
In past few years, major Instant Messaging providers allow developers to hook their service. Means as long as you have existing simple message process and response system, you can quickly interact with all kind of message channel.

Normally, a software developer will start from build a system in a server box, no matter Linux or Windows. Recently, the server might be a VM in public cloud, no matter AWS, Azure, Linode or DigitalOcean. However, a serverless design model might be a better choice.

Why Serverless?


Firstly, a serverless system will be easy to scale in/out. It doesn't mean you can't scale in/out in traditional VM in public cloud or your own datacenter. It just means that all the Lambda, no matter which provider, is actually decouple from it development environment. Supposedly, you start from one Lambda function to a few thousands same Lambda function without consider "traditional question", for example: should I shutdown VM when not in peak our, should I do some script to check if current VMs are closed to overloading?

Secondly, a serverless system will be easy to plug-in which means during the design phase, developer will be forced to think de-couple functions in small modules (bricks). Developer will also be forced NOT to rely on specific environment, even though docker is one of the solution but purely Lambda function will create much better environment-free structure.

Furthermore, it will also help to define boundary of sub system and help the future maintenance.

The Design Concerns

(1) IM independent

LINE occupies a huge market in Taiwan, about more than 90% of mobile user has LINE account. The most incredible thing is many elder people who never touch Internet before have LINE accounts! However, this design won't use any LINE specific methods. We've try the same engine in Yahoo Messenger and it also works.

(2) AWS Lambda

-- (2.1) try NOT to use context

AWS Lambda has a standard invoke parameter (event, context), The event is actually the user input when invoke Lambda function. The context is what developer might need to understand the 'environment context'. The major design concern here is try NOT to use context when possible. Because this will make you hard to move out your lambda to other public cloud environment. If you really need to have ARN or identity, try to limit environment in just one Lambda.

-- (2.2) async invoke

AWS Lambda could be invoked in 3 types: Event, RequestResponse, DryRun. The "Event" is actually asynchronous call. For any IM message receiver Lambda, you should  keep that Lambda as simple as possible to response IM webhook. Put other things via "Event" Lambda. Because most of IM provider (LINE, fb) ask a very short timeout in IM webhook. DO NOT just put http webhook and response to IM a synchronous call stack

Of course, see detail from AWS document: here.

-- (2.3) timeout/memory

AWS lambda allow to config timeout and memory size. AWS CloudWatch could see a Lambda's resource consuming. It is fine to use larger memory or setup a longer running time but developer should know WHY.

-- (2.4) quick testing

It is necessary to have your own developer server for test your Lambda function and trigger a deployment script to upload to AWS. If you didn't actually use "context", it will be very simple to have a quick test in every Lambda handler.

# in the end of your Lambda python script.
if __name__ == '__main__':

    event = {'param1':test'}
    lambda_handler(event,None)


Of course developers need other framework (unittest).

-- (2.5) deployment

As always, from a developer should have a semi-automatic way to do deployment. This is a very simple deployment script to (a) zip python files (b) upload to S3 (c) create lambda function (d) config function using S3 zip file.

(a) zip lottery.zip -r lambda_lottery.py lottery60.py
(b) aws --profile ailine s3 cp lottery.zip s3://bucket/
(c) aws --profile ailine lambda create-function --function-name lottery --runtime py
thon3.6 --role "arn:aws:" --handler lambda_lott
ery.lambda_handler --timeout 10 --code "S3Bucket=bucket,S3Key=lottery.zip"
(d) aws --profile ailine lambda update-function-code --function-name lottery --s3-bu
cket bucket --s3-key lottery.zip

-- (2.6) scheduled (cron) Lambda

Chatbot might need to do scheduled task to response to user, maybe send a regular morning call. To trigger a scheduled Lambda might be one of the major cloud-provider-dependent thing we have in Chatbot design.


(3) AWS API Gateway

AWS API Gateway is another major cloud-provider-dependent things, however, it is not hard to use other provider or have our own lab testing environment. The major concerns of API Gateway are (a) should convert IM provider's http request to a given format: which becomes a Lambda input. (b) security concerns: how to make sure only IM provider's system could access this API Gateway

(4) AWS dynamodb

Chatbot uses dynamodb to store use information and also message log. It is also pretty easy to use local JSON formate nosql.

(5) AWS elasticsearch

Chatbot leverages AWS elasticsearch to store knowledge base. It is easy to setup a developer's elasticsearch server to do lab test before deployment. The real concerns in public cloud might be the future budget:)

(6) AWS S3

Chatbot still need some static content (html or js) and S3 is the most easy way to provide public static content. It is also the place to upload latest Lambda code.


The Implementation


See: github repository 

Take a look?

This chatbot could understand and speak only Tradition Chinese, since she is a Taiwanese robot:). You need to have LINE account to chat with her.

聊天機器人小姍的Line QR 
加小姍為好友 Add Friend 









1/19/2017

聊天機器人 - 人類會跟她聊什麼?



過去幾個月,製作了學習式的聊天機器人,並且也提供了免費製作個人化聊天機器人的方式。

請參考:

免費聊天機器人
學習式人工智慧

現在已經超過550個人跟她聊天。雖然數量還沒有很多,但是也值得做一些簡單的統計。

最有趣的當然就是,人類在知道對方是機器人的情況下,會傳什麼訊息?

絕大多數的人,一開始都是以「Hi」「你好」「哈嘍」等等開始。

接下來三種最常見的話是:



(1) 罵髒話,教髒話

不知道是不是人類生活壓力太大。至少有60%以上的人,罵機器人髒話。例如「幹林娘」「操你媽」「Fuck」...

當聊天機器人的簡易學習機制開啟後,也有50%以上的人,會試圖教她髒話。這甚至迫使我們將機器人暫停一天,增加排除「壞朋友」的機制。

機器人被罵是小事,但是如果她學壞了,可能會影響到之後對其他人的對話。


(2) 擬人化訊息

把機器人當成真人來詢問人類特有的資訊。即便已經知道對方是機器人。

差不多有一半左右的人會探尋擬人化訊息。

例如:「你長得漂亮嗎」「你的三圍」「你家住哪裡」「你喜歡吃什麼」「你今天心情好嗎」

進一步會詢問個人價值觀等等問題。

例如:「你是藍的還是綠的」「你支持多元成家嗎」



(3) 資訊查詢


畢竟是機器人,可能大家認為會像電影一樣,知識庫有極多的資料。所以也有超過一半以上的人,會試圖請她找一下資訊。

例如:「附近哪裡有好吃的餐廳」「今天天氣」「推薦減重餐」「我在哪裡」

不知道是不是受到Startrek的影響,資訊查詢只要幾次無法滿足人類的期待,接下來人類就會暴怒開始罵髒話:~


聊天機器人小姍的Line QR 
加小姍為好友 Add Friend