0.1 C
New York

Проектирование генеративных рабочих нагрузок ИИ для обеспечения устойчивости | DeepTech

Published:

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

Полнофункциональный генеративный искусственный интеллект

Хотя большая часть ажиотажа вокруг генеративного искусственного интеллекта сосредоточена на моделях, комплексное решение предполагает участие людей, навыков и инструментов из нескольких областей. Рассмотрим следующий рисунок, который представляет собой представление AWS о новом стеке приложений a16z для больших языковых моделей (LLM).

По сравнению с более традиционным решением, основанным на искусственном интеллекте и машинном обучении (ML), генеративное решение на основе искусственного интеллекта теперь включает в себя следующее:

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

Рассуждения агента

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

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

Конвейеры данных

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

Источниками данных могут быть PDF-документы в файловой системе, данные из системы программного обеспечения как услуги (SaaS), такой как инструмент CRM, или данные из существующей вики-страницы или базы знаний. Получение данных из этих источников отличается от обычных источников данных, таких как данные журналов в корзине Amazon Simple Storage Service (Amazon S3) или структурированные данные из реляционной базы данных. Уровень параллелизма, которого вы можете достичь, может быть ограничен исходной системой, поэтому вам необходимо учитывать регулирование и использовать методы отсрочки. Некоторые из исходных систем могут быть хрупкими, поэтому вам необходимо встроить логику обработки ошибок и повторных попыток.

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

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

Векторные базы данных

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

  • Выделенные варианты SaaS, такие как Pinecone.
  • Функции векторной базы данных, встроенные в другие сервисы. Сюда входят собственные сервисы AWS, такие как Amazon OpenSearch Service и Amazon Aurora.
  • Параметры в памяти, которые можно использовать для временных данных в сценариях с низкой задержкой.

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

  • Задержка – Может ли база данных векторов хорошо работать при высокой или непредсказуемой нагрузке? В противном случае вызывающему приложению необходимо обработать ограничение скорости, отсрочку и повторную попытку.
  • Масштабируемость – Сколько векторов может содержать система? Если вы превысите емкость векторной базы данных, вам придется рассмотреть сегментирование или другие решения.
  • Высокая доступность и аварийное восстановление – Встраивание векторов представляет собой ценные данные, и их воссоздание может оказаться дорогостоящим. Обеспечена ли ваша векторная база данных высокой доступностью в одном регионе AWS? Есть ли у него возможность реплицировать данные в другой регион для целей аварийного восстановления?

Уровень приложения

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

  • Потенциально высокая задержка – Модели Foundation часто работают на больших экземплярах графического процессора и могут иметь ограниченную емкость. Обязательно используйте рекомендации по ограничению скорости, отсрочке и повторным попыткам, а также сбросу нагрузки. Используйте асинхронные конструкции, чтобы высокая задержка не мешала работе основного интерфейса приложения.
  • Положение безопасности – Если вы используете агенты, инструменты, плагины или другие методы подключения модели к другим системам, обратите особое внимание на уровень безопасности. Модели могут пытаться взаимодействовать с этими системами неожиданными способами. Следуйте обычной практике доступа с наименьшими привилегиями, например, ограничив входящие запросы от других систем.
  • Быстро развивающиеся фреймворки – Фреймворки с открытым исходным кодом, такие как LangChain, быстро развиваются. Используйте подход микросервисов, чтобы изолировать другие компоненты от этих менее зрелых платформ.

Емкость

Мы можем думать о емкости в двух контекстах: конвейерах данных логических выводов и обучающих моделей. Емкость учитывается при создании собственных конвейеров. Требования к ЦП и памяти — два самых важных требования при выборе экземпляров для выполнения рабочих нагрузок.

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

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

Наблюдаемость

Помимо показателей ресурсов, которые вы обычно собираете, таких как загрузка ЦП и ОЗУ, вам необходимо внимательно отслеживать загрузку графического процессора, если вы размещаете модель в Amazon SageMaker или Amazon Elastic Compute Cloud (Amazon EC2). Использование графического процессора может неожиданно измениться, если изменится базовая модель или входные данные, а нехватка памяти графического процессора может привести систему в нестабильное состояние.

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

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

Аварийное восстановление

Наличие плана обеспечения непрерывности бизнеса со стратегией аварийного восстановления является обязательным условием для любой рабочей нагрузки. Генеративные рабочие нагрузки ИИ ничем не отличаются. Понимание режимов сбоя, применимых к вашей рабочей нагрузке, поможет разработать стратегию. Если вы используете для своей рабочей нагрузки управляемые сервисы AWS, такие как Amazon Bedrock и SageMaker, убедитесь, что этот сервис доступен в вашем регионе восстановления AWS. На момент написания этой статьи эти сервисы AWS не поддерживают репликацию данных между регионами AWS изначально, поэтому вам необходимо подумать о стратегиях управления данными для аварийного восстановления, а также, возможно, потребуется выполнить тонкую настройку в нескольких регионах AWS.

Заключение

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

Дополнительную информацию о генеративном искусственном интеллекте и его использовании с сервисами AWS можно найти на следующих ресурсах:


Об авторах

Дженнифер Моран — старший специалист по архитектуре решений AWS по обеспечению устойчивости, базирующийся в Нью-Йорке. У нее разносторонний опыт: она работала во многих технических дисциплинах, включая разработку программного обеспечения, гибкое лидерство и DevOps, и является защитником прав женщин в сфере технологий. Ей нравится помогать клиентам разрабатывать устойчивые решения для повышения устойчивости, и она публично высказывается на все темы, связанные с устойчивостью.

Рэнди ДеФауРэнди ДеФау — старший главный архитектор решений в AWS. Он получил степень MSEE в Мичиганском университете, где работал над компьютерным зрением для автономных транспортных средств. Он также имеет степень MBA Университета штата Колорадо. Рэнди занимал различные должности в сфере технологий, от разработки программного обеспечения до управления продуктами. Он вошел в сферу больших данных в 2013 году и продолжает исследовать эту область. Он активно работает над проектами в сфере ML и выступал на многочисленных конференциях, включая Strata и GlueCon.

Related Articles

Recent articles