Middle Data Scientist — Вопросы на собеседовании data scientist

Расскажите, как бы вы выбирали фичи для модели оттока и избегали утечки данных.

Начните с того, что реально известно в момент предсказания: фича, посчитанная по данным, существующим только после исхода (например, «дни с момента открытия письма об отмене подписки», если такое письмо отправляется уже после того, как человек решил уйти), протаскивает метку прямо во вход и даёт модель, которая отлично выглядит офлайн и падает в проде. После исключения утечек список сужают доменными знаниями, корреляцией с таргетом и чем-то вроде permutation importance, а затем проверяют мультиколлинеарность среди оставшихся вместо того, чтобы доверять одной метрике важности в отрыве от остальных.

Как работает k-fold кросс-валидация и почему одного разбиения train/test недостаточно?

Данные делят на k блоков, обучают на k-1 из них и валидируют на оставшемся, затем прогоняют все k комбинаций и усредняют результаты. Одно разбиение даёт одну шумную оценку, сильно зависящую от того, какие строки попали в тест, — удачное или неудачное разбиение может представить посредственную модель отличной, а хорошую — плохой. Кросс-валидация меняет вычислительные затраты на куда более стабильную оценку обобщающей способности модели, и именно её используют для честного сравнения моделей перед выбором.

Как бы вы спроектировали A/B-тест для изменения, которое подозрительно даёт малый эффект на малотрафиковой странице?

Малый ожидаемый эффект при низком трафике — худшее сочетание для статистической мощности, поэтому первый шаг — проверить по расчётам, реализуем ли тест вообще за разумное время, а не проектировать его в надежде на удачу. Если нет, честные варианты — расширить целевую аудиторию, увеличить длительность, перейти на более чувствительную метрику (непрерывную прокси-метрику вместо бинарной конверсии) или согласиться на больший минимальный детектируемый эффект и явно проговорить, что более мелкие реальные эффекты останутся незамеченными.

Когда вы возьмёте оконную функцию, а не подзапрос, чтобы посчитать накопительный итог в SQL?

Оконная функция вроде SUM(amount) OVER (PARTITION BY customer_id ORDER BY order_date) считает накопительный итог за один проход, не схлопывая строки, и большинство планировщиков запросов оптимизируют её куда лучше эквивалентного коррелированного подзапроса, пересканирующего предыдущие строки для каждой выходной строки. Подход с подзапросом ещё встречается в старых кодовых базах и как «наивный» ответ на собеседовании — умение вовремя его заменить само по себе сигнал зрелости в SQL.

Вы показываете продакт-менеджеру модель с точностью 92%, и он хочет её выкатить. Что проверить, прежде чем соглашаться?

Сначала — баланс классов: если 92% данных относится к мажоритарному классу, модель, всегда предсказывающая мажоритарный класс, тоже даст 92% accuracy, будучи бесполезной, поэтому precision, recall и confusion matrix по классам важнее одной accuracy. Второе — совпадает ли метрика с реальной бизнес-ценой: для детекции мошенничества ложноотрицательный дорог, а ложноположительный — мелкая неприятность, так что порог сдвигают в сторону recall даже ценой формальной accuracy, и об этом говорят явно до того, как модель выкатят.