ML-инженер: вопросы и ответы для собеседования

Образец ответа

Я ML-инженер с фокусом на production-задачи: от подготовки данных и обучения моделей до их внедрения, мониторинга и последующего улучшения. Мне интересно соединять ML и software engineering, потому что ценность появляется не в ноутбуке, а в устойчивом сервисе с понятным SLA. Я привык работать в связке с backend, аналитиками и продуктом, чтобы решение давало измеримый эффект.

Образец ответа

Сначала я уточняю цель: что именно считаем успехом, какие есть ограничения по latency, стоимости и интерпретируемости. Затем сравниваю несколько baseline-решений, от простых правил и линейных моделей до более сложных подходов, если они действительно нужны. Для production я выбираю не «самую умную» модель, а ту, которая стабильно даёт нужное качество, легко поддерживается и укладывается в бюджет по инфраструктуре.

Образец ответа

Я начинаю с контроля источников данных, валидации схемы, диапазонов значений и пропусков. Для признаков критично избежать training-serving skew, поэтому я стараюсь использовать единый пайплайн вычисления признаков и, где уместно, feature store. Ещё я проверяю point-in-time correctness, чтобы в train не попадала информация из будущего, и добавляю тесты на аномалии и дрейф.

Образец ответа

Я смотрю не на одну метрику, а на набор показателей, которые связаны с бизнесом: precision/recall, ROC-AUC, PR-AUC, calibration, а для ранжирования — NDCG или MAP. Затем я проверяю метрики по сегментам, чтобы увидеть слабые места на разных группах данных. Если задача чувствительна к ошибкам, я оцениваю стоимость false positive и false negative и сверяю offline-результат с ожидаемым online-эффектом.

Образец ответа

Сначала я смотрю на мониторинг: данные на входе, распределение предсказаний, latency, ошибки сервиса и, если уже есть разметка, фактическое качество. Дальше проверяю, что именно изменилось — данные, upstream-пайплайн, поведение пользователей или сам код. Если причина в drift, я решаю, нужен ли быстрый rollback, hotfix, дообучение или пересборка признаков; для снижения риска полезны canary и shadow deployment.

Training-serving skew возникает, когда признаки или preprocessing в обучении и в inference отличаются, из-за чего модель на проде работает хуже, чем в экспериментах. Причина часто в том, что логика вычисления признаков продублирована и разошлась. Я снижаю риск за счёт общего кода трансформаций, feature store, тестов на совпадение значений и контроля схемы данных между train и serve.

Batch inference считает прогнозы пакетно по расписанию, например ночью, и подходит для больших объёмов данных, когда важнее throughput, чем мгновенный ответ. Online inference выдаёт прогноз в реальном времени на запрос пользователя и требует низкой latency, высокой доступности и строгого контроля ресурсов. Выбор зависит от продукта: для рекомендаций и антифрода часто нужны оба режима.

Feature store — это централизованное хранилище и слой управления признаками, который помогает единообразно считать, версионировать и отдавать features для обучения и inference. Он уменьшает дублирование, помогает избежать training-serving skew и упрощает повторное использование признаков между разными моделями. Особенно полезен в командах, где несколько ML-проектов работают на одних и тех же данных.

Я связываю метрику с задачей и стоимостью ошибки. Для классификации на несбалансированных данных accuracy почти всегда недостаточна, поэтому я чаще смотрю precision, recall, F1, PR-AUC и calibration; для ranking — NDCG, MAP или CTR-метрики. Если есть несколько сегментов пользователей, я дополнительно считаю метрики по срезам, чтобы не потерять качество на важной группе.

Bagging обучает несколько моделей независимо на разных bootstrap-выборках и усредняет их ответы, снижая variance. Boosting обучает модели последовательно: каждая новая исправляет ошибки предыдущих, что обычно снижает bias и повышает качество. На практике boosting часто даёт сильный результат, но может быть чувствительнее к переобучению и сложнее в эксплуатации.

Я бы сначала проверил, нет ли training-serving skew, и сравнил реальные online-признаки с теми, что были в обучении. Затем посмотрел бы на изменения в данных, сегментах пользователей и качестве upstream-пайплайна. В одном проекте проблема оказалась именно в различии расчёта признака онлайн и офлайн; после унификации логики и добавления проверок качество в production вернулось к ожидаемому уровню.

Я бы начал с простого baseline и собрал максимум пользы из имеющейся разметки: weak supervision, active learning, data augmentation и аккуратную работу с правилами. Если задача допускает это, можно использовать transfer learning или pre-trained модели. Параллельно я бы помогал продукту улучшать процесс разметки, чтобы со временем качество данных стало лучше, а не только модель.

Я бы сначала зафиксировал целевой budget по latency и стоимости, а потом смотрел на узкие места: размер модели, preprocessing, I/O и инфраструктуру. Часто помогают quantization, distillation, caching, batching и упрощение признаков. Если компромисс по качеству приемлем, лучше сделать более лёгкую модель, которая стабильно работает в production, чем держать точную, но слишком медленную.

Я стараюсь описать понятный inference contract: входные поля, формат ответа, ошибки, SLA, версии модели и правила fallback. Для backend важны предсказуемость и документация, поэтому я отдельно фиксирую preprocessing, зависимость от external services и сценарии отказа. Обычно хорошо работает совместный code review и этап интеграции через staging, где мы заранее ловим несовместимости.