顯示具有 ai 標籤的文章。 顯示所有文章
顯示具有 ai 標籤的文章。 顯示所有文章

12/01/2025

AI 樂觀與悲觀的未來


對於 AI 未來的發展,每個人都有自己的預測。在新聞、報章雜誌或各大媒體上,也有各種有趣的看法。但簡單來說,這些看法大概可以分成兩大類:第一類是樂觀的,第二類是悲觀的。

樂觀派的依據:科技發展的長期效益

所謂樂觀的意思是,現在有了 AI,人類可以做的事情變得比以前更多。人類的文明發展、科技進步又可以向前推進一大步。科技能讓我們的生活更好,不必在乎那些小小的細節。

總之,在過去一兩千年來,每次人類在科技樹上有新的發展,點了一個新的領域,突破了一個新的東西,雖然有時候會造成不好的結果,但大體上最終人類都是最大的得利者

得利者的例子有很多。早期有像火藥,火藥當然是因為戰爭而發明的(大部分人至少是這麼認為),但火藥其實對人類文明也有許多其他進展。像現在的火箭之所以可以發射到太空,就跟當初火藥的化學科學有很大的關係。

另一個例子當然就是核能。沒錯,核子彈是一個可怕的東西,如果現在某個國家發瘋了,可能全人類就不復存在了。但實際上,至少到目前為止,被核子彈打過的國家也就那一個,而大部分的核能是用在和平用途上,包含發電。當然啦,核能還有用在互相恐嚇的用途上,那是另外一回事。但至少到今天為止,我們人類還活著,沒有被核子彈毀滅吧。

這就是所謂樂觀的看法。樂觀看法簡單說,是根據過去的情況推測未來:過去情況就是這麼的好,長期來講未來會是不錯的。

悲觀派的擔憂:短期衝擊與階層分化

那什麼是悲觀的看法呢?悲觀的看法是直說:「沒錯,科技在大的尺度範圍通常都是好的。但是呢,在小的尺度範圍或者是小的範圍的人,不僅不一定是好的。」

什麼叫小範圍?小範圍指的是那一區的人。當然,指跟整個地球比起來,那一區的人可能也不小,可能是幾十萬、幾百萬、幾千萬都有可能。什麼是小的時間尺度呢?以人類文明發展史來看,有文字到現在大概兩三千年,有文明到現在一萬年。以這個時間尺度來講,我們未來的一兩代人,30 年到 60 年就是小的時間尺度範圍。

悲觀的看法是指:「沒錯,以大的尺度跟大的範圍來說,AI 可能會對人類有比較好的發展結果。但是以小的時間尺度來說,我們一個人活在世界上,頂多啦 80 年、100 年就算了不起。我們終其一生,能夠橫跨的時間尺度是比較小的。如果在這個時間尺度之內,AI 對我們來說是一場災難的話呢?」

它 AI 再加上機器人,是不是會讓 80% 的人沒有所謂的生產競爭力呢?那難道 80% 的人就要失業,只能領所謂的失業救濟金,過最底層的生活?而另外 20% 的人因為他控制 AI 跟控制資本,所以他們過得非常非常幸福的生活。

這就像工業革命早期一樣。工業革命其實對全人類以最終的結果來看是有好處的。不管你現在是什麼樣的人,就像我們前幾天講的那個底層人,你就算是全世界、全台灣 20% 底層人,或者是美國、歐洲國家 20% 底層的人,你只要不是一些極端落後國家的底層,你只要是資本主義國家的 20% 底層人,你的日子仍然比幾百年前的 20% 底層人過得好太多倍了。大部分人至少有抽水馬桶可以用。

我們回溯到過去的例子,100 年前,不用說底層 20%,甚至 60% 的人都是沒有抽水馬桶、沒有現代化的衛生設備可以用。買衣服非常貴,現在衣服便宜得不得了。

