Как происходит процесс сопровождения: через git или вручную?
Что проверяют
Есть ли у вас инженерная дисциплина: можно ли по проекту восстановить, какой код, какие данные и какие параметры дали модель, которая сейчас в проде. Следом обычно спрашивают, где вы храните данные и артефакты модели, раз не в Git.
Как отвечать
Правильный ответ: через Git и автоматизацию, но Git хранит не всё.
- код и конфигурации: пайплайны, SQL, DAG Airflow, конфиги обучения, Dockerfile и lock-файл зависимостей (
poetry.lockилиuv.lock) лежат в Git и меняются через merge request с ревью; - данные и модели: крупные бинарные файлы в Git не кладут. Их версионируют через DVC (в Git лежат маленькие
.dvc-файлы с хэшами, сами данные в S3) или хранят в объектном хранилище с версионированием; - эксперименты: MLflow записывает параметры, метрики и артефакт каждого запуска. В Model Registry у модели есть версии, продовая помечается алиасом, а старые стадии Staging и Production в MLflow объявлены устаревшими;
- CI: на MR запускаются
ruff, тестыpytest, проверки данных через Great Expectations или pandera, иногда короткое обучение на срезе; - выкладка: модель попадает в прод через пайплайн, а не копированием файла на сервер.
Ручные шаги при этом остаются, и это нормально, если они осознанные: ручное одобрение перевода модели в прод после проверки метрик, разбор ошибок на отложенной выборке. Ненормально, когда код правят прямо на сервере или в ноутбуке, из которого потом никто не может повторить результат.
Если в вашей команде было именно так, скажите честно и расскажите, что вы поменяли или предложили бы поменять первым.
Где спотыкаются
Советуют класть в Git всё, включая датасеты. Репозиторий распухает и клонируется часами, для этого и придуманы DVC и Git LFS.
Коммитят Jupyter-ноутбуки вместе с выводом ячеек и потом не могут прочитать дифф. Помогают nbstripout или перенос логики из ноутбуков в модули.
Не могут ответить, на каких данных обучена текущая модель. Без версии датасета и зафиксированного seed любой инцидент с качеством превращается в гадание.