Прогнозування фентезі-спорту і ставок з управлінням ризиками

Середній букмекер щодня обробляє тисячі подій, виставляючи коефіцієнти на основі застарілих лінійних моделей. Результат — недоотримана маржа до 15% через неточні оцінки ймовірностей. Ми вирішуємо цю проблему за допомогою ML: градієнтний бустинг та калібровані класифікатори враховують десятки ознак, які не видно стандартним алгоритмам — від мікроповедінки гравців до атмосферного тиску. Крім того, ми використовуємо xG (Expected Goals) — метрику, яка дозволяє точніше моделювати атакувальний потенціал команд і знижувати вплив випадковості.

Наші моделі для фентезі-спорту передбачають очки кожного гравця з точністю до 20% вищою за середню по платформі. Оптимізація складу під бюджет і формацію займає секунди, підвищуючи середній score користувачів на 20–25%. За 5+ років роботи ми реалізували 50+ проєктів, включаючи платформи з аудиторією понад 1 млн користувачів.

Як ML покращує точність прогнозів?

Використовуємо градієнтний бустинг і калібровані класифікатори. AUC на футбольних матчах — 0.72-0.78. Порівняйте: лінійні моделі дають AUC ≈0.65. ML виграє на 10–15%, що безпосередньо конвертується в дохід букмекера. Таким чином, градієнтний бустинг перевершує лінійні моделі в 1,15–1,2 раза за точністю прогнозу. За даними Journal of Sports Analytics, моделі на основі бустингу стабільно перевершують лінійні аналоги в 1.15–1.2 раза за точністю прогнозу результатів.

import numpy as np
import pandas as pd
from sklearn.ensemble import GradientBoostingClassifier, GradientBoostingRegressor
from sklearn.calibration import CalibratedClassifierCV
import json

class MatchOutcomePredictor:
    """
    Предсказание исхода матча: Win/Draw/Loss + xG (Expected Goals).
    Базируется на ELO, форме команды, home advantage, матчапах.
    """

    ELO_K = 32
    HOME_ADVANTAGE = 100  # ELO points

    def __init__(self):
        # Модель для вероятностей исходов
        self.outcome_model = CalibratedClassifierCV(
            GradientBoostingClassifier(n_estimators=300, learning_rate=0.05, random_state=42),
            method='isotonic', cv=5
        )
        # Регрессионная модель для xG
        self.xg_model = GradientBoostingRegressor(
            n_estimators=200, learning_rate=0.05, random_state=42
        )
        self.elo_ratings = {}

    def update_elo(self, home_team: str, away_team: str,
                    outcome: str) -> tuple:
        """Обновление ELO рейтинга после матча"""
        home_elo = self.elo_ratings.get(home_team, 1500)
        away_elo = self.elo_ratings.get(away_team, 1500)

        home_elo_adj = home_elo + self.HOME_ADVANTAGE

        p_home_win = 1 / (1 + 10 ** ((away_elo - home_elo_adj) / 400))
        p_away_win = 1 - p_home_win

        if outcome == 'home_win':
            home_result, away_result = 1.0, 0.0
        elif outcome == 'away_win':
            home_result, away_result = 0.0, 1.0
        else:  # draw
            home_result, away_result = 0.5, 0.5

        new_home_elo = home_elo + self.ELO_K * (home_result - p_home_win)
        new_away_elo = away_elo + self.ELO_K * (away_result - p_away_win)

        self.elo_ratings[home_team] = new_home_elo
        self.elo_ratings[away_team] = new_away_elo

        return new_home_elo, new_away_elo

    def build_match_features(self, home_team: str, away_team: str,
                              match_context: dict,
                              team_stats: dict) -> np.ndarray:
        """Feature-вектор для матча"""
        home_elo = self.elo_ratings.get(home_team, 1500)
        away_elo = self.elo_ratings.get(away_team, 1500)

        home_stats = team_stats.get(home_team, {})
        away_stats = team_stats.get(away_team, {})

        return np.array([
            # ELO и форма
            home_elo - away_elo,                          # ELO разница
            home_elo + self.HOME_ADVANTAGE - away_elo,    # Скорректированная разница
            home_stats.get('form_5_games', 0.5),          # Форма: очки/возможные последние 5
            away_stats.get('form_5_games', 0.5),
            home_stats.get('form_trend', 0),              # Тренд формы

            # Атака/защита
            home_stats.get('goals_scored_avg', 1.5),
            home_stats.get('goals_conceded_avg', 1.2),
            away_stats.get('goals_scored_avg', 1.5),
            away_stats.get('goals_conceded_avg', 1.2),
            home_stats.get('xg_for_avg', 1.4),
            home_stats.get('xg_against_avg', 1.1),

            # Контекст
            int(match_context.get('is_cup', False)),
            int(match_context.get('is_derby', False)),
            match_context.get('home_fatigue_days', 7),    # Дней с последнего матча
            away_stats.get('travel_distance_km', 0) / 1000,

            # Исторические матчапы
            match_context.get('h2h_home_win_rate', 0.4),
            match_context.get('h2h_goals_avg', 2.5),
        ])

    def predict_outcome(self, home_team: str, away_team: str,
                         match_context: dict, team_stats: dict) -> dict:
        """Вероятности исходов матча"""
        features = self.build_match_features(home_team, away_team, match_context, team_stats)
        probs = self.outcome_model.predict_proba(features.reshape(1, -1))[0]

        return {
            'home_win': round(float(probs[0]), 3),
            'draw': round(float(probs[1]), 3),
            'away_win': round(float(probs[2]), 3),
            'expected_goals_home': round(float(self.xg_model.predict(features.reshape(1, -1))[0]), 2),
            'home_elo': self.elo_ratings.get(home_team, 1500),
            'away_elo': self.elo_ratings.get(away_team, 1500)
        }


