Совместимость (или нет?) MLOps-инструментов30.01.2024 14:16

Как и любой уважающий себя инженер, в детстве я любил конструкторы и всякого рода головоломки. Не растерял я эту любовь и сейчас, правда, на смену простеньким детским головоломкам пришли сложные программные системы. Как Lead Data Scientist я решил автоматизировать процессы в разработке для себя и своей команды. Изучил десяток различных MLOps-инструментов, дело оставалось за малым — соединить их в одну общую удобную систему. Вот только этот конструктор отказывался легко собираться…

Источник: «Идиократия»

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

С чего начать?

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

Для начала определимся, что является основой хорошего ML-процесса:

• грамотно выстроенный пайплайн;

• инструменты автоматизации, которые не противоречат особенностям задач.

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

• частое изменение шагов пайплайна;

• периодическое изменение структуры данных;

• широкий диапазон задач — от классики до CV.

Учитывая всё это, нужно было разработать легко модифицируемый пайплайн с гибкими инструментами для автоматизации процессов. При этом речь шла только об Open Source решениях: их никто не заблокирует, и они бесплатные.

Концептуальные подходы в построении пайплайна ML

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

• Центральный скрипт. Пайплайн организован через центральный скрипт (условный main.py), в котором происходят вызовы частей пайплайна в виде отдельных функций. Запуск пайплайна = запуск скрипта main.py.

• Раздельные скрипты. Шаги пайплайна — это отдельные скрипты, каждый из которых независим и выполняет только одно действие. Пайплайн организован через файл с описанием последовательности вызовов скриптов с указанием аргументов запуска. Запуск скрипта производится с помощью специального инструмента для менеджмента пайплайна, в базовом варианте можно организовать в виде sh-скрипта или через Makefile.

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

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

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

Второй вопрос, с которым нам предстоит столкнуться при разработке пайплайна: как мы планируем сохранять и разделять результаты различных запусков?

• Артефакты и результаты экспериментов хранятся локально в виде файлов (графики, метрики и т. п.) и доступны постоянно.

• Артефакты и результаты экспериментов хранятся удаленно и доступны через API.

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

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

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

Какие инструменты помогут организовать пайплайн?

Я не буду описывать в этой статье все существующие инструменты, остановлюсь на тех, что оказались наиболее удобными по моему опыту.

• Через центральный скрипт

  • Hydra — это, в первую очередь, инструмент для конфигурирования, но в задачах ML он заходит просто замечательно. При помощи Hydra оформляется main.py скрипт, который конфигурируется с помощью удобной структуры yaml-конфигов. Киллер-фичей Hydra является возможность производить запуск пайплайна, изменяя параметры запуска (как скрипта, так и самой конфигурации) на лету при помощи CLI. Вторая киллер-фича — организация локального хранения результатов и артефактов на выходе из пайплайна для различных запусков. Одного этого инструмента достаточно, чтобы организовать пайплайн через единый файл с локальным хранением артефактов.

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

• Через раздельные скрипты

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

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

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

Что выбрал я?

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

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

Как вы могли уже догадаться, я взял DVC в качестве основы пайплайна — он прекрасно ложится под вышеописанный подход. Вот только я не просто так расписывал особенности Hydra — этот инструмент мог сразу добавить в пайплайн конфигурирование и сильно упростить экспериментирование с подбором параметров пайплайна. \Если бы не одно «но»: DVC и Hydra — представители двух противоположных концепций в плане организации пайплайна, и их не получится совместить… Или получится?

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

Что делать, если вы хотите использовать пайплайны из DVC, а структуру хранения артефактов — из Hydra? А вот такой интеграции, к сожалению, не подвезли.

Получается, мы взяли два инструмента из разных миров и практически без потерь совместили их вместе, но это же противоречит заголовку — так в чем подвох? Во-первых, как уже было сказано выше, теряется возможность сохранять результаты эксперимента с помощью Hydra. Если вам не нравится то, как их хранит DVC, то выбора у вас нет. Ну, а во-вторых…

А как же трекер экспериментов?

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