所以,如果從時間尺度上來看,沒錯,未來 AI 的技術發展再加上機器人的確對人類可能會有很大幫助。但對我們現在這一代,還是我們的下一代呢?未來 30 年到 60 年,真的對我們會有好處嗎?我們會不會像工業革命的開始一樣?工業革命一開始的時候,底層勞工很慘,他們被迫到工廠去工作,那時候也沒有所謂的最低基本工資跟勞基法,在工廠工作那基本上跟奴隸沒有什麼兩樣。

但是因為工業革命的關係,你又不太可能去選擇其他的工作範圍。換言之,當時的底層五六十百分比是很慘的,他沒有因為工業革命而獲利。因為工業革命而獲利的是上層人士,就是 Top 10%、Top 20%,就是前 20%、前 30% 擁有資本的人。當然啦,只要人在資本主義下,底層人上升是可以流動的,只是流動速度不會是你想像中的快,可能不是三、五年,是三、五十年耗盡一點的時間。

我的個人看法:兩者都會發生,重點在於「選對邊」

AI 呢?我個人覺得畢竟這是一個大家都有看法的時代,所以對 AI 來説,我個人覺得這兩個恐怕都會發生,也就是說悲觀的事情會發生,樂觀的事情也會發生。

就我個人來講,如果悲觀的事情會發生,樂觀的事情也會發生的話,那重點就已經不是這個事情會不會發生,而是你要怎麼選對邊。這聽起來非常的牆頭草,不過我找不到更好的選擇(比「選對邊」更好的形容詞、更好的描述方式)。有時候覺得感覺上我最近常常會沒有辦法講出我想要形容的那個詞,一時之間找不到更好的詞彙,簡單的詞彙也好,複雜詞彙也好,不管怎麼樣就是找不太到。那就只好用個最簡單的:「你要選哪一邊呢?」

當然選樂觀那一邊的,你不會是想選悲觀那一邊。在這個時代之下要選樂觀這一邊,其實也有非常多的方式。其中有一個東西,也是因為我最近在網路上或者是在社群媒體上看到很多這類的訊息,就是教你怎麼用 AI。教你怎麼用 AI 這件事情,讓我想到 AI 的樂觀面跟悲觀面,進而想到今天要講的話。

避免被 AI 取代:不要跟「人」學 AI

如果有人想要教你用 AI,你真的必須要透過一個人或是透過一個教學的方式(不管他是賣課程也好,還是他做什麼特殊的活動也好)你去參加特殊活動,通過這個人來學習的話,那你可能是屬於不太能自己學 AI 的這一種。

怎麼說呢?所謂的教學,不管我們以前上過補習班,我們去學過一些有的沒有的東西。例如說去學英文、學日文,或學其他東西像一些技能學打羽毛球,也是需要人教。所以任何知識跟技能,你也可以自己自學,你也可以別人教。一般來說,只要你找到好的老師,別人來教你,通常是比較快,而且比較好的,對你也比較好處,因為你可以少走許多冤枉路。

你少走許多冤枉路,可以讓你比較快達到你想要的結果。例如說學不同語言,學日文或者學英文,它其實是有很多訣竅的。那在市面上很多老師出了很多書,或者是他有什麼課程,你可以這個老師也可以聽,那個老師也聽,找到一個你覺得最適合你的訣竅。那這樣的話,你學習語言的速度就比較快。

但是我覺得 AI 不太一樣 為什麼呢?

第一,AI 發展現在才在剛開始而已,就像當初網際網路剛開發發展一樣。而且 AI 跟其他技術有一個截然不同的地方:AI 代表的是人類做出一個濃縮人類知識與技能的某個東西

當然這邊的 AI,其實只限制在 LLM(大型語言模型)上。其他有很多不同的 AI 雖然很重要,可畢竟 LLM 現在是某種程度的主流或者是最流行的東西。所以這邊講 AI 其實就是 LLM。

