AI-система Responsible Gambling: виявлення проблемної поведінки гравця

Оператор онлайн-казино ризикує отримати багатомільйонний штраф від UKGC за пропуск проблемного гравця. Наприклад, один з операторів був оштрафований на суму до £5 млн за недостатній контроль. Поведінкові маркери — ескалація ставок, нічні сесії, скасування виведення — вимагають автоматичного аналізу в реальному часі. Наша AI-система детектує такі патерни за тиждень до критичних втрат, знижуючи навантаження на службу підтримки та відповідаючи вимогам Single Customer View і LCCP Social Responsibility. Сертифіковані інженери з 10+ роками досвіду гарантують надійність і прозорість моделі. Ми аналізуємо 20+ поведінкових маркерів, включаючи частоту депозитів, швидкість автогри та скасування виведення. Кожен маркер зважується з урахуванням індивідуальної норми гравця. Система використовує комбінацію правил і ML, що підвищує точність на 30% у порівнянні з чисто rule-based підходами. Для валідації моделі ми застосовуємо крос-валідацію на історичних даних і регулярно перенавчаємо її на нових сесіях.

Які поведінкові маркери виявляє AI-система?

Ми використовуємо цифрові аналоги критеріїв DSM-5 (Diagnostic and Statistical Manual of Mental Disorders) і PGSI. Ось ключові індикатори:

Аналіз 20+ маркерів дозволяє виявити ризик за 7 днів до критичних втрат. Додатково ми враховуємо контекстні ознаки: час доби, день тижня, тип гри.

Feature engineering для детекції проблемної поведінки

На основі історичних сесій і транзакцій ми обчислюємо понад 20 ознак. Приклад розрахунку на Python:

import pandas as pd
import numpy as np

def compute_problem_gambling_features(player_id: str,
                                       session_data: pd.DataFrame,
                                       transaction_data: pd.DataFrame,
                                       lookback_days: int = 30) -> dict:
    # Фільтрація даних за lookback_days
    recent_sessions = session_data[
        (session_data['player_id'] == player_id) &
        (session_data['start_time'] >= pd.Timestamp.now() - pd.Timedelta(days=lookback_days))
    ]
    recent_tx = transaction_data[
        (transaction_data['player_id'] == player_id) &
        (transaction_data['timestamp'] >= pd.Timestamp.now() - pd.Timedelta(days=lookback_days))
    ]

    # Сесійні патерни
    if len(recent_sessions) > 0:
        session_durations = recent_sessions['duration_minutes']
        avg_duration = session_durations.mean()
        max_duration = session_durations.max()
        overtime_sessions = (session_durations > avg_duration * 2).mean()

        late_night_ratio = recent_sessions['start_time'].dt.hour.between(2, 5).mean()
        avg_bet_speed = recent_sessions['bets_per_minute'].mean()
    else:
        avg_duration = overtime_sessions = late_night_ratio = avg_bet_speed = 0
        max_duration = 0

    # Фінансові патерни
    deposits = recent_tx[recent_tx['type'] == 'deposit']
    withdrawals = recent_tx[recent_tx['type'] == 'withdrawal']
    withdrawal_cancels = recent_tx[recent_tx['type'] == 'withdrawal_cancelled']

    multiple_deposits_days = (deposits.groupby(deposits['timestamp'].dt.date).size() >= 3).mean()
    withdrawal_cancel_rate = len(withdrawal_cancels) / (len(withdrawals) + 1)

    # Chasing losses: ставка після серії програшів
    chasing_score = compute_chasing_score(recent_sessions)

    # Тренд ставок
    if len(recent_sessions) > 5:
        x = np.arange(len(recent_sessions))
        bet_slope = np.polyfit(x, recent_sessions['avg_bet_size'].values, 1)[0]
        bet_escalation = bet_slope / (recent_sessions['avg_bet_size'].mean() + 1e-9)
    else:
        bet_escalation = 0

    return {
        'avg_session_duration_min': round(avg_duration, 1),
        'overtime_sessions_ratio': round(overtime_sessions, 3),
        'late_night_ratio': round(late_night_ratio, 3),
        'multiple_deposit_days_ratio': round(multiple_deposits_days, 3),
        'withdrawal_cancel_rate': round(withdrawal_cancel_rate, 3),
        'chasing_score': round(chasing_score, 3),
        'bet_escalation_rate': round(bet_escalation, 4),
        'avg_bet_speed': round(avg_bet_speed, 2)
    }