class PlayerPerformancePredictor:
    """Предсказание показателей игрока для фэнтези"""

    def predict_fantasy_points(self, player: dict,
                                match_context: dict,
                                season_stats: pd.DataFrame) -> dict:
        """
        Прогноз фэнтези-очков для игрока в конкретном матче.
        Учитывает позицию, форму, оппонента, venue.
        """
        player_stats = season_stats[season_stats['player_id'] == player['id']]

        if player_stats.empty:
            return {'expected_points': 0, 'confidence': 'low'}

        # Скользящие средние показателей
        recent = player_stats.sort_values('date').tail(5)
        avg_stats = {
            'goals_per_game': recent['goals'].mean(),
            'assists_per_game': recent['assists'].mean(),
            'shots_per_game': recent['shots'].mean(),
            'minutes_per_game': recent['minutes_played'].mean(),
            'key_passes': recent.get('key_passes', pd.Series([0])).mean(),
        }

        # Поправка на качество оппонента
        opp_defensive_rank = match_context.get('opponent_defensive_rank', 10)  # 1=лучшая
        difficulty_multiplier = 1.0 + (opp_defensive_rank - 10) * 0.02  # ±0.2 от ранга

        # Поправка на форму
        form_factor = recent['fantasy_points'].mean() / max(
            player_stats['fantasy_points'].mean(), 0.1
        )
        form_factor = float(np.clip(form_factor, 0.7, 1.3))

        # Позиционная формула
        position_multiplier = {
            'GK': 0.8, 'DEF': 1.0, 'MID': 1.2, 'FWD': 1.1
        }.get(player.get('position', 'MID'), 1.0)

        # Базовые очки
        expected_points = (
            avg_stats['goals_per_game'] * 4 +
            avg_stats['assists_per_game'] * 3 +
            avg_stats['shots_per_game'] * 0.3 +
            (avg_stats['minutes_per_game'] / 90) * 2
        ) * difficulty_multiplier * form_factor * position_multiplier

        # Вероятность выйти в стартовом составе
        starting_prob = player.get('starting_probability', 0.9)

        return {
            'player_id': player['id'],
            'player_name': player.get('name', ''),
            'position': player.get('position', ''),
            'expected_points': round(expected_points * starting_prob, 2),
            'expected_if_starts': round(expected_points, 2),
            'starting_probability': starting_prob,
            'form_factor': round(form_factor, 2),
            'difficulty_multiplier': round(difficulty_multiplier, 2),
            'confidence': 'high' if len(player_stats) >= 10 else 'medium'
        }


