Как в Яндекс.Такси ищут машины, когда их нет +39



image

Хороший сервис для заказа такси должен быть безопасным, надёжным и быстрым. Пользователь не станет вдаваться в детали: ему важно, чтобы он нажал кнопку «Заказать» и как можно быстрее получил машину, которая доставит его из точки А в точку Б. Если рядом нет машин — сервис должен сразу об этом сообщить, чтобы у клиента не складывалось ложных ожиданий. Но если плашка «Нет машин» будет высвечиваться слишком часто, то логично, что человек просто перестанет пользоваться этим сервисом и уйдёт к конкуренту.

В этой статье я хочу рассказать о том, как при помощи машинного обучения мы решали задачу поиска машин на территории с малой плотностью (проще говоря — там, где, на первый взгляд, нет машин). И что из этого вышло.

Предыстория


Чтобы вызвать такси, пользователь совершает несколько простых действий, а что при этом происходит во внутренностях сервиса?
Пользователь Этап Бэкенд Яндекс.Такси
Выбирает точку отправления Пин Запускаем упрощённый поиск кандидатов — поиск на пине. На основе найденных водителей предсказывается время приезда — ETA в пине. Рассчитывается повышающий коэффициент в данной точке.
Выбирает точку назначения, тариф, требования Оффер Строим маршрут и рассчитываем цены на все тарифы с учётом повышающего коэффициента.
Нажимает кнопку «Вызвать такси» Заказ Запускаем полноценный поиск машины. Выбираем наиболее подходящего водителя и предлагаем ему заказ.

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

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

Вот что видел пользователь в приложении:



Поиск машин без машин


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

Чтобы проверить эту гипотезу, мы запустили эксперимент: перестали проверять наличие машин во время поиска на пине для тестовой группы пользователей, т. е. у них появилась возможность сделать «заказ без машин». Результат получился довольно неожиданным: если машина не находилась на пине, то в 29% случаев она находилась позже — при поиске на заказе! Более того, заказы без машин не сильно отличались от обычных по частоте отмен, оценкам и прочим показателям качества. Число заказов без машин составило 5% всех заказов, но чуть более 1% всех успешных поездок.

Чтобы понять, откуда берутся исполнители этих заказов, посмотрим на их статусы во время поиска на пине:



  • Свободен: был доступен, но по каким-то причинам не попал в кандидаты, например был слишком далеко;
  • На заказе: был занят, но успел освободиться или стать доступным для заказа по цепочке;
  • Занят: возможность принимать заказы была отключена, но потом водитель вернулся на линию;
  • Недоступен: водителя не было в сети, но он появился.

Добавим надёжности


Дополнительные заказы — это замечательно, однако 29% успешных поисков означают, что в 71% случаев пользователь долго ждал и в итоге никуда не уехал. Хотя с точки зрения эффективности системы в этом нет ничего ужасного, но на самом деле, пользователь получает ложную надежду и тратит время, после чего расстраивается и (возможно) перестаёт пользоваться сервисом. Чтобы решить эту проблему, мы научились предсказывать вероятность того, что машина на заказе будет найдена.

Схема такая:

  • Пользователь ставит пин.
  • Проводится поиск на пине.
  • Если машин нет — предсказываем: может быть, они появятся.
  • И в зависимости от вероятности даём или не даём сделать заказ, но предупреждаем, что плотность машин в этом районе и в это время маленькая.

В приложении это выглядело так:



Использование модели позволяет аккуратней создавать новые заказы, не обнадёживать человека напрасно. То есть регулировать соотношение надёжности и числа заказов без машин с помощью precision-recall модели. Надёжность сервиса влияет на желание и дальше пользоваться продуктом, т. е. в итоге всё сводится к числу поездок.

Немного про precision-recall
Одна из базовых задач в машинном обучении — задача классификации: отнести объект к одному из двух классов. При этом результатом работы алгоритма машинного обучения часто становится числовая оценка принадлежности к одному из классов, например оценка вероятности. Однако действия, которые совершаются, обычно бинарные: если машина будет — то даём заказать, а если нет — то нет. Для определённости назовём моделью алгоритм, который выдаёт числовую оценку, а классификатором — правило, которое относит к одному из двух классов (1 или –1). Чтобы на основе оценки модели сделать классификатор, нужно подобрать порог оценки. Как именно — сильно зависит от задачи.

