發表文章

使用Azure AI Question Answering 快速建立客服機器人

圖片
還記得疫情那時候嗎? 有一段時間,醫療院所內的護理師面對應接不暇的來電,都是為了詢問跟疫苗有關的問題。像是: 疫苗施打的順序? 何時可以輪到我? 如果有過敏該如何選擇? 注射時應該要注意些甚麼? 我能不能不打疫苗? 諸如此類的詢問,塞爆了正常的電話掛號系統,導致許多真正需要幫忙的病患,無法得到該有的醫療資源以及諮詢,而護理師也無法專注於本來應該進行的護理工作。 這時,有些醫院開始導入對談機器人,透過手機APP或是網頁,可以讓一般民眾詢問疫苗相關的問題,並且提供正確的回覆。 當時,還沒有 ChatGPT 這樣的大型語言模型,醫院的資訊單位也不是AI領域的專家,要如何在極短的時間內,建構出一個可以準確回答用戶疫苗相關QA問題的對談機器人? 來幫助醫院在面對突乎其來的詢問電話時,可以透過分流來舒緩客服壓力? 答案,就在底下這個影片裡。我們從這個影片中可以看到,要如何在幾分鐘內,將既有的 知識庫 轉換成對談機器人,讓用戶可以直接透過網頁或手機問問題: 底下這個影片,加碼介紹如何把這個QA對談機器人,變成LINE Bot(也就是LINE官方帳號),讓用戶只需要用LINE就可以直接得到答案:

使用 Airtable 在小型需求上取代傳統資料庫

圖片
我好幾年沒有用傳統的關聯式資料庫了。 老實說,傳統的關聯式資料庫,其實對於教育訓練和小型的專案來說,是一種負擔。 如果你想讓學員清楚的掌握一門技術,就好比說,對談機器人的開發吧,在整個教學的過程中,若是範例用到SQL或MySQL資料庫,無疑是一種節外生枝,把問題變得更複雜。因為,在對談機器人當中,儲存只是一種迫不得已的額外需求,是枝微末節,而非對談機器人技術的主體。 同樣的,如果你做一個小型專案或POC的話,『儲存』也往往不是重點,儲存只是『必要之惡』。其實,若是從這個角度廣義的來說,軟體開發的GUI、資料庫,都只是細節(枝微末節),都應該要是可以隨時被抽換或取代的部分,而非系統核心。 一套軟體或解決方案的真正核心,是商業邏輯。它(商業邏輯)才是一個應用程式真正展現價值的部分。 我們把主題拉回來。所以,我最近這幾年在上課的時候,盡量不讓範例程式碼涉及資料庫存取,特別是關聯式資料庫的存取。因為這對讀者或學員來說,變成了另一種必須學習的負擔。 但說的容易,如果範例中有碰到需要儲存資料的時候該怎麼辦呢? 有沒有什麼最簡單的儲存機制可以在程式碼中替代傳統資料庫? 這也是我最近幾年寫範例的時候,常常碰到的問題。因此,我特別花了一段時間,找看看有沒有什麼好用的『類』資料庫儲存體? 最後,我選擇了 Airtable。 Airtable Airtable 是一個靈活的雲端資料庫產品,結合了資料庫的功能和電子表格(data grid)的簡易性。它允許用戶以視覺化的方式存儲、組織和協作各種資訊: 白話一點說,就是它可以很自由的在Web畫面上設計欄位和維護(輸入、編輯)資料。 對我來說,它還有另一個重點,就是它擁有非常簡單的REST API,透過呼叫API就可以直接來讀寫資料。 它的API在使用上很簡單,只需要在設計好資料表之後,透過 https://airtable.com/create/tokens 站台建立一個 PAT(Personal Access Token): 建立PAT的時候,可以選擇要針對所有資料表,還是特定資料表,要只給這個token 讀取(Read)權限,還是要寫入(Write)權限: 有了token之後,可以透過很標準的REST API呼叫,進行連線的建立與資料的寫入: string ID = "👉air_tabl

Azure Web App 的基本驗證被停止了!

