Базовая эталонная архитектура чата OpenAI

Корпоративные приложения чата могут предоставлять сотрудникам возможность взаимодействия с беседами. Это особенно верно из-за непрерывного развития языковых моделей, таких как модели GPT OpenAI и модели LLaMA Мета. Эти приложения чата состоят из пользовательских интерфейсов чата, репозиториев данных, содержащих сведения, относящиеся к запросам пользователя, языковым моделям, которые приводят к получению соответствующего ответа, а также оркестратору, который контролирует взаимодействие между этими компонентами.

В этой статье представлена базовая архитектура для создания и развертывания корпоративных приложений чата, использующих языковые модели службы OpenAI Azure. Архитектура использует поток запроса для создания исполняемых потоков. Эти исполняемые потоки оркеструет рабочий процесс из входящих запросов к хранилищам данных для получения данных для языковых моделей, а также другой требуемой логики Python. Поток исполняемого файла развертывается в управляемой сетевой конечной точке с управляемыми вычислительными ресурсами.

Размещение пользовательского пользовательского интерфейса чата следует рекомендациям по базовому веб-приложению служб приложений для развертывания безопасного, избыточного между зонами и высокодоступного веб-приложения в службе приложение Azure. В этой архитектуре Служба приложений взаимодействует с решением Платформы Azure как услуга (PaaS) через интеграцию виртуальной сети с частными конечными точками. Пользовательский интерфейс чата Служба приложений взаимодействует с управляемой конечной точкой в Сети для потока через частную конечную точку. Общедоступный доступ к порталу Azure AI Foundry отключен.

Центр Azure AI Foundry настроен с изоляции управляемой виртуальной сети, требующей утверждения всех исходящих подключений. С помощью этой конфигурации создается управляемая виртуальная сеть, а также управляемые частные конечные точки, которые позволяют подключаться к частным ресурсам, таким как рабочая служба хранилища Azure, Реестр контейнеров Azure и Azure OpenAI. Эти частные подключения используются во время разработки и тестирования потоков, а также потоками, развернутыми для Машинное обучение вычислений.

Центр — это ресурс Azure AI Foundry верхнего уровня, который обеспечивает центральный способ управления безопасностью, подключением и другими проблемами в нескольких проектах. Для этой архитектуры требуется только один проект для рабочей нагрузки. Если у вас есть дополнительные возможности, требующие разных потоков запросов с другой логикой, потенциально используя различные внутренние ресурсы, такие как хранилища данных, можно рассмотреть возможность реализации этих потоков в другом проекте.

Архитектура

Скачайте файл Visio для этой архитектуры.

Компоненты

Многие компоненты этой архитектуры совпадают с базовой архитектурой чата Azure OpenAI. В следующем списке выделены только изменения базовой архитектуры.

• Azure OpenAI используется как в базовой, так и в этой базовой архитектуре. Azure OpenAI — это полностью управляемая служба, которая предоставляет доступ REST API к языковым моделям Azure OpenAI, включая GPT-4, GPT-3.5-Turbo и набор моделей внедрения. Базовая архитектура использует преимущества корпоративных функций, таких как виртуальная сеть и приватный канал , что базовая архитектура не реализует.
• Azure AI Foundry — это платформа, которую можно использовать для создания, тестирования и развертывания решений ИИ. Портал Azure AI Foundry используется в этой архитектуре для создания, тестирования и развертывания логики оркестрации потоков запроса для приложения чата. В этой архитектуре Azure AI Foundry предоставляет управляемые виртуальные сети для обеспечения безопасности сети. Дополнительные сведения см. в разделе "Сеть".
• Шлюз приложений — это подсистема балансировки нагрузки уровня 7 (HTTP/S) и маршрутизатор веб-трафика. Он использует маршрутизацию на основе URL-адресов для распределения входящего трафика между зонами доступности и разгрузки шифрования для повышения производительности приложения.
• Брандмауэр веб-приложений (WAF) — это облачная служба, которая защищает веб-приложения от распространенных эксплойтов, таких как внедрение SQL и межсайтовые скрипты. Брандмауэр веб-приложений обеспечивает видимость трафика в веб-приложение и из нее, что позволяет отслеживать и защищать приложение.
• Azure Key Vault — это служба, которая безопасно хранит секреты, ключи шифрования и сертификаты и управляет ими. Она централизованно обеспечивает управление конфиденциальной информацией.
• Виртуальная сеть Azure — это служба, которая позволяет создавать изолированные и безопасные частные виртуальные сети в Azure. Для веб-приложения на Служба приложений требуется подсеть виртуальной сети для использования частных конечных точек для сетевого безопасного взаимодействия между ресурсами.
• Приватный канал позволяет клиентам получать доступ к службам платформы Azure как услуга (PaaS) непосредственно из частных виртуальных сетей без использования общедоступных IP-адресов.
• Azure DNS — это служба размещения для доменов DNS , которая предоставляет разрешение имен с помощью инфраструктуры Microsoft Azure. Частная зона DNS зонах предоставляют способ сопоставления полного доменного имени службы (FQDN) с IP-адресом частной конечной точки.

Альтернативные варианты

Эта архитектура содержит несколько компонентов, которые могут обслуживаться другими службами Azure, которые могут лучше соответствовать функциональным и нефункциональным требованиям рабочей нагрузки. Вот несколько таких альтернатив, которые следует учитывать.

Машинное обучение Azure рабочих областей (и интерфейсов портала)

Эта архитектура использует портале Azure AI Foundry для создания, тестирования и развертывания потоков запросов. Кроме того, можно использовать Машинное обучение Azure рабочих областей, так как обе службы имеют перекрывающиеся функции. Хотя портал Azure AI Foundry является хорошим выбором, если вы разрабатываете решение потока запросов, есть некоторые функции, для которых в настоящее время машинное обучение Azure имеет лучшую поддержку. Дополнительные сведения см. в сравнении функций. Рекомендуется не смешивать и соответствовать порталу Azure AI Foundry и студии машинного обучения Azure. Если вы можете полностью выполнить работу на портале Azure AI Foundry, используйте портал Azure AI Foundry. Если вам по-прежнему нужны функции из Студия машинного обучения Azure, продолжайте использовать Студия машинного обучения Azure.

Компоненты уровня приложений

Существует несколько предложений управляемых служб приложений, доступных в Azure, которые могут служить уровнем приложений для интерфейса пользовательского интерфейса чата. См. статью "Выбор вычислительной службы Azure" для всех вычислений и выбор службы контейнеров Azure для решений контейнеров. Например, в то время как azure веб-приложения и веб-приложение для контейнеров выбраны как для API интерфейса чата, так и для узла потока запроса соответственно аналогичные результаты можно достичь с помощью Служба Azure Kubernetes (AKS) или приложений контейнеров Azure. Выберите платформу приложений рабочей нагрузки на основе конкретных функциональных и нефункциональных требований рабочей нагрузки.

Размещение потока запроса

