跳到主要內容

發表文章

目前顯示的是有「Azure Blob Storage」標籤的文章

【Azure OpenAI】o1 模型與 2024-09-01-preview API

距離上篇在 Early Access Playground 試用 o1 模型後又過了兩週,今天終於等到 API 開放使用啦!本篇將紀錄如何使用 Python SDK 存取 o1 模型。 系列文章 【Azure OpenAI】快速試用 o1 模型 模型佈署 在先前開放的 Early Access Playground 中使用 o1 是不需要另外佈署模型的,不過回到使用 API 來存取 o1 模型,就需要像之前的模型一樣先進行佈署才能使用,相信大家都很熟悉了。 使用 Python SDK 一樣使用熟悉的 openai 套件: 2024-09-01-preview 初始化的方式與先前模型都一樣,需要注意的是 o1 模型目前只能使用最新的 API 版本 2024-09-01-preview 來訪問。 Chat Completions 將 model 填入 o1-preview ,或是你的模型佈署名稱, messages 也一樣是歷史對話堆疊的 List。 回應如下: 查看 Token 使用量 內建 Chain of Thought 的 o1 比起過往的模型會消耗較多的 Token,因此我們特別把 Token 使用量拉出來看。 回應如下: 其中 prompt_tokens 、 completion_tokens 、 total_tokens 在先前的 API 就已經存在了,分別代表Token 的 Input、Output 與總使用量,而在新的 completion_tokens_details 中可以看到  reasoning_tokens 使用了 320 個 Tokens,居然佔了總輸出 Token 的 80% 以上! 控制 Token 成本 已往我們可以使用  max_tokens 參數來控制 Token 的用量,但在 o1 模型中棄用了 max_tokens ,取而代之的是使用  max_completion_tokens 參數,來看看這段程式碼: 回應如下: 沒東西?那再看一次 Token 量。 回應如下: Token 居然是有被使用的! 這表示 max_completion_tokens 並不像過往使用  max_tokens 這麼簡單,先前在回應遇到...

【Bicep】自動還要更自動的 AOAI On Your Data

 Azure OpenAI 上的 On Your Data 是微軟最早推出的 RAG 架構,沒有太多複雜的 Chunking 手法,甚至直接不處理文件中的圖文夾雜問題,有的就是基本的 Embedding 與向量搜尋機制,主打的是一個快速串接流程。 On Your Data 藉由 Azure OpenAI Studio 介面提供使用者快速完成所有服務的串接,而背後主要由兩個動作組成,On Your Data 首先會使用 Azure OpenAI 提供的 Ingestion Jobs API 建立 Azure AI Search、Azure OpenAI 與 Storage Account 之間的串聯設定,接著再使用存放於 GitHub 上的 Sample Chat App with AOAI 做為 App Service 的原始碼來源來建立一個範例網頁。 儘管 Ingestion Jobs API 已經包裝了大部份的流程,但這兩項主要動作還是需要人為點擊來觸發。本篇將紀錄如何使用 Bicep 建立 On Your Data 流程與其範例網頁,以達到真正的自動佈署。 完整的 Bicep 程式碼已經整理在我的 GitHub 上,歡迎參考以下連結。 相關連結: https://github.com/charliewei0716/azure-openai-on-your-data-with-bicep 系列文章 【Bicep】從開發到佈署的工作流程 【Bicep】使用佈署指令擴充 Bicep 功能 【Bicep】自動還要更自動的 AOAI On Your Data(本篇) 建立儲存體帳戶 首先我們需要一個儲存體帳戶與 Blob 容器來存放 RAG 使用的原始文件。 建立 Azure OpenAI 最重要的 Azure OpenAI 資源,同時佈署目前最新的 gpt-4o 與 text-embedding-ada-002 模型。 啟用的受控識別會在稍後賦予對應權限,另外這邊需要注意使用的訂閱在該地區的 Azure OpenAI 額度。 建立 AI Search 選擇基本 Basic 等級的 AI Search,一樣也啟用受控識別。 服務間的授權 到此我們建立的儲存體帳戶、Azure OpenAI 與 AI Search ...

【Bicep】使用佈署指令擴充 Bicep 功能

