[實作上手營] 行動裝置開發及使用Windows Azure開發後端服務實作

作者： -
 
明天主要講的是Azure與Apps(Win8 Apps, WP8 Apps)開發之間的關係，會介紹的是如何從手機和平板App上存取Azure的資源，以及微軟最新的mobile services
 
點選這邊報名。(如果不能點，就是活動過期了，或是額滿了)


留言

張貼留言

這個網誌中的熱門文章

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 »

使用 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 »

使用 Render.com 作靜態網站的自動化佈署

作者： -
圖片
最近在上課時，為了讓不想花錢申請 Azure 雲端服務的學員，也能夠實際體驗 CI/CD 的開發流程，我一直在尋找一個 免費、簡單 的網站部署的平台。希望用戶只要有 GitHub 帳號，就能將 repo 內的網站經由 GitHub Actions 自動佈署到雲端。 試過幾個方案之後，最後選擇了 Render.com 。它不但提供免費的靜態網站託管，還能輕鬆與 GitHub 整合，自動化部署流程幾乎沒什麼難度，非常適合教學與初學者練習使用。 什麼是 Render.com Render.com 是一個現代化的雲端平台，提供簡單、快速且免費的網站服務。​透過與 GitHub 的整合，開發者可以輕鬆地將靜態網站自動部署到 Render，並利用 GitHub Actions 進行持續整合與部署（CI/CD）。 Render 支援多種服務類型，包括： 靜態網站（Static Sites） ：​適用於 HTML、CSS、JavaScript 等前端資源，透過全球 CDN 提供快速、安全的內容傳遞。 Web 服務（Web Services） ：​支援 Node.js、Python、Ruby 等後端應用程式的部署。(但不支援 .net) 私有服務（Private Services） 、 背景工作（Background Workers） 、 排程任務（Cron Jobs） ：​適用於內部服務、非同步處理及定時任務。 如何從 GitHub 部署靜態網站到 Render Render 本身直接支援自動化佈署，你可用 GitHub 帳號申請Render.com ，並且直接建立一個靜態網站： 你可以在建立站台的時候，直接選擇要從哪一個 GitHub Repo 進行佈署: 在選擇好後，你可以配置該網站關聯的資料來源位置(選擇Repo中的資料夾): 設定完成之後，只需要一鍵就能佈署完成： 如果要變成自動化呢? 我們可以在 GitHub Repo 中設定 Action，來進行網站的自動化佈署。 由於Render.Com 提供一個自動化佈署的 WebHook(本質上就是一個API)，只要呼叫該API， Render.com 就可以自動從 GitHub repo 中取得最新的程式碼，並且佈署到伺服器端： 也因此，只要我們為其配置一個 GitHub Acti...
Read more »