wen aidev
Published on

Azure AI 解析（二）：Azure AI Foundry 實戰指南

Table of Contents

在上篇文章中，我們釐清了 Azure AI 的三層架構。你現在知道，如果要調用 GPT-4，你應該找第二層的 Azure OpenAI；如果要自己訓練模型，你應該找第一層的 Azure Machine Learning。

但實務上，一個成熟的 Agentic Application 從來不會只有一次 API 呼叫。它可能長這樣：

  1. 接收使用者問題。
  2. 呼叫 Embedding 模型轉向量。
  3. 查詢企業內部知識庫 (Azure AI Search)。
  4. 把查到的文章跟使用者的 Prompt 拼接。
  5. 呼叫 GPT-4 (或 Llama 3) 生成答案。
  6. 送給另一個模型檢查，這回答有沒有涉及暴力、或是有沒有「幻覺」？
  7. 輸出給前端。

這就是著名的 RAG（檢索增強生成）管線。問題來了：如果這個管線某天生成了一句廢話，你要怎麼 Debug？ 傳統把這七件事寫死在 Backend Code 裡的做法，就像一個巨大的黑箱，維護起來痛苦不堪。

這就是微軟將此前的 Azure AI Studio 重構，並升級推出 Azure AI Foundry 的核心原因：我們需要一座統合這一切的「兵工廠」。

什麼是 Azure AI Foundry？LLMOps 的指揮中心

Azure AI Foundry 的定位非常明確：它是一個專為開發 Generative AI 應用與 Agent 所設計的單一 Portal。它把「探索模型」、「編排邏輯」、「評估品質」與「部署監控」四大生命週期全部收攏在同一個介面裡。

Azure AI Foundry 端到端生命週期：Explore, Build, Evaluate, Deploy

圖說：Foundry 提供的是端到端的 LLMOps (大語言模型維運) 體驗，讓開發者不需要在十幾個不同的介面之間切換。

第一站：Model Catalog（軍火庫）

早期很多開發者猶豫不用 Azure 的原因是：「Azure 上只有 OpenAI 啊！如果我要開源模型怎麼辦？」

在 Foundry 的首頁 Model Catalog，這個迷思被徹底打破。微軟在這裡上架了極其豐富的模型，包含 Meta Llama、Mistral、Hugging Face 上的熱門小模型，甚至微軟自家的 Phi 系列。作為企業架構師，你能讓這些模型在同樣的資安架構與計費標籤下並存，這是連直接使用原廠 API 也很難辦到的綜合管理優勢。

核心亮點：打破黑箱的 Prompt Flow

在所有 Foundry 的功能中，我覺得最能讓開發者「哇！」一聲的，就是 Prompt Flow。

回到一開始的痛點：複雜的 RAG 管線。傳統開發者只能把它寫死在 Python def 裡面，一出錯，只能到處 console.log。

傳統程式碼呼叫 API Debug 困難與 Prompt Flow 視覺化節點即時追蹤的對比圖

圖說：Prompt Flow 讓整個業務邏輯變得可視化。當回答出錯時，你可以點開中間的節點，立刻看出「啊，原來是資料庫撈回來的文章根本就不對！」

Prompt Flow 帶來的好處：

  1. DAG 可視化：它強迫你把業務邏輯抽象成 有向無環圖 (DAG)。不管是呼叫 Python function, LLM node, 還是 Prompt Tool，每一個節點的 Input 和 Output 都被記錄下來。
  2. Batch Testing (批次測試)：當你要換上新的 System Prompt 時，直接上傳一份包含 100 道 Q&A 的 Excel 檔，讓 Flow 自動跑完，比起你人工輸入 100 次還要精準快速。
  3. 一鍵部署：拉好的 Flow 確認沒問題，不用重新包裝，按一個鍵就能將這個圖表轉換並部署成一個標準的 REST API Endpoint，直接交給前端或是 LINE Bot 串接。

企業級護城河：Evaluation & Safety (質檢與安控)

當應用準備上線前，企業主管一定會問：「這個 AI 如果罵客人，或是胡說八道怎麼辦？」

傳統做法是再寫幾條正規表示式（Regex）去擋，但在 Gnerative AI 時代根本擋不住。Foundry 提供了內建的 Evaluation 機制：

  • Groundedness (扎實度/防幻覺)：它會自動讓另一個 AI 去評比：「生成的回答，是否 100% 來自於檢索到的知識庫文章？」如果有哪怕一句話是瞎掰的，就會被抓出來扣分。
  • Content Safety：內建的內容安控過濾器，自動攔截仇恨言論、暴力、或者是越獄 (Jailbreak) 嘗試。

💡 實戰落地建議

在開發初期的 MVP (最小可行性產品)，先用簡單的 Python 原生腳本測試可行性。但只要你的專案準備跨入「多人協作」或「交付給企業維運(Ops)」的階段，強烈建議將核心邏輯轉移到 Foundry 的 Prompt Flow 上。這不是為了炫技，而是為了未來 100 次的 Prompt 迭代能擁有版本控制與客觀的評測數據。

小結與下一步

Azure AI Foundry 把「AI 玩具」變成了「企業級軍火庫」。它補足了模型本身以外的所有痛點：流程編排、測試與上線監控。

但是，當我們把核心業務交給這些 AI 模型處理時，隨之而來的**「資安焦慮」**卻是這一切最大的絆腳石。

「我們的客戶資料丟給 Azure OpenAI，真的不會被微軟拿去訓練 GPT-5 嗎？」 「如果我的 API Key 不小心 push 到 GitHub，是不是今晚就破展了？」

下一篇，我們就要切入大企業導入 AI 最頭痛的問題：《Azure OpenAI：為什麼企業不直接刷卡買 OpenAI API？》。我們將直擊 VNet 網路隔離與 RBAC 資安驗證，徹底打通最後一哩路。

留言討論