在 Azure 中的所有資源都是由一組 Azure Resource Manager (ARM) 模板定義出來的,但以純 JSON 格式組成的 ARM 模板在開發或閱讀時都非常不方便,於是微軟推出了一組 IaC 工具 Bicep,讓使用者以更像程式開發的創作方式來生成 ARM 模板。 對於 Azure 資源的操作主要可以分為 Control Plane 與 Data Plane,Bicep 與 ARM 模板主要都是負責 Control Plane 的動作,而 Data Plane 大部分都是透過 Azure CLI、Azure Power Shell 或 REST API 來實現,這導致使用純 Bicep 在某些情境下可能沒辦法做到全自動化佈署,因此在 Bicep 中推出了佈署指令來解決這個問題。 以下我們將以儲存體帳戶做為範例,使用 Bicep 建立基本的儲存體帳戶與容器,並透過 Bicep 中的佈署指令使用 Azure  Power Shell 在容器中寫入一個測試檔案。接下來如果你需要一個方便執行 Bicep 的環境,可以參考下方連結部落格使用 GitHub Codespaces 搭建 Bicep 開發環境。 系列文章 【Bicep】從開發到佈署的工作流程 【Bicep】使用佈署指令擴充 Bicep 功能(本篇) 【Bicep】自動還要更自動的 AOAI On Your Data 使用 Bicep 建立儲存體帳戶 我們直接由一個現有的 Bicep 範例開始,以下範例將建立儲存體帳戶與一個名為 data 的 Blob 容器。 建立使用者指派的受控識別 為了有足夠的權限可以使用佈署指令執行 Azure Power Shell 指令,我們需要先建立一個使用者指派的受控識別。 賦予權限 稍後我們將使用 Azure Power Shell 指令在 Blob 容器中寫入一個檔案,為了執行這個動作,我們將賦予 參與者 與 儲存體 Blob 資料參與者 兩個內建腳色給剛剛建立的受控識別。 建立佈署指令 事前準備完成後可以開始建立佈署指令了,我們先從一個 deploymentScript 的基本框架開始: 我們在 kind 中指定使用 Azure Power Shell,並且在  iden...

【Azure Blob Storage】使用物件複寫同步儲存體帳戶

同步兩個儲存體帳戶內的 Blob 容器是個很常見的需求,做法也有非常多種,從單純的在 VM 中啟 Azcopy 服務,到 PaaS 方案的 Azure Data Factory 都可以做得到,但如果什麼東西都不想維護的話,那 Blob Storage 的物件複寫功能肯定是個好選擇。 架構說明 物件複寫可以跨地區、跨租用戶的在兩個 Storage Account 間運作,本篇為展示方便,將會在同一個租用戶下建立為於不同區域的 Storage Account。 注意事項 要使用物件複寫功能必須要先在 Azure Storage Account 上啟用以下兩個功能: 在 來源端 的 Storage 啟用變更摘要。 在 來源端 和 目的地端 的 Storage 啟用 Blob 版本控制。 要特別注意的是變更摘要與 Blob 版本控制這兩項功能都會產生額外的費用,開啟前還是要自己衡量一下使用量。 建立 Storage Account 來源的 Storage Account 我們選擇建立在東南亞地區,規格使用一般用途 V2。 做為來源的 Storage Account 記得要開啟「版本設定」與「變更摘要」。 建立完成後進到 Storage Account 再建立一個名為「source」的容器。 接著再使用相同規格在美國東部建立目地端 Storage Account 與 Blob 容器就可以了。 編寫複寫原則 Storage Account 建立完成後就能開始設定物件複寫,最簡單的方式是可以透過 Azure Portal 點擊設定完成,但如果有跨租用戶的需求就沒辦法只使用 UI 完成,再加上我覺得使用定義檔的方式比較清楚明瞭,所以一直以來都是使用這個方式。 物件複寫原則的定義檔使用的是 Json 格式,直接看以下範例: properties.policyId :固定  default ,後續會知道原因。 properties.sourceAccount & properties.destinationAccount :兩個 Storage Account 的完整識別碼,可以在「設定」→「端點」的頁籤中找到。 properties.rules[0].ruleId :先保持空字串。 properties...

【Bicep】從開發到佈署的工作流程