Развертывание потоков запросов не ограничивается Машинное обучение вычислительными кластерами, и эта архитектура иллюстрирует, что с альтернативой в службе приложение Azure. Потоки в конечном итоге являются контейнерным приложением, которое можно развернуть в любой службе Azure, совместимой с контейнерами. К ним относятся такие службы, как Служба Azure Kubernetes (AKS), приложения контейнеров Azure и служба приложение Azure. Выберите службу контейнеров Azure на основе требований уровня оркестрации.

Пример того, почему размещение потока запросов на альтернативном вычислении является рассмотрением далее в этой статье.

Хранилище данных заземления

Хотя эта архитектура ведет к использованию службы "Поиск ИИ Azure", выбор хранилища данных для данных на основе данных является архитектурным решением, характерным для вашей рабочей нагрузки. Многие рабочие нагрузки на самом деле многоглотовые и имеют разнородные источники и технологии для заземления данных. Эти платформы данных варьируются от существующих хранилищ данных OLTP, облачных собственных баз данных, таких как Azure Cosmos DB, через специализированные решения, такие как поиск ИИ Azure. Общие, но не обязательные, характерные для такого хранилища данных, являются векторным поиском. См. статью "Выбор службы Azure" для поиска векторов для изучения параметров в этом пространстве.

Соображения

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для повышения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Эта архитектура лучше всего подходит для конкретной ситуации, когда усилия по проектированию объединяются с рекомендациями по проектированию, приведенными в рабочих нагрузок ИИ в Azure Well-Architected Framework в принципах и рекомендациях Azure.

Надежность

Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см . в контрольном списке проверки конструктора для обеспечения надежности.

Базовая архитектура веб-приложения Служба приложений сосредоточена на зональной избыточности для ключевых региональных служб. Зоны доступности физически разделяются в пределах региона. Они обеспечивают избыточность в пределах региона для поддержки служб, когда в них развертываются два или более экземпляра. При простое одной зоны другие зоны в регионе по-прежнему могут быть не затронуты. Архитектура также обеспечивает достаточное количество экземпляров служб Azure и конфигурации этих служб для распространения между зонами доступности. Дополнительные сведения см. в базовом плане для просмотра этого руководства.

В этом разделе рассматривается надежность с точки зрения компонентов этой архитектуры, которые не рассматриваются в базовом Служба приложений базовом плане, включая Машинное обучение, Azure OpenAI и поиск ИИ.

Зональная избыточность для развертываний потоков

Корпоративные развертывания обычно требуют зональной избыточности. Чтобы обеспечить зональную избыточность в Azure, ресурсы должны поддерживать зоны доступности, и необходимо развернуть по крайней мере три экземпляра ресурса или включить поддержку платформы, если элемент управления экземплярами недоступен. В настоящее время Машинное обучение вычислительные ресурсы не поддерживают зоны доступности. Чтобы снизить потенциальное влияние катастрофы на уровне центра обработки данных на компоненты Машинное обучение, необходимо установить кластеры в различных регионах вместе с развертыванием подсистемы балансировки нагрузки для распространения вызовов между этими кластерами. Вы можете использовать проверки работоспособности, чтобы убедиться, что вызовы направляются только в кластеры, которые работают правильно.

Существуют некоторые варианты Машинное обучение вычислительных кластеров, таких как Служба Azure Kubernetes (AKS), Функции Azure, приложения контейнеров Azure и служба приложение Azure. Каждая из этих служб поддерживает зоны доступности. Чтобы обеспечить зональную избыточность для выполнения потока запроса без дополнительной сложности развертывания в нескольких регионах, необходимо развернуть потоки в одном из этих служб.

На следующей схеме показана альтернативная архитектура, в которой потоки запросов развертываются в Служба приложений. Служба приложений используется в этой архитектуре, так как рабочая нагрузка уже использует ее для пользовательского интерфейса чата и не будет пользоваться преимуществами внедрения новой технологии в рабочую нагрузку. Группы рабочей нагрузки, имеющие опыт работы с AKS, должны рассмотреть возможность развертывания в этой среде, особенно если AKS используется для других компонентов рабочей нагрузки.

Схема нумеруется для заметных областей в этой архитектуре:

1. Потоки по-прежнему создаются в потоке запросов, а сетевая архитектура не изменяется. Авторы потоков по-прежнему подключаются к интерфейсу разработки в проекте Azure AI Foundry через частную конечную точку, а управляемые частные конечные точки используются для подключения к службам Azure при тестировании потоков.

2. Эта точка показывает, что контейнерные исполняемые потоки отправляются в реестр контейнеров. На схеме не показаны конвейеры, которые контейнеризируют потоки и отправляются в реестр контейнеров. Вычисления, в которых выполняются эти конвейеры, должны иметь сетевую линию видимости к ресурсам, таким как реестр контейнеров Azure и проект Azure AI Foundry.

3. Существует другое веб-приложение, развернутное в том же плане службы приложений, который уже размещает пользовательский интерфейс чата. Новое веб-приложение размещает контейнеризованный поток запросов, совместно размещенный в том же плане службы приложений, который уже выполняется не менее трех экземпляров, распределяется по зонам доступности. Эти Служба приложений экземпляры подключаются к реестру контейнеров через частную конечную точку при загрузке образа контейнера потока запроса.

4. Контейнер потока запроса должен подключаться ко всем зависимым службам для выполнения потока. В этой архитектуре контейнер потока запросов подключается к поиску ИИ и Azure OpenAI. Службы PaaS, которые были доступны только для подсети управляемой частной конечной точки Машинное обучение, теперь также необходимо предоставить в виртуальной сети, чтобы можно было установить линию видимости из Служба приложений.

Azure OpenAI — надежность

Azure OpenAI в настоящее время не поддерживает зоны доступности. Чтобы снизить потенциальное влияние катастрофы на уровне центра обработки данных на развертывания моделей в Azure OpenAI, необходимо развернуть Azure OpenAI в различных регионах вместе с развертыванием подсистемы балансировки нагрузки для распространения вызовов между регионами. Вы можете использовать проверки работоспособности, чтобы убедиться, что вызовы направляются только в кластеры, которые работают правильно.

Для эффективной поддержки нескольких экземпляров рекомендуется выполнить внешнюю настройку файлов, таких как геоизбыточная учетная запись хранения. Этот подход сводит к минимуму состояние, хранящееся в Azure OpenAI для каждого региона. Для каждого экземпляра необходимо настроить файлы для размещения развертывания модели.

Важно отслеживать требуемую пропускную способность с точки зрения маркеров в минуту (TPM) и запросов в минуту (RPM). Убедитесь, что достаточно доверенного платформенного модуля, назначаемого квотой, для удовлетворения требований к развертываниям и предотвращения регулирования вызовов развернутых моделей. Шлюз, например Azure Управление API, можно развернуть перед службой или службами Azure OpenAI и настроить для повторных попыток, если существуют временные ошибки и регулирование. Управление API также можно использовать в качестве средства автоматического останова, чтобы предотвратить перегрузку службы при вызове, превышающей квоту. Дополнительные сведения о добавлении шлюза для проблем с надежностью см. в статье Access Azure OpenAI и другие языковые модели через шлюз.

Поиск ИИ — надежность

Разверните поиск ИИ с ценовой категорией "Стандартный" или выше в регионе , поддерживающем зоны доступности, и разверните три или более реплики. Реплики автоматически распределяют равномерно между зонами доступности.

