距離上篇在 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 這麼簡單，先前在回應遇到...
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
系列文章
建立儲存體帳戶
首先我們需要一個儲存體帳戶與 Blob 容器來存放 RAG 使用的原始文件。
建立 Azure OpenAI
最重要的 Azure OpenAI 資源，同時佈署目前最新的 gpt-4o 與 text-embedding-ada-002 模型。
啟用的受控識別會在稍後賦予對應權限，另外這邊需要注意使用的訂閱在該地區的 Azure OpenAI 額度。
建立 AI Search
選擇基本 Basic 等級的 AI Search，一樣也啟用受控識別。
服務間的授權
到此我們建立的儲存體帳戶、Azure OpenAI 與 AI Search 是 On Your Data 的三個主要服務，三者之間的授權方式我們選擇使用受控識別，這是官方建議的最佳作法。
根據 On Your Data 官方文檔，整個流程共需要以下五組授權，一樣使用 Bicep 來完成。
使用佈署指令觸發 Ingestion Jobs API
如同前面提到的，Ingestion Jobs API 已經打包了三個服務之間的串接流程，可惜的是 Ingestion Jobs API 是屬於 Data Plane 的操作，使用純 Bicep 是沒辦法完成這個動作的。
不過現在我們可以使用佈署指令來觸法 API，佈署指令會將我們的 Azure Power Shell 腳本放入獨立的容器實例中執行，藉此可以完成對 Data Plane 的所有操作，詳細的使用方式建議可以觀看以下文章。
建立使用者指派的受控識別並賦予權限
佈署指令需要使用使用者指派的受控識別來進行授權，我們會對其賦予參與者與儲存體 Blob 資料參與者兩個內建腳色。
建立佈署指令
我們將使用佈署指令完成「上傳 RAG 文件」與「觸發 Ingestion Jobs API」兩項 Data Plane 操作。
藉由儲存體 Blob 資料參與者的權限，使用 Set-AzStorageBlobContent 指令上傳了 data.txt，這份文件將模擬 RAG 中使用到的來源文件。
使用 Invoke-RestMethod 指令觸發 Ingestion Jobs API，這個動作使用的身分認證是 Azure OpenAI 建立完成時回傳出的 API 金鑰。
最後我們確保佈署指令是在所有身份授權動作完成後才會執行。
建立 On Your Data 範例網頁
建立範例網頁的動作原本設計是透過 Azure OpenAI Studio 觸發，其中將會建立 App Service 與 App Service Plan 兩項資源，所以以下 Bicep 我們將仿照 Studio 的行為，同時完成所有需要的設定。
使用的 App Service Plan 是 Linux 環境與基本的 B1 等級。
而 App Service 使用原始碼佈署方式，並設定了一個官方 GitHub 專案做為原始碼來源，程式中需要使用到的環境變數也一起設定到 App Service 中。
最後為了架構單純，我們關閉了程式中預設的 Microsoft Entra 登入認證，取而代之的是為 App Service 的受控識別賦予 Cognitive Services OpenAI User 角色。
測試 Bicep
最方便的方式是使用 Azure Cloud Shell 來測試 Bicep，先建立一個單獨的資源群組。
接著將 Bicep 儲存為 main.bicep 後執行 az deployment 指令。
Portal 中會看到所有被建立的資源：
進入 App Service 的「部署」→「部署中心」，確認佈署狀態：
有時在第一次 App Service 與 GitHub 連動時會部署失敗，這時候只要再點擊上方「同步」後等待數分鐘即可。
最後進入 App Service 的網址，試著詢問一些與資料相關的問題：
測試成功！🎉
總結
自動還要更自動，我們結合 Bicep 與主打快速串接的 Azure OpenAI On Your Data，完全自動地佈署了一個具有前端網頁的基本 RAG 系統，其中因為使用到 On Your Data 的 Ingestion Jobs API，整份 Bicep 精簡到僅需要約 300 行就可以完成整套佈署，降低額外加工比例的同時也減少維運成本，是一個值得推薦的組合。
留言
張貼留言