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

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

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

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

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

Архитектура

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

Компоненты

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

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

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

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

• Хранилище используется для сохранения исходных файлов потока запроса для разработки потока запроса.

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

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

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

поток запроса Машинное обучение

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

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

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

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

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

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

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

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

Сеть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Шлюз приложений
• компоненты интеграции Служба приложений
• Частные конечные точки
• Бастион 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-адресом.

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

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

Мониторинг фильтрации содержимого и злоупотреблений

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

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

Надежность

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

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

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

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

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

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

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

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

2. Эта точка показывает, что контейнерные исполняемые потоки отправляются в реестр контейнеров. На схеме не показаны конвейеры, которые контейнеризируют потоки и отправляются в реестр контейнеров.

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

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

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

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

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

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

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

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

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

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

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

Машинное обучение — надежность

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

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

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

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

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

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

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

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

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

Следующее руководство расширяет руководство по управлению удостоверениями и доступом в базовом Служба приложений.

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

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

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

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

Управляемое удостоверение	Область	Назначения ролей
Управляемое удостоверение рабочей области	Группа ресурсов	Участник
Управляемое удостоверение рабочей области	Учетная запись хранения рабочей области	Участник данных хранилища BLOB-объектов
Управляемое удостоверение рабочей области	Учетная запись хранения рабочей области	Привилегированный участник файловых данных хранилища
Управляемое удостоверение рабочей области	Хранилище ключей рабочей области	Администратор хранилища ключей
Управляемое удостоверение рабочей области	Реестр контейнеров рабочей области	AcrPush
Управляемое удостоверение конечной точки в Сети	Реестр контейнеров рабочей области	AcrPull
Управляемое удостоверение конечной точки в Сети	Учетная запись хранения рабочей области	Читатель данных больших двоичных объектов хранилища
Управляемое удостоверение конечной точки в Сети	Рабочая область машинного обучения	Средство чтения секретов подключения к рабочей области AzureML
Управляемое удостоверение вычислительного экземпляра	Реестр контейнеров рабочей области	AcrPull
Управляемое удостоверение вычислительного экземпляра	Учетная запись хранения рабочей области	Читатель данных больших двоичных объектов хранилища

Смена ключей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Машинное обучение поток запросов поддерживает несколько вариантов размещения исполняемых потоков. Эти параметры включают управляемые конечные точки в сети в Машинное обучение, 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 для мониторинга затрат, настройки бюджета для управления затратами и создания оповещений заинтересованных лиц о рисках или аномалиях.

Эффективность работы

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

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

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

Наблюдение

Диагностика настроена для всех служб. Все службы, но Машинное обучение и Служба приложений настроены для записи всех журналов. Машинное обучение диагностика настроены для записи журналов аудита, которые являются всеми журналами ресурсов, которые записывают взаимодействие клиента с данными или параметрами службы. Служба приложений настроено для записи AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs и AppServicePlatformLogs.

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

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

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

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

Разработка

Машинное обучение поток запроса предлагает как интерфейс разработки на основе браузера в студии Машинное обучение, так и с помощью расширения Visual Studio Code. Оба параметра хранят код потока в виде файлов. При использовании Машинное обучение студии файлы хранятся в учетной записи хранения. При работе в 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 активирует процесс сборки и выпуска среды разработки. В частности:

   1. Конвейер CI активируется из слияния в Main. Конвейер CI выполняет все действия, выполненные в конвейере PR, и следующие действия.
   • Поток экспериментов
   • поток оценки.
   • Регистрирует потоки в реестре Машинное обучение при обнаружении изменений
   1. Конвейер CD активируется после завершения конвейера CI. Этот поток выполняет следующие действия:
   • Развертывает поток из реестра Машинное обучение в Машинное обучение конечную точку в сети
   • Выполняет тесты интеграции, предназначенные для конечной точки в Сети
   • Выполняет тесты дыма, предназначенные для конечной точки в Сети

5. Процесс утверждения встроен в процесс продвижения выпуска — после утверждения процессы CI и CD, описанные в шагах 4.a. и 4.b. повторяются, предназначенные для тестовой среды. Шаги a. и 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, Azure OpenAI и Машинное обучение.

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

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

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

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

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

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

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

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

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

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

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

Соавторы

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

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

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

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

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

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