Лексика ML-платформ: feature stores, реєстри моделей і MLOps-пайплайни

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

Складання і аналіз даних для аналізу

Feature store є централізованим сховищем для зберігання і обслуговування ML-функцій — інженерних вхідних даних до моделі. Склад функцій має два компоненти: ** автономний склад ** (історичні функції для навчання, зазвичай підтримуються сховищем даних або об’ єктом зберігання) і ** мережевий склад ** (функції з низькою затримкою для виведення в реальному часі, підтримуються сховищами ключів- значень, такими як Redis або DynamoDB).

Feature serving is the process of retrieving features at prediction time. Інженери кажуть: * “Коректність в момент часу є критичною - офлайн-магазин повинен обслуговувати функції, як вони існували в час етикетки, а не сьогоднішні значення.” *

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

Реєстр моделей і експериментів

** експеримент ** в ML є записаною спробою тренування моделі з певною конфігурацією. Кожна спроба називається ** запуск **. Інструменти, такі як MLflow, Weights & Biases і Neptune track, виконуються автоматично, записуючи ** метрики ** (точність, F1, AUC), ** параметри ** (швидкість навчання, розмір партії, кількість шарів) і ** артефакти ** (тренувані файли моделей, діаграми оцінки, препроцесори).

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

** Налаштування гіперпараметрів** (також відоме як оптимізація гіперпараметрів, HPO) є автоматичним пошуком найкращої конфігурації моделі. Інженери відрізняють гіперпараметри (встановлені до тренування, наприклад, швидкість навчання) від параметрів моделі (вивчених під час тренування, наприклад, ваги нейронних мереж).

Підтримка і обслуговування мереж

** Конвейєр ML ** є оркестрованою послідовністю кроків - вживання даних, обчислення функцій, навчання, оцінка і реєстрація - що виконується від початку до кінця. Інструменти включають Kubeflow Pipelines, Metaflow, і Vertex AI Pipelines. Типове оновлення: * “Нічний тренувальний конвеєр зазнав невдачі на етапі оцінки - новий набір даних перевірки мав дрейф схеми.” *

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

** Дрейф моделі ** відбувається, коли продуктивність розгорнутої моделі погіршується через зміну розподілу у реальному світі. Існує два типи: ** концептуальний дрейф ** (зміни у зв’ язку між властивостями і мітками) і ** дрейф даних ** (зміни у розподілі властивостей вхідних даних). ** Тригер перенавчання ** це правило або сигнал, який запускає новий тренувальний запуск, наприклад, коли метрика дрейфу перетинає поріг.

Стратегия развертывания

** A/B тестування моделей ** означає маршрутизацію відсотка трафіку до нового кандидата моделі і порівняння метрик з базовим рівнем. ** Тіньове розгортання ** (також називається ** режим тіні **) надсилає поточний трафік до нової моделі, але відкидає її передбачення — ви спостерігаєте затримку і частоту помилок без впливу на користувачів. Інженери кажуть: * “Запустити нову модель рекомендацій в тіні на тиждень, перш ніж ми перейдемо.” *

Налаштування ** champion/ challenger ** зберігає поточну найкращу модель (champion) у виробництві, одночасно маршрутизуючи невеликий шматок трафіку до нового кандидата (challenger) для порівняння.

Наступні кроки

Виберіть один з інструментів MLOps, яким користується ваша команда — MLflow, SageMaker, Vertex AI — і прочитайте його офіційну документацію протягом 20 хвилин, використовуючи словник з цієї статті як оглядову лінзу. Кожного разу, коли ви стикаєтеся з терміном, який не можна визначити англійською, записуйте його і знайдіть реальні приклади речення з інженерних блогів або проблем GitHub. Активний словник виникає тільки через навмисне виставлення.

На практиці: Навігація та співпраця

Будьмо чесними – навіть з чітким розумінням термінології навколо платформ машинного навчання, ефективне спілкування в командному середовищі все ще може бути складним. Це не просто про те, щоб знати, що означає «магазин функцій»; це про те, щоб сформулювати свої потреби, зрозуміти чиюсь іншу точку зору і спільно формувати рішення. Поширений сценарій, який ми бачимо під час перегляду коду - розглянемо, як ви можете пояснити запропоновані зміни старшому інженеру, який переглядає вашу роботу над інтеграцією моделі реєстру.

Уявіть це повідомлення Slack: «Привіт @John, я додав поле model_version до схеми реєстру, що відображає структуру в нашому магазині функцій. Я використовую SQLAlchemy для запитів — це досить стандартний засіб, який дозволяє нам ефективно фільтрувати метадані, такі як дата тренування та версія алгоритму.» Джон може відповісти запитанням: « Добре бачити, що ви вирівняли склад з функціями, але чи можете ви розібратися, * чому * ви обрали SQLAlchemy? Зараз ми випробовуємо Dask для деяких з цих запитів, особливо коли справа стосується великих наборів даних моделей. Він пропонує значно кращі результати в нашому середовищі»

Це не критика; це цінна можливість уточнити ваше пояснення і продемонструвати, що ви розумієте ширший контекст. Хороша відповідь може бути: «Ви маєте рацію – Dask варто дослідити. Спочатку я обрав SQLAlchemy, оскільки це був найшвидший спосіб для початку роботи, а швидкість виконання запитів була прийнятною для менших моделей. Я, безумовно, можу дослідити інтеграцію Dask в цей робочий процес як частину наступної ітерації, особливо коли ми почнемо розгортати більші, більш складні моделі. Ключовим тут є використання точної мови - “прийнятна продуктивність”, “більші, більш складні моделі” - показуючи, що ви розглянули наслідки і відкриті для альтернативних рішень. Це також стосується визнання компромісів, пов’язаних з різними технологіями.

Інша ситуація може виникнути під час написання опису запитів на завантаження для нового конвеєра MLOps, який використовує реєстр моделі. Ви не просто вкажете: « Цей PR додає конвеєр для розгортання моделей з реєстру ». Замість цього ви надасте контекст: « Цей PR реалізує автоматизований конвеєр розгортання, який запускається за допомогою реєстрації нових моделей у реєстрі моделей. Конвейєр використовує Airflow для організації кроків - витягування останньої версії моделі з реєстру, перевірка її продуктивності на тіні метрики, визначеної в нашій системі моніторингу (за допомогою Prometheus), а потім розгортання її в середовищі стаджінгу для A / B тестування. Ми зосереджуємось на скороченні часу розгортання, зберігаючи суворий контроль якості.” Цей рівень деталізації демонструє, що ви розумієте не тільки * що * конвеєр робить, але * чому * це робиться, і як це інтегрується в ширшу стратегію MLOps.

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

SELECT model_name, training_date, algorithm_version
FROM models
WHERE algorithm_version = 'v1.2.3' AND training_date >= '2023-01-01';

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