LLM 的特徵就是它濃縮人類的知識結晶在某一個模型裡面,你用打字的方式或者口說方式跟它對談,獲取你要的東西,不管是直接獲取也好,間接獲取也好。在 AI 的其他線上所有課程裡面,都會告訴你有一個人,他覺得他跟 AI 的溝通方式比你還要不錯,或者是他有想到一套可以跟 AI 好好溝通的方法。包括現在最流行的提示詞(Prompt),或者是在 Facebook 上有人說是魔法,或是魔法詠咒,反正就是各種各種行動詞層出不窮。簡單來說是 Prompt,這個語句就是讓你告訴 AI,然後讓 AI 回答你,無論你是寫程式也好,還是其他工具也好,那只是在外面再多加幾層 Prompt 而已。

所以呢,就會有人想要這樣子教別人。教別人沒有什麼不好啊,為什麼不去學呢?就像我剛才講,AI 有一個很重要的特點是它濃縮人類知識,包含教學的知識。也就是因此,如果你真的想要學 AI,而且你覺得你要站在樂觀那一面,其他東西都可以學,但是怎麼樣用 AI 做某件事這件事情,最好不要跟人去學

您應該想辦法去從 AI 去學這件事情。這聽起來是有點繞圈圈,或是有點繞舌的感覺:「我怎麼樣從 AI 去學我怎麼樣用 AI 呢?」

但是呢,如果你不這麼做的話,會有一些悲觀上的後果。

無腦使用 AI 的後果:智商降低與失去自主權

如果你從人類的角度去學 AI 的話,那你就用 AI,並沒有使用你的腦袋去用 AI,那就會淪入所謂的悲觀那一面

悲觀那一邊有很多,例如說有很多研究早就指出來,如果你常常用 ChatGPT 或 Generative AI 去解決某些問題,常常用的人呢分兩組人。一種是不太會想的,不太會想的,你會越來越笨,智商會降低。

人跟動物最不一樣的地方就是我們還有點智商,我們至少還有一些推測能力、推演能力跟基本的智能,這是人跟動物最大的差別。如果我們可以把很多東西交給 AI、交給機器、交給外力來處理,可是如果我們把推理跟知識的累積這件事情交到外面去的話,那就會變成悲觀的主人

什麼叫悲觀的主人呢?你可能就是以後會被 AI 好好控制的那種主人,因為你已經把自主權交出去。那什麼叫做不交出去呢?不交出去你知道自己在幹嘛,你知道怎麼用 AI,因為你並不是用一個別人教你的方法去用 AI。

那為什麼別人教法不行?因為別人教是一個基本的套路、既定使用,沒有任何困難,但是它會降低你思考能力。在其他知識領域是可以的,只有在 AI 的未來恐怕是不行的。


什麼叫其他知識領域可以呢?像我自己手邊有個 iPhone,我在用 iPhone 的時候,我難道需要知道 iPhone 裡面的各式各樣的細節嗎?它的觸控原理怎麼運作?它的節能怎麼運作?iPhone 如何連通 3G、4G、5G?如何把我的聲音傳到機台?如何跟別人溝通我的聲音?這個東西我難道需要知道細節嗎?不用。我根本不需要,作為一個人類,我只要需要知道操縱 iPhone 就可以。

但重點是我有一件事情,我始終很清楚,就是我操縱 iPhone。當我關掉 iPhone,它就關了。當我告訴 iPhone 叫它做一些事情的時候,它會 exactly(完全)如同我叫它做去做。不只是 iPhone,像汽車什麼都是這類。

**但 AI 就不太一樣。**當你無腦地使用 AI 的話,那麼 AI 對你來講,就是一個 iPhone,或是一個電視遙控器,或者是任何一個現在已知的工具。你沒有辦法從這工具上獲得什麼,你在這工具上的使用變成自動化進行,而自動導航,或者是完全無腦地進行。別的工具對於我們來說是可以完全無腦地運作它,而且對我們平常要做事情不會有任何壞處。

