發表文章

目前顯示的是 11月, 2023的文章

AI to AI Communication

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

使用 JSON Mode 讓 OpenAI API 乖乖回傳 JSON

圖片
有在使用 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/

在APIM中自動使用Jwt Token統一進行驗證

圖片
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