.NET Walker

先前我們 提到了 透過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...

身為 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 輕易地建立聊天機器人/智能助理，我們之前(參考 這篇 )也看到了如何用自然語言驅動 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...

之前開直播的時候，和線上朋友聊到，因為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...

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...

過去，如果你有用 Azure OpenAI 開發對談機器人，其中最麻煩的事情之一，大概就是記錄和處理歷史對談訊息。但歷史對談訊息對於AI的正確回覆佔有舉足輕重的角色，不記錄不行。 這是因為本質上API的呼叫是無狀態的(Stateless) 因此，在與API交談的過程中，你每次呼叫API都必須把過去的訊息，當作參數重新傳到後端，這樣API後面的AI Model才會知道先前跟用戶說過了什麼。但如此一來，對談越多，不就得花費愈多Token嗎? 是的，沒錯，這是過去透過OpenAI開發對談機器人時的一個難題。 2023年11/06，OpenAI舉辦了DevDay，在keynote的場次中，Sam Altman介紹了新的API --> Assistants API，把對談機器人的開發，再繼續優化到更簡單的步驟。 搭配Assistants API，你可以輕易建立出一個智能助理(或客服機器人)，除了讓開發人員更省事之外，還包含了類似RAG的功能，可以將企業內的資訊先餵給這個AI助理。 如今，Azure OpenAI也提供了這個服務，在 美國東部2 、 澳大利亞東部 和 瑞典中部 率先提供了這個服務(Preview)，同樣的，他提供了一個遊樂場後台： 初次進入，畫面上出現『找不到任何佈署』? 那你就給他來個新的佈署： 系統會引導你建立一個獨立的模型: 接著就可以透過該模型來建立助理了： 填寫完智能助理的名稱、提示(system prompt) 之後，就可以儲存和測試了。 乍看之下，和原本的聊天對談沒什麼不同，但背後有一個很大的差異，那就是，過去的聊天對談，前後文(Context)的實踐是透過把先前與機器人的互動(訊息)，每次重新回傳給API來實現的，而現在這個助理(Assistant API)則是透過一個新的物件，叫做Thread(執行緒)，來保存這些對話記錄。簡單的說就是，你不用再自己保存對話記錄了： Thread(執行緒)聽起來有點抽象，你可以把一個執行緒想成一連串的對話記錄，其中有一則一則的訊息(Messages)： 當用戶輸入一則訊息(放上Thread)給機器人(assistant)，機器人回覆這則訊息(也放上Thread)，這樣就構成了一個Run。 也因此，透過 Assistant api 操作的對談流程，原則上大概是底下這...

先前介紹過 OpenAI API 的 DALL-E-3 ，但如果你要在Azure OpenAI 上使用相同的功能，不管是模型的佈署和API的呼叫，兩者之間都有些不同。 使用在Azure OpenAI上的DALL-E-3，你必須把服務建立在瑞典中部(Sweden Central)的資料中心，才能享用該模型: 目前只有該資料中心有提供 DALL-E-3 的模型選項，當你將AOAI的服務建立在Sweden Central資料中心，就會在模型佈署中，找到底下這個 dall-e-3 的選項： 如果你透過 Azure OpenAI Studio 這個後台測試 DALL-E，你會發現系統會自動幫你佈署 dalle3 模型： (動畫) 有了DALL-E-3模型之後，你就可以透過自然語言產生圖像了： 如果你要採用 API 來生成圖像，可以參考微軟 官網 上的 API 使用方式。 我們也可以透過 Postman 呼叫該 API： 台北 101 的下雪美景，就這樣出現了： 但你需要注意到，Auzre OpenAI DALL-E-3 的 API Endpoint 也明顯與Chat不同: https://{AOAI服務名稱}.openai.azure.com/openai/deployments/{Dalle3佈署名稱}/images/generations?api-version=2023-12-01-preview 不過掌握好了之後，透過程式碼來動態建立圖像，也就只是小菜一碟了。 相關課程： https://www.studyhost.tw/NewCourses/LineBot

