MLOps и ML в продакшене
Training-serving skew, дрейф данных против дрейфа концепции, feature store, триггеры переобучения, воспроизводимость, реестры моделей и мониторинг в проде.
11 вопросов
JuniorТеорияОчень частоЧто такое training-serving skew, и как расходятся два пайплайна признаков?
Что такое training-serving skew, и как расходятся два пайплайна признаков?
Training-serving skew — расхождение в том, как признак вычисляется офлайн при обучении и онлайн при инференсе. Оно возникает, когда пайплайны — отдельные куски кода, которые разъезжаются, либо когда в проде другие окна агрегации, дефолты или единицы.
Типичные ошибки
- ✗Приравнивать skew к дрейфу данных — skew это расхождение вычислений, а не сдвиг данных
- ✗Считать, что общая библиотека убирает skew, хотя источники данных при обучении и в проде разные
- ✗Лечить skew переобучением, что просто зашивает то же неверное определение признака в новую модель
Уточняющие вопросы
- →Как логирование признаков, реально увиденных в проде, позволяет измерить skew напрямую?
- →Почему ночной batch-джоб, добивающий признак задним числом, часто порождает skew для онлайн-трафика?
JuniorДизайнЧастоВаша команда выкатывает две-три версии модели в неделю. Сейчас артефакты лежат в бакете объектного хранилища, метрики — в таблице, а в проде та версия, которую последний инженер скопировал на сервинг-хост. В прошлом месяце откат восстановил не тот чекпоинт, и этого два дня никто не заметил. Объясните, что такое реестр моделей, какие метаданные должна нести каждая зарегистрированная версия, чтобы любой инженер мог ответить, какая модель в проде и как она получена, и какие проверки версия обязана пройти перед промоушеном из staging в production.
Ваша команда выкатывает две-три версии модели в неделю. Сейчас артефакты лежат в бакете объектного хранилища, метрики — в таблице, а в проде та версия, которую последний инженер скопировал на сервинг-хост. В прошлом месяце откат восстановил не тот чекпоинт, и этого два дня никто не заметил. Объясните, что такое реестр моделей, какие метаданные должна нести каждая зарегистрированная версия, чтобы любой инженер мог ответить, какая модель в проде и как она получена, и какие проверки версия обязана пройти перед промоушеном из staging в production.
Реестр моделей — единый каталог версий модели и их стадий. Версия хранит артефакт, ревизию данных и кода, гиперпараметры, метрики, окружение и владельца. Промоушен закрыт порогами по метрикам, подтверждением и зафиксированным предшественником для отката.
Типичные ошибки
- ✗Считать реестр хранилищем весов, а не источником истины о стадии и происхождении версии
- ✗Регистрировать метрики без ревизии данных и кода, из-за чего запуск невозможно объяснить
- ✗Промоутить по одной метрике, не зафиксировав предшественника для отката
Уточняющие вопросы
- →Как переход стадии в реестре запускает пайплайн деплоя вместо ручного копирования?
- →Что ломается, если две версии одновременно претендуют на стадию production для одного имени модели?
JuniorТеорияЧастоКак обученная модель реально попадает в прод — артефакт в процессе, model server или переносимый runtime?
Как обученная модель реально попадает в прод — артефакт в процессе, model server или переносимый runtime?
Артефакт можно загрузить в процесс приложения, вынести за отдельный model server с endpoint или экспортировать в переносимый формат вроде ONNX. Загрузка в процесс проще всего, но привязывает приложение к точным версиям библиотек обучения.
Типичные ошибки
- ✗Считать сериализованный артефакт самодостаточным и переносимым между версиями библиотек
- ✗Видеть в model server только накладные расходы, а не развязку версий
- ✗Забывать, что вместе с моделью должен ехать и код препроцессинга, а не только веса
Уточняющие вопросы
- →Когда открытый формат обмена
ONNXперестаёт быть вариантом для вашей модели? - →Что даёт inference-сервер сверх загрузки в процесс, кроме изоляции?
MiddleТеорияЧастоДрейф данных против дрейфа концепции — что меняется в каждом и какой из них требует переобучения?
Дрейф данных против дрейфа концепции — что меняется в каждом и какой из них требует переобучения?
Дрейф данных — изменение P(x), распределения входов, при сохранении правила связи входа и метки. Дрейф концепции — изменение P(y|x), те же входы теперь означают другие метки. Дрейф концепции требует переобучения; дрейф данных важен, только если метрика просела.
Типичные ошибки
- ✗Менять определения местами — относить P(y|x) к дрейфу данных, а P(x) к дрейфу концепции
- ✗Переобучать на каждый найденный сдвиг входов, даже когда продовая метрика не изменилась
- ✗Считать дрейф и training-serving skew одной и той же поломкой с общим лечением
Уточняющие вопросы
- →Какой детектор к какому дрейфу — индекс стабильности популяции
PSIпо входам или кривая просадки метрики? - →Почему дрейф меток бывает виден в доле целевого класса задолго до сдвига любого входного признака?
MiddleТеорияЧастоКакую задачу реально решает feature store и когда его внедрение избыточно?
Какую задачу реально решает feature store и когда его внедрение избыточно?
Feature store хранит одно определение на признак и отдаёт его из офлайн-хранилища для обучения и из онлайн-хранилища для инференса, так что оба пути используют одно преобразование. Он даёт переиспользование и джойны по времени; для одной batch-модели избыточен.
Типичные ошибки
- ✗Сводить feature store к онлайн-кешу и упускать общее определение признака
- ✗Считать обучающие признаки наивным джойном, который подтягивает значения из будущего относительно события
- ✗Внедрять feature store ради одной модели, платя за эксплуатацию без переиспользования
Уточняющие вопросы
- →Что именно предотвращает корректный по времени джойн при сборке обучающей таблицы?
- →Как офлайн- и онлайн-хранилища остаются согласованными при изменении определения признака?
SeniorДизайнЧастоКредитная модель выходит в прод завтра, но исход займа известен только через тридцать дней, поэтому первая честная цифра по точности появится через месяц. Руководству нужно уже в первый день понимать, здоров ли деплой. Спроектируйте мониторинг, который реально работает без меток: какие распределения и операционные сигналы вы отслеживаете, по каким из них будите дежурного, а какие просто рисуете на графике, какая прокси- или бизнес-метрика заменяет точность в это время и как не утопить команду в алертах от безобидных дневных колебаний.
Кредитная модель выходит в прод завтра, но исход займа известен только через тридцать дней, поэтому первая честная цифра по точности появится через месяц. Руководству нужно уже в первый день понимать, здоров ли деплой. Спроектируйте мониторинг, который реально работает без меток: какие распределения и операционные сигналы вы отслеживаете, по каким из них будите дежурного, а какие просто рисуете на графике, какая прокси- или бизнес-метрика заменяет точность в это время и как не утопить команду в алертах от безобидных дневных колебаний.
Без меток мониторят вход и выход — распределения входных признаков, распределение скоров и долю одобрений, плюс доля пропусков, задержка и ошибки. Будите дежурного на поломках и резком сдвиге скоров, медленный дрейф просто рисуйте. Прокси до меток — исходы ручной проверки.
Типичные ошибки
- ✗Решать, что до появления меток измерять нечего, оставляя запуск без мониторинга
- ✗Алертить на каждый сдвиг отдельного признака вместо поломок и резких изменений выхода
- ✗Путать прокси-метрику с точностью и объявлять успех по ней, когда метки уже пришли
Уточняющие вопросы
- →Почему резкий сдвиг доли одобрений — более сильный сигнал первого дня, чем движение отдельного признака?
- →Как закреплённое референсное окно не даёт сезонности поднимать ваши алерты по дрейфу?
SeniorДизайнЧастоАнтифрод-модель работает год на еженедельном ручном переобучении, которое запускает аналитик. Схемы мошенничества меняются вспышками, поэтому в одни недели переобучение — это впустую потраченные ресурсы, а в другие модель отстаёт от атаки на три недели. Спроектируйте политику переобучения: выберите между переобучением по расписанию, по триггеру и непрерывным, укажите, что именно поднимает триггер и на каком окне измерения, определите, кто или что подтверждает кандидата до выхода в прод, и опишите путь отката, когда свежая модель оказывается хуже заменённой.
Антифрод-модель работает год на еженедельном ручном переобучении, которое запускает аналитик. Схемы мошенничества меняются вспышками, поэтому в одни недели переобучение — это впустую потраченные ресурсы, а в другие модель отстаёт от атаки на три недели. Спроектируйте политику переобучения: выберите между переобучением по расписанию, по триггеру и непрерывным, укажите, что именно поднимает триггер и на каком окне измерения, определите, кто или что подтверждает кандидата до выхода в прод, и опишите путь отката, когда свежая модель оказывается хуже заменённой.
Расписание оставляем нижней границей и добавляем триггеры — просадку метрики, дрейф выше порога или объём новых меток, каждый на окне, достаточно длинном против шума. Кандидат сравнивается с действующей моделью на свежем отложенном срезе; предыдущая версия остаётся для отката.
Типичные ошибки
- ✗Считать периодичность переобучения календарным вопросом, игнорируя, что реально изменилось в данных
- ✗Поднимать триггеры на окне настолько коротком, что обычный шум вызывает постоянные переобучения
- ✗Промоутить кандидата без сравнения с действующей моделью на том же свежем срезе оценки
Уточняющие вопросы
- →Как не дать вспышке мошенничества отравить метки, на которых учится переобучение?
- →Что делает откат изменением конфигурации, а не пересборкой, в вашей схеме?
MiddleДебаггингИногдаКонтейнер скорит те же строки иначе, чем ноутбук — как локализовать причину?
Контейнер скорит те же строки иначе, чем ноутбук — как локализовать причину?
Сравнивайте не модель, а окружения. Залогируйте точный вектор признаков, который каждая сторона строит для одной строки, и сравните — порядок, dtype, заполнение пропусков и пропущенный препроцессинг видны там. Если векторы совпали, сравните версии библиотек.
Открыть задачу →Типичные ошибки
- ✗Отлаживать артефакт модели, когда расхождение живёт в векторе признаков, который до неё доходит
- ✗Считать совпадающее число признаков доказательством идентичности двух векторов признаков
- ✗Списывать крупный воспроизводимый разрыв на недетерминированность вместо разницы dtype или версий
Уточняющие вопросы
- →Как фиксация транзитивных зависимостей через lock-файл убирает этот класс ошибок?
- →Почему колонка, прочитанная как
objectбез типа, меняет решения о разбиении у дерева?
MiddleПроизводительностьИногдаBatch, online и streaming инференс — как задержка, объём и стоимость определяют выбор?
Batch, online и streaming инференс — как задержка, объём и стоимость определяют выбор?
Batch-скоринг считает предсказания заранее по расписанию — дешевле всего на запись, но они устаревшие. Online-инференс отвечает на каждый запрос в бюджете p99 и платит за простой мощностей. Streaming скорит события по мере поступления, давая свежесть в секунды.
Типичные ошибки
- ✗Выбирать online-инференс по умолчанию и платить за простаивающие мощности, не нужные трафику
- ✗Игнорировать, что batch-предсказания устаревают ровно на длину интервала расписания
- ✗Рассчитывать онлайн-сервис по средней задержке вместо p99, который обещан продукту
Уточняющие вопросы
- →Какой режим подходит для ежедневного скора оттока по десяти миллионам пользователей и почему по стоимости?
- →Как батчирование запросов в онлайн-сервисе меняет баланс между p99 и пропускной способностью?
MiddleТеорияИногдаShadow, canary и A/B выкатка новой модели — что ловит каждый способ и чего он стоит?
Shadow, canary и A/B выкатка новой модели — что ловит каждый способ и чего он стоит?
Shadow зеркалит трафик и выбрасывает ответ, ловя падения и задержку без риска для пользователей, но не говоря о влиянии на бизнес. Canary направляет малую долю реального трафика и рано ловит регрессии. A/B-тест измеряет бизнес-эффект, но стоит трафика и времени.
Типичные ошибки
- ✗Ждать от shadow-режима ответа на бизнес-вопрос, на который он структурно ответить не может
- ✗Называть canary экспериментом и читать его прирост как статистически значимый результат
- ✗Выкатывать, не сохранив адресуемой предыдущей версии, из-за чего откат требует пересборки
Уточняющие вопросы
- →Какие сигналы на canary вы бы отслеживали для автоматического отката?
- →Почему shadow-режим всё же вскрывает training-serving skew, хотя его ответ выбрасывается?
SeniorДизайнИногдаРегулятор просит воспроизвести скоринговую модель, обученную полгода назад, и показать, что пересобранный артефакт ведёт себя идентично. Ноутбук обучения сохранился, исходные таблицы с тех пор перезаписаны на месте, а запускавший всё сотрудник уволился. Спроектируйте пайплайн обучения, при котором такой запрос становится рутиной: укажите, что именно должно версионироваться и как адресуется каждый элемент, как гарантировать пересборку обучающей таблицы на исходный момент времени и какой артефакт вы передадите регулятору как доказательство совпадения перезапуска с оригиналом.
Регулятор просит воспроизвести скоринговую модель, обученную полгода назад, и показать, что пересобранный артефакт ведёт себя идентично. Ноутбук обучения сохранился, исходные таблицы с тех пор перезаписаны на месте, а запускавший всё сотрудник уволился. Спроектируйте пайплайн обучения, при котором такой запрос становится рутиной: укажите, что именно должно версионироваться и как адресуется каждый элемент, как гарантировать пересборку обучающей таблицы на исходный момент времени и какой артефакт вы передадите регулятору как доказательство совпадения перезапуска с оригиналом.
Версионируйте неизменяемо пять вещей — ревизию кода, снимок данных, определения признаков, конфигурацию с сидами и образ окружения. Обучающая таблица пересобирается запросами на момент времени по только дописываемым данным. Доказательство — манифест запуска с хешем артефакта.
Типичные ошибки
- ✗Версионировать код, но не снимок данных, из-за чего перезапуск незаметно учится на других строках
- ✗Фильтровать текущие таблицы по дате и звать это пересборкой на момент времени после перезаписи
- ✗Забыть образ окружения и сиды, из-за чего перезапуск получается близким, но не идентичным
Уточняющие вопросы
- →Какие источники недетерминированности переживают фиксированный сид и как их ограничить?
- →Как общие определения признаков делают старый запуск не только повторяемым, но и объяснимым?
