Charlie Wei Blog

距離上篇在 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 這麼簡單，先前在回應遇到...

在 OpenAI 與 Azure OpenAI 同時發佈 o1 系列模型的一週後，我也順利通過 Azure OpenAI 的使用申請啦！本篇就來快速試用一下最新的o1 系列模型。 提出申請 目前如果要使用 o1 系列模型都需要經過微軟的資格審查，申請表單可以參考以下連結，表單只需要填寫一份，申請通過後 o1-preview 和 o1-mini 兩個模型都能使用。 相關連結： https://aka.ms/oai/modelaccess 使用 AI Studio 首先你必須要有一個位於 美東 2 地區的 Azure OpenAI 資源，不管是原有的或是新建立的資源都可以。 因為目前 o1 系列模型還處於早期訪問階段，資源中不需要自行佈署模型，取而代之的是需要透過 Early Access Playground 才能使用到 o1 系列模型。 而這次比較特別的是只能使用 AI Studio 的 Playground，看得出來微軟要慢慢整併掉 Azure OpenAI Studio 了。 草莓問題 這次就拿近期已經被大家玩爛的草莓問題來測試，在這個問題中我們會詢問 GPT 在「Strawberry」這個單字裡包含了多少個字母「r」，沒錯，這個草莓問題就是這麼簡單無聊，但結果卻出乎意料。 gpt-4o：兩次 gpt-4o 會有非常高的機率回答：兩次，看似如此簡單的問題又能讓 gpt-4o 屢屢回答錯誤，這就是草莓問題出名的原因，大家也可以自己嘗試看看。 o1-preview：三次 反觀加入 Chain of Thought 概念的 o1-preview 就輕鬆解決了這個草莓問題 😂 總結 根據官方資訊，具有 Chain of Thought 的 o1 模型犧牲了回應的即時性，但大幅改善在邏輯與推理類型問題中的表現，同時成本方面 o1-preview 相較 gpt-4o-0806 貴了 6 倍，對於企業來說就需要好好思考是否有適用的情境了，不過現階段還是繼續期待 API 可用的那天。

在這個 LLM 時代 RAG 可說是一個非常熱的議題，其中來源資料的品質幾乎決定了整個 RAG 應用的成敗，而在一系列的資料處理流程中，又以 Chunking 做為一個重要的環節，像是常見的固定長度、重疊等等都是基本的 Chunking 策略。 Semantic Chunking 是一種進階的 Chunking 手法，比起基本的固定長度切分，Semantic Chunking 希望藉由語意分析劃分出更具有意義的 Chunk。本篇將使用在 Document Intelligence 中新推出的 Layout Model 文檔分析 API 來實作 Semantic Chunking。 Markdown 與 Semantic Chunking Markdown 是一種具有結構的標記語言，對於人類在閱讀上是非常友好的，而對於 LLM 來說當然也是如此，不過在現實上，我們提供給 RAG 的文件往往都不是 Markdown。 現在我們將使用 Layout Model 來解決這個問題，其提供的文檔分析 API 可以在一次呼叫中將傳入的 PDF、PPT 等常見格式文檔轉換成 Markdown 格式，這個轉換過程中包含了 OCR、文件結構分析等步驟，這也就代表轉換出的 Markdown 結構在某種程度上是蘊含文件語意的。 最後我們將使用這個 Markdown 結構做為 Chunking 的依據，以此來實現 Semantic Chunking。 建立 Document Intelligence 建立 AI 類服務時基本上都不用做太複雜的設定，這邊唯一要注意的是我們預計要使用的 Layout Model API 目前只有在美東、美西 2 與西歐三個地區提供，建議時需要留意選擇的地區。 Document Intelligence Studio 與其他 AI 服務一樣，Document Intelligence 也有提供 Studio 讓我們快速體驗功能，從 Studio 首頁進入「Layout」頁面，我們使用內建的範例文件來看看文檔分析 API 的能力。 首先選擇一篇範例文件，再調整「Output format style」為「Markdown 」後點擊上方的「Run an...

 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 ...

