Як Machine Learning у BlaBlaCar допомагає водіям знайти пасажирів

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт! Мене звати Павло Башинський, я Senior Devops Engineer в BlaBlaCar.

У рубриці Behind the Curtain від BlaBlaCar буду ділитися кейсами та історіями, як у нас все влаштовано, з якими технічними складнощами стикаємося та як шукаємо рішення.

Часто читаю статті про технології від різних гігантів. В них часто не вистачає деталей: як саме ця чи інша технологія інтегрована в архітектуру, які процеси відбуваються навколо неї, чому саме вона? Щоразу доводиться шукати відповіді поміж рядків. Тому ми вирішили почати розповідати, як у нас всередині. Ми теж маємо багато цікавого як у компанії загалом, так і в офісі в Києві, де розташований другий за величиною інжиніринговий хаб BlaBlaCar після Парижа, який працює над автобусним маркетплейсом.

Сьогодні BlaBlaCar — це найбільша платформа для поїздок у світі, яка об’єднує карпулінг (поїздки з попутниками) та автобусні поїздки. У цій колонці я хочу поділитись, як ми допомагаємо новим водіям успішно знаходити попутників під час публікації першої поїздки.

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

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

Щоб надати більш корисні рекомендації новим водіям, ми вирішили створити модель, яка пояснює передбачення успіху пошуку попутників у дусі explainable AI. Тобто ми хочемо зрозуміти, що саме сприяє успіху, і на основі цього створити персональні рекомендації для водіїв. Наша задача полягала в тому, щоб знайти ознаки (feature), які впливають на це, та відібрати одну чи дві ключових. Ми припускаємо, що персональні рекомендації, створені на основі таких ознак, є набагато ефективніші, ніж загальні рекомендації для водіїв.

Погляд на моделі, які можна пояснити

Зрозумілий ШІ (explainable AI) — це такі моделі, які дозволяють пояснити свої дії в зрозумілих термінах або вигляді.

Зважаючи на можливі підходи explainable AI, ми визначили різні методи, які можуть пояснити та кількісно визначити, як кожна ознака стосується прогнозованого результату. Ось деякі приклади:

• Створення моделі, яка може бути інтерпретована з коробки як лінійна модель або дерева рішень. Таким чином ми можемо легко прочитати на самій моделі, як кожна ознака впливає на успіх. Ми не віддавали перевагу цьому методу, оскільки хотіли використовувати складніші моделі.
• Для більш складних моделей ми можемо використати метод LIME (Local Interpretable Model-Agnostic Explanations). Завдяки йому можна наблизити будь-яку чорну скриньку до лінійної моделі. Отже, для кожної навчальної вибірки ми могли б використовувати це лінійне наближення для інтерпретації того, як переміщення різних параметрів впливає на успіх.
• Також для складних моделей, таких як дерева градієнтного бустингу, існує метод під назвою SHAP (SHapley Additive exPlanations), розроблений Лундбергом та Лі. Він спирається на те, що в теорії ігор називають вектор Шеплі. Задача вектора Шеплі — визначити, наскільки кожна ознака сприяє нашій ймовірності успіху. Більше про це тут. Наприклад, якщо ми прогнозуємо, що успіх поїздки становить 80%, а середній рівень успіху 50%, то кожна ознака має вектор Шеплі, що пояснює частину цього 30% розриву. Потім ми можемо використовувати ці числові значення для аналізу результатів нашої моделі та перевірити, чи одна або дві ознаки суттєво підвищують/знижують показник успіху.
• Ще один, на наш погляд, цікавий метод — використання PDP (Partial dependence plots) кожної ознаки. Ідея PDP полягає в тому, щоб побачити на графіках граничний вплив однієї змінної на змінну успіху. Це передбачає, що кожна інша ознака не залежить від тієї, яку ми розглядаємо. Це допомагає зрозуміти, як зміна цієї ознаки в середньому впливає на зміну рівня успіху. Тоді для кожного значення даних ми побачили б, де стоїмо на нашому PDP, щоб зробити прогноз. Однак ці графіки базуються на апроксимальних даних. Тому на них можна робити лише загальні припущення.
• Вищенаведений метод не є корисним для надання індивідуальних рекомендацій. Але ми можемо спробувати для кожного значення даних зсунути всі ознаки, знову передбачити успіх і подивитися, як їх переміщення впливає на оцінку. Рекомендованою ознакою буде та, що має більший вплив. Це також припускає, що наші ознаки є незалежними одна від одної. Цей метод схожий на те, що робить What-If Tool.

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

Як ми обрали найкращу

Що ж, подивімось, як ми до цього дійшли. Спочатку ми створили модель для прогнозування шансів водіїв на успіх знайти попутників. Ця модель для кожної публікації поїздки застосовує наші знання, досвід і дані. Вона використовує градієнтний бустинг і навчена на даних 2019 року. Датасет містить дані з профілів водіїв та описів поїздок. На виході ми маємо отримати дані, була опублікована поїздка успішною чи ні. Для нашого випадку градієнтний бустинг є швидким і показує гарні результати. Площа під кривою становила близько 0,8. Дивлячись на криві влучності (precision) та повноти (recall), ми підтвердили, що модель показала гарні результати.

Щоб побудувати модель з урахуванням методології «what if», нам довелося виділити три групи ознак:

• ознаки, які допомагають передбачити здійснення;
• дієві ознаки під час публікації;
• дієві ознаки на час відправлення.

Крім того, якщо ми використовуємо лише ті ознаки, які безпосередньо пов’язані з користувачем, то ми маємо не найкращу модель. Нам також потрібні дієві ознаки, які можуть виступати потенційними рекомендаціями. Існує два типи таких дієвих ознак. Перші діють відразу після публікації, наступні допомагають майбутній публікації. Наприклад, ми не можемо надіслати лист в минуле, щоб повідомити водія опублікувати поїздку за два дні до відправлення. Однак ми можемо дати таку рекомендацію водію після від’їзду для публікації наступних поїздок.

Ми помітили дві проблеми. Коли існує колінеарність між ознаками, одна ознака може приховати ефект іншої. Наприклад, ми побачили, що кількість днів між реєстрацією та публікацією має сильний вплив. Однак ознака, яка повідомляє, чи був водій у ролі пасажира до публікації, виявилась малозначущою. Роздивляючись різні значення вектора Шеплі, ефективність (main effect) та інтерактивні значення (interactive values) цих ознак, ми зрозуміли взаємодію. Справді ознака «кількість днів між реєстрацією та публікацією» не є дуже корисною, якщо вона не приховує, що новий водій у ролі пасажира отримав кілька балів рейтингу, що підвищило шанси на успіх як водія. Ми вирішили проблему, згрупувавши такі ознаки та підсумувавши їхні вектори Шеплі, щоб зрозуміти вплив цієї групи на успіх. Через адитивність вектора Шеплі ми знали вплив цих ознак як групи і більше не звертали увагу на взаємодію цих ознак.

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

Висновок

Зрештою, ми створили дві окремі моделі. Перша схожа на «what if tool», що створює рекомендації новим водіям під час публікації та відправлення. Та модель на основі метода SHAP, яка виробляє агреговані вектори Шеплі, які далі використовуються для аналізу в нашій CRM.

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

Щиро дякуємо за допомогу Дані Сраж, Ентоні Барчевски, Data Scientists в BlaBlaCar, і Дмитру Унковському, Data Scientist в Grammarly.