使用模型目錄探索模型

在建置 AI 應用程式時，最困難的部分往往不是實作，而是挑選正確的模型。你可以擁有強大的提示詞與乾淨的工作流程，但如果模型不匹配，品質和速度都會大打折扣。

在本章中，我們將使用 Visual Studio Code 中的 Foundry Toolkit，走過一條從建議到並排驗證的實用選擇路徑。

可以把它想像成「有憑有據」的模型選擇。

每個步驟本身都很有用。而真正的魔力在於完整迴圈端對端執行的時候。

您將學到什麼

本章旨在建立一個可重複使用的模型選擇流程，而不是一次性的猜測。我們將結合 GitHub Copilot 建議、模型目錄篩選、模型卡片檢視、部署以及 Playground 比較，組合成一個你可以重複使用的迴圈。

在本章中，你將學會如何：

• 產生入選名單：使用 GitHub Copilot 產生一組初步且切合實際的候選名單。
• 精煉目錄：使用篩選條件將模型選項縮減為相關的子集。
• 驗證功能：在部署前檢查模型卡片。
• 部署選定的模型：將選定的候選模型推送至你的 Foundry 專案中。
• 比較行為：在 Playground 中並排評估輸出結果。

在我們執行工作流程之前，先來釐清為什麼這個結構如此重要。

問題定調：模型選擇是一個降低風險的過程

將模型選擇視為降低風險的過程，而不是偏好測試，這會很有幫助。你不是在尋找普遍意義上「最好」的模型，而是在為你的工作負載、限制條件和區域尋找最可靠的適配模型。

這種框架改變了你評估結果的方式，因為一致性與可部署性跟輸出風格一樣重要。

漂亮的輸出很好，但可部署的輸出才是贏家。

應用此原則的一個簡單方法是，針對四個實用檢查項目對每個候選模型進行評分：功能適配性、區域可用性、成本狀況，以及在相同提示詞下的行為品質。當某個模型在這些檢查中勝出時，你對工程與產品利害關係人就更容易捍衛你的選擇。

先決條件

在進行任何比較之前，我們先確保環境已經準備就緒。本章依賴本機工具與雲端可用性，因此現在進行快速的設定檢查，可以避免日後遇到討厭的失敗。

如果這些先決條件都已就緒，本章中的每一個步驟都應該能與你在使用者介面（UI）中看到的內容完美對應。

• Visual Studio Code：已安裝並更新，以確保擴充功能工作流程和命令介面可用。
• Foundry Toolkit 擴充功能：已安裝且可在活動列中看到。
• Azure 訂用帳戶與區域：已選取，用於部署檢查與配額感知篩選。
• 已連線的 Foundry 專案：可在 Foundry Toolkit 的資源下方取得。

確認設定後，讓我們明確定義本章所教授的內容，以及它如何對應到日常的模型工作。

你即將用可重複的迴圈取代憑感覺猜測。

為什麼模型選擇很重要

當你有多個提供者、模型系列、大小和功能標誌時，模型選擇很快就會變得令人應接不暇。結構化的流程可讓決策立基於證據，並防止團隊僅根據個人偏好進行最佳化。

它還能建立可追溯性，這在你需要向利害關係人解釋結果時至關重要。

例如，如果你的情境需要影像輸入且部署在瑞典中部（Sweden Central），那麼一個整體表現優秀但在該區域無法使用的模型就不是實際的選擇。這正是嚴謹的「篩選與驗證」工作流程能節省時間的地方。

在實務上，這個工作流程能為你提供：

• 更快速的縮小範圍：在進行深入測試之前，減少龐大的候選集。
• 更高的信心：在定案之前驗證功能與可用性。
• 更清晰的權衡分析：使用相同的提示詞比較速度、風格與品質。
• 更切合正式環境：選擇符合配額、區域和部署限制的模型。

接下來我們來談談如何在實務中執行這個工作流程。

步驟 1：從 GitHub Copilot 建議開始

在深入了解目錄之前，先從 GitHub Copilot 的建議開始是個好主意。這是因為 Copilot 在提供建議時，可以將功能需求與訂用帳戶及區域限制結合起來。

對於這個步驟，讓我們要求一個符合三個實用標準的模型入選名單：