昨天去參加G社群舉辦的活動，想說來認識一下Gemini。 來到了據說是全台灣最高的活動舉辦場合，也具體實作了一下 Gemini API 的使用。 聆聽分享的過程當中，台上講者問大家說：『現在已經有使用 OpenAI API 的舉手? 』(恩…很多)。 又問：『現在已經在使用 Gemini 的呢?』(哇…也不少)。 再問：『那使用 Azure OpenAI 的呢?』 我正想舉手，往四周一看，哇靠，怎麼一個人都沒有! 真的假的? 原來來到不同的陣營，民調數據會差這麼多? 🤔 接著台上講者繼續問大家，用什麼語言寫AI程式，看來 Python 還是大宗，我本來想喊 C# 的，但看看周遭氛圍，我決定暫時先觀望一下。 然後講者開啟自己的 github repo，點選一個 badge ，把 github 的source code 帶到 colab 中，順口又問了一句：『應該大家都用過 colab 吧?』 (我本來又想喊…“沒有”) 沒想到講師立即說：『恩…很好，顯然大家都有用過…』😮😮😮 我偷偷看了一下隔壁的朋友，耶欸，大家好像還真的都挺熟悉colab的呢。哇，果然隔『營』如隔山。 接著我看講者嘩啦嘩啦地在colab中運行每一個程式碼片段，行雲流水，很是順暢。也難怪，大家喜歡用 python，雖然從我的角度來看，一直覺得它其實跟 Visual Basic 有點像。 不過做Labs的過程中，我確實也開始覺得，有寫好的互動式腳本，上課時還是頗方便，大家只需要點個按鈕 clone 過去，然後程式碼都寫好了，只要改改參數，就可以一段一段運行了，難怪大家覺得 OpenAI API 和 Gemini API 用起來很簡單。 但其實，Azure OpenAI 也不難啦~ 做完 Gemini Lab 後，我索幸順手也寫了一個 python 的 notebook ，用 python 來呼叫 Azure OpenAI ，我把它放在 github 上了。又效法講者的作法，為它做了一個 badge ，讓用戶可以從 github repo 直接連到 colab。操作動作如下： 然後我們就可以在 colab 中，透過互動式的方式，一段一段把程式運行完，體驗一下 Azure OpenAI API的呼叫。你看到上面的影片，就是整個操作過程。 由於notebook程...

前幾天介紹過如何透過 LINE Messaging API 來串接 OpenAI API，實現具有GPT能力的LIEN Bot。但如果你的 ChatBot 不想只支援 LINE 怎麼辦呢? Microsoft Bot Framework 是另一個不錯的選擇。 Microsoft Bot Framework 提供了一個健全的平台，讓開發者可以建立、測試、和部署具有高度互動性的聊天機器人，除了可以直接串接 LINE Bot， 還支援 Teams、Telegram、FB、Skype、Alexa、Web UI、甚至 email 和 SMS…等不同的Channel。 當它與 OpenAI 的 API 結合時，不僅可以快速的建立出對談機器人應用 ，更能確保了機器人可以在多種平台上運行，包括網頁、社交媒體平台和行動應用，使其更具可訪問性和便利性。 底下這個在MS Bot模擬器中的截圖，就是我們在上課的時讓學員做出的成果，你會看到透過 Bot Framework 設計的對談機器人，具備理解前後文與對談記憶，由於ChatGPT的加持，可以輕易的理解用戶的對談訊息，從而輕鬆地蒐集用戶的購票資訊，協助用戶進行購票。 這個範例的最後，產生了一個可以傳遞給 購票系統的 JSON 內容，只需要再加上呼叫 購票系統的API，就可以在對談中自動完成協助用戶購票的動作了。 讓 OpenAI API 產出 JSON 是為了方便開發人員後續可以直接呼叫 售票系統的 API 來完成真正的購票行為，如此一來可以更方便的做系統間的整合。 而採用 MS Bot Framework 開發的好處在於，可以輕易地透過 Azure Bot 的維護後台，以設定的方式，就可以讓串接好 ChatGPT 的 Bot 與各種不同的頻道進行整合: 這樣我們只需要撰寫一次，就可以直接支援各種不同的操作介面或App。 基本款的 MS Bot Framework + ChatGPT 範例，可以參考筆者的 Github repo: https://github.com/isdaviddong/DemoChatGPTwithMSBotFramework.git 相關課程: https://www.studyhost.tw/NewCourses/LineBot