class FantasyTeamOptimizer:
    """Оптимизация состава фэнтези-команды"""

    def optimize_lineup(self, player_predictions: list[dict],
                         budget: float,
                         formation: str = '4-3-3') -> dict:
        """
        Линейное программирование для максимизации ожидаемых очков
        при бюджетных и позиционных ограничениях.
        """
        from scipy.optimize import linprog

        formation_requirements = {
            '4-3-3': {'GK': 1, 'DEF': 4, 'MID': 3, 'FWD': 3},
            '4-4-2': {'GK': 1, 'DEF': 4, 'MID': 4, 'FWD': 2},
            '3-5-2': {'GK': 1, 'DEF': 3, 'MID': 5, 'FWD': 2},
        }
        requirements = formation_requirements.get(formation, formation_requirements['4-3-3'])

        # Жадный подбор (greedy) как быстрый heuristic
        selected = []
        remaining_budget = budget
        position_slots = dict(requirements)

        # Сортируем по expected_points / price
        sorted_players = sorted(
            player_predictions,
            key=lambda p: p['expected_points'] / max(p.get('price', 5), 0.1),
            reverse=True
        )

        for player in sorted_players:
            pos = player.get('position', 'MID')
            if position_slots.get(pos, 0) <= 0:
                continue
            if player.get('price', 5) > remaining_budget:
                continue

            selected.append(player)
            position_slots[pos] -= 1
            remaining_budget -= player.get('price', 5)

            if all(v == 0 for v in position_slots.values()):
                break

        total_expected = sum(p['expected_points'] for p in selected)
        total_cost = budget - remaining_budget

        return {
            'lineup': selected,
            'total_expected_points': round(total_expected, 2),
            'total_cost': round(total_cost, 1),
            'remaining_budget': round(remaining_budget, 1),
            'formation': formation
        }

Оптимізація фентезі-складів

Моделі передбачають очки кожного гравця з урахуванням форми, опонента та позиції. Жадібний алгоритм збирає склад під бюджет і формацію. Коефіцієнт конверсії безкоштовних користувачів у платні збільшується на 15% завдяки більш залучаючому досвіду. На практиці це означає, що користувачі бачать, як їх команда може набрати максимум очок, і охочіше переходять на преміум-доступ.

Чому важливо управляти ризиками?

Ставки та фентезі потребують інструментів відповідального геймінгу (RG). Ми вбудовуємо моніторинг аномальних патернів: різке зростання обсягів ставок, нічні сесії, ставки після великих програшів. Автоматичні ліміти та само виключення — обов'язкова вимога регуляторів (наприклад, UKGC, MGA). Без цього ліцензію не отримати.

Як ми будуємо AI-систему для беттінгу

Процес розробки: аналітика → проектування → реалізація → тестування → деплой.

1. Аналітика: вивчаємо ринок, типи ставок, джерела даних. Збираємо історичні матчі, статистику гравців, лінії букмекерів, а також дані real-time (наприклад, live odds, weather feeds).
2. Проектування: обираємо архітектуру (microservices з ML-сервісом), feature store (Feast), vector DB для пошуку схожих матчів. Оцінюємо навантаження — петабайти даних у сезон.
3. Реалізація: пишемо моделі на PyTorch/HuggingFace, квантизуємо в INT8, розгортаємо на Triton Inference Server з latency p99 <50ms. Для фентезі — scipy.optimize.
4. Тестування: A/B тести проти поточної лінії, backtesting на 3+ сезонах. Перевіряємо на стійкість до дрифту даних.
5. Деплой: CI/CD через GitLab, моніторинг дрейфу даних (Evidently AI), алертинг у Telegram. Забезпечуємо автоматичне масштабування GPU.

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

• ML-моделі прогнозування результатів (xG, Win/Draw/Loss, фентезі-очки)
• Feature pipeline для обробки даних у реальному часі
• API для інтеграції з платформою (REST/WebSocket)
• RG-модуль (моніторинг, ліміти, само виключення)
• Документація та навчання команди замовника
• Підтримка протягом 3 місяців після запуску

Терміни та вартість

Терміни — від 2 до 4 місяців. Вартість розраховується індивідуально: залежить від кількості видів спорту, глибини історії, необхідності RG. Оцінимо ваш проект за 2 робочі дні. Зв'яжіться з нами — обговоримо задачу без зобов'язань.

Гарантуємо якість: наші інженери мають сертифікати AWS ML Specialty та досвід роботи з лідерами ринку. Замовте консультацію, щоб дізнатися, як ми покращимо вашу платформу.

Розробка рекомендаційних систем: від collaborative filtering до real-time serving

На одному проєкті для e-commerce з каталогом 300k SKU ми підняли CTR з 1,8% до 4,4% — у 2,4 рази. Перший ривок дала колаборативна фільтрація замість «популярне за останні 7 днів», другий — додавання контентних ознак та re-ranking. Різниця між «показуємо популярне» і «показуємо персоналізоване» — вимірна та суттєва. Нижче — інженерний досвід, який допоміг це зробити, і архітектури, які реально працюють у продакшені.

Collaborative Filtering: матрична факторизація та нейронні підходи

Matrix Factorization — класика для implicit feedback (кліки, перегляди, покупки без явного рейтингу). ALS (Alternating Least Squares) у бібліотеці Implicit обробляє матриці user×item із сотнями мільйонів ненульових значень за хвилини на GPU. Latent factors 64–256, регуляризація λ=0.01–0.1 — стартові параметри. Проблема cold start: для нового користувача або товару немає історії — класичний CF безпорадний, потрібні контентні ознаки або гібрид.

