Настройка DVC для версионирования данных и моделей ML

DVC настройка: где ломается воспроизводимость моделей

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

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

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

DVC настройка закрывает именно этот разрыв: версионирование датасетов и конфигураций, привязка веса модели к конкретному снимку данных и предсказуемый повтор запуска. Ниже — как это устроено и где чаще всего ломается.

Что даёт версионирование данных и моделей в работе

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

Первый измеримый эффект — доля воспроизводимых запусков. Данные адресуются по хешу содержимого, а не по пути в файловой системе, поэтому один коммит даёт совпадающие метрики и на машине разработчика, и на сервере обучения. Разбор инцидента начинается с идентификатора версии, а не с опроса команды: расхождение между прогонами падает с «каждый второй» до единичных случаев.

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

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

Варианты хранения версий: сравнение подходов

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

Что учитываем при выборе

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

Настройка DVC по шагам: от аудита до передачи

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

1. Аудит текущего процесса. Разбираем, что уже лежит в Git, какие наборы данных и веса живут вне репозитория, как часто меняются и сколько занимают. Фиксируем узкие места: ручную передачу артефактов, потерянные промежуточные выборки, невоспроизводимые запуски обучения.
2. Схема версионирования. Определяем, что берём под контроль — сырые данные, промежуточные срезы, конфигурации обучения, веса моделей — и по каким правилам версия данных связывается с коммитом и меткой.
3. Подключение хранилища. Настраиваем удалённое хранилище, разграничиваем доступ по ролям, включаем локальный кэш, чтобы повторные выгрузки не гоняли одни и те же файлы, и задаём политику хранения старых версий.
4. Описание воспроизводимых шагов. Шаги подготовки данных и обучения описываются декларативно: любой прошлый эксперимент поднимается одной командой, а не восстановлением по памяти.
5. Автоматизация проверок. Контрольные суммы сигналят об изменении данных, а в непрерывной интеграции настраиваем сборку и сравнение метрик: просевший результат не проходит в основную ветку.
6. Передача команде. Отдаём регламент, инструкции под реальные сценарии и ответственного за хранилище. После этого команда сама версионирует данные и откатывается на нужную версию без внешней поддержки.

Что заказчик получает на руки: конфигурации и регламенты

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

• Файлы конфигурации конвейера: описание этапов подготовки данных, обучения и оценки — повтор эксперимента запускается одной командой, а не собирается вручную.
• Схемы хранения: карта, где лежат датасеты, метрики и веса моделей, что версионируется, а что восстанавливается из кэша.
• Настройки хранилищ: подключение удалённого хранилища и кэша, разбиение путей по датасетам и версиям, правила вытеснения устаревших объектов.
• Политики доступа: роли инженеров, аналитиков и подрядчиков, разделение прав на чтение и запись, порядок выдачи и отзыва ключей.
• Регламент работы с версиями: когда заводится ветка эксперимента, как модель переводится в промышленную эксплуатацию и как выполняется откат.
• Документация: структура репозитория, инструкции по подключению нового участника и по восстановлению рабочей среды с нуля.
• Чек-лист приёмки: сценарии, которые прогоняем при передаче, — воспроизведение обучения, откат версии, выдача доступа новому инженеру.

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

Кейс: сократили время воспроизведения результатов

Что было до

Проект — обучение моделей на данных, которые обновляются каждую неделю. Десятки экспериментов жили «как получилось»: выборки на диске, веса рядом с кодом, параметры запуска — в заметках исполнителя.

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

Что изменилось

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

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

Чем версионирование данных отличается от версионирования кода?

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

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

Для данных в репозиторий уходят файлы-указатели с контрольной суммой, а сами наборы и веса — в объектное хранилище; так устроена настройка DVC. Совпадение версий проверяется по контрольной сумме: одинаковый набор даёт одинаковый идентификатор, а откат к нужной комбинации данных и модели выполняется одной командой синхронизации.

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

Технические сомнения: объёмы, хранилища, права доступа

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

Ниже — ответы на то, что чаще всего уточняют до старта работ. Если вашего случая в списке нет, разберём отдельно.

Как разграничить доступ к данным и моделям?

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

У нас уже развёрнуто версионирование и свой процесс обучения. Ломать придётся?

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

Обсудим задачу: с чего начать версионирование

Чтобы вернуться с оценкой объёма и планом работ, нам нужно обсудить задачу предметно — по вашему текущему процессу работы с данными и моделями. Часть ответов можно дать приблизительно, остальное уточним сами при разборе репозитория и хранилищ.

• Где сейчас лежат данные и модели: локальные диски, сетевые каталоги, объектное хранилище — и какой объём с темпом прироста в месяц.
• Что считается артефактом: веса моделей, метрики обучения, конфигурации, подготовленные выборки — и какие из них нужны в продакшене.
• Сколько инженеров работают с одним набором данных и нужны ли разграничение прав и правила ревью изменений.
• Как устроен текущий цикл обучения: скрипты, ноутбуки, оркестратор, ручные шаги — где версионирование встанет, а что придётся переписать.
• Требования к хранилищу артефактов: внешний контур или внутренний, политика хранения и удаления, доступ из внешней сети.
• Что уже есть из инфраструктуры: репозиторий с историей изменений, сервер сборки, где запускаются обучения.

Из этих ответов складывается порядок старта: аудит текущего хранения, схема ветвления и тегов, настройка удалённого хранилища, перенос существующих наборов, регламент работы для команды. Это и есть входные данные проекта — без них оценка объёма будет приблизительной. Опишите задачу в удобном виде, и мы вернёмся с оценкой и планом работ.