Проекты машинного обучения часто сложнее, чем они должны быть. Мы имеем дело с данными и программным обеспечением, и это должно быть простой вопрос запуска кода, итерации через некоторые изменения алгоритма, и через некоторое время у нас есть идеально подготовленная модель ИИ. Но перенесемся через три месяца, учебные данные могли быть изменены или удалены, и понимание тренировочных сценариев может быть смутным воспоминанием о том, что делает что. Создали ли вы разрыв между обученной моделью и процессом для создания модели? Как вы делитесь работой с коллегами для сотрудничества или копирования ваших результатов?
Как и для программных проектов в целом, необходимо лучше управлять кодовыми версиями и активами проекта. Возможно, потребуется вернуться к состоянию проекта, как это было на любом этапе в прошлом. Мы делаем это (обзор старых коммитов) в разработке программного обеспечения все время. Разве проект машинного обучения также не должно иногда делать то же самое? Это даже больше, чем это. Как насчет эквивалента запроса на притяжение или других видов практик управления командой, обычно используемых в других областях?
Я только начинаю свое путешествие, чтобы узнать о инструментах машинного обучения. Среди учебных материалов я смотрю учебные видеоролики, и инструкторы иногда говорят о проблемах, напоминающих мне период в начале моей карьеры по разработке программного обеспечения. Например, в 1993-4 я был ведущим инженером команды, разрабатывающей пользовательский агент электронной почты. У нас не было системы управления исходным кодом (SCM). Каждый день я консультировался со всеми другими членами команды, чтобы увидеть, какие изменения они внесли в тот день. Единственным инструментом, который у меня был, было запустить различие между их деревом источника и деревом мастера -исходного дерева (с использованием diff -c | mess ), а затем вручную применить изменения. Позже члены команды вручную обновили свое исходное дерево с дерева мастер -источника. Это был беспорядок, пока мы не нашли раннюю систему SCM (CVS). Этот один инструмент заставил проект работать гораздо более плавно.
Когда я изучаю инструменты, используемые в проектах машинного обучения и науки о данных, истории кажутся похожими на это. Даже сегодня исследователи ML иногда хранят эксперименты (данные, код и т. Д.) В структурах параллельных каталогов, чтобы облегчить различие, как я это делал в 1993 году.
Давайте начнем с краткого обзора некоторых принципов, которые могут быть полезны для улучшения состояния инструментов управления программным обеспечением для проектов машинного обучения.
В любом проекте машинного обучения ученый проведет много экспериментов для разработки наилучшей подготовленной модели для целевого сценария. Эксперименты содержат:
- Код и конфигурация : Программное обеспечение, используемое в эксперименте, наряду с параметрами конфигурации
- Набор данных : Любые используемые входные данные – это может легко быть много гигабайт в размерах, таких как проекты для распознавания содержания аудио, изображений или видеофайлов.
- Выходы : Обученная модель ML и любые другие выходы из эксперимента
Проект машинного обучения просто запускает программное обеспечение. Но часто возникают трудности в обмене файлами с коллегами или воспроизведением результатов. Получение повторяемых результатов, которые можно поделиться с коллегами, и куда вы можете вернуться назад, чтобы оценить более ранние этапы проекта, требует более полных инструментов управления.
Решение должно охватить подобные идеи (абстрактно от разговора Патрика Болла под названием Принципиальная обработка данных ):
Прозрачность : Осмотр каждого аспекта проекта ML.
- Какой код, конфигурация и файлы данных используются
- Какие шаги обработки используются в проекте и порядок шагов
Аудит : Осмотр промежуточных результатов трубопровода
- Глядя на оба конечного результата, но Любые промежуточные результаты
Воспроизводимость : Способность пересматривать именно проект на любой стадии его разработки и способность коллег в пересмотр
- Запись этапов обработки так, что они автоматически пересекаются любым
- Запись состояния проекта по мере продвижения проекта. «Состояние» означает код, конфигурацию и наборы данных
- Возможность воссоздания точных наборов данных, доступных в любое время в истории проекта, имеет решающее значение для проверки, чтобы быть полезным
- Масштабируемость : Способность поддерживать несколько коллег, работающих над проектом, и способность работать над несколькими проектами одновременно
Что отличает проекты ML от обычной разработки программного обеспечения?
Вы уже пришли к выводу, что если проекты ML такие же, как программное обеспечение, то почему бы нам просто не использовать регулярные инструменты разработки программного обеспечения в проектах машинного обучения? Не так быстро!
Есть много инструментов, используемых в регулярных проектах по разработке программного обеспечения, которые могут быть полезны для исследователей ML. Конфигурация кода и эксперимента может быть легко управляется в обычной системе управления исходным кодом, такой как GIT, и такие методы, как запросы на привлечение, можно использовать для управления обновлениями в эти файлы. Системы CI/CD (Jenkins и т. Д.) Могут быть даже полезны при автоматизации прогонов проектов.
Но проекты ML имеют различия, предотвращая регулярные инструменты разработчика программного обеспечения от удовлетворения всех потребностей. Вот несколько вещей:
- Разработка, управляемая метриками, по сравнению с функциональными разработками : В регулярной разработке программного обеспечения «решать» решения основаны на том, достигла ли команда этапы. Напротив, исследователи ML рассматривают совершенно другое измерение – прогнозирующую ценность модели генерируемого машинного обучения. Исследователь итеративно генерирует десятки (или более) модели, измеряя точность каждого. Проект руководствуется метриками, достигнутыми в каждом эксперименте, поскольку цель состоит в том, чтобы найти наиболее точную модель.
- Модели ML требуют огромных ресурсов для обучения : Где регулярный программный проект организует файлы для составления программного продукта, проект ML вместо этого обучает «модель», которая описывает алгоритм ИИ. В большинстве случаев компиляция программного продукта занимает несколько минут, что настолько дешево, что многие команды следуют стратегии непрерывной интеграции. Обучение модели ML занимает так много времени, что желательно избежать этого, если это необходимо.
- Огромные наборы данных и обученные модели : Обобщение предыдущего пункта заключается в том, что фазы разработки машинного обучения почти всегда требуют огромных наборов данных, которые используются при обучении модели ML, плюс обученные модели могут быть огромными. Обычные инструменты управления исходным кодом (GIT et al) не очень хорошо обрабатывают большие файлы, и такие дополнения, как GIT-LF, не подходят для проектов ML. (См. моя предыдущая статья )
- Трубопроводы : Проекты ML – это серия этапов, таких как загрузка данных, подготовка данных, разделение данных на наборы обучения/валидации, обучение модели и проверка модели. Многие используют слово «трубопровод», и полезно структурировать проект ML с дискретными командами для каждого шага по сравнению с втиранием всего в одну программу.
- Специальное оборудование : Программные организации могут размещать свою программную инфраструктуру на любом виде серверного оборудования. Если они хотят развертывания облака, они могут арендовать каждый день обычные VPS от своего любимого поставщика облачных вычислений. У исследователей ML есть огромные потребности в вычислении. Мощные графические процессоры не только ускоряют редактирование видео, но и могут заставить алгоритмы ML летать, сокращая время, необходимое для обучения моделей ML.
Что, если этот промежуточный результат был получен три месяца назад, и все изменилось, так что вы не помните, как программное обеспечение запускалось в то время? Что если набор данных был перезаписан или изменен? Система, поддерживающая прозрачность, аудит и воспроизводимость для проекта ML, должна учитывать все эти вещи.
Теперь, когда у нас есть список принципов, давайте посмотрим на некоторые инструменты с открытым исходным кодом в этом контексте.
Существует большое количество инструментов, которые могут быть подходящими для практиков по науке о данных и машинного обучения. В следующих разделах мы специально обсуждаем два инструмента ( mlflow и dvc ), а также говорим об общих принципах.
Одна сторона этого обсуждения сводится к:
- Отслеживание, какие файлы данных использовались для каждого раунда моделей обучения машинного обучения.
- Отслеживание, получая обученные модели и показатели оценки
- Простой метод обмена файлами данных с коллегами через любую форму системы обмена файлами.
Система отслеживания данных необходима для прозрачного аудита или для воспроизведения результатов. Система совместного использования данных, необходимая для масштабирования команды проекта до нескольких коллег.
Это может быть уже очевидно, но нецелесообразно использовать GIT или другой SCM (система управления исходным кодом) для хранения файлов данных, используемых в проекте машинного обучения. Было бы привлекательно, если бы SCM хранение кода и файлов конфигурации также мог бы сохранить файлы данных. Git-LFS тоже не является хорошим решением. Моя предыдущая статья, Почему GIT и GIT-LFS недостаточно, чтобы решить кризис воспроизводимости машинного обучения , рассмотрел некоторые подробности о рассуждениях.
Некоторые библиотеки предоставляют API для упрощения работы с файлами на удаленном хранилище и управления загрузкой файлов в удаленное хранилище или из удаленного хранилища. Хотя это может быть полезно для общего доступа к удаленному набору данных, это не помогает с описанной здесь проблемой. Во -первых, это форма встроенной конфигурации, поскольку имена файлов запекаются в программное обеспечение. Любая программа, в которой настройки конфигурации встроены в исходный код, труднее повторно использовать в других обстоятельствах. Во -вторых, он не корреляет, какой файл данных использовался для каждой версии сценариев.
Рассмотрим пример кода для Mlflow:
mlflow.pytorch.load_model("runs://run-relative/path/to/model")
Это поддерживает несколько альтернативных «схем доступа к файлу», включая системы облачного хранения, такие как S3. Пример здесь загружает файл, в данном случае обученную модель, из области «запустить». Mlflow «запуск» генерируется каждый раз, когда вы выполняете «кусок кода науки о данных». Вы настраиваете местоположение, где хранятся данные «запуска», и, очевидно, для каждого запуска генерируется «идентификатор запуска», который используется для индексации в область хранения данных.
Это выглядит полезным, поскольку он автоматически связывает данные с коммитами с кодом хранения репозитория SCM и файлов конфигурации. Кроме того, поскольку API MLFLOW доступен для нескольких языков, вы не ограничитесь Python.
DVC имеет другой подход. Вместо интеграции API файла в ваши сценарии ML ваши скрипты просто вводят и выводится файлы, используя нормальные API-интерфейсы файловой системы. Например:
model = torch.load('path/to/model.pkl')
В идеале это имя будет передано из командной строки. Дело в том, что от кода не требуется ничего особенного, поскольку DVC предоставляет свою ценность вне контекста кода, используемого в обучении или проверке моделей.
DVC делает это прозрачным, потому что управление версией файла данных в сочетании с GIT. Файл или каталог принимается под управлением DVC с помощью команды:
$ dvc add path/to/model.pkl
Данные хранятся в естественном месте, в вашем рабочем каталоге. Навигация по результатам различных прогонов – это простой вопрос навигации по вашей истории GIT. Просмотр конкретного результата так же просто, как бег GIT Checkout и DVC будет вызван, чтобы убедиться, что правильные файлы данных связаны в рабочее пространство.
«Файл DVC» создается для отслеживания каждого файла или каталога и вставлена в рабочее пространство с помощью DVC. У них есть две цели, одной из которых является отслеживание данных и файлов моделей, а другая записывает команды рабочего процесса, которые мы рассмотрим в следующем разделе.
Эти файлы DVC записывают контрольные суммы MD5 файлов или отслеживаемых каталогов. Они привержены рабочее пространство GIT, и поэтому файлы DVC записывают контрольную сумму каждого файла в рабочем пространстве для каждого коммита GIT. За кулисами DVC использует то, что называется «каталог кэша DVC» для хранения нескольких экземпляров каждого файла. Экземпляры индексируются с помощью контрольной суммы и связаны в рабочее пространство с использованием обратков или символов. Когда DVC отвечает на GIT Checkout Работа, она способна быстро переставлять связанные файлы в рабочем пространстве на основе контрольной суммы, записанных в файлах DVC.
DVC поддерживает удаленный каталог кэша, который используется для обмена данными и моделями с другими.
$ dvc remote add remote1 ssh://user@host.name/path/to/dir $ dvc push $ dvc pull
Дистанционное управление DVC – это пул хранения, через который можно обмениваться данными. Он поддерживает многие услуги хранения, включая S3 и другие услуги, HTTP и FTP. Создать один очень просто. DVC Push и DVC Pull Команды намеренно похожи на git push и git тянутся команды Там, где DVC Push отправляет данные в удаленный кеш DVC, мы получаем данные из DVC Cache, используя DVC Pull Анкет
Другая сторона обсуждения – это то, как лучше всего описать рабочий процесс или трубопровод, используемый в проекте ML. Мы зачитываем все это в одну программу? Или мы используем несколько инструментов?
Самая большая гибкость заключается в реализации рабочего процесса в качестве трубопровода или направленного ациклического графика многократных команд, которые принимают параметры конфигурации в качестве аргументов командной строки. Это намеренно похоже на философию UNIX небольших четко определенных инструментов, с узким объемом, которые хорошо работают вместе, где поведение адаптировано вариантами командной строки или переменными среды, и это может быть смешано и сопоставлено по мере необходимости. За этой философией стоит длинная коллективная история.
Напротив, многие из фреймворков ML используют другой подход, в котором записана одна программа для управления рабочим процессом, используемым конкретным проектом. Единственная программа может начаться с шага разделения данных на наборы обучения и проверки, а затем пройти через обучение модели и запустить проверку модели. Это дает нам ограниченный шанс повторно использовать код в других проектах.
Структурирование проекта ML в качестве трубопровода служит некоторым преимуществам.
- Управление сложностью : Внедрение шагов в качестве отдельных команд улучшает прозрачность и позволяет сосредоточиться
- Оптимизировать выполнение : Способность пропустить шаги, которые не нужно повторять, если файлы не изменились.
- Повторно использование : Возможность использования одного и того же инструмента между несколькими проектами.
- Масштабируемость : Различные инструменты могут быть независимо разработаны разными членами команды.
В Mlflow Framework вы пишете «программу драйверов». Эта программа содержит любую требуемую логику, такую как обработка и создание модели машинного обучения. За кулисами API MLFLOW отправляет запросы на сервер MLFLOW, который затем порождает указанные команды.
Пример Mlflow для Многоэтапный рабочий процесс делает это ясным Анкет А именно:
...
load_raw_data_run = _get_or_run("load_raw_data", {}, git_commit)
ratings_csv_uri = os.path.join(load_raw_data_run.info.artifact_uri,
"ratings-csv-dir")
etl_data_run = _get_or_run("etl_data",
{"ratings_csv": ratings_csv_uri,
"max_row_limit": max_row_limit},
git_commit)
…
als_run = _get_or_run("als",
{"ratings_data": ratings_parquet_uri,
"max_iter": str(als_max_iter)},
git_commit)
…
_get_or_run("train_keras", keras_params, git_commit, use_cache=False)
...
_get_or_run Функция – это простая обертка вокруг mlflow.run Анкет Первым аргументом каждого является intrypoint Определено в MlProject файл. Точка входа содержит настройки среды, команду для запуска и параметры, чтобы передать эту команду. Например:
etl_data:
parameters:
ratings_csv: path
max_row_limit: {type: int, default: 100000}
command: "python etl_data.py --ratings-csv {ratings_csv} --max-row-limit {max_row_limit}"
Сначала это кажется очень хорошим. Но вот несколько вопросов, чтобы обдумать:
- Что если ваш рабочий процесс должен быть более сложным, чем прямая линия? Вы передаете false к синхронному параметру Mlflow.run, затем ждите объекта RequartedRun, чтобы указать выполненную задачу. Другими словами, можно построить систему управления процессами на вершине API MLFLOW.
- Почему требуется сервер? Почему бы просто не запустить команды в командной строке? Требование, чтобы сервер был настроен, делает настройку проекта MLFLOW более сложной.
- Как избежать выполнения задачи, которая не нужно выполнять? Во многих проектах ML требуются дни, чтобы обучить модель. Эта стоимость ресурса должна быть потрачена только в случае необходимости, например, изменение данных, измененные параметры или измененные алгоритмы.
DVC имеет подход, который работает с регулярными инструментами командной строки, но не требует настройки сервера и не записывает программу драйверов. DVC поддерживает определение рабочего процесса как направленный ациклический график (DAG) с использованием набора файлов DVC, упомянутых ранее.
Мы упомянули файлы DVC ранее как связанные с файлами, добавленными в рабочую область. Файлы DVC также описывают команды для выполнения, например:
$ dvc run -d matrix-train.p -d train_model.py \
-o model.p \
python train_model.py matrix-train.p 20180226 model.p
$ dvc run -d parsingxml.R -d Posts.xml \
-o Posts.csv \
Rscript parsingxml.R Posts.xml Posts.csv
Команда DVC Run определяет файл DVC, который описывает команду для выполнения. -Д Опция документирует зависимость от файла, в котором DVC будет отслеживать свою контрольную сумму для обнаружения изменений в файле. -o Опция является выводом из команды. Выходы одной команды, конечно, можно использовать в качестве входов в другую команду. Посмотрев на зависимости и выходы DVC могут рассчитать порядок выполнения для команд.
Все выходы, включая обученные модели, автоматически отслеживаются в кэше DVC, как и любой другой файл данных в рабочем пространстве.
Поскольку он вычисляет контрольную сумму, DVC может обнаружить измененные файлы. Когда пользователь запрашивает DVC для повторного использования конвейера, он выполняет только этапы, где есть изменения. DVC может пропустить вашу трехдневную учебную задачу модели, если ни один из его входных файлов не изменился.
Все выполняется в обычной командной строке, нет сервера для настройки. Если вы хотите, чтобы это было выполнено в среде облачных вычислений или на сервере с прикрепленными графическими процессорами, просто разверните код и данные на этом сервере и выполните команды DVC на командной строке на этом сервере.
Мы прошли долгий путь с этим исследованием некоторых принципов улучшенных методов машинного обучения. Поле ML, как многие признают, нуждаются в лучших инструментах управления, чтобы команды ML могли работать более эффективно и надежно.
Способность воспроизводить результаты означает, что другие могут оценить то, что вы сделали, или сотрудничать в дальнейшем развитии. Воспроизводимость имеет много предпосылок, включая возможность изучать каждую часть системы и возможность точно повторить программное обеспечение и входные данные.
Некоторые из инструментов, используемых в проектах машинного обучения, имеют хорошие красивые пользовательские интерфейсы, такие как Notebook Jupyter. Такие инструменты занимают свое место в работе машинного обучения. Однако инструменты с графическим интерфейсом не вписываются в принципы, обсуждаемые в этой статье. Инструменты командной строки хорошо подходят для обработки задач, работающих в фоновом режиме, и могут легко удовлетворить все принципы, которые мы наметим, в то время как типичный графический интерфейс мешает большинству этих принципов.
Как мы видели в этой статье, некоторые инструменты и практики могут быть заимствованы из регулярной разработки программного обеспечения. Тем не менее, потребности проектов машинного обучения диктуют инструменты, которые лучше соответствуют цели. Несколько достойных инструментов включают Mlflow , DVC , Modeldb и даже Git-lfs (Несмотря на то, что мы сказали ранее об этом).
Оригинал: “https://dev.to/robogeek/principled-machine-learning-4eho”