ChatGPT的出現，是對談機器人一個明顯的分水嶺。 你肯定用過許多網路銀行的對談機器人服務，或是類似的其他機器人，然而效果總是讓人覺得差強人意。原因不外乎幾點，過去的對談機器人很明顯無法明白你說的話，這是NLU(natural language understanding)能力的不足。再來，過去的對談機器人大多沒有前後文的概念，也沒有記憶，因此對談起來常常讓你覺得答非所問，牛頭不對馬嘴，整體效果並不理想。 但ChatGPT卻讓人完全沒有這樣的感覺，主要是ChatGPT對於NLU有極強的能力，ChatGPT本身又有前後文記憶，這讓整體對談效果理想非常多。 透過OpenAI API，我們也可以用LINE Bot做一個類似ChatGPT的客服機器人，這一篇，就step by step來跟您介紹，如何實現一個ChatGPT能力加持的LINE Bot。 建立LINE WebHook 建立LINE Bot的方式過去我們在Blog有介紹很多次了，我們這邊就不再贅述。 我們在建立好LINE Bot之後，可以建立一個WebHook的開發專案(使用 C#與 .net core)： md folder cd folder # 建立 Web API 專案 dotnet new webapi -f net5.0 # 安裝套件 dotnet add package linebotsdk # 安裝程式碼範本 dotnet new --install isRock.Template.LineWebHook dotnet new linewebhook # 開啟VS Code ( OR vs2019/vs2022) code . 上面這段CLI指令會建立出一個 .net core 的 webapi 專案，建立好後透過 VS Code 開啟，並且修改 LineBotChatGPTWebHookController.cs 中的 Admin User ID 與 Channel Access Token： 這個動作是讓 WebHook 可以控制你的LINE Bot來 接收 與 發送 訊息。 接著看同一支程式碼中的 117 行，由於我們要呼叫 OpenAI 的 ChatCompletion API，因此我們把程式碼中的 117 行從 CallAzureOpenAIChatAPI ...

OpenAI 的 Completions API 雖然已經是屬於legacy的API，但其實一直以來它都是一個挺方便的文字生成工具。 這個 API 提供了對 GPT-3 和最新的 GPT-4 模型的存取，允許用戶輕鬆創建自然語言應用。無論是文章 自動生成 、 語言翻譯 還是 情緒分析 ，Completions API 都是相當便捷好用的API。 要使用 OpenAI Completions API，開發人員可透過 POST 方法與 API 互動。在 Request 的 Header 中，應包含 Authorization 字段，其值為 Bearer [你的API金鑰] ，以認證API的使用者身份。 ( 金鑰申請方式 ) Request 的 Body 則需包含數個參數，主要是 model （指定使用的 GPT 模型）， prompt （輸入給模型的提示文本），以及 max_tokens （指定生成文本的最大長度）等。透過指定這些參數，開發者可精確控制生成出的文字，例如： 你會發現，當使用 OpenAI Completions API 的 POST 請求時，Body 部分的撰寫相當重要。這部分的內容指導了 AI 模型如何回應需求。其中， prompt 屬性是控制AI Model生成文字的起點，而 max_tokens 則指定生成內容的最大長度。其他可用的參數包括 temperature （控制回應的創造性）， top_p （影響回應的多樣性），以及 frequency_penalty 和 presence_penalty （用於調節特定詞語的重複出現）。合理的設定這些細節，能夠讓開發者有效地定制模型的回應，以符合其特定應用場景的需求。 我們再透過一個例子來看 Completions API的另一種用法。假設我們想要生成一段關於人工智能未來趨勢的文字，我們的 POST 請求的 JSON Body 可以如下: { "model" : "gpt-3.5-turbo-instruct" , "prompt" : "描述未來五年內人工智能的發展趨勢" , "max_tokens" : 1450 , "temperatu...