AI-система матчинга водителей и пассажиров в райдшеринге

Почему матчинг в райдшеринге — это нетривиальная задача?

Водитель едет 15 минут к пассажиру, а затем везет его 5 минут — знакомая ситуация? Причина — неоптимальный матчинг. Когда алгоритм просто назначает ближайшего водителя, игнорируются будущий спрос, загруженность водителя и возможность объединения поездок. В результате пассажиры ждут дольше, водители простаивают, а платформа теряет прибыль. Мы — команда AI/ML-инженеров с суммарным опытом 40+ лет в райдшеринге, выполнили более 20 проектов по матчингу. Наш подход сочетает комбинаторную оптимизацию и машинное обучение, что позволяет снизить ETA на 30–40% и повысить utilization водителей до 72%, одновременно снижая операционные расходы платформы на 25%.

На одном из проектов мы столкнулись с ситуацией, когда жадный матчинг давал match rate всего 85% и utilisation 55% из-за игнорирования прогноза спроса. После внедрения батч-матчинга с heatmap спроса через 2 недели match rate вырос до 96%, а средний доход водителя увеличился на 18% — до 500$ в месяц на водителя.

Для улучшения качества матчинга мы используем embeddings для представления запросов и водителей в векторном пространстве. Алгоритм матчинга учитывает коэффициент динамического ценообразования (surge), чтобы в часы пик назначать приоритетные поездки.

Как мы разрабатываем алгоритм матчинга?

Для батч-матчинга мы используем венгерский алгоритм на матрице стоимости, вычисленной на основе ETA, качества водителя и коэффициента детура. Приводим полный код движка, который передаём клиенту:

import numpy as np
from scipy.optimize import linear_sum_assignment
from dataclasses import dataclass
from typing import Optional
import heapq

@dataclass
class Driver:
    id: str
    lat: float
    lon: float
    current_passengers: int
    max_passengers: int
    rating: float
    acceptance_rate: float
    vehicle_type: str  # economy, comfort, xl

@dataclass
class RideRequest:
    id: str
    pickup_lat: float
    pickup_lon: float
    dropoff_lat: float
    dropoff_lon: float
    passenger_count: int
    vehicle_preference: str
    max_wait_seconds: int
    surge_accepted: bool

