...

пятница, 18 сентября 2015 г.

Секреты алгоритма ценообразования Airbnb

Какую бы вы назначили цену за проживание незнакомцев в вашем доме? Или сколько вы сами заплатили бы за то, чтобы пожить у кого–то? Вы заплатили бы больше или меньше, будь это спланированный отпуск или спонтанная поездка?
Не так просто ответить на все эти вопросы. В своё время мы столкнулись с тем, что заставляя арендодателей и пользователей отвечать на них, мы тем самым уменьшали активную базу данных жилья. Собирая фокус–группы мы наблюдали за тем, как люди вносят своё жильё в список доступных для аренды мест на нашем портале. И большинство застревали, когда нужно было назначить стоимость. Многие начинали смотреть, какие цены установлены на жильё поблизости, открывая в браузере кучу вкладок и пытаясь сравнивать своё предложение с аналогичными. Кто–то уже приходил, имея определённую цель, может быть, чтобы немного заработать на оплату ипотеки или оплату отпуска. Такие люди устанавливали цену исходя из своих заранее обдуманных целей, без учёта реальной ситуации на рынке. А некоторые, к сожалению, просто сдавались и не указывали стоимость аренды их жилья.

Мы пришли к выводу, что нужно предложить арендодателям удобный автоматизированный сервис, помогающий принять решение при назначении стоимости аренды. Разработка началась в 2012 году, и мы до сих пор его периодически дорабатываем. Этим летом мы внедрили динамическое ценообразование: ориентировочные цены пересчитываются ежедневно, исходя из текущей рыночной ситуации. Мы настроили алгоритм так, чтобы он учитывал наличие необычных, даже удивительных свойств выставляемого жилья. Также мы внедрили, уникальный, как мы считаем, механизм машинного обучения, позволяющий системе не только обучаться на своём опыте, но и, при необходимости, использовать небольшую толику «человеческой» интуиции.
Алгоритмы для назначения и предложения цен используются во многих онлайн–сервисах. Например, eBay покажет список аналогичных проданных товаров и на его основе предложит выбрать цену. Но задача у этой торговой площадки была относительно простой: не важно, где территориально находятся продавцы и покупатели, а также когда именно будут проданы или куплены товары. В то же время для сервисов Uber и Lyft география и время имеют значение. Но в этих компаниях цены устанавливаются принудительно, и нужды в прозрачности ценообразования у них нет.

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

Три года назад мы начали создавать сервис, подсказывающий владельцам, какие можно установить цены исходя из параметров жилья: числа комнат и кроватей, соседского окружения, развитости инфраструктуры и многого другого. Первая версия сервиса была выпущена в 2013 году и по большей части неплохо выполняла свою задачу. Но у неё были определённые ограничения. Например, нельзя было поменять способ, с помощью которого алгоритмы определяли цены. Если они приходили к заключению, что в районе Perl в Портленде, например, есть определённые ограничения по цене, или что жильё в прибрежных домах должно быть на столько–то дороже, чем кварталом дальше, то алгоритмы применяли эти метрики всегда, пока их не корректировали вручную. Также ценообразование не было динамическим: советы арендодателям не зависели от времени года или востребованности жилья в данном районе.

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

Три ситуации


Чтобы оценить трудности, которые нам предстояло преодолеть, давайте рассмотрим три разные ситуации.

Представьте, что вы живёте в Бразилии, и скоро начнётся очередной Чемпионат по футболу. В ваш город нахлынут туристы и болельщики со всего света. У вас есть подходящая комната в доме, и вы хотите немного подзаработать, сдавая её любителям футбола. Чтобы наш сервис мог предложить вам адекватную цену, он должен был учесть несколько факторов. Во–первых, Чемпионат Мира по футболу — уникальное событие для этой страны, происходящее крайне редко. И нам просто не от чего отталкиваться. Во–вторых, номера во всех отелях уже забронированы, так что налицо был огромный дисбаланс спроса и предложения. В–третьих, прибывающие туристы уже заплатили немалые деньги за международные перелёты, так что они наверняка готовы хорошо потратиться и на проживание. Всё это должно быть учтено помимо основных критериев вроде размера жилья, расположения и числа комнат.

Вторая ситуация: вы унаследовали от богатого дядюшки Маклауда замок в горах Шотландии со всей причитающейся атрибутикой. И вам нужно регулярно выкладывать круглую сумму на очистку рва с водой, работу вискикурни, кормление соколов и т.д. Чтобы облегчить своё финансовое бремя, вы решили превратить одну из башен замка в сдаваемые апартаменты. В отличие Чемпионата Мира по футболу, вам есть от чего отталкиваться, учитывая некоторое количество замков в округе. Причём по некоторым критериям доступна статистика за многолетние периоды, например, сезонность туризма. И вы с большой долей точности можете оценить, что в данный момент спрос и предложение сбалансированы. Хотя ваш замок весь из себя уникальный. Как системе оценить в деньгах привлекательность этой уникальности для посетителей?

