.NET Walker

前幾天介紹過如何透過 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

引言 在當今由AI驅動的世界中，讓你的應用程式能夠連接先進的人工智能技術，是許多開發者和企業的重要需求。提供ChatGPT 服務的 OpenAI ，提供了一系列強大的 API，包括著名的 GPT 模型，它們可以幫助開發人員在各種應用中實現自然語言處理(NLP)。要使用這些 API，首先需要申請一個 API 金鑰。 以下是申請過程的逐步指南。 步驟 1：進入 OpenAI 網站 首先，前往 OpenAI 開發人員官方網站 。在網站的右上角，您會找到“註冊”或“登錄”選項。如果您還沒有 OpenAI 賬戶，您需要先註冊一個。 步驟 2：登入賬戶 建議採用 Google 帳號以SSO方式進行登入： 登入後，即可前往 https://platform.openai.com/account/billing/overview 網址，並且設定付款方式： 步驟 3：申請 API 金鑰 登入完成付款方式後，即可前往 https://platform.openai.com/api-keys 網址，建立新的 API 金鑰： 建立好金鑰後，即可開始使用 OpenAI 的 API囉。 不妨，先從 文件生成 和 圖像生成 開始？ 相關課程: https://www.studyhost.tw/NewCourses/LineBot

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

OpenAI 在 ChatGPT 紅了之後，開始逐步把背後的 LLM(大型語言模型) 開放給開發人員使用(當然是收錢的)，LLM 作為對談機器人實際的運算主體，它隱藏在雲端的某一個角落悄悄的運行著，而外部的 UI 則是透過 API 來存取這個大型語言模型(LLM)： ChatGPT 採用 Web 的方式實作此操作界面，背後也是透過 OpenAI 的 API 來叫用LLM。而當開發人員有了API可以呼叫LLM之後，我們(企業內的開發人員)，也可以建立自己的界面，或在自己開發的應用程式中直接來使用AI，不管是 App、Web 或是ChatBot (像是 LINE Bot)，都可以透過串接 OpenAI 的 API ，來叫用 LLM 實現各種 AI 加值功能。 其中， OpenAI 釋出的 Chat Completion API 就是作為對談機器人應用的主要API 。它讓開發人員可以直接叫用最新的 GPT 模型(GPT-3 or GPT-4)，生成流暢、(與提示)關聯性高、且自然的回應對話。 在接下來的介紹當中，我們將深入檢視該功能的REST API 呼叫方式，並通過實際例子來展示其用法。 功能概述 從功能面來說，Chat Completion API 能夠理解用戶傳來的訊息(提示)，並且以智能助理的角色來回應，由於LLM具有基礎知識，其回應範圍從日常對話到專業的主題，都可以很好的進行問題解答、情緒分析、故事講述等多種任務，甚至可以生成 JSON(這對於開發人員相當重要)。 要使用 Chat Completion API，開發人員可以通過 HTTP Request與之互動。該API標準的HTTP請求包括以下幾個部分： Endpoint : API 的 URL 端點，就Chat Completion API 來說，目前是 https://api.openai.com/v1/chat/completions。 Headers : 包括用於認證的 Authorization 欄位，其值應為 Bearer [您的API金鑰] 。 Body : 包含請求參數，如 model （指定 GPT 模型）， messages （包含一系列對話歷史和當前用戶消息的陣列），例如： { "model" : "gpt-3.5-tu

我依稀還記得AI的上一波潮流，大概是在2016年前後，各種基於類神經網路模型的應用開始市場化。但當時，還沒有到現在這種遍地開花的程度。 自從去年2023年11月，ChatGPT出現之後，坊間對生成式AI的 各種想像 開始變成了 各種應用 ，圖像生成當然也是其中之一。 如今，透過雲端的API，使用程式碼來動態產生圖片，已經是人人都能夠做的事情。OpenAI除了提供文字的生成，也提供了圖像的生成，採用的是DALL-E技術，最新的更新是DALL-E3，加入了類似於 ChatGPT 的 AI 聊天機器人技術來幫助完善圖像生成的提示，也因為這樣，你只需要透過自然語言，以形容的方式，甚至只需要打個關鍵字，就可以讓AI輕易的為你繪製出想要的圖片，支援不同的大小( 1024x1024 , 1792x1024 , or 1024x1792 )與風格。​ 熟悉REST API使用的開發人員，可以輕易地透過底下這樣的方式，來呼叫API，產生所需的圖片(底下是透過postman工具呼叫API的擷圖)： 如同上面API呼叫中的提示，我們要生成 “ 麥當勞美味的漢堡 ” ，出現的圖片如下: 完整的HTTP/1.1 呼叫為： POST /v1/images/generations Host: api.openai.com Authorization: Bearer ______API_KEY______________ { "model": "dall-e-3", "prompt": "麥當勞美味的漢堡" , "n": 1, "size": "1792x1024" } 你會發現，其實呼叫方式相當簡單，endpoint 是 https://api.openai.com/v1/images/generations ，只需要在http Header中提供 API Key 即可呼叫，API Key的建立方式在 這裡 。不過當然，好的服務是要付費的，OpenAI 關於DALL-E的費用在 這裡 。 使用C#呼叫API的程式碼如下: using System; using System.Net.Http; using Syste