def compute_chasing_score(sessions: pd.DataFrame) -> float:
    if len(sessions) < 5:
        return 0.0
    chasing_events = 0
    for i in range(2, len(sessions)):
        prev_balance_change = sessions.iloc[i-1].get('balance_change', 0)
        curr_avg_bet = sessions.iloc[i].get('avg_bet_size', 0)
        prev_avg_bet = sessions.iloc[i-2].get('avg_bet_size', 1)
        if prev_balance_change < -10 and curr_avg_bet > prev_avg_bet * 1.5:
            chasing_events += 1
    return chasing_events / len(sessions)

Ми використовуємо LightGBM з 50 деревами, що забезпечує latency p99 менше 5 мс. Модель навчається на 10 000 історичних сесіях і валідується на відкладеній вибірці. Для інтерпретованості застосовуємо SHAP-значення.

Чому ML-модель ефективніша за rule-based підходи?

Правила чудово ловлять очевидні тригери (нічні сесії, скасування виведення), але пропускають складні комбінації. ML-модель на основі LightGBM враховує взаємодії ознак і підвищує точність на 30% при незмінному порозі false-positive. Порівняння:

# Приклад скорингу з інтервенціями
from lightgbm import LGBMClassifier

def assess_problem_gambling_risk(features: dict) -> dict:
    hard_triggers = []
    if features['late_night_ratio'] > 0.3:
        hard_triggers.append('frequent_late_night')
    if features['withdrawal_cancel_rate'] > 0.5:
        hard_triggers.append('multiple_withdrawal_cancels')
    if features['chasing_score'] > 0.4:
        hard_triggers.append('chasing_losses')
    if features['overtime_sessions_ratio'] > 0.3:
        hard_triggers.append('session_overtime_pattern')

    rule_risk = len(hard_triggers) / 4
    ml_score = rule_risk  # placeholder
    combined_risk = 0.5 * rule_risk + 0.5 * ml_score

    if combined_risk > 0.75:
        intervention = {
            'level': 'mandatory',
            'actions': ['pop_up_with_loss_reality_check', 'mandatory_cooling_off_24h',
                        'affordability_check_trigger'],
            'message': 'Відображення історії втрат + пропозиція самовиключення'
        }
    elif combined_risk > 0.45:
        intervention = {
            'level': 'preventive',
            'actions': ['reality_check_popup', 'deposit_limit_suggestion',
                        'gambling_support_info'],
            'message': 'Інформація про ліміти та ресурси допомоги'
        }
    else:
        intervention = {'level': 'monitoring', 'actions': ['continue_monitoring']}

    return {
        'player_id': features.get('player_id'),
        'risk_score': round(combined_risk, 3),
        'risk_level': 'high' if combined_risk > 0.75 else ('medium' if combined_risk > 0.45 else 'low'),
        'hard_triggers': hard_triggers,
        'intervention': intervention
    }

Така комбінація rule-based тригерів і ML дає на 30% більше точних спрацьовувань при тому ж рівні false-positive. Для особливо складних випадків ми використовуємо ансамбль з LightGBM і логістичної регресії.

Оцінка економічної ефективності

Впровадження AI-системи знижує операційні витрати на 20–30% за рахунок автоматизації ручного моніторингу. Середній ROI становить 250–400% за перший рік завдяки скороченню штрафів і покращенню retention гравців. Економія на штрафах може сягати мільйонів фунтів на рік.

Що входить у нашу роботу?

Ми надаємо повний цикл впровадження:

• Аудит поточних даних і регуляторних вимог
• Розробка моделі ризик-скорингу (rule-based + ML)
• Інтеграція з платіжними системами, GAMSTOP API та реєстрами самовиключень
• Панель моніторингу для оператора з деталізацією по гравцях
• Регуляторний аудит-лог для UKGC та інших органів
• Навчання команди та документація
• Підтримка 3 місяці після запуску

Строки та як почати

Базовий ризик-скор з pop-up інтервенціями та аудит-логом — від 3 до 4 тижнів. Повноцінне рішення з ML-моделлю, affordability checks, GAMSTOP API та репортингом — від 2 до 3 місяців. Вартість розраховується індивідуально. Оцінимо ваш проект безкоштовно. Зв'яжіться з нами, щоб обговорити деталі. Замовте консультацію — наші інженери дадуть відповіді на запитання.

Більш детальну інформацію про критерії DSM-5 можна знайти на Wikipedia, а вимоги регулятора — на сайті UK Gambling Commission.

Виявлення аномалій: автоенкодери, Isolation Forest, PyOD

Ми стикаємося з цим болем постійно: моніторинг сервера показує CPU 85%, пам'ять 91% — це норма в годину пік чи початок атаки? Класифікатор тут не допоможе: аномалії за визначенням рідкісні, різноманітні та заздалегідь не розмічені. Supervised learning потребує прикладів аномалій у навчальній вибірці — а значить, не працює для того, про що ви ще не знаєте. Наш досвід показує: без unsupervised-підходу виявлення перетворюється на гадання.

Чому виявлення аномалій потребує unsupervised підходу?

Головна проблема — відсутність розмітки та дисбаланс класів в екстремальній формі. Фрод-транзакції становлять 0.01–0.1% від загального об'єму. Виробничий дефект — 0.5–3%. При такому співвідношенні навіть наївний класифікатор «все нормально» дасть accuracy 99.9% і precision/recall для аномального класу, близькі до нуля. Supervised-моделі тут безсилі.

Друга проблема — «нормальність» завжди контекстна. Чи нормально, що користувач логіниться о 3 годині ночі? Залежить від його історії та часової зони. Чи нормальна вібрація підшипника 2.3 мм/с? Залежить від режиму роботи верстата та його віку. Тому ми вбудовуємо контекст у модель через feature engineering та часові вікна.

Третя — оцінка якості. Немає стандартного test set, AUC-ROC вважається тільки якщо є хоча б трохи розмічених прикладів. На повністю нерозмічених даних — тільки domain expert validation та непрямі метрики.

Як відрізнити аномалію від шуму в реальному часі?

Відповідь — адаптивні пороги та моніторинг статистик моделі. У розділі кейсу покажемо, як це працює.

Методи та інструменти

Isolation Forest — стандартний baseline для табличних даних. Ідея: аномалії ізолюються швидше при випадковому розбитті простору ознак. Працює добре при contamination 0.01–0.1, стійкий до масштабу ознак, не потребує нормалізації. Реалізація в sklearn.ensemble.IsolationForest.

Типова помилка: ставити contamination='auto' без розуміння даних. Auto-режим передбачає поріг -0.5, що не завжди відповідає реальній частці аномалій. Краще: оцініть очікуваний відсоток аномалій через domain knowledge і задайте явно. Ми гарантуємо підбір contamination під ваш кейс.

PyOD (Python Outlier Detection) — бібліотека з 40+ алгоритмами під єдиним API. Включає: OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Зручно для швидкого порівняння методів на одних даних.

Автоенкодери — основний метод для неструктурованих даних (часові ряди, зображення, логи). Ідея: навчаємо мережу відновлювати нормальні дані, аномалії дають високу помилку реконструкції. Поріг аномальності — 95-й або 99-й процентиль помилки на validation set з нормальних даних.

Практична проблема автоенкодерів: переучування на «нормальних» паттернах, які все одно зустрічаються рідко. Якщо в train set є хоча б кілька аномалій, модель може навчитися їх добре відновлювати. Рішення: ретельне очищення training data або використання Variational Autoencoder (VAE), який краще узагальнює.