圖片
如果先不管自動化CD Pipeline,習慣使用Visual Studio的開發人員,若要對 Azure Web App 佈署網站,大概最喜歡採用的佈署方式,莫過於『發行設定檔』。這一招用很久了,直到最近你可能會發現,建立Azure Web App 的時候,會看到底下這樣的警告: 這也意味著,你無法下載發行設定檔了: 如此一來,Visual Studio 當然也無法佈署了! Azure 這個調整,當然是為了安全性提升。 使用基本驗證不安全嗎? 對,相對來說是的。 因為基本驗證只透過一組帳號密碼來做佈署,再加上發行設定檔還把這組帳密直接給放在裡面,誰拿到了這組帳密都能夠更新網站,沒有進一步的身分驗證,對一般個體戶小型專案的開發人員來說還行,但對企業來說顯然不是一個理想的選擇。 好吧,但這樣比較簡單啊。假設,你只是要快速的進行佈署,我們是否可以先把這個被 disabled 掉的功能暫時開啟呢? 可以的,在 Azure WebApp 的組態設定,將『基本驗證發佈認證』給開啟即可: 如此一來,發行設定檔又可以下載了(記得把網站 reload 一下): 下載到發行設定檔之後,我們在Visual Studio當中可以透過底下這樣的方式佈署網站: 然後選擇剛才下載的發行設定檔即可。 這種佈署方式雖然方便,但就如同前面說過的,發佈的過程並沒有嚴謹的身分驗證,也不支援AAD帳號或是RBAC等權限配置。因此,短期暫時將傳統的基本驗證開啟,取得發行設定檔佈署即便可行,建議未來還是採用AAD(Entra ID)驗證是比較理想的做法:

Semantic Kernel Plugin 的錯誤處理

圖片
先前我們 提到了 透過Semantic Kernel,可以讓AI/LLM在與用戶對談的過程中,自動在需要的時候去呼叫 PlugIn 物件的方法(Method),特別的事情是,這個呼叫並非是我們寫程式去做的,而是 AI 自己做的,我們並沒有寫這部分程式碼的邏輯,我們寫的只是提示(prompt)而已。 那問題來了,如果不是我們寫程式去呼叫這個方法,而是AI自己去呼叫的,那假設,這個被呼叫的方法裡面發生了 Exception ,那會發生什麼事情!? 我們看底下這段程式碼: public class LeaveRequestPlugin { [KernelFunction] [Description("取得請假天數")] public int GetLeaveRecordAmount([Description("要查詢請假天數的員工名稱")] string employeeName) { isRock.LineBot.Bot bot = new LineBot.Bot(ChannelAccessToken); bot.PushMessage(AdminUserId, $"[action : 查詢 {employeeName} 假單]"); if (employeeName.ToLower() == "david") return 3; else if (employeeName.ToLower() == "mary") throw new System.ArgumentOutOfRangeException("無法取得假單資料"); else return 5; } (...略...) } 請注意上面這段查詢員工請假天數的程式碼,你會發現,我們刻意在程式碼裡面,加入了底下這段 code: (...略...) else if (employeeName.ToLower() == "mary") throw new System.Ar

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

圖片
身為 LAE(LINE API Expert) 與 LINE 的支持者,既然知道透過Semantic Kernel可以快速的開發對談機器人,那當然要嘗試用在 LINE Bot的開發上。 先前我們 介紹過 如何使用 Semantic Kernel 來開發一個支援記憶與對話前後文、可以用自然語言進行請假的對談機器人,但當時的架構是在 console 環境,負責記憶處理的 ChatHistory 是可以被長時間保存的實體物件,但換成了LINE Bot開發的WebAPI架構,一切就變的有所不同了。 首先,由於ChatHistory物件會隨著WebAPI行程消失而遺失,且我們的LINE Bot還得面對多個用戶,因此也無法簡單的用一個 ChatHistory 物件就保存所有用戶的對話紀錄。所以我們要做一些調整,為每一位用戶建立一個自己的ChatHistory物件。 因此,我們在 WebAPI 中撰寫了底下這樣的程式碼: static Dictionary<string, ChatHistory> ChatHistoryByUser = new Dictionary<string, ChatHistory>(); private ChatHistory getHistoryFromStaticRepo(string UserId) { if (ChatHistoryByUser.ContainsKey(UserId)) return ChatHistoryByUser[UserId]; else return new ChatHistory(); } private void saveHistory(string UserId, ChatHistory chatHistory) { if (ChatHistoryByUser.ContainsKey(UserId)) ChatHistoryByUser[UserId] = chatHistory; else ChatHistoryByUser.Add(UserId, chatHistory); } 這段程式碼以靜態方式儲存ChatHistory物件的Dictionary,搭配 getHistoryF

使用Semantic Kernel 建立自然語言請假系統