先前曾經提過，My GPT的Action功能，讓我們可以在自行設計的客製化GPT當中，呼叫外部API，這將使我們能夠輕易地透過 ChatGPT 強大的自然語言對話能力，讓用戶透過語音或文字就可以操作企業內的資訊系統。 未來，在企業內想要用語音或文字Chat Bot 來控制電腦請假、簽核、自動填寫各種表單，甚至操控企業的資訊系統，都將不是難事了。(我自己覺得，這對幾十年來，紅了好一陣子的UI/UX 會是一個很大的影響，但我由衷期待一個可以透過語音控制資訊系統的時代來臨) 底下這個MY GPT的Demo，展示出的就是這樣的效果： 具體設計 action 的方式如下： 不過這些在企業內的API，大多都是必須要透過API KEY進行驗證與授權後才能呼叫的。因此，這一篇我們就來看，需要KEY的API，要如何在MyGPT的Action中被呼叫。 首先，底下是一個需要KEY才能呼叫的API，如果我們把 header 中的 API Key 移除，你會發現呼叫時就會出現 401 Access Denied錯誤： 因此，當我們在 MyGPT中使用這組API，當然也會出錯： 這時，你可以在 MyGPT 下方的 Action 處，設定Authentication，並且填入該API所需要的 http header key 和 value： 例如，上圖中的 Ocp-Apim-Subscription-Key Header，就是APIM中很常見用來保護API的訂閱金鑰，前面提過的API，當有金鑰驗證之後，就可以呼叫了： 也因此，當我們對 MyGPT做了同樣的驗證金鑰配置之後，MyGPT也可以順利呼叫受金鑰保護的API了： 或許，要不了多久時間，我們就可以在螢幕前用語音跟電腦說：『幫我訂一張從南港到左營的高鐵票，要找靠窗的座位，8點左右出發，最好是能夠直達的班次…』 然後，我們的訂票GPT，就能夠自動呼叫高鐵班次查詢與購票API，幫我們持續搜尋最適合的班次與座位，最後完成訂票。 靠一張嘴完成所有事情的時代，終於將要出現。 相關課程: https://www.studyhost.tw/NewCourses/LineBot

OpenAI DevDay 最驚豔的展示之一，就是現在人人都可以設計自己的GPT了。 (成果展示影片請參考底下) 不用寫程式，只需要跟ChatGPT以對談的方式，ChatGPT就可以自動幫你做出客製化的GPT，給你的公司、客戶、甚至上架給所有人使用。 只要你有ChatGPT帳號，即可開始建立： ChatGPT會問你想建立什麼功能的GPT，用對談的方式，一步一步引導你做出自己客製化版本的GPT，還可以即時預覽: 你可以用對談的方式(當然也可以上傳文件)，讓ChatGPT知道請假規則： 對談之中，不知不覺的，你的客製化GPT已經完成，你可以選擇公開給全世界所有人，或是只給自己的好友或企業使用： 可預見的未來，將能更進一步的，串接企業系統的API，與自己企業內的ERP、CRM、HR系統整合。 半年前，我在一次受訪中曾說，ChatGPT的出現，將會改寫資訊系統的UI發展方向，如同電影Star Trek中，以自然語言語音控制電腦實現你想要完成的任何功能，現在已經近在眼前。 做完之後，用戶就可以透過客製化GPT以自然語言的對話方式請假了： 改變真的很大，未來將會發生什麼變化，就留給大家自己想像了… 相關課程: https://www.studyhost.tw/NewCourses/LineBot