Provisioned Throughput Units 一直是目前在 Azure OpenAI 對於延遲問題的最有效解法，同時也是官方最推薦的方案。有別於基本的隨付即用，PTU 具有穩定、可預測的延遲等優勢，適合用於正式上線的生產環境。 但 PTU 的成本是一個不可忽視的問題，儘管選購最小單位量的 PTU，也是需要應用到達一定規模後才看得出使用效益。在確認是否購買 PTU 時，除了詳細閱讀官方文件並使用官方推出的計算機規劃額度外，以下幾點或許也是你該注意的。 不可自行購買 PTU 首先，是的，截自撰文當日 (2024/07/09) PTU 只能透過微軟業務窗口洽詢購買細節，這可能對於多數用戶是不友善的，但我相信這個過程很快就能得到優化。 相關連結： https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/provisioned-throughput#how-do-i-get-access-to-provisioned PTU 的可用區域僅供參考 在官方文件中記錄了下述表格，其中詳細的呈現各種模型的 PTU 在不同地區的可用性，但這張表只是一個參考，因為當你洽詢業務窗口時你會得到另一張不同的表格。 其中對於台灣用戶可能最有影響的，是我們沒辦法在日本東部購買 gpt-4o 模型的 PTU，對於想透過購買 PTU 以降低模型延遲的用戶來說這是一個矛盾的選擇，當然更不用提隨之產生的跨區傳輸量成本。 一樣截至撰文為止，為何在打勾區域✅無法購買的問題，官方並沒有給出任何理由，或許是我們採購量沒有達到官方需要解釋的程度😔 相關連結： https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/provisioned-throughput#what-models-and-regions-are-available-for-provisioned-throughput 有別於你認知的定價策略 承如前述，PTU 的成本絕對是導入時的重要考量點。 PTU 的售價到底是多少 事實上 PTU 的官方售價早就是公開的秘密，稱之為秘密是因為 PTU 的售價截至目前並沒有被列在官方文件或定價計算機中，但在最新的 Azure OpenAI S...

二月底時 Azure OpenAI 已經悄悄的上線了第三代的 Embedding 模型，共有 text-embedding-3-large 與 text-embedding-3-small 兩種，隨後又在 3/8 釋出新的 API 版本  2024-03-01-preview ，在這版 API 中主要就是一些針對新版 Embedding 模型的新功能，以下簡單記錄一下試用心得。 模型佈署 首先當然是佈署新的 Embedding 模型，兩種模型在 Azure OpenAI 上都是獨立存在的，large 具有較高的精準度，而 small 則有成本和效能的優勢，不過兩者透過 API 存取的方式都是一樣的，所以這邊就擇一選擇佈署  text-embedding-3-large 就好。 Python SDK 再來會使用 Python SDK 搭配  2024-03-01-preview ，因為都是比較新的功能，所以使用的 SDK 版本建議升級至最新版本，以下展示的內容使用的是 openai==1.13.3 。 2024-03-01-preview 新參數 就像一開始提到的，這版 API 是針對 Embedding 模型的新功能，主要增加了兩個新參數： encoding_format 與 dimensions 。 encoding_format encoding_format 可以指定產生的向量格式，有 base64 與 float 兩種選擇，預設值為 float 也是我們原本常看到的樣子，而 base64 的使用方式如下： 執行結果如下： 另外也可以透過 Python 套件 base64 與 numpy 再轉回原本的浮點數： 執行結果如下： base64 在回傳時是固定的，尤其有使用原廠 OpenAI 搭配 Python SDK 的人，應該很常發生回應不固定的問題，這與 Python 上的 float64 格式有關，細節就不在這討論了，總之使用  encoding_format=base64 可以處理掉這個問題。 另外  base64 相較於 float 更為緊湊，更適合放在 http 請求中傳送，即使加上轉換格式的時間還是略快於 ...

