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

Основные компоненты для решения машинного обучения

Сейчас иногда легко забыть (или, к сожалению, для некоторых это слишком реально), но когда-то было время, когда создание моделей машинного обучения требовало значительного объема работы. В недалеком прошлом это потребовало бы реализации ваших собственных алгоритмов, написания тонны кода в процессе и надежды на то, что вы не сделаете критических ошибок при переводе академической работы в функциональную библиотеку. Теперь, когда у нас есть такие вещи, как scikit-learn, XGBoost и Tensorflow / PyTorch, большое препятствие было устранено, и неспециалисты могут создавать модели с меньшим объемом знаний предметной области и опытом кодирования и, возможно, получить обратно первоначальные результаты. в часах. В процессе иногда легко забыть, в чем суть решения машинного обучения. Если бы мы были склонны попытаться решить проблему машинного обучения с нуля, что бы нам понадобилось? Я долгое время считал, что любое решение машинного обучения состоит из четырех основных частей:

  1. Данные. Данные обучения необходимы для любого алгоритма машинного обучения.
  2. Код: выберите нужную библиотеку, но для ее использования потребуется некоторый код.
  3. Среда: нам нужно где-то запустить код.
  4. Модель: то, что мы будем использовать, чтобы делать прогнозы.

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

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

Платформы могут сильно меняться в зависимости от их направленности, как мы увидим ниже. Тот, который подходит для вашей организации, во многом зависит от ваших целей: нужна ли вам платформа, которая оптимизирует жизненный цикл разработки для исследователей данных (поколение 1), или что-то, что поможет вашему бизнесу выполнять сценарии использования ИИ так быстро, как возможно с минимальным риском (Gen 3)?

Поколение 1: совместная наука о данных

Современный подход к платформе машинного обучения начал формироваться в конце 2000-х годов, когда появилась экосистема библиотек Python с открытым исходным кодом, что сделало задачу развития науки о данных относительно простой. Такие пакеты, как NumPy (2006), pandas (2008) и scikit-learn (2007), сделали преобразование и моделирование данных в Python намного проще, чем это было раньше, и в сочетании с такими инструментами, как matplotlib (2003) и IPython (2001), недавно Специалисты по анализу данных могут довольно быстро развернуть локальную среду разработки и легко получить в свое распоряжение множество инструментов. Многие первые специалисты по работе с данными пришли из академического мира и ранее привыкли к инструментам, ориентированным на записные книжки, таким как Mathematica и Maple, поэтому неудивительно, что выпуск IPython Notebooks в 2011 году (позже переименованный в Jupyter Notebooks в 2015 году) прошел с большой помпой ( Хотя в этой статье мы воспользуемся подходом, ориентированным на Python, стоит отметить, что RStudio также был выпущен в 2011 году). К этому времени управление пакетами Python и средой также стало проще благодаря Pypa (который поддерживает такие инструменты, как virtualenv и pip); а несколько лет спустя специалисты по данным получили более мощные инструменты моделирования с помощью XGBoost (2014), TensorFlow (2015) и PyTorch (2016). Для профессионалов в области данных Python все действительно стало на свои места.

Блокноты были и остаются одним из основных инструментов, которые специалисты по данным используют ежедневно. Любите их или ненавидите их, они закрепились в среде машинного обучения так, как никакая другая технология редактирования. Однако, какими бы замечательными они ни были, по мере того, как реальные компании начали внедрять ноутбуки в свои технологические стеки, они неизбежно обнаружили множество пробелов (этот список не является исчерпывающим), таких как:

  1. Совместное использование работы и сотрудничество с коллегами
  2. Создание допустимой среды для работы с чужой записной книжкой
  3. Получение доступа к нужной инфраструктуре для запуска кода
  4. Планирование записных книжек
  5. Обеспечение соблюдения стандартов кодирования

