Прогнозирование спроса и перебалансировка флота каршеринга с AI

Как AI-система решает проблему дисбаланса в каршеринге?

В каршеринге дисбаланс между спросом и предложением — утром автомобили скапливаются в спальных районах, вечером — в центре. Без машинного обучения простои достигают 40%, а пользователи ждут свободную машину до 15 минут. Мы разработали AI-систему, которая прогнозирует спрос на 2–24 часа вперёд с использованием градиентного бустинга и оптимизирует распределение флота, сокращая простои до 20–35% и время ожидания на 18–25%. Система учитывает историю поездок, погоду, события и календарь. Решение подходит для операторов с флотом от 500 автомобилей. Согласно недавнему анализу, подобные системы снижают операционные затраты на 25%McKinsey Global Institute.

Система работает следующим образом: модель для каждой зоны предсказывает количество поездок, которые начнутся в ближайшие часы. Затем алгоритм перебалансировки указывает, какие автомобили переместить из зон с избытком в зоны с дефицитом. Дополнительно модуль динамического ценообразования корректирует тарифы, стимулируя пользователей выбирать машины в нужных направлениях.

Как мы прогнозируем спрос?

Основа — исторические данные о поездках, погоде, событиях и календаре. Мы строим отдельную модель градиентного бустинга для каждой зоны. Ключевые признаки:

• Временные: час, день недели, признак часа пик (утро 7–10, вечер 17–20).
• Погодные: температура, осадки, бинарный индикатор дождя.
• Лаговые: спрос 1 час, 24 часа, неделю назад.
• Событийные: праздники, крупные мероприятия рядом (например, концерт или стадион).

Для новых зон с малым количеством данных используем трансферное обучение с зон-доноров. Модель обучается на данных за последние 90 дней и переобучается ежедневно. Feature engineering включает кодирование цикличных признаков (час, месяц) через sin/cos, что повышает точность на 5%.

import numpy as np
import pandas as pd
from sklearn.ensemble import GradientBoostingRegressor
from sklearn.preprocessing import LabelEncoder

class ZonalDemandForecaster:
    """Прогноз спроса на прокат по географическим зонам"""

    def __init__(self, n_zones: int):
        self.n_zones = n_zones
        self.models = {}  # Отдельная модель для каждой зоны

    def build_features(self, df: pd.DataFrame) -> pd.DataFrame:
        """Временные и контекстуальные признаки"""
        features = pd.DataFrame()

        # Временные
        features['hour'] = df['timestamp'].dt.hour
        features['weekday'] = df['timestamp'].dt.weekday
        features['is_weekend'] = (features['weekday'] >= 5).astype(int)
        features['is_morning_rush'] = features['hour'].between(7, 10).astype(int)
        features['is_evening_rush'] = features['hour'].between(17, 20).astype(int)
        features['month'] = df['timestamp'].dt.month

        # Погода (из внешнего API)
        features['temperature'] = df.get('temperature_c', 15)
        features['precipitation_mm'] = df.get('precipitation_mm', 0)
        features['is_raining'] = (features['precipitation_mm'] > 2).astype(int)

        # Лаговые признаки
        features['demand_lag_1h'] = df.get('demand_1h_ago', 0)
        features['demand_lag_24h'] = df.get('demand_24h_ago', 0)
        features['demand_lag_week'] = df.get('demand_7d_ago', 0)

        # Специальные события
        features['is_holiday'] = df.get('is_holiday', 0)
        features['event_nearby'] = df.get('event_capacity_nearby', 0)

        return features.fillna(0)

    def train(self, historical_data: pd.DataFrame):
        """Обучение модели для каждой зоны"""
        for zone_id in range(self.n_zones):
            zone_data = historical_data[historical_data['zone_id'] == zone_id]
            if len(zone_data) < 500:
                continue

            X = self.build_features(zone_data)
            y = zone_data['trips_started']

            self.models[zone_id] = GradientBoostingRegressor(
                n_estimators=200, learning_rate=0.05, max_depth=4, random_state=42
            )
            self.models[zone_id].fit(X, y)

    def forecast(self, zone_id: int, future_features: pd.DataFrame) -> np.ndarray:
        """Прогноз на горизонт forecast_hours"""
        if zone_id not in self.models:
            return np.zeros(len(future_features))

        X = self.build_features(future_features)
        return self.models[zone_id].predict(X).clip(0)

Почему градиентный бустинг лучше нейросетей?

Gradient Boosting даёт лучшее качество на табличных данных с нелинейными зависимостями и интерпретируемость через feature importance. Он устойчив к выбросам и работает быстрее нейросетей на стадии инференса. В наших тестах GBR превзошёл LSTM по RMSE на 12% при горизонте прогноза 2 часа. Для особо зашумлённых зон используем ансамбль: GBR + LightGBM с усреднением.

Сравнение методов прогнозирования на тестовом полигоне (500 зон, 3 месяца данных):

Оптимизация распределения флота

Алгоритм перебалансировки распределяет автомобили по зонам пропорционально прогнозу спроса, минимизируя перемещения. Принцип: избыток -> дефицит с учётом приоритета. Учитывается время и стоимость перегона: если перемещение занимает более 30 минут, оператор может применить скидку для пользователя (user-incentivized rebalancing).