class RideshareMatchingEngine:
    """Матчинг водитель-пассажир с учётом множества критериев"""

    EARTH_RADIUS_KM = 6371.0

    def haversine_distance(self, lat1: float, lon1: float,
                            lat2: float, lon2: float) -> float:
        """Расстояние в км"""
        dlat = np.radians(lat2 - lat1)
        dlon = np.radians(lon2 - lon1)
        a = (np.sin(dlat/2)**2 +
             np.cos(np.radians(lat1)) * np.cos(np.radians(lat2)) * np.sin(dlon/2)**2)
        return 2 * self.EARTH_RADIUS_KM * np.arcsin(np.sqrt(a))

    def estimated_pickup_time(self, driver: Driver, request: RideRequest) -> float:
        """ETA в минутах (упрощённо через дистанцию, в production — OSRM/Google Maps)"""
        dist_km = self.haversine_distance(
            driver.lat, driver.lon,
            request.pickup_lat, request.pickup_lon
        )
        # Средняя скорость с учётом городского трафика: 20-25 км/ч
        return dist_km / 22 * 60

    def compute_match_score(self, driver: Driver,
                             request: RideRequest) -> float:
        """
        Составной скор для матчинга. Минимизируем ETA + максимизируем
        utilization + учитываем предпочтения и качество водителя.
        """
        eta_min = self.estimated_pickup_time(driver, request)

        # Жёсткие ограничения
        if driver.vehicle_type != request.vehicle_preference and request.vehicle_preference != 'any':
            if not (request.vehicle_preference == 'economy' and driver.vehicle_type == 'comfort'):
                return -1.0  # Недопустимое совпадение

        if driver.current_passengers + request.passenger_count > driver.max_passengers:
            return -1.0  # Нет мест

        if eta_min > request.max_wait_seconds / 60:
            return -1.0  # Слишком долго ждать

        # Нормализация компонент (меньше ETA = выше скор)
        eta_score = max(0, 1.0 - eta_min / 10)  # 0 мин = 1.0, 10+ мин = 0

        # Качество водителя
        quality_score = (driver.rating - 4.0) / 1.0 * 0.5 + driver.acceptance_rate * 0.5

        # Детур-коэффициент для пул-поездок (если водитель уже везёт пассажиров)
        if driver.current_passengers > 0:
            detour_factor = 0.7  # Пул-поездка менее привлекательна для пассажира
        else:
            detour_factor = 1.0

        return eta_score * 0.55 + quality_score * 0.25 + detour_factor * 0.20

    def batch_match(self, drivers: list[Driver],
                     requests: list[RideRequest]) -> dict:
        """
        Оптимальный батч-матчинг через венгерский алгоритм.
        Запускается каждые 30 секунд для накопившихся запросов.
        """
        n_drivers = len(drivers)
        n_requests = len(requests)

        if n_drivers == 0 or n_requests == 0:
            return {'matches': [], 'unmatched_requests': [r.id for r in requests]}

        # Матрица стоимости (венгерский алгоритм минимизирует, поэтому инвертируем скор)
        cost_matrix = np.full((n_drivers, n_requests), 1000.0)

        for i, driver in enumerate(drivers):
            for j, request in enumerate(requests):
                score = self.compute_match_score(driver, request)
                if score >= 0:
                    cost_matrix[i, j] = 1.0 - score  # Инверсия для минимизации

        # Венгерский алгоритм O(n³)
        driver_indices, request_indices = linear_sum_assignment(cost_matrix)

        matches = []
        matched_request_ids = set()

        for d_idx, r_idx in zip(driver_indices, request_indices):
            if cost_matrix[d_idx, r_idx] < 900.0:  # Не фиктивное назначение
                matches.append({
                    'driver_id': drivers[d_idx].id,
                    'request_id': requests[r_idx].id,
                    'eta_min': round(self.estimated_pickup_time(drivers[d_idx], requests[r_idx]), 1),
                    'score': round(1.0 - cost_matrix[d_idx, r_idx], 3)
                })
                matched_request_ids.add(requests[r_idx].id)

        unmatched = [r.id for r in requests if r.id not in matched_request_ids]

        return {
            'matches': matches,
            'unmatched_requests': unmatched,
            'match_rate': len(matches) / max(len(requests), 1)
        }


class DriverPositioningAdvisor:
    """Рекомендации водителю куда переехать для следующего заказа"""

    def suggest_repositioning(self, driver: Driver,
                               demand_heatmap: dict,
                               nearby_drivers: list[Driver],
                               radius_km: float = 3.0) -> dict:
        """
        demand_heatmap: {(lat, lon): expected_requests_next_30min}
        Ищем зону с высоким спросом и малой конкуренцией среди водителей.
        """
        best_zone = None
        best_score = -1.0

        for (zone_lat, zone_lon), expected_demand in demand_heatmap.items():
            dist_to_zone = self.haversine_distance(
                driver.lat, driver.lon, zone_lat, zone_lon
            )
            if dist_to_zone > radius_km:
                continue

            # Сколько водителей уже в этой зоне
            competing_drivers = sum(
                1 for d in nearby_drivers
                if self.haversine_distance(d.lat, d.lon, zone_lat, zone_lon) < 1.0
            )

            # Спрос на водителя = demand / (drivers + 1)
            demand_per_driver = expected_demand / (competing_drivers + 1)

            # Штраф за дистанцию перемещения
            relocation_cost = dist_to_zone / radius_km * 0.3

            score = demand_per_driver - relocation_cost

            if score > best_score:
                best_score = score
                best_zone = (zone_lat, zone_lon, dist_to_zone, expected_demand)

        if best_zone:
            return {
                'suggest': True,
                'target_lat': best_zone[0],
                'target_lon': best_zone[1],
                'distance_km': round(best_zone[2], 1),
                'expected_wait_min': round(best_zone[2] / 22 * 60, 0),  # Время добраться
                'expected_demand': best_zone[3]
            }

        return {'suggest': False, 'reason': 'Already in optimal zone'}

    def haversine_distance(self, lat1, lon1, lat2, lon2) -> float:
        dlat = np.radians(lat2 - lat1)
        dlon = np.radians(lon2 - lon1)
        a = np.sin(dlat/2)**2 + np.cos(np.radians(lat1)) * np.cos(np.radians(lat2)) * np.sin(dlon/2)**2
        return 2 * 6371.0 * np.arcsin(np.sqrt(a))

