10 вопросов по теме «MLOps и модель в проде» на собеседовании

Короткий ответ: Data drift (ковариатный сдвиг) — меняется распределение входов P(x): например, пришёл новый сегмент пользователей. Concept drift — меняется сама зависимость P(y|x): тактики фрода эволюционируют, вкусы сдвигаются. Первый виден сразу по фичам, второй — только по качеству на свежих метках.

Подробно:

1. PSI (Population Stability Index) — эмпирическое правило: PSI < 0.1 — стабильно, 0.1–0.2 — присмотреться, > 0.2 — алерт.
2. Мониторинг скоров — сдвиг распределения предсказаний часто заметен раньше, чем сдвиг отдельных фич.
3. Отложенная оценка качества — concept drift без меток напрямую не виден; трекаем метрики на созревших когортах.

⚠️ Частая ошибка: считать любой дрифт поводом переобучать. Дрифт фичи с нулевой важностью качество не трогает — сначала оценить влияние, потом действовать.

Короткий ответ: Пока меток нет, мониторим прокси: распределения входных фич, сдвиг распределения скоров, объём предсказаний по сегментам. Качество считаем отложенно — на когортах, у которых метки уже созрели. Алертим сначала по распределениям, по качеству — потом.

Подробно:

1. Входы — PSI/KS по ключевым фичам: сломанный источник данных виден за часы, а не через месяцы.
2. Выходы — распределение скоров и доля одобрений/блокировок по сегментам; резкий сдвиг среднего скора — ранний сигнал.
3. Отложенная оценка — когортный подход: качество по выдачам января считаем в апреле, когда дефолты созрели; следим за трендом от когорты к когорте.
4. Опережающие индикаторы — метрики, коррелирующие с целевой: ранняя просрочка (FPD) как прокси дефолта, chargeback-заявки как прокси фрода.

день 0        дни 1–90              день 90+
предикт ──►  прокси-мониторинг ──►  метки созрели
             (фичи, скоры,           └─► качество
              объёмы)                    по когорте

⚠️ Частая ошибка: «будем следить за accuracy» — меток ещё нет, следить не за чем. Интервьюер ждёт план именно на период слепоты.

Короткий ответ: Два подхода: по расписанию (еженедельно/ежемесячно) или по триггеру (алерт дрифта, деградация качества). В обоих случаях новая версия — challenger: валидируется на свежих данных и попадает в прод только через eval-гейт, а не автоматом.

Подробно:

1. По расписанию — просто и предсказуемо; подходит, когда данные дрейфуют плавно. Риск: переобучаем впустую или, наоборот, опаздываем.
2. По триггеру — реагируем на PSI-алерт или падение метрик; сложнее в инфраструктуре, зато переобучаем ровно тогда, когда нужно.
3. Champion/challenger — текущая модель (champion) остаётся; кандидат проверяется на holdout из свежих данных и/или в шедоу-режиме; промоушен — только если стабильно лучше.

Подводные камни автопереобучения:

⚠️ Частая ошибка: «переобучаем каждый день, значит всё свежее» — без валидационного гейта ежедневное переобучение лишь быстрее доставляет баги в прод.

Короткий ответ: Это расхождение между фичами, на которых модель училась, и фичами, которые она получает в проде: оффлайн считали batch-SQL, онлайн переписали на сервисном коде — и логика разошлась. Модель тихо деградирует без единой ошибки в логах. Знание этой проблемы интервьюеры читают как маркер боевого продакшн-опыта.

Подробно:

1. Откуда берётся — две реализации одной фичи (SQL для трейна, Java/Go для инференса), разные источники данных, разная обработка null, агрегаты «на сейчас» vs «на момент события».
2. Фича-стор (feature store) — фича определена один раз и отдаётся и в трейн, и в онлайн-инференс; главный аргумент за его внедрение.
3. Log-and-train — логировать фичи, реально поданные на инференс, и обучаться на этих логах: трейн видит ровно то, что видел прод.
4. Мониторинг паритета — регулярная сверка оффлайн- и онлайн-значений одной фичи на одних и тех же объектах.

              ┌── batch SQL ─────► трейн        ✗ два пути —
сырые данные ─┤                                   логика разъезжается
              └── сервисный код ─► инференс

              ┌───────────────┐
сырые данные ─┤ feature store ├─► трейн + инференс   ✓ один путь
              └───────────────┘

⚠️ Частая ошибка: проверять только схему (типы совпали — ок). Skew живёт в семантике: тот же float, но посчитан иначе.

Короткий ответ: Лестница: шедоу-режим (скорим живой трафик, но решений не принимаем) → canary на малом проценте трафика → A/B-тест на бизнес-метрике. На каждой ступени — критерии выхода и kill switch с планом отката.

Подробно:

1. Shadow — модель видит боевой трафик, ответы логируются, но не применяются: проверяем латентность, долю ошибок и адекватность распределения скоров.
2. Canary — 1–5% трафика получает решения новой модели; смотрим системные и продуктовые метрики, при инциденте — мгновенный откат.
3. A/B на бизнес-метрике — финальный вердикт выносит конверсия/выручка/retention, а не оффлайн-AUC: оффлайн-прирост регулярно не доезжает до продукта.
4. Интерливинг — для ранжирования: смешиваем выдачи двух моделей в одном списке; чувствительнее классического A/B.

offline eval ─► shadow ─► canary 1–5% ─► A/B ─► 100%
                  │            │          │
                  └────────────┴──────────┴──► rollback (kill switch)