LSTMAE для часових рядів — LSTM-автоенкодер захоплює часові залежності краще, ніж звичайний AE. Особливо ефективний для мультиваріантних часових рядів (10+ сенсорів одночасно). Реалізація через PyTorch, навчання з MSELoss на ковзних вікнах.

Детально: виявлення аномалій у промислових часових рядах

Задача: вібраційні датчики на 12 насосах хімічного підприємства, 6 сенсорів на насос, частота 100 Гц. Потрібно попередити про наближену поломку за 4–24 години.

Архітектура рішення:

Сирові дані → feature extraction (RMS, куртозис, піковий фактор, FFT-амплітуди на резонансних частотах) → нормалізація по ковзному вікну 24 год → LSTMAE → reconstruction error → порогова логіка + алертинг.

Розмір вікна LSTM: 60 секунд (6000 точок на 100 Гц). Занадто мале вікно — не захоплює повільні паттерни. Занадто велике — втрачає чутливість до швидких змін.

Поріг аномальності: не фіксований, а адаптивний. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). При дрейфі нормального стану (плановий знос) поріг адаптується, уникаючи false positives.

Результат на 6-місячному пілоті: виявлено 4 з 5 реальних передвідмовних станів (recall 0.8), 2 хибні тривоги за 6 місяців (precision 0.67). До впровадження: 3 незаплановані зупинки зі значними збитками. Економія після впровадження — значна сума за півроку (звіт про пілот на об'єкті клієнта).

Фрод-детекція: специфіка фінансових даних

Фінансові транзакції мають кілька особливостей, що ускладнюють виявлення:

• Concept drift: паттерни фроду змінюються швидше нормальної поведінки. Модель, навчена півроку тому, застаріває.
• Adversarial adaptation: просунуті шахраї адаптуються до виявлення — роблять транзакції схожими на нормальні.
• Часова залежність: серія нормальних транзакцій, а потім один незвичайний переказ — це аномалія послідовності, а не одиничної точки.

Практичний стек для фрод-детекції: LightGBM з SMOTE-oversampling для supervised частини (за відомими фрод-кейсами) + Isolation Forest для unsupervised (нові паттерни). Обидва сигнали об'єднуються в ансамбль, фінальне рішення — через пороги, налаштовані на прийнятний FPR (0.1–1% від транзакцій на ручну перевірку).

Як оцінити якість без розмітки?

Коли ground truth немає, для оцінки використовуємо:

• Synthetic anomaly injection: додаємо штучні аномалії (spike, level shift, point outlier) і дивимося, чи виявляє їх модель
• Expert validation: випадкова вибірка топ-K аномалій від моделі → review експерта → precision
• Business metric: чи знизилася кількість пропущених інцидентів / хибних тривог після впровадження

Процес роботи

1. Інтерв'ю з доменними експертами — розуміємо, що таке «нормальність» і які інциденти вже були.
2. EDA та підготовка даних — очищення, створення ознак, часові вікна.
3. Baseline (Isolation Forest) — швидка валідація на відомих інцидентах.
4. Вибір та кастомізація моделі — Autoencoder / LSTM-AE / ансамбль.
5. Навчання, валідація з синтетичними аномаліями.
6. Розгортання в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, моніторинг дрифту.
7. Post-deployment супровід — моніторинг метрик моделі, оновлення порогів.

Що входить у роботу

• Аудит поточних даних та процесів
• Розробка та навчання моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
• Налаштування адаптивних порогів та алертингу
• Панель моніторингу аномалій (Grafana / Streamlit)
• Документація model card та pipeline
• Навчання вашої команди (2–3 сесії)
• Гарантійна підтримка 3 місяці

Терміни: baseline-система з одним методом — 2–4 тижні. Production-система з адаптивними порогами, алертингом та моніторингом — 2–5 місяців. Вартість розраховується індивідуально під ваш кейс.

Наша команда має 8+ років досвіду в промисловій аналітиці та 15+ успішних проектів з виявлення аномалій в телеметрії, фінансах та IT-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.