我無腦使用電視遙控器讓我看到電視節目,完全是對的。我無腦使用 iPhone,讓我可以傳訊息、打電話、貼一些文章給我朋友、打電話給我的家人,完全沒有問題,它不會降低你的智商。

但是 AI 不太一樣,特別是 LLM(大型語言模型)。當你無腦使用的話,它會讓你變得更無腦。因為呢,你再也不用推測、推理、收集跟消化別人的知識。別人給你個 PDF,你告訴有人說「請給我 摘要」,你就會只看到摘要,但你再也不會去推敲這個 摘要 是怎麼得出來的?為什麼這一篇試驗論文的 摘要重點 是這個?它看到了什麼?我如果自己去看,能夠達到一樣的結果嗎?

如果你是自己去學 AI,你慢慢、慢慢的會去想這件事情,因為你知道 AI 是怎麼推敲東西。有一天如果真有必要的話,你仍然可以從一個 1000 頁的文件裡面做出 Summary。然後呢,不管你是作為一個學生也好,還是作為研究也好,還是作為任何職業角色也好,你對你來講,AI 就是像 iPhone 一樣一個非常好用的工具。可是你不會受限於它

失去 iPhone,你很快可以找到替代品。例如說我現在有一台電腦,我雖然不知道 iPhone 怎麼運作過程,可是我知道我還是可以用電腦傳爛的訊息呀、做其他事情。

但對於知識份子,知識是自有推敲性、有邏輯性、有推理性的、有組織性的。但是呢,如果你用 LLM 沒有思考,就會讓失去這一些。失去了這些,你就變成了 那底下的80% 的人類:你會越來越笨。雖然這講得有點殘忍,但是這恐怕是事實。

在 AI 時代,跟其他時代比起來,以往在資本主義下,中層的人,也就是說中產階級,中間的 60% 的人其實是非常能夠獲利的。比較慘的是底層 20% 的人,但最好的是 Top 20% 的人。


那對於 AI 時代,我覺得就算再怎麼樂觀,恐怕也只有 Top 20% 到 30% 是真正超越 AI、使用 AI,他沒有喪失自己的智商。後面 20% 到最慘的極端是 20% 到 80%。我是希望不是這樣子,但是最慘的情況是 20% 到 80% 的人,他可能是因為 AI 關係開始喪失智商,變成某種程度的被 AI 驅動著的人類的附屬品。

不知道這樣講是不是一個可以發生的未來?如果不可以的話,那當然我們是希望每一個人都是可以好好使用 AI,然後呢,通過 AI 去讓自己的工作變得更簡單、開發出新的東西,或者是發展出新的 Business,或者是讓你的本來你在做的企業、讓你的工作變得更簡單。

要做到這一點,雖然這是個起步,但是這個起步是很重要:也就是說在學習上,必須要靠自己,而不是靠另外一個把 AI 的捷徑交給你的人。因為一旦有了 AI 捷徑,接下來使用 AI 就永遠都是那個捷徑了。

4/03/2025

AI 輔助的人名查詢工具

在今天的數位時代,資料搜尋變得越來越簡單,但如何從海量資訊中篩選出所需的、準確的政府資料卻是一項挑戰。然而,隨著AI技術的進步,這一切都變得更加高效與便捷。在此將介紹如何透過AI輔助來搜尋政府資料檔案,並舉例說明一個專為台灣人設計的實作網站:閒閒貓www.saltycat.tw)。


AI輔助搜尋政府資料的優點


AI技術的加入,讓搜尋政府資料變得不再那麼複雜與繁瑣。首先,AI能夠從大量的網路資料中,快速找到相關的政府資料檔案,並且自動整理成簡單易讀的報告。這對於需要即時查詢資料的人來說,是一大福音。而且,AI會持續學習並更新資料庫,確保使用者能得到最新的資料。