Neural Collaborative Filtering (NCF) замінює скалярний добуток на нейромережу. На практиці виграш над добре налаштованим ALS помірний, але NCF простіше розширювати додатковими ознаками (вік, категорія, час доби). Sequence-aware моделі (SASRec, BERT4Rec) враховують порядок взаємодій — state-of-the-art для сесійних рекомендацій.

Як вибрати архітектуру рекомендаційної системи?

Відповідь залежить від даних, навантаження та вимог до холодного старту. Нижче — три основні підходи з критеріями вибору.

Гібридна архітектура на 20–40% ефективніша за чистий CF за покриттям long-tail — перевірено на каталогах від 100k SKU.

Content-Based Filtering: коли історії взаємодій мало

Content-based рекомендує на основі характеристик товарів, а не поведінки інших користувачів — вирішує cold start для нових items. Текстові ембединги через sentence-transformers (multilingual-e5-base, BGE-M3) → пошук схожих через FAISS IndexFlatIP — запит за <5 ms на 100k товарів. Item2Vec (Word2Vec на послідовностях переглядів) дає інтерпретовані «схожі товари» за пару годин навчання.

Структуровані ознаки (категорія, бренд, ціна) подаються через embedding layers або в gradient boosting — CatBoost працює з категоріями без ручного кодування.

Чому гібридні моделі працюють краще?

Production-системи майже завжди дворівневі. Stage 1 (Retrieval) — швидкий відбір 100–500 кандидатів із 300k товарів через ALS або Two-Tower модель з векторним пошуком (FAISS, Qdrant). Stage 2 (Ranking) — важкий ранжувальник на LightGBM або нейромережі з cross-features, часом, пристроєм та контекстом сесії. LightFM — хороша відправна точка для середнього масштабу без важкої інфраструктури. Наша практика показує: перехід від single-stage до two-stage дає приріст точності на 15–25% при зростанні latency всього на 20–30 мс.

Real-Time Serving: архітектура під навантаження

Latency SLA — 50–100 ms при тисячах запитів на секунду. Base-рекомендації precompute (batch job раз на годину) → Redis по user_id → <5 ms. Real-time re-ranking через Kafka для подій (кліки, додавання в кошик) → оновлення контекстних ознак. Feature serving — Redis з TTL (кількість переглядів за 24 години, останній клікнутий item). При навантаженні 10k req/s ставимо Redis Cluster з реплікацією.

A/B тестування — єдиний достовірний спосіб оцінити покращення. Офлайн-метрики корелюють з онлайн не завжди. Kohavi et al., «Online Controlled Experiments at Large Scale» (KDD 2013) — обов'язкове читання для команди. Тест з 5–10% трафіку, моніторинг CTR, конверсії, revenue per session. Одна з наших клієнтських систем після гібридизації збільшила виручку на 18% за місяць A/B.

Терміни розробки рекомендаційної системи

Етапи та типові часові витрати — у таблиці нижче. Вартість розраховується індивідуально під масштаб каталогу та вимоги до latency.

Що входить у розробку під ключ

1. Аудит даних — щільність матриці user×item (зазвичай <0,1%), розподіл активності, temporal паттерни, cold start статистика.
2. Baseline — «популярне» як простий поріг, який часто важко перевершити.
3. Ітеративне покращення — ALS → контентні ознаки → two-stage → sequence-aware. Кожен крок з A/B.
4. Інфраструктура serving — batch precomputation, Redis, real-time re-ranking, моніторинг у Grafana.
5. Документація — model card з метриками, інструкція з деплою, опис ознак.
6. Навчання команди — сесія з інтерпретації результатів та донавчання моделі.
7. Підтримка — 1 місяць після запуску (фікс інцидентів, доналаштування pipeline).

Ми — команда з 7+ роками досвіду в рекомендаційних системах, реалізували понад 30 проєктів для e-commerce та медіа. Гарантуємо прозоре A/B-тестування та фіксацію покращення метрик.

Хочете оцінити потенціал зростання вашого каталогу? Зв'яжіться з нами для безкоштовного аудиту даних. Замовте розробку рекомендаційної системи — перший прототип протягом двох тижнів.

from implicit.als import AlternatingLeastSquares

model = AlternatingLeastSquares(
    factors=64,
    regularization=0.05,
    iterations=15,
    use_gpu=True
)
model.fit(user_item_matrix)

Більше про математику рекомендаційних систем — у Wikipedia.