Проектирование приложений для рабочих нагрузок ИИ в Azure
Существует множество вариантов, которые следует учитывать при создании приложения с функциями искусственного интеллекта. Уникальные функциональные и нефункциональные требования, такие как традиционные требования к машинному обучению, генерированному, детерминированному или сочетанию типов ИИ, помогают сузить высокоуровневые решения по проектированию. Вы рассмотрите эти варианты при переходе от высокоуровневых областей проектирования к областям проектирования нижнего уровня.
Как описано в статье начало работы, решение о том, создавать ли собственную модель или использовать готовую модель, является одним из первых важных решений. При использовании предварительно созданной модели рассмотрите следующие моменты:
Каталожные источники. Изучите репозитории, такие как Hugging Face Model Hub, TensorFlow Hub и портал Azure AI Foundry , каталог моделей для поиска предварительно обученных моделей. Эти платформы предоставляют обширный каталог моделей для различных задач.
Лицензирование Убедитесь, что условия лицензирования модели соответствуют вашим целям безопасности, соответствия требованиям и приложениям, особенно если вы планируете распространять приложение или интегрировать его с другими службами.
Ключевые компоненты. Изучите архитектуру модели, обучающие данные, производительность и лицензирование, чтобы определить, настроена ли она для вашей задачи или домена.
Для рекомендаций по выбору платформы размещения см. раздел Соображения по размещению модели и выполнению выводов.
В этой статье описываются общие области проектирования и факторы, которые следует учитывать при принятии решений о технологии и подходе.
Рекомендации
В следующей таблице приведены рекомендации, приведенные в этой статье.
| Рекомендация | Описание |
|---|---|
| Отдайте предпочтение готовым решениям. | Используйте решения платформы как услуги (PaaS), где это возможно, для обработки задач рабочей нагрузки. Используйте заранее разработанные и обученные модели, где это возможно, чтобы свести к минимуму эксплуатационные и разработческие нагрузки для ваших команд. |
| Абстрагируйте функции и возможности от клиента. | Чтобы клиент оставался максимально облегчённым, создавайте серверные службы для обработки сквозных задач, таких как ограничение частоты и обеспечение отказоустойчивости. |
| Блокировать доступ к хранилищам данных. | Код в системе ИИ не должен напрямую обращаться к хранилищам данных. Маршрутизация всех запросов данных через слой API. API-интерфейсы должны создаваться специально для требуемой задачи. |
| Изолируйте ваши модели. | Как и в хранилищах данных, используйте уровень API для выполнения запросов к модели в качестве шлюза. Некоторые решения PaaS, такие как Служба Azure OpenAI и Служба машинного обучения Azure, используют пакеты SDK для этой цели. Многие средства, такие как поток запросов, содержат встроенную поддержку распространения API в службу. |
| Разработка компонентов для независимого развертывания. | Модели ИИ, конвейеры данных, интерфейсные компоненты и микрослужбы, такие как предварительная обработка данных, извлечение признаков и вывод функций, должны быть независимо развернуты для оптимизации гибкости, масштабируемости и операбельности рабочей нагрузки. |
Контейнеризация компонентов
Чтобы обеспечить полностью автономное развертывание компонентов и оптимизировать развертывания, рассмотрите возможность контейнеризации в рамках стратегии разработки. Следующие компоненты должны быть контейнеризованы:
микросервисы. Отдельные микрослужбы, обрабатывающие определенные функции приложения, такие как обработка данных, вывод модели и проверка подлинности пользователей, должны быть контейнеризованы. Такой подход обеспечивает независимое развертывание и масштабирование и упрощает более эффективное обновление и обслуживание.
модели ИИ. Контейнеризируйте модели ИИ, чтобы обеспечить объединение всех зависимостей, библиотек и конфигураций. Этот подход изолирует среду модели от хост-системы, чтобы предотвратить конфликты версий и обеспечить согласованное поведение в разных средах развертывания.
Пайплайны обработки данных. Все задачи обработки данных, которые предшествуют выводу модели, например очистка данных, преобразование и извлечение признаков, должны быть контейнеризованы. Этот подход повышает воспроизводимость и упрощает управление зависимостями.
службы инфраструктуры. Службы, предоставляющие поддержку инфраструктуры, такие как базы данных и уровни кэширования, также могут воспользоваться контейнеризацией. Контейнеризация этих служб помогает поддерживать согласованность версий и упрощает масштабирование и управление этими компонентами.
Разместите компоненты ИИ совместно с другими компонентами рабочей нагрузки
Существует несколько хороших причин для того, чтобы сопоставить компоненты ИИ с другими компонентами рабочей нагрузки, но существуют компромиссы, связанные с этим. Вы можете разместить компоненты вместе по следующим причинам:
Чувствительность к задержке. Размещайте компоненты ИИ вместе с другими службами, такими как хостинг API, когда важна низкая задержка. Например, если требуется вывод в режиме реального времени, чтобы улучшить взаимодействие с пользователем, размещение моделей ИИ близко к API может свести к минимуму время, необходимое для получения результатов.
близость данных Если модели искусственного интеллекта требуют частого доступа к определенным наборам данных, таким как индекс поиска, совместное размещение этих компонентов может повысить производительность и сократить затраты на передачу данных для ускорения обработки и вывода.
использование ресурсов. Если определенные компоненты имеют дополнительные потребности ресурсов, такие как ЦП и память, совместное размещение их может оптимизировать использование ресурсов. Например, модель, требующая значительных вычислений, может совместно использовать ресурсы со службой, которая одновременно имеет более низкие требования.
компромисс. Существуют компромиссы, которые следует учитывать при принятии решения о том, следует ли колокатировать компоненты. Вы можете потерять возможность независимо развертывать или масштабировать компоненты. Вы также можете увеличить риск сбоя, увеличивая потенциальный радиус воздействия инцидентов.
Оценка использования оркестраторов в решениях для создания искусственного интеллекта
Оркестратор управляет рабочим процессом, координируя обмен данными между различными компонентами решения искусственного интеллекта, которые в противном случае сложно управлять сложными рабочими нагрузками. Рекомендуем включить оркестратор в проект, если ваша нагрузка имеет следующие характеристики:
сложные рабочие процессы. Рабочий процесс включает несколько шагов, таких как предварительная обработка, связывание моделей или постобработка.
Условной логики. Решения, такие как маршрутизация результатов в разные модели, необходимо принимать динамически на основе выходных данных модели.
масштабирование и управление ресурсами. Необходимо управлять выделением ресурсов для высокопроизводительных приложений с помощью масштабирования модели на основе спроса.
управление состоянием. Необходимо управлять состоянием и памятью взаимодействия с пользователем.
получение данных. Необходимо иметь возможность получать данные об увеличении из индекса.
Рекомендации по использованию нескольких моделей
Если рабочая нагрузка использует несколько моделей, оркестратор имеет важное значение. Оркестратор направляет данные и запросы к соответствующей модели в зависимости от варианта использования. Планируйте поток данных между моделями, гарантируя, что выходные данные одной модели могут служить входными данными для другого. Планирование может включать преобразование данных или процессы обогащения.
Оркестрация и агенты
Для рабочих нагрузок генеративного ИИ рекомендуется принять агентный, иногда называемый агентическим, подход к проектированию для добавления расширяемости к вашей оркестрации. Агенты предоставляют функциональные возможности, связанные с контекстом. Они разделяют множество характеристик с микрослужбами и выполняют задачи в сотрудничестве с оркестратором. Оркестратор может объявлять задачи в пул агентов, или агенты могут регистрировать свои способности у оркестратора. Оба подхода позволяют оркестратору динамически определять способ разделения и маршрутизации запроса между агентами.
Агентские подходы идеальны, когда у вас есть общая поверхность пользовательского интерфейса с несколькими развивающимися функциями, которые можно интегрировать в опыт, чтобы со временем добавить больше навыков и основополагающих данных в процесс.
Для сложных рабочих нагрузок, имеющих много агентов, более эффективно разрешить агентам динамически сотрудничать, а не использовать оркестратор для разбиения задач и назначения их.
Обмен данными между оркестратором и агентами должен соответствовать шаблону очереди разделов, где агенты являются подписчиками темы, а оркестратор отправляет задачи через очередь.
Использование агентического подхода лучше всего работает с шаблоном оркестрации, а не с шаблоном хореографии.
Дополнительные сведения см. в разделе Учитываемые аспекты для платформы оркестрации.
Оценка использования шлюзов API
Шлюзы API, такие как Azure API Management, абстрагируют функции от API, что устраняет зависимости между запрашивающей службой и API. Шлюзы API предоставляют следующие преимущества для рабочих нагрузок ИИ:
несколько микрослужб. Шлюзы помогают управлять несколькими конечными точками модели ИИ, если необходимо применять согласованные политики, такие как ограничение скорости и проверка подлинности.
Управление трафиком. Шлюзы помогают эффективно управлять приложениями с высоким трафиком, управляя запросами, кэшированием ответов и распределением нагрузки.
Безопасность. Шлюзы обеспечивают централизованный контроль доступа, ведение журнала и защиту от угроз для API-интерфейсов, стоящих за шлюзом.
Использование шаблонов проектирования приложений ИИ
В отрасли для приложений искусственного интеллекта были созданы несколько распространенных шаблонов проектирования. Их можно использовать для упрощения проектирования и реализации. К этим шаблонам проектирования относятся следующие:
ансамблирование моделей. Этот шаблон проектирования включает объединение прогнозов из нескольких моделей для повышения точности и надежности путем устранения недостатков отдельных моделей.
Архитектура микрослужб. Разделение компонентов на независимые развернутые службы повышает масштабируемость и удобство обслуживания. Она позволяет командам одновременно работать над различными частями приложения.
Архитектура на основе событий. Использование событий для активации действий позволяет отделить компоненты и обработку в режиме реального времени, чтобы сделать систему более адаптивной и адаптируемой к изменению данных.
Стратегии схем RAG и группировки.
Шаблон создания Retrieval-Augmented (RAG) объединяет генеривные модели с системами извлечения, что позволяет модели получать доступ к внешним источникам знаний для улучшения контекста и точности. Обратитесь к серии статей по проектированию и разработке решения RAG, чтобы получить подробное руководство по этому шаблону. Существует два подхода к RAG:
Точно в срок. Этот подход динамически получает соответствующую информацию во время запроса, чтобы гарантировать, что последние данные всегда используются. Это полезно в сценариях, требующих контекста в режиме реального времени, но это может привести к задержке.
предварительно вычисленные (кэшированные). Этот метод включает кэширование результатов извлечения для уменьшения времени отклика путем передачи предварительно вычисленных данных. Он подходит для сценариев с высоким спросом, где можно хранить согласованные данные. Данные могут не отражать самую текущую информацию, что может привести к проблемам релевантности.
При использовании шаблона RAG важно наличие четко определенной стратегии разбиения для оптимизации эффективности выполнения рабочей нагрузки. Начните с руководства , предоставленного в серии по проектированию и разработке решений RAG. Ниже приведены некоторые дополнительные рекомендации, которые следует учитывать:
Реализуйте стратегию динамического блокирования, которая настраивает размеры блоков на основе типов данных, сложности запросов и требований пользователей. Это позволяет повысить эффективность извлечения и сохранение контекста.
Включите циклы обратной связи для уточнения стратегий разбиения на основе данных о производительности.
Сохраните происхождение данных для блоков, поддерживая метаданные и уникальные идентификаторы, которые связывают их с исходным источником. Чёткая документация по происхождению данных помогает гарантировать, что пользователи понимают источник данных, его преобразования и как он участвует в формировании выходных данных.
Когда следует использовать шаблоны проектирования
Рекомендуется использовать эти шаблоны проектирования, если вариант использования соответствует описанному условию:
сложные рабочие процессы. Если у вас есть сложные рабочие процессы или взаимодействие между несколькими моделями ИИ, шаблоны, такие как RAG или микрослужбы, могут помочь управлять сложностью и обеспечить четкое взаимодействие между компонентами.
требования к масштабируемости. Если спрос на приложение изменяется, шаблон, такой как микрослужбы, позволяет отдельным компонентам масштабироваться независимо, чтобы соответствовать различным нагрузкам, не влияя на общую производительность системы.
приложения на основе данных. Если приложению требуется обширная обработка данных, архитектура на основе событий может обеспечить скорость реагирования в режиме реального времени и эффективную обработку данных.
Примечание.
Небольшие приложения или прототипы обычно не получают особой выгоды от этих паттернов проектирования. Эти приложения должны быть разработаны для простоты. Аналогичным образом, если у вас есть ограничения ресурсов (бюджет, время или численность персонала), использование простой конструкции, которую можно улучшить позже, лучше, чем применение сложного проектного шаблона.
Выбор правильных платформ и библиотек
Выбор платформ и библиотек тесно связан с дизайном приложения. Они влияют на производительность, масштабируемость и удобство обслуживания. Однако требования к проектированию могут ограничить выбор платформы. Например, использование пакета SDK для семантического ядра часто поощряет проектирование на основе микрослужб, где каждый агент или функция инкапсулируется в собственной службе. При выборе платформ и библиотек следует учитывать следующие факторы:
требования к заявке. Требования приложения, такие как обработка в режиме реального времени или пакетная обработка, могут ограничить выбор платформы. Например, если приложению требуется низкая задержка, может потребоваться использовать платформу с асинхронными возможностями.
Требуется интеграция. Для разработки может потребоваться конкретная интеграция с другими системами или службами. Если платформа не поддерживает необходимые протоколы или форматы данных, может потребоваться пересмотреть проект или выбрать другую платформу.
Компетентность команды. Набор навыков команды разработчиков может ограничить выбор платформы. Дизайн, основанный на менее знакомых платформах, может привести к увеличению времени разработки и сложности, поэтому вы можете использовать более знакомый инструмент.
Разработка стратегии по идентификации, авторизации и доступу
Как правило, следует подходить к идентификации, авторизации и доступу таким же образом, что и при обычном проектировании приложений. Для управления этими областями по возможности следует использовать поставщика услуг идентификации, например Microsoft Entra ID. Однако многие приложения ИИ имеют уникальные проблемы, которые требуют особого рассмотрения. Иногда сложно или даже невозможно сохранить списки управления доступом (ACL) через систему без новой разработки.
См. руководство по проектированию безопасного мультитенантного решения для вывода RAG, чтобы узнать, как добавить метаданные для ограничения доступа в документы и разделы. Это ограничение может основываться на группах безопасности или аналогичных организационных конструкциях.
Рассмотрите нефункциональные требования
У рабочей нагрузки могут быть нефункциональные требования, которые представляют трудности из-за факторов, которые являются неотъемлемой частью технологий ИИ. Ниже приведены некоторые распространенные нефункциональные требования и их проблемы.
задержка вывода модели / время ожидания. Приложения ИИ часто требуют ответов в режиме реального времени или практически в реальном времени. Проектирование для низкой задержки имеет решающее значение. Она включает оптимизацию архитектуры модели, конвейеров обработки данных и аппаратных ресурсов. Реализация стратегий кэширования и обеспечение эффективной загрузки модели также важно, чтобы избежать времени ожидания и своевременного реагирования.
ограничения пропускной способности токена или запроса. Многие службы ИИ накладывают ограничения на количество маркеров или пропускную способность запросов, особенно с облачными моделями. Для разработки этих ограничений требуется тщательное управление размерами входных данных, пакетирование запросов при необходимости и потенциально реализация механизмов ограничения скорости или очередей для управления ожиданиями пользователей и предотвращения нарушений работы служб.
сценарии затрат и возвратных платежей. Проектирование прозрачности затрат включает реализацию функций отслеживания использования и создания отчетов, которые упрощают модели обратной оплаты. Эти функции позволяют организациям точно распределять затраты между отделами. Обработка чарджбэков обычно осуществляется шлюзом для управления API, например Azure API Management.