Как доставались дополнительные фичи
Что проверяют
Вопрос о вашем реальном опыте: откуда брались признаки сверх исходной выборки, как вы их доставали и как проверяли, что они помогают. За ним стоит проверка на утечку данных и на то, доедет ли признак до продакшена. Следом обычно спрашивают: «А этот признак был доступен в момент предсказания?»
Как отвечать
Стройте рассказ на своём проекте, по шагам:
- источник: внутренние таблицы и логи (история заказов, клики, обращения в поддержку), внешние данные (погода, календарь праздников, геоданные, курсы валют), ручная разметка. Назовите, кто владел данными и как вы получили доступ;
- как доставали: SQL-витрины, джобы в Spark под Airflow, запросы к внешнему API с кэшированием, feature store вроде Feast, если он был. Отдельно расскажите про историю: признак нужно восстановить на каждую дату обучения;
- корректность по времени: point-in-time join, когда к каждой строке присоединяется только то, что было известно на её момент. Для погоды это прогноз, а не фактическая температура;
- проверка пользы: сравнение с базовой моделью на валидации, разбитой по времени, абляция групп признаков, важности через SHAP или перестановки;
- цена в проде: задержка получения, доступность источника, поведение модели, если признак не пришёл.
Результат называйте своей метрикой и с базой: «MAE упала с такого-то значения до такого-то на отложенном периоде», а не круглый процент без контекста. Если признаки вам давали готовыми, скажите честно и расскажите, как проверяли их качество и что добавили бы сами.
Где спотыкаются
Допускают утечку: признак считается по данным из будущего, например по итоговому статусу заказа. На валидации модель выглядит отлично, в проде падает.
Меряют прирост на случайном разбиении временного ряда. Соседние дни попадают и в обучение, и в тест, и польза нового признака оказывается завышенной.
Рассказывают только про инженерную часть и не упоминают расхождение между обучением и инференсом: в офлайне признак считался одним SQL, в онлайне другим кодом, и значения разъехались.