Сокращенная версия этого поста появилась в The New Stack 19 марта 2024 года.

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

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

В другом посте мы представили эталонную архитектуру современного озера данных, способного удовлетворить потребности бизнес-аналитики, анализа данных, науки о данных и искусственного интеллекта и машинного обучения. Давайте рассмотрим современную эталонную архитектуру Datalake и выделим ее возможности для поддержки рабочих нагрузок AI/ML.

Современное озеро данных

Давайте начнем с определения современного озера данных, поскольку оно послужит основой для нашей эталонной архитектуры. Эта архитектура не является «переработанной», а отражает основные инженерные принципы, которые широко применимы. Современное Datalake наполовину представляет собой хранилище данных, наполовину озеро данных и использует объектное хранилище для всего. Использование объектного хранилища для озера данных имеет смысл, поскольку объектное хранилище предназначено для неструктурированных данных, для хранения которых предназначено озеро данных. Однако использование объектного хранилища для хранилища данных может показаться странным, но построенное таким образом хранилище данных представляет собой следующее поколение хранилищ данных. Это стало возможным благодаря спецификациям формата открытых таблиц (OTF), разработанным Netflix, Uber и Databricks, которые упрощают использование объектного хранилища в хранилище данных.

OTF — это Apache Iceberg, Apache Hudi и Delta Lake. Их авторами выступили Netflix, Uber и Databricks соответственно — потому что на рынке не было продуктов, которые могли бы удовлетворить их потребности в данных. По сути, все они (по-разному) определяют хранилище данных, которое можно построить поверх объектного хранилища (MinIO). Объектное хранилище обеспечивает сочетание масштабируемой емкости и высокой производительности, которого не могут достичь другие решения для хранения данных. Поскольку это современные спецификации, они обладают расширенными функциями, которых нет в старых хранилищах данных, такими как эволюция разделов, эволюция схемы и ветвление с нулевым копированием. Наконец, поскольку хранилище данных построено на объектном хранилище, вы можете использовать это же хранилище объектов для неструктурированных данных, таких как изображения, видеофайлы, аудиофайлы и документы.

Неструктурированные данные обычно хранятся в том, что в отрасли называется озером данных. Использование хранилища объектов в качестве основы как для озера данных, так и для хранилища данных приводит к созданию решения, способного хранить все ваши данные. Структурированное хранилище находится в хранилище данных на базе OTF, а неструктурированное хранилище — в озере данных. Для обоих можно использовать один и тот же экземпляр MinIO.

В MinIO мы называем эту комбинацию хранилища данных на основе OTF и озера данных современным озером данных и рассматриваем ее как основу для всех ваших рабочих нагрузок AI/ML. Здесь данные собираются, хранятся, обрабатываются и преобразуются. Модели обучения с использованием дискриминационного ИИ (обучение с учителем, без учителя и с подкреплением) часто требуют решения для хранения, способного обрабатывать структурированные данные, которые могут храниться в хранилище данных. С другой стороны, если вы обучаете модели большого языка (LLM), вам необходимо управлять неструктурированными данными или документами в их необработанной и обработанной форме в озере данных.

Источник : Современная эталонная архитектура Datalake

В этом посте основное внимание уделяется тем областям современной эталонной архитектуры Datalake для AI/ML, которые поддерживают различные рабочие нагрузки AI/ML. Эти функциональные области перечислены ниже. Визуальное изображение современного озера данных показано выше. Слои, в которых можно найти эти функциональные области, выделены.

• Дискриминационный ИИ

  
  

  • Хранение неструктурированных данных

  • Хранение полуструктурированных данных

  • Ветвление с нулевым копированием в хранилище данных

    
    

• Генеративный ИИ

  
  

  • Создание пользовательского корпуса с помощью векторной базы данных

  • Создание конвейера документов

  • Поисковая дополненная генерация (RAG)

  • Точная настройка больших языковых моделей

  • Измерение точности LLM

    
    

• Операции машинного обучения

  
  

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

• Текущее состояние графических процессоров

  
  

  • Проблема голодного графического процессора

  • Расширение объектного хранилища

    
    

• История двух организаций

• План построения инфраструктуры данных искусственного интеллекта

Дискриминационный ИИ

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

Хранение неструктурированных данных