Azure OpenAI 服務自從推出以來一直非常熱門，但 Azure 背後還是存在的資源問題，這點從新模型都會分散上架在世界各地中不難看出來，另外還有呼叫時存在的 TPM 限制，這造成在實際使用時不得不建立出一大堆 AOAI 實例與 API 端點，在開發與管理上都會複雜許多。 為了解決這個問題，一個想法是如果可以透過某種機制在兩個 AOAI 端點間進行負載均衡，這就相當於擁有了兩倍的 TPM，因此，本篇將介紹如何使用 APIM 來達成這個目標。 系列文章 【Azure APIM】Azure OpenAI 端點上的負載均衡（本篇） 【Azure APIM】在呼叫 Azure OpenAI 端點時使用 Managed Identity 事前準備 在開始之前需要先建立好以下資源： 開發人員層級的 APIM 佈署於美國中北部的 Azure OpenAI 實例與模型 佈署於美國中南部的 Azure OpenAI 實例與模型 因為稍等會使用 gpt-35-turbo (0125) 來測試，所以選擇了該模型目前可使用的地區，可以根據自己的需求來選擇地區，另外這邊記得也先將 API 端點與 API KEY 記錄下來。 準備 API 文件 首先我們需要準備 Azure OpenAI 的 OpenAPI 規格文件，這份文件可以直接從 官方 GitHub 上下載下來，除非你有在 APIM 的開發者頁面查看 API 規格的需求，不然這邊使用任何一個 API 版本都是可以的。 下載到本地端後，我們需要先將開頭部分的 servers.url 拿掉，修改完成後應該會長這樣： 匯入 API 接著進到 APIM 的 API 頁面，選擇使用 OpenAPI 來建立一個新的 API。 在 OpenAPI specification 中上傳剛剛修改好的 OpenAPI 規格文件，按下建立就可以了。 設定 API Policy 再來就是最關鍵的負載均衡規則了，在這個規則中，我們會將進入的流量輪流轉發到事前準備好的中北美與中南美兩個 API 端點上。 在流量每次進入時，會先使用  cache-lookup-value 查找存在快取中的 backend-counter 值，決定這一次要使用哪一個 API 端點，再用 set-backend-service 來設定給...

千呼萬喚的 Assistants API 終於趕在農曆年假期前一天上線了！我絕對不會說隔壁棚已經上線超過兩個月，趕緊記錄下來試用的心得。 Assistants API 這次增加了託管上下文的線程管理功能，終於不用再每次都把對話紀錄全部塞進 Prompt 了，同時也整合 Function calling、Code Interpreter 與讀取多種格式文件等功能，最後再加上允許圖表輸出，讓開發者可以輕鬆在應用中打造出個人助理。 這次參考了 官方的範例程式 ，其中使用的是 Python SDK 與  2024-02-15-preview 的 API，並且結合目前工作上遇到的一個場景，來演示這次推出的新功能，完整程式碼歡迎查看下方 GitHub。 相關連結： https://github.com/charliewei0716/azure-openai-assistant-data-engineer Assistants API 概念 在過去 OpenAI 的 API 一直都是無狀態的設計，所以如果希望 GPT 的回答是朔及前文的，就必須在每次的對話中，將所有歷史對話紀錄都塞進 API 內，常用的做法是塞入最新的 10 筆對話紀錄，以減少 Token 爆量的問題發生。 而 Assistants API 新增了 Thread 的概念，Thread 支援上下文的持久儲存，這使 API 變成是有狀態的，同時 Thread 將自動管理存入的對話紀錄，雖然這部份就像是黑盒子，官方並沒有明確說明對話的保留機制，但從此以後終於不用再自己搞個 DB 把對話都記錄下來，只需要一直無腦的新增訊息就好。 當一個 Thread 被建立後，可以將每一次對話視為一個 Run，其中我們可以定義 Function calling 與 Code Interpreter 兩類工具：Function calling 就像平常寫程式一樣，可以客製化編寫自己的邏輯，一般常用來做第三方串接，讓自然語言可以轉化為實際的動作；另一項 Code Interpreter 會在背後啟動一個 Python 沙盒環境，Assistants API 會在環境中編輯運行程式碼，藉此提升程式碼回答的正確性。而最終在每一次的 Run 中，GPT 將根據對話自動判斷是否呼叫這些定義好的工具。...

