# MLOps у 2026: MLflow, Model Registry та технічні питання співбесіди

> Питання співбесіди з MLOps: життєвий цикл ML, відстеження експериментів у MLflow, просування моделей у Model Registry, патерни розгортання, моніторинг дрейфу та системний дизайн для 2026 року, з кодом на Python і відповідями.

- Published: 2026-06-23
- Updated: 2026-07-06
- Author: Anthony Fillion-Maillet
- Tags: data-science, mlops, mlflow, machine-learning, interview
- Reading time: 9 min

---

Питання співбесіди з MLOps у 2026 році перетворилися з вузької спеціалізації на ключову частину найму фахівців з data science та інженерії машинного навчання. Команди більше не запитують лише про те, як навчається модель; вони з'ясовують, як її відстежують, версіонують, розгортають і моніторять після того, як на неї потрапляє реальний трафік. Цей посібник розбирає питання, що регулярно виникають на співбесідах з MLOps, згрупувавши їх за етапами життєвого циклу, з прикладами MLflow, що відображають продакшн-конфігурації.

> **Що насправді перевіряють співбесіди з MLOps**
>
> Співбесіди з MLOps оцінюють три вміння: відтворюваність (відновлення експерименту з відстежених параметрів та артефактів), безпечне просування (перенесення моделі зі staging у продакшн без порушення роботи залежних сервісів) та операційну обізнаність (виявлення дрейфу, відкат і тригери перенавчання). Кандидати, які обговорюють лише точність моделі, зазвичай застрягають на другому питанні.

## Питання співбесіди з MLOps щодо життєвого циклу машинного навчання

**Q1: Що таке MLOps і чим він відрізняється від DevOps?**

