Pull to refresh

Comments 22

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

Хорошая статья, решал задачу коммивояжера и расписания для издательства по доставке еженедельного тиража курьерами по городу, но без МЛ, на paradox 4.5 ещё. Минимаксовый алгоритм справлялся с тиражом минут за 40 под МС ДОС. Но там было попроще: тираж в известный день, курьеры свои, грузоподъёмность известна. Периодически менялся только объем тиража и точки доставки по зонам.

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

ML для красного словца прикрутили ? Тема не раскрыта ...

Срочная доставка конверта с документами из Новосибирска на Камчатку.

СДЭК до использования ML: отвозит в аэропорт Новосибирска, откуда прямой рейс на Камчатку, срок доставки - 2-5 дней.

СДЭК под управлением ML: везет из Новосибирска в Красноярск, откуда нет прямого рейса и теперь не знает что делать дальше. Видимо, вручил конверт курьеру, а кожаный мешок отказывается на своей легковушке ехать с Красноярска на Камчатку. Отправлено 15.01, сегодня 26.01 и документы где-то на складе в Красноярске с неизвестной дальнейшей судьбой.

документы где-то на складе в Красноярске

Вот видите как здорово! А ведь могли бы и в Краснодаре всплыть (у нас так DPD без ML разок вместо Краснодара в Красноярск посылку зафигачил :)) ).

О, и у меня DPD Краснодар и Красноярск перепутал.

Самое смешное в нашем случае - что отправка была из Ростова-на-Дону в Краснодар (ну реально доплюнуть можно) но эти, эээ, альтернативно одарённые товарищи решили срезать угол через Красноярск.

Интересная статья, спасибо за раскрытую тему :)

Когда маршрут сразу в приложении у курьера, а не где‑то на стороне — это действительно очень важно.

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

А не сталкивались с прямой ситуацией, когда маршрут в приложении есть, и все водители им пользуются?

Яндекс-такси, сталкивался много раз:

-"А зачем меня в круговую повез?"

-"Э-э-э, слишь дарагой, я этот город ни знаю. Как мне маршрут пралажил так и еду"

;)

Я ничего не понял из вашего рассказа. Вас обманывает яндекс-такси?

Почему сразу "обманывает"? Есть заказ, он оценен, меня устроило, заказ подтвержден, таксист найден, приехал. Где тут "обман"?

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

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

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

Честно говоря, я сталкивалась только с обратной ситуацией: если таксист решил, что он дорогу лучше знает, то все, я опоздаю минут на 20-30(

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

Чтобы курьеры пользовались маршрутизацией в приложении, а не игнорировали ее - это отдельная задача, конечно) Мы идем по пути показывать, что вот ты не пользовался маршрутизацией и у теяб такие показатели, а если бы пользовался - то были бы вот такие. Чтобы курьер сам прочувствовал разницу и понял, что ему проще и выгоднее пользоваться нашими маршрутами.

Есть предложение для СДЭК

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

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

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

Судя по задаче, генетика должна подойти, но ни строчки кода…

Не понял. Вы говорите что у вас есть курьерские маршруты (макрозоны для доставки) и тут же пишете что каждый раз неизвестно заранее сколько курьеров будет на маршруте. Это как?

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

Как бывший супервайзер логистической компании скажу, что все здорово работает пока у тебя 80-90% это юрики (заводы, магазины, офисы). Но как только появляются физики, да еще каждый со своим «закидоном», то резко все системы рушатся.

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

Про форс-мажор с потерей времени у клиента я молчу. Все эти: подождите я померяю, прочитаю и подпишу, сейчас соберу обратную посылку и сразу отдам, я без мужа/жены не могу принять решение и т.д. Которые увеличивают время одной доставки с Х до 2Х и даже 3Х. А как итог у курьер не успевает дальше по маршруту и ему приходится уже без вашей системы перестраивать себе маршрут и контактировать с клиентами.

Здравствуйте!
1. Макрозоны статичны в обычный день, но если большая нагрузка или, наоборот, меньше обычного (выходные), то их склаивают или делят. У нас в основном доставка до физиков, и вы верно перчисляете проблемы с этим связанные) Из-за этого в нашей системе много дополнительных процессов - прозвоны, согласования времени доставки и много чего еще. Это все усложняет задачу маршрутизации, на все такое приходится смотреть. Именно поэтому перед собственно построением маршрутов у нас большой модуль, который слушает все события - перенос времнеи-места, заявки и прочее, и принимает решение когда и с какими данными надо строить маршрут.
2. "...  ему приходится уже без вашей системы перестраивать себе маршрут и контактировать с клиентами"
Так в том-то и дело, что мы не можем построить кму маршурт в начале дня и все! Нам приходится его перестаивать из-за форсмажоров, из-за переноса времени клиентом, из-за непредсказаннйо пробки.


закончились айтишники ? никто не идет... нужно пиариться?

а примените еще такой же ML в HR, что бы хамов в ПВЗ, очередей и грязи не было
еще примените ML для отслеживания отзывов

Sign up to leave a comment.