Предположим, мы делаем тест (классификатор) на какую-то редкую и опасную болезнь. По результатам теста мы или отправляем пациента на более подробное обследование, или говорим: «Здоров, иди домой». Для нас отправить домой больного человека гораздо хуже, чем зря обследовать здорового. То есть мы хотим, чтобы тест срабатывал для как можно большего количества реально больных людей. Эта величина называется recall =$\frac{число\ определённых\ классификатором\ больных}{число\ всех\ больных}$. У идеального классификатора recall равен 100%. Вырожденная ситуация — отправлять на обследование всех, тогда recall тоже будет 100%.

Бывает и наоборот. Например, мы делаем тестирующую систему для студентов, и в ней есть детектор списывания. Если вдруг на какие-то случаи списывания не сработает проверка, то это неприятно, но не критично. С другой стороны, крайне плохо незаслуженно обвинять студентов в том, чего они не совершали. То есть нам важно, чтобы среди положительных ответов классификатора было как можно больше правильных, возможно, в ущерб их количеству. Значит, нужно максимизировать precision = $\frac{число\ верных\ срабатываний}{число\ всех\ срабатываний}$. Если срабатывания станут происходить на всех объектах, то precision будет равен частоте определяемого класса в выборке.

Если алгоритм выдаёт числовое значение вероятности, то, подбирая разные пороги, можно добиться разных значений precision-recall.

В нашей задаче ситуация следующая. Recall — число заказов, которое мы можем предложить, precision — надёжность этих заказов. Вот так выглядит precision-recall кривая нашей модели:

Есть два крайних случая: не разрешать заказывать никому и разрешать заказывать всем. Если не разрешать никому, то recall будет 0: мы не создаём заказов, но зато никакой из них не станет провальным. Если разрешать всем, то recall будет 100% (мы получим все возможные заказы), а precision — 29%, т. е. 71% заказов окажутся плохими.


В качестве признаков мы использовали различные параметры точки отправления:

  • Время/место.
  • Состояние системы (число занятых машин всех тарифов и пинов в окрестности).
  • Параметры поиска (радиус, число кандидатов, ограничения).

Подробнее о признаках


Концептуально мы хотим различить две ситуации:

  • «Глухой лес» — машин тут в это время не бывает.
  • «Не повезло» — машины есть, но вот при поиске подходящих не оказалось.

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

Поэтому хорошими фичами оказались различные показатели системы в окрестностях точки А:

  • Общее число машин.
  • Число машин на заказе.
  • Число недоступных для заказа машин в статусе «Занят».
  • Число пользователей.

Ведь чем больше вокруг машин, тем более вероятно, что какая-нибудь из них станет доступна.
На самом деле для нас важно, чтобы не просто находились машины, но и совершались успешные поездки. Поэтому можно было предсказывать вероятность успешной поездки. Но решили так не делать, потому что эта величина сильно зависит от пользователя и водителя.

В качестве алгоритма обучения модели применяли CatBoost. Для обучения использовали данные, полученные из эксперимента. После внедрения пришлось собирать обучающие данные, иногда позволяя небольшому числу пользователей делать заказ вопреки решению модели.

Итоги


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

На данный момент механизм запущен во всех городах и странах и с его помощью происходит около 1% успешных поездок. Причём в некоторых городах с небольшой плотностью машин доля таких поездок доходит до 15%.

