#featureengineering #supervisedlearning #standardpractice

Недавно был материал о стандартном подходе к решению ML-задач с разметкой (не хочется использовать термин "с учителем", нет там учителя/супервизора), хотелось бы подробнее остановиться на создании признаков.
Часто бывает, что в модельной задаче есть целые группы признаков, которые относятся к определённой сущности: пользователю, компании, активностям, внешней среде, локациям. Часть из них текстовые, часть графовые. Это всё ещё часто осложняется временной структурой, и надо думать об агрегатах этих всех признаков по некоторым скользящим окнам. Если всё это богатство слепить в одну таблицу, начинают буксовать любые алгоритмы, не говоря уже про требования к железу. Как не сойти с ума во время такой инженерии и добиться осмысленных результатов в рамках бюджета?
Пока я остановился на таком подходе.
1) определяем Cross-Validation schema и метрики
2) настраиваем библу для трекинга, типа neptune или mlflow
3) начинаем с DummyClassifier/Regressor (DummyLags, если у вас timeseries-задача) со всеми доступными strategy. Лучший по метрикам становится baseline-ом.
4) работаем индивидуально по группам, относящимся к отдельным классам сущностей (юзеры, компании, и т.п.), начиная с самых простых
5) также можно работать по признакам, объединённым типом данных, например, все текстовые. это позволит ещё и логично считать межпризнаковые связи, например, расстояния в разных пространствах.
6) на данной группе построенных признаков обучаемся, фиксируем CV метрики, делаем анализ важности признаков, фиксируем барчарт важностей и список как артефакт модели и фичерсета. важность признаков в группе позволяет понять, куда копать дальше, в какие дебри углубляться
7) если это временной ряд, надо строить окна. строим коррелограмму, ориентируемся на пики графика, начинаем с небольших окон.
8) когда все группы пройдены, анализируем важности признаков и принимаем решение о том, в какую сторону углубляться, повторяем цикл с более "тонкими" признаками
9) теперь объединяем группы, пробуем обучаться на всех сразу, и используя Feature Selector (по-прежнему на CV).
10) если остаётся время, пробуем отношения фичей из разных групп, их добавляем к основному датасету и прогоняем тоже через пункт 9

Теперь смотрим в свой трекинг, выбираем лучший вариант по соотношению сложность/качество. Страдает ли этот метод от подгонки? Конечно, ведь мы, принимая решения о новых фичах, заглядываем в метрики. Можно ли этого избежать? Не знаю. Но можно зарезервировать часть данных под OOS, и финальное решение принимать только по этому набору, это уменьшит смещение.