Версіонування ML-моделей: налаштування Model Registry під ключ

Model Registry: чому версії моделей розходяться за середовищами

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

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

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

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

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

Ефект від версіонування: відтворюваність і відкат моделі

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

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

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

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

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

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

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

Режими зберігання та роздавання моделей: порівняння варіантів

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

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

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

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

Етапи впровадження: від інвентаризації моделей до передачі

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

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

Конфігурації, політики доступу та регламент випуску версій

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

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

• Конфігурації реєстру — файли параметрів сховища артефактів і бази метаданих, правила зберігання версій та очищення, прив’язка до об’єктного сховища, ліміти на розмір артефакту й на кількість одночасних публікацій.
• Схема інтеграцій — як складальна лінія передає навчену модель, на якому кроці перевіряються метрики якості, хто й під яким обліковим записом реєструє версію, які зовнішні системи отримують повідомлення про нову версію.
• Політики доступу — ролі та сервісні облікові записи з розподілом прав на читання, публікацію й переведення моделі в продакшн, строки дії токенів, порядок надання та відкликання доступів.
• Регламент випуску — правила нумерації версій, обов’язкові стадії перевірки, точки погодження, умови переведення в продакшн, процедура відкату на попередню версію та її граничний строк.
• Документація реєстру — опис структури, обов’язкові поля картки моделі (джерело даних, метрики, відповідальний, призначення), інструкція з підключення нового проєкту.
• Інструкції для чергової зміни — що перевіряти під час збою публікації, як відновити доступ, куди дивитися насамперед у разі розбіжності версій між реєстром і продакшном.
• Матриця відповідальних — хто володіє реєстром, хто затверджує випуск, до кого надходить ескалація в разі інциденту.

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

Кейс: скоротили частку збоїв після випуску моделей

Кейс впровадження: у замовника в бойовому контурі жили 14 моделей, і кожна версія виходила через листування.

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

Що змінили

Розгорнули MLflow Model Registry як єдине джерело правди щодо версій: у кожного запису — номер, прив’язка до датасету, коміту й вимірювань якості, а стадії «навчання → перевірка → бойовий контур» проставляються автоматично.

Ручний крок «скопіювати ваги на сервер» прибрали зовсім: випуск став просуванням версії стадіями, відкат — перемиканням вказівника на попередній запис.

Метрики до та після

Скорочення збоїв дало не сам реєстр, а зникнення ручних артефактів: зник клас помилок «у бойовий контур поїхала не та версія» і «метрики рахувалися на іншому датасеті».

Залишкові відмови пов’язані з якістю даних і навантаженням — їх тепер видно на стадії перевірки, до випуску, а не на живих користувачах.

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

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

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

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

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

Сумісність, зберігання артефактів і права: часті питання

Реєстр моделей (Model Registry) надбудовується над поточним стеком, а не замінює його: навчання відбувається у звичному середовищі, а версія, метрики та артефакт потрапляють до реєстру автоматичним кроком контуру збірки або через програмний інтерфейс.

Уже навчені моделі переносимо імпортом — ваги, метадані та власник версії прив’язуються до запису, історія експериментів не втрачається.

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

Чи сумісний реєстр з нашими інструментами навчання? Підключення відбувається через програмний інтерфейс і стандартні бібліотеки, середовище навчання залишається незмінним. Якщо середовищ кілька, версії зводимо в один список з метриками та артефактами.

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

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

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

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

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

Опишіть задачу та надішліть вхідні дані — хоча б чорновими нотатками: уточнимо деталі й повернемося з планом і строками.