在台灣,許多人可能會面對需要查詢各種政府資料的情境,但由於資料來自不同網站、來源繁雜,常常讓人覺得十分困難。閒閒貓這類型網站正是為了解決這個問題而誕生的。這是一個僅只用於台灣工具,透過AI的輔助,使用者只需要簡單的輸入關鍵字,便能迅速獲取各種公開的政府資料,並且由AI將這些資料整合、整理成一份清晰的報告。這樣一來,不僅節省了大量的搜尋時間,也能避免資訊過載。

不少人可能會擔心,這樣的工具是否會侵犯個人隱私。其實,這個工具所整理的所有資料,都是來自於公開的政府資料,並不涉及任何隱私或敏感資料。簡單來說,這個工具並不會持有或產生任何個人資料,它只是運用AI技術將公開資料彙整並提供給使用者。因此,使用者完全不需要擔心隱私問題。他在彙整的地方會列出所有參考資料來源,理論上,人類也可以自行去彙整這些公開資料,只是花的時間不划算。

從繁瑣到簡單,AI技術的轉變


在沒有大型語言模型(LLM)技術的時候,搜尋政府資料往往需要花費大量的時間和精力,甚至有可能因為資訊的混亂而找不到正確的資料。然而,隨著AI技術,尤其是LLM的普及,這項工作變得簡單多了。讓使用者能在短時間內找到所需的資料,提升工作和生活效率。

專門查“人名”功能,類似肉搜
閒閒貓專門查詢“人名”。這類似於網路上的“肉搜”功能,使用者可以透過輸入某個名字,快速獲得該人物的公開報告,包括其社會、工作背景等相關資料。更重要的是,AI技術會儘量區分同名同姓的人,讓使用者獲得更加精確的結果。這樣的功能對於需要快速了解某個人背景的使用者,無疑是一個非常實用的工具。

這個工具適用的使用者群體


企業招聘人員:在招聘過程中,招聘人員需要查證應聘者的背景資料。這個工具能幫助他們快速找出正確的應聘者資料,並避免因同名同姓而出現混淆。

企業風險管理部門:風險管理人員常需要了解合作夥伴或潛在員工的背景。AI技術能幫助他們快速獲得精確的資料,減少人為錯誤,從而有效控制風險。

法律專業人士:律師在進行案件調查或處理法律事務時,常常需要查詢某些人物的背景資料。這個工具能幫助他們更快速地獲得所需資料,避免錯誤,提升工作效率。

媒體與記者:記者在進行人物報導或新聞採訪時,可能需要查詢某些人的公開背景資料。這個工具能幫助他們迅速準確地獲得所需資料,避免報導錯誤。


一般民眾
:有些普通使用者基於好奇或其他需求,也可能會利用這個工具查詢某個人的公開資料,尤其是當這些資料能夠對其生活或工作有幫助時。

社交平台用戶與網絡安全專業人士:對於關心個人資料安全的用戶或從事網絡安全工作的人來說,這樣的工具可以幫助他們查詢公開人物資料,保護自己的網絡安全。

總結來說,AI輔助搜尋政府資料和人名查詢工具,對於許多需要查找、整理、和分析資料的使用者來說,都具有極高的價值。無論是政府機構、公務人員、企業還是一般民眾,這些工具都能幫助他們更加高效、準確地處理資料,並避免了過去的繁瑣流程。



(本文90%內容利用AI生成)

7/28/2024

AI的計價方式 - 計算使用量嗎?


自從chatgpt出現之後,LLM以及各類型AI應用突然間大量湧出。可以想像到的是,就像其他的科技發展一樣,AI相關應用的發展速度只會越快不會越慢。

AI的應用方向雖然很多,但目前對於"如何收費"似乎沒有很智慧的方式。大部分的工具,仍然像SaaS一樣的以月租/使用量來收費。

這張圖是截至2024七月為止 gpt-4o API的收費,單純還是以使用量(token)來計算。如果是直接使用介面的話,每個月則是20美金。當然這20美金每個月,是有使用上限的,例如每三小時只能傳遞80個訊息,或者只能要求製作或者輸出多少自動生成圖片。