И наконец, третий пример. Допустим, вы владелец типичной двухкомнатной квартиры в Париже. Вы хотите взять несколько недель отпуска в августе и отправиться на юг страны, в Монпелье. Ваше предложение можно сравнить с огромным количеством других позиций, так что цену определить достаточно легко. Но после первичного размещения вы видите, что люди проявили интерес к вашему жилью, и решили немного поднять цену, чтобы заработать побольше. Но это дело тонкое — что будет, если вы слишком сильно задерёте стоимость аренды или повысите её слишком близко к забронированной дате заезда? Может быть, вы вообще ничего не заработаете, оставшись без клиентов. Но если вы не рискнёте поиграть ценой и удовлетворитесь рекомендованной, достаточно низкой суммой, то потом несколько месяцев будете корить себя за нерешительность и переживать о возможной упущенное выгоде. Как нам помочь владельцам получить наилучшую информацию, чтобы они не оказывались в состоянии неуверенности или сожаления?

Вот с такими вот проблемами мы и столкнулись. А ведь нам хотелось создать простой в обращении сервис, полезный при принятии решений о ценообразовании, с прозрачными правилами.

Архитектура


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

Трудности начались уже на стадии определения ключевых параметров как таковых. Не бывает двух одинаковых позиций, как по убранству, так и по планировке. Предлагаемое жильё разбросано по всему городу, многие позиции являются не квартирами и домами, а какими–нибудь замками, хижинами и юртами. Тогда мы решили, что наш сервис должен ориентироваться на три основных типа данных: сходство, новизну и местоположение.

Для определения сходства мы начали собирать все измеряемые количественно параметры. После этого анализировали, какие из них лучше всего коррелируют с ценами, которые гости готовы платить за конкретные позиции. Мы оценивали, сколько человек там может переночевать, сдаётся ли весь объект целиком или лишь комната, что это за тип жилья (квартира, замок, юрта), количество отзывов и многое другое.

Самое удивительное оказалось связано с количеством отзывов. Судя по нашим наблюдениям, люди готовы платить больше за позиции, имеющие большое количество отзывов. Amazon, eBay и прочие сервисы ориентируются на выставленные в отзывах оценки, помогая пользователям определиться с товарами и продавцами, у них не ясно влияние количества отзывов на цену. У нас же позиция с одним единственным отзывом будет сильно отличаться от подобных, но без отзывов.

Параметр «новизна» мы выбрали потому, что ситуация на рынках часто меняется, особенно в сфере туризма. Этот бизнес крайне подвержен влиянию сезонности, и при оценке нужно ориентироваться на сегодняшний день, потому что в прошлом году в это время или в прошлом месяце всё могло быть по другому.

На развитых рынках, вроде Лондона или Парижа, все эти данные собрать достаточно просто благодаря большой истории бронирований. А новые и развивающиеся рынки мы делим на группы согласно их размеру, уровню туризма и динамике роста предложений на нашем портале. Это помогает сравнивать с позициями не только в том же городе, но и с похожими предложениями на других рынках. Скажем, если кто–то впервые выставил жильё в Киото, то мы можем сравнить с предложениями в Токио, в Окаяме или даже в Амстердаме.

И наконец, мы оцениваем местоположение жилья, что для нас куда более сложная задача, чем для отелей. Те обычно группируются в нескольких основных районах, у нас же позиции разбросаны по всему населённому пункту.

Ранние версии


Сначала наш алгоритм ценообразования рисовал окружность с центром по указанному владельцем адресу жилья. Радиус брался исходя из аналогичных параметров близлежащих предложений. Какое–то время этот подход неплохо работал, но однажды мы обнаружили критическую проблему. Возьмём некую квартиру в центре Парижа, скажем, перед мостом Пон–Нёф, рядом с Лувром или Садом Тюильри. Но в этом случае обведённая окружность очень разные дома и квартиры на другой стороне реки, куда менее дорогие и престижные. В Париже стоимость жилья очень сильно различается в зависимости от того, на каком берегу Сены оно расположено. А в других городах встречаются ещё более ярко выраженные разделения. Например, в Лондоне стоимость квартир в районе Гринвич может более чем в два раза превосходить стоимость жилья в районе доков, находящихся напротив через реку.

Пример изменения цен в Остине, штат Техас, во время фестивалей SXSW и Austin City Limits.

В результате нам пришлось составлять схематические карты кварталов и районов в крупных городах по всему миру, с учётом местных условий. Это позволило очень точно кластеризовать позиции в базе данных на основе основных географических особенностей и структур: рек, транспортных путей и т.д. И теперь в октябрьские выходные комната на двоих в Гринвиче стоит около $130 за ночь, а аналогичное жильё, но через реку напротив, около $60.

