使用模型目录探索模型
在构建 AI 应用程序时，最难的部分往往不是实现，而是挑选正确的模型。你可以拥有强大的提示词和清晰的工作流，但如果模型不匹配，质量和速度都会受到影响。
在本章中，我们将使用 Visual Studio Code 中的 Foundry Toolkit，走一条从推荐到并排验证的实用选择路径。
可以把它看作是有据可查的模型选择。
每个步骤本身都很有用。当完整的循环端到端运行时刻，真正的魅力才会显现。
你将学到什么
本章旨在建立一个可重复的模型选择过程，而不是进行一次性猜测。我们将 GitHub Copilot 推荐、模型目录筛选、模型卡片查看、部署以及 Playground 对比结合到一个可重复使用的循环中。
在本章中，你将学习如何
- 生成入围名单：使用 GitHub Copilot 生成最初的一组符合实际的候选模型。
- 精简目录：使用筛选器将模型选项缩减为相关的子集。
- 验证功能：在部署前检查模型卡片。
- 部署所选模型：将选定的候选模型推送到你的 Foundry 项目中。
- 对比行为：在 Playground 中并排评估输出。
在运行工作流之前，让我们先明确为什么这种结构如此重要。
问题界定：模型选择是一个降低风险的过程
这有助于将模型选择视为降低风险，而不是偏好测试。你并不是在寻找普遍意义上“最好”的模型。你是在为你的工作负载、限制条件和区域寻找最可靠的匹配项。
这种界定改变了你评估结果的方式，因为一致性和可部署性与输出风格同样重要。
漂亮的输出很好，但可部署的输出才是赢家。
应用这一原则的一个简单方法是对每个候选模型进行四项实际检查并评分：功能契合度、区域可用性、成本概况以及在相同提示词下的行为质量。当某个模型在这些检查中全面胜出时，你的选择在工程和产品利益相关者面前就更容易站得住脚。
前提条件
在进行任何对比之前，让我们确保环境已就绪。本章依赖于本地工具和云可用性，因此现在进行快速设置检查可以避免以后出现烦人的故障。
如果满足这些先决条件，本章中的每个步骤都应该与你在用户界面中看到的内容完美对应。
- Visual Studio Code：已安装并更新，以便使用扩展工作流和命令界面。
- Foundry Toolkit 扩展：已安装并在活动栏中可见。
- Azure 订阅和区域：已选择，用于部署检查和配额感知的筛选。
- 已连接的 Foundry 项目：可在 Foundry Toolkit 的资源下列出。
确认设置后，让我们明确本章的具体内容及其如何映射到日常模型工作中。
你即将用一个可重复的循环来取代凭猜测行事。
为什么模型选择至关重要
当面对多个提供商、模型系列、大小和功能标志时，模型选择很快就会让人应接不暇。结构化的流程可以使决策立足于证据，并防止团队仅凭偏好进行优化。
它还创造了可追溯性，这在需要向利益相关者解释结果时非常重要。
例如，如果你的场景需要图像输入并部署在瑞典中部（Sweden Central），那么一个总体上非常优秀但在该区域不可用的模型就不是一个实际的选择。这正是严谨的“筛选与验证”工作流节省时间的地方。
实际上，此工作流为您带来
- 更快地缩小范围：在深入测试之前减少大型候选集。
- 更高的置信度：在投入之前验证功能和可用性。
- 更清晰的权衡分析：使用相同的提示词对比速度、风格和质量。
- 更好的生产契合度：选择符合配额、区域和部署限制的模型。
接下来我们谈谈如何在实践中运行此工作流。
第一步：从 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.
接下来，让我们使用这个提示词
-
在 Visual Studio Code 中打开 GitHub Copilot Chat。
-
粘贴你的推荐提示词。
-
在聊天中运行提示词，而不是在终端中。
这里有一个你可以使用的示例提示词
Recommend two models for a marketing scenario that require image input support and are deployable in my subscription and region.
图 1：向 GitHub Copilot 索取模型推荐的示例提示词。
-
查看回复并记下推荐的模型。
图 2：来自 GitHub Copilot 推荐的示例结果。
这比盲目滚动浏览数百个模型要好得多。
现在我们有了一个起点，让我们进入目录，看看如何筛选和验证候选模型。
第二步：探索模型目录
模型目录是 Foundry Toolkit 中的核心发现界面。在确定候选模型之前，你可以使用它来对比来自多个提供商的模型、检查功能以及验证部署限制。
接下来，让我们打开目录，看看如何将候选集缩减到易于管理的数量，以便进行更深入的检查。
- 打开 Foundry Toolkit。
- 转到开发人员工具（Developer Tools）。
- 在查看任何特定模型之前，选择模型目录（Model Catalog）。
现在，你应该会看到一个包含多个提供商和托管路径的模型列表，类似于下图
图 3：Foundry Toolkit 中的模型目录。
在下一步中，我们将应用筛选器将此列表缩小为可管理的候选集。
第三步：使用筛选器缩小候选范围
筛选有助于将候选列表缩小为满足我们要求的可管理模型集。当要求包含特定功能需求（如视觉输入）时，这一点尤其有用。
以下是可以用来将候选模型缩减到可管理范围的所有筛选条件
- 托管源：限制为你实际计划部署的托管路径。
- 发布者：有意识地在某个提供商内部或跨提供商对比模型。
- 功能支持：需要诸如图像附件等功能。
- 运行时类型：在相关时包括本地 CPU、GPU 或 NPU 选项。
- 微调支持：仅保留符合适应要求的模型。
接下来，让我们从“有趣的列表”过渡到“实际的候选模型”。
-
打开模型目录中的筛选面板。
-
这样设置筛选器
托管方：Foundry 发布者：OpenAI
你应该会看到一个缩减后的候选列表，类似于下方所示。
图 4：Foundry Toolkit 中的模型筛选面板。在此我们选择：托管方：Foundry，发布者：OpenAI
你的候选列表会缩减到一个可在几分钟内检查完毕的可管理集合，而不必浏览数十个条目。
此时，下一步是查看每个候选模型的模型卡片，以在部署前确认功能、定价和限制条件。
第四步：查看模型卡片
在部署之前，打开每个模型卡片并核实提供商实际保证的内容。这可以防止以后出现隐藏的不匹配，尤其是在定价、输入限制和功能假设方面。
可以将此视为部署前检查。
实际上，模型卡片审查应该回答：这个模型能否以可接受的成本和预期的行为特征，完成我们需要它做的事情？
- 功能：确认所需模态和优势。
- 用例：检查你的场景是否与预期用途一致。
- 定价：了解预期的 Token 成本表现。
- 技术规格：审查限制、上下文详情和操作约束。
要查看模型卡片
- 选择一个筛选出的模型。
- 打开其模型卡片页面。
- 在转入部署之前检查功能和定价。
对模型卡片审查满意后，你就可以将候选模型部署到 Foundry 项目中进行并排对比了。
第五步：部署入围模型
部署将模型对比从理论转变为实操测试。在此步骤中，两个 OpenAI 候选模型将被部署到同一个 Foundry 项目中，以便在相同的提示词下进行评估。
很好，让我们开始部署。
- 从模型卡片中选择“部署（Deploy）”。
- 选择你连接的 Foundry 项目作为部署目标。
这将启动一个需要几分钟才能完成的部署过程。完成后，你将在 Foundry 项目中看到部署好的模型。
在下一步中，我们将在 Playground 中并排对比这两个部署的模型，以评估它们在相同提示词下的行为。
第六步：在 Playground 中对比模型
模型选择中的一个重要步骤是对比相同提示词下的输出。这可以确保输出的差异是由模型行为引起的，而不是由提示词漂移引起的。
此次对比使用两种提示词类型来展现不同的优势：营销文本提示词和视觉提取提示词。
以下是我们用于对比的两个提示词
文本提示词:
Generate a short LinkedIn post for developer productivity with AI tools.
视觉提示词:
Extract text from an attached image.
接下来，我们将使用 Playground 的对比（Compare）模式来并排评估两个部署的模型。
要进行此对比，请遵循以下步骤
- 打开 Playground。
- 启用对比（Compare）模式。
- 为每个响应窗格指定一个部署的模型。
在检查输出时，请评估一组一致的维度
- 延迟：哪个模型更快返回可用的输出？
- 风格：语气、流利度和结构有何不同？
- 冗长程度：针对该任务，回复是简洁还是过于冗长？
- 场景契合度：哪个输出更接近业务的实际需求？
选择候选模型后，还有一个重要步骤：提示词和参数优化。
第七步：通过提示词和参数优化行为
模型选择只是质量的一部分。你仍然需要通过系统指令和生成控制来塑造输出行为。
在深入了解智能体工作流之前，此步骤可使回复与声音、受众和渠道限制保持一致。
典型的优化过程包括添加系统提示词、以小幅度调整生成控件，然后使用相同的场景提示词重新测试。
- 系统提示词：设置角色、语气和输出边界。
- 最大响应 Token 数：控制回复长度。
- 温度（Temperature）：调整创造力与确定性。
- Top-p：调整 Token 采样行为。
以下是可用于调整行为的简单优化循环
- 在 Playground 中添加系统提示词。
- 每次调整一个生成设置。
- 在调整下一个设置之前评估每次更改。
快速提问
如果两个模型产生同样好的文本，但其中一个在你的目标区域不可用，哪一个才是更好的生产选择？为什么？
回答
更好的生产选择是能够在你的目标区域部署且具备可接受的行为和成本的模型。稍微好一点但无法在你需要的地方部署的输出，会带来以后无法掩盖的交付风险。生产契合度始终包括可用性，而不仅仅是原始输出质量。
下一步计划
你现在可以从模型选择转向智能体开发了。在下一章中，我们将利用这个模型评估基础来构建智能体，让它们提出更好的问题、有效地使用工具，并产出更容易评估和发布的输出。
现在驱动模型决策的是信号（有据可依），而不是直觉。
了解更多
如果你想巩固本章内容，最佳的下一步是从三个角度审查相同的工作流：本文字指南、产品指南和部署详情。这种组合可帮助你从理解概念过渡到在实际项目中应用它们。请按顺序使用以下链接，你将从教程和参考的角度看到相同的“推荐到对比”流程。
- Visual Studio Code 中的 GitHub Copilot：在 Visual Studio Code 文档中查看 Copilot 功能和工作流。
- 可选配套视频：观看本章的完整视频。
- 模型目录概述：查看官方模型目录文档。
- Foundry SDK 开发指南：探索 Azure AI Foundry 的基于 SDK 的开发指南。
- 模型部署参考：了解如何在 Azure AI Foundry 中部署 OpenAI 模型。
- 下一步智能体快速入门：继续阅读 Azure AI 智能体快速入门。