類似的收費模型,也同樣出現在AI應用上。例如,videogen.io是一個利用AI來生成影片的saas服務,它收取月費,不過這月費會有很大的使用限制,大概只能生成一小時的影片。


月費與使用量付費,的確是典型的Saas服務收費方式。這雖然沒有什麼不好,但是這樣的收費方式,大大限制了AI未來發展的潛力,因為現在的AI發展,都是以某種形式,大量取代某種人類正在做的事情。而使用月費或使用量付費,對於技術人員來說是合理的,但對於一般消費者而言,是不是使用AI技術並不是重點,而是解決消費者問題才是重點,而收費的方向,應該會朝向解決問題的本身,而不是技術上的數字。

舉個例子來說,AI大幅度取代了第一線的文字客服以及語音客服人員,對於經營7x24的不間斷服務的大型企業來說,如果原本要雇用20個客服人員,提供24小時不間斷的客服服務,想要用AI取代部分人力,只留下4位核心人員。那麼提供AI客服的應用公司,應該要的計費方式其實是16個AI客服的「薪水」,這個薪水自然小於原本的客服人員。如果仍然使用用量計費,例如這個月使用了五千萬個token,因此收費多少錢,這5千萬token不但很難讓一班企業理解真正的意思,也根本看不到AI的真正價值。如果計費的方式是「你雇用了我們16個AI員工,這16個員工薪水比人類低很多,而且不用勞健保,也從來不抱怨加班,更不會請假,失誤率也低」那對於企業端就很容易理解。


同樣的,未來AI會合併機器人的發展,仿生機器人很快可見。但計費的方式如使用類似租車的方式計費:每天租機器人費用2千元,充電費用另計。那麼該機器人潛在「用法」可能會被低估,AI機器人會變成人類的附屬工具:例如一台汽車。雖然這並沒有什麼不對,但潛在的價值將會大幅低估。一樣是費用,當仿生機器人改用「月薪」付費的時候,在使用上,它會變成企業員工的一部分,自然企業會用各種方式,強化它的應用方向,訓練它,讓他學習更多東西。

國內外的新聞電視台,已經開始可以看到AI主播,如果AI主播是以用量計費:例如講多少字的話語,產生多長時間的語音檔案,電視台其實很難比較有AI主播和人類主播的差異。但如果AI主播是以「月薪」計算,那就很容易理解AI與人類的差異。此時更容易可以讓人類去執行更有價值的工作,讓AI進行重複性質高的工作。

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: 這也讓開發團隊(年紀太大)增廣見聞,之前根本不知道聖結石是誰。

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 









9/05/2016

人工智慧的淺顯應用 - 製作Facebook或Line聊天機器人

自2022年有chatgpt之後,原本的fb聊天機器人已經停止使用。新的聊天機器人使用chatgpt, 想要試用的,可以email聯絡:consultant.3rd@gmail.com



聊天機器人(chatbot)並不是什麼新鮮事,早在1950年間圖靈(註一)在提出關於人工智慧判別方式時,就提到利用文字訊息 - 因要把人和機器分開 - 來和兩個對象聊天,其中一個對象是人,另一個對象是電腦,如果一個正常人在聊天的過程無法區分這兩者誰是電腦,誰是人,則可判別這電腦程式,是真正擁有智慧。

要達到這個目的難上加難,在wiki上可以看到目前僅有在2014年一個名為Eugene Goostman的聊天程式通過這個測試。

目前可取得的人工智慧演算法或相關技術都沒有太驚人的發展。然而,由於網路上的資料取得越來越容易,電腦執行速度越來越快,以致於不需要有驚人的技術能力,也不需要有對人工智慧會不會變成奴役人類的電影劇情的深思,就可以開發出有意義的應用。


Facebook聊天機器人也是其中之一。