Другие посты о технологиях Такси


Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (41):

  1. YaMishar
    /#20150914

    У меня пара вопросов.
    А почему предлагается только одному водителю? В результате пользователь ждёт какое-то время (может водитель в это время вышел из машины фары протереть). В результате получается задержка в нахождении. Не лучше ли при ранжировании посылать 3-5 лидерам, если их ранк в поиске сравним? А если ранки отличаются, то скажем послать первому, с небольшой задержкой второму и т.д.
    Второй вопрос скорее организационный. Если я заказываю из Шереметьево машину, я знаю, что вот — в 50м от меня целая парковка забитая машинами Я-Такси. Я вижу в них водителей. Но при заказе мне находится машина, которая едет ко мне потом 10 минут. Эти водители — не на линии?

    • vomar
      /#20151074

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

      В аэропортах из-за разных особенностей заказы распределяются немного иначе — в порядке очереди водителей. Поэтому иногда может назначаться не ближайшая машина.

      • YaMishar
        /#20151412

        Погодите. Вы же себе противоречите. У вас же в тексте

        Пользователь не станет вдаваться в детали: ему важно, чтобы он нажал кнопку «Заказать» и как можно быстрее получил машину, которая доставит его из точки А в точку Б

        Я не вижу ничего суперопасного в том, что вместо кнопки «взять заказ» у водителя будет «предложить себя». А у пользователя получится преимущество даже выбрать из предложенных вариантов (по рейтингу или по автомобилю, если такое требуется). Чисто как идея — вы можете такое открывать скажем лояльным пользователям только. После 100-1000 поездок. Но мне лично сейчас непонятно, почему мой заказ принимает водитель, который едет из Шереметьево в сторону Ленинградки. И я жду его 10-12 инут, пока он развернётся и проедет всё Международное шоссе ещё раз.

        • putnik
          /#20153556

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

          • Losted
            /#20153692

            Вполне рабочая. Taxify так работает в европах, насколько я помню

          • YaMishar
            /#20154264

            Я прелагаю так делать для лояльных пользователей. Как-то надо лояльность поддерживать? да и время выбора ограничить 5-10с. Эир не сильно повлияет в сравнении с тем, что сейчас я могу например получить вариант «машина приедет через 12 минут», потом я отказываюсь, повторяю поиск и тут же получаю «приедет через 3 минуты»

      • imm
        /#20151802

        человек просто перестанет пользоваться этим сервисом и уйдёт к конкуренту

        Не хочется лишний раз дёргать водителя, особенно за рулём.

        вы бы всё-таки определились, что в приоритете — клиенты, или кривой алгоритм на который все плюются (зато одобренный руководством).
        вот сложно что-ли дёрнуть не одного водителя из очереди, а 3-5 стоящих N минут водителей рядом? неужели у вас проблемы с анализом текущего состояния водителя?
        для чего заставлять клиента ждать овер 10 минут, когда рядом скучающих машин — полстоянки? для чего дёргать уехавшего водителя?

        • vomar
          /#20152780 / -1

          вот сложно что-ли дёрнуть не одного водителя из очереди, а 3-5 стоящих N минут водителей рядом?

          Водители тоже наши пользователи. Мы не хотим дёргать 3-5 водителей ради того чтобы сократить время поиска на несколько секунд.

          для чего заставлять клиента ждать овер 10 минут, когда рядом скучающих машин — полстоянки?

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

      • Accounter
        /#20151834

        Еще в аэропортах таксисты не любят получать оплату картой. Пример: знакомый заказал такси с оплатой корпоративной картой. Делал заказ трижды, так каждый таксист, когда узнавал, что оплата картой — отменял заказ. В результате три-четыре отмены заказа — и потенциального клиента заблокировали в приложении. Таксисты, наверное, заминусовали его карму в приложении где-то.

  2. Koroed
    /#20151382

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


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


    Нельзя указать при заказе на ближайшее время что мне не нужен водитель который будет ехать ко мне 15 минут и я все равно не буду его ждать и отменю заказ. Кстати такая ситуация тоже встречается часто, независимо от количества машин рядом. Добавили бы какое-нибудь максимальное время ожидания.


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

    • Sanovskiy
      /#20151414

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

      • Koroed
        /#20151432

        Ну если бы этот кейс обрабатывался то братья и жены у водителя кончились бы довольно быстро. А сейчас яндекс даже при всем желании не сможет посчитать сколько заказов отменяется по такой схеме.

      • ITurchenko
        /#20154768

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


        Агрегатору достаточно мониторить аккаунт водителя (телефон/паспортные данные/итп) И автомобиль (госномер/птс/итп). Считать что в течении года автомобиль закреплен за этим водителем, если это частник. Если это таксопарк — выставлять претензии таксопарку в целом с расценками для юрлиц, потом они пусть сами как хотят с водителем проблему решают.

        Всё, проблема решена. Но делать этого мы конечно не будем.

        • sergey-b
          /#20163814

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


          Ну уж нет. Пусть лучше пассажиры в экран по полчаса тыкают.

    • teemour
      /#20151430

      А как вообще водитель получает заказ если он не хочет ехать? Там что обязаловка?

      • Koroed
        /#20151446

        Я полагаю что водитель не видит точную точку назначения. Ему просто пишут примерное время, которое потребуется на заказ. Ну что-то вроде «заказ от Красной площади, ехать примерно на 30 минут». А в какую именно сторону он не знает. Может в популярное место, а может в промзону.

        • remzalp
          /#20151554

          Просто видит условный заказ, но детали его узнаёт только после взятия заказа.

        • YaMishar
          /#20151586

          Ну вроде точку он видит. Он же переспрашивает — «На 3ью улицу Строителей?».
          Меня однажд не посадили в минивен (просто не обратил внимания с прошлой поездки, что стоит семейный тариф) мотивировав тем, что «зачем вам одному кататься в большой машине». Пришлось ещё стоять под дождём.
          После этого я перешёл к альтернативному аггрегатору, и пока не жалею. Пользуюсь Я.Такси в редких случаях, когда у альтернативного долго ждать.

          • imm
            /#20151760

            Конечную точку водитель не видит, пока не приедет за клиентом.

          • tundrawolf_kiba
            /#20151918

            Ну вроде точку он видит. Он же переспрашивает — «На 3ью улицу Строителей?».

            Они видят только когда подъезжают к точке отправления. Хотя вот читал вроде Яндекс в некоторых регионах тестирует бонусную программу, и водители с рейтингами 4.9 и выше смогут видеть точку прибытия сразу, когда появляется предложение заказа.

          • dmitryvolkovtaxi
            /#20152236 / +1

            Здравствуйте! Я из команды поддержки Яндекс.Такси. Водитель не должен так поступать, хотим разобраться в этой ситуации.
            Напишите, пожалуйста, подробности нам на почту: blogs@taxi.yandex.ru.

            • YaMishar
              /#20153178

              Извините, но это было 2 года назад, смысла уже нет. Меня просто удивило.

  3. x67
    /#20151790

    1. Определенно стоит понимать, что в не очень популярной зоне ожидания клиента скромнее и скорее всего, если у него нет альтернатив поездке на такси, ему придется искать авто какое то время, а потом ждать приезда. Значит для таких зон можно чуть увеличивать допуски для заказов по цепочке — время ожидания будет предсказуемее для пользователя
    2. Определенно стоит учитывать автомобили на заказе, которые едут в зону поиска, ведь почти всегда известна точка назначения, а значит за время поиска такой автомобиль может стать доступным для заказа по цепочке
    3. Определенно стоит смягчить ваши фильтры для водителей в непопулярных зонах, а в определенных случаях их не должно быть вообще — клиент должен получить услугу и это важнее, чем ваша "воспитательная" система для водителей.
    4. Определенно стоит иметь понимание по количеству расчетов стоимости поездки в определенной зоне в определенное время, так как эта переменная позволит оценить потребность в такси и независима от предложения, а значит показывает более реальную картинку спроса
    5. Определенно стоит без кнутов и пряников показывать таксистам, оказавшимся в непопулярной зоне, где недалеко они могут пригодиться, дабы они перетягивались при необходимости в зоны, где спрос, расчитанный по п.4 выше предложения — это удобно и водителям и вам и клиентам

  4. Warrangie
    /#20152126

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

    • vomar
      /#20152790

      Похоже на какие-то сбои. С такой системой поиск либо начинается, либо нет, прерывается только по достаточно большому таймауту.
      Если такое будет повторяться, напишите в поддержку, например на blogs@taxi.yandex.ru.

  5. aborouhin
    /#20152684

    Чтобы помочь «территориям с малой плотностью» (сам в такой живу, коттеджная застройка, от МКАД 30 км) и самим увеличить охват клиентов с таких территорий — лучше бы Вы сделали опцию заказа на будущее время. Из-за отсутствия этой возможности вынужден для поездок, где опоздание критично неприемлемо (в аэропорт в основном), по старинке заказывать такси из местной службы по телефону, что неудобно, дороже, но надёжнее.
    У Гетт такая опция есть — но там свои фокусы: искать водителя они начинают только за полчаса до указанного времени, а этак в 4 часа ночи ни одного желающего ехать к нам, что неудивительно, зачастую не находится. Хотя, может, час-два назад кто-то как раз приехал в нашу сторону и предпочёл бы вздремнуть, дождавшись моего заказа, чем возвращаться пустым.

    • vlad49
      /#20152840

      Люто поддерживаю. Необходима возможность заказать машину на определенное время и быть уверенным, что она железно и гарантированно приедет, вне зависимости от плотности территории, пробок, высокого спроса, загрузки, времени и других факторов. Чтобы водитель осознанно принял решение о поездке в это место хотя бы за 3-4 часа, а не за 15 минут — и если там не окажется — все кары на него бы обрушивались какие только можно. А клиенту дополнительную уверенность придавало бы сообщение — «Водитель найден и выедет к вам через 3 часа 25 минут. Позвонить ему?»

      Видимо, весь AI и ML Яндекса пока на такое неспособен. Только старый добрый живой диспетчер в службе заказа.

      • sergey-b
        /#20163826

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

    • Aingis
      /#20154986

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

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

      • aborouhin
        /#20155514

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

        Во-вторых, в ряде случаев подобная опция ещё и приведёт-таки к снижению издержек. Опять же, особенно в малопопулярных территориях, откуда до оживлённых мест ехать далеко и пустым — невыгодно, так что водитель предпочёл бы подождать более поздний заказ, если бы он таковые видел, а то и вообще заранее подбирать два последовательных заказа «туда» и «обратно». Заказы-то эти сами по себе на фоне коротких поездок по городу дорогие.

        • sergey-b
          /#20163838

          У этих динозавров есть то, чего нет у Яндекса, — машины, которыми они распоряжаются. Диспетчер таксопарка дает водителю задание ехать туда-то к такому-то времени, и с вероятностью 99% водитель это задание выполнит. А Яндекс публикует кота в мешке: "Эй, есть заказ неизвестно куда. Кто желает взять?" — и ждет, когда кто-то откликнется. Естественно, никакие долгосрочные прогнозы в такой модели невозможны.

  6. gleb_l
    /#20153252

    Можно cделать статистическое предположение, сколько времени проходит в среднем (по всем пользователям, или только для текущего) между событиями Пин и Заказ, и прогнозировать доступность такси по событию Пин, но на время в будущем, равное текущему + среднее время между этими двумя событиями. Для свободных водителей можно считать среднее время между взятиями заказов, а для занятых на момент Пин вблизи точки вызова — ожидаемое время окончания текущего заказа, исходя из конечной точки маршрута. В итоге будем иметь модель краткосрочного прогноза доступности такси, которой можно дать больший вес в часы пик. Чтобы лишний раз не напрягать бакенд, от фронта можно получать сигналы активности юзера (типа, как от мессенджеров typing...) — о том, что после события Пин идет выбор точки назначения. Тем клиентам, от которых идет событие выбора точки или параметров поездки, давать большую вероятность совершения поездки (то есть появления события Заказ)

  7. PeoneEr
    /#20154276

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

    1. Водители просто не берут заказ
    2. Взяв заказ, водитель через какое-то время от него отказывается
    3. Взяв заказ, водитель приезжает на пин и тут выясняется, что у него нет пропуска, хотя я этот вопрос задаю в чат сразу же, как только водитель берет заказ

    и крайне редко случается четвертый кейс: у водителя таки есть пропуск и я спокойно еду домой.
    В кейсах 1 и 2 я остаюсь искать машину дальше, в кейсе 3 я еду до кпп и с кпп вызываю еще одну машину.
    В чем проблема вызвать машину до кпп сразу, а потом пересесть? Малый процент водителей всё же хочет туда ехать, т.к «пустой» пробег будет довольно велик, хотя и ценник на такую поездку в районе 400р, что для нашего города вполне приличная цена за такси. Я по своему городу больше 150р никогда не платил.

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

    • Skerrigan
      /#20155122

      Северск/Томск?
      Просто крайне знакомые паттерны :)
      UPD: Да, точно! Машу рукой, ваш сосед по «региону» :)
      Подтверждаю — проблема имеет место быть.

  8. dovg
    /#20155084

    О, самое время начать ныть.
    Яндекс, в больших городах с такси проблем нет. Но недавно вы пришли ко мне на малую родину, сильно уронили цены и случилась вполне ожидаемая вещь.
    Ночью в пригород никто не хочет ехать, и это даже понятно: за 10-километровую поездку предлагается заплатить меньше 200 рублей, при этом таксист точно знает, что из условного Нововятска заказов до утра точно не будет. То есть обратно он поедет пустым.

    Я бы очень хотел, чтобы в приложении была кнопка «двойной тариф» или даже «тройной тариф», которая бы позволила мне повысить цену, но все-таки уехать, а не сидеть в баре ночью одному, зато дешево.
    Сейчас я эту проблему решаю так: вызываю такси до соседнего дома, а уже потом голосом водителю говорю: поехали в %SUBURBAN_NAME% за 500 рублей. Еще ни один не отказался.
    Было бы классно, если бы это могло делать приложение за меня, избавляя меня от необходимости коммуницировать с водителями.

    • LumberJack
      /#20155530

      Тут палка о двух концах: В одном не менее известном агрегаторе, однофамильце пулемёта, сделали такую кнопку. В результате водители, видя заказ по «базовой» цене просто не берут его, пока заказчик не поднимет цену поездки хотя б рублей на 20-30, причём по карте видно, что свободные машины есть.

      • dovg
        /#20155550

        Рынок всё расставит по местам. Если таксисты не берут заказ, значит считают, что это невыгодно. Это их право.
        Я прошу дать мне возможность заплатить больше, разве это плохо?

        Кстати еще в одном агрегаторе есть «приоритетный режим», но он добавляет к цене поездки всего 30-50 рублей, что в моем случае не производит требуемого эффекта.

  9. dm9
    /#20155744

    Довольно забавно, что единственная техническая, обучающая и потенциально полезная информация про precicion/recall стыдливо спрятана под спойлер.

  10. SergeyMarkelov
    /#20158106

    1. Поддерживаю двумя руками предложение aborouhin и vlad49 ввести опцию предварительного заказа на будущее время!

    В Uber предварительные заказы возможны (английская ссылка, русская). Но деликатно написано: «Вы можете запланировать поездку почти во всех городах присутствия Uber. Проверьте в своем приложении, доступно ли планирование поездок в вашем районе.»

    В России Uber работает по технологии Яндекса, предварительных заказов нет — и это создает изрядное неудобство тем, кто регулярно ездит с дачи в Московской области в Москву. Кругом лес, машин нет, агрегировать нечего — но вызвать такси иногда нужно. Сейчас для этого приходится раз в 5 минут проверять приложение — и за полчаса-час проезжает машина в радиусе поиска, удается ее вызвать. Бессмысленная деятельность по монотонному тыканью в приложение раздражает. Когда Яндекс выпустил приложение Uber Russia, он многое улучшил по сравнению с обычным Uber — но в этом месте есть неочевидное ухудшение. В обычном Uber надпись «нет свободных машин» является кнопкой, на нее можно нажать (и Uber будет искать машины какое-то время — вдруг появятся?). В Uber Russia надпись «нет свободных машин» вообще не кнопка, на нее нельзя нажать.

    В Lyft (второй после Uber агрегатор в США с долей в 30%) тоже есть предварительные заказы (Scheduled Ride).

    Но вернемся в Московскую область. Если нужно с дачи уехать ночью, даже и часа постоянной проверки приложения может не хватить, приходится заниматься «подманиванием»: с одного телефона вызывать машину к деревне, которая полпути до железнодорожной станции (у которой машины есть). Когда машина подъезжает к деревне, нужно одновременно на первом телефоне отменить заказ, и на втором вызвать уже на дачу. Так машина приезжает.

    Заниматься этим хлопотно, да и морально стыдно. Оставляю потом водителю повышенные чаевые, чтобы он не расстраивался. Но другого пути гарантированно вызвать Яндекс-такси на дачу ночью — не вижу.

    Если разработчики Uber и Lyft как-то смогли предварительные заказы запрограммировать — значит и разработчики Яндекс наверняка смогут!

    2. Кроме предварительного заказа, хочу внести предложение по улучшению в срочные. Вместо надписи «нет свободных машин» показывать объективную картину — ОК, в обычной окрестности машин нет, но ведь в какой-то большей окрестности они есть? Сделайте мне предложение! Вероятно, такая поездка обойдется дороже из-за долгой подачи (а может и нет, если поездка далекая, водитель будет готов на долгую подачу). Почему бы не показывать пользователю: «эконом может приехать через 40 минут и стоить будет XXX, минивэн через 72 минуты по цене YYY». Может быть, меня устроит и время подачи, и цена? Мне же все равно как-то надо уехать после вечеринки на даче у друзей…

    Вижу 2 возможных контраргумента, почему Яндекс может не хотеть вводить такой сервис:

    — Страх снижения репутации (пользователь увидит, что Яндекс предлагает подать машину за 45 минут, ха-ха-ха). На мой взгляд, так не будет. Если я на даче, кругом машин объективно нет — не только у Яндекса, но и у других агрегаторов. Если Яндекс может подать машину за 45 минут, а другой агрегатор за 60 или вообще не может — я уеду на Яндексе и буду доволен.

    — Страх, что найдутся «шутники», которые будут вызывать водителя в далекий коттеджный поселок, и в последнюю минуту отменять заказ. Если водитель ехал до заказа долго — Яндексу придется компенсировать водителю подачу. Что ж, «шутники» бывают, увы — но ведь Яндекс знает обо мне все. В частности, знает что у меня было более 1000 заказов Яндекс-такси, и ни разу ни один водитель не пожаловался на проблемы с оплатой. Кроме того, Вы видите, что у меня есть Яндекс-деньги в заведомо достаточном количестве. Вы можете заблокировать стоимость подачи у меня на Яндекс-кошельке или на карточке. А если у пользователя хорошая личная статистика, можно и при наличной оплате давать ему возможность делать заказы со сверхдлинной подачей.

    Вот скриншот, чего хотелось бы: рядом с этой дачей машин не было ни у Яндекса, ни у Ситимобиля. Их вообще в разумной близости нет, объективно. Но Яндекс пишет «нет свободных машин», а Ситимобиль дал возможность заказать водителя с подачей 37 минут, чем я и воспользовался (хотя в целом лоялен Яндексу, Ваш сервис мне больше нравится).

    image

    Особенно остро стоит эта проблема, когда в области нужен минивэн. В Москве они есть, в области — почти никогда нет. Для большой семьи с детьми заказывать 2 машины — крайне неудобно, лучше подождать, переплатить, но все-таки получить минивэн. Яндекс многое улучшил в мире такси — но в этом месте ухудшил, заказывать минивэн на дачу в Серебряно-Прудский район Московской области стало труднее (раньше были мелкие местные игроки, у некоторых были минивэны; сейчас большая часть из них уже разорилась, не выдержав конкуренции, а у оставшихся минивэнов нет). Фактически сейчас приходится, когда из Москвы едешь на дачу на минивэне, спрашивать водителя, сможет ли он забрать в такой-то день? У меня уже много телефонов таких водителей собралось. Они забывают, уезжают в другой район, у них меняются планы, с ними надо торговаться о цене — все это хлопотно. Хочется иметь возможность сделать срочный заказ (пусть и со сверхдолгой подачей минивэна) и хочется иметь возможность сделать предварительный заказ — оба хоть по какой-то (пусть и более высокой) цене, но с высокой вероятностью приезда такси. Конечно, 100% недостижимо в реальном мире, но чтобы на это можно было положиться.

    3. Можно ли спросить Вас, vomar, пожалуйста — почему свернут эксперимент с совместными поездками по тарифу Яндекс.Комбо? Планируется ли восстановить этот тариф? В США в тех городах, где ввели совместные поездки по тарифам Uber Pool и Express Pool, на них приходится 25% оборота. В Lyft тоже есть тариф для совместных поездок (Shared Ride), есть и аналог Express Pool (Shared Saver).

    Скажем, из аэропорта Домодедово в Москву вполне уместно было бы ездить на Яндекс.Комбо (для тех, кто с небольшой сумкой из командировки возвращается), разве нет? А в минивэне можно и 2 пары с чемоданами посадить комфортно. Или так — впереди дачный сезон. От станции электрички заказывать такси до дачи — мало кто будет (ездящие электричкой небогаты). Но если от приехавшей электрички можно будет сесть в Яндекс.Комбо, которое довезет тебя прямо до дачи дешево (пусть и завезет заодно кого-то в соседний дачный поселок) — думаю, этим многие пользовались бы.

    И в конце хочу поблагодарить. Несмотря на описанные сложности, я пользуюсь Яндекс/Uber каждый день, и в целом Ваше приложение сделало жизнь моей семьи лучше. Спасибо Вам!

  11. nomadmoon
    /#20158318

    Если кто то в теме, подскажите, есть ли такси которые лояльно относятся к перехватчикам (или даже может API дают) и позволяют ездить только на свободном взятии заказов (т.е. чтобы меня вообще не назначали). Согласен ездить задешево, но только на моих условиях, по количеству заказов вообще пофигу, даже если один раз за ночь скатаюсь — уже отлично.

    Такси Максим, такси Мини — как там сейчас с этим?

    P.S. Хабаровск.