Рассмотрим следующее руководство по определению соответствующего количества реплик и секций:

• Мониторинг поиска ИИ.

• Используйте метрики мониторинга и журналы и анализ производительности, чтобы определить соответствующее количество реплик, чтобы избежать регулирования на основе запросов и секций, чтобы избежать регулирования на основе индексов.

Azure AI Foundry — надежность

Если вы развертываете вычислительные кластеры за Машинное обучение управляемой сетевой конечной точкой, рассмотрите следующие рекомендации по масштабированию:

• Автоматически масштабируйте свои сетевые конечные точки, чтобы обеспечить доступность достаточной емкости для удовлетворения спроса. Если сигналы об использовании не являются достаточно своевременными из-за ускорения использования, рассмотрите возможность чрезмерной подготовки, чтобы предотвратить влияние на надежность от слишком небольшого числа доступных экземпляров.

• Рекомендуется создавать правила масштабирования на основе метрик развертывания, таких как загрузка ЦП и метрики конечных точек, такие как задержка запросов.

• Для активного рабочего развертывания необходимо развернуть не менее трех экземпляров.

• Избегайте развертываний для экземпляров, используемых в использовании. Вместо этого развернитесь в новом развертывании и переместите трафик после готовности развертывания к получению трафика.

Управляемые сетевые конечные точки служат подсистемой балансировки нагрузки и маршрутизатором для управляемых вычислительных ресурсов, работающих за ними. Вы можете настроить процент трафика, который должен направляться в каждое развертывание, если проценты добавьте до 100 %. Кроме того, вы можете развернуть управляемую конечную точку в Сети с перенаправленным трафиком 0 % в любое развертывание. Если, как и в предоставленной эталонной реализации, вы используете инфраструктуру в качестве кода (IaC) для развертывания ресурсов, включая управляемые сетевые конечные точки, возникает проблема надежности. Если вы настроили трафик для маршрутизации в развертывания (созданные с помощью ИНТЕРФЕЙСА командной строки или портала Azure AI Foundry) и выполняете последующее развертывание IaC, включающее управляемую конечную точку в сети, даже если она не обновляет управляемую конечную точку в сети каким-либо образом, трафик конечной точки возвращается к маршрутизации 0% трафик. Фактически это означает, что развернутые потоки запросов больше не будут доступны, пока вы не измените трафик обратно в нужное место.

Структура с несколькими регионами

Эта архитектура не создается для региональной метки в архитектуре с несколькими регионами. Он обеспечивает высокий уровень доступности в одном регионе из-за полного использования зон доступности, но не хватает некоторых ключевых компонентов, чтобы сделать это действительно готовым к решению с несколькими регионами. Это некоторые компоненты или рекомендации, которые отсутствуют в этой архитектуре:

• Глобальный вход и маршрутизация
• Стратегия управления DNS
• Стратегия репликации данных (или изоляции)
• Обозначение "активный-активный", "активный-пассивный" или "активный-холодный"
• Стратегия отработки отказа и восстановления размещения для достижения RTO и RPO рабочей нагрузки
• Решения о доступности региона для разработчиков в ресурсе Azure Studio Hub

Если требования рабочей нагрузки требуют стратегии с несколькими регионами, необходимо инвестировать в дополнительные усилия по проектированию компонентов и операционных процессов на основе того, что представлено в этой архитектуре. Вы разрабатываете для поддержки балансировки нагрузки или отработки отказа на следующих уровнях:

• Базовые данные
• Размещение моделей
• Уровень оркестрации (поток запроса в этой архитектуре)
• Пользовательский интерфейс, доступный для клиента

Кроме того, вам потребуется поддерживать непрерывность бизнес-процессов в наблюдаемости, интерфейсе портала и ответственных проблемах искусственного интеллекта, таких как безопасность содержимого.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в контрольном списке проверки конструктора для безопасности.

Эта архитектура расширяет объем ресурсов безопасности, реализованных в сквозном чате с архитектурой Azure OpenAI. Хотя базовая архитектура использует управляемые удостоверения, назначаемые системой, и назначения назначаемых системой ролей, эта архитектура использует удостоверения, назначенные пользователем, с созданными вручную назначениями ролей.

Архитектура реализует периметр безопасности сети, а также периметр удостоверения, реализованный в базовой архитектуре. С точки зрения сети, единственное, что должно быть доступно из Интернета, — это пользовательский интерфейс чата через Шлюз приложений. С точки зрения идентификации пользовательский интерфейс чата должен проходить проверку подлинности и авторизовать запросы. Управляемые удостоверения используются, где это возможно, для проверки подлинности приложений в службах Azure.

Вместе с рекомендациями по работе с сетями в этом разделе описываются вопросы безопасности для смены ключей и точной настройки модели Azure OpenAI.

Управление удостоверениями и доступом

При использовании управляемых удостоверений, назначаемых пользователем, рассмотрите следующее руководство.

• Создайте отдельные управляемые удостоверения для следующих ресурсов Azure AI Foundry и Машинного обучения, где это применимо:
  • Azure AI Foundry Hub
  • Проекты Azure AI Foundry для разработки и управления потоками
  • Сетевые конечные точки в развернутом потоке, если поток развертывается в управляемой сетевой конечной точке
• Реализация элементов управления доступом к удостоверениям для пользовательского интерфейса чата с помощью идентификатора Microsoft Entra

Создайте отдельные проекты и сетевые конечные точки для различных потоков запросов, которые необходимо изолировать от других пользователей с точки зрения разрешений. Создайте отдельное управляемое удостоверение для каждого проекта и управляемой сетевой конечной точки. Предоставьте авторам запросов доступ только к нужным проектам.

При подключении пользователей к проектам Azure AI Foundry для выполнения таких функций, как потоки разработки, необходимо сделать назначения ролей с минимальными привилегиями, которыми они требуются.

Машинное обучение роли доступа на основе ролей

Как и в базовой архитектуре, система автоматически создает назначения ролей для управляемых удостоверений, назначенных системой. Так как система не знает, какие функции концентратора и проектов вы можете использовать, она создает назначения ролей, поддерживая все потенциальные функции. Автоматически созданные назначения ролей могут переназначить привилегии подготовки в зависимости от варианта использования. Например, роль "Участник", назначенная концентратору для реестра контейнеров, где для него, скорее всего, требуется доступ "Читатель" к плоскости управления. Если вам нужно дополнительно ограничить разрешения для целей наименьших привилегий, необходимо использовать удостоверения, назначенные пользователем. Вы создадите и сохраните эти назначения ролей самостоятельно.

Из-за нагрузки на обслуживание управления всеми необходимыми назначениями эта архитектура благоприящает эффективность работы по сравнению с абсолютными назначениями ролей с минимальными привилегиями. Обратите внимание, что необходимо сделать все назначения, перечисленные в таблице.