商家,企業,甚至某些個人都擁有FB page (粉絲頁 專頁),而從2015年開始,facebook開始出現具有固定反應或者訊息回應的聊天程式。不過台灣似乎比較少見非特定用途的聊天機器人,因此我們就做了一個在粉絲頁上。參考下圖:


https://www.facebook.com/sandy4ai/ 具有人工智慧聊天的粉絲頁

這個聊天機器人會回應你的訊息,根據她內建的知識庫和基本的語意分析,會回應你訊息。當然,她也會慢慢學習對話,這個聊天程式並不會需要額外的facebook權限,因此她沒有太多額外的功能。下圖是聊天實況範例:



和具有人工智慧聊天的粉絲頁聊天


Line在今年(2016)也開放bot api,作法和Facebook幾乎很雷同。不過雖然都是webhook,他們的api實際傳遞內容當然完全不一樣。

Facebook/Line 聊天機器人的可能應用:


1. 基本客戶問題:

企業組織在網路上最常「被」查。查詢營業時間,查詢電話,查詢服務項目等等。在台灣,這幾年用facebook來做生意來越頻繁,而聊天機器可以提供24x7的基本回答問題服務。

2. 促銷活動:

聊天機器人在某些權限下,可以主動傳遞訊息,或者貼文給facebook使用者。這和一般廣告貼文有些許不同,因為貼文之後,使用者可以持續和貼文者 - 也就是聊天機器人互動。

3. 例行客戶服務:

預約預定,提醒預約,服務調查,生日賀卡貼文等等。




如何製作Facebook臉書聊天機器人:



1.摘要步驟

  (1) 到AWS開設帳號。 開發過程會用到Lambda, API Gateway, elasticsearch, s3 cloudwatch 等服務。

  (2) 到facebook建立facebook app。(簡稱 fb app)

  (3) 新增並撰寫基本的Lambda 以回應 之後fb app webhook時的GET驗證。

  (4) 新增撰寫基本的Lambda 以用在 接下fb app message hook回應

  (5) 新增 API Gateway 的GET/POST,對應到Lambda

  (6) 設定fb app 的webhook 對應到API Gateway的URL
  
  (7) 讓fb app的設定頁verify(基本上就是http  GET) API  Gateway

  (8) 讓fb app設定頁訂閱message 並記得在lambda程式回覆訊息時使用page token

  (9) 此時可以進行知識庫的連結,在AWS建立elasticsearch並且匯入經過程式處理的資料,這裡我們以台灣e院資料為範例。

   (10) 修改lambda程式,讓使用者的訊息,在elasticsearch查訊相關訊息,並且回復給原送訊息者

   (11) 至此完成,其結果大致如下圖:



2. 詳細步驟:

    ....<待續>...


如何製作Line聊天機器人:


1.摘要步驟

  (1) 到AWS開設帳號。 開發過程會用到Lambda, API Gateway, elasticsearch, s3 cloudwatch 等服務。

  (2) 到line developer建立帳號以及channel。

  (3) 新增並撰寫基本的Lambda 和 api gateway 用以回應之後在line的channel上link時的驗證。Line的api基本上只用到POST

  (4) 將自己的line帳號 加入剛剛自己增加的channel。就是設好友的意思,這樣才能測試

  (5) 將line channel所需要的api key, secret以及token設定在lambda 要傳回給line bot api的地方。

  (6) 此時可以進行知識庫的連結,在AWS建立elasticsearch並且匯入經過程式處理的資料,這裡我們以台灣e院資料為範例。

   (7) 修改lambda程式,讓使用者的訊息,在elasticsearch查訊相關訊息,並且回復給原送訊息者

   (8) 至此完成,其結果大致如下圖:


2. 詳細步驟:


    ....<待續>...



參考: https://www.facebook.com/sandy4ai/ 

 註一:Turing 就是電影模仿遊戲的主角
 註二:詳細步驟還沒有時間寫...反正不見得有人需要:)