У DVC есть CLI-команды для сравнения результатов разных экспериментов, но те, кто работали с DVC, отметят, что это не самый удобный инструмент. Кроме того, иногда нужен доступ не только к результатам и графикам, но и к промежуточным артефактам.

Кроме того, кто бы что не говорил, но UI при сравнении результатов, безусловно, упрощает работу. К сожалению, без трекера эксперимента в таком случае нам не обойтись. Какие инструменты тут могут помочь?

Есть два удобных open source решения:

• MLflow — классика в мире MLOps, проверенная годами, но, к сожалению, весьма ограниченная в функционале;

• ClearML — менее известный, но весьма впечатляющий инструмент, есть всё те же возможности, что и у MLflow, и даже больше. Но есть нюансы…

Пробуем MLflow?

Начнем сразу со спойлера: выбор пал не на MLflow, и вот почему: отсутствие авторизации в сервис — не очень-то удобно, когда команда больше трех человек, и в сервис может зайти чуть ли не любой желающий;

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

Но могли ли такие небольшие неудобства нас остановить? Конечно, нет, поэтому я не мог не попробовать свести DVC, Hydra и MLflow воедино. В итоге связать-то их удалось, но с некоторыми недостатками:

• Так как мы выбрали подход с раздельными скриптами, трекинг результатов приходится прописывать в каждом отдельном скрипте (шаге пайплайна). В результате одного запуска пайплайна в MLflow мы видим записи каждого отдельного шага.

• Ситуацию усложняет особенность DVC (из-за которой мы его, собственно, и выбрали) — при повторных запусках пайплайн перезапускается не с начала, а с изменившегося шага. Если мы внесли изменения в скрипт train, то шаги со сборкой датасета будут пропущены. После пары-тройки таких экспериментов становится проблематично понять, на основе каких данных вообще происходит обучение.

«Но в MLflow же есть nested run, который позволяет объединять эксперименты в группу!» — возразят знакомые с MLflow читатели. Вот только для создания nested run должен быть стартовый скрипт, который объявит начало nested run, а DVC не обязательно запускает пайплайн с самого начала, из-за чего вместо группированных экспериментов мы всё так же получим отдельные записи. Потанцевав с бубном, можно решить и эту проблему, но разве этого мы хотим от инструмента автоматизации?

А чем ClearML лучше?

Имея те же возможности, что и MLflow, в плане трекинга экспериментов, ClearML также имеет:

• авторизацию пользователей, что позволяет ограничить доступ к сервису;

• возможность создавать вложенную структуру экспериментов;

• возможность ссылаться на другие эксперименты, что решает проблему с поиском предыдущего шага пайплайна в случае ненормированного запуска DVC;

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

Но это только сравнение с MLflow, сам ClearML может куда больше:

• воспроизведение проведенного эксперимента через UI — ClearML запустит шаг пайплайна в докере и воспроизведет результаты с указанными при запуске параметрами, сама эта фишка может показаться бесполезной на первый взгляд, но перед запуском шага вы можете отредактировать параметры запуска, указав новые, тем самым запустив новый эксперимент на основе старого, а это уже полезно в случаях:

  • если после запуска эксперимента обнаружили ошибку в параметрах запуска или конфигурации пайплайна;

  • если после анализа результатов появилась новая гипотеза, которую можно проверить, поменяв пару параметров.

• ClearML имеет поддержку Hydra — удобно визуализируя структуру конфига и позволяя его редактировать для последующего перезапуска эксперимента с новыми настройками.

• Визуализация и запуск пайплайна целиком из интерфейса.

Именно эти фишки в конечном счете не оставили мне выбора — возможность «подкорректировать» эксперимент и запустить его заново прямо из интерфейса однозначно подкупает. А последний гвоздь в гроб MLflow забивает поддержка Hydra в ClearML. Вот они — те инструменты, которые отлично друг с другом работают из коробки, так ведь?

ClearML так не считает!

Источник: «Идиократия»

Вот только ни одна из этих фишек не собиралась работать в связке DVC+Hydra+ClearML:

• ClearML, конечно, поддерживает Hydra, но только если последний выступает в качестве основы пайплайна. Так как DVC использует только конфиги Hydra, не используя при этом остальной функционал, ClearML не может задетектить конфигурацию проекта. Поэтому нельзя менять параметры конфигурации для запуска эксперимента из ClearML.