• Toolkit 支援：模型是否可透過你目前的 Foundry 流程存取。
• 區域可部署性：你的目標區域是否支援該模型。
• 功能適配性：是否具備影像處理或其他必要的功能。

因此，一個適合 Copilot 的提示詞，應該是將這三個限制結合成單一請求，如下所示：

Recommend two models for a marketing scenario that require image input support and are deployable in my subscription and region.

接著，讓我們使用這個提示詞：

1. 在 Visual Studio Code 中開啟 GitHub Copilot Chat。

2. 貼上你的建議提示詞。

3. 在 Chat 中執行提示詞，而不是在終端機中。

   以下是你可以使用的範例提示詞：

    Recommend two models for a marketing scenario that require image input support and are deployable in my subscription and region.
   

   

   圖 1：向 GitHub Copilot 索取模型建議的範例提示詞。

4. 檢視回應並記下建議的模型。

   

   圖 2：來自 GitHub Copilot 建議的範例結果。

這比單靠冷冰冰地捲動瀏覽數百個模型要好得多。

既然我們已經有了起點，接下來就進入目錄，看看如何篩選和驗證候選模型。

步驟 2：探索模型目錄

模型目錄（Model Catalog）是你在 Foundry Toolkit 中的核心探索介面。你可用它來比較來自多個提供者的模型、檢查功能，並在確定選用某個候選模型之前驗證部署限制。

接著，讓我們開啟目錄，看看如何將候選名單縮減至易於管理的數量，以便進行更深入的檢查。

1. 開啟 Foundry Toolkit。
2. 前往開發人員工具（Developer Tools）。
3. 在檢視任何特定模型之前，先選取模型目錄。

現在你應該會看到一個包含多個提供者與代管路徑的模型清單，類似下圖：

圖 3：Foundry Toolkit 中的模型目錄。

在下一個步驟中，我們將套用篩選條件，將此清單縮小為一組易於管理的候選模型。

步驟 3：使用篩選條件縮小候選範圍

篩選有助於將候選清單縮小至符合我們需求的一組易於管理的模型。當需求包含特定功能需求（例如視覺輸入）時，這特別有用。

以下是你可以套用以將候選模型縮減至可管理集合的所有篩選條件：

• 代管來源：限制為你實際計畫部署的代管路徑。
• 發行者：有意識地在單一提供者內或跨提供者比較模型。
• 功能支援：要求例如附加影像等功能。
• 執行階段類型：在相關時包含本機 CPU、GPU 或 NPU 選項。
• 微調支援：僅保留符合調適要求的模型。

接著，讓我們從「有趣的清單」進展到「實際的候選模型」。

1. 在模型目錄中開啟篩選器面板。

2. 依如下方式設定篩選條件：

   代管於 (Hosted By)：Foundry 發行者 (Publisher)：OpenAI

   你應該會看到類似下方縮減後的候選清單。

   

   圖 4：Foundry Toolkit 中的模型篩選器面板。在此我們選取 Hosted By: Foundry、Publisher: OpenAI

   你的候選清單會縮減至一個可在幾分鐘內檢查完畢的易管理集合，而不必逐一掃描數十個項目。

屆時，下一步是檢視每個候選模型的模型卡片，以在部署前確認功能、定價與限制。

步驟 4：檢視模型卡片

在部署之前，請開啟每個模型卡片，並驗證提供者實際保證了什麼內容。這可防止日後發生隱藏的不匹配狀況，特別是在定價、輸入限制和功能假設方面。

可以把它看作是你的部署前檢查。

在實務上，模型卡片檢視應該回答：這個模型能否以可接受的成本、符合預期的行為外觀，做到我們需要的事情？

• 功能：確認所需的模態與優勢。
• 使用案例：檢查你的情境是否與預期用途一致。
• 定價：了解預期的 Token 成本行為。
• 技術規格：檢視限制、內容相關詳細資料與作業限制。

若要檢視模型卡片：

1. 選取一個經過篩選的模型。
2. 開啟其模型卡片頁面。
3. 在進入部署之前，先檢查功能與定價。

當你對模型卡片的檢視感到滿意後，就可以準備將候選模型部署到你的 Foundry 專案中進行並排比較。

步驟 5：部署入選模型