Выкатив очередную версию алгоритма, мы были очень довольны собой. Ведь нам удалось исправить баг, из–за которого система рекомендовала для многих позиций назначить стоимость в $99, вне зависимости от конкретных характеристик. Длилось это недолго, да и не во всех регионах, но если бы мы оставили всё как есть, то нам рано или поздно начали бы задавать вопросы относительно корректности советов сервиса.

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

Кроме того, сервис сам по себе оставался статичным. Его оценки строились на всё большем количестве статистических данных, но сам алгоритм не улучшался.

Новый алгоритм


Прошлым летом мы запустили проект, который был призван решить обе эти проблемы. Во–первых, мы хотели сделать динамическое ценообразование — чтобы наш сервис мог прогнозировать стоимость жилья на каждый день в будущем. Этот подход далеко не нов, авиалинии используют его уже несколько десятилетий, изменяя цены — зачастую в режиме реального времени — с целью максимального заполнения самолётов и получения максимальной прибыли с каждого пассажира. По аналогичному пути сегодня идут и крупные сети отелей, анализируя массивы статистических данных о работе всех своих филиалов. А поскольку к тому времени мы тоже накопили немало информации о рынках аренды жилья по всему миру, то тоже решили сконцентрироваться на динамическом ценообразовании, несмотря на более высокие требования к вычислительным ресурсам.

Труднее было сделать алгоритмы саморазвивающимися. Особенно с учётом того, что мы хотели сделать систему с прозрачными и понятными для человека правилами, чтобы можно было на них как–то повлиять при необходимости. Сложные и мощные системы машинного обучения, которые справились бы с решением наших задач, зачастую работают как–то странно. Например, Google Brain, научившийся находить кошек на видео в сети, содержит несколько уровней алгоритмов, классифицирующих данные. И человек практически не в состоянии воспроизвести порядок «умозаключений», в результате которых Google Brain решает, кот перед ним или нет.

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

Конечно владельцы вправе не следовать совету сервиса и назначать стоимость выше или ниже рекомендуемой. В этом случае система пересчитает вероятность успешности сдачи, а позднее сравнит прогноз с реальным положением дел. Результаты сравнения будут использованы при расчёте будущих рекомендаций.

Алгоритм использует статистику цен аренды для группирования предлагаемых позиций в микрокластеры по степени сходства.

Это и является элементом обучения алгоритма. Зная, насколько успешной была та или иная рекомендованная цена, система подстраивает веса, назначаемые разным параметрам жилья — «сигналам», как мы их называем. Мы начинали с ряда предположений. Например, что географическое местоположение крайне важно, а наличие гидромассажной ванны — не особенно. Также мы пересмотрели систему параметров, какие–то исключив, какие–то добавив. Некоторые из новых сигналов, вроде «количество дней, оставшихся до даты въезда», влияют на функцию динамического ценообразования.

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

Если будет нужно, то мы можем повлиять на расчёт весов, если сочтём, что это улучшит точность рекомендаций. Наша система может генерировать список факторов и весов, влияющих на стоимость аренды каждой позиции. Если мы решим, что какая–то сторона вопроса представлена недостаточно полно, то мы вручную добавим в модель нужные сигналы. К пример, мы знаем, что в Сиэтле у жилья без Wi–Fi очень мало шансов быть арендованным, причём при любой цене. И нам не нужно ждать, пока алгоритм до этого «додумается», мы можем поправить метрики самостоятельно.

Также наша система постоянно исправляет на карте схемы районов, объединённых по ряду параметров. Мы не ориентируемся на существующие официальные карты, а исходим из собственной накопленной статистики по ценам и бронированиям. Этот подход позволяет нам также выделять микрорайоны, которые мы ранее не брали в рассмотрение. Они могут объединять многочисленные популярные позиции, и их границы вовсе не обязательно совпадают с муниципальными. Также микрорайоны могут выделяться по наличию каких–то местных особенностей, привлекающих туристов в «большой» район.

Сегодня наш сервис ценовых рекомендаций ежедневно обслуживает множество владельцев жилья, разместивших свои предложения на портале. Но мы считаем, сервис способен делать гораздо больше. Поэтому мы платформу Aerosolve, на которой он построен, мы выпустили под лицензией Open Source. С её помощью многим разработчикам будет легче начать работать с системами машинного обучения. Ясно представляя, как работает платформа, можно не опасаться новой для себя области и свободно экспериментировать с инструментарием. Например, с помощью того же Aerosolve мы создали систему, рисующую картины в стиле пуантилизма. Так что предлагаем всем желающим и прочим сочувствующим самостоятельно поработать с платформой. Кто знает, сколько замечательных продуктов удастся создать на ней сообществу.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.

Комментариев нет:

Отправить комментарий