Microsoft Foundry：模型部署與 RAG

💡 先搞懂問題

虛構公司「晴空食品」想做一個內部助理，讓客服同仁問「瑕疵品退貨的運費誰付」「會員點數多久過期」就能馬上得到答案。他們先拿一個通用的聊天模型試，結果模型很流暢地回答：「一般電商有七天鑑賞期，退貨運費多半由顧客負擔。」聽起來很合理，但晴空食品的規定是瑕疵品由公司負擔運費。模型沒有說謊的意圖，它只是不知道這家公司的手冊，於是用網路上常見的說法補了一個看似正確的答案，這種現象叫幻覺（hallucination）。

直覺的解法有兩個，都不太行。把整本手冊重新訓練進模型，成本高，而且手冊下個月改了又要再訓練一次；把整本手冊每次都貼進提示，內容一長就貴又慢，還可能超過模型一次能讀的長度。比較實際的做法是檢索增強生成（retrieval-augmented generation，RAG）：事先把手冊切成小段、建立索引；使用者發問時，先找出最相關的幾段，再把這幾段和問題一起交給模型，要求它只根據這些內容回答並附上出處。

要做到這件事，Azure 上的起點是 Microsoft Foundry（前身是 Azure AI Studio，之後改名 Azure AI Foundry，2025 年底再改為現在的名稱）。你建立一個 Foundry 資源（Foundry resource），底下開專案（project），從 Foundry Models 的模型目錄挑模型並部署（deployment）；檢索的部分交給 Azure AI Search（前身 Azure Cognitive Search）。新手最常卡在部署這一步：同一個模型有好幾種部署類型（deployment type），決定資料在哪裡處理、怎麼計費、吞吐量有沒有保證，選錯就會遇到資料落地不合規或費用失控。

生活比喻：開卷考的考生

把語言模型想成一位文筆很好、常識豐富的考生，但他沒讀過晴空食品的手冊。閉卷考時，遇到不會的題目，他會憑印象寫一段像樣的答案。RAG 就是把考試改成開卷：考生先到圖書館，用目錄找到和題目最相關的幾頁（檢索），影印帶進考場，再看著那幾頁寫答案，最後註明參考第幾頁（引用出處）。圖書館事先把每本書編好目錄、把章節拆成好查的小節，這就是建立索引和切塊。

考場座位也有不同租法。可以去共用考場隨到隨考、按題數付費；可以包下一排固定座位，不管當天有沒有人來考都照付，換來保證有位子、不用排隊；也可以把一大疊考卷交給閱卷中心，說好隔天再交回結果，價格最便宜。考場還有地點限制：有的考生只能在本國考場應試，有的只要在同一個區域就好，有的則隨便哪裡都行。

這個比喻有三個容易誤解的地方。第一，真正的考生讀過的東西會記住，模型不會：每一次請求都是獨立的，這次帶進去的片段，下一次問問題時模型就「忘了」，所以每次都要重新檢索、重新放進提示；RAG 也不會改變模型本身。第二，考生翻錯章節時，可能自己察覺不對；模型拿到不相關的片段，卻可能照樣寫出看似合理的答案，或者乾脆回頭用一般知識亂答，所以提示裡要明講「找不到就說找不到」，檢索品質也要另外評估。第三，影印的頁數不是越多越好：每一頁都會變成要計費的權杖，太多不相關的內容還會干擾模型。

🎮 互動實驗室一：這個情境該選哪一種部署類型？

每張卡是一個虛構情境，請在下方的格子裡點選最適合的部署類型。格子的列是資料在哪裡處理（Global：任何 Azure 區域；Data Zone：微軟定義的資料區域，例如美國、歐盟；地理區：資源所在的 Azure 地理區），欄是怎麼計費與保證吞吐量（Standard 類按權杖計費；Provisioned 預留容量；Batch 非同步、便宜但不即時）。答完會說明理由；只對一個維度時，也會告訴你錯在哪一邊。類型名稱與規則依 Microsoft Learn 的 Foundry Models 部署類型頁（2026 年 10 月查證）。

🎮 互動實驗室二：RAG 流程模擬器

下面是晴空食品的內部手冊（虛構，共六段）。選一個問題（或自己輸入），調整切塊大小與 top-k，按「執行 RAG」，畫面會依序顯示四個步驟：切塊、檢索、組成提示、回答。再按「不檢索直接問」比較沒有 RAG 時的回答。注意：這裡的「相似度」是用兩個字一組的字詞重疊算出的分數，只是示意，不是真的向量 embedding；回答也是預先寫好的示意，用來呈現模型拿到哪些片段時會怎麼回答。

🛠️ 操作教學：建立 Foundry 專案、部署模型、接上 Azure AI Search

左邊是簡化的 Foundry 入口網站（實際網址是 ai.azure.com），右邊是做同一件事的 Azure CLI、Bicep，以及呼叫模型的 Python 範例。照著步驟填欄位，右邊會即時換成你填的資源名稱、區域、部署名稱、部署類型與每分鐘權杖數，目前步驟對應的那幾行用黃色底標出。不需要登入 Azure，也不會真的建立資源。模型名稱與版本取自 Microsoft Learn 的快速入門（2026 年 10 月查證）；可用模型與版本會變動，以模型目錄為準。