class FleetRebalancer:
    """Оптимизация перераспределения флота"""

    def compute_rebalancing_plan(self, current_distribution: dict,
                                  demand_forecast: dict,
                                  fleet_size: int) -> list[dict]:
        """
        current_distribution: {zone_id: car_count}
        demand_forecast: {zone_id: expected_trips_next_2h}
        Returns: список перемещений (откуда -> куда, сколько машин)
        """
        # Целевое распределение пропорционально прогнозу спроса
        total_demand = sum(demand_forecast.values()) + 1e-9
        target_distribution = {
            zone_id: int(fleet_size * demand / total_demand)
            for zone_id, demand in demand_forecast.items()
        }

        # Корректировка: итог должен = fleet_size
        diff = fleet_size - sum(target_distribution.values())
        top_zones = sorted(demand_forecast, key=demand_forecast.get, reverse=True)
        for i in range(abs(diff)):
            zone = top_zones[i % len(top_zones)]
            target_distribution[zone] += 1 if diff > 0 else -1

        # Вычисляем перемещения
        surpluses = {z: current_distribution.get(z, 0) - target_distribution.get(z, 0)
                     for z in set(current_distribution) | set(target_distribution)}

        moves = []
        surplus_zones = sorted([(z, s) for z, s in surpluses.items() if s > 0], key=lambda x: -x[1])
        deficit_zones = sorted([(z, -s) for z, s in surpluses.items() if s < 0], key=lambda x: -x[1])

        s_idx, d_idx = 0, 0
        while s_idx < len(surplus_zones) and d_idx < len(deficit_zones):
            s_zone, s_count = surplus_zones[s_idx]
            d_zone, d_count = deficit_zones[d_idx]

            move_count = min(s_count, d_count)
            if move_count > 0:
                moves.append({
                    'from_zone': s_zone,
                    'to_zone': d_zone,
                    'cars_to_move': move_count,
                    'priority': 'high' if d_count > 3 else 'normal'
                })

            surplus_zones[s_idx] = (s_zone, s_count - move_count)
            deficit_zones[d_idx] = (d_zone, d_count - move_count)

            if surplus_zones[s_idx][1] == 0:
                s_idx += 1
            if deficit_zones[d_idx][1] == 0:
                d_idx += 1

        return sorted(moves, key=lambda x: x['priority'] == 'high', reverse=True)

Динамическое ценообразование

Модуль динамического ценообразования корректирует тарифы на основе соотношения спроса и предложения. При дефиците — наценка до 1.5х, при избытке — скидка 15%. Также пользователь получает скидку за поездку в дефицитную зону, что стимулирует естественное перераспределение флота.

class DynamicPricingForCarsharing:
    """Ценообразование на основе спроса"""

    def calculate_surge_multiplier(self, zone_id: int,
                                    available_cars: int,
                                    demand_forecast_1h: float) -> float:
        """Динамический тариф по соотношению спрос/предложение"""
        supply_demand_ratio = available_cars / max(demand_forecast_1h, 0.1)

        if supply_demand_ratio > 2.0:
            multiplier = 0.85  # Скидка при избытке
        elif supply_demand_ratio > 1.5:
            multiplier = 1.0
        elif supply_demand_ratio > 1.0:
            multiplier = 1.15
        elif supply_demand_ratio > 0.5:
            multiplier = 1.3
        else:
            multiplier = 1.5  # Максимальная наценка при дефиците

        return round(multiplier, 2)

    def incentivize_user_rebalancing(self, pickup_zone: int,
                                      dropoff_zone: int,
                                      zone_surpluses: dict) -> float:
        """Скидка пользователю, который привезёт машину в дефицитную зону"""
        pickup_surplus = zone_surpluses.get(pickup_zone, 0)
        dropoff_deficit = -zone_surpluses.get(dropoff_zone, 0)

        if dropoff_deficit > 3 and pickup_surplus > 2:
            return 0.15  # 15% скидка на поездку
        return 0.0

Что входит в работу?

Мы передаём полный комплект документации: описание архитектуры, API-спецификацию (OpenAPI), model card с метриками, инструкцию по эксплуатации и регламент переобучения. Предоставляем доступ к репозиторию с исходным кодом, обученной модели и скриптам развёртывания. Обучение команды заказчика работе с системой проводится в формате workshop на 2 дня. Поддержка после запуска — 1 месяц, включая мониторинг и исправление инцидентов.

Процесс внедрения

Проект реализуется под ключ за 4–8 недель на пилот и до 3 месяцев на полноценный запуск. Этапы:

1. Анализ данных: сбор исторических поездок, интеграция с погодным API и календарём событий.
2. Разработка моделей: обучение и валидация на ваших данных, подбор гиперпараметров.
3. Интеграция: REST API или gRPC для получения прогнозов и плана перебалансировки.
4. Развёртывание: Docker + Kubernetes, on-premise или облако (AWS, GCP).
5. Мониторинг: дрейф данных, переобучение моделей, A/B тестирование.

Результаты внедрения

Как начать?

Оцените свой проект — свяжитесь с нами для бесплатной консультации. Мы проанализируем ваши данные и предложим решение, подходящее под ваш флот и бюджет. Накопленный опыт — 30+ проектов в области AI для транспорта и логистики. Получите консультацию уже сегодня.

Разработка рекомендательных систем: от 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.