Управляемое удостоверение	Область	Назначения ролей
Управляемое удостоверение концентратора	Участник	Группа ресурсов
Управляемое удостоверение концентратора	Узел	Администратор ИИ Azure
Управляемое удостоверение концентратора	Реестр контейнеров	Участник
Управляемое удостоверение концентратора	Key Vault	Участник
Управляемое удостоверение концентратора	Key Vault	Администратор
Управляемое удостоверение концентратора	Учетная запись хранения	Читатель
Управляемое удостоверение концентратора	Учетная запись хранения	Участник учетных записей хранения
Управляемое удостоверение концентратора	Учетная запись хранения	Участник данных хранилища BLOB-объектов
Управляемое удостоверение концентратора	Учетная запись хранения	Привилегированный участник файловых данных хранилища
Управляемое удостоверение концентратора	Учетная запись хранения	Участник данных таблицы хранилища
Управляемое удостоверение проекта	Project	Администратор ИИ Azure
Управляемое удостоверение проекта	Реестр контейнеров	Участник
Управляемое удостоверение проекта	Key Vault	Участник
Управляемое удостоверение проекта	Key Vault	Администратор
Управляемое удостоверение проекта	Учетная запись хранения	Читатель
Управляемое удостоверение проекта	Учетная запись хранения	Участник учетных записей хранения
Управляемое удостоверение проекта	Учетная запись хранения	Участник данных хранилища BLOB-объектов
Управляемое удостоверение проекта	Учетная запись хранения	Привилегированный участник файловых данных хранилища
Управляемое удостоверение проекта	Учетная запись хранения	Участник данных таблицы хранилища
Управляемое удостоверение конечной точки в Сети	Project	секреты подключения к рабочей области Машинное обучение Azure
Управляемое удостоверение конечной точки в Сети	Project	Редактор метрик Azure ML
Управляемое удостоверение конечной точки в Сети	Реестр контейнеров	ACRPull
Управляемое удостоверение конечной точки в Сети	Azure OpenAI	Пользователь службы OpenAI в Cognitive Services
Управляемое удостоверение конечной точки в Сети	Учетная запись хранения	Участник данных хранилища BLOB-объектов
Управляемое удостоверение конечной точки в Сети	Учетная запись хранения	Читатель данных больших двоичных объектов хранилища
Служба приложений (при развертывании потока запроса в Служба приложений)	Azure OpenAI	Пользователь службы OpenAI в Cognitive Services
Пользователь портала (разработка потока запроса)	Azure OpenAI	Пользователь службы OpenAI в Cognitive Services
Пользователь портала (разработка потока запроса)	Учетная запись хранения	Участник данных BLOB-объектов хранилища (используйте условный доступ)
Пользователь портала (разработка потока запроса)	Учетная запись хранения	Привилегированный участник файловых данных хранилища

Важно понимать, что центр Azure AI Foundry имеет ресурсы Azure, которые совместно используются в проектах, таких как учетная запись хранения и реестр контейнеров. Если у вас есть пользователи, которым требуется доступ только к подмножествам проектов, рассмотрите возможность использования условий назначения ролей для служб Azure, которые поддерживают их, чтобы предоставить минимальный доступ к ресурсам. Например, большие двоичные объекты в служба хранилища Azure поддерживают условия назначения ролей. Для пользователя, требующего доступа к подмножествам проектов, вместо назначения разрешений на основе каждого контейнера используйте условия доступа к ролям, чтобы ограничить разрешения для контейнеров BLOB-объектов, используемых этими проектами. Каждый проект имеет уникальный GUID, который служит префиксом для имен контейнеров БОЛЬШИХ двоичных объектов, используемых в этом проекте. Этот GUID можно использовать в рамках условий назначения ролей.

Центр должен иметь Contributor доступ к группе ресурсов концентратора, чтобы разрешить ему создавать и управлять ресурсами концентратора и проекта. Побочный эффект этого концентратора имеет доступ к любому ресурсу в группе ресурсов. Все ресурсы Azure, не связанные с концентратором, и его проекты должны быть созданы в отдельной группе ресурсов. Рекомендуется создать как минимум две группы ресурсов для рабочей нагрузки с помощью самостоятельно управляемого центра Azure AI Foundry. Одна группа ресурсов для хранения концентратора, его проектов и всех его прямых зависимостей, таких как реестр контейнеров Azure, Key Vault и т. д. Одна группа ресурсов, содержащая все остальное в рабочей нагрузке.

Мы рекомендуем свести к минимуму использование ресурсов Azure, необходимых для работы центра (реестр контейнеров, учетная запись хранения, Key Vault, Application Insights) другими компонентами в рабочих нагрузках. Например, если необходимо хранить секреты в рамках рабочей нагрузки, необходимо создать отдельное хранилище ключей, отдельное от хранилища ключей, связанного с концентратором. Хранилище ключей концентратора должно использоваться только центром для хранения секретов концентратора и проекта.

Убедитесь, что для каждого отдельного проекта назначения ролей для зависимостей не предоставляют доступ к ресурсам пользователя портала и управляемого удостоверения конечной точки в Интернете. Например, Cognitive Services OpenAI User назначение ролей в Azure OpenAI предоставляет доступ ко всем развертываниям для этого ресурса. Нет способа ограничить авторов потоков или управляемых управляемых сетевых конечных удостоверений с доступом к определенным развертываниям моделей в Azure OpenAI. В таких сценариях мы рекомендуем развертывать такие службы, как Azure OpenAI и поиск Azure AI на основе каждого проекта, и не развертывать ресурсы в тех службах, к которым авторы потока или управляемые конечные точки в сети не должны иметь доступа. Например, развертывайте только модели в экземпляре Azure OpenAI проекта, к которому требуется доступ. Только развертывайте индексы в экземпляре службы "Поиск ИИ Azure", к которому должен иметь доступ проект.

Сеть

Наряду с доступом на основе удостоверений сетевая безопасность находится в основе базовой комплексной архитектуры чата, которая использует OpenAI. На высоком уровне сетевая архитектура гарантирует следующее:

• Только одна безопасная точка входа для трафика пользовательского интерфейса чата.
• Сетевой трафик фильтруется.
• Данные при передаче шифруются сквозным способом с помощью TLS.
• Утечка данных сводится к минимуму с помощью Приватный канал для поддержания трафика в Azure.
• Сетевые ресурсы логически группируются и изолированы друг от друга через сегментацию сети.

Сетевые потоки

Два потока на этой схеме рассматриваются в базовой архитектуре веб-приложения Служба приложений: поток входящего трафика от конечного пользователя к пользовательскому интерфейсу чата (1) и потоку из Служба приложений в службы Azure PaaS (2). В этом разделе основное внимание уделяется потоку Машинное обучение онлайн-конечной точки. Следующий поток переходит из пользовательского интерфейса чата, который выполняется в базовом веб-приложении Служба приложений в поток, развернутый для Машинное обучение вычислений:

1. Вызов из пользовательского интерфейса чата, размещенного в Служба приложений, направляется через частную конечную точку в Машинное обучение интернет-конечную точку.
2. Конечная точка в Сети направляет вызов серверу, на котором выполняется развернутый поток. Конечная точка в сети выступает как подсистемой балансировки нагрузки, так и маршрутизатором.
3. Вызовы служб Azure PaaS, необходимых развернутой потоку, направляются через управляемые частные конечные точки.

Входящий трафик для Машинное обучение