聚餐中，朋友屢屢接到電話，聽了一兩秒，又直接掛掉電話。 『怎麼了嗎？』我問。 『沒有，都是廣告』朋友無奈的說『現在會打手機給我的，要麼是推銷，要麼是民調，不然就是問我要不要借錢，剩下的十之八九都是詐騙。』 我說：『那你不要接就好啦。』 朋友回答：『沒辦法，怕是潛在客戶打來的，沒接到就少了一個案子的機會。現在，那個 who’s call 的 app 辨識率愈來愈低，很多電話號碼也根本沒紀錄，不接不行啊…』 『最可惡的是，現在很多打來的都是機器人!!! 聲音還很好聽，你聽了半天，它還會問你問題，你被騙回答後，才發現電話另一頭其實根本不是人』朋友忿忿的說。 『哈哈哈哈，你現在才知道喔?』我笑著說。 『我之前不是早說了嗎，如今的 類神經網路 AI ，不僅可以聽懂你說的語音，即時辨識語意，還能直接動態產生擬真的悅耳人聲語音回覆你，這年頭，這些技術都早已不是問題，更何況現在還有 ChatGPT 加持，眼見都不能為憑了，更別說只是遠端的聲音? 』 『真沒有辦法可以反制嗎? 這樣好煩哦 』朋友問。 我說：『其實，我最近有個 Idea，搞不好有用。』 『願聞其詳?』朋友看著我。 我覺得，可以作一個手機 app，然後你有電話來的時候，它就自動幫你接聽，用 AI 語音識別來辨識對方是誰，並且開始跟對方對話，詢問對方的意圖。如果是詐騙、民調、推銷、貸款、投資…就陪對方聊天，聊到天昏地暗，讓對方的行銷(詐騙)成本提高，如此一來，就可以逐漸減少這類煩人的機器人電話。 朋友說：『你是說，我們在手機上作一個聊天機器人app，跟對方的聊天機器人聊天，來反制對方的聊天機器人?』『沒錯。』我回答 『咦? 這有點個人語音秘書的概念吼?』 『對，而且現在這很便宜，可以用極低的成本開發出來。』 『虧你想得出來，那以後就都是AI在講話，AI在寫信，人類要幹嘛?』 『當然是吃吃喝喝、快快樂樂的過一生啦 』我驕傲地說。 朋友不置可否的笑了笑。 這時，手機又響了起來，上面沒有來電者姓名。 『接不接?』我笑著問他。 『接啊，不然怎麼辦，等你的 app 問世嗎?』朋友無奈的回答，拿起手機『喂』了一聲。 我不忍繼續看下去，逕自走向廁所的方向。 『希望他也能夠跟機器人聊的愉快』我心裡這樣想著。

有在使用 ChatGPT(OpenAI API)開發的Developers 一定知道，對於開發人員來說，使用OpenAI API有一個重要的技巧，就是要求 API 回傳JSON格式的物件。 這樣的 Prompt 非常好用，因為 ChatGPT 最強的功能可能不是回答正確的答案，但對於理解用戶說的自然語言，絕對可以說是所向披靡、無人能及。 如果在程式碼中，能夠要求OpenAI API固定的回傳JSON格式，這樣我們就可以輕鬆的Parsing回傳結果。然而，過去的OpenAI API，就算你的 Prompt 寫的再好，在幾十次的呼叫當中，總是會有一兩次回傳給你的不是精準的JSON格式，而是帶有描述性的字串，這可能會讓接收的程式立刻崩潰，除非你在程式碼中額外做一些判斷，然後重新呼叫API，retry到接收到正確的JSON格式為止。但顯然，這樣的結構設計會讓程式顯得有點傻。 如果OpenAI API能乖乖的回傳 JSON 不就好了嗎? 恩~ 恩~ OpenAI DevDay 之後，這件事情實現了。 現在你可以在呼叫 Chat API 的時候，加上底下的參數: "response_format" : {"type": "json_object" } 這會讓回傳的結果一律變成 JSON 形式。 這指令必須搭配新的 Model 👉gpt-4-1106-preview 或 gpt-3.5-turbo-1106 JSON Mode可以確保你拿到的一定是一個可以解析(Parsing)的 JSON 字串，這使得你 parsing JSON 的時候，不會得到 null，開發人員終於可以不再碰到因為 ChatGPT 的回傳不確定性，所可能帶來的程式崩潰問題。 我自己覺得，OpenAI DevDay中新推出的JSON Mode這個小功能反而是對開發人員最大的幫助。

