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

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

Есть старая и очень жизненная истина в Data Science: слабая модель на хороших признаках часто побеждает сильную модель на плохих. Это не значит, что алгоритм не важен. Это значит, что модель не может из пустоты извлечь ту структуру, которой нет в данных. Feature engineering — это работа над тем, чтобы наблюдения стали ближе к задаче и понятнее для алгоритма.

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

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

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

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

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

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

Еще одна частая ошибка — создавать признаки, которые невозможно честно посчитать на момент предсказания. Такой столбец может сделать train красивым, но в проде окажется недоступным. Это уже не feature engineering, а скрытая 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, чем просто механическое копирование исходных значений.