今日 Azure OpenAI 釋出了 12 月份的改版，其中最期待的功能當然是 GPT-4 Turbo with Vision 了，雖然隔壁棚已經上線快一個月了，但收到消息的當下還是馬上到 Portal 上建了一個來玩。 模型佈署 GPT-4 Turbo with Vision 目前被歸屬在 GPT-4 中獨立的一個模型版本： gpt-4-vision-preview ，與上個月的 1106 版相同，要使用的話都需要額外佈署模型，不過優點就是配額與一般的 gpt-4 模型是分開計算的，不用擔心佔用到現有的額度。 另一個需要注意的地方是，gpt-4-vision-preview 首批開放只限於 瑞士北部 、 瑞典中部 、 美國西部 與 澳洲東部 四個地區而已，不意外地再次增加了模型的管理難度😔。 vision-preview 預設可使用 10K 的配額 聊天遊樂場 GPT-4 Turbo with Vision 可以直接在遊樂場中快速試用，進入遊樂場的聊天頁面後，選到剛剛佈署的  gpt-4-vision-preview  模型，下方就會出現可以上傳檔案的圖示了。 選對模型才能上傳檔案 測試範例 以下測試了兩個 OpenAI 官方提供的範例並改成了繁體中文的版本，另外還有一個我在工作中常遇到的架構圖案例。 巴黎綜合理工學院考試題 Prompt：Answer question I.1.a with Traditional Chinese. Think step-by-step. GPT-4： 雖然不確定回答的正不正確，畢竟我也不會這題，但確實根據輸入的圖片回答了問題。 迷因圖 Prompt：Can you explain why this is funny use Traditional Chinese. Think about it step-by-step. GPT-4： Azure 架構圖 Prompt：Explain the advantages of this architecture in Traditional Chinese. GPT-4： 總結 同時輸入文字與圖片讓 GPT 又進入了另一個境界，尤其是第一個範例中的物理問題，從一開始在發佈功能的文檔中看到，到了現在實際上線後測試，真的是帶來驚奇。 另外 Azure 上也同...

「JSON 模式」是模型 1106 版本中的新功能，主要適用在一些自動化場景中，比起單純使用 Chat Completions API 生成的文字對話，「JSON 模式」可以有效地確保輸出都是使用 JSON 格式，以下使用幾個範例來測試這項功能，完整的程式碼可以查看文末的 GitHub 連結。 模型佈署 與「可重現的輸出」功能相同，目前只有 gpt-35-turbo-1106 與 gpt-4-1106-preview 兩個模型中可以使用「JSON 模式」功能，畢竟也只有這兩個模型有 1106 的版本編號，有關模型與地區限制可以查看以下官方文檔連結。 本篇將使用美東 2 地區佈署  gpt-4-1106-preview  模型進行測試。 相關連結： 區域配額限制 必要條件 佈署一個符合上述條件的 Azure OpenAI 資源與模型，並記下模型的佈署名稱 使用目前最新的 API 版本： 2023-12-01-preview 執行以下指令來安裝目前最新的 Python SDK 使用以下程式碼完成初始化設定 json_object JSON 模式的使用方式非常簡單，只需要在原有的 Chat Completions API 中加入參數 response_format={'type': 'json_object'} 即可。 程式執行結果如下： 可以看到程式輸出從原有的純文字變成了 JSON 格式，另外在官方文件中，也建議將「輸出 JSON 格式」做為系統訊息的一部份放入 Chat Completions API 中，以達到更好的效果與減少一些空白輸出的異常狀況。 其他範例 上述是在官方文件中所使用的範例，不免俗的還是要來測試一下 JSON 模式在中文的表現狀況。先從一個簡單的訂票場景開始： 程式執行結果如下： 在這種有明確實體的範例中，效果想當然的好，一些地名：「台中」、「台北」與「高鐵」等關鍵字都有被抓出來，算是一個簡單有效的嘗試。 接著再測試另一個進階一點的範例，這次是一個有開放性問答的對話場景： 程式執行結果如下： 確實輸出結果變得比較不可預期了，有興趣的朋友也可以多重複執行幾次程式，會發現在這種沒有明確結果或實體的對話中，執行輸出的變動性就會增加許多。 總結 整體來說，以目前的「JSON 模式」還是...

