Налаштування DVC для версіонування даних і моделей ML

DVC налаштування: де ламається відтворюваність моделей

Показова картина: модель показує добру якість на перевірці, її викочують, а за місяць той самий результат уже не повторюється.

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

Причина не в моделі, а в тім, що код і дані живуть за різними правилами. Код проходить рев'ю, у нього є історія та точки повернення, а дані лежать у мережевій папці або об'єктному сховищі, де нове вивантаження затирає попереднє.

Навчання моделей при цьому запускається «на тому, що є зараз», і зв'язок між версією даних та отриманою метрикою тримається лише в пам'яті інженера або в назві папки.

Ціна такої схеми — розходження результатів і втрачена відтворюваність експериментів. Інженер витрачає дні на спроби повторити минулий запуск, порівнює метрики, які порівнювати не можна, а суперечка «що змінилося» переходить у листування. Коли потрібно відкотити невдале оновлення, з'ясовується, що відкочувати нічого.

DVC налаштування закриває саме цей розрив: версіонування датасетів і конфігурацій, прив'язка ваг моделі до конкретного знімка даних і передбачуваний повтор запуску. Нижче — як це влаштовано і де найчастіше ламається.

Що дає версіонування даних і моделей у роботі

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

DVC пов'язує набір даних, конфігурацію та ваги в один коміт, тому стан експерименту відновлюється за ідентифікатором, а не за пам'яттю інженера.

Перший вимірюваний ефект — частка відтворюваних запусків. Дані адресуються за хешем вмісту, а не за шляхом у файловій системі, тому один коміт дає однакові метрики і на машині розробника, і на сервері навчання.

Розбір інциденту починається з ідентифікатора версії, а не з опитування команди: розходження між прогонами падає з «кожен другий» до поодиноких випадків.

Другий ефект — час. Незмінні стадії не перераховуються: підготовка даних, навчання та валідація кешуються за вхідними хешами, і повторний прогін піднімає готові артефакти замість повного циклу.

Збирання середовища теж перестає бути ручним — залежності та параметри фіксуються в конфігурації, і новий інженер отримує робоче середовище однією командою.

Третій — історія версій моделей і відкат до попередньої версії. Ваги прив'язані до конкретного стану даних, тому повернення до попереднього релізу — це перемикання вказівника, а не повторне навчання.

Клас помилок «у проді модель, навчена на інших даних» зникає: невідповідність даних і ваг стає видною до викочування.

Варіанти зберігання версій: порівняння підходів

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

Що враховуємо під час вибору

На практиці ці варіанти комбінують: об'єктне сховище стає основним місцем для даних, реєстр моделей — точкою видачі версій в експлуатацію, а мережевий диск залишається кешем для прискорення читання.

Ключове обмеження тут не швидкість запису, а передбачуваність: версія має відновлюватися за ідентифікатором, а не за назвою файлу з датою в назві — інакше відкат перетворюється на пошук потрібної копії вручну.

Налаштування DVC за кроками: від аудиту до передачі

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

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

Що замовник отримує на руки: конфігурації та регламенти

Передаємо не лише робочі файли, а й усе, що потрібно вашій команді для самостійної роботи з версіями даних і моделей. Склад пакета узгоджуємо на старті, а на прийманні перевіряємо за ним, а не за пам'яттю.

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

Пакет залишається у вашому контурі: зовнішні залежності перелічені окремим списком, щоб нічого не опинилося за його межами.

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

Що було до

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

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

Що змінилося

Версії вибірок і ваг винесли з робочої папки в окреме сховище, у репозиторії залишилися тільки вказівники на них. Один файл конфігурації описує запуск цілком: розбиття вибірок, передобробку, порядок етапів.

Налаштували DVC так, що повторний запуск підтягує ті самі дані й відновлює середовище, а повернення до минулої версії — перемикання вказівника, а не ручне збирання.

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

Чим версіонування даних відрізняється від версіонування коду?

Код і дані змінюються по-різному, і ця відмінність визначає все інше. Правка в коді — кілька рядків тексту, тому система контролю версій зберігає лише різницю між сусідніми станами.

Набір даних — бінарний файл на десятки гігабайт, і різниця між двома вивантаженнями майже завжди зіставна з повним обсягом.

Тому датасет не кладуть у той самий репозиторій, що й код: порівняння по рядках для нього не існує, дельта не рахується, а кожен коміт подвоює розмір сховища.

Моделі поводяться так само — їх безглуздо порівнювати по рядках, зате осмислено пов'язувати з даними та параметрами, на яких вони навчені.

Для даних у репозиторій ідуть файли-вказівники з контрольною сумою, а самі набори та ваги — в об'єктне сховище; так влаштоване налаштування DVC.

Збіг версій перевіряється за контрольною сумою: однаковий набір дає однаковий ідентифікатор, а відкат до потрібної комбінації даних і моделі виконується однією командою синхронізації.

Критерій збігу результатів теж різний. Для коду достатньо, щоб пройшли тести на тій самій ревізії; для моделі важливо, щоб метрика відтворилася на зафіксованому наборі з тими самими параметрами навчання.

Не закріплена хоча б одна з трьох складових — дані, код, параметри — і результат навчання перестає бути повторюваним.

Технічні сумніви: обсяги, сховища, права доступу

Інженерні питання перед налаштуванням версіонування майже завжди одні й ті самі: великий обсяг даних, кілька команд із різними правами, уже працюючий процес навчання.

DVC влаштований так, що в репозиторії залишаються тільки файли-вказівники, а самі артефакти живуть в окремому сховищі.

Нижче — відповіді на те, що найчастіше уточнюють до старту робіт. Якщо вашого випадку в списку немає, розберемо окремо.

Як розмежувати доступ до даних і моделей?

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

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

Ні — версіонування надбудовується поверх поточних папок і скриптів: дані індексуються як є, навчання запускається звичним способом. Версія даних фіксується в тому самому коміті, що й код навчання, тому відтворюваність з'являється без переписування процесу. Перехід відбувається за кроками, з відкатом на початкову схему.

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

Щоб повернутися з оцінкою обсягу та планом робіт, нам потрібно обговорити задачу предметно — за вашим поточним процесом роботи з даними та моделями. Частину відповідей можна дати приблизно, решту уточнимо самі під час розбору репозиторію та сховищ.

• Де зараз лежать дані та моделі: локальні диски, мережеві каталоги, об'єктне сховище — і який обсяг із темпом приросту на місяць.
• Що вважається артефактом: ваги моделей, метрики навчання, конфігурації, підготовлені вибірки — і які з них потрібні в продакшені.
• Скільки інженерів працюють з одним набором даних і чи потрібні розмежування прав і правила рев'ю змін.
• Як влаштований поточний цикл навчання: скрипти, ноутбуки, оркестратор, ручні кроки — де версіонування впишеться, а що доведеться переписати.
• Вимоги до сховища артефактів: зовнішній контур чи внутрішній, політика зберігання та видалення, доступ із зовнішньої мережі.
• Що вже є з інфраструктури: репозиторій з історією змін, сервер збирання, де запускаються навчання.

З цих відповідей складається порядок старту: аудит поточного зберігання, схема гілкування та тегів, налаштування віддаленого сховища, перенесення наявних наборів, регламент роботи для команди. Це і є вхідні дані проєкту — без них оцінка обсягу буде приблизною. Опишіть задачу у зручному вигляді, і ми повернемося з оцінкою та планом робіт.