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

Текущий подход

Вот как один проект TR Labs структурировал свой код в отдельных репозиториях GitHub:

  • Эксперименты. Содержит все эксперименты, испытания и записные книжки, над которыми работали исследователи, чтобы обучить/разработать наилучшую модель для задачи.
  • Переобучение моделей —содержит код для создания конвейера обучения в SageMaker для переобучения моделей.
  • Вывод. Включает код, сканирование, тесты и конвейеры CICD, которые необходимы для упаковки и развертывания модели в виде образа докера в ECR, прежде чем ее смогут использовать команды разработчиков приложений.

Однако этот процесс создает несколько пробелов, когда речь идет о ремонтопригодности проекта.

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

Инструменты

У TRLabs есть инструменты, которые обеспечивают поддержку AWS и Sagemaker. MLTools-CLI — это инструмент, представляющий собой оболочку экспериментов Sagemaker AWS, который помогает генерировать шаблонный код для обучения и обработки заданий. Инструмент также помогает структурировать проекты и изолировать среду для отдельных экспериментов.

Шаблон пакета Python. Для настройки наших проектов Python мы используем шаблон для формовки печенья Python. Он устанавливает структуру каталогов (разделение проблем), а также средства автоматизации кода, такие как стиль, тип и другие проверки перед фиксацией.

MLTools-CLI. Во время исследовательской работы по конкретному проекту обычно проводится несколько экспериментов и испытаний в блокнотах Jupyter. Это затрудняет последующую изоляцию кода для конкретного эксперимента/испытания. MLTools-CLI обеспечивает создание шаблонов кода, которые помогают организовывать эксперименты и испытания в свои собственные папки, которые сопоставляются с соответствующими местоположениями на S3. Он также поощряет написание сценариев для обучения и обработки заданий путем создания стандартного кода. На основе сценариев инструмент также может генерировать конвейер переобучения модели Sagemaker.

Подход монорепо

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

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

Первым шагом было посмотреть, можно ли объединить репозитории Experimentation и Model Re-training с помощью экспериментов Sagemaker. Использование MLTools-CLI (см. Инструменты) сделало это возможным. Как только эксперименты и следы организованы в сценарии и определенная структура папок с помощью инструмента, можно легко создать конвейер переобучения модели в Sagemaker. Инструмент предоставляет функциональные возможности для создания конвейера повторного обучения модели путем ссылки на один или несколько сценариев, используемых для предварительной обработки, обучения, оценки и/или вывода модели.

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

Предлагаемая структура проекта

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

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

Все исследовательские эксперименты и код содержатся в папке «research». Этот уровень также создается с использованием шаблона пакета Python. Файлы на этом уровне не проходят проверку качества, так как они не развернуты в рабочей среде. Он содержит папку экспериментов, в которой каждый эксперимент представляет собой собственную виртуальную среду. Инструмент MLTools-CLI (см. раздел инструментов) помогает в создании этой структуры.

Перенос репозитория экспериментов исследователей с историей

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

Предпосылки

  1. Установите git-filter-repo (см. предупреждения об использовании git filter-branch:
pip3 install git-filter-repo

Шаги

Чтобы импортировать source_repo/sub/dir в target_repo/sub/dir:

  1. Клонируйте нужную ветку исходного репо на локальную
git clone {source_repo URL} source_repo_clone --no-local --branch main 
cd source_repo_clone

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

git remote rm origin

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

git filter-repo --path sub/dir --force

Чтобы импортировать весь исходный репозиторий, используйте вместо этого этот фильтр

git filter-repo --to-subdirectory-filter {destination dir} --force

4. Слияние с целевым репо

cd ../target_repo 

git remote add source_repo ../source_repo_clone/ 

git fetch source_repo main 

git merge remotes/source_repo/main --allow-unrelated-histories 

git remote remove source_repo

Стратегия ветвления

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

Ветви, выделенные зеленым и желтым цветом (показаны выше), принадлежат команде инженеров. Ветки, выделенные красным цветом, принадлежат исследователям.

Инженер в монорепозитории работает только в следующих 3 ветках

  • Основная ветка — используется для выпусков новых версий решения Реестра моделей ИИ.
  • Ветвь разработки — используется для непрерывной интеграции из веток функций для создания и развертывания образа Docker, содержащего упакованную модель, в реестр Labs ECR.
  • Ветка(и) функций — одна или несколько веток функций, созданных из ветки «разработка».

Исследователи обычно работают с двумя ветвями, как описано ниже:

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

Предлагаемый рабочий процесс

Инженеры работают только на корневом уровне проекта и фиксируют папки на корневом уровне и любые папки в src. С другой стороны, исследователи работают только в папке research и используют MLTools-CLI (см. инструменты) для создания и отслеживания экспериментов. Исследователи работают с веткой experiments, которая всегда синхронизируется с веткой develop. Исследователи создают новые ветки функций на основе ветки experiments и после завершения объединяют ее обратно в ветку experiments.

Когда конкретный эксперимент будет готов к переносу в ветки develop и main, инженер создаст новый PR. из ветки эксперименты. Если какой-либо код необходимо извлечь в общую папку в src, инженер выполняет рефакторинг перед объединением PR в develop ветвь. Когда приходит время выпуска артефакта модели, инженер создает PR из ветки develop в main филиал.

Заключение

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

Кроме того, хранение общего кода, совместно используемого исследователями и инженерами в одном и том же репозитории, позволяет сократить количество пакетов, которые необходимо собрать, а также избежать необходимости иметь несколько лицензий для данного проекта (для сканирования образов безопасности/докеров). .

За и против