Feature Engineering і відбір ознак
1) Призначення та принципи
Мета: сконструювати стійкі, інтерпретовані та економічні ознаки, узгоджені між офлайном і онлайном.
Принципи:- Point-in-time: фічі обчислюються з даних, доступних на момент рішення, без майбутнього (anti-leakage).
- Domain-first: фічі відображають бізнес-механіки (депозити, сесії, жанри ігор, RG/AML).
- Reuse & Contracts: фічі - версії, власники, формули і SLO в Feature Store.
- Cost-aware: вважаємо latency і вартість обчислення/зберігання → матеріалізуємо тільки окупне.
- Observability: моніторимо дрейф/стабільність/калібрування; тест еквівалентності online/offline.
2) Таксономія ознак для iGaming
RFM/поведінкові: recency/frequency/monetary по вікнах (10м/1ч/1д/7д/30д).
Сесійні: тривалості, паузи, зміни пристроїв/ASN, швидкість дій.
Фінансові: депозити/висновки/чарджбеки, частки методів оплати, FX-нормалізація.
Ігрові: жанрові профілі, волатильність провайдерів, RTP-кластери, win-streak.
Маркетингові: канали/UTM, відгуки на кампанії, saturation/cooldown.
RG/AML: ліміти, прапори самовиключень, velocity-патерни, повторне використання BIN/IP.
Гео/час: локальні календарі/свята, година поясів, вечір/ніч.
Графові: зв'язку user-card-device-ip, центральності/компоненти, «кільця» фроду.
NLP/тексти: теми і тональність тікетів/чатів; ключові скарги.
Операційні: лаг/помилки провайдерів, стабільність сесій (для SRE-моделей).
3) Вікна та агрегати (point-in-time)
Типові вікна: 10м/1ч/24ч/7д/30д. Для кожного вікна - count/sum/mean/std/last/max/min, ratio і rate.
SQL-шаблон (30д депозити, без майбутнього):sql
SELECT u.user_pseudo_id, t.asof,
SUM(CASE WHEN e.type='deposit'
AND e.event_time>=t.asof - INTERVAL '30' DAY
AND e.event_time< t.asof THEN e.amount_base ELSE 0 END) AS dep_30d,
COUNT(CASE WHEN e.type='bet'
AND e.event_time>=t.asof - INTERVAL '7' DAY
AND e.event_time< t.asof THEN 1 END) AS bets_7d
FROM silver.fact_events e
JOIN (SELECT user_pseudo_id, DATE(event_time) AS asof
FROM silver.fact_events GROUP BY 1,2) t USING(user_pseudo_id)
JOIN dim.users_scd u ON u.user_pseudo_id=t.user_pseudo_id
AND t.asof >= u.valid_from AND (u.valid_to IS NULL OR t.asof < u.valid_to)
GROUP BY 1,2;
4) Категоріальні кодування
One-Hot/Hashing: для рідкісних/високо-кардинальних категорій (ігри, провайдери).
Target Encoding (TE): середні по таргету з k-fold/leave-one-out і time-aware згладжуванням (anti-leakage).
WOE/IV (ризик-скоринг): монотонні біни з контролем IV і стабільності.
python for fold in time_folds:
train_idx, val_idx = split_by_time(fold)
te_map = target_mean(train[["provider_id","label"]])
val["provider_te"] = val["provider_id"].map(te_map).fillna(global_mean)
5) Нормалізація та скейлінг
Мін-макс/Robust/Z-score - по тренувальному вікну; зберігаємо параметри в артефактах.
Лог-перетворення для довгих хвостів сум/ставок.
Box-Cox/Yeo-Johnson - коли потрібна симетризація.
6) Тимчасові та сезонні фічі
Календарні: день тижня, година, свято ринку (ref. calendar), pay-day.
Періодичність: ковзаючі середні/експон. згладжування (EMA), deltas (t − t-1).
Event-based: час з останнього депозиту/виграшу/програшу, «охолодження».
7) Графові ознаки (фрод/AML)
Вершини: user/card/device/ip. Ребра: транзакції/сесії/спільні ознаки.
Фічі: розмір компоненти, degree, betweenness, pagerank, triads, повторна поява.
Шаблон: nightly batch будує граф → ембеддинги/центральності → online кеш.
8) NLP-фічі (саппорт/чати/рев'ю)
Базово: TF-IDF/NMF теми, sentiment, довжина, частоти скарг.
Просунуто: ембеддинги (Sentence-BERT) → усереднення за тікетами за вікно.
PII: до- і пост-маскування (email, PAN, телефони) по політиках.
9) Гео/ASN і пристрої
IP→Geo/ASN: кешуємо та оновлюємо; не робити синхронних запитів в онлайні без таймауту/кешу.
Фічі: стабільність ASN/DeviceID, частота змін, відстань між логінами.
10) Anti-Leakage і узгодження online/offline
Point-in-time join, ніяких майбутніх подій у вікнах/лейблах.
Один код трансформацій (library) для офлайну та онлайну.
Тест еквівалентності: на вибірці T порівнюємо онлайн-значення фіч з офлайном (MAE/MAPE).
yaml name: deposits_sum_10m owner: ml-risk slo: {latency_ms_p95: 20, availability: 0.999}
offline:
source: silver.payments transform: "SUM(amount_base) OVER 10m BY user_pseudo_id"
online:
compute: "streaming_window: 10m"
tests:
- compare_online_offline_max_abs_diff: 0.5
11) Відбір ознак (feature selection)
11. 1 Filter
11. 2 Wrapper
RFE/Sequential FS: на маленьких наборах/логістичній регресії.
Stability Selection: стійкість при бутстреп-семплінгу.
11. 3 Embedded
L1/Lasso/ElasticNet: розрідження.
Дерева/GBDT: importance/SHAP для відбору та бізнес-інтерпретації.
Group Lasso: груповий відбір (набори бін-фіч однієї змінної).
python
X = preprocess(raw) # one-hot/TE/scale
X = drop_const_and_corr(X, thr=0.95)
rank_mi = mutual_info_rank(X, y)
keep1 = topk(rank_mi, k=200)
model = LGBMClassifier(...)
model.fit(X[keep1], y)
shap_vals = shap.TreeExplainer(model).shap_values(X[keep1])
keep2 = stable_topk_by_shap(shap_vals, k=60, bootstrap=20)
final = keep2
12) Стійкість, дрейф і калібрування
Drift: PSI/KS за фічами і швидкістю; алерти при перевищенні порогів.
Стабільність: стежимо за «крихкими» TE/WOE (кардинальність/зрушення).
Калібрування: Platt/Isotonic; звіти reliability.
Slice-аналіз: ринки/провайдери/пристрої - бенчмарки метрик і очікуваної вартості помилок.
13) Cost-інжиніринг і продуктивність
Cost per Feature (CPF): CPU/IO/мережа/зберігання → бюджет на модель.
Матеріалізація: важкі offline, легкі online; TTL/кеш для гарячих фіч.
Віддалені lookups: тільки async + кеш; p95 <20-30 мс на фічі в онлайні.
Chargeback: облік вартості фіч/інференсу за командами.
14) Feature Store (ядро узгодженості)
Реєстр: ім'я, формула, власник, SLO, тести, версії.
Online/Offline синхронізація: один код трансформацій, тест рівності.
Логи/аудит: хто змінював формулу; вплив версії на метрики моделі.
15) Приклади
ClickHouse: хвилинні агрегати ставок:sql
CREATE MATERIALIZED VIEW mv_bets_1m
ENGINE = SummingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), user_pseudo_id)
AS
SELECT toStartOfMinute(event_time) AS ts_min,
user_pseudo_id,
sum(stake_base) AS stake_sum_1m,
count() AS bets_1m
FROM stream.game_events
GROUP BY ts_min, user_pseudo_id;
Anti-correlation drop (SQL-ідея):
sql
-- вычислить корреляции и удалить пары с ρ >0.95, сохранив более «дешевую» фичу
WOE бінінг (ескіз):
python bins = monotonic_binning(x, y, max_bins=10)
woe = compute_woe(bins)
iv = compute_iv(bins)
16) Процеси і RACI
R (Responsible): Data Eng (конвеєри/Feature Store), Data Science (дизайн фіч/відбір/метрики).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/DPO (PII, residency), Risk/AML/RG (правила), SRE (SLO/вартість), Security.
I (Informed): Продукт/Маркетинг/Операції/Підтримка.
17) Дорожня карта
MVP (3-5 тижнів):1. Каталог топ-50 фіч (Payments/Gameplay) з point-in-time формулами.
2. Feature Store v1 (online/offline) + тест еквівалентності.
3. Базовий відбір: константи/кореляції → MI → L1/SHAP shortlist (до 60 фіч).
4. Моніторинг дрейфу фіч і cost-дашборд.
Фаза 2 (5-10 тижнів):- TE/WOE з time-aware валідацією, графові та календарні фічі.
- Slice-аналіз і fairness, калібрування ймовірностей.
- Матеріалізація важких офлайн фіч, кеш онлайну, квоти.
- Автогенерація документації фіч, stability-selection в CI.
- Авто-деактивація «дорогих і марних» фіч (CPF↑, vklad↓).
- A/B порівняння наборів фіч, звіти expected-cost.
18) Чек-лист перед продом
- Всі фічі мають специфікації (owner, формулу, версії, SLO).
- Пройдено тести point-in-time та еквівалентності online/offline.
- Відбір виконано: filter → embedded (SHAP/L1) → stability.
- Моніторинг дрейфу і reliability налаштований; пороги і алерти є.
- CPF/latency вписуються в бюджет; важкі фічі матеріалізовані.
- ПII-політики дотримані (CLS/RLS, токенізація, резидентність).
- Документація та приклади використання додані до каталогу.
19) Анти-патерни і ризики
Лейкедж (майбутні події/наслідки промо).
Неузгоджені online/offline формули.
Надлишкові one-hot з високо-кардинальних категорій без hashing/TE.
«Дорогі» фічі без вимірного приросту якості.
Відсутність slice/fairness аналізу - приховані деградації.
TE/WOE без time-aware крос-валідації → перенавчання.
20) Підсумок
Feature Engineering - це керована дисципліна: point-in-time, бізнес-сенс, відтворюваність, моніторинг і економіка. Сильні фічі + строгий відбір (filter/wrapper/embedded) і єдиний Feature Store дають стійкі, інтерпретовані і дешеві моделі, які покращують Net Revenue, знижують фрод і підтримують RG - прозоро і комплаєнтно.