Azure OpenAI 在 11 月中也跟上了 GPT-4 模型 1106-preview 版本，其中包含了「可重現的輸出」這項功能，單從字面上理解，明顯就是希望解決大家詬病已久的回覆隨機性問題，以下將使用官方範例來測試這項功能，完整的程式碼可以查看文末的 GitHub 連結。 模型佈署 目前只有 gpt-35-turbo-1106 與  gpt-4-1106-preview 兩個模型中可以使用「可重現的輸出」功能，跟先前釋出新模型的模式一樣，一開始都只有特定幾個區域開放使用，有關模型與地區限制可以查看以下連結。 本篇將使用美東 2 地區佈署  gpt-4-1106-preview 模型進行測試。 相關連結： 區域配額限制 必要條件 佈署一個符合上述條件的 Azure OpenAI 資源與模型，並記下模型的佈署名稱 使用目前最新的 API 版本： 2023-12-01-preview 執行以下指令來安裝目前最新的 Python SDK 使用以下程式碼完成初始化設定 一般的輸出 對於一般的聊天輸出就是使用最常見的 Chat Completions API，不過在新版的 Python SDK 1.x 中寫法略微不同，首先使用 for 迴圈執行相同的提問三次，其中 model 記得修改成模型的佈署名稱，以我這邊為例是使用 gpt-4-1106 。 程式執行結果如下： 可以看到順利的輸出了三段故事，但這邊就像平常的輸出一樣，GPT 每次的執行結果都存在隨機性，所以三段故事都不太相同。 可重現的輸出 為了解決這個問題，在這次的更新中允許我們加上一個隨機種子，設計邏輯與其他帶有隨機性的 Python 套件寫法一樣，帶有相同種子的問答可以預期有相同的結果。 加上隨機種子 seed=42 後，程式執行結果如下： 在這次執行中，因為加上了隨機種子  seed=42  的關係，輸出了三段相同的故事。 現實中的限制 以上兩段程式是官方文檔中提供的範例，但事實上這個功能其實沒辦法如預期的每次都得到相同輸出結果，隨意換上一些對話內容 呼叫中已經帶上了隨機種子，但程式執行結果如下： 很明顯輸出不是相同的。 總結 「可重現的輸出」對於程式的除錯來說非常重要，GPT 問世至今相關的系統也因為問答存在隨機性，而無法完整...

在上一篇中，我們已經建立了一個可以儲存向量的 Index，並寫入了包含向量欄位在內的 108 筆資料，還沒看過的可以先到下方連結查看喔！ 接續上篇，我們會在這個 Index 上開始執行向量搜尋，交叉使用先前設定好的兩種演算法，最後會結合全文檢索進行混和搜尋。 完整程式碼於文末 GitHub 連結提供！ 相關連結： 【Azure Cognitive Search】使用 Python SDK 在認知搜尋中進行全文檢索 相關連結： 【Azure Cognitive Search】使用 Python SDK 在認知搜尋中進行向量搜尋（上） 相關連結： https://github.com/Azure/cognitive-search-vector-pr/tree/main/demo-python 必要條件 具有與上篇相同設定的 Cognitive Search Index Cognitive Search 的官方 Python SDK：azure-search-documents 的  11.4.0b11  版 連線 Index 首先必須要連線到在上篇建立好的 Index： 使用 SearchClient 類與現有的 Index 建立連線，這邊要注意 index_name 是要建立連線的 Index 名稱 ，後面都會使用到這個物件，不過文章中就不會再重複這段程式碼了。 單一欄位的純向量搜尋 在執行向量搜尋時，一般都需要先將要搜尋的語句轉換為向量，後續才能與其他向量計算相似度，但每次執行都需要多這一步確實有點麻煩，常見的解法也是把流程包成函數來重複使用。 但在 Cognitive Search 中，非常貼心的幫我們把這一步處理掉了，現在我們可以直接把查詢問句丟進呼叫的接口，而不再是先轉換成向量，以下程式碼會更清楚這個流程： 原因是我們使用  VectorizableTextQuery 這個類別，背後他會自己去使用我們在上篇設定給 Index 的 Azure OpenAI 連線資訊來轉換向量，真的是非常方便，但因為還是使用我們自己的 Azure OpenAI 資源，所以轉換費用還是逃不了的😓 VectorizableTextQuery 代表的是一組向量搜尋的設定， k=3 表示回傳分數前三高的結果， fields="contentVect...