現在的應用程式登入，特別是 Microsoft, Google, Facebook等大廠的網站SSO登入，常常設計有二階段驗證(2FA)，而其中手機App二階段驗證是最常用的模式。主要是因為簡單、迅速、免費，對於用戶、開發人員、網站本身，都是一個很好的選擇。 這種透過手機App實現的二階段驗證，採用的常是一種稱為TOTP(Time-based One Time Password)的技術。簡單的說就是，用戶以先以正確的帳號密碼登入之後，必要時(或每次)再跳出一個驗證視窗，讓用戶輸入另一組隨機產生的N位數密碼，而該密碼會自動出現在你的手機(APP)上，且只能使用一次並有時間限制。 如此一來，即便用戶的帳號密碼不慎外洩，駭客也必須要有用戶的手機，才能登入或執行進階的功能。當然，如果每次都要這樣驗證，用戶肯定會覺得麻煩，所以這類的驗證，往往不會在每次登入時都進行，而是在底下幾種情境下被觸發： 用戶在不尋常的情境下(地區、IP、時間)登入 用戶要進行進階的行為(例如變更密碼) 觸發的時機或演算法因系統特性不同而異，但2FA做法的原理則大致相同，這一篇，我們就來看如何實現2FA。 概念 上圖是 Twilio 網站的 TOTP示意圖，現在有很多業者提供 Authenticator App來實現這個功能，我自己喜歡 Twilio 的 Authy Authenticator, 你可以從底下位置下載： https://authy.com/download/ 使用 Authenticator App 實現2FA 的典型流程如下: 網站針對已登入的用戶產生一個唯一的key值，並以這個Key值產生URL，進而生成QR Code 讓用戶以任何一款Authenticator App掃描該 QR Code，即可在該App上登記註冊。 掃描好QR Code完成註冊後，一般會先做一次六位數密碼驗證，以便於確認用戶有正確完成掃描註冊。 未來，任何需要二階段驗證的時機，網站後台都可以呼叫API產生六位數密碼，並讓用戶在手機上檢視由App產生的六位數密碼，若兩者相同，即可確認用戶身分正確無誤。 實作 程式碼其實一點都不難，而且有現成的NuGet套件可以使用，我整理好的 source code 這邊: https://github.com/isdaviddong/

Azure API Management ( APIM ) 是 Microsoft Azure 服務的一部分，主要功能在協助組織建立、發佈、維護、監控和保護 API。 其主要功能包含： API Gateway 限流和配額 分析和監控 保護 API 現有服務的代理和包裝 … 使用 Azure APIM 可以幫助組織提供統一的 API Gateway、提升 API 管理與發佈、更確保 API 的安全和可靠性。因此，在最近幾年許多企業開始想走微服務或是API first的架構下，常常做為API的對外閘道。 這樣做有一個好處，拿保護API做為例子，透過APIM，你只需要透過設定，就可以讓Gateway 後面的所有API都支援 JWT token驗證，你就無需在每隻API的程式碼裡面，去做token驗證的動作。 這一篇，我們就來實踐這個例子。 使用 Policy 我們做好了一組測試API，呼叫的網址是 https://testapim20231030.azure-api.net/conference/speakers ，這是APIM的雲端位置，它保護了我們原始的API Endpoint，這也是閘道器基本的功能和行為。 你會發現，預設狀況下我們透過postman在呼叫這組API的時候，是無需驗證帳號密碼的： 假設，我們希望讓 APIs 都受到JWT token驗證的保護，那只需要在 InBound Policy 這邊做設定： 加入底下這條 policy: <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized"> <issuer-signing-keys> <key>123456781234567812345678</key> </issuer-signing-keys> <required-claims> <claim name="admin&quo

ChatGPT 也紅了好一陣子，大部分開發人員應該也知道，如果要把ChatGPT的能力整合到自己的專案當中，可以透過 Open AI 所提供的API(或是微軟提供的Azure OpenAI API)。 我們開發LINE Bot也是，想做一個具有ChatGPT能力的LINE Bot非常簡單。如果你是C#開發人員，甚至可以直接用套件和範本來完成。 你可以先用 .net 6 以上的環境建立 WebAPI專案： md testgptbot cd testgptbot dotnet new webapi 完成後，請一併執行 LineBotSDK和LineWebHook範本的安裝： dotnet add package linebotsdk dotnet new install isRock.Template.LineWebHook dotnet new linewebhook 執行後你會看到底下畫面： 這時開啟專案，會看到這些範本內容，主要是LineBotChatGPTWebHookController 這隻： 這隻是寫好的 LINE Bot 範本，同時支援 OpenAI API 和 微軟的Azure OpenAI API。如果您熟悉LINE Bot的開發，只需要把25行的Channel Access Token換掉，順便把 20 行的 Admin User ID換掉(這是處理發生例外的訊息用的)，這樣主程式就完成了。Channel Access Token和Admin User ID這些資訊你可以從LINE Developers Console( https://developers.line.biz/console )找到： 為了讓這個 LINE Bot 可以支援 OpenAI API，我們把需要一個 OpenAI的API Key，這個Key可以從OpenAI的開發人員後台( API keys - OpenAI API )看到： 有了這些資訊之後，只需要把剛才LineBotChatGPTWebHookController 這隻程式碼中的 117 行調整成 return ChatGPT.CallOpenAIChatAPI(…)，並填入剛才取得的key: 將其運行起來之後，你就可以跟這隻 LINE Bot互動了： 你會發現，有了 Ch