在這個年代,靠這行吃飯的勢必都需要學幾項 IaC 工具,最近遇到的專案剛好有機會可以練習,考量到公司內部幾乎是純 Azure 的環境,就直接選擇 Azure 專用的 Bicep 了,趁這次也將過程記錄下來。 本文不打算深入探討 Bicep 的語法細節,因為這些都可以在官方文檔中找到,反之,重點會放在如何利用 VSCode 上的 Bicep 擴充模組來簡化開發,所有工具將打包在 Devcontainer 中搭配 GitHub Codespaces 搭建乾淨的開發環境,整合 GitHub Action 在每次推送時建構 ARM 模板,最終會生成一個美觀又功能強大的一鍵佈署按鈕:Deploy to Azure。 以上這些已經在我的 GitHub 上整理成一個範例,歡迎使用以下連結。 相關連結: https://github.com/charliewei0716/azure-bicep-codespaces-sample 系列文章 【Bicep】從開發到佈署的工作流程(本篇) 【Bicep】使用佈署指令擴充 Bicep 功能 【Bicep】自動還要更自動的 AOAI On Your Data 開啟 GitHub Codespaces 使用 GitHub Codespaces 的方式非常簡單,先進到下方 GitHub 連結,在登入 GitHub 後點擊 README.md 中的「Open in GitHub Codespaces 」。 相關連結: https://github.com/charliewei0716/python-fastapi-azure-cosmos-db-todo-list Open in GitHub Codespaces 進入 Codespaces 時不用做任何動作,它會在啟動時自動安裝 Bicep 擴充模組與 Azure CLI 工具,直到在瀏覽器中看到 VSCode 的畫面就代表成功。 使用 Bicep 擴充模組開發 VSCode 上的 Bicep 擴充模組是官方在開發 Bicep 的首推工具,同時也已經安裝在我們剛剛開啟的 Codespaces 中了。 首先我們試著定義一個儲存體帳戶,但我們不打算背一堆 Bicep 寫法,或是又要跳到哪篇文檔中複製出來修改,現在只需要要輸入代表儲存體帳戶的前幾碼英文字母「sto」,就能從清單中看...

【Azure Kubernetes Service】在 AKS 中使用 NFS 靜態掛載 Azure Blob Storage

運行在 AKS 中的 Pod 如果有產生或需要使用到資料時,一般都會將資料存放在容器的肚子裡頭,這會導致在容器或 Pod 重啟時丟失資料,若要解決這個問題,就需要在 AKS 上掛載額外的儲存體。 在 Azure 中當然就是首選 Azure Blob Storage,本篇文章會介紹使用 NFS 連線 Blob Storage,使用靜態方式佈建磁碟區 (PV) 並將其與 Pod 掛接,以此將 Blob Storage 作為 Pod 的儲存體使用。 建立 AKS 在將 AKS 掛載上 Blob Storage 前,必須先為 AKS 啟用相應的 CSI 驅動程式,而在建立 AKS 時順帶啟用驅動程式,使用以下 az cli 指令是最快速的方式。 其中帶上的  --enable-blob-driver 參數即是在建立 AKS 時啟用 CSI 驅動程式。AKS 的建立其實還有很多複雜的設定,不過這並不是本篇的重點,其他的參數就不多加贅述了。 AKS 建立完成 建立 Azure Blob Storage 我們首先需要建立儲存體帳戶,其中在「進階」頁面記得要勾選「啟用網路檔案系統 v3」,因為我們需要使用 NFS 來連線 Blob Storage。 啟用 NFS v3 而啟用 NFS v3 的必要條件是啟用階層命名空間,記得要一起勾選。接著進入「網路」頁面: 設定 VNet 因為啟用了 NFS v3,在網路存取這邊就沒辦法設定「在所有網路啟用公用存取」;再者也因為後續是要讓 AKS 來存取這個 Storage,所以這邊也需要選到 AKS 所在的 Subnet 並透過 Service Endpoint 的方式提供 AKS 來訪問,關於 Service Endpoint 的詳情可以參考以下連結。 相關連結: 【Azure VNet】虛擬網路中的服務端點 儲存體帳戶建立完成後,如下圖再任意建一個要掛載上 AKS 的 Blob 容器就可以了。 建立 Blob 容器 PV 會使用到的資源我們都已經建立完成了,接著我們需要編寫 AKS 中的 PV。 其中比較需要注意的地方: spec.capacity.storage :事實上 Blob Storage 的空間是無限的💲💵,但在 Kubernetes 中該參數是必要的,所以任意給一個數值即可。...

【Azure Data Factory】當 ZIP 上傳到 Blob Storage 時自動執行解壓縮(下)

