Multi-touch? Gesture? how about this???

作者： -
會不會每天接觸電腦，透過開發工具撰寫程式的我們，反而讓電腦世界制約(抑制扼殺)了我們的想像力? 或許，這一切真的有不同的可能性?

留言

承佑表示…
董老師您好
這真是太棒的一場秀，感謝你提供的影片分享，獲益良多，也希望未來能持續多多提供類似的影片。謝謝。
2009年12月29日 晚上11:00
張貼留言

這個網誌中的熱門文章

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...
Read more »

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

當 Dify 遇上 MCP：打造 AI Agent 從此不再燒腦

作者： -
圖片
以前，要做一個 AI Agent，光是想怎麼讓它跟外部系統溝通，就足以讓人頭痛。 但現在不同了。 Dify 與 MCP：天作之合的組合技 先說說 Dify 。如果你還沒用過它，那真的該好好認識一下。Dify 是一個開源的 LLM 應用開發平台，整合了視覺化的工作流程編輯器、RAG（檢索增強生成）管道、AI Agent 開發能力、模型管理等功能。簡單說，就是把原本複雜的 AI 應用開發，變成拖拖拉拉就能搞定的事情。 然後，另外是 MCP （Model Context Protocol）。這是 Anthropic 推出的協議標準，目的是讓 AI 模型能夠標準地串接各種外部工具、與不同的資料來源溝通。 試想一下，以前當我們想讓 AI 接資料庫、串 API、整合各種企業內五花八門的資訊系統時，每套都要自己刻一個介面。有了 MCP，這些都變成像是標準化的「插頭」，插上去就能用。 當這兩個東西碰在一起，會發生什麼事？ 讓流程無所不能的魔法 有了 MCP 之後，Dify (開發的AI Agent) 能做的事情突然變多了。 更讚的是，我之前做了一個小工具，可以把 Dify 直接串到 LINE OA(官方帳號) 上。現在要設計一個 AI Agent？ 輕鬆到太過美好。 以前要花兩週處理的工作，現在可能半小時就搞定了。 實戰：用 MCP 串接請假系統 直接看個案例。 底下這張圖片就是 Dify 串接 MCP 請假系統進行請假的畫面。看到了什麼？對話介面相當乾淨(下圖右方)，使用者只需要自然地說「我要請假」，AI Agent 就會自動處理剩下的流程，蒐集請假所需要的資料，然後透過MCP呼叫串接好的HR請假系統的 API，完成請假功能。 當然，查詢剩餘請假時數，也是如此。 這背後發生了什麼？AI 透過我們做好的 MCP Tools，呼叫了請假系統的 API，確認你的假別、假期餘額、代理人…等資訊。所有這些複雜的商業邏輯，都被優雅地包裝在 MCP Server 裡面。使用者完全感覺不到複雜性，就像在跟一個很聰明的 AI 聊天助理對談而已。 這就是 MCP 的魅力。 它不只是一個協議，更是一個思維模式的轉變——把複雜的系統整合，變成簡單的行動，讓AI Agent可以在與用戶對話互動中隨時調用。 用 .NET Core 打造你的 MCP Server ...
Read more »

使用 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這個小功能反而是對開發人員最大的幫助。
Read more »

使用 Dify API 快速建立一個包含前後文記憶的對談機器人

作者： -
圖片
Dify 這個產品我就暫時先不介紹了，它找到了一個挺好的切入點跨入AI Agent市場。讓不喜歡(或不擅長)寫太多 Code 的開發人員，也可以快速的建立一個具有前後文、記憶的對談機器人。 其實若單就設計 Chat Bot 來談，它本質上和 GPTs 有那麼一點點像，你只需要給一個 system prompt ，再加上一點點的資料上傳做為 RAG 的數據來源，就可以生出一隻有模有樣的對談機器人。 但 GPTs 做出來的 Chat Bot 被綁在 ChatGPT 的 UI 裡面，你不容易把它跟 LINE Bot (LINE 官方帳號) 或其它 UI (例如 MS Teams) 串在一起，而 Dify 呢? 則給你了一個 chat-messages API，讓你能很快的實現這個功能，把你在 Dify 平台上做好的 Chat Bot 轉變成可以正式運行的 LINE Bot 或 其它 Bot。 這也是今天我們要介紹的部分。 建立 Assistant 我們先用 Dify 以底下這個 system prompt 建立了一個請假助理： 發佈後，你可以在Dify 內建的 Web UI 上測試： 你會發現，這個 chat bot 已經有著基本的記憶，然後可以依照 system prompt 完成對談和任務。 不要問我在這邊建立出一個假單有什麼用，正常情況下是要直接讓 chat bot 寫入資料庫(例如 HR 系統，直接完成請假)，只是我們還沒談到這一段，這部分以後再展開來談。 chat-messages API 好，透過上面那樣建立一個對談機器人超容易，且內建就有了記憶和前後文的功能。讓開發人員快樂的不得了。跟使用無腦 GPTs 生成術差不多。然而，如果只能在 Web 上用，不能串接 MS Teams、LINE…等介面，做了也是白搭。 但，Dify 貼心的提供了 API，我們來試試看。先Gen個 API Key： 生成了 API key 之後，你只需要透過底下這樣的 rest api，即可進行呼叫： 你會發現，開發人員只要使用單一的這一個 https://api.dify.ai/v1/chat-messages API 即可進行對談。每次只需要透過 query 輸入用戶說的話，response 中的 answer 則是 LLM (Assist...
Read more »