В этой архитектуре общедоступный доступ к рабочей области Машинное обучение отключен. Пользователи могут получить доступ к рабочей области через частный доступ, так как архитектура следует частной конечной точке для конфигурации Машинное обучение рабочей области. На самом деле частные конечные точки используются в этой архитектуре для дополнения безопасности на основе удостоверений. Например, пользовательский интерфейс чата с Служба приложений может подключаться к службам PaaS, которые не предоставляются в общедоступном Интернете, включая Машинное обучение конечные точки.

Для подключения к рабочей области Машинное обучение для разработки потоков также требуется доступ к частной конечной точке.

На схеме показана схема создания потока запроса, подключающегося через Бастион Azure к прямоугольнику перехода виртуальной машины. В этом поле перехода автор может подключиться к рабочей области Машинное обучение через частную конечную точку в той же сети, что и поле перехода. Подключение к виртуальной сети также можно выполнить через ExpressRoute или VPN-шлюзы и пиринг между виртуальными сетями.

Поток из управляемой виртуальной сети Azure AI Foundry в службы Azure PaaS

Рекомендуется настроить центр Azure AI Foundry для изоляции управляемых виртуальных сетей, которые требуют утверждения всех исходящих подключений. Эта архитектура следует этой рекомендации. Существует два типа утвержденных правил исходящего трафика. Необходимые правила исходящего трафика — это ресурсы, необходимые для работы решения, например реестра контейнеров и хранилища. Определяемые пользователем правила исходящего трафика предназначены для пользовательских ресурсов, таких как Azure OpenAI или поиск ИИ, которые будет использоваться в рабочем процессе. Необходимо настроить определяемые пользователем правила исходящего трафика. Необходимые правила исходящего трафика настраиваются при создании управляемой виртуальной сети. Управляемая виртуальная сеть развертывается по запросу при первом использовании и сохраняется после этого.

Правила исходящего трафика могут быть частными конечными точками, тегами служб или полными доменными именами (FQDN) для внешних общедоступных конечных точек. В этой архитектуре подключение к службам Azure, таким как Реестр контейнеров, хранилище, Azure Key Vault, Azure OpenAI и поиск ИИ, подключены через приватный канал. Хотя и не в этой архитектуре, некоторые распространенные операции, которые могут потребовать настройки правила исходящего доменного имени, скачивают пакет pip, клонируют репозиторий GitHub или загружают базовые образы контейнеров из внешних репозиториев.

Управление исходящим полным доменным именем реализуется брандмауэром Microsoft Managed Azure, развернутым в управляемой сети Azure AI Foundry. Выберите ценовую категорию "Базовый", если необходимо управлять трафиком http (порт 80) или HTTPS (порт 443). Если для исходящего трафика требуются пользовательские протоколы или порты, выберите ценовую категорию "Стандартный". В этой архитектуре используется ценовая категория "Базовый", так как единственный исходящий трафик — это конечные точки HTTPS через порт 443.

Сегментация виртуальной сети и безопасность

Сеть в этой архитектуре имеет отдельные подсети для следующих целей:

• Шлюз приложений
• компоненты интеграции Служба приложений
• Частные конечные точки
• Бастион Azure
• Виртуальная машина с полем перехода
• Подсети обучения и оценки — оба из них предназначены для привлечения собственных вычислений, связанных с обучением и выводом. В этой архитектуре мы не работаем на обучении и используем управляемые вычисления.
• Очки

Каждая подсеть имеет группу безопасности сети (NSG), которая ограничивает исходящий и исходящий трафик для этих подсетей только тем, что требуется. В следующей таблице показано упрощенное представление правил NSG, которые базовые показатели добавляются в каждую подсеть. Таблица предоставляет имя и функцию правила.

Подсеть	Входящий трафик	Исходящие
snet-appGateway	Пособия для исходных IP-адресов пользователей пользовательского интерфейса чата (например, общедоступный Интернет), а также необходимые элементы для службы.	Доступ к частной конечной точке Служба приложений плюс необходимые элементы для службы.
snet-PrivateEndpoints	Разрешить только трафик из виртуальной сети.	Разрешить только трафик в виртуальную сеть.
snet-AppService	Разрешить только трафик из виртуальной сети.	Разрешить доступ к частным конечным точкам и Azure Monitor.
AzureBastionSubnet	Ознакомьтесь с рекомендациями по работе с доступом NSG и Бастионом Azure.	Ознакомьтесь с рекомендациями по работе с доступом NSG и Бастионом Azure.
snet-jumpbox	Разрешить входящий протокол удаленного рабочего стола (RDP) и SSH из подсети узла Бастиона Azure.	Разрешить доступ к частным конечным точкам
агенты snet-agent	Разрешить только трафик из виртуальной сети.	Разрешить только трафик в виртуальную сеть.
snet-training	Разрешить только трафик из виртуальной сети.	Разрешить только трафик в виртуальную сеть.
snet-scoring	Разрешить только трафик из виртуальной сети.	Разрешить только трафик в виртуальную сеть.

Весь остальной трафик явно отрицается.

При реализации сегментации и безопасности виртуальной сети следует учитывать следующие моменты.

• Включите защиту от атак DDoS для виртуальной сети с подсетью, которая входит в шлюз приложений с общедоступным IP-адресом.

• Добавьте группу безопасности сети в каждую подсеть, где это возможно. Используйте самые строгие правила, которые обеспечивают полную функциональность решения.

• Используйте группы безопасности приложений для группировки групп безопасности сети. Группирование групп позволяет упростить создание правил для сложных сред.

Смена ключей

В этой архитектуре есть одна служба, использующая проверку подлинности на основе ключей: Машинное обучение управляемую конечную точку в Сети. Так как для этой службы используется проверка подлинности на основе ключей, важно:

• Сохраните ключ в безопасном хранилище, например Key Vault, для доступа по запросу от авторизованных клиентов, таких как веб-приложение Azure, в котором размещен контейнер потока запроса.

• Реализуйте стратегию смены ключей. Если вы вручную поворачиваете ключи, создайте политику истечения срока действия ключа и используйте Политика Azure для отслеживания того, был ли ключ поворачивался.

Точное настройка модели OpenAI

Если вы точно настраиваете модели OpenAI в реализации, рассмотрите следующее руководство.

• Если вы отправляете обучающие данные для точной настройки, рассмотрите возможность использования ключей , управляемых клиентом, для шифрования данных.

• Если вы храните обучающие данные в хранилище, например Хранилище BLOB-объектов Azure, рассмотрите возможность использования управляемого клиентом ключа для шифрования данных, управляемого удостоверения для управления доступом к данным и частной конечной точкой для подключения к данным.

Управление с помощью политики

Чтобы обеспечить соответствие безопасности, рекомендуется использовать Политика Azure и политику сети, чтобы развертывания соответствовали требованиям рабочей нагрузки. Использование автоматизации платформы с помощью политики снижает нагрузку на этапы проверки вручную и гарантирует управление, даже если конвейеры обходятся. Рассмотрим следующие политики безопасности:

• Отключите ключ или другой локальный доступ к проверке подлинности в службах, таких как службы ИИ Azure и Key Vault.
• Требуется определенная конфигурация правил доступа к сети или групп безопасности сети.
• Требовать шифрование, например использование ключей, управляемых клиентом.

Назначения ролей Azure AI Foundry для Azure Key Vault

Управляемое удостоверение Azure AI Foundry требует назначения ролей уровня управления (участника) и плоскости данных (администратор Key Vault). Это означает, что это удостоверение имеет доступ на чтение и запись ко всем секретам, ключам и сертификатам, хранящимся в хранилище ключей Azure. Если у рабочей нагрузки есть службы, отличные от Azure AI Foundry, для которых требуется доступ к секретам, ключам или сертификатам в Key Vault, ваша рабочая нагрузка или команда безопасности могут не быть комфортно с управляемым удостоверением Центра Azure AI Foundry, имеющим доступ к этим артефактам. В этом случае рассмотрите возможность развертывания экземпляра Key Vault специально для центра Azure AI Foundry и других экземпляров Azure Key Vault в соответствии с другими частями рабочей нагрузки.

Оптимизация затрат

Оптимизация затрат заключается в том, чтобы подумать о способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см . в контрольном списке проверки конструктора для оптимизации затрат.

Чтобы просмотреть пример ценообразования для этого сценария, используйте калькулятор цен Azure. Необходимо настроить пример для сопоставления использования, так как этот пример включает только компоненты, включенные в архитектуру. Наиболее дорогими компонентами в сценарии являются защита от атак DDoS и брандмауэр, развернутый в рамках управляемой сетевой конечной точки. Другие важные затраты — это пользовательский интерфейс чата и вычисление потоков запросов и поиск ИИ. Оптимизируйте эти ресурсы, чтобы сэкономить большую стоимость.

Службы вычислений

Поток запросов поддерживает несколько вариантов размещения исполняемых потоков. Эти параметры включают управляемые конечные точки в сети в Машинное обучение, AKS, Служба приложений и Служба Azure Kubernetes. Каждый из этих вариантов имеет собственную модель выставления счетов. Выбор вычислений влияет на общую стоимость решения.

Azure OpenAI

Azure OpenAI — это служба на основе потребления, и как и любая служба на основе потребления, контроль спроса на поставку является основным элементом управления затратами. Для этого в Azure OpenAI необходимо использовать сочетание подходов:

• Управление клиентами. Клиентские запросы являются основным источником затрат в модели потребления, поэтому управление поведением клиента является критически важным. Все клиенты должны:

  • Будьте утверждены. Избегайте предоставления службы таким образом, чтобы поддерживать бесплатный доступ для всех. Ограничить доступ как через сетевые, так и элементы управления удостоверениями, такие как ключи или управление доступом на основе ролей (RBAC).

  • Будьте самоуправляемы. Требовать от клиентов использовать ограничения, ограничивающие маркеры, предлагаемые вызовами API, например max_tokens и max_completions.

  • Используйте пакетную обработку, где практическая. Проверьте клиенты, чтобы убедиться, что они правильно пакетируют запросы.

  • Оптимизируйте входные данные запроса и длину ответа. Более длинные запросы потребляют больше маркеров, повышая затраты, но запросы, которые отсутствуют достаточный контекст, не помогают моделям получить хорошие результаты. Создайте краткие запросы, которые предоставляют достаточно контекста, чтобы позволить модели создавать полезный ответ. Аналогичным образом убедитесь, что вы оптимизируете предел длины отклика.

• Использование игровой площадки Azure OpenAI должно быть необходимо и в экземплярах предварительной подготовки, чтобы эти действия не влечет за собой производственные затраты.

• Выберите нужную модель ИИ. Выбор модели также играет большую роль в общей стоимости Azure OpenAI. Все модели имеют сильные и слабые стороны и по отдельности ценятся. Используйте правильную модель для варианта использования, чтобы убедиться, что вы не перераспределаете модель более дорогой, если менее дорогой модель дает приемлемые результаты. В этой реализации справочника по чату GPT 3.5-turbo был выбран по сравнению с GPT-4, чтобы сэкономить на уровне затрат на развертывание модели при достижении достаточных результатов.

• Общие сведения о точках останова выставления счетов. Штрафная настройка взимается в час. Чтобы быть наиболее эффективным, вы хотите использовать столько времени, сколько времени доступно в час, чтобы улучшить результаты тонкой настройки, избегая просто проскользнуть в следующий период выставления счетов. Аналогичным образом, стоимость 100 изображений из создания изображений совпадает с стоимостью для одного изображения. Максимальное увеличение цен на точки останова для вашего преимущества.

• Общие сведения о моделях выставления счетов. Azure OpenAI также доступен в модели выставления счетов на основе обязательств с помощью подготовленной пропускной способности . После того как у вас есть прогнозируемые шаблоны использования, рассмотрите возможность переключения на эту модель выставления счетов предварительной оплаты, если она является более экономичной на томе использования.

• Задайте ограничения подготовки. Убедитесь, что все квоты подготовки выделены только для моделей, которые, как ожидается, будут частью рабочей нагрузки на основе каждой модели. Пропускная способность для уже развернутых моделей не ограничивается этой подготовленной квотой, пока включена динамическая квота. Квота не сопоставляет затраты напрямую и может отличаться.

• Отслеживайте использование по мере использования. Если вы используете цены на оплату по мере использования, следите за использованием TPM и RPM. Используйте эти сведения для информирования об архитектурных решениях проектирования, таких как то, какие модели следует использовать, и оптимизировать размеры запросов.

• Отслеживайте использование подготовленной пропускной способности. Если вы используете подготовленную пропускную способность, отслеживайте использование, управляемое подготовкой, чтобы убедиться, что вы не используете подготовленную пропускную способность, которую вы приобрели.

• Управление затратами. Следуйте инструкциям по использованию функций управления затратами с OpenAI для мониторинга затрат, настройки бюджета для управления затратами и создания оповещений заинтересованных лиц о рисках или аномалиях.

Операционное превосходство

Операционное превосходство охватывает процессы, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см . в контрольном списке проверки конструктора для повышения эффективности работы.

Встроенные среды выполнения потока запросов

Как и в базовой архитектуре, эта архитектура использует автоматическую среду выполнения для минимизации рабочей нагрузки. Автоматическая среда выполнения — это бессерверный параметр вычислений в Машинное обучение, который упрощает управление вычислениями и делегирует большую часть конфигурации потока запроса в файл и requirements.txt конфигурацию запущенного flow.dag.yaml приложения. Это делает этот выбор низким обслуживанием, временным и управляемым приложением. Использование среды выполнения вычислительных экземпляров или внешних вычислений, таких как в этой архитектуре, требует больше управляемого командой жизненного цикла вычислений и должно быть выбрано, если требования к рабочей нагрузке превышают возможности конфигурации параметра автоматической среды выполнения.

Наблюдение

Как и в базовой архитектуре, диагностика настроены для всех служб. Все службы, но Служба приложений настроены для записи всех журналов. Служба приложений настроено для записи AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs и AppServicePlatformLogs. В рабочей среде все журналы, вероятно, чрезмерны. Настройте потоки журналов в соответствии с вашими потребностями в работе. Для этой архитектуры журналы Машинного обучения Azure, используемые проектом Azure AI Foundry, относятся: AmlComputeClusterEvent, AmlDataSetEvent, AmlEnvironmentEvent и AmlModelsEvent.