自己動手時要注意

權限：建立 Foundry 資源需要訂用帳戶的 Owner，或在資源範圍有 Foundry Account Owner、Foundry Owner 這類角色；只是在專案裡開發與呼叫模型，給 Foundry User 就夠了（這組角色原名 Azure AI User 等，Learn 註明正逐步改名，角色 ID 不變，所以 CLI 範例直接用角色 ID）。建立 Azure AI Search 與指派角色，則需要資源群組上的對應權限。

費用：Standard 類部署按輸入與輸出權杖計費，Provisioned 預留容量按時數計費、不論用不用都會收費，練習時不要選；Azure AI Search 的 Basic 層一建立就按時數計費，語意排序有每月免費額度、超過後按用量計費。價格以 Azure 定價頁為準。

清理：練習完刪除整個資源群組：az group delete --name <名稱> --yes --no-wait。Foundry 資源刪除後也會先進入虛刪除狀態，名稱在清除前不能重用；需要立刻重用名稱時，可以用 az cognitiveservices account purge 清除。

不要寫進範例的東西：不要把 API 金鑰、連接字串或訂用帳戶 ID 寫進程式或範本，請用 <your-subscription-id> 這種佔位字。這裡的 Python 範例用 DefaultAzureCredential 取得 Microsoft Entra 權杖：本機開發時使用你 az login 的身分，部署到 Azure 後改用受控識別，程式碼都不需要改；Bicep 範例也把 disableLocalAuth 設為 true，直接關掉金鑰驗證。也不要把真實的客戶資料或個資拿來練習建立索引。

📘 原理補完

1. Foundry 的資源模型與名稱對照

Microsoft Foundry 的新架構是「一個 Foundry 資源，底下多個專案」。Foundry 資源在 Azure Resource Manager 裡的型別是 Microsoft.CognitiveServices/accounts，kind 為 AIServices；RBAC、私人網路、Azure Policy 與受控識別在這一層統一設定。專案是子資源，放 agent、評估、追蹤與資料連線。模型部署也是 Foundry 資源的子資源，同一個資源底下的專案共用這些部署與配額。舊架構（Hub 加上 Azure OpenAI 與 Azure AI services 資源）只留在 Foundry (classic) 入口網站維護，官方表示新投資集中在新版。

2. 部署類型：兩個維度、九種組合裡的八種

在 Foundry Models 部署 Azure 直接販售的模型時，部署類型同時決定兩件事。第一是推論在哪裡處理：Global 可能在任何 Azure 區域，Data Zone 只在微軟定義的資料區域內（Learn 列出美國、歐盟與亞太；歐盟資料區域依循 EU Data Boundary），地理區型只在資源所在的 Azure 地理區。三者的靜態資料（例如上傳的檔案）都儲存在指定的地理區。第二是計費與吞吐量：Standard 類按權杖計費、共用容量；Provisioned 預留佈建輸送量單位（PTU），延遲與吞吐量較可預期；Batch 非同步處理，官方說明比 Global Standard 便宜 50%，目標 24 小時內完成但可能更久，而且有獨立的佇列權杖配額。另有一種 Developer 類型，只用來評估微調後的模型，24 小時後自動刪除、沒有 SLA。以下依 Microsoft Learn 部署類型頁整理（2026 年 10 月查證）。

配額與速率限制：配額以每分鐘權杖數（tokens per minute，TPM）計，依「訂用帳戶 × 區域 × 模型 × 部署類型」分配。建立部署時分給它多少 TPM，就是它的速率限制，同時從剩餘配額扣掉；容量以「單位」表示，每單位對應多少 TPM 與每分鐘要求數（RPM）依模型而定，例如 Learn 的配額表列出較舊的聊天模型是 1 單位＝1,000 TPM、6 RPM。超過速率限制時，請求會被節流。Provisioned 部署還可以設定溢出（spillover），在容量用滿時把多出來的流量轉給指定的 Standard 部署，Azure CLI 對應的參數是 --spillover-deployment-name。

3. RAG 的兩個階段

RAG 分成「事先準備」與「每次查詢」兩段。準備階段把文件擷取成文字（掃描檔要先做 OCR）、切塊、用嵌入模型（embedding model）把每個片段轉成向量，連同原文與中繼資料寫進 Azure AI Search 的索引，之後在來源更新時增量重建。查詢階段則是：使用者提問 → 用同一個嵌入模型把問題轉成向量 → 在索引裡做混合搜尋與語意排序 → 取前 k 個片段 → 和系統訊息、問題組成提示 → 模型生成回答並引用片段。官方把這種單次查詢、自己寫編排的做法稱為 classic RAG；另一種 agentic retrieval 由 LLM 先把複雜問題拆成多個子查詢，Foundry IQ 的知識庫就是這一種。

4. 關鍵字、向量、混合搜尋與語意排序