Батч-матчинг каждые 30 секунд (против жадного онлайн-матчинга) снижает average ETA на 15–20%. Рекомендации позиционирования для водителей повышают их earnings per hour на 10–15% и улучшают покрытие районов с высоким спросом. Венгерский алгоритм гарантирует глобально оптимальное назначение в пределах батча.

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

Сравнение нашего подхода с классическим

Сравнение ETA по времени суток

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

Для прогнозирования спроса используем ансамбль моделей: XGBoost и LSTM. Входные признаки — исторические данные о заказах с привязкой к координатам (grid 500x500 метров), время суток, день недели, погодные условия. Модель выдает heatmap ожидаемого количества запросов в каждой ячейке на ближайшие 30 минут. Эта heatmap используется модулем позиционирования водителей и батч-матчингом для принятия решений. Пример формата heatmap:

{
  "(55.751, 37.617)": 12,
  "(55.753, 37.620)": 8
}

Какие метрики мы отслеживаем?

Помимо ETA и match rate, мы мониторим экономические метрики: средний доход водителя в час (earnings per hour), долю пустого пробега (deadhead miles), а также удовлетворенность пассажиров (оценка поездки). Наши системы позволяют снизить операционные расходы платформы примерно на $0.15 за поездку за счет уменьшения дистанции подачи.

Типичные ошибки при внедрении

• Игнорирование demand heatmap — неравномерная загрузка, рост ETA в пиковые часы.
• Отсутствие ML для прогноза спроса — низкая utilization, водители стоят в пустых зонах.
• Слишком частый пересчёт (каждые 5 сек) — избыточная нагрузка без улучшения качества.
• Неучёт ограничений вместимости — ошибки при пул-поездках.
• Пренебрежение динамическим ценообразованием — платформа упускает прибыль в часы пик.

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

1. Аналитика — аудит текущих метрик (ETA, match rate, utilization), анализ исторических данных, выявление узких мест.
2. Проектирование — архитектура (микросервисы: FastAPI, Redis, Kafka), выбор версий пакетов.
3. Реализация — написание кода с unit-тестами (coverage > 90%), code review.
4. Интеграция — подключение через REST/gRPC, настройка CI/CD.
5. Нагрузочное тестирование — симуляция 10k+ водителей и 100k+ запросов, p99 latency < 1 с.
6. Деплой и мониторинг — развёртывание в вашем контуре, дашборды Grafana, алерты.

Сроки и стоимость

Ориентировочные сроки — от 3 до 6 недель в зависимости от объёма данных и сложности интеграции. Стоимость рассчитывается индивидуально после анализа вашей задачи. Свяжитесь с нами для получения консультации — оценим ваш объём данных и предложим решение в течение 3–5 дней.

Мы гарантируем прозрачность исходного кода и возможность дальнейшей модификации вашей командой. Закажите разработку системы матчинга — поможем сделать матчинг эффективнее и повысить доход вашей платформы.

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