⚠️ Частая ошибка: катить сразу в A/B без шедоу-этапа — о всплеске латентности или битых фичах узнаёте уже на живых пользователях.

Короткий ответ: Четыре слоя: входы (распределения фич, доля null, схема и свежесть), выходы (распределение скоров, объёмы предсказаний по сегментам), система (латентность, throughput, ошибки) и качество (метрики на подъехавшей ground truth, по сегментам). На каждый слой — свои пороги алертов.

Подробно:

1. Сегментация обязательна — глобальная метрика может стоять на месте, пока в важном сегменте всё горит.
2. Логи фич — сохранять фичи, поданные на инференс: без них не отдебажить инцидент и не переобучиться честно.

⚠️ Частая ошибка: мониторить только «accuracy». Метки задерживаются, а пайплайн ломается сегодня — входные алерты срабатывают первыми.

Короткий ответ: Сначала данные, потом модель. Порядок: (1) не сломался ли пайплайн данных — схема, null, отставший источник; (2) форма падения — ступенька (поломка/релиз) или плавное сползание (дрифт); (3) сдвиг распределения входов; (4) проблемы с самими метками; (5) мир действительно изменился.

Подробно:

1. Пайплайн данных — самая частая причина: upstream поменял схему, фича превратилась в null, источник отстал на сутки. И проверяется быстрее всего.
2. Датировка и форма — наложить падение на календарь релизов: ступенька в день деплоя — это поломка, а не дрифт.
3. Входные распределения — PSI по фичам, поиск нового сегмента трафика.
4. Метки — не сломалась ли разметка или джоин таргета: иногда «падение качества» — это падение качества измерения.
5. Мир изменился — concept drift как гипотеза последней очереди, когда скучные причины исключены.

ступенька    ──► ищи релиз или поломку в этот день
плавный спад ──► ищи дрифт данных или поведения

⚠️ Частая ошибка: первым делом «давайте переобучим» — если сломан пайплайн, переобучение на битых данных закрепит поломку.

Короткий ответ: Версии всего, из чего собирается результат: данные, код, конфиг с гиперпараметрами, random seeds и окружение. Плюс трекинг экспериментов и model registry, чтобы у каждой продовой модели была полная родословная.

Подробно:

1. Данные — снапшоты или версионирование (DVC, lakeFS): «та же таблица» через месяц — это уже другие данные.
2. Код — git-коммит, привязанный к запуску эксперимента.
3. Конфиг — гиперпараметры, версии фич, сплиты — в конфиге, а не в ноутбуке.
4. Seeds — фиксировать random seed везде (numpy, фреймворк, сплиты); помнить про недетерминизм GPU.
5. Окружение — lock-файл зависимостей или Docker-образ.
6. Трекинг — MLflow/W&B: параметры, метрики и артефакты каждого запуска.
7. Registry — продовая модель указывает на конкретный запуск: данные + код + конфиг восстановимы.

данные (v) + код (git) + конфиг + seed + env
        └──► run в трекере ──► model registry ──► прод

⚠️ Частая ошибка: «у меня же ноутбук сохранился» — ноутбук с ячейками, перезапущенными вразнобой, не воспроизводит ничего.

Короткий ответ: Здесь проверяют навык коммуникации, а не определение. Рабочая аналогия: студент вызубрил ответы прошлых экзаменов — идеально сдаёт пробник и проваливает настоящий экзамен, потому что выучил ответы, а не предмет. Модель «запомнила» исторические данные вместо закономерности.

Подробно:

1. Аналогия — это и есть тест — интервьюер смотрит, найдёте ли вы образ из мира собеседника: зубрёжка vs понимание, костюм, сшитый строго по одному человеку.
2. Метрики → бизнес-язык — не «AUC 0.93», а «ловим 80% фрода, ошибочно блокируем 1 из 200 честных клиентов».
3. Что это значит для продукта — «на исторических данных модель выглядит лучше, чем поведёт себя с реальными пользователями, поэтому мы держим честную проверку на отложенных данных».
4. Формат — меньше минуты, без единого термина; закончить действием: что мы делаем, чтобы это поймать.

⚠️ Частая ошибка: через два предложения съехать в «добавим регуляризацию и уменьшим variance» — жаргон вернулся, тест провален.

Короткий ответ: Через петлю обратной связи: предсказания модели определяют, какие данные вообще появятся. Рекомендер показывает — пользователь кликает по показанному — клики становятся обучающей выборкой следующей модели. Антифрод блокирует — заблокированный фрод никогда не получает метку.

Подробно:

1. Рекомендательные системы — position bias и selection bias: модель учится на кликах по собственной выдаче, «пузырь фильтров» самоусиливается.
2. Фрод/скоринг — reject inference: у отклонённых заявок нет исхода, выборка следующей модели смещена в сторону одобренных.
3. Митигация — держать exploration-слайс: небольшая доля трафика с рандомизацией или ослабленной политикой даёт несмещённые данные.
4. Логировать propensity — вероятность показа/действия на момент решения: позволяет взвешивать (IPS) и делать off-policy оценку.

модель ──► показы/решения ──► поведение юзеров ──► логи
  ▲                                                  │
  └──────────── следующий трейн ◄────────────────────┘
     разорвать: exploration-слайс + propensity-логи

⚠️ Частая ошибка: не заметить, что петля вообще существует, и радоваться росту оффлайн-метрик, которые модель сама себе нарисовала.