Как ответить
На практике чаще всего берём сырые данные в качестве основы, а агрегаты — только как вспомогательный источник. Сырые данные дают гибкость, потому что я сам контролирую, как и когда их обрабатывать, какие признаки вытаскивать и какие допущения закладывать. Готовые агрегаты экономят время, но несут риски скрытого сдвига распределения или leak'ов, если их кто-то собрал с целевым знанием.
В моём последнем проекте по прогнозированию времени ответа на платежи у нас были сырые логи транзакций: timestamp, сумма, статус, id отправителя и получателя. Оттуда я вытаскивал признаки сам — скользящие медианы за N минут, долю успешных транзакций за окно, количество уникальных получателей отправителя в час. Агрегаты, которые нам в готовом виде поставляла команда биллинга, например «среднее время обработки платежа по валютной паре за последний день», я брал осторожно: проверял, не заглядывает ли этот признак в будущее. Если агрегат обновляется с задержкой в реальном времени, его не стоит использовать в продакшене.
Важный нюанс — сырые данные нужно явно валидировать: дропать дубликаты, обрабатывать пропуски, проверять временные метки на инверсию. Иначе грязные фичи — грязная модель. Готовые агрегаты проходят precompute, но их семантика редко документирована, и только отладка на истории показывает, где они сломаны.
- Основной поток: сырые логи → feature engineering → признаки (скользящие статистики, лаги, энкодинги).
- Агрегаты беру только с проверкой временных рамок: агрегат по d-1, а не по всё-время-включая-сегодня.
- Обязательный этап: ретроспективный расчёт фич на исторических данных, с отставанием симуляции времени (без peek 'в будущее).