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