你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
在 AI 开发的快速发展环境中，选择正确的模型既是基础决策，也是战略决策。 数以千计的模型可用于部署，并定期开发和发布更多模型。 本文重点介绍可用于改进决策过程的策略。
注释
如果所选的模型满足工作负荷要求，可以继续使用它。 GPT-5 等常规用途模型可以有效处理各种任务。 与运行冗长的评估过程相比，继续使用经过验证的模型可以节省宝贵的开发时间。
模型选择的关键条件
多个条件可能会影响模型选择。 根据工作负荷的独特特征和组织优先级，某些条件可能比其他条件更重要。 每个条件都用作筛选器，以将数千个可用模型减少到更易于管理的集。 以下列表按常规优先级排序，从通常影响最大的因素开始。
适合任务
确定模型的目的，例如聊天、推理、嵌入、检索扩充生成（RAG）或多模式处理。
选择 AI 模型时，请选择一个模型，该模型具有与需要执行的特定任务一致的功能。 不同的模型针对不同的函数进行优化。 某些模型擅长自然语言处理，如文本分类和摘要。 卷积神经网络（CNN）非常适合视觉数据，包括图像分类和对象检测。 循环神经网络（RNN）和转换器支持音频分析和语音识别。 多模式模型处理合并文本、图像或音频输入的任务。 例如，GPT 模型非常适合文本生成和理解。 若要缩小选项范围，并选择为用例提供最佳性能、准确性和效率的模型，请明确定义任务。 任务包括情绪分析、代码生成或实时对话。
单个模型与多个模型注意事项
在考虑任务的适合性时，请考虑应用程序设计中的工作负荷。 满足所有任务要求的单个模型最适合采用更简单的方法。 或者，可以将任务结构化为多个步骤，每个步骤都使用适合其特定用途的模型。 多个模型在基于 AI 代理的工作负荷设计中很常见，尤其是在使用 AI 代理业务流程模式时。 例如，可以结合语言理解、推理和检索。 这种模块化方法可实现更大的灵活性、可伸缩性和适应性，尤其是在任务发展或需要多样化功能的动态环境中。
请逐一评估并选择在您的工作负荷中包含的每个模型。 为每个模型应用以下注意事项。
成本约束
确定推理和部署的预算限制。
选择 AI 模型时，请考虑成本注意事项，尤其是在将性能与预算约束进行平衡时。 高性能模型通常需要大量的计算资源，这可能会增加基础结构和运营成本，尤其是大规模。 对于资金有限的工作负载，来自云提供商的开源或预训练模型可以是满足性能要求的经济高效选择。 或者，预算较大的工作负荷可能更喜欢专有的模型或自定义训练，以提高精度和特定领域的功能。 将模型选择与最大化投资回报（ROI）的模型保持一致。
上下文窗口大小
确定任务所需的上下文窗口的大小。
选择 AI 模型时，上下文窗口大小应与预期使用的输入数据的复杂性和长度保持一致。 一般来说，大型、功能齐全的模型具有更大的上下文窗口。 这些模型还需要更多的计算资源，并且返回响应的速度通常比较小的专用模型慢。 较大的上下文窗口允许模型一次考虑更多信息，例如较长的文档、扩展对话或复杂的基本代码，而不会丢失早期内容的跟踪。 此功能对于需要一致响应、了解细微差别上下文或引用对话或文档早期部分的任务尤其重要。 相反，具有较小上下文窗口的模型可能更快或更具成本效益，并且最适合更短、更专注的任务。
安全性和合规性
检查模型是否符合组织的安全性和符合性标准和要求。
选择一个模型，该模型符合组织的安全标准和法规义务，以降低风险和维护信任。 在受管制行业（如医疗保健、金融或政府）运营的组织必须确保其模型符合一般数据保护条例（GDPR）、健康保险可移植性和责任法（HIPAA）或加州消费者隐私法（CCPA）等标准。 他们必须选择在决策过程中提供可靠的数据保护、安全部署选项和透明度的模型。 开放源代码模型可以提供更高的可解释性和控制性，而专有模型可能提供更强大的内置安全措施和支持合规性认证。
区域可用性
检查是否可以在其他工作负荷资源所在的同一区域中部署模型。
有限的区域可用性可能会显著影响 AI 模型选择，尤其是在考虑延迟、数据驻留和合规性要求时。 某些模型仅托管在特定地理区域中，这可能会影响其他位置用户的性能，因为响应时间增加。 受区域数据保护法约束的工作负载（如欧洲的 GDPR 或加州的 CCPA）必须确保所选模型符合本地数据存储和处理法规。
部署策略
检查是否可以在无服务器或托管基础结构、自己的基础结构或直接在设备上托管模型。
模型必须部署在计算资源上后才能被使用。 这些计算资源可以来自您的云提供商，与其他云客户共享基础设施，或者可以是与您的工作负载本地化的，例如直接在代码中运行的本地进程。 某些模型通过提供商的无服务器平台（有时称为模型即服务（MaaS））可用，但这些模型要么太大，要么未获授权用于在你自己的计算环境中部署。 提供商的托管不支持某些专用模型，因此只能在自己的推理环境中运行它们。
工作负荷要求限制每个任务的计算平台选项。 此约束可有效地根据可部署模型的位置来限制可以使用哪些模型来满足效率、成本和合规性要求。 根据可用的托管，在 SDK 中还可以选择针对该模型执行推理。 某些平台提供统一的 SDK，支持调用所有托管模型。 其他计算平台要求使用模型提供程序生成的 SDK。
域特定性
检查模型是否预先训练了与行业相关的数据，例如财务或医疗保健。
预先训练与行业相关的数据（如医疗保健、财务或法律）的 AI 模型可以在准确性、效率和上下文理解方面具有显著优势。 这些模型基于特定于域的术语、法规细微差别和典型工作流进行训练。 此训练减少了广泛重新训练和微调的需求。 因此，它们可以提供更精确的预测、生成更相关的内容，并支持在实际应用程序中更快地部署。 行业特定的预训练还有助于确保合规性并提高可信度，尤其是在那些强调精确性和可靠性的领域。
Performance
确定你对响应速度和准确性的要求。
每个 AI 模型都有内置的性能限制，以及如何托管模型可以引入额外的限制。 模型及其托管设置决定了它可以响应的速度以及一次可以处理的请求数。 根据系统或应用程序使用模型的方式，必须选择符合系统要求的模型，或调整系统，以匹配模型可以实际处理的内容。
你通常想要选择一个符合质量标准的模型，同时尽快做出响应。 它还应该以支持预期的请求量的方式进行托管，而不会造成延迟或降低用户体验。
注释
一些交叉问题（如实施负责任的 AI 策略）可能会带来额外的性能限制。 应将这些限制包含在评估中，但它们不应影响模型选择。
模型可优化性
确定所需的自定义量。
某些 AI 模型提供了许多超参数，你可以根据应用程序需求进行优化。 示例包括深度神经网络和梯度提升计算机。 这些模型提供对学习速率和体系结构等参数的精细控制，这使得它们非常适合准确性至关重要的高风险任务。 或者，更简单的模型（如线性回归或决策树）更易于部署和解释，这使得它们适用于较小的数据集、实时用例或具有有限机器学习体验的团队。 可调整性还会影响通用化。 过于复杂的模型可能会过度拟合，而更简单的模型可能会欠拟合，但可提供更稳定的性能。 另请考虑资源约束，因为高度可调整的模型通常需要更多的训练时间、内存和自动优化工具。
其他因素
以前的条件通常与工作负荷的功能和非功能要求密切相关。 但其他因素有时与决策过程相关。 这些因素通常是大多数工作负荷的最低优先级，但工作负荷在特定情况下可能会为它们分配更大的重要性。 以下因素还会影响模型选择决策：
- 许可证类型
- 多语言功能
- 支持计划（社区或付费）
- 可持续性和环境影响报告
- 更新周期（bug 修复和模型修订）和停用策略
用于模型选择的非标准条件
不要在决策中包括以下因素，因为它们很少符合工作负荷的功能或非功能要求：
- 文化人气
- 发布者，如 OpenAI、Meta、Microsoft、xAI 等
优化模型选择
为了帮助你有效地应用选择条件，请使用像 Hugging Face、Foundry 模型和 GitHub 模型这样的目录。 这些服务提供与以前的许多决策条件（如任务）保持一致的筛选器，以帮助你减少可供选择的模型数量。
评估和基准测试
若要执行并行 AI 模型评估，请首先根据应用程序的特定需求（例如准确性、速度、成本、上下文保留和输出质量）定义一组明确的条件。 然后在同一个代表性数据集或任务集中运行候选模型，以确保一致的输入和评估条件。 通过使用相关性、一致性、延迟和用户满意度等指标，以定性和定量方式比较输出。 在评估过程中，让利益干系人或用户参与评估过程，以收集有关哪个模型最符合实际期望的反馈也很有帮助。 此结构化方法可帮助你就哪种模型最适合你的用例做出明智的决策。
还可以使用 Hugging 人脸基准集合等工具来评估语言支持、推理和安全模型。 请参阅多个基准测试源，了解特定模型如何在各种实际方案中执行。 此方法可降低来自任何单个模型主机的偏差风险。
模型主机可能在其平台上提供内置评估工具，我们建议你利用它们。 有关详细信息，请参阅 使用 Microsoft Foundry 评估生成 AI 模型。
微调和酿酒
在许多情况下，需要进行一些微调来训练数据集上的模型。 此要求可能会影响模型选择，因为某些模型不支持微调。 提取是指使用在数据集上训练的模型来训练另一个通常更小、更专用的模型。 通过这种做法，可以通过提高性能和降低成本来构建更高效的工作负荷。 与微调一样，某些模型不支持提取，因此在规划工作负荷设计时请考虑此要求。
规划模型更改
选择模型不是一次性活动。 在概念证明（POC）或原型阶段，可以选择一个边界模型来加快生成速度。迁移到生产环境时，更专业化的模型，甚至小型语言模型可能更合适。 随着工作负荷的发展，最初选择的模型可能无法按预期方式执行，或者计划的功能可能与该模型不一致。 为了跟上市场的进步，你可能还需要定期将模型替换为较新版本。 有关模型生命周期注意事项的详细信息，请参阅 设计以支持基础模型生命周期。
为了使您的体系结构具备应对未来的能力，请考虑以下去风险化的方法：
使用抽象层（如 Azure AI 推理 SDK）避免供应商锁定。
通过切换环境变量和比较输出来并行测试模型。
除非保证可观测性和可追溯性，否则避免不透明路由。