Какие алгоритмы, языки и математические области реализованы в приложениях доставок — для курьеров двух типов, а так же для заказчиков?

Question

[Greenberry01]

Какие алгоритмы, языки, математические области и идеи реализованы в приложениях доставок вцелом, и конкретнее в сервисах по подбору заказа для нужного курьера, именно в их рабочих приложениях, где в одном случае система автоматически предлагает нужный заказ основываяясь на геопозиции, а в остальных они сами выбирают из списка доступных? Мне как опытному курьеру всегда было интересно то как они разрабатывались, стек технолгий, сколько в команде было человек. Есть идеи как я лично бы их улучшил и узнать возможно ли вообще это. И даже попытаться перекатиться в кодеры за полгода-год. С какой литературы начать иучение? Для андроида, как я понял, база это Java/Kotlin, но интереснее начать именно со стороны задач прикладной математики, разработать бота для автоматического взятия самого дорогого и быстровыполнимого заказа, если есть возможность, то отреверсить курьерские приложухи, да и разработать какие-то форки на основе доступных в качестве своего пет-проекта. Например от Достависты, Яндекса, Озона и пр. Хочу полностью разобраться впервую очередь в приложениях для курьеров типа Яндекс/FlowWow, где система автоматически выбирает заказы и кому куда ехать. Опциально и с теми где курьер сам выбирает заказ для исполнения а далее углубится в приложения для заказчиков.

Comments

[shurshur]

Самый простой способ для курьерской доставки из типичного ПВЗ маркетплейса или стора магазина: вокруг каждого пункта построить зоны с разным временем доставки. Например, зона до 10 минут, до 20 минут, до 30 минут. Или даже с делением поминутно. В результате город накрыт зонами, и каждое место доставки достижимо за разумное время от какого-то пункта.

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

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

Всё это не должно быть статичным: надо собирать статистику и постоянно корректировать показатели. Например, в каком-то направлении время доставки систематически 3-4 минуты больше рассчётного? Почему? Это может быть, например, из-за светофора с длинным циклом по пути. Из-за пропускного режима. Из-за отсутствия в здании лифта. Итд итп. Необязательно прям вносить все эти светофоры и лифты в граф/карту, вместо этого можно учитывать статистические данные вместо прямого расчёта времени или вместе с ним для его корректировки.

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

Также собирать инфу о загруженности пунктов, о нехватке и простоях курьеров...

Потом можно начать оптимизации. Например, выявлять, где можно курьеру дать 2-3 заказа, чтобы он их исполнил за один рейс. Тут проще всего прямым перебором: есть, например, 10 заказов, пробуем объединять их в 2-3 в разных сочетаниях и проверять, каким будет общее время.

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

У некоторых курьерских систем также курьреры (все или только некоторые) могут быть не привязаны к пунктам. В этом случае надо на заказ находить курьера в более-менее доступной от пункта области. Фактически, есть пул пунктов и пул курьеров и надо для них искать оптимальную комбинацию заданий, обеспечивающую доставку в разумное время, достаточную загрузку курьеров, их низкий "перепробег" итд итп.

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

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

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

Что поизучать? По теории можно предложить посмотреть на здачу коммивояжера, алгоритмы поиска пути в графе (Дейкстры, A* итд).

Может быть интересно познакомиться с задачей линейного программирования.

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

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

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

Answer 1

[VoidVolker]

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

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

Answer 2

[Сергей Горностаев]

Напрямую никакие алгоритмы не реализуются, используются готовые решения. Например, для поиска ближайших заказов может использоваться PostGIS и ему подобные. Для построения наиболее выгодных маршрутов графовые базы или графовые расширения для реляционных СУБД. Для кросс-селлинга библиотеки машинного обучения, типа Apache Mahout. И т.д. и т.п. И естественно, что всё это работает на бэкенде, в мобильном приложении нет вообще ничего - это просто тонкий клиент, делающий rest-запросы при нажатии пользователя на кнопки. Бэкенд в большинстве случаев написан на Java или Go.

Answer 3

[#]

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

Вы уже знаете нужные слова! хотя и допускаете опечатки..

Мне как опытному курьеру всегда было интересно то как они разрабатывались, стек технолгий, сколько в команде было человек

чаще всего это коммерческая тайна

Есть идеи как я лично бы их улучшил и узнать возможно ли вообще это

в нашей жизни возможно все - хотите? реализуйте!

Для андроида, как я понял, база это Java/Kotlin

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

но интереснее начать именно со стороны задач прикладной математики

диплом уже получили?

отреверсить курьерские приложухи

упс... чтим УК!...

Хочу полностью разобраться впервую очередь в приложениях для курьеров типа Яндекс/FlowWow, где система автоматически выбирает заказы и кому куда ехать

отличный план! дерзайте!

Answer 4

[Василий Банников]

Про алгоритмы например недавно от Яндекса рассказ был:
https://habr.com/ru/companies/yandex/articles/887484/

Естественно это только малая часть.

Comments

[Elmo Sputterspark]

Эти как всегда "Скорее, надо изобрести велосипед, чтобы олимпиадники не скучали!"

[Василий Банников]

Elmo Sputterspark, ну справедливости ради постгис тут не очень оптимален будет

Answer 5

[alexalexes]

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

Есть идеи как я лично бы их улучшил и узнать возможно ли вообще это.

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

И даже попытаться перекатиться в кодеры за полгода-год.

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

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

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

Answer 6

[Роман Вершенко]

привет. я не программист, стек тильда+курсор, но тож логистическую платформу пилю, и похожую задачу решаю. допустим есть заказ из 100 позиций разного веса объема и совместимости перевозки (10 кирпича, 5 доски, 500 шифера и тд). эти позиции есть по разным ценам в зависимости от объема закупки позиции и вцелом на скаде на разных складах, есть разные виды транспорта ( в разных ТК по разным адресам по разным ценам с разной вместимостью и типом допустимого груза).

и вопрос: на каких складах какими транспортами из каких ТК и в каком порядке это перевозить. На данный момент на тестовых данных эта штука находит решения лучше человека на 2% (считал по всей россии на 5 млн скю и 100 тыс транспортов). Крч человек на 2% дороже выбирает комбинацию товары склады транспорт и маршруты. Причем я вобще в этом до сих пор не шарю хаха.

области которые изучал чтоб примерно понять: комбинаторная оптимизация с ограничениями (задача рюкзака + коммивояжора). Всякие линейные/целочисленные программирования, эвристики типа генетических алгоритмов, отжигов, нейросетки кастомные, кэтбусты от яндекса и тд показывают плохие результаты.

Лучший результат дает библиотека гугла ОР-тулс. Думаю, это как раз подходит для твоей задачи. Простыми расширениями типа постгис и поиск ближайшего не обойтись, как сказал комментатор выше. Но библиотека просто ускоряет вычисления, самое интересное тут - самому формулу придумать. что как и зачем считаем. ГПТ реализует, но придумывать какие данные считать и зачем - самый кайф. Хотя возможно все уже давно придумали за нас, повторюсь, любитель в этом.

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

по стеку на пайтоне все. обычная комбинаторная оптимизация. для математики язык жулию юзаю, вроде побыстрее считает. ну эт чисто свой опыт, как должно быть - хз (пс: хз даже что такое реверс инжиниринг)

Comments

[Everything_is_bad]

блеск и нищета вайбкодеров, что-то сделать могут, но масштабировать уже не способны.