Реальна історія про те, як в Uklon впроваджували машинне навчання

Привіт, мене звати Андрій, я Data Science інженер в SMART business. У цій статті я розповім, як ми для сервісу таксі Uklon прискорили час подачі машини та оптимізували розрахунок вартості за допомогою машинного навчання. Нижче піде мова про реальний кейсі застосування ML в бізнесі, який показав результати.

Про конкуренцію і мотивацію

Тільки в 2016 році в Києві з'явилося відразу кілька найпотужніших компаній-перевізників: спершу американський Uber, за ним — компанії з Росії («Яндекс.Таксі»), Словаччини (Hopin), Естонії (Тaxify), а також кілька менших компаній (українських та іноземних), що, природно, спричинило за собою загострення конкуренції в сегменті виклику таксі і закриття багатьох традиційних служб.

Жителі великих міст все активніше замовляють таксі онлайн. Якщо на початку 2016 року частка таких замовлень була 5-10% із загальної маси, то через рік їх стало вже вдвічі більше. Очікувано, що частка онлайн-замовлень на ринку буде тільки збільшуватися. Щоб залишатися на плаву, деякі традиційні служби таксі почали вводити у себе можливість замовлення таксі через сайт або мобільний додаток. Першим онлайн-сервісом виклику таксі у Києві став Uklon. Сьогодні компанія отримує в середньому кілька тисяч запитів на виклик в день. Головна фішка в тому, що ціна на поїздку — керована. Тобто ти можеш призначити будь-яку ціну замовлення і чекати, поки хтось з водіїв підтвердить її.

До недавнього часу Uklon використовував ціноутворення з динамічним коефіцієнтом, який враховує два фактори — рівень попиту (кількість запитів на подачу машини) і рівень пропозиції (кількість доступних на замовлення машин). При розрахунку вартості замовлення спершу визначалась ціна поїздки з точки А в точку Б, далі застосовувався динамічний коефіцієнт, який був покликаний створити оптимальну ціну, при якій імовірність знайти машину значно підвищується. Але існувала проблема з низьким відсотком вивезення в певних точках міста, а також клієнтам доводилося довго шукати і чекати машину, що, природно, призводило до скасування замовлення та втрати лояльності клієнта.

Для того щоб змінити ситуацію, ми створили сервіс, заснований на алгоритмах машинного навчання.

Упор був зроблений на поліпшення двох показників: очікуваний час прибуття таксі (Estimated Time of Arrival — ETA) і відсоток виконання замовлення (або так званий «процент вивезення»). Час прибуття таксі впливає на те, чи буде клієнт чекати подачі машини або скасує замовлення і скористається іншим сервісом. Відсоток виконання замовлення — це ПОКАЗНИК, який в цілому характеризує популярність сервісу та впливає на рівень продажів і частку ринку.

На очікуваний час прибуття таксі і відсоток вивезення можуть впливати різні параметри: ціна, кінцева точка маршруту, марка машини, місце прибуття, час доби, пору року (вгадайте, який з параметрів у підсумку виявився найбільш важливим?). Тому після аналізу бізнес-процесів компанії був обраний ряд таких параметрів, і почалася перевірка гіпотез на даних сервісу таксі.

В результаті перевірки вибраних гіпотез ми прийшли до висновку, що каменем спотикання є ціна — та ціна, яку клієнт готовий заплатити, щоб виїхати, і ціна, за яку таксист готовий приїхати на точку подачі. Значить все просто: якщо знайти ціну, яка влаштує обидві сторони угоди, то зменшиться час пошуку машини, і збільшиться показник відсотка вивезення. Data Science інженери запропонували створити нову модель ціноутворення, яка буде враховувати всі фактори, при цьому влаштовувати обидві сторони.

Переходимо до рішення

Використовувані дані для роботи моделі

Для перевірки гіпотез і подальшої побудови моделі були використані наші закриті дані — таблиця з історією замовлень і поїздок клієнтів, розміром близько 20 Гб. Ця таблиця містила більше 20 мільйонів записів з 20 характеристиками (полями) поїздок, які протягом роботи доповнювалися інформацією про водія, автомобілі і клієнта.

Також використовувалися метеорологічні дані, які ми збирали з двох джерел: сайт з відкритими даними від NASA і метеостанції трьох київських аеропортів.

Опис роботи моделі (алгоритму)

Так як працювати відразу з 20 параметрами (полями) поїздок було важко, вирішили агрегувати параметри по групах. Перший параметр, з яким почали працювати, — це точка подачі машини. Ми провели аналіз точок виникнення попиту в різних районах Києва і розбили місто на кластери, які, звичайно ж, відрізнялися від стандартного поділу міста на адміністративні райони.

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

