Comments 21
Вначале четыре из пяти пассажиров платили меньше 3 долларов, а теперь все платят по 3 и довольны? Любопытно… но ведь мы помним, что за цену в полтора раза больше можно проехать на такси. Т.е. три из четверых оставшихся просто выберут такси за стоимость меньше 3 долларов и не будут терять деньги и время…
Хороший комментарий, спасибо!
Смотрите, в начале мы предполагали, что будем собирать клиентов равномерно вдоль всего маршрута. Из этого предположения и был построен мой гипотетический пример с 5-ю работниками и поэтому мы собирались возить клиентов тем дешевле, чем короче их поездка. Исследуя задачу, мы пришли к выводу, что посадка каждого следующего по мере роста числа пассажиров становится все более дорогим удовольствием и брать задешево мы не можем. Этот вывод не просто говорит нам, как назначать цены, но и указывает, как именно будет использоваться сервис. Поскольку цену за поездки можно считать почти фиксированной, основная часть клиентов будет садится именно на дальних остановках, а те, кто живет совсем близко - поедут либо на обычном общественном транспорте (красивом трамвае, благо недалеко), либо возьмут такси.
Так что да, все по 3 доллара и большинство с самых дальних остановок.
Ну для дальних - логично, но их будет 2 из 5 и это всего 6 долл., а остальные - как повезёт. В среднем на 12 долл. и тем более на 15 не выйдет никак.
Кстати, есть пример автобусов Москва-Подмосковье, у них у всех висят таблички расценок от остановки до остановки, условно от 30 руб и до 120. Полагаете, им надо сделать единую цену 80 руб?
Кстати, а пенсионеры как учитываются?
Ну и вдогонку - мой практический опыт: я работал недалеко (2 перегона метро), и регулярно ездил бесплатно как многодетный, общий путь от порога до порога занимал 30-40 минут. Также был альтернативный маршрут автобуса буквально от порога до порога, раз в 20 минут примерно. Если я выходил и он как раз подъезжает, садился в него.
Но когда я спешил, то брал такси по цене 180-200 руб. и доезжал за 10 минут. То-есть при выборе я оперировал не только стоимостью, но и скоростью.
В реальности по маршруту едут сразу много автобусов к одному и тому же времени высадки у бизнесцентра, поэтому просто автобусов будет меньше и все они будут заполнятся преимущественно с дальних остановок.
Потом в статье конкретные выводы относятся к реалиям Алма-Аты, а вот разработанные методы - наоборот универсальны. Для Москвы они могут дать другие результаты: нужно смотреть на цену фрахта автобуса, цену такси, стоимость минуты времени клиента, время посадки, распределение по остановкам (сколько в среднем садится с одной). Тем не менее способ вывода оптимального числа пассажиров остаются прежними или могут быть легко обобщены из тех, что я использовал в статье.
Да, и самое главное, никто не утверждает, что даже при оптимальных ценах и параметрах совместные поездки должны быть рентабельными.
Столько расчётов, а в итоге пришли к единой цене на билет как в ОТ.
Хватит называть стартапы казахскими, как бы им этого не хотелось. Будьте честны хотя бы перед собой. Иначе скоро начнёте говорить хлопок, отрицательный рост
Идея лежит на поверхности: я ранее предлагал работодателю пустить автобусы по городу для сбора персонала со всего города, договориться об использовании выделенных полос. При этом есть корпоративные шаттлы между разными офисами в городе.
Идею, естественно, не поддержали.
Однозначно плюсую, но мне кажется вы как-то слишком сильно переборщили с формулами, экономикой и в какой-то мере с изобретательством велосипедов. Сейчас все гонятся за оптимальным ценообразованием (точно так же как и за UGC), но ввиду скудной информации по данной теме, каждый "привносит" что-то "новенькое" в эту в общем-то недосформировавшуюся (ввиду крайней междисциплинарности) науку. С чем вы очень точно угадали, так это с задачей: планирование продаж, это не динамическое ценообразование. За это отдельный респект.
Чего хотелось бы посоветовать:
1) фундамент всего - это модель дискретного выбора. В какой-то мере она очень похожа на все то, что вы проделали, однако, она намного ближе к данным и их анализу.
2) модель клиента - маркетинг и все такое, но с большей ориентацией на данные.
3) фиксированная цена - зло. Если в системе что-то меняется а цена нет - это потеря эффективности. А эффективность - наше все.
4) Байесовский вывод - вывод продукта на рынок это тоже оптимизация, нужно много хороших гипотез (с которыми у вас все впорядке, но проконсультироваться с LLM-кой все равно не помешало бы). А что лучше всего работает с гипотезами?
5) робастная оптимизация - это то что вытекает из пункта №4.
6) стохастическое программирование - вытекает из пункта №1, потому что по факту там не объемы продаж/покупок, а вероятности. Ну а там где вероятности - там вообще все не так.
Дальше... дальше у вас появятся данные.
Чего еще добавить? Uber начал использовать в модели дискретного выбора графовые нейросети (как они работают вообще хз, но точно знаю что логиты не работают с историей покупок клиента, а нейросети работают).
Есть оч хорошая книга "Алгоритмы принятия решений" Микель Кохенденфер - она в общем-то неявно, но исчерпывающе отвечает на вопросы как барыжить чем угодно продажи связаны со стратегиями. Ну и она все-таки ближе к OR чем к экономике. Я не сколько не против экономики и всяких преобразований Брауэра, но как по мне лучше сразу рисовать четырехэтажные форму в виде целевых функций, чем сначала делать это в экономическом ключе, а потом в виде техже самых (а может и нет) целевых функций.
Ну и кстати да, что там с MVRP? На самом деле было бы очень интересно узнать. OZON тут организовали чемпионат по AI, причем один из треков - это как раз маршрутизация курьеров (VRP с разными ограничениями). Сегодня по моему последний день регистрации. Я вот зарегался, думал (в 100500 раз), что получится как-нибудь быстро освоить or-tools, но как обычно придется разбираться по ходу дела.
Спасибо за комментарий, советы и рекомендацию книг.
По теме MVRP история такая. Один из фаундеров Муаммар аль Шедиват задумался над такой проблемой: с одной стороны есть хорошие промышленные решатели задачи маршрутизации, но они предполагают, что у каждого клиента в точности одна точка посадки и ровно одна точка высадки, с другой - в реальности у клиента обычно есть несколько почти равнозначных по удобству точек посадки и высадки и мы могли бы выбирать те точки, которые нам удобны, но это уже не вписывается в стандартную MVRP. Муаммар задался вопросом, а нельзя ли с помощью каких-нибудь математических ухищрений свести вторую задачу к первой (задача Муаммара)? Я нашел очень простое, красивое и вычислительно эффективное решение этой задачи. Сейчас мы обсуждаем условия передачи и стоит ли его публиковать.
Если здесь есть ребята из Озона, обратитесь ко мне, авось я вам смогу чем-то помочь. Без ИИ :)
Мне показалось, что or-tools довольно гибок в плане всяких ограничений и требованиям к решениями, в сети довольно много вариаций VRP, кторые с помощью него решаются. Но видимо он не настолько гибок.
Интересно то, что решение задач комбинаторной оптимизации относят к сфере ИИ (в том числе и VRP). Моя первая книга по ИИ "Программирование ИИ в приложениях" Тим Джонс. В этой книге первая глава посвящена задаче о расстановке ферзей, которая решалась с помощью отжига. Это была моя первая эвристика сделанная на python + numpy и matplotlib для визуализации. Прошло около 10 лет и выяснилось, что в or-tools расставить ферзей можно несколькими строчками кода и считается все гораздо быстрее.
Вы уверены, что вашу задачу нельзя решить с помощью or-tools?
Не уверен) Я позиционирую себя как специалист в абстрактной математике, не в конкретных решателях и библиотеках. Может быть что-то стандартное уже есть, но и у меня свое решение тоже есть. Я был бы вам благодарен, если бы вы смогли как эксперт в or-tools прояснить, решает она задачу Муаммара или нет.
Оу, в or-tools я только-только начинаю вникать и надо сказать, что из-за весьма скудной документации это не так-то просто, особенно в плане VRP. Что могу сказать точно.
1) В принципе, насколько я понял, or-tools может решать любую задачу для которой есть устоявшаяся аббревиатура: TSP, VRP, CVRP, TWVRP, MDVRP и т.д. и т.п. причем все эти задачи можно комбинировать.
2) or-tools поддерживает два вида ограничений: ограничения на "измерение" (dimension) - любая величина (расстояние, время, вес груза, кол-во пассажиров и тд), которая изменяется по мере продвижения по маршруту и ограничение на сами маршруты.
3) Ограничения на маршруты могут быть довольно гибкими, например, можно задать какие транспорты в какие точки могут заезжать, а в какие нет. Точно так же там можно задавать обязательные точки маршрутов. Вполне возможно, что там так же есть возможность задавать предпочтительные точки маршрутов (ваш случай).
Тут надо обязательно добавить, что or-tools это все таки инженерная сфера, а не научная. Как бы по дефолту предполагается, что пользователь должен шарить в OR, но так же предполагается, что пользователь должен шарить и в солверах. А солверы тоже работают с очень абстрактными материями. Это приводит к тому, что математик не может сходу догадаться до каких-то инженерных трюков и наоборот.
Я очень долго работал кем-то вроде переводчика между бизнесом и наукой: что бы все друг друга понимали и хотя бы не несли прям какой-то лютой дичи и брехни. Но совсем недавно к коммуникациям подключилась еще одна сторона - инженеры. И вот тут я поплыл как пломбир под жарким солнцем.
Дело в том, что у решения может быть несколько реализаций, а значит необходимо взвешивать плюсы и минусы каждой из них. Например, у вас есть красивое и элегантное решение с точки зрения математики, но:
1) Будет ли оно масштабироваться до размеров города? Например, для любого солвера VRP с 1000 точек может оказаться серьезной проблемой. Значит надо как-то делить город на микрополигоны. А это еще одна оптимизационная задача причем тоже далеко не тривиальная.
2) Будет ли ваше решение сбалансированным, т.е. не будет ли такого, что одни перевозчики будут пахать с рассвета до заката, а другие будут работать не так интенсивно. В or-tools, например, сбалансированностью маршрутов можно управлять.
3) Если ваше решение, это прям супер-пупер-пыщ-пыщ-вау-вау. То возникает другая проблема: как его встроить в реальный процесс: базы данных, реальные карты городов, финансовые транзакции и пошло поехало.
4) Следующая проблема, заключается не в том что реализовывать, а кто это будет реализовывать. Допустим человек, который поймет ваше решение и сможет его встроить в процесс найдется. Но не получится ли потом так, что этот человек станет обладателем сакрального знания о том как все работает? Такая ситуация - это риск, потому что если такой человек вдруг уйдет, то заменить его будет непросто. Значит нужна документация. А документация в R&D - это, как правило, минимум увесистая монография на пару сотен страниц далеко не самого легкого чтива.
5) Что насчет железа? Понятно что его придется жечь, но сколько жечь. Наверное ваш алгоритм придется как-то параллелить. Это легко? В or-tools это легко, причем там параллелизм реализован весьма умным, в плане алгоритмизации, способом (разные потоки по разному улучшают решение). Самостоятельное распараллеливание и заточка под железо только усиливают пункт №4.
6) Из пункта №5 вытекает другой вопрос, что дешевле: 1 час работы 2-х, 3-х или 10-ти 32-хядерных процессоров или вся эта (уж простите за слово) возня с красивым и элегантным решением. Хорошо (и не так обидно), когда тебе говорят: "Да не парься, я просто второй сервер куплю", то того как ты потратил кучу сил на поиск такого решения. Сделать все сразу зашибись, это конечно путь самурая, но такая стратегия может обойтись в разы дороже, как по деньгам, так и по времени. Например, одна известная стриминговая компания однажды (очень давно) организовала ML-чемпионат по рекомендательным системам, но решение-победитель не пошло в прод, просто потому что его оказалось крайне сложно реализовать.
7) Ну и последний пункт: может вообще дешевле отдать эту, в значительной степени инженерную задачу на аутсорс или фриланс? Наверняка, ведь уже есть люди, которые на этом собаку съели и не прочь получить 5-100к за хороший MVP? Для этого конечно надо сделать адекватный ТЗ, что тоже, само по себе, проблема. Но и ее можно решить с помощью платных консультаций.
Прошу не поймите меня неправильно, я вовсе не пытаюсь цинично язвить и все такое. Мне нравится ваша идея (иначе не стал бы строчить такие длинющие комменты). Я вообще всеми конечностями за персонализацию и повышение качества клиентского опыта в любых сферах (это неизбежное течение, под которое надо как можно скорее подстраиваться, а не сопротивляться). А сложные модели этому только способствуют (сам заморачиваюсь с экономикой благополучия). Но все упирается в реализацию и жизнеспособность решения, а это зависит от огромного числа активностей, которые так или иначе вращаются вокруг коммуникаций между разными сферами в каждой из которых огромное количество заморочек.
С развитием LLM происходит беспрецедентное смешивание ролей (профессий). В наше время становится невозможным быть в бизнесе чистым математиком. Так или иначе "белое пальто" придется "запачкать". Но надо отметить, что благодаря тем же LLM это "замарывание" превращается в приятные и целебные грязевые ванны.
Ценообразование совместных поездок: справедливость, капитализм и теорема Брауэра в промышленных исследованиях