Геоданные и маршрутизация: кастомизация, пробочная модель и спасение клиентов от страхов
Во второй части интервью ведущий алгоритмист компании Veeroute Вячеслав Соколов рассказывает о кастомизации геоданных, разрешении спорных ситуаций при разработке маршрутов, об устройстве пробочной модели и спасении клиентов от их главной «боли».
Вячеслав, расскажите, какой вопрос от клиентов можно назвать самым чувствительным? И как вы этот вопрос закрываете?
Клиента, который начинает сотрудничество с нами, конечно, интересует следующее - «как будет проходить переход от этапа моделирования к использованию маршрутизатора в реальном мире?». Поскольку это важная часть его бизнеса, его беспокоят риски с связанные с внедрением технологии. Мы объясняем, как мы управляем этими рисками и что делается для того, чтобы свести к нулю все возникающие проблемы, а также как мы обеспечиваем гарантию решения для любой возможной ситуации. В том числе рассказываем о том, как мы будем устранять проблему, которая может возникнуть.
С «болевым» вопросом понятно, а в чём заключается главный страх клиента?
Вполне понятное опасение клиента заключается в следующем. Представим картину: в компании есть штат логистов (и других сотрудников), которые выполняют определённый функционал. Система работоспособна – происходят доставки, товар отгружается и так далее. Есть огрехи, руководство их видит, но в целом все «как-то» справляются. А вот будет ли система работоспособной, когда компания начнёт пользоваться оптимизацией, совершенно непонятно. Легко представить ситуацию: руководитель готов поверить, что мы (в процессе внедрения) дошли до состояния, когда курьеры получили свои маршрутные листы и пошли их выполнять, но он не сразу готов поверить, что всё пройдёт гладко на этом этапе.
Вся наша работа нацелена на то, чтобы инженерно-техническими средствами обеспечить надёжность маршрутизации и выстроить доверие к нашей технологии. Мы на практике демонстрируем, что алгоритм способен повысить эффективность бизнеса.
Это мышление ответственного лица, который представляет себе опоздания курьеров уже на первой точке, а затем и на последующих, а в городе пробки… В общем речь о точности выполнения маршрута и, соответственно, построенных прогнозов. И чем больше заказов в день, тем больше подобные опасения. Вся наша работа нацелена на то, чтобы инженерно-техническими средствами обеспечить надёжность маршрутизации и выстроить доверие к нашей технологии. Мы на практике демонстрируем, что алгоритм способен повысить эффективность бизнеса. Например, предлагаем логистам планировать в день не 20 заказов в маршруте (как это в среднем бывает), а 30 заказов. Это как раз и вызывает недоверие на первых этапах сотрудничества – из серии «не может быть такого, чтобы мы раньше были настолько неэффективными». Получается, что непривычно высокий уровень эффективности нашей разработки становится причиной недоверия. Однако, реальная практика всё расставляет по местам. Наша маршрутизация имеет высочайший уровень точности и всем известные клиенты пользуются разработкой Veeroute ежедневно.
Хотелось бы понять, что такое кастомизация геоданных?
Кастомизация геоданных – это возможность более точечно управлять процессами. Например, у нас есть транспорт определённого типа – машина с известными габаритами и грузоподъёмностью. Используя точки кастомизации, мы предоставляем конечному пользователю маршрутизацию именно по тем типам транспорта, который точно будет использоваться. Если заказчику нужен роутинг машин определённого типа, то мы можем добавить в наш API эти типы транспорта. Иными словами – мы говорим о расширяемости функционала, который мы можем предоставить. Если говорить о сторонних провайдерах, которые являются поставщиками геоданных (см. первую часть интервью), то не все участники рынка предоставляют такую опцию. Чтобы понять значимость функционала можно, например, посмотреть наш кейс внедрения маршрутизации для компании Globaltruck.
Наверняка в процессе работы с маршрутами возникают спорные ситуации, расскажите о таких?
Бывает такое, что клиент приходит с вопросом «а почему ваша система предлагает именно эту дорогу, а не другую». Мы смотрим на карту и видим, что ограничений для движения по данному участку нет. Здесь требованиям заказчика соответствует и направление движения, и тип покрытия, и возможность для движения транспорта с нужной грузоподъёмностью, и так далее. Однако, если посмотреть на панорамное фото нужной локации, то с двух концов отрезка видно установленные шлагбаумы, которые водители объезжают, чтобы проехать по этому участку. Провайдеры геоданных могут по-разному оценить данный отрезок дороги – как нежелательный для проезда или как вовсе непригодный для движения. Возникает сложный нюанс, связанный с актуальностью геоданных (бывает так, что дорога уже разбита и фактическая скорость движения по ней значительно ниже нормативного ограничения). В каждом таком случае мы анализируем ситуацию и принимаем наиболее эффективное решение. Например, в пользу сохранности автотранспорта. Подобные ситуации иллюстрируют сложность самой задачи выбора маршрута в неочевидных условиях.
Расскажите подробнее о том, как найти решение при таких неочевидных условиях?
Существуют зафиксированные правила в каждой системе цифровой навигации. Они определяют, в каких случаях разрешаются те или иные манёвры, какие есть запреты и так далее. Специалисты уже поработали над политиками поведения, а не только над самой оцифровкой дорог. То есть логику поведения водителей внимательно анализировали и предложили регулирование. Сюда включаются и локальные нормы ПДД (в некоторых странах есть специфические запреты), и предпочтения. Например, грузовик «очень не хочет» поворачивать налево. Таким образом, существуют способы исключения определённых ситуаций из практики. При прочих равных условиях будут использоваться те маршруты, которые в меньшей степени нарушают обозначенные ограничения. Политика нашей компании предполагает принцип следования разработанным системам и стандартным правилам. К расширению системы мы прибегаем только при возникновении существенной проблемы. В примере про шлагбаум мы не встретили серьёзных причин для отказа от маршрута.
То есть существует процедура выхода из сложных ситуаций?
В любом случае мы будем рассматривать такую ситуацию вместе с клиентом. Это будет анализ его обратной связи, учёт его экспертной оценки, плюс наша экспертная оценка. Обязательно мы будем обсуждать варианты выхода. Многие ситуации разрешаются проще, чем могло показаться на первый взгляд, потому что у нас уже предусмотрен функционал под определённый тип задач. Например, клиенту нужно поменять тип транспорта, чтобы он лучше соответствовал его целям. А бывает, что проблема связана только с актуальностью геоданных – они исправляются через небольшой отрезок времени. Случались такие моменты, когда в реальном мире был мост. В системе он отражается как действующий, но в действительности он уже закрыт.
«Пробки – это не всегда замедление, потенциально – это ускорение. Так что мы находим точку кастомизации, которая позволяет исправить проблему достаточно быстро».
Бывали обратные ситуации – новый, крайне нужный, мост уже открыт, но в геоданных это ещё не отражается. Значительный процент таких проблем «закрывается» с помощью нашей «пробочной модели»: если мы видим, что между двумя точками на карте фактическое время проезда стало существенно меньше, чем расчётный показатель, то мы это учтём. Здесь нам даже не обязательно сразу знать, как водители на месте выполняют проезд. Их поведение отразится в системе и, соответственно, на дальнейшем планировании. Пробки – это не всегда замедление, потенциально – это ускорение. Так что мы находим точку кастомизации, которая позволяет исправить проблему достаточно быстро.
Как выстраивается диалог с клиентами по теме пробок и как устроена пробочная модель?
Пробочная модель – это специально разработанный алгоритм. Что означает с нашей точки зрения отсутствие пробок? Мы берём две точки на карте, смотрим сколько времени займет маршрут между этими точками и предполагаем, что время в пути между ними не зависит от времени (суток), когда мы начинаем движение.
«Пробочная модель содержит в себе информацию о том, как именно время в пути меняется в зависимости от времени старта».
То есть время в пути не зависит от того, когда мы выезжаем. Это уже допущение, поскольку в реальном мире есть разводы мостов и другие ограничения. Что такое роутинг с пробками? Здесь мы предполагаем, что временные затраты в пути существенно зависят от времени старта. Утром – одно время, днём и вечером – другие показатели. Так, время в пути может увеличиваться в несколько раз. Соответственно пробочная модель содержит в себе информацию о том, как именно время в пути меняется в зависимости от времени старта. На нашу пробочную модель накладываются существенные ограничения – она должна быстро передаваться по сети и должна быстро применяться. Потому что любые задержки с получением информации о проезде между точками существенно сказываются на планировании. В процессе планирования нам нужно обработать сотни миллиардов запросов в формате «сколько времени займёт проехать от одной точки до другой в конкретный момент времени». Любая задержка с выполнением такого запроса будет существенно сказываться на времени, затрачиваемом на подготовку маршрутов. Просто из-за того, что самих запросов очень много. Эти расчеты мы должны сделать быстро и на должном уровне точности.
Как разрабатывается эта модель?
Для формирования пробочной модели мы должны иметь точные данные по фактическому времени проезда между точками. Откуда нам такую информацию получить? Вариантов на самом деле не так много. Первый – от стороннего геопровайдера. Тут мы должны выбрать авторитетного и надёжного поставщика. Что мы в компании и делаем. Существует второй вариант – покупать, или использовать данные клиентов, более низкоуровневую информацию о фактических временах проезда. То есть получать не подготовленные данные, а «сырые», с которыми пришлось бы что-то делать. И третий вариант – мы могли бы сами эту «сырую» информацию собирать. Например, с мобильных устройств курьеров нужные нам треки. А затем уже их обрабатывать.
Почему выбран первый вариант? Так дешевле?
Нет. Причина в другом. В рамках этого варианта максимально проработаны вопросы точности прогноза, то есть причина напрямую связана с точностью нашей модели. А чтобы её оценить, нам нужен какой-то референс. И в этом качестве выступают как раз данные провайдера. Свою модель мы построили, обучили и натренировали, а дальше мы должны проверить точность её соответствия референсу. Для этого делается ещё ряд запросов, сравнивающих наш прогноз и значение референса. Например, мы спрашиваем у стороннего геопровайдера «если я выйду из точки А в точку Б в определённый момент времени, то каким будет моё время в пути». Геопровайдер даёт ответ, мы сравниваем его с нашим значением – так выглядит шаг процедуры сравнения. Получив много таких ответов, мы можем сделать выводы с помощью математической статистики. Эти инструменты позволяют нам уточнить модель, выявить и устранить недостатки. В случае с получением «сырых» данных у нас не было бы нужного референса, так как сами GPS-данные не очень точные, а также мы не могли бы быть уверены в точности маршрута, который по факту проехал курьер.
Также для уточнения пробочной модели используется обратная связь от наших клиентов. Мы её постоянно получаем, анализируем и сегодня видим, что ситуации, свидетельствующие о потенциальной статистической ошибке, не возникают. Бывают проблемы с отдельными переездами, но они неизбежны. Несоответствия нашего роутинга реальному миру мы не фиксируем. Мы периодически уточняем модель, если видим, что в отдельным местах она недостаточно точна. Этот процесс уже не требует вмешательства разработчика, поэтому этим занимается специально обученная команда техподдержки.
От чего может зависеть изменение прогноза ситуации с пробками?
Если говорить о прогнозе, формируемом провайдерами, то изменения связаны с появлением новых данных. В целом процедура устроена так: мы должны учесть исторические данные, все последние изменения в статистике и тогда уже предлагать свой анализ. Хороший прогноз должен включать информацию о реальных дорожных работах. Например, плановые ремонты или временные перекрытия переездов. Бывают различные мероприятия, такие как парад 9 мая. О них тоже необходимо знать. Есть и такие факторы, как смена расписания общественного транспорта. И здесь всё зависит от того, насколько хорошо провайдер геоданных проинформирован.
Приоткройте завесу компьютерного кода – как устроены сами карты?
Нужно сказать, откуда берётся так называемая «подложка» карты, то есть сама основа. Мы берем открытые данные (в формате OSM), с которыми мы проводим технические процедуры для их дальнейшей визуализации в браузере. Визуальный интерфейс видит наш заказчик. Само устройство карт связно с понятием уровня зума, то есть степени приближения, которую выбирает пользователь при просмотре карты.
«В нашем инструменте для просмотров карты – в студии – можно переключатся в различные режимы просмотра. Так, логисты в России используют удобную им русскоязычную версию, а для того, чтобы коммуницировать с коллегами из Китая мы выбираем англоязычную версию».
От уровня зума будет зависеть использование различных «тайлов» – той информации, которая для выбранного режима просмотра наиболее актуальна. Мы дополнительно насыщаем эти уровни («тайлы») необходимой информацией. Например, локальными названиями, англоязычными названиями и оригинальными названиями местности. В нашем инструменте для просмотров карты – в студии – можно переключатся в различные режимы просмотра. Так, логисты в России используют удобную им русскоязычную версию, а для того, чтобы коммуницировать с коллегами из Китая мы выбираем англоязычную версию. Актуальность карты в точности соответствует полученной порции свежих «тайлов», которые мы преобразовали в доступный для визуального анализа формат. Таким образом, от обновления геоданных зависит и актуальность наших карт. Мы избавились от задержки с публикацией обновлённых карт. Сделано это за счёт автоматизации процесса. Для этого мы провели необходимые технические процедуры. Также наши «тайлы» могут отображаться в различных стилях – тёмная тема, светлая тема… Стилизация важна для решения итоговой задачи. Например, для пешехода необходим один стиль отображения карты (и тут много факторов – вплоть до отображения нужных дорог), а для велосипедиста нужно акцентировать внимание на другом – иная цветовая палитра, другие отображения. Для автомобилистов крайне важны знаки и так далее. Исходя из того, что нужно конечному потребителю, мы предоставляем различные стили отображения карт. При отрисовке маршрутов тоже есть различные стили – необходимые логисту данные мы предоставляем в максимально доступном виде.
Если вас заинтересовала тема автоматической оптимизации, то вы сможете больше узнать о возможностях платформы оптимизации и компаниях, которые успешно используют продукт.
