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

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

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

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

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

Архитектура

Рис. 1. Базовая сквозная архитектура чата с помощью OpenAI

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

Компоненты

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

• Машинное обучение Azure — это управляемая облачная служба, которая используется для обучения, развертывания и управления моделями машинного обучения. В этой архитектуре используется несколько других функций Машинное обучение Azure, используемых для разработки и развертывания исполняемых потоков для приложений искусственного интеллекта на основе крупных языковых моделей:
  • Машинное обучение Azure поток запросов — это средство разработки, позволяющее создавать, оценивать и развертывать потоки, которые связывают запросы пользователей, действия с помощью кода Python и вызовы LLM. Поток запроса используется в этой архитектуре в качестве слоя, который управляет потоками между запросом, различными хранилищами данных и LLM.
  • Управляемые сетевые конечные точки позволяют развертывать поток вывода в режиме реального времени. В этой архитектуре они используются в качестве конечной точки PaaS для пользовательского интерфейса чата для вызова потоков запросов, размещенных Машинное обучение Azure.
• служба хранилища Azure используется для сохранения исходных файлов потока запроса для разработки потока запроса.
• Реестр контейнеров Azure позволяет создавать, хранить и управлять образами контейнеров и артефактами в частном реестре для всех типов развертываний контейнеров. В этой архитектуре потоки упаковываются в виде образов контейнеров и хранятся в Реестр контейнеров Azure.
• Azure OpenAI — это полностью управляемая служба, которая обеспечивает доступ REST API к большим языковым моделям Azure OpenAI , включая GPT-4, GPT-3.5-Turbo и набор моделей внедрения. В этой архитектуре, помимо доступа к модели, она используется для добавления общих корпоративных функций, таких как виртуальная сеть и приватный канал, поддержка управляемых удостоверений и фильтрация содержимого.
• Поиск ИИ Azure — это облачная служба поиска, которая поддерживает полнотекстовый поиск, семантический поиск, векторный поиск и гибридный поиск. Поиск ИИ Azure включен в архитектуру, так как это общая служба, используемая в потоках за приложениями чата. Поиск ИИ Azure можно использовать для получения и индексирования данных, которые относятся к запросам пользователей. Поток запросов реализует RAG pattern Retrieval Дополненное поколение для извлечения соответствующего запроса из запроса, поиска ИИ и использования результатов в качестве данных приземления для модели Azure OpenAI.

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

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

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

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

Сеть

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

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

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

Рис. 2. Сетевые потоки для базовой комплексной архитектуры чата с помощью OpenAI

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

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

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

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

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

Рис. 3. Сетевые потоки для автора потока запроса Машинное обучение Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Надежность

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

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

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

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

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

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

Рис. 4. Альтернативная сквозная архитектура чата с помощью OpenAI развертывания потоков запросов в приложение Azure Services

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

1. Потоки по-прежнему создаются в потоке запросов Машинное обучение Azure, а архитектура сети Машинное обучение Azure не изменяется. Авторы потоков по-прежнему подключаются к интерфейсу разработки рабочей области через частную конечную точку и управляемые частные конечные точки используются для подключения к службам Azure при тестировании потоков.
2. Эта точка показывает, что контейнерные исполняемые потоки отправляются в Реестр контейнеров Azure (ACR). На схеме не показаны конвейеры, которые контейнеризируют потоки и отправляются в ACR.
3. В другом веб-приложении, развернутом в том же плане Служба приложений, который уже размещает пользовательский интерфейс чата. Новое веб-приложение размещает контейнеризованный поток запросов, совместно размещенный в том же плане Служба приложений, который уже выполняется не менее трех экземпляров, распределяется по зонам доступности. Эти Служба приложений экземпляры подключаются к ACR через частную конечную точку при загрузке образа контейнера потока запроса.
4. Контейнер потока запроса должен подключаться ко всем зависимым службам для выполнения потока. В этой архитектуре будет использоваться служба поиска ИИ Azure и Azure OpenAI. Службы PaaS, предоставляемые только подсети управляемой частной конечной точки AML, теперь также должны быть предоставлены в виртуальной сети, чтобы можно было установить линию видимости из Служба приложений.

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

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

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

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

Поиск по искусственному интеллекту Azure — надежность

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

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

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

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

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

• Следуйте указаниям по автомасштабированию ваших сетевых конечных точек, чтобы обеспечить доступность достаточной емкости для удовлетворения спроса. Если сигналы об использовании не являются достаточно своевременными из-за ускорения использования, рассмотрите возможность чрезмерной подготовки, чтобы предотвратить влияние на надежность от слишком мало доступных экземпляров.
• Рекомендуется создавать правила масштабирования на основе метрик развертывания, таких как загрузка ЦП и метрики конечных точек, такие как задержка запросов.
• Для активного рабочего развертывания необходимо развернуть не менее трех экземпляров.
• Избегайте развертываний для экземпляров, используемых в использовании. Вместо этого развернитесь в новом развертывании и переместите трафик после готовности развертывания к получению трафика.

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

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

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

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

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

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

роли RBAC Машинное обучение Azure

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

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

Смена ключей

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

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

Настройка модели OpenAI

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

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

Оптимизация производительности

Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности производительности".

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure OpenAI

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

