Windows 8 Metro Style Apps開發...

作者： -
Keynote新聞介紹  <---Windows 8 的中文介紹

要如何開發Windows 8 Metro Style 的 Apps呢...想嘗鮮的朋友可以看這裡...
(好像好像Silverlight啊~)

留言

張貼留言

這個網誌中的熱門文章

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 »

實際嘗試使用DeepSeek API

作者： -
圖片
突然造成關注的 DeepSeek DeepSeek 是一家於2023年由中國私募基金「幻方量化」創立的人工智慧公司，專注於AI技術。算是少數專注於基底模型訓練的廠商。幻方量化這家公司的負責人很年輕，1985年生，才40歲，同時也是DeepSeek的創辦人。但他為何從投資領域跑來訓練AI模型? 如果對這家企業有興趣，可以參考 這裡 。) 從沒沒無聞到震動市場，主要是因為其最新成果 DeepSeek-V3 與 R1模型，採用「混合專家架構」設計，僅在需要時啟動部分「腦細胞」，以便於降低運算資源消耗。據傳，由於訓練該模型僅使用 2048 部 NVIDIA H800 GPU，耗時約兩個月，以極低的成本(約為560萬美元)完成訓練，但 R1 模型在數學和推理基準測試中表現出色，號稱與OpenAI的o1模型效果相當。 據聞 Meta 和 OpenAI 對 DeepSeek 的快速崛起感到緊張，主要原因在於 DeepSeek 在各種壓力底下，居然可以更低的成本，基於過去開源的基礎完成更高階的成果展現。Meta的首席AI科學家Yann LeCun指出，DeepSeek的成功證明了開源模型(例如他們家的llama)正在超越專有模型(像是 GPT or Gemini)，強調了開放研究與開源的重要性。 總之這些進展引起了矽谷的關注，甚至有Meta員工匿名表示，內部出現了恐慌情緒，工程師們正在連夜嘗試複製DeepSeek的技術。 可預見的未來，模型(不管是雲端或地端)的可選擇性將會大增，在使用的成本上也有機會日漸低廉。因此，我們就來看看 DeepSeek API 的使用。 使用 DeepSeek API DeepSeek 也有提供雲端版本的API，要使用 DeepSeek 的 API，您需要先申請 API 金鑰(以信用卡或PayPal付費)，位於 這裡 : 申請後，您可以透過發送 HTTP POST 請求與 DeepSeek 的模型進行互動。以下是使用 cURL 的範例： curl https://api.deepseek.com/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <DeepSeek API Key...
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 »