MLOps застосовує принципи DevOps, такі як автоматизація, CI/CD та моніторинг, до систем машинного навчання, а потім додає три аспекти, яких немає в традиційному програмному забезпеченні: версіонування даних, версіонування моделей і безперервну валідацію щодо реальних розподілів даних. У класичному DevOps код — єдиний артефакт, що змінюється. У MLOps код, дані та навчена модель версіонуються незалежно, і будь-який із цих трьох елементів може непомітно погіршити якість результату без зміни жодного рядка коду. Часто цитована стаття [Hidden Technical Debt in Machine Learning Systems](https://proceedings.neurips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html) наголошує, що код моделі — це лише невелика частина реальної ML-системи, тоді як конвеєри даних, моніторинг і конфігурація займають більшу частину поверхні.

**Q2: Опишіть етапи життєвого циклу продакшн-моделі ML.**

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

## Відстеження експериментів на прикладі туторіалу MLflow

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

**Q3: Як відстеження MLflow фіксує експеримент і чому важливий run ID?**

Кожен виклик `mlflow.start_run()` відкриває запуск, який логує гіперпараметри, метрики та серіалізовану модель. Run ID — це незмінний ідентифікатор, який пов'язує метрику з точним кодом, параметрами та знімком даних, що її створили, і саме це робить експеримент відтворюваним навіть через кілька місяців.

```python
# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle
```

Аргумент `name` замінює застарілий `artifact_path` у MLflow 3.x — зміну варто згадати, щоб продемонструвати обізнаність із поточним API. Кандидати, які посилаються на відстеження ознак та наборів даних через [патерни валідації ML-конвеєрів](/technologies/data-science/interview-questions/ml-pipelines-validation), зазвичай отримують вищі оцінки, адже відтворюваність залежить від усього конвеєра, а не лише від моделі.

## Model Registry 2026: версіонування та просування

MLflow Model Registry перетворює артефакт запуску на керований об'єкт, готовий до просування. Найбільша нещодавня зміна, яку часто перевіряють на співбесідах 2026 року, — це відмова від іменованих стадій (stages).

**Q4: Як MLflow Model Registry просуває модель і що змінилося у 2026 році?**

Ранні версії MLflow просували моделі через фіксовані стадії з назвами Staging, Production та Archived. MLflow 3.x оголошує ці стадії застарілими на користь аліасів (aliases) і тегів, оскільки жорстко закодований перелік стадій не міг виразити реальні топології розгортання, такі як champion, challenger чи shadow. Аліас — це змінюваний вказівник на одну версію, тож просування зводиться до перепризначення аліаса, а не до модифікації самої моделі.

```python
# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")
```

Оскільки споживачі завантажують `models:/churn-classifier@champion`, відкат зводиться до одного перепризначення аліаса на попередню версію без повторного розгортання. [Офіційна документація MLflow Model Registry](https://mlflow.org/docs/latest/model-registry.html) детально розкриває керування аліасами та вебхук-тригери.

> **Аліаси проти стадій в одному реченні**
>
> Стадії відповідали на питання «у якому фіксованому кошику перебуває ця модель», тоді як аліаси відповідають «яка версія зараз є champion», що відповідає тому, як blue-green та canary розгортання насправді маршрутизують трафік.

## Патерни розгортання машинного навчання та сервінг

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

**Q5: Порівняйте пакетне (batch), онлайн та потокове (streaming) розгортання машинного навчання.**

| Патерн | Затримка | Типовий сценарій | Поверхня сервінгу |
|---------|---------|------------------|-----------------|
| Batch | Від годин до доби | Скоринг відтоку, оновлення рекомендацій | Заплановане завдання, що записує у таблицю |
| Online (реального часу) | Десятки мілісекунд | Перевірка шахрайства, ранжування під час запиту | Ендпоінт REST або gRPC |
| Streaming | Менше секунди, безперервно | Виявлення аномалій у потоках подій | Консюмер у черзі повідомлень |

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

```bash
# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv
```

**Q6: Як blue-green та canary розгортання знижують ризик під час викочування моделі?**

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

## Тестування та CI/CD для конвеєрів машинного навчання

**Q7: Що CI/CD перевіряє у ML-конвеєрі, чого не перевіряє стандартний програмний конвеєр?**

Програмний CI-конвеєр запускає модульні та інтеграційні тести коду. ML-конвеєр додає до цього тести даних і моделі: валідацію схеми вхідних даних, перевірки розподілів, щоб навчальний запуск не поглинув непомітно пошкоджені ознаки, і бар'єр якості моделі, який завалює збірку, коли кандидат набирає менше за поточного champion на фіксованому holdout-наборі. Тому безперервна доставка для ML просуває артефакт моделі, а не лише образ контейнера, і бар'єром просування є поріг метрики, а не сама лише зелена тестова збірка. Ретельний конвеєр також фіксує знімки даних і версії залежностей, щоб будь-який повторний запуск був детермінованим — саме це відрізняє відтворювану збірку від тієї, що просто випадково проходить сьогодні.

## Моніторинг, дрейф даних і перенавчання моделі

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

**Q8: Як виявляють дрейф даних і яка метрика його кількісно оцінює?**

Дрейф даних означає, що розподіл продакшн-вхідних даних відхилився від навчального розподілу. Population Stability Index (PSI) — поширена метрика, незалежна від фреймворку: вона розбиває еталонний розподіл на біни, порівнює продакшн-частоти із цими бінами й підсумовує зважені логарифмічні різниці.

```python
# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)
```

Крім саморобної метрики, продакшн-команди вдаються до інструментів на кшталт [Evidently](https://www.evidentlyai.com/), щоб за розкладом відстежувати дрейф ознак, дрейф цільової змінної та якість даних. Повна відповідь розрізняє дрейф даних (зсув вхідних даних) і дрейф концепції (зсув зв'язку між входом і виходом), адже другий неможливо вловити, спостерігаючи лише за входами — він потребує розмічених результатів.

**Q9: Що має запускати конвеєр перенавчання?**

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

## Питання співбесіди з системного дизайну MLOps

**Q10: Спроєктуйте платформу, що обслуговує сотні моделей із узгодженими ознаками.**

Очікуваним центральним елементом є feature store (сховище ознак), яке усуває розбіжність між навчанням і сервінгом (training-serving skew), обчислюючи ознаки один раз і надаючи ідентичні значення як для навчання, так і для інференсу. Інструменти на кшталт [Feast](https://feast.dev/) забезпечують офлайн-сховище для навчання та онлайн-сховище з низькою затримкою для сервінгу. Повний дизайн також називає model registry для версіонування, сервер відстеження для lineage, оркестратор для конвеєрів і рівень моніторингу, що замикає цикл назад на перенавчання. Обґрунтування відповіді реальною роботою з ознаками, зокрема компромісами, розглянутими у цьому [посібнику зі співбесіди з інженерії ознак](/blog/data-science/feature-engineering-machine-learning-techniques-interview-2026), свідчить про практичний досвід, а не про заучену схему.

> **Пастка розбіжності навчання й сервінгу**
>
> Найпоширеніша помилка дизайну MLOps — обчислювати ознаку одним способом у навчальному ноутбуці й іншим способом у коді сервінгу. Feature store існує саме для того, щоб зробити це неможливим, тож інтерв'юери очікують почути його назву тієї ж миті, коли у відповіді на системний дизайн з'являється слово «ознаки».

## Висновок

- Сприймати MLOps як DevOps плюс версіонування даних і моделей: відтворюваність, безпечне просування та моніторинг — три осі, за якими оцінюють інтерв'юери
- Знати зміну API MLflow 3.x: аліаси й теги замінюють застарілі стадії Staging та Production, а `log_model` тепер приймає `name` замість `artifact_path`
- Узгоджувати патерн розгортання з бюджетом затримки й за замовчуванням обирати canary замість blue-green для викочування моделей, бо проблеми з якістю проявляються лише на реальних даних
- Кількісно оцінювати дрейф конкретною метрикою на кшталт PSI та розрізняти дрейф даних і дрейф концепції, оскільки без розмітки видно лише один із них
- Запускати перенавчання за метриками, а не за календарем, і проводити отриманого challenger через canary, перш ніж перепризначати аліас champion
- Називати feature store у будь-якій відповіді на системний дизайн, щоб закрити прогалину розбіжності навчання й сервінгу, перш ніж її піднімуть у наступному питанні

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/uk/blog/data-science/mlops-mlflow-model-registry-interview-questions-2026