• Управление клиентами. Клиентские запросы являются основным источником затрат в модели потребления, так как такое управление поведением клиента является критически важным. Все клиенты должны:
  • Будьте утверждены. Избегайте предоставления службы таким образом, чтобы поддерживать бесплатный доступ для всех. Ограничить доступ как через сетевые, так и элементы управления удостоверениями (ключ или RBAC).
  • Будьте самоуправляемы. Требовать от клиентов использовать ограничения, ограничивающие маркеры, предлагаемые вызовами API, например max_tokens и max_completions.
  • Используйте пакетную обработку, где практическая. Проверьте клиенты, чтобы убедиться, что они правильно пакетируют запросы.
  • Оптимизируйте входные данные запроса и длину ответа. Более длинные запросы потребляют больше маркеров, повышая затраты, но запросы, которые отсутствуют достаточный контекст, не помогают моделям получить хорошие результаты. Создайте краткие запросы, которые предоставляют достаточно контекста, чтобы позволить модели создавать полезный ответ. Аналогичным образом убедитесь, что вы оптимизируете предел длины отклика.
• Использование детской площадки Azure OpenAI должно быть как необходимо и в экземплярах предварительной версии, поэтому эти действия не несут производственных затрат.
• Выберите нужную модель ИИ. Выбор модели также играет большую роль в общей стоимости Azure OpenAI. Все модели имеют сильные и слабые стороны и по отдельности ценятся. Использование правильной модели для варианта использования может убедиться, что вы не перераспределаете на более дорогой модели, когда менее дорогие модели дают приемлемые результаты. В этой реализации справочника по чату GPT 3.5-turbo был выбран по сравнению с GPT-4, чтобы сэкономить на уровне затрат на развертывание модели при достижении достаточных результатов.
• Общие сведения о точках останова выставления счетов. Плата за точную настройку взимается в час. Чтобы быть наиболее эффективным, вы хотите использовать столько времени, сколько времени доступно в час, чтобы улучшить результаты тонкой настройки, избегая просто проскользнуть в следующий период выставления счетов. Аналогичным образом, стоимость 100 изображений из создания изображений совпадает с стоимостью для 1 изображения. Максимальное увеличение цен на точки останова для вашего преимущества.
• Общие сведения о моделях выставления счетов. Azure OpenAI также доступна в модели выставления счетов на основе обязательств с помощью подготовленного предложения пропускной способности . После того как у вас есть прогнозируемые шаблоны использования, оцените переключение на эту модель выставления счетов предварительной оплаты, если она вычисляет, чтобы она была более экономичной на томе использования.
• Задайте ограничения подготовки. Убедитесь, что все квоты подготовки выделены только для моделей, которые, как ожидается, будут частью рабочей нагрузки на основе каждой модели. Пропускная способность для уже развернутых моделей не ограничивается этой подготовленной квотой, пока включена динамическая квота. Обратите внимание, что квота не сопоставляет затраты и затраты могут отличаться.
• Отслеживайте использование по мере использования. При использовании оплаты по мере использования отслеживайте использование токенов в минуту (TPM) и запросов в минуту (RPM). Используйте эти сведения для информирования об решениях архитектуры, таких как то, какие модели следует использовать, а также оптимизировать размеры запросов.
• Отслеживайте использование подготовленной пропускной способности. При использовании подготовленной пропускной способности отслеживайте использование, управляемое подготовкой, чтобы убедиться, что вы не используете подготовленную пропускную способность, приобретенную вами.
• Управление затратами. Следуйте инструкциям по использованию функций управления затратами с OpenAI для мониторинга затрат, настройки бюджетов для управления затратами и создания оповещений для уведомления заинтересованных лиц о рисках или аномалиях.

Операции с крупной языковой моделью (LLMOps)

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

Разработка

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

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

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

Оценка

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

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

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

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

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

Рис. 5. Развертывание потока запроса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Синие и зеленые развертывания. С помощью этой стратегии вы можете безопасно развернуть новую версию веб-службы в ограниченной группе пользователей или запросов, прежде чем направлять весь трафик к новому развертыванию.
• A/B Testing: не только развертывания Blue/Green эффективны для безопасного развертывания изменений, их также можно использовать для развертывания нового поведения, позволяющего подмножество пользователей оценить влияние изменения.
• Включите подстраивание файлов Python, которые являются частью потока запроса в конвейерах. Linting проверка для соответствия стандартам стиля, ошибкам, сложности кода, неиспользуемого импорта и именования переменных.
• При развертывании потока в изолированной от сети рабочей области Машинное обучение Azure используйте локальный агент для развертывания артефактов в ресурсах Azure.
• Реестр моделей Машинное обучение Azure следует обновлять только при изменении модели.
• LLM, потоки и пользовательский интерфейс клиента должны быть слабо связаны. Обновления потоков и пользовательского интерфейса клиента могут и должны быть в состоянии выполняться без влияния на модель и наоборот.
• При разработке и развертывании нескольких потоков каждый поток должен иметь собственный жизненный цикл, что позволяет свободно сочетать потоки из экспериментов в рабочую среду.

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

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

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

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

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

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

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

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

Наблюдение

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

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

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

Соавторы

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

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

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

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

Дополнительные сведения об Azure OpenAI

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

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