認知搜尋 Azure Cognitive Search，在需要限縮 ChatGPT 回答內容的對話機器人情境中，Cognitive Search 可以作為其中最關鍵的「知識庫」角色，其 PaaS 服務的方便性加上後期與 Azure OpenAI 的整合，可說是 2023 年最受益於 ChatGPT 的 Azure 服務之一。 因應 Cognitive Search 在 10 月份對向量搜尋的最新版更新，本篇參考以下 GitHub 範例程式實作與心得分享；接續前篇由快速入門 Cognitive Search 的角度出發，一樣會使用 Python SDK 建立 Cognitive Search 的 Index ，而測試資料的向量會由 Azure OpenAI 的 Embedding API 產生後，與資料一同存入 Index 中，最後會在 Index 中進行向量搜尋。 完整程式碼於文末 GitHub 連結提供！ 相關連結： https://github.com/Azure/cognitive-search-vector-pr/tree/main/demo-python 必要條件 在任何區域或任何層級上的認知搜尋服務 Azure Cognitive Search，記得先複製好金鑰備用 Cognitive Search 的官方 Python SDK：azure-search-documents 的  11.4.0b11  版 以上項目如果不知道如何進行，建議可由下方連結的前文開始閱讀，參考如何建立需要的服務與環境。 相關連結： 【Azure Cognitive Search】使用 Python SDK 在認知搜尋中進行全文檢索 測試資料 繼續借用以下官方放在 GitHub 上的範例資料，資料中包含了 108 項 Azure 服務的名稱與簡介，並存放於 Json 格式中。 相關連結： https://github.com/Azure/cognitive-search-vector-pr/blob/main/demo-python/data/text-sample.json 建立 Index 我們預計會對測試資料中的 title 與 content 兩欄位各自產生向量，所以在這次建立的 Index 中會新增 titleVector 與 contentVecto...

認知搜尋 Azure Cognitive Search，在需要限縮 ChatGPT  回答內容的對話機器人情境中，Cognitive Search 可以作為其中最關鍵的「知識庫」角色，其 PaaS 服務的方便性加上後期與 Azure OpenAI 的整合，可說是 2023 年最受益於 ChatGPT 的 Azure 服務之一。 此篇會由快速入門 Cognitive Search 的角度出發，使用 Python SDK 建立 Cognitive Search 的 Index ，並在其中載入測試資料與進行全文檢索。 建立服務 由 Portal 建立 Cognitive Search 服務是最簡單快速的，基本上在建立時只需要決定「定價層」、「復本數」與「分割區數量」。 選擇建立免費層的 Cognitive Search 這邊我們先從最簡單的免費層開始就好，在這個層級中「復本數」與「分割區數量」都被限制在 1 份，所以只需要無腦點建立就可以囉。 免費層無法調動設定 看到預估成本是 0 元就莫名的開心.. API 金鑰 建立完成後進入 Cognitive Search 畫面左邊的「金鑰」頁籤，先複製下來備用。 查看 API 金鑰 測試資料 先借用以下官方放在 GitHub 上的範例資料，資料中包含了 108 項 Azure 服務的名稱與簡介，並存放於 Json 格式中。 相關連結： https://github.com/Azure/cognitive-search-vector-pr/blob/main/demo-python/data/text-sample.json Python 套件安裝 Cognitive Search 的官方 Python SDK，使用以下指令安裝： 建立 Index 首先透過以下這段程式，使用剛剛暫存下來的金鑰連線到 Cognitive Search，記得將 endpoint 與 credential 替換成自己的。 在將測試資料放入 Cognitive Search 前，必須先建立 Index，這邊可以將 Index 想像成資料庫中的表，與在資料庫中建立表的流程一下，需要先定義表的欄位與其格式，在 Cognitive Search 中使用 Field 來設定這些。 配合測試資料中的 4 個欄位：id、tit...