Також були вивчені дані про клієнтів, щоб сформувати поведінкову модель пасажирів і провести на її основі сегментацію. Враховувалося, хто, коли, куди і як часто їздить, погоджувався на торг, скасовував замовлення і так далі. Таким чином, після аналізу поведінки клієнтів ми виділили кілька груп користувачів, для яких ціна формувалася по-своєму.

Для поділу міста за регіонами вивозу клієнтів і точки призначення, а також для сегментації клієнтів, ми використовували кластеризацію (k-means алгоритм).

Вихідні точки і випадково обрані початкові точки. Точки, віднесені до початкових центрам. Розбиття на площині — діаграма Вороного щодо початкових центрів. Обчислення нових центрів кластерів (шукаємо центр мас ). Попередні кроки повторюються, поки алгоритм не зійдеться.

Також використовували класифікацію і регресію (Random forest алгоритм) для наступних завдань:

Етапи роботи над моделлю

Відібравши набори даних і завантаження їх у базу даних в SQL Azure Database service , ми взяли частина даних для тренування моделі в Microsoft Data Science Virtual Machine . Для різних завдань використовували різні моделі, наприклад, для кластеризації міста або сегментації клієнтів використовувався k-means алгоритм для прогнозування ціни — дерево рішень (до речі, зараз дерево рішень для визначення оптимальної ціни містить близько 300 гілок). Після тренування моделі ми взяли стандартні параметри, які задає модель, і перевірили роботу моделі на певній вибірці даних. Результат був задовільним.

Далі для перевірки коректності роботи моделі бралися дані, які були спочатку приховані від моделі при тренуванні і оцінці результатів тренування. У результаті перевірка показала, що модель все-таки враховує не всі параметри. Тому за результатами першої перевірки був підібраний новий набір параметрів для моделі, і процеси тренування та перевірки пройдено знову по колу, поки не був отриманий необхідний результат.

Далі отримана в Microsoft Data Science Virtual Machine модель, яка вирішує завдання клієнта, була розгорнута у виробничому середовищі у вигляді веб-сервісу — а саме в Azure Machine Learning web service. Схема роботи рішення така: потенційний пасажир створює замовлення в мобільному додатку з параметрами точки вивезення і точки призначення, на основі чого розраховується стандартна ціна поїздки по кілометражу, і ці вхідні дані віддаються через сервер «Ухилу» до розгорненого веб-сервісу. Далі модель прораховує оптимальну ціну для даної поїздки, при якій пасажир не буде торгуватися, а таксист найбільш ймовірно візьме замовлення. Прорахована моделлю ціна повертається на сервер «Ухил» і вже звідти — в клієнтське додаток, де пасажир може бачити запропоновану ціну для даної поїздки. Швидкість прорахунку оптимальної ціни настільки висока, що користувач мобільного додатка не помічає ніяких затримок.

Зміна моделі після перших тестових запусків

Перед запуском роботи моделі на всіх клієнтів і на все місто ми пройшли ряд кроків для поліпшення результатів:

Результати роботи моделі

Створена нами модель була запущена в експлуатацію паралельно з існуючим ціноутворенням з використанням динамічного коефіцієнта, та замовлення клієнтів розподілялися 50/50 на обидві моделі.

В результаті роботи нової моделі покращилися показники виконання замовлень і часу очікування — власне, ті параметри, на які ми націлювалися на початку проекту. У порівнянні з минулою моделлю ці показники вище на 5-15%.

При використанні нової моделі машина знаходиться на 18 секунд швидше. При кількості близько 3000 замовлень в день — це близько 15 годин економії часу для всього міста. Якщо брати до уваги середню сім'ю, яка їздить на таксі приблизно 4 рази в тиждень, економія часу становить близько 1 год в рік.

У порівнянні з існуючою моделлю ціноутворення, тепер у 75% випадків клієнт не торгується і погоджується на вартість, запропоновану новою моделлю. Це показує досить високу здатність алгоритму враховувати поведінкову модель клієнтів.
Якщо говорити про фінансові результати, то при використанні нової моделі збільшилася прибуток і середній чек поїздки, при цьому не скоротилася кількість клієнтів.

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

Зараз алгоритм моделі працює на основі тих даних, на яких вона навчалася, але в подальшому планується перенавчання моделі кожен місяць або навіть щотижня з урахуванням нових даних.

Опубліковано: 30/03/18 @ 07:00
Розділ Різне

Рекомендуємо:

Google Cloud Spanner: огляд можливостей та перші враження від бази даних
DOU Hobby: "Триставісім" — рок із запальними карпатсько-балканськими мотивами
DOU Проектор: Movie Expert — рекомендації фільмів за вашими інтересами
Робота вночі: як висипатися і треба ставати жайворонком
Scala дайджест #8: перша версія Hydra, пререлиз Scala-2.13-M3, конференція ScalaUA