距離上篇在 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 這麼簡單，先前在回應遇到...
接續前一篇，我們已經完成了 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 檔，而現在對於被解壓縮出來的資料也需要使用第二個資料集來表示它。
與前面的動作都一致，選到「作者」→「資料集」→「新增資料集」→ 資料存放區：「Azure Data Lake Storage Gen2」→ 資料格式類型：「二進位」，這邊注意到需要與第一個資料集有不同的名稱，因為它代表的是不同的資料。
 |
| 第二個資料集的屬性設定 |
再來比起第一個資料集，這邊只需要用到「@dataset().folderPath」一個參數，至於為什麼這邊不需要用到檔案名稱，是因為一般情況下我們不會提前知道解壓縮出來的檔案名稱，所以第二個資料集在這邊更像是對「存放路徑」的宣告。
在 Azure Data Factory 中新增管線
與新增資料集的動作類似，選到「作者」→「管線」→「新增管線」，接著如下圖設定兩個管線內的全域參數，等一下我們會用到它們
 |
| 設定管線內的全域參數 |
再來如下圖將「移動和轉換」→「複製資料」拖移到中間空白畫布中：
 |
| 在管線中建立複製資料活動 |
開始設定「複製資料」的內容，首先到「來源」頁籤，來源資料集在這個範例中就是 .zip 檔，所以選擇第一個資料集，這時會彈出資料集需要的兩個參數，如下圖完成設定：
 |
| 複製資料活動的來源設定 |
「@pipeline().parameters.folderPath」與「@pipeline().parameters.fileName」也是內建的變數，代表使用管線全域參數來代入。
再來如下圖切到下一個「接收器」頁籤，這邊當然就是選擇第二個資料集做為接收資料集，一樣需要代入對應的管線全域參數，之後在「Copy behavior」這邊建議設定「Preserve hierarchy」，這樣在解壓縮後就能保持 .zip 檔內的資料夾架構。
到此完成整個管線的設定！
測試資料
完成後當然是趕快來測試看看了，測試用的資料只需要普通到不能再普通的 .zip 檔，這邊我建立一個名為 test 的 .txt 檔，在 Windows 中右鍵把它壓成 test.zip。 |
| 很普通的測試資料 |
接著把 test.zip 上傳到上一篇建立的 Blob Storage 中備用即可。
 |
| 測試資料上傳至 Blob Storage |
管線偵錯模式
Data Factory 非常貼心的提供了管線發布前的偵錯模式，直接點擊畫布上方的「偵錯」，會在右方跳出以下畫面： |
| 輸入觸發管線的值 |
還記得我們先前編輯管線時，有設定了兩個管線全域參數，這邊就是輸入我們想用怎樣的參數值來觸發這次的管線執行；因為剛剛的測試資料直接放在 Container 的根目錄，所以第一個「folderPath」填入 Container 名即可，但要注意這邊有很詭異的兩個斜線是固定的格式，而「fileName」當然就是填入測試資料的檔案名稱。
設定完成按下「確定」就會看到管線開始執行，等待約 10 秒就會看到執行成功的畫面囉！
 |
| 管線執行成功 |
回到 Blob Storage 的畫面來看看檔案的狀態：
如預期地從 test.zip 中解壓縮出 test.txt，測試成功！
總結
我們完成了解壓縮管線的設定，並且手動的觸發一次管線執行，也成功解壓縮出測試資料；但回想我們的執行方式，在開始時需要輸入檔案路徑與檔案名稱，似乎不是這麼的方便好用，所以在下一篇中會使用 Data Factory 的觸發程序來自動填上這些值，請繼續收看！
留言
張貼留言