Налаштування Model Registry для керування версіями моделей

Чому без Model Registry версії моделей розходяться з продом

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

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

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

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

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

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

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

Що дає керований реєстр моделей: вимірюваний ефект

Реєстр моделей — це не каталог файлів, а контракт між тими, хто навчає моделі, і тими, хто виводить їх у продукт.

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

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

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

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

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

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

Підсумок — реєстр перетворює роботу з моделями з набору особистих практик на повторюваний процес із вимірюваними показниками.

Варіанти Model Registry: хмара, власний контур, гібрид

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

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

Як обрати

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

Впровадження реєстру моделей: від аудиту до передачі

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

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

Що залишається у вашому контурі: артефакти і регламенти

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

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

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

Кейс: навели лад у версіях моделей на проді

Що було до

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

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

Що змінили

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

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

Що стало

Через квартал під управлінням реєстру — 100% моделей, випуск версії скоротився з 4 годин до 40 хвилин, відкат — з 3–4 годин до 8 хвилин, вдень і без зупинки сервісу. Повторювані інциденти виду «на прод повернулася застаріла модель» припинилися.

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

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

Сховище артефактів відповідає на питання «де лежить файл», реєстр моделей — на питання «що це за модель і чи можна її розгортати».

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

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

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

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

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

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

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

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

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

Технічні сумніви: розбираємо часті питання

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

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

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

Успадковані моделі без метаданих доведеться збирати повторно?

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

Скільки місця займуть усі версії моделей?

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

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

Щоб оцінка за model registry спиралася на ваш контур, а не на середні допущення, першу розмову будуємо як розбір ввідних. Нам потрібні факти про те, як моделі живуть зараз, — тоді трудомісткість вважаємо за етапами, а не однією усередненою цифрою.

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

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