Azure AI Search 的全文檢索（full-text search）就是關鍵字比對，以 BM25 計分，產品代碼、人名、精確數字很準，但「運費」和「物流費」這種同義詞會漏。向量搜尋（vector search）比對 embedding 的距離（HNSW 或窮舉 KNN），換句話說也找得到，但對精確代碼反而不一定準。混合搜尋（hybrid search）在同一個請求裡同時跑兩種查詢，再用 RRF（Reciprocal Rank Fusion）合併兩邊的排名。語意排序（semantic ranker）再把合併後的前 50 筆，用微軟的語言模型依語意重新排序，給出 0～4 的 @search.rerankerScore，並可回傳標題摘要（captions）。Learn 寫明，以真實與基準資料集測試，混合檢索加語意排序對相關性有明顯幫助，這也是 RAG 的常見建議組合。語意排序是付費功能，有每月免費額度。

5. 切塊大小與 top-k：太碎、太大都有代價

實驗室二已經讓你看到：切得太碎，標題和事實會被分到不同片段，「會員點數」的片段被選中，真正寫「十二個月」的下一個片段卻沒進提示；切得太大，每個片段混雜好幾個主題，向量變得模糊，放進提示的權杖也變多。實務上會讓相鄰片段重疊一小段，避免一句話被切斷，並依文件結構（標題、段落）切。top-k 也一樣：太小容易漏掉需要的第二個事實，太大會塞進不相關的內容、增加費用並干擾模型，所以常搭配相關性門檻。這些都是 AI-300 技能大綱點名的 RAG 調校項目：切塊、門檻、混合搜尋與嵌入模型選擇。

6. 什麼時候用 RAG，什麼時候不用

RAG 適合知識常更新、需要附出處、不同使用者能看的資料不一樣的情境。它不擅長改變模型的語氣、輸出格式或某種特定技能，那是微調（fine-tuning）的工作；兩者也可以並用。如果資料量很小、而且很少變動，直接寫進系統訊息可能就夠了。多個 agent 要共用企業知識並尊重權限時，可以考慮 Foundry IQ；需要完全自訂索引欄位與評分邏輯時，直接操作 Azure AI Search。

7. 安全與驗證：keyless 是預設思維

Foundry 資源支援 Microsoft Entra ID 驗證。應用程式在 Azure 上執行時用受控識別，本機開發時用開發者自己的登入身分，兩者都透過 DefaultAzureCredential 取得權杖，再指派 Foundry User 這類資料平面角色；確定不需要金鑰後，把 disableLocalAuth 設為 true 關閉金鑰驗證。RAG 還有一個特有風險：檢索進來的文件可能夾帶惡意指示（間接提示注入），所以要啟用 Foundry 的防護措施（guardrails）與 Prompt Shields，並讓檢索結果依使用者權限過濾，避免模型把使用者無權看的內容說出來。

遇到題目時的判斷步驟

1. 先看是「選部署」還是「讓模型懂公司資料」。前者看處理位置與流量型態，後者通常是 RAG。
2. 選部署：有資料位置限制就先排除 Global；再看流量穩定且大選 Provisioned，起伏大或量小選 Standard 類，大量不急選 Batch。
3. 速率限制錯誤：先看部署分到的 TPM 與該區域的剩餘配額，而不是換模型。
4. RAG 答錯或答不完整：先檢查檢索結果有沒有包含答案，再調切塊、top-k、搜尋類型與嵌入模型，最後才懷疑生成模型。
5. 檢索品質：同時要精確字詞與語意，選混合搜尋加語意排序。
6. 安全：用 Entra ID 與受控識別、最小權限角色，啟用防護措施，讓檢索依使用者權限過濾。

容易考錯的地方

相關考試：AI-901 考在 Foundry 入口網站部署模型並互動、用 Foundry SDK 建立用戶端；AI-103 考選模型、部署設定、配額與速率限制、RAG 與 semantic／hybrid／vector search；AI-300 考 Foundry 資源與專案、PTU 部署，以及切塊、門檻、混合搜尋與嵌入模型等 RAG 調校（依各考試 2026 年的技能大綱）。

✅ 自我檢測

以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6

🎯 重點整理

1. Microsoft Foundry（前身 Azure AI Studio、Azure AI Foundry）以一個 Foundry 資源加多個專案組織工作，模型部署掛在資源底下。
2. 部署類型有兩個維度：處理位置（Global、Data Zone、地理區）與計費方式（Standard 類按權杖、Provisioned 預留 PTU、Batch 非同步便宜 50%）。
3. 配額以 TPM 依訂用帳戶、區域、模型、部署類型分配；部署分到的 TPM 就是它的速率限制。程式呼叫時填的是部署名稱。
4. RAG＝先檢索、再生成：準備階段切塊、向量化、建索引；查詢階段檢索前 k 個片段放進提示，要求依據片段回答並引用。
5. 模型不會記住檢索到的資料；檢索不到時要讓它說找不到。切塊大小、top-k、搜尋類型與嵌入模型都會影響結果，要用評估指標比較。
6. 檢索建議混合搜尋加語意排序；驗證用 Microsoft Entra ID 與受控識別，關閉金鑰，並啟用防護措施。