圖片
既然我們已經知道,可以透過 Semantic Kernel 輕易地建立聊天機器人/智能助理,我們之前(參考 這篇 )也看到了如何用自然語言驅動 AI ,來自動呼叫 IoT 控制開關燈類別中的方法,體驗過了它的威力,接著,我們就來實作一下,如何透過 Semantic Kernel 來建立一個可以透過自然語言請假的對談機器人。 我得說,我過去幾年做過無數次這個範例,試圖用自然語言以對談方式來完成請假。從最初LINE Bot 出現的時候,以手工苦刻的方式,來建立請假機器人,到使用 Azure AI 上的 Language Understanding 解決方案,讓機器人能夠『稍微』看懂用戶以自然語言的方式輸入的請假資訊,但整個過程從來沒有愉快過。 過去,電腦對自然語言的理解實在太差了,直到GPT的出現,直到有了LLM,一切才開始不同。現在,我們可以輕易地透過 Semantic Kernel 使用大語言模型,來建立一個類似底下這樣,表現非常好的自然語言請假系統: 你會發現,我們實作了一個可以幫助用戶請假的對談機器人。他會蒐集用戶的請假資訊,然後在資訊滿足之後,呼叫API來完成請假動作。 上面這段對談紀錄當中,黃色的部分就是AI自動進行的 Action,也就是具體的『請假』或是『查詢』動作,其他的則是自然語言的交談對話。 我們之前說過,透過 Semantic Kernel ,我們可以快速地完成上面這個功能的開發。為了完成這個需求,我們建立了底下這個 LeaveRequestPlugin 類別。這個類別裡面有三個方法,你可以從Description描述看到這些方法的功能(當然,範例裡面的Action暫且用示意的方式來呈現,不真的寫入資料庫): // 請假功能 Plugin public class LeaveRequestPlugin { [KernelFunction] [Description("取得請假天數")] public int GetLeaveRecordAmount([Description("要查詢請假天數的員工名稱")] string employeeName) { //修改顯示顏色 Console.ForegroundColor = Con

精彩(且驚人)的Semantic Kernel入門範例

圖片
之前開直播的時候,和線上朋友聊到,因為AI的出現,未來的應用程式,勢必會和現在有所不同。 先不要跳到 黃仁勳 說的,未來『每個開發人員都可以直接用自然語言做程式設計』(這樣也太駭人聽聞了一點),先看看眼下我們可以做到什麼程度。 你會發現透過 Semantic Kernel,這個所謂的 AI 開發框架,已經可以做到, 讓 AI 自己決定何時(以及如何)呼叫一個類別(Class)中的方法(Method) 。而我們只需要讓用戶輸入對話與機器人對談,就可以控制程式運行的流程與邏輯。也就是說,現在不需要滑鼠點選,不用選單操作,只要與機器人透過自然語言對談(底下的範例是打字,但當然可以是語音),就可以操控系統。 我前陣子一直說的,AI 會讓 GUI 有著天翻地覆的改變,意即如此。 看底下這個類別的程式碼: //控制開關燈的類別 public class LightPlugin { //當前燈的狀態 public bool IsOn { get; set; } = false; [KernelFunction] [Description("取得燈的狀態")] public string GetState() { return IsOn ? "on" : "off"; } [KernelFunction] [Description("改變燈的狀態")] public string ChangeState(bool newState) { this.IsOn = newState; var state = GetState(); // Print the state to the console Console.WriteLine($"[Light is now {state}]"); return state; } } 上面這個很簡單的 LightPlugin 類別,具有兩個方法:GetState 和 ChangeState。這兩個方法都被標記為 [KernelFunctio

使用CLI指令快速開啟Windows Terminal

圖片
不知道你會不會和我一樣有種感覺,Terminal 用久了,喜歡打字勝過用滑鼠點GUI。 這導致,我在VS 2022中寫 code 的時候,有時候要安裝套件,我喜歡用 windows terminal 多過用 NuGet 管理員,包含執行類似 dotnet run 指令,我都比較喜歡在 CLI 環境下執行(也許是用慣了VS Code的關係)。 當然,在 VS 2022中,不是沒有 Terminal,其實它有一個 『開發人員 PowerShell』,一般你按 Ctrl + ~ 就會出現: 但我很不喜歡用它,主要是因為『醜』。 沒法很簡單的調整文字大小,也沒什麼色彩,而且有時候還會有奇怪的換行或顯示問題。 我忍耐它好一陣子了,我一直想,是不是有什麼方法,可以從這個 『開發人員 PowerShell』直接開啟 windows terminal? 總該有個指令可以簡單的完成這件事情對吧? 類似像是在一般的終端機下 『start . 』指令,我就可以啟動檔案總管,並且開啟當前資料夾。下『code .』指令,就可以用 VS Code 開啟當前資料夾。 那 windows terminal 呢? 有沒有簡單的指令可以呼叫它? 稍微一找,發現還真簡單,指令是: wt -d . 就這樣,搞定:

Azure OpenAI 的申請與使用