Оцените создание пользовательских оповещений для ресурсов в этой архитектуре, таких как те, которые находятся в базовых оповещениях Azure Monitor. Например:

• Оповещения реестра контейнеров
• оповещения Машинное обучение и Azure OpenAI
• Оповещения azure веб-приложения

Не забудьте отслеживать использование маркеров в развертываниях модели Azure OpenAI. В этой архитектуре поток запроса отслеживает использование маркеров через интеграцию с приложение Azure Insights.

Операции языковой модели

Развертывание решений чата на основе OpenAI в Azure, таких как эта архитектура, должно соответствовать инструкциям в GenAIOps с потоком запросов с помощью Azure DevOps и GitHub. Кроме того, необходимо рассмотреть рекомендации по непрерывной интеграции и непрерывной доставке (CI/CD) и архитектуре, защищенной сетью. В следующем руководстве рассматривается реализация потоков и связанной с ними инфраструктуры на основе рекомендаций GenAIOps. Это руководство по развертыванию не включает интерфейсные элементы приложения, которые не изменяются в архитектуре веб-приложения с высоким уровнем доступности.

Разработка

Поток запросов предлагает интерфейс разработки на основе браузера на портале Azure AI Foundry или расширения Visual Studio Code. Оба параметра хранят код потока в виде файлов. При использовании портала Azure AI Foundry файлы хранятся в учетной записи хранения. При работе в Microsoft Visual Studio Code файлы хранятся в локальной файловой системе.

Чтобы следовать рекомендациям по совместной разработке, исходные файлы должны поддерживаться в репозитории исходного кода в Интернете, например GitHub. Этот подход упрощает отслеживание всех изменений кода, совместную работу между авторами потоков и интеграцию с потоками развертывания, которые тестируют и проверяют все изменения кода.

Для корпоративной разработки используйте расширение Microsoft Visual Studio Code и пакет SDK потока запросов или CLI для разработки. Авторы потока запросов могут создавать и тестировать потоки из Microsoft Visual Studio Code и интегрировать локальные сохраненные файлы с системой управления версиями и конвейерами. Хотя интерфейс на основе браузера хорошо подходит для изучения разработки, с некоторыми работами, он может быть интегрирован с системой управления версиями. Папку потока можно скачать с страницы потока на Files панели, распакуировать и отправить в систему управления версиями.

Оценка

Проверьте потоки, используемые в приложении чата, так же, как и тестировать другие артефакты программного обеспечения. Сложно указать и подтвердить один "правильный" ответ для выходных данных языковой модели, но вы можете использовать саму языковую модель для оценки ответов. Рассмотрите возможность реализации следующих автоматизированных вычислений потоков языковой модели:

• Точность классификации. Определяет, дает ли языковая модель оценку "правильный" или "неправильный" и агрегирует результаты для получения оценки точности.

• Согласованность: оценивает, насколько хорошо предложения в прогнозируемом ответе модели написаны и как они последовательно связываются друг с другом.

• Fluency: оценивает прогнозируемый ответ модели для его грамматической и лингвистической точности.

• Обоснование контекста: оценивает, насколько хорошо прогнозируемые ответы модели основаны на предварительно настроенном контексте. Даже если ответы языковой модели верны, если они не могут быть проверены в заданном контексте, такие ответы не создаются.

• Релевантность: оценивает, насколько хорошо прогнозируемые ответы модели соответствуют заданным вопросам.

При реализации автоматизированных вычислений рассмотрите следующее руководство.

• Создайте оценки из оценки и измеряйте их с помощью предопределенного порогового значения успешности. Используйте эти оценки, чтобы сообщить о прохождении или сбое теста в конвейерах.

• Для некоторых из этих тестов требуются предварительно настроенные входные данные вопросов, контекста и правды.

• Включите достаточно пар ответов на вопросы, чтобы убедиться, что результаты тестов надежны, при этом рекомендуется по крайней мере 100-150 пар. Эти пары ответов на вопросы называются "золотым набором данных". В зависимости от размера и домена набора данных может потребоваться большее число.

• Избегайте использования языковых моделей для создания любых данных в золотом наборе данных.

Поток развертывания

1. Инженер запроса или специалист по обработке и анализу данных открывает ветвь компонента, где они работают над конкретной задачей или функцией. Специалист по обработке запросов и специалист по обработке и анализу данных выполняет итерацию потока запросов для Microsoft Visual Studio Code, периодически фиксирует изменения и отправляет эти изменения в ветвь компонента.

2. После завершения локальной разработки и экспериментирования специалист по запросу или специалист по обработке и анализу данных открывает запрос на вытягивание из ветви компонента в главную ветвь. Запрос на вытягивание (PR) активирует конвейер PR. Этот конвейер выполняет быстрые проверки качества, которые должны включать:

   • Выполнение потоков экспериментирования.
   • Выполнение настроенных модульных тестов.
   • Компиляция базы кода.
   • Анализ статического кода.

3. Конвейер может содержать шаг, который требует по крайней мере одного участника команды вручную утвердить PR перед слиянием. Утверждающий не может быть фиксацией, и у них есть опыт потока запроса и знакомство с требованиями проекта. Если pr не утвержден, слияние блокируется. Если pr утвержден, или нет шага утверждения, ветвь компонента объединяется в главную ветвь.

4. Слияние с Main активирует процесс сборки и выпуска среды разработки. В частности:

   a. Конвейер CI активируется из слияния в Main. Конвейер CI выполняет все действия, выполненные в конвейере PR, и следующие действия.

   • Поток экспериментов
   • поток оценки.
   • Регистрирует потоки в реестре Машинное обучение при обнаружении изменений

   b. Конвейер CD активируется после завершения конвейера CI. Этот поток выполняет следующие действия:

   • Развертывает поток из реестра Машинное обучение в Машинное обучение конечную точку в сети
   • Выполняет тесты интеграции, предназначенные для конечной точки в Сети
   • Выполняет тесты дыма, предназначенные для конечной точки в Сети

5. Процесс утверждения встроен в процесс продвижения выпуска — после утверждения процессы CI & CD, описанные в шагах 4.a и 4.b повторяются, предназначенные для тестовой среды. Шаги и b одинаковы, за исключением того, что тесты приемки пользователей выполняются после тестов дыма в тестовой среде.

6. Процессы CI & CD, описанные в шагах 4.a и 4.b запускаются для повышения выпуска в рабочую среду после проверки и утверждения тестовой среды.

7. После выпуска в динамической среде выполняются операционные задачи мониторинга метрик производительности и оценки развернутых языковых моделей. Это включает в себя, но не ограничивается:

   • Обнаружение смещения данных
   • Наблюдение за инфраструктурой
   • Управление затратами
   • Взаимодействие производительности модели с заинтересованными лицами

Руководства по развертыванию

Вы можете использовать Машинное обучение конечных точек для развертывания моделей таким образом, чтобы обеспечить гибкость при выпуске в рабочую среду. Рассмотрите следующие стратегии, чтобы обеспечить оптимальную производительность и качество модели:

• Синие и зеленые развертывания. С помощью этой стратегии вы можете безопасно развернуть новую версию веб-службы в ограниченной группе пользователей или запросов, прежде чем направлять весь трафик к новому развертыванию.

• Тестирование A/B: не только сине-зеленые развертывания эффективны для безопасного развертывания изменений, их также можно использовать для развертывания нового поведения, позволяющего подмножество пользователей оценить влияние изменения.

• Включите подстраивание файлов Python, которые являются частью потока запроса в конвейерах. Linting проверяет соответствие стандартам стиля, ошибкам, сложности кода, неиспользуемого импорта и именования переменных.

• При развертывании потока в изолированной от сети рабочей области Машинное обучение используйте локальный агент для развертывания артефактов в ресурсах Azure.

• Реестр моделей Машинное обучение следует обновлять только при изменении модели.

• Языковые модели, потоки и пользовательский интерфейс клиента должны быть слабо связаны. Обновления потоков и пользовательского интерфейса клиента могут и должны быть в состоянии выполняться без влияния на модель и наоборот.

• При разработке и развертывании нескольких потоков каждый поток должен иметь собственный жизненный цикл, который позволяет свободно сочетать потоки из экспериментов в рабочую среду.

Инфраструктура

При развертывании базовых компонентов чата Azure OpenAI некоторые из подготовленных служб являются базовыми и постоянными в архитектуре, в то время как другие компоненты являются более временными в природе, их существование связано с развертыванием. Кроме того, в то время как управляемая виртуальная сеть является базовой, она автоматически подготавливается при создании вычислительного экземпляра, который приводит к некоторым соображениям.

Базовые компоненты

Некоторые компоненты в этой архитектуре существуют с жизненным циклом, который выходит за рамки любого отдельного потока запроса или любого развертывания модели. Эти ресурсы обычно развертываются как часть базового развертывания командой рабочей нагрузки и поддерживаются отдельно от новых, удаленных или обновлений потоков запросов или развертываний моделей.

• Рабочая область машинного обучения
• Учетная запись хранения для рабочей области Машинное обучение
• Реестр контейнеров
• Поиск ИИ
• Azure OpenAI
• Azure Application Insights
• Бастион Azure
• Виртуальная машина Azure для поля перехода

Временные компоненты

Некоторые ресурсы Azure тесно связаны с структурой конкретных потоков запросов. Такой подход позволяет связать эти ресурсы с жизненным циклом компонента и стать временным в этой архитектуре. Ресурсы Azure влияют на развитие рабочей нагрузки, например при добавлении или удалении потоков или при появлении новых моделей. Эти ресурсы создаются повторно и удаляются предыдущие экземпляры. Некоторые из этих ресурсов являются прямыми ресурсами Azure, и некоторые из них являются проявлениями плоскости данных в их автономной службе.

• Модель в реестре моделей Машинное обучение должна обновляться при изменении в рамках конвейера CD.

• Образ контейнера должен быть обновлен в реестре контейнеров в рамках конвейера CD.

• Конечная точка Машинное обучение создается при развертывании потока запроса, если развертывание ссылается на конечную точку, которая не существует. Эта конечная точка должна быть обновлена, чтобы отключить общедоступный доступ.

• Развертывания конечной точки Машинное обучение обновляются при развертывании или удалении потока.

• Хранилище ключей для пользовательского интерфейса клиента должно быть обновлено с ключом к конечной точке при создании новой конечной точки.

Управляемая виртуальная сеть по запросу

Управляемая виртуальная сеть автоматически подготавливается при первом создании вычислительного экземпляра. Если вы используете инфраструктуру в качестве кода для развертывания концентратора, и у вас нет вычислительных ресурсов Azure AI Foundry в Bicep, управляемая виртуальная сеть не развернута, и при подключении к порталу Azure AI Foundry возникает ошибка. Необходимо выполнить однократное действие, чтобы вручную подготовить управляемую виртуальную сеть после развертывания IaC.

Организация ресурсов

Если у вас есть сценарий, в котором центральный центр принадлежит группе, отличной от команды рабочей нагрузки, можно развернуть проекты в отдельных группах ресурсов. Если вы используете инфраструктуру в качестве кода, это можно сделать, задав другую группу ресурсов в Bicep. Если вы используете портал, вы можете задать defaultWorkspaceResourceGroup свойство в workspaceHubConfig группе ресурсов, которую вы хотите создать.

Эффективность производительности

Эффективность производительности — это возможность вашей рабочей нагрузки отвечать требованиям, заданным пользователями. Дополнительные сведения см . в контрольном списке проверки конструктора для повышения эффективности.

В этом разделе описывается эффективность производительности с точки зрения поиска Azure, Azure OpenAI и Машинное обучение.

Поиск Azure — эффективность производительности

Следуйте инструкциям по анализу производительности в поиске ИИ.

Azure OpenAI — эффективность производительности

• Определите, требуется ли ваше приложение подготовленной пропускной способности или общего размещения или модели. Подготовленная пропускная способность обеспечивает зарезервированную емкость обработки для развертываний модели OpenAI, которая обеспечивает прогнозируемую производительность и пропускную способность для моделей. Эта модель выставления счетов отличается от общего размещения или потребления модели. Модель потребления лучше всего усилий и может быть подвержена шумному соседу или другим стрессорам на платформе.

• Отслеживайте использование, управляемое подготовкой, для подготовленной пропускной способности.

Машинное обучение — эффективность производительности

При развертывании в Машинное обучение сетевых конечных точек:

• Следуйте инструкциям по автомасштабированию сетевой конечной точки. Это делается для того, чтобы оставаться в тесном соответствии с спросом без чрезмерного перепроверения, особенно в периоды низкого использования.

• Выберите соответствующий номер SKU виртуальной машины для сетевой конечной точки, чтобы удовлетворить целевые показатели производительности. Проверьте производительность как более низкого числа экземпляров, так и более крупных номеров SKU и более крупных экземпляров, чтобы найти оптимальную конфигурацию.

Развертывание этого сценария

Чтобы развернуть и запустить эталонную реализацию, выполните действия, описанные в реализации эталонной базы OpenAI.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

• Роб Багби | Шаблоны и практики — Корпорация Майкрософт
• Фредди Айала | Архитектор облачных решений — Корпорация Майкрософт
• Prabal Deb | Старший инженер по программному обеспечению — Корпорация Майкрософт
• Рауф Алиуат | Инженер программного обеспечения II — Корпорация Майкрософт
• Ritesh Modi | Главный инженер по программному обеспечению — Корпорация Майкрософт
• Райан Пфальц | Старший архитектор решений — Корпорация Майкрософт

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующий шаг

Связанные ресурсы

• Перспектива Well-Architected Платформы для рабочих нагрузок ИИ в Azure
• Azure OpenAI
• Языковые модели Azure OpenAI
• поток запроса на портале Azure AI Foundry
• Изоляция управляемой виртуальной сети рабочей области
• Настройка частной конечной точки для рабочей области Машинное обучение
• Фильтрование содержимого