接續前一篇,我們已經完成解壓縮 Pipeline 的設定,如果還沒看過的話建議先從下方連結觀看,接著我們希望 Pipeline 是能被自動觸發的,而不是每次都需要輸入檔案名稱來手動觸發,在這最後一篇中我們會完成這個設定。 相關連結: 【Azure Data Factory】當 ZIP 上傳到 Blob Storage 時自動執行解壓縮(中) 在 Azure Data Factory 中新增觸發程序 先回想一下我們的情境,解壓縮管線已經可以正常運行,但我們希望的是它在 .zip 檔上傳到 Blob Storage 時自動執行一次,在 Data Factory 中可以使用觸發程序來完成這件事。 選到左側「管理」→「作者」→「觸發程序」→「新增」,右側會跳出下方畫面: 設定觸發程序 在類型的部份有根據特定時間執行的有「排程」與「輪轉視窗」兩類,而我們需要的是「儲存體事件」,接著選到上篇中建立的 Blob Storage 與 Container,這邊要注意 Container 的格式需要在前後都多一個斜線。 再來因為我們只想針對 .zip 檔上傳時來執行管線,在「Blob 路徑,結尾為」填入「.zip」,並在「事件」勾選「已建立 Blob」,最後點擊就可以了。 觸發程序建立完成 這時可以回到 Blob Storage 所在的資源群組中,會看到自動建立起來的 Azure Event Grid,其實Data Factory 中的儲存體事件就是使用 Event Grid 來完成的,所以如果看到群組內突然多了一個服務不要覺得奇怪喔! 建立觸發程序時自動帶起的 Event Grid 在管線上新增觸發程序 接著我們要把做好的觸發程序與管線連接上,先回到管線的畫面上方,選擇「新增觸發程序」→「新增/編輯」 在管線上新增觸發程序 在彈出的視窗中選到剛剛建立的觸發程序後,如以下將「@triggerBody().folderPath」和「@triggerBody().fileName」設定上去,這樣管線就能抓到是由哪個 .zip 檔上傳所觸發的,同時針對這個檔案執行解壓縮。 在管線上編輯觸發程序設定 全部發行 以上我們終於完成所有 Data Factory 的設定,最後別忘了點下左上角的「全部發行」! 記得點擊全部發行 最終測試 再次使用與上一篇相同的 t...

【Azure Data Factory】當 ZIP 上傳到 Blob Storage 時自動執行解壓縮(中)

接續前一篇,我們已經完成了 Data Factory 到 Blob Storage 的連線設定,如果還沒看過的話建議先從下方連結觀看,接著我們會正式開始編寫執行解壓縮的 Pipeline。 相關連結: 【Azure Data Factory】當 ZIP 上傳到 Blob Storage 時自動執行解壓縮(上) 在 Azure Data Factory 中新增資料集 而在開始建立解壓縮 Pipeline 前,還需要先完成資料集的設定,所有會接觸到的資料都需要先使用 Data Factory 中的資料集做一次宣告,才能在 Pipeline 中被使用。 首先選到左邊的「作者」→「資料集」→「新增資料集」, 新增資料集 右側彈跳出的視窗中一樣選擇 Gen2 做為資料存放區,而資料格式如果還不確定的話可以直接選擇「二進位」, 選擇二進位資料格式 接著進入設定屬性頁面,這邊可以直接從下拉選單找到剛剛建立好的連結服務,而下面的檔案路徑先保持空白就好,我們後面再把它填上, 資料集屬性設定 點擊確定後就會看到建立出來的資料集,是一個二進位的格式。再來我們先進到「參數」的頁籤中,如下圖分別新增名為「folderPath」與「fileName」的參數: 在資料集中新增兩個參數 建好參數後再回到第一個「連接」頁籤,先將壓縮類型選到我們這次的目標:.zip 檔,而檔案路徑就比較特別一點,需要如下圖填入「@dataset().folderPath」與「@dataset().fileName」: 資料集中的連接設定 「@dataset().folderPath」與「@dataset().fileName」是資料集內內建的變數表達式,分別表示使用我們在「參數」頁籤設定的「folderPath」與「fileName」兩個參數,所以後續在使用這個資料集時我們需要在呼叫的當下給定「folderPath」與「fileName」兩個參數的值,而這兩個值會再傳遞到「@dataset().folderPath」與「@dataset().fileName」中。 第二個資料集 如同前面提到的:資料集是資料的一個宣告,可以把我們剛剛設定好的第一個資料集視作要被解壓縮的 .zip 檔,而現在對於被解壓縮出來的資料也需要使用第二個資料集來表示它。 與前面的動作都一致,選到「作者」→「資料集」→「新增資料...