Как я организую структуру своих ML-проектов

Максим Поляков

Machine Learning Engineer в DataArt 

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

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

Обзор подходов

В большинстве курсов по DS или ML рекомендуется использовать Jupyter Notebook, который чаще всего устанавливается вместе с пакетом Anaconda. Он также популярен как подход к ML-соревнованиям, например, на Kaggle. Этот инструмент действительно удобен для просмотра, визуализации и построения моделей, когда это нужно сделать в сжатые сроки. Но для проектов, над которыми работают команды, а не один разработчик, или длительность которых больше месяца, у такого подхода есть серьезные недостатки:

• невозможность отслеживания изменений в репозиториях (GitHub, GitLab);
• трудности при работе нескольких людей с одним и тем же Jupyter Notebook;
• сложность воспроизведения экспериментов;
• отсутствие возможности загрузить код как исполняемый на сервер.

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

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

• Microsoft (Microsoft Azure).
• Amazon (Amazon Web Services).
• Google (Google Cloud Platform).
• Yandex (Yandex Cloud).

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

Предположим, что проект не обладает достаточными ресурсами, для использования облачных архитектур, либо в силу конфиденциальных данных не имеет права их использовать. Для таких случаев существуют библиотеки, позволяющие построить ML-проект автоматизировано:

• Ocean.
• Cookiecutter Data Science.
• Catalyst.

У каждой найдутся недостатки. Например, Catalyst работает только с библиотекой PyTorch, а другие более универсальны, но Ocean или Cookiecutter Data Science чаще всего оказываются слишком перегружены лишним для проекта, такое больше количество папок просто не используется и висит мертвым грузом. Можно построить и свою структуру, но требуется учесть все особенности цикла разработки DS- или ML-разработки: возможность воспроизвести результаты разработки, сохранение метрик экспериментов, логирование обучения модели.

Мой подход

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

Корневая папка

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

• train.py— код для чтения параметров и путей из конфигурационного файла, обучение модели с последующей ее сериализацией и сохранением логов;
• predict.py —код для загрузки модели, расчета метрик на данных и их сохранение;
• preprocess.py— код для препроцессинга и разбиения датасета, если этого требует задача.

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

Структура проекта

Директория notebooks хранит Jupyter Notebook для удобной визуализации данных или других манипуляций с данными, которые удобнее делать в интерактивном режиме.

В папке data будут находиться все данные для экспериментов: исходные, обработанные, с добавлением новых признаков и т. д. Иногда для удобства в ней создаются подпапки, например, с датами получения данных. Либо исходные данные помещаются в папку source, а подготовленные для входа в модель — processed.

Experiments — директория с экспериментами. Для любого изменения в модели, даже одного гиперпараметра, необходимо создавать новую подпапку эксперимента. Каждая подпапка с экспериментом содержит:

• config.yaml — конфигурационный файл. Может быть в любом структурированном формате, например, JSON или XML, содержит все данные для запуска эксперимента: путь до использованного датасета, гиперпараметры модели, тип обучаемой модели, название и путь для сохранения обученной модели и логов, любые другие параметры для запуска кода;
• trained_model— обученная модель машинного обучения;
• metrics.yaml— как и конфигурационный файл, может быть в любом структурированном виде, удобном для команды проекта, хранит метрики модели на путь до датасетов, на которых они были получены, и путь до модели, с помощью которой выполнялись предсказания.
• logs.md— логи, записанные в процессе обучения модели.

Requirements.txt — список библиотек и фреймворков, которые необходимо установить для запуска проекта.

Example_config.yaml — пример конфигурационного файла для запуска проекта. Нужен для понимания командой, какие поля, типы данных в них и какую структуру должен иметь файл для успешного запуска проекта.

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

Readme.md — описание структуры проекта, используемого окружения и информации, как запустить код и увидеть результаты.

К проекту также можно добавить файлы: для работы с git-репозиториями, например .gitignore, makefile — разные, например для проверки кодстайла.

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