Як Grubhub проаналізував 4000 страв, щоб передбачити ваше наступне замовлення
Щоб створити механізм рекомендацій, служба доставки продуктів через Інтернет витратила вісім років на вирішення класичної проблеми неструктурованих даних.
Все, що Метт Мелоні хотів знати, - чи піца з глибоким блюдом у стилі Чикаго краща, ніж тонка скоринка в Нью-Йорку. Це просте запитання.
Якби він був кимось іншим, Мелоні довелося б жорстоко анекдотувати. Глибока страва, хоч і смачна, явно не стільки піца, скільки запіканка; навпаки, якщо ви хочете покласти начинку для піци на зломщик, чому б просто не замовити корж? (Мелоні з Чикаго, тож ви здогадуєтесь, на якому боці він спускається).
Але не. Мелоні відчував, що він повинен мати можливість буквально відповісти на питання. Окрім того, що він є глибоким прихильником, він також є генеральним директором Grubhub, найбільшої служби доставки їжі в Інтернеті в США. "Враховуючи обсяг транзакцій, які я роблю щодня, - каже Мелоні, - я міг би об'єктивно сказати вам, що краще".
Не давайте битися про те, чи «популярне» дорівнює «краще». Тому що в цілому, Мелоні, звичайно, має рацію. Оскільки 14,5 мільйона активних користувачів замовляють у 80 000 ресторанів, дані Grubhub повинні мати змогу розповісти вам багато про їжу. Мелоні хотів мати можливість сегментувати, кількісно оцінювати та порівнювати, хто що замовляв у районах та містах. Він хотів алгоритмічно рекомендувати страви, допомагати ресторанам оптимізувати свій вибір їжі, залучати нових клієнтів за допомогою швидкого обслуговування і відверто змусити клієнтів по всій країні діяти більше як жителі Нью-Йорка, які замовляють звідкись хоча б раз на тиждень.
Сьогодні Grubhub дійсно має алгоритм, який може проаналізувати цінні замовлення на вивезення в країні та повідомити користувачеві, який індійський джойнт біля них забезпечує найпопулярнішу курячу тікку масалу. Але для того, щоб туди потрапити, потрібно було вирішити, здавалося б, неможливу проблему з даними, трохи висококласного машинного навчання та автора кулінарної книги з Брукліна.
Порівняння Pad Thai
Проблемою були дані. Не замовлення - хто-замовляє-що і звідки. Це легко. Це було меню. Ніхто не поєднував страви, кожна з них була унікальною. Плов з одного ресторану може бути біріані в іншому. Японські каррі не були індійськими, а не пакістанськими. Вони працювали над цим вісім років. "Кожного разу, коли групи продуктів і технологій поверталися і говорили:" Метте, це занадто складно. Зрештою, щоб отримати те, що ви хочете, це буде ручне рішення, і у нас є 10 інших речей, які є пріоритетними ", - говорить Мелоні.
Його відповідь: “Хлопці. Ми багатомільярдна компанія і не можемо сказати людям, яка суть цих страшних страв? Ми навіть не можемо порівняти накладки тайського по всій країні? "
"Тому я змусив їх це зробити", - каже Мелоні.
Grubhub - це лише багатомільярдна компанія за обсягами продовольства, яке вона переміщує, не за своїми доходами, але навіть так: те, що хотів Мелоні, є складною проблемою. Це пов’язано з неструктурованим, sui generis характером меню ресторанів. Якщо у вас немає методології, призначеної для отримання даних, готових для статистичного аналізу, ви використовуєте "знайдені" дані, які завжди безладно, говорить Дункан Уоттс, соціолог з Microsoft Research. "В науці про дані існує суть про те, як 90 відсотків задіяної роботи очищає та впорядковує самі дані", - говорить Уоттс. "Це справедливо для даних електронної пошти, даних веб-переглядача, даних Twitter, новинних засобів масової інформації та навіть адміністративних даних, які повинні бути чистими".
Як зазвичай, вся система була б набагато простішою без людей у ній. Якщо ви намагаєтеся створити механізм рекомендацій, скажімо, для широкого потокового розважального сервісу, ну, більшість людей не переглядають один і той же фільм знову і знову. Таким чином, ви отримуєте поширення на їх поведінку. Це може бути менш вірно, коли справа стосується замов на вечерю. "Я прочитав деякі статті, в яких говориться, що існують типи дослідників, і є такі, які кажуть:" Це мій улюблений ресторан, то чому я повинен ходити куди-небудь ще? ", - говорить Джоел Сокол, директор магістра наук з аналітики ступінь в Georgia Tech. Тому вони можуть не хотіти нової рекомендації, якою б ідеальною вона не була. "Це насправді більше проблема бізнесу, ніж проблема даних", - говорить Сокол.
Більшість продуктів електронної комерції мають узгоджені метадані, так звані одиниці ведення запасів (або SKU), які чисельно відстежують запаси. Як результат, «купувати, орієнтуватися, відкривати, персоналізувати та рекомендувати порівняно просто, тому що все виглядає однаково для всіх», - каже Марія Білоусова, технічний директор Грубхуба. "Коли справа доходить до їжі, це зовсім навпаки. Grubhub та кожна інша компанія торгували абзацами тексту із заголовком та цінником ".
Шеф-кухар, який використовував регіональний, нестандартний написання назви страви, робив це меню несумісним з іншими, що використовували стандартне написання. Залиште інгредієнт, і раптом це інша страва. Білоусова каже, що спосіб примирити такі розбіжності часто полягає у "спільній фільтрації, тобто людям, яким це також подобається". Але вона каже, що для гіперлокальних підприємств, таких як сусідні ресторани, спільна фільтрація не працює добре. Не вистачає людей для співпраці та недостатньо варіантів для фільтрування. Всесвіт вибору та вибору занадто малий.
Якщо говорити мовами дослідників даних, то їжа - це неструктурована сфера. У Grubhub було 14 мільйонів пунктів меню, і єдине, що їх було спільне, це те, що іноді люди їх їли. Тож команда Білоусової взялася будувати власну таксономію їжі.
Вони зрозуміли, що мають три незалежні, але дублюючі набори даних. Спочатку у них було меню, повне унікальної мови сніжинок, яке кожен ресторан використовував для кожної страви, але з деякими спільними рисами. На щастя, оскільки ресторани дають свої меню Grubhub, а Grubhub перекладає їх для веб-сайту, людей, які готують їжу, стимулюють давати багато інформації.
По-друге, у Grubhub були журнали пошуку та огляди користувачів. Вони могли показати, що люди шукали і що врешті замовили. І компанія може обмежити виробництво цих даних фактичним, обізнаним споживачам, оскільки служба надає права на перегляд лише тим, хто насправді замовляв їжу. Це працює лише на платформі, де люди говорять про речі, які вони придбали; десь, наприклад, о, скажімо, Yelp в кінцевому підсумку стає більш безкоштовним для всіх і може бути менш корисним.
І по-третє, у них була історія замовлень для клієнтів і, що ще важливіше, обсяг замовлень для кожного пункту меню. У цій конструкції більше замовлень на товар повідомляє, що конкретний товар має високу якість - або, принаймні, популярний, що, так, не обов’язково одне і те ж. Але один може бути довіреним для іншого.