圖片
OpenAI 介紹久了,覺得還是需要寫一篇來介紹Azure OpenAI的申請和使用。 和 OpenAI APIs一樣,微軟身為 OpenAI 最大的投資廠商,理當有一組 Azure 上的 OpenAI API 服務。然而其實,兩組API之間,幾乎完全一樣,不管是用法和價格。 那兩者之間的差異如何定位呢? OpenAI 與 Azure OpenAI 之間的差異 目前Azure OpenAI API服務的定位是針對企業用戶,而OpenAI API則有開放給一般個人用戶申請。這使得Azure OpenAI API的嚴謹度與安全性相對比較高。例如,Azure OpenAI API在呼叫時有獨立的Endpoint,針對使用的模型也有獨立的部署,除了不會跟別人共用API呼叫端點因此可以讓安全性和穩定性提升之外,微軟也承諾你上傳的數據不會被用在訓練模型的用途(這也是大家很在意的議題)。 此外,Azure OpenAI API的帳單是跟著Azure訂閱,同時在全球各地有不同的資料中心,這讓開發人員可以選擇距離自己(或自己的客戶)比較近的資料中心進行模型部署,以便於取得最好的運作效能。 由於微軟是透過在地的合作夥伴進行Azure銷售,因此在Azure OpenAI API的使用成本方面,可能因為採購的優惠折扣而有比較低的總體金額,相較之下OpenAI API就是死板板的固定金額,碰到問題的時候大概也只能上討論區尋求解答,比較沒有在地的服務。 OpenAI API有多次因為用戶數量太大,而導致API端點無法呼叫的案例,OpenAI API是全球同一個端點,因此當此問題發生時,很可能大家都會遭遇魚池之殃,全都無法使用。 另外就是,Azure OpenAI API針對具有暴力、自殘、猥褻、情色的文字的過濾相較於OpenAI API更加嚴格,你也可以從後台選擇不同等級的過濾器,來排除可能造成問題的文字,這對服務的安全性也是一種保障。 依照我現在自己測試的結果,最大的差異在於,微軟的API確實有比較嚴謹(有時候甚至過頭)的filter(過濾器),會對偏激或煽情的字眼非常敏感。在呼叫API時,你偶而會收到類似底下這樣的訊息( 註 ): 此外,就是目前(2024/1) OpenAI 有支援 Assistants API,但 Azure OpenAI 我還沒看到(2024/2

周末讀書會 - 姿勢決定你是誰

圖片
某次有位朋友問我:『你現在上台應該都不會緊張了吼,是吧?』 我打從心底笑了出來,回答他:『並不是,我每次上台前都很緊張,不管你看不看得出來,而且沒有一次例外。』 最近,我看完半年前上課時某位老師推薦的『姿勢決定你是誰』一書,內頁第一句話寫著:『有一種勇敢,就是全世界只有你知道自己在害怕。』 其實不管場次大小,是線上或實體,每一次上台前我都還是會緊張、甚至焦慮。 但上台幾分鐘後,我大多能夠慢慢穩定下來,找到自己的節奏。過去我自己也不知道為什麼,但看完這本書之後,我才明白背後的原理。 『姿勢決定你是誰』這本書由 Amy Cuddy 著作,你可能有聽過她在 Ted的演說(我放在底下第一個留言),很多人聽了之後大受激勵。但我得說,其實書的完整內容比起Ted演說要深刻全面的多,從書名或演說15分鐘的內容,你很可能會誤會這本書真正要表達的事情。這本書要說的其實並非很多人誤以為的 fake it till you make it,而是『權力,讓你能夠表現出最佳狀態。』 你看到這邊可能會覺得不可思議。權力,不是那個會讓人腐化的可憎東西嗎? 沒錯,但這邊講的權力並不只是外在的『社會權力』,而是來自內心的『個人權力』。 『個人權力』指的是👉確信對自己的未來能夠掌握的程度。 『個人權力』的反面就是『焦慮』,這個大家就很熟了。但,焦慮的來源是什麼呢? 其實剛剛好就是個人權力的相反,也就是『對自己未來遭遇的不確定性感到無法(或沒有足夠資源可以)控制的程度』。 而『焦慮』,正是讓你無法表現出最佳狀態的關鍵因素。 愈是重要的場合,你愈是會焦慮,愈是焦慮,你愈無法表現出最好的自己。 但,人就是會焦慮啊,上台就是會緊張啊,如何解決這問題? 👉如何讓自己在關鍵時刻能發揮全力,能夠把最好的、真實的那一面呈現出來? 👉如何讓自己隨時能進入『最佳狀態』? 正是這本書真正在講的內容。 順帶一提,從這本書,我也大概搞懂了,為何球類比賽的時候,會有所謂的『主場優勢』? 為何有信仰的人,往往能夠更有力量面對未知的挑戰? 還有那著名的吸引力法則,為何真的有效? 我認為,都是因為恰恰好這些人都掌握到了發揮『最佳狀態』的秘訣。 我覺得,這本書對許多人都會有很大幫助。 有興趣可以找來看看,在這農曆春節假期的周末,推薦給大家。 新的一年,你會成為一個更有力量的自己。 #周末讀書