Неструктурированные данные будут храниться в озере данных, где их можно будет использовать для обучения и тестирования моделей. Обучающие наборы, которые могут поместиться в память, можно загрузить до обучения (до начала цикла эпох). Однако, если ваш обучающий набор велик и не помещается в память, вам придется загрузить список объектов перед обучением и извлечь фактические объекты при обработке каждого пакета в цикле эпох. Это может создать нагрузку на ваше озеро данных, если вы не создадите озеро данных с использованием высокоскоростной сети и высокоскоростных дисков. Если вы обучаете модели с данными, которые не помещаются в память, рассмотрите возможность создания озера данных с сетью емкостью 100 ГБ и дисками NVMe.

Хранение полуструктурированных данных

В Modern Datalake доступно несколько вариантов хранения полуструктурированных файлов, таких как файлы Parquet, файлы AVRO, файлы JSON и даже файлы CSV. Самый простой способ — сохранить их в Data Lake и загружать так же, как и неструктурированные объекты. Если данные в этих полуструктурированных файлах не нужны другим рабочим нагрузкам, которые поддерживает Modern Datalake (бизнес-аналитика, анализ данных и обработка данных), то это лучший вариант.

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

Ветвление с нулевым копированием в хранилище данных

Разработка функций — это метод улучшения наборов данных, используемых для обучения модели. Очень интересная функция, которой обладают хранилища данных на основе OTF, — это ветвление с нулевым копированием. Это позволяет разветвлять данные так же, как разветвляется код внутри репозитория Git. Как следует из названия, эта функция не создает копию данных — скорее, она использует уровень метаданных формата открытой таблицы, используемый для реализации хранилища данных, для создания видимости уникальной копии данных. Ученые, работающие с данными, могут экспериментировать с веткой — если их эксперименты пройдут успешно, они смогут объединить свою ветвь обратно с основной веткой, чтобы ее могли использовать другие специалисты по данным. Если эксперимент не удался, то ветку можно удалить.

Генеративный ИИ

Все модели, будь то небольшие модели, созданные с помощью Scikit-Learn, пользовательские нейронные сети, созданные с помощью PyTorch или TensorFlow, или большие языковые модели, основанные на архитектуре Transformer, требуют чисел в качестве входных данных и выдают числа в качестве выходных данных. Этот простой факт накладывает несколько дополнительных требований на вашу инфраструктуру AI/ML, если вы заинтересованы в генеративном искусственном интеллекте, где слова необходимо превращать в числа (или векторы, как мы увидим). Решение с генеративным искусственным интеллектом становится еще более сложным, если вы хотите использовать частные документы, содержащие собственные знания вашей компании, для улучшения ответов, предоставляемых LLM. Это усовершенствование может быть в форме поисковой расширенной генерации или точной настройки LLM.

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

Создание пользовательского корпуса с помощью векторной базы данных

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

Векторные базы данных облегчают семантический поиск. То, как это сделать, требует большого математического знания и является сложным. Однако семантический поиск концептуально легко понять. Допустим, вы хотите найти все документы, в которых обсуждается что-либо, связанное с «искусственным интеллектом». Чтобы сделать это в обычной базе данных, вам нужно будет найти все возможные сокращения, синонимы и связанные с ними термины «искусственный интеллект». Ваш запрос будет выглядеть примерно так:

 SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ...

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

 { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } }

Еще одним важным фактором при выборе пользовательского корпуса является безопасность. Доступ к документам должен учитывать ограничения доступа к оригиналам документов. (Было бы прискорбно, если бы стажер мог получить доступ к финансовым результатам финансового директора, которые еще не были опубликованы на Уолл-стрит.) В вашей векторной базе данных вам следует настроить авторизацию, соответствующую уровням доступа исходного контента. Это можно сделать путем интеграции вашей базы данных Vector с решением для управления идентификацией и доступом вашей организации.

По своей сути векторные базы данных хранят неструктурированные данные. Поэтому им следует использовать ваше Data Lake в качестве решения для хранения данных.

Создание конвейера документов

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

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

Точная настройка больших языковых моделей

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

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

Недостатки

• Для тонкой настройки потребуются вычислительные ресурсы.

• Объяснение невозможно.

• По мере развития вашего корпуса вам периодически придется вносить новые данные.

• Галлюцинации вызывают беспокойство.

• Безопасность на уровне документов невозможна.

  
  

Преимущества

• LLM использует знания из вашего пользовательского корпуса посредством тонкой настройки.

• Поток вывода менее сложен, чем RAG.

  
  

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

Давайте рассмотрим метод, который объединяет ваши пользовательские данные и параметрические данные во время вывода.

Поисковая дополненная генерация (RAG)

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

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

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

Недостатки

• Поток вывода более сложен.

  
  

Преимущества

• LLM имеет непосредственные знания из вашего пользовательского корпуса.
• Объяснимость возможна.
• Никакой тонкой настройки не требуется.
• Галлюцинации значительно уменьшаются, и их можно контролировать, изучая результаты запросов к векторной базе данных.
• Авторизацию можно реализовать.

Операции машинного обучения (MLOps)

Чтобы лучше понять важность MLOps, полезно сравнить создание моделей с разработкой обычных приложений. Обычная разработка приложений, например реализация нового микросервиса, добавляющего в приложение новую функцию, начинается с рассмотрения спецификации. Любые новые структуры данных или любые изменения в существующих структурах данных разрабатываются в первую очередь. Структура данных не должна меняться после начала кодирования. Затем услуга реализуется, и основным видом деятельности в этом процессе является кодирование. Также кодируются модульные и сквозные тесты. Эти тесты доказывают, что код исправен и правильно реализует спецификацию. Их можно запускать автоматически с помощью конвейера CI/CD перед развертыванием всего приложения.

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

MLOps, сокращение от Machine Learning Operations, представляет собой набор практик и инструментов, направленных на устранение этих различий. Отслеживание экспериментов и совместная работа — это функции, которые больше всего ассоциируются с MLOP, но более современные инструменты MLOP, имеющиеся сегодня в отрасли, могут сделать гораздо больше. Например, они могут предоставить среду выполнения для ваших экспериментов, а также упаковать и развернуть модели, как только они будут готовы к интеграции в приложение. Ниже приведен расширенный набор функций, имеющихся в современных инструментах MLOps. В этот список также входят другие моменты, которые следует учитывать, например поддержка и интеграция данных.

1. Поддержка крупного игрока — методы и функции MLOps постоянно развиваются. Вам нужен инструмент, поддерживаемый крупным игроком, гарантирующий, что этот инструмент постоянно развивается и совершенствуется.

   
   

2. Современная интеграция с Datalake . Эксперименты генерируют много структурированных и неструктурированных данных. В идеале это могло бы храниться в хранилище данных и озере данных. Однако многие инструменты MLOps существовали до появления форматов открытых таблиц, которые привели к появлению Modern Datalake, поэтому у большинства из них будет отдельное решение для структурированных данных.

   
   

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

   
   

4. Упростите сотрудничество — позвольте членам команды просматривать результаты всех экспериментов, проведенных всеми инженерами ML.

   
   

5. Упаковка модели . Упакуйте модель так, чтобы она была доступна из других сред программирования.

   
   

6. Обслуживание моделей — развертывание моделей в формальных средах организации. Вам это не понадобится, если вы нашли способ включить свои модели в существующий конвейер CI/CD.

   
   

7. Реестр моделей — ведение всех версий всех моделей.

   
   

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

   
   

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

   
   

10. Возможности обучающего конвейера — возможность организовать ваши бессерверные функции в направленный ациклический граф. Также позволяет планировать и запускать конвейеры обучения.

Влияние графических процессоров на вашу инфраструктуру данных искусственного интеллекта

Цепочка так же сильна, как и ее самое слабое звено, а ваша инфраструктура AI/ML работает настолько же быстро, насколько быстро ваш самый медленный компонент. Если вы обучаете модели машинного обучения с помощью графических процессоров, то вашим слабым звеном может стать решение для хранения данных. Результатом является то, что мы называем «проблемой голодающего графического процессора». Проблема голодания графического процессора возникает, когда ваша сеть или ваше решение для хранения данных не могут достаточно быстро передавать обучающие данные в вашу логику обучения, чтобы полностью использовать ваши графические процессоры. Симптомы довольно очевидны. Если вы следите за своими графическими процессорами, вы заметите, что они никогда не приближаются к полной загрузке. Если вы инструментировали свой обучающий код, то вы заметите, что в общем времени обучения преобладает ввод-вывод.

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

Текущее состояние графических процессоров

Графические процессоры становятся быстрее. Не только улучшается производительность, но также увеличиваются объем памяти и пропускная способность. Давайте посмотрим на эти три характеристики новейших графических процессоров Nvidia. А100 , Н100 и Н200 .

Стоит привести несколько сравнительных наблюдений по приведенной выше статистике. Во-первых, H100 и H200 имеют одинаковую производительность (1979 терафлопс), что в 3,17 раза выше, чем у A100. У H100 в два раза больше памяти, чем у A100, и пропускная способность памяти увеличена на аналогичную величину — что имеет смысл, иначе графический процессор будет голодать. H200 может обрабатывать колоссальные 141 ГБ памяти, а пропускная способность его памяти также увеличена пропорционально по сравнению с другими графическими процессорами.

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

Производительность . Терафлоп (TFLOP) равен одному триллиону (10^12) операций с плавающей запятой в секунду. Это 1 с 12 нулями после нее (1 000 000 000 000). Трудно приравнять TFLOP к требованию ввода-вывода в гигабайтах, поскольку операции с плавающей запятой, которые происходят во время обучения модели, включают в себя простую тензорную математику, а также первые производные от функции потерь (также известной как градиенты). Однако относительное сравнение возможно. Глядя на приведенную выше статистику, мы видим, что H100 и H200, которые оба работают со скоростью 1979 терафлопс, в три раза быстрее - потенциально потребляют данные в 3 раза быстрее, если все остальное будет поддерживать такой же уровень.

Память графического процессора — также известна как видеопамять или графическая память. Память графического процессора отделена от основной памяти системы (ОЗУ) и специально разработана для выполнения интенсивных задач графической обработки, выполняемых видеокартой. Память графического процессора определяет размер пакета при обучении моделей. Раньше размер пакета уменьшался, когда логика обучения перемещалась с ЦП на графический процессор. Однако по мере того, как память графического процессора догоняет память процессора по емкости, размер пакета, используемого для обучения графического процессора, будет увеличиваться. Когда одновременно увеличиваются производительность и объем памяти, в результате запросы становятся более крупными, при этом каждый гигабайт обучающих данных обрабатывается быстрее.

Пропускная способность памяти . Подумайте о пропускной способности памяти графического процессора как о «магистрали», соединяющей память и вычислительные ядра. Он определяет, какой объем данных может быть передан в единицу времени. Точно так же, как более широкое шоссе позволяет проехать большему количеству автомобилей за определенный промежуток времени, более высокая пропускная способность памяти позволяет перемещать больше данных между памятью и графическим процессором. Как видите, разработчики этих графических процессоров увеличили пропускную способность памяти для каждой новой версии пропорционально объему памяти; следовательно, внутренняя шина данных чипа не будет узким местом.

Расширенное хранилище объектов для обучения моделей

Если у вас возникла проблема с голоданием графического процессора, рассмотрите возможность использования сети объемом 100 ГБ и дисков NVMe. А недавний тест использование MinIO с такой конфигурацией позволило достичь скорости 325 ГиБ/с на GET и 165 ГиБ/с на PUT всего лишь с 32 узлами готовых твердотельных накопителей NVMe.

По мере развития компьютерного мира и цена DRAM резко упала мы обнаружили, что конфигурации серверов часто имеют 500 ГБ или более DRAM. Когда вы имеете дело с более крупными развертываниями, даже со сверхплотными дисками NVMe, количество серверов, умноженное на DRAM на этих серверах, может быстро увеличиться — часто до многих ТБ на экземпляр. Этот пул DRAM можно настроить как распределенный общий пул памяти и идеально подходит для рабочих нагрузок, требующих большого количества операций ввода-вывода в секунду и высокой пропускной способности. В результате мы создали MinIO Cache, чтобы наши клиенты Enterprise и Enterprise Lite могли настроить свою инфраструктуру так, чтобы использовать преимущества этого общего пула памяти для дальнейшего повышения производительности основных рабочих нагрузок ИИ, таких как обучение графического процессора, при одновременном сохранении полной устойчивости.

История двух организаций

В качестве заключительного мысленного эксперимента давайте расскажем историю о двух организациях, которые используют совершенно разные подходы в своем путешествии по искусственному интеллекту и машинному обучению. В организации №1 существует культура «итеративных улучшений». Они считают, что все крупные инициативы можно разбить на более мелкие и более управляемые проекты. Эти более мелкие проекты затем планируются таким образом, что каждый из них опирается на результаты предыдущего проекта для решения проблем все большей и большей сложности. Им также нравятся небольшие проекты, организованные таким образом, чтобы каждый из них приносил пользу бизнесу. Они обнаружили, что проекты, направленные исключительно на улучшение инфраструктуры или модернизацию программного обеспечения без каких-либо новых функций для бизнеса, не очень популярны среди руководителей, контролирующих бюджеты. Следовательно, они поняли, что запрашивать модные устройства хранения данных и вычислительные кластеры для проверки концепции генеративного ИИ — не лучший способ организовать улучшения инфраструктуры и новые возможности программного обеспечения. Скорее, они начнут с малого, с инфраструктурных продуктов, которые могут масштабироваться по мере роста, и начнут с простых моделей искусственного интеллекта, чтобы получить инструменты MLOP и понять, как работать с существующими командами DevOps и конвейерами CI/CD.

В организации №2 существует культура «блестящих предметов». Когда новейшая идея попадает в отрасль, она сначала решает сложную задачу, чтобы продемонстрировать свою техническую мощь. Они обнаружили, что эти проекты очень заметны как внутри, так и снаружи. Если что-то сломается, то умные люди всегда смогут это починить.

Организация №1 структурировала свой первый проект, создав часть инфраструктуры данных искусственного интеллекта и одновременно работая над рекомендательной моделью для своего основного сайта электронной коммерции. Модель рекомендаций была относительно простой в обучении. Это дискриминационная модель, использующая наборы данных, которые уже существуют в общей папке. Однако в конце этого проекта команда также создала небольшой (но масштабируемый) Modern Datalake, внедрила инструменты MLOP и разработала некоторые передовые методы обучения и развертывания моделей. Несмотря на то, что модель несложная, она все же значительно повысила эффективность их сайта. Они использовали эти положительные результаты, чтобы получить финансирование для своего следующего проекта, который станет генеративным решением на базе искусственного интеллекта.

Организация №2 создала чат-бота для своего сайта электронной коммерции, который отвечал на вопросы клиентов о продуктах. Модели большого языка довольно сложны — команда не была знакома с точной настройкой или извлечением дополненной генерации — поэтому все инженерные циклы этого проекта были сосредоточены на быстром прохождении крутой кривой обучения. Когда модель была завершена, она дала хорошие результаты – ничего особенного. К сожалению, его пришлось вручную загружать в предварительную и производственную среды, поскольку для его развертывания не было инструментов MLOps. Это вызвало небольшие разногласия в команде DevOps. У самой модели также было несколько проблем со стабильностью в производстве. Кластеру, в котором он работал, не хватало вычислительной мощности для выполнения генеративной рабочей нагрузки ИИ. Было несколько вызовов первой степени серьезности, что привело к экстренному расширению кластера, чтобы LLM не выходил из строя в условиях интенсивного трафика. После проекта ретроспектива определила, что им необходимо расширить свою инфраструктуру, если они хотят добиться успеха с ИИ.

План построения инфраструктуры данных AI/ML

Рассказ, приведенный выше, представляет собой простое повествование о двух крайних обстоятельствах. Построение моделей ИИ (как дискриминативных, так и генеративных) существенно отличается от разработки обычного программного обеспечения. Это следует учитывать при постановке в очередь попыток AI/ML. Рисунок ниже представляет собой визуальное изображение истории, рассказанной в предыдущем разделе. Это параллельное сравнение подхода AI Data Infrastructure First и подхода Model First. Как показала история выше, каждый из приведенных ниже кирпичиков для первого подхода к инфраструктуре не обязательно должен быть отдельным проектом. Организациям следует искать творческие способы реализации ИИ, пока строится их инфраструктура. Этого можно добиться, поняв все возможности ИИ, начав с простого, а затем выбирая проекты ИИ возрастающей сложности.

Заключение

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

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