部署將模型比較從理論帶入實際動手測試。在此步驟中，兩個 OpenAI 候選模型將被部署到同一個 Foundry 專案中，以便在相同的提示詞下進行評估。

太好了，讓我們開始進行部署。

1. 從模型卡片中選擇部署 (Deploy)。
2. 選取你已連線的 Foundry 專案作為部署目標。

這應該會啟動一個需要幾分鐘的部署流程。完成後，你將會在你的 Foundry 專案中看到已部署的模型。

在下一個步驟中，我們將在 Playground 中並排比較這兩個已部署的模型，以評估它們在相同提示詞下的行為表現。

步驟 6：在 Playground 中比較模型

模型選擇中的一個重要步驟是比較相同提示詞下的輸出。這可確保輸出結果的差異是由於模型行為所致，而不是提示詞漂移。

這次比較使用了兩種提示詞類型來突顯不同的優勢：行銷文字提示詞和視覺擷取提示詞。

以下是我們將用於比較的兩個提示詞：

文字提示詞:

Generate a short LinkedIn post for developer productivity with AI tools.

視覺提示詞:

Extract text from an attached image.

接下來，我們將使用 Playground 的「比較」(Compare) 模式來並排評估這兩個已部署的模型。

若要進行此項比較，請遵循以下步驟：

1. 開啟 Playground。
2. 啟用「比較」(Compare) 模式。
3. 將一個已部署的模型指派給每個回應窗格。

當你檢查輸出時，請評估一組一致的維度：

• 延遲：哪一個模型能更快返回可用輸出？
• 風格：語氣、流暢度與結構有什麼不同？
• 詳細程度：針對該任務而言，回應是簡潔的還是過於冗長？
• 情境適配性：哪一個輸出更貼近業務的實際需求？

選定候選模型後，還有一個重要步驟：提示詞與參數微調。

步驟 7：使用提示詞與參數微調行為

模型選擇只是品質的一部分。你仍然需要透過系統指令和生成控制來塑造輸出行為。

在你深入探討代理程式工作流程之前，這個步驟會使回應與語音、受眾和管道限制保持一致。

典型的微調過程是新增系統提示詞，並以小幅度調整生成控制，然後使用相同的情境提示詞重新測試。

• 系統提示詞：設定角色、語氣與輸出邊界。
• 最大回應 Token 數：控制回應長度。
• 溫度 (Temperature)：調整創造力與確定性之間的平衡。
• Top-p：調整 Token 取樣行為。

以下是你可以用來微調行為的簡單微調迴圈：

1. 在 Playground 中新增系統提示詞。
2. 每次調整一個生成設定。
3. 在調整下一個設定之前，先評估每次變更的結果。

快速問答

如果兩個模型的文字品質同樣優秀，但其中一個在你的目標區域無法使用，哪一個才是較好的正式環境選擇？為什麼？

解答

較好的正式環境選擇是那個能夠在你的目標區域部署、且具備可接受行為與成本的模型。稍微好一點但無法部署在你需要之處的輸出，會造成日後無法掩蓋的交付風險。正式環境適配性永遠包含可用性，而不僅僅是原始輸出品質。

後續步驟

你現在已經準備好從模型選擇跨入代理程式開發。在下一章中，我們將利用這個模型評估基礎來建置代理程式，使其能夠提出更好的問題、有效使用工具，並產生產出更容易評估與發布的結果。

你現在是用訊號（而非憑感覺）來驅動模型決策。

深入了解

如果你想鞏固本章的學習內容，最好的下一步是從三個角度來檢視相同的工作流程：本文字指南、產品指導與部署細節。這種結合有助於你從理解概念過渡到在實際專案中應用它們。請依序使用下方的連結，你將從教學與參考資料的雙重視角中看到相同的「建議到比較」流程。

• Visual Studio Code 中的 GitHub Copilot：在 Visual Studio Code 文件中檢視 Copilot 功能與工作流程。
• 選看的隨附影片：觀看本章的完整影片。
• 模型目錄概觀：檢視官方模型目錄文件。
• Foundry SDK 開發指南：探索 Azure AI Foundry 的 SDK 導向開發指南。
• 模型部署參考：了解如何在 Azure AI Foundry 中部署 OpenAI 模型。
• 後續步驟：代理程式快速入門：繼續閱讀 Azure AI 代理程式快速入門。