• Визуализация и запуск пайплайна из интерфейса? Да, но только если он описан в центральном скрипте, а не с помощью DVC.

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

• При стыковке Hydra и DVC теряется возможность сохранять артефакты в структуре Hydra.

• MLflow и DVC — каждый шаг пайплайна отображается отдельно и засоряет эксперименты, а nested run не выйдет организовать из коробки.

• ClearML + Hydra + DVC — исчезает поддержка Hydra и главных особенностей ClearML.

• Может, проблема в DVC? Заменим DVC на Snakemake — пропадет поддержка Hydra в целом, а остальные проблемы никуда не уйдут.

• Проблема в концепции отдельных скриптов? С центральным скриптом всё бы работало?

  • Теряем особенность DVC — запуск с места изменения пайплайна.

  • Получаем недостатки централизованного подхода, что не годится для наших задач.

В чем причина?

Источник: «Идиократия»

Неужели разработчики популярных инструментов сознательно не хотят добавлять поддержку других полезных в автоматизации систем? Конечно, нет. DVC поддерживает Hydra, ClearML тоже поддерживает Hydra, но все вместе они не работают так, как задумано. Так в чем причина?

Основных причин, на мой взгляд, две:

• Разница в концепциях — ClearML, как и Hydra, построены вокруг концепции центрального скрипта, а DVC, в свою очередь, полностью про раздельные шаги пайплайна. Но при этом DVC вполне смогли интегрировать в свой концепт Hydra для поддержки конфигов, так почему ClearML не может состыковаться с DVC? Ответ во второй причине.

• Разработчики DVC и ClearML стремятся разработать не отдельные удобные инструменты, а полноценные ML-платформы. Iterative.ai (разработчики DVC) создают вокруг своей первоначальной разработки целую экосистему инструментов, среди которых есть и трекер экспериментов, который является аналогом ClearML, но при этом не является Open Source решением. В то время как ClearML — это по сути и есть ML-платформа, в которую входят и трекер экспериментов, и инструменты для построения пайплайнов, хранения моделей и так далее.

Неужели нет инструментов, которые работали бы друг с другом из коробки? Конечно, есть — платные платформы или только те инструменты, интеграция с которыми предусмотрена в ключевом для вас инструменте.

Резюмирую. Если вы хотите автоматизировать свой ML процесс, вы можете:

• Попытаться совместить инструменты своими силами, дописав пару велосипедов между ними, но тогда придется эти велосипеды поддерживать колдовством с выходом новых версий систем.

• Отказаться от части инструментов и использовать только экосистему центрального инструмента — тогда, возможно, вы будете ограничены теми концепциями, которые продвигает платформа.

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

Подборка инструментов и платформ

В последние годы появляется все больше инструментов для автоматизации ML-процессов. Если пять лет назад все использовали только MLflow и строили процессы вокруг него, то сейчас выбор инструментов для создания собственной экосистемы стал значительно шире. Я подготовил подборку инструментов, которые наиболее удобны в использовании, имеют хорошую документацию и активное комьюнити, что позволит вам с минимальными усилиями разобраться в них и применить в работе.

Я не стал упоминать в подборке классические инструменты в автоматизации процессов по типу Airflow, GitLab (CI/CD), всё это вы можете найти в DevOps-подборках или в нашем посте о классических инструментах. Но если у вас найдутся свои любимые инструменты, которые вы применяете в работе и которые я упустил в своей статье, буду рад почитать о них в комментариях.

Так что не так с конструктором?

Взяв изоленту и WD-40, инженер соединит что угодно. Конечно, как я и писал выше, пришлось отказаться от ряда фишек используемых систем. Автоматизация полного ML-процесса включает гораздо больше инструментов, чем те, что упомянуты в статье, так что пришлось столкнуться с многими «несостыковками» и вполне удачно их разрешить. Если вы задумываетесь над автоматизацией своего ML-процесса средствами Open Source решений, дерзайте, пусть ничто вас не остановит.

Антон Головко, Lead Data Scientist центра машинного обучения «Инфосистемы Джет».

© Habrahabr.ru