企業級 GenAI 中樞：Microsoft Foundry 上的模型服務與 RAG 落地

如果你要找的是「Azure 上怎麼開始用大型語言模型」，站上那篇 Azure OpenAI 服務入門 是比較好的起點。這一篇往下走一層，談的是企業真正會卡住的地方。

會卡住的通常不是模型好不好，而是三件事：這個服務現在到底叫什麼、我的資料會跑到哪裡、以及檢索要怎麼做才不會答錯。

企業導入生成式 AI，難的很少是模型本身。難的是把「資料在哪、誰能看、答錯了怎麼查」這三件事講清楚。

而在 Azure 上，這三件事現在都掛在同一個名字底下。那個名字在 2026 年變了，所以我們從名字開始。

先把名字理清楚，不然查不到正確文件

這個平台的品牌換過幾次。Azure AI Studio 在 2024 年改名為 Azure AI Foundry，2025 年再改名為 Microsoft Foundry，並在 2026 年 1 月起的產品條款中正式沿用新名。

拿掉 Azure 這個字，跟當年 Azure Active Directory 改名為 Microsoft Entra ID 是同一種思路：把它定位成 Microsoft 的核心產品，而不只是一個 Azure 服務。

這張表最實際的用途，是幫你判斷手上的教學文章還能不能用。名稱對不上，多半代表那篇的其他細節也過期了。

資料不出雲，官方到底承諾了什麼

「資料不外流」這句話太模糊，實際要看的是官方隱私文件逐條寫了什麼。以下是截至 2026 年 8 月文件中的重點。

• 你的提示、輸出、嵌入向量與訓練資料，不會提供給其他客戶。
• 不會提供給 OpenAI 或其他模型供應商，也不會被他們用來改善模型或服務。
• 未經你的許可或指示，不會被用來訓練任何生成式 AI 基礎模型。
• 微調後的模型僅供你自己使用，靜態資料預設以 AES-256 加密，也可改用客戶自管金鑰。
• 模型是無狀態的，提示與輸出不會存在模型裡。

企業級 RAG 的兩條路

官方把 RAG 的實作分成兩種取向，而不是一種最佳解。理解這個分法，比背 API 有用得多。

無論走哪條路，第一段的內容準備都跑不掉：大文件要切塊、要做向量化、要處理圖片與 PDF、還要有同義詞與語意排名去補術語落差。

另外值得記一筆的是 Foundry IQ。官方把它描述成建立在 Azure AI Search 之上的受管知識層，讓代理人用單一端點取得可重用、具權限意識的知識庫。

權限是最容易被留到最後的一面

RAG 出事最痛的一種，不是答錯，是答對了但不該給這個人看。財務資料不能因為主管去問聊天機器人就流出來。

• 索引時就把權限中繼資料帶進來，之後才修剪得掉；事後補會變成整批重建。
• 對某些遠端來源，檢索可以沿用來源本身的權限，不必在檢索層再造一套。
• 其他來源就用查詢時的篩選式安全性，並把規則寫在同一處，避免散在各支程式裡。
• 網路層用私人端點隔離，別讓檢索服務暴露在公開網路上。

從原型到生產，工具鏈長什麼樣

Foundry 提供好幾個開發介面，官方也直接說多數人是混著用：在入口網站做原型，再搬到程式碼。

• Foundry 入口網站：瀏覽模型、試提示詞、不寫程式就能建宣告式的提示型代理人。
• SDK：Python、C#、JavaScript、Java 都有，統一的專案用戶端搭配單一專案端點。
• Azure Developer CLI：從命令列建立、執行、測試與部署代管型代理人專案。
• Visual Studio Code 擴充：在編輯器裡建置與除錯代理人。
• MCP 與程式碼代理人：用 MCP 伺服器從編碼代理人驅動 Foundry。

代理人本身也分兩種形狀：宣告式的提示型代理人交給平台代管，最少東西要顧；程式碼路線的代管型代理人則自帶框架與容器，換到最多控制權。

生產面的三件事別忘了掛上：追蹤、評估與監控。沒有評估集的 RAG 專案，改動之後沒人說得出來到底變好還是變壞。

如果要我排落地順序

1. 先定資料邊界：部署型別、濫用監控、金鑰管理，這三項寫進架構文件。
2. 再做內容準備：來源盤點、切塊策略、權限中繼資料，這一段做壞了後面全歪。
3. 先用傳統 RAG 打通一條端到端的路，拿到可量測的基準線。
4. 建評估集，讓每次調整都有數字可比，而不是靠感覺。
5. 確定需要更強的查詢理解時，再評估換成代理式檢索。