Feature engineering в Data Science: зачем нужны признаки

Почему хорошие признаки часто важнее, чем сложная модель

Новичок обычно воспринимает признак как «еще одну колонку». Но в реальной задаче признак — это гипотеза о механике процесса. Если ты строишь `revenue_per_session`, ты говоришь модели: мне кажется, не абсолютная выручка важна сама по себе, а то, как она распределена на взаимодействие. Если ты считаешь число покупок за последние семь дней, ты предполагаешь, что недавняя активность несет сигнал о будущем поведении.

Именно поэтому feature engineering стоит воспринимать не как декоративную доработку датасета, а как момент, в котором Data Science начинает по-настоящему переводить реальность в язык модели.

Как появляются действительно полезные признаки

Полезный признак редко рождается из слепого перебора операций. Обычно он выходит из понимания процесса. В продуктовой задаче нужно подумать, как ведет себя пользователь во времени. В финансовой — как соотносятся абсолютные и относительные величины. В логистике — как маршрут, расстояние и тип объекта влияют на итог. То есть хороший feature engineering начинается не с библиотеки, а с вопроса: какая скрытая величина может стоять за наблюдаемыми столбцами.

Именно поэтому хороший Data Scientist много разговаривает с доменом. Модель учится на таблице, но признак придумывается на стыке данных и предметной логики.

А когда признаки уже придуманы и модель обучена, появляется следующий важный вопрос: какие из них реально влияют на предсказание, а какие просто создают ощущение полезности. Поэтому эту тему удобно продолжать через feature importance, где инженерия признаков встречается с интерпретацией модели.

Что чаще всего делают зря

Есть соблазн породить как можно больше столбцов: логарифмы, квадраты, бины, взаимодействия, rolling-метрики, лаги, индикаторы. Иногда это помогает, но часто превращает проект в шум. Особенно если новый признак не проверен на валидации и просто увеличивает размерность без прироста качества. Feature engineering — это не соревнование по количеству колонок, а поиск устойчивых представлений данных.

Это особенно заметно, когда речь заходит о категориальных данных. Там кажется, что достаточно просто превратить столбец в набор индикаторов, но на практике и сама схема кодирования влияет на размерность, устойчивость и читаемость пространства признаков. Поэтому рядом полезно разобрать и one-hot encoding как частный, но очень частый случай feature engineering.

Еще одна частая ошибка — создавать признаки, которые невозможно честно посчитать на момент предсказания. Такой столбец может сделать train красивым, но в проде окажется недоступным. Это уже не feature engineering, а скрытая leakage.

Поэтому рядом особенно полезно держать и отдельный разбор data leakage. Он хорошо показывает, где инженерия признаков перестает усиливать модель и начинает незаметно подглядывать в ответ.

Как это выглядит в Python

import pandas as pd  # работаем с табличными данными и новыми признаками

events = pd.DataFrame({  # создаем простую таблицу пользовательских событий
    'user_id': [1, 1, 2, 2, 3],  # идентификатор пользователя
    'sessions': [3, 5, 2, 4, 6],  # количество сессий за период
    'revenue': [1200, 1800, 500, 900, 2400],  # выручка пользователя
    'days_from_last_visit': [2, 1, 10, 4, 0]  # давность последнего визита
})

events['revenue_per_session'] = events['revenue'] / events['sessions']  # строим среднюю ценность одной сессии
events['is_recent_user'] = (events['days_from_last_visit'] <= 3).astype(int)  # отделяем недавних пользователей от ушедших
events['activity_score'] = events['sessions'] / (events['days_from_last_visit'] + 1)  # объединяем частоту и свежесть поведения

print(events.round(2))  # смотрим, как новые признаки меняют представление о пользователях

Здесь каждый новый столбец выражает содержательную идею. Один показывает эффективность взаимодействий, другой — свежесть контакта, третий — комбинирует интенсивность и давность. Это уже больше похоже на настоящее feature engineering, чем просто механическое копирование исходных значений.

А если смотреть на эту работу уже не как на разовый ноутбук, а как на стабильный production-процесс, то следующим естественным уровнем становится feature store. Там становится видно, как придуманные признаки превращаются в воспроизводимый слой данных, а не теряются между ноутбуком и продом.

Дальше уже встает вопрос, какие из придуманных признаков вообще стоит оставлять в модели. Поэтому естественным продолжением этой темы становится feature selection, где речь идёт уже не о создании сигналов, а о том, как не утонуть в их избытке.