Высокотехнологичные компании, которые рано взяли на вооружение ноутбуки, вероятно, создали какое-то индивидуальное решение, которое решает указанные выше проблемы (а может быть, и другие!). В остальном начали появляться поставщики программного обеспечения, предлагающие инструменты «совместной обработки данных». Эти инструменты были созданы для специалистов по данным: они вращаются вокруг записных книжек и пытаются уменьшить трение при совместной работе и выполнении кода на уровне предприятия. Если мы вернемся к нашим исходным основным компонентам машинного обучения, эти инструменты полностью сосредоточены на коде и среде. Современные решения основаны на облаке и выполняются в контейнерах, что избавляет исследователей от еще большей сложности. Вообще говоря, они, как правило, хороши в том, что делают: предоставляют хорошую «песочницу» для разработки, которую специалисты по данным могут исследовать и сотрудничать.

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

  1. Отсутствие операционной модели. Делая платформу максимально универсальной и гибкой, становится сложнее автоматизировать общие задачи.
  2. Трудный путь к производству. Ноутбуки являются основным ресурсом для этой платформы, но, как известно, на них сложно полагаться при производственной работе, и они очень подвержены ошибкам.
  3. Ориентация на специалистов по данным. Подход, основанный на коде, отлично подходит для специалистов по данным, но это означает, что другие пользователи в вашей организации мало что получат от этого. Даже большинство людей, которым вы платите за код (разработчики программного обеспечения), вообще не любят ноутбуки.
  4. Поощряйте конвейерные джунгли: ручной характер платформы означает, что любая производственная работа потребует сложной обработки данных и конвейеров API, чтобы гарантировать, что все действительно работает.
  5. Более сложные задачи - это «упражнения, оставленные читателю»: разработка функций, хранилище функций, развертывание и мониторинг моделей - все это выполняется вручную или извне.

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

Поколение 2: точечные решения на основе моделей

Примерно в то время, когда лидеры в области науки о данных разочаровались в платформах на базе портативных компьютеров, созданных собственными силами или приобретенными поставщиками, многие люди начали говорить о рабочем процессе обработки данных или жизненном цикле разработки машинного обучения (MLDLC). Смысл в том, чтобы разработать структуру, подобную Жизненному циклу разработки программного обеспечения, которая является довольно стандартной для групп разработчиков программного обеспечения и помогает вести эту команду от разработки к производству. Такая вещь была / остро необходима в ML, чтобы помочь борющимся командам собрать части воедино, чтобы концептуализировать правильную стратегию производства ML.

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

К счастью, новые инструменты уже появлялись на рынке: инструменты AutoML и трекеры экспериментов для обучения модели, инструменты MLOps для развертывания и мониторинга моделей, объяснимые инструменты AI (XAI) для анализа моделей и инструменты конвейера для сквозной автоматизации. Интересно, что инструменты магазина функций по-настоящему начали появляться только в последние пару лет, но мы обсудим их больше в третьем поколении. В любом случае, с достаточной самоотдачей и смазкой для локтей (или наличными) вы можете скрыть все коробки в MLDLC и почувствуйте, что вы создали надежную платформу ML.

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

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

На первый взгляд, все эти модельные точечные решения выглядят великолепно. Соберите их всех, как покемонов, и вы завершили MLDLC.

Однако сборка точечных решений также не лишена подводных камней:

  1. Ад интеграции: для выполнения простого варианта использования ML-часть решения требует четырех или более различных инструментов. Удачи в устранении неполадок, когда что-то ломается.
  2. Джунгли конвейеров все еще существуют. И они, возможно, намного хуже, чем в первом поколении. Теперь у вас есть исходные конвейеры, идущие на платформу машинного обучения, а также несколько других между всеми вашими новыми инструментами.
  3. Изолировано от плоскости данных. Все эти инструменты ориентированы на модели и работают с моделями, а не с данными. Вам по-прежнему понадобится такой инструмент, как блокнот для совместной работы первого поколения, чтобы обрабатывать любую работу с данными, которую необходимо выполнить, поскольку они не предоставляют таких возможностей.
  4. Производство - это сложная сеть API / SDK Acrobatics. Реалистичный сценарий производства в Gen 2: написание сценария, который генерирует обучающие данные (возможно, записанные из записной книжки), передавая полученный Dataframe в вашу среду AutoML. через API или SDK, передав получившуюся модель в ваш инструмент MLOps через API или SDK, а затем запустив ее через вашу структуру XAI (если она у вас даже есть) для генерации аналитических данных. Как вы оцениваете новые данные? Точно так же напишите другой сценарий, который использует больше API. Запустите все это в чем-то вроде Airflow, или, может быть, ваша платформа Gen 1 имеет функцию планировщика.
  5. Более сложные задачи - это «упражнения, оставленные читателю»: разработка функций, магазин функций, сопоставление взаимосвязей сущностей и т. д. Вы все еще делаете приличный объем работы в другом месте.
  6. Требуется команда экспертов. Эти инструменты любят утверждать, что, поскольку они автоматизируют части процесса, они «демократизируют машинное обучение», чтобы облегчить любому человеку самообслуживание. Однако мне еще предстоит найти тот, который ставит на первое место бизнес-контекст и для работы не требуется команда K8s / облачных инженеров, инженеров по машинному обучению и специалистов по обработке данных.

Стоит отметить, что платформы Gen 2 уже эволюционировали: более известные поставщики либо разрабатывают новые продукты, либо приобретают стартапы для расширения предложений. Вместо того, чтобы покупать несколько точечных решений у нескольких поставщиков, вы можете купить их все у одного и того же поставщика, который удобно окрестили «Корпоративный ИИ». К сожалению, полученный результат не решает в достаточной мере ни одну из проблем, перечисленных выше, за исключением того, что возможно делает интеграцию менее болезненной (но это не само собой разумеющееся, будьте осторожны с покупателем). Основное преимущество заключается в том, что вы можете покупать все свои блестящие игрушки у одного и того же поставщика, и когда вы начинаете работать с технологией из коробки, вы быстро понимаете, что снова вернулись к исходной точке, пытаясь наладить собственный производственный процесс. среди продуктов, которые имеют мало общего, кроме названия бренда.

Не путайте это с подходом поколения 3. Должен быть способ получше.

Поколение 3: ИИ с приоритетом декларативных данных

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

К чести подходов Gen 1 и Gen 2, Gen 3 не существовало бы без них. И потому, что он основан на некоторых из разработанных ими концепций, и если бы люди не боролись с практической реализацией машинного обучения с помощью инструментов Gen 1 и Gen 2, это, вероятно, никогда бы не появилось. В основе подхода, ориентированного на данные, лежит идея о том, что ИИ достаточно продвинулся, чтобы вы могли просто предоставить набор обучающих данных для своей платформы вместе с небольшим объемом метаданных или конфигурацией, и платформа сможет для создания и развертывания вашего варианта использования в производственной среде за считанные часы. Никакого кодирования не требуется. Нет конвейерной обработки. Специалист по анализу данных не испытывает проблем с инструментами DevOps. Сделать этот рабочий процесс проще простого.

Как это возможно? Как я уже сказал, мы опираемся на множество концепций, которые уже обсуждали в этой статье. Есть три основных ингредиента:

  1. Магазин функций: зарегистрируйте свои особенности и отношения. Автоматизируйте проектирование функций. Сотрудничайте с коллегами, чтобы вам не приходилось воссоздавать колесо каждый раз, когда вам нужно преобразовать данные. Позвольте хранилищу функций выяснить, как использовать данные для обучения и вывода.
  2. Declarative AI Engine: повысьте уровень абстракции и автоматизируйте модели построения и создание прогнозов. Разрешите опытным пользователям настраивать работу с помощью конфигурации.
  3. Постоянные MLOps и XAI: осознайте, что мир не статичен. Автоматизируйте развертывание и продвижение модели. Автоматизируйте создание аналитических сведений о модели. Позвольте специалистам по обработке данных действовать в качестве привратников, которые рассматривают и одобряют работу, но перекладывают все остальное на автопилот.

Если вы хотите увидеть, как это выглядит на практике, вы можете попробовать декларативную платформу AI с приоритетом данных, которую мы создаем в Continual. Он находится на вершине вашего облачного хранилища данных и постоянно строит прогнозные модели, которые никогда не перестают учиться на ваших данных. Пользователи могут взаимодействовать с системой через CLI, SDK или UI, но производственное использование легко реализуется с помощью простых декларативных команд CLI.

Мы не единственные, кто думает об машинном обучении, ориентируясь на данные. Эта идея уже несколько лет обсуждается в компаниях FAANG, таких как Overton и Trinity от Apple и Ludwig от Uber. Недавняя статья Declarative Machine Learning Systems дает прекрасное резюме этих усилий. Эндрю Нг недавно использовал ИИ, ориентированный на данные, как и Андрей Карпати из Tesla. Мы ожидаем, что их ждет еще много. Мы также считаем, что декларативный ИИ, ориентированный на данные, является неотъемлемой частью современного стека данных, который обещает снизить сложность работы платформы данных в облаке.

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

  1. Надежный путь к производству: упростите производственное машинное обучение с помощью четко определенного рабочего процесса.
  2. Сквозная платформа: ускорьте окупаемость за счет сокращения задач интеграции и трубопроводов.
  3. Демократизация ИИ. Создайте настолько простую систему, чтобы ее могли использовать все профессионалы в области данных. Поручни позволяют специалистам по обработке данных контролировать процесс.
  4. Ускорение внедрения сценариев использования: настройте рабочие процессы за дни, а не недели или месяцы. Управляйте большим количеством забот, используя меньше ресурсов.
  5. Снижение затрат: покупайте меньше вещей и снижайте расходы на обслуживание.

Хотя мы полагаем, что платформы, ориентированные на данные, станут преобладающими платформами машинного обучения для повседневного ИИ, они не безграничны. Для действительно передовых исследований ИИ, вероятно, нет ничего, что могло бы обойти тот факт, что потребуется ручная работа. Возможно, это не будет большой проблемой за пределами самых технических компаний, но для таких случаев полезно иметь инструмент, ориентированный на разработку. Мы считаем, что платформа data-first отлично подходит для решения 95% известных проблем машинного обучения, а для остальных 5% может потребоваться дополнительная обработка данных. Тем не менее, мы думаем, что это грандиозное улучшение, позволяющее обрабатывать 95% ваших сценариев использования инженерами / аналитиками данных при некотором надзоре со стороны специалиста по данным, и позволяет группе специалистов по анализу данных больше сосредоточиться на 5% сложных проблем. Для этого им нужна звездная система, которая автоматизирует все и позволяет им управлять и поддерживать рабочий процесс с минимальным вмешательством: как правило, платформа, ориентированная на данные.

Какой инструмент подходит вашей команде?

В этой статье мы рассмотрели много вопросов и обсудили множество вариантов инструментов. Время от времени инструментарий машинного обучения и искусственного интеллекта может показаться подавляющим. Подход к ИИ, ориентированный на данные, разрушает многие предвзятые представления, и его сила лучше всего видна, чтобы поверить в это. В Continual мы твердо убеждены в том, что решения ML / AI следует оценивать на основе реальных сценариев использования. Со многими решениями это может занять недели или месяцы и разоблачить шумиху от реальности. Наша цель в Continual - предоставить вам возможность предоставить вам первые производственные сценарии использования за день. В этом заключается сила декларативного подхода к ИИ, ориентированного на данные, который изначально интегрируется с вашим облачным хранилищем данных. Если это звучит интригующе, мы предлагаем бесплатную 30-дневную пробную версию Continual, чтобы вы могли испытать ее на себе.