Я веду подкаст "Бизнес мысли" (пока только на польском языке), на котором уже более 200 000 прослушиваний.
На русском языке мы будем публиковать статьи на основании подкастов.
Я практик. На подкастах я делюсь самым полезным и интересным из мира машинного обучения. Часто приглашаю гостей - они тоже практики и связаны с машинным обучением :)
Сегодня у нас эпизод про искусственный интеллект в iTaxi.
В этом эпизоде вы узнаете:
- Как оптимизация помогла iTaxi?
- Как повысить привлекательность и улучшить работу компании с помощью машинного обучения и искусственного интеллекта?
- Как эффективно оптимизировать алгоритмы?
- Может ли эффективная автоматизация улучшить рабочий процесс?
- Каковы проблемы и трудности в правильной оптимизации алгоритмов?
- Как можно использовать подход моделирования для решения проблем?
- Что должно быть приоритетом при выборе процессов, чтобы они как можно точнее отражали реальность?
- Как эффективно использовать A/B тестирование?
- Как убедиться, что симулятор работает правильно, и как выбрать его параметры соответствующим образом?
- Эффективно ли с экономической точки зрения использование симулятора в других отраслях, кроме такси?
- Чего следует остерегаться и каких затрат ожидать при внедрении машинного обучения и искусственного интеллекта в свой бизнес?
- Как будет выглядеть технический прогресс в ближайшие 15 лет?
Первый тип - это те, кто просто бунтует и говорит: нет, но за этим ничего не стоит, они просто не согласны. Такой подросток.
И второй тип, который привлекает мое внимание, - это человек, который говорит, что что-то можно сделать по-другому, и за этим стоят такие твердые аргументы. И это очень интересно, когда кажется, что все всегда делалось именно так, а кто-то приходит и говорит: а давайте сделаем это по-другому. И объясняет, почему это так.
Вторая вещь - более аналитическая, хотя тоже научно-популярная. Есть запись под названием "Футбольная математика", написанная Самптером, английским математиком. И это попытка аналитического подхода к футболу. Очень бодрит, очень интересно. Подход, который показывает, как, например, можно разными способами попытаться предсказать, кто выиграет Лигу чемпионов в следующем сезоне, а также как можно объяснить на уровне математической теории, почему для того стиля, который представляет, например, "Барселона", где много быстрых, коротких передач, почему именно та формация, которую они выставляют на поле, имеет смысл.
Третье, что я сейчас читаю, это "Век крови" Влошанского, тоже научно-популярная книга, но в области истории, очерки о 20 веке и о переломных моментах. Также очень, очень разные жанры. На самом деле я читаю много разных жанров. Я избегаю, может быть, только некоторых романтических романов и тому подобных вещей, а кроме этого, я не думаю, что для меня есть какие-то запретные жанры, и, вероятно, меньше, чем большинство профессионалов в этой нашей отрасли, я читаю менее строго технические вещи.
И мне вдруг пришло в голову, что, не тратя время на эти занятия, которые воруют у нас то пять минут, то семь, он вдруг смог прочитать гораздо больше, чем раньше. Возможно, я не столь последователен в этом, но это произвело на меня сильное впечатление. Это своего рода вдохновение.
И это такая разница на юридико-техническом уровне, в то время как она имеет очень сильный перевод в бизнес. Потому что мы, например, не можем ввести такие механизмы, как Uber, то есть гибко менять цены даже от минуты к минуте, потому что стоимость проезда должна быть напечатана на окне. Наша философия совершенно иная. Uber - это компания, которая фокусируется на полной масштабируемости, то есть их бизнес, по сути, может работать в любой точке мира, что они в основном и делают, в то время как мы фокусируемся на более, я бы сказал, отшлифованном, локальном бизнесе, то есть мы фокусируемся на Польше.
Прежде всего, в крупнейших городах, и там мы можем скорректировать нашу политику таким образом, чтобы получить конкурентное преимущество. Второе отличие, очень большое, заключается в том, что мы в первую очередь ориентированы на услуги business to business (B2B), то есть мы заключаем контракты с компаниями на перевозку их сотрудников. Здесь мы разработали ряд механизмов, которые облегчают жизнь компании, например, единый счет за все поездки, совершенные за месяц, возможность установить определенные лимиты для сотрудников, отнести расходы на конкретный проект, проверить, какие поездки совершил тот или иной сотрудник.
Множество подобных механизмов для того, чтобы компании было удобнее использовать то, что очень необходимо и нужно для бизнеса, но не является их основной деятельностью. Если же вы запускаете приложение Uber и наше приложение, то со стороны пользователя принцип работы схож. Вы находитесь в определенном месте, заказываете такси, такси приезжает к вам, вы можете отслеживать маршрут в этом приложении, вы знаете, когда такси приедет к вам, вы знаете более или менее точно, когда вы прибудете в пункт назначения, у вас есть история поездок. И так далее.
Таким образом, разница невелика, в то время как вы должны помнить, что Uber, в силу того, что этот бизнес ориентирован на быстрое масштабирование, не может заботиться о качестве предоставляемых услуг так же сильно, как мы. Он не в состоянии так точно проверить все драйверы. Им не нужно иметь лицензию, им не нужно знать город. В крайних случаях они могут даже не знать языка страны, в которой они предоставляют услуги, в то время как у нас это люди, имеющие лицензию на такси, и это такая большая разница.
Мы также уделяем большое внимание экологии и стараемся, чтобы в нашем автопарке было как можно больше электрических или гибридных автомобилей, что означает, что мы заботимся о качестве и лучших такси, выполняющих заказы. Это три основных параметра, которые я пытаюсь оптимизировать с помощью алгоритма выдачи заказов.
Наша задача сильно нелинейна и, на мой взгляд, не сводима к линейной, что может означать просто то, что я не могу свести ее к линейной, кроме того, что, это оптимальное решение неустойчиво во времени. В том смысле, что это, конечно, не тот случай, что если я разработаю идеальный алгоритм для часа пик, он также будет оптимальным, скажем, для новогодней ночи или просто утренних часов. Он также пространственно неустойчив, что означает, что оптимальный алгоритм для Варшавы наверняка не будет работать, например, в Трехградье, где расстояния короче и проблема городских пробок гораздо меньше. И вся оптимизация для этого проводится в условиях неопределенности. То есть у нас нет данных, как, например, у почты или у логистической компании, которая заранее знает, из каких пунктов, в какие пункты ей нужно перевезти какой-то груз, будь то посылки или какие-то товары, в данный день, и она может просто оптимизировать это с помощью каких-то методов. Мы видим этот спрос на постоянной основе и бываем удивлены им. Мы можем внезапно увидеть, как триста заказов появляются в какой-то момент там, где раньше эти заказы не появлялись. Таким образом, это тоже оптимизация в условиях неопределенности. Вот такие основные вызовы, основные вопросы, которые делают эту проблему такой сложной.
Во-вторых, невозможно так быстро протестировать различные идеи, потому что их очень много, и нам нужно время, чтобы проверить идею. Решением этой проблемы может стать симулятор. И мне интересно, как вообще возникла эта идея? Было ли это таким очевидным? Это был такой естественный путь? И я также думаю, что стоит спросить о смелости, потому что это, конечно, нечто отличное от того, что обычно используется.
Образуются очереди, приходится ждать этот лифт или бежать по лестнице, например, на тринадцатый этаж, что не так просто для всех. Поэтому мы сказали, что решим эту проблему и расскажем, как изменить алгоритм движения этих лифтов. Поэтому мы обратились к тогдашнему ректору, который, к счастью, был эконометриком, и он дал нам зеленый свет на это. И мы решили решить эту проблему.
Конечно, дело не в том, что существует единственная оптимальная стратегия для работы трех лифтов в пятнадцатиэтажном здании, потому что если бы она существовала, она была бы просто реализована, и нам не пришлось бы ее обнаруживать, и, конечно, такая стратегия зависит от того, каково распределение людей, перемещающихся между каждой парой этажей. Мы, наверное, интуитивно знаем, что больше всего посадок и высадок происходит на первом этаже, и так далее.
И вы можете построить простую модель, например, предположить, что поездки осуществляются только между первым этажом, каким-то этажом и наоборот, то есть вы предполагаете, что люди никогда не путешествуют между этажами, что не соответствует действительности, но в некоторых случаях вы можете не учитывать эти поездки между этажами. Вы можете сделать массу других предположений, и мы, амбициозные студенты, решили, что это будет чрезмерным упрощением реальности, и мы хотим сделать что-то, что гарантированно будет работать.
Мы обнаружили, что эмпирически изучаем движение в этих лифтах, что было довольно забавной историей, потому что люди, путешествующие на этих лифтах, могли встретить студента, стоящего в этом лифте. Затем мы оптимизировали наш способ сбора информации, и у нас уже были стулья, на которых сидел этот студент, и мы отмечали время, когда каждый человек входил в лифт. Этаж, на котором он зашел, этаж, с которого он сошел.
Когда мы собрали достаточно данных, мы оценили распределения и начали строить симулятор. Это было очень весело для нас, студентов. Очень познавательный опыт, но самое интересное, что это решение было позже реализовано и решило проблему очередей перед лифтами. Это работало в течение очень долгого времени. Несколько лет назад кто-то рассказал мне, что ректор упомянул в аудитории, что этот алгоритм все еще работает. Кроме того, я до сих пор испытываю некоторую гордость по этому поводу.
И это был последний раз, когда я использовал симулятор, потому что после этого проблемы, с которыми я сталкивался, либо решались аналитически, и тогда зачем строить сам симулятор, если можно решить их аналитически, либо они были настолько сложными, что я не представлял, как построить симулятор. Теперь, когда я перешел на iTaxi, я вдруг обнаружил, что могу увидеть, что, опять же, проблема, которую даже можно решить только методами моделирования.
Потому что процессы строго определены. Мы знаем, как выглядит этот процесс. Пассажир нажимает на кнопку, такси получает заказ, принимает его или нет, потому что таксист может отказаться, если заказ не принят, он переходит к следующему таксисту. Тот, кто, наконец, принимает приказ, начинает движение. Вы можете смоделировать, с какой скоростью, когда он приедет. Позже он садится за руль, высаживает где-то пассажира и снова свободен. Все это можно описать таким итеративным симулятором, где, допустим, мы ловим такие окна каждые 15 секунд, обновляем ситуацию, ну и я обнаружил, что не знаю лучшего способа решить эту проблему.
Ты также спросил о смелости. Да, я задавался вопросом, сработает ли это вообще, но есть проблема, которую нужно решить. У меня нет другой идеи, поэтому я пробую методы моделирования. И поэтому очень часто бывает так, что проблема кажется гораздо более сложной, прежде чем мы садимся за нее. Бывает и наоборот, но в этом случае я вдруг обнаружил, что создание этого симулятора не так трудоемко, как я думал. У нас было много данных из прошлого, что позволило легко проверить, какие предположения этого симулятора верны, а какие необходимо изменить. И это был действительно путь вперед, которым я в принципе доволен, потому что мы достигли именно того, чего хотели. То есть теперь у нас есть отражение того, как работает город, назовем это так, где-то в компьютере, и мы также можем моделировать некоторые из наших новых идей.
Мы предполагали, что каждый заказ — это всегда ровно одно такси. Мы настроили, что нет предварительных заказов, т.е. таких, что я, например, сейчас заказываю такси на завтра в 9:00. Поэтому идея состоит в том, чтобы как можно скорее добраться туда на такси. Мы также исходили из того, что пассажир не меняет своих решений без причины. То есть он может сказать: «Я отказываюсь от такси, потому что время в пути слишком длинное», и мы максимально смоделировали это, но предположили, что дело не в том, что он заказывает такси, а в том, что такси едет и время ожидания для него допустимо, но я отказываюсь от него, что, очевидно, является упрощением действительности.
А сейчас это самые простые упрощения, но мы же предполагали, что все такси имеют одинаковые скоростные характеристики. Так что, конечно, скорость такси в центре города и на окраине разная, но каждое такси в центре города движется с той же скоростью и с той же скоростью, что и другие, на окраинах. Ну проглотить еще можно. И последнее предположение, самое резкое, это мое предположение, что такси будут двигаться прямолинейно. И это, конечно, никак не отражает действительности, но тут мой ход мыслей был такой: городская метрика.
Не то, что в оперативных исследованиях называют городской метрикой, а такую реальную городскую метрику, такая классическая евклидова метрика, т. е. движение по прямой без нагрузки в любом направлении. Конечно, мы предполагаем, что путь будет намного короче, поэтому мы должны компенсировать это, соответственно регулируя скорость такси.
И, конечно, я очень боялся, как это предположение, не является ли оно слишком упрощающим и не повлияет ли оно на то, что то, что мы получим в симуляторе, совсем не будет отражать реальность, поэтому я очень тщательно проверил на таких узких случаях, значительно ли отличаются результаты, полученные таким методом, и прежде всего я проверил, очень ли тесно коррелирует расстояние по прямой, то есть то, которое я собираюсь использовать, со временем в пути. Потому что если она очень тесно коррелирует со временем поездки, причем реальной, исторической, то это означает, что, манипулируя только скоростью, я могу имитировать реальное время поездки, которое было бы у такси, если бы оно ехало по нормальным дорогам.
И это было самое грубое предположение, но есть также вещи, которые, как мы выяснили, нам предстоит нанести на карту. Определенные явления имеют специфические распределения, например, распределение заказов, появление заказов специфично и во времени и в пространстве, то есть больше заказов появляется в пике и также в пространстве.
Это довольно характерно, потому что, например, утром больше заказов появляется на окраинах города, а после обеда больше заказов появляется в центре, потому что люди обычно едут на работу с окраин в центр и возвращаются с работы из центра на окраины. И, конечно, эти графики должны были быть связаны, то есть распределение заказов во времени и в пространстве должно было быть связано. И должно было быть воспроизведена очень точно. Я бы, наверное, хотел сейчас рассказать, как мы это делали, какими методами. Кроме того, мы хотели очень точно отобразить распределение доступности водителей такси.
Нельзя считать, что каждый водитель такси работает по восемь часов одинаково. Некоторые из них работают два часа в день, другие - восемь, некоторые работают два дня в неделю, другие - семь. Мы предоставляем таксистам полную свободу в этом отношении. Еще один момент с этой стороны - распределение терпения пассажиров. Нельзя сказать, что если время в пути составляет более восьми минут, пассажир всегда откажется от поездки. Для некоторых пассажиров это приемлемое время, для других - абсолютно неприемлемое. Поэтому мы должны были смоделировать это распределение терпения для каждого пассажира независимо.
Мы также исходили из того, что отдельные города имеют совершенно разные характеристики, поэтому мы не будем предполагать, что то, что работает для Варшавы, будет работать и для других городов, и смоделируем каждый город отдельно. Мы также предположили, что проходимость города, что в нашем случае означает, что скорость такси меняется со временем, т.е. она разная в часы пик и разная ночью. Ну, и она неоднородна в пространстве. В центре вы ездите по-другому, на окраинах - по-другому. И, такое очень важное предположение в любой симуляции, что когда мы принимаем решения в данный момент, мы не имеем никакого знания о будущем. Это вполне очевидно, но часто аналитики пытаются идти коротким путем и говорят: у меня есть весь спрос за весь день, и сейчас я найду такую функцию, которая оптимизирует удовлетворение этого спроса, тогда как нам не нужно иметь такую функцию, которая, имея информацию в 9:20 утра, примет оптимальное решение, а потом узнает, что произошло в 9:21 утра, и примет другое решение.
И, конечно, это уже очень очевидно. Мы выяснили, что каждый вид деятельности должен занимать определенное количество времени. Заказ такси, принятие заказа водителем такси, время прибытия, посадка пассажира и так далее. Каждое из этих действий требует времени, и это время должно быть введено в симулятор. Что касается того, что делать с этими графиками. Как я уже говорил о лифтах, мы оценивали расписание, сидя в лифтах и делая записи. Здесь я был в несколько лучшем положении, потому что у нас было много исторических данных, но, конечно, особенно в компании, которая растет так динамично, как наша, вы не можете перенести прошлое в будущее, будущее просто намного интенсивнее.
Есть еще много других заказов, которые выполняются изо дня в день. И я решил, что лучшим подходом будет использование метода Монте-Карло для построения большинства этих распределений. Для тех, кто не знает, метод Монте-Карло был изобретен польским математиком по имени Станислав Улам. Это математик, выходец из львовской школы, который, помимо всего прочего, работал над созданием атомной бомбы во время Второй мировой войны.
И этот метод используется для поиска решения проблемы, которую слишком сложно решить аналитически. И это решение находится путем многократного повторения эксперимента, который предполагает розыгрыш в соответствии с определенным распределением вероятности. Например, можно представить, что мы хотим оценить площадь некоторой области с очень неправильными формами, например, допустим, мы хотим оценить площадь озера. Метод Монте-Карло в таком случае даст следующее решение: создайте себе квадрат с известной вам длиной стороны, такой, чтобы все озеро находилось внутри квадрата. Затем из такого классического равномерного распределения многократно отбираются точки, принадлежащие этому квадрату.
Некоторые из точек будут находиться на поверхности озера, некоторые - нет. Если разделить количество точек, принадлежащих озеру, на количество всех точек, то получится оценка того, какую часть квадрата занимает озеро, а поскольку вы знаете площадь поверхности квадрата, это также дает вам оценку площади поверхности озера. Очень просто и элегантно. Конечно, вам придется сделать много таких отрисовок, но это очень здорово для оценки, например, просто площади, если кто-то вроде меня не очень любит интегралы, это также здорово для вычисления площади под графиком.
И я использовал этот метод для оценки распределения вероятностей для моего симулятора. Например, чтобы смоделировать спрос, я взял все заказы клиентов за соответствующий период в прошлом. Если, например, я хотел бы сделать симулятор дня, когда я ожидаю двести заказов, то просто из прошлого, из подобных дней я просто взял двести заказов и взял все признаки этих заказов, т.е. то, что было у пассажира. Характеристики, где именно появился заказ, какой был адрес получателя, в какое время и так далее. Подобным образом я оценивал и другие признаки, даже моделировал их для них. А потом нужно было построить симулятор. Если бы вы визуализировали это, что я и сделал, а в симуляторе есть возможность посмотреть, как выглядел город в какой-то итерации, это выглядело бы, скажем, как такси на карте Варшавы. И тут появляется заказ. И заказ назначается одному из такси самой важной функцией в этом алгоритме, потому что мы ее оптимизируем.
Затем, на следующей итерации, такси движется к клиенту. Может появиться больше заказов, может появиться больше такси, потому что какой-то таксист только начал работу, может исчезнуть какое-то такси, потому что какой-то таксист закончил работу, может произойти какое-то другое событие. Они могут изменить, например, скорость. Затем еще одна итерация. Выбранное нами такси прибудет к пассажиру в определенное время, затем вместе с пассажиром доедет до адреса назначения, высадит пассажира, снова изменит статус на доступный и будет готово принять другой заказ. И так я моделирую весь день. Затем, конечно, возникают такие проблемы, как отсутствие работы у таксистов, отказ таксистов от заказов, потому что они считают, что поездка займет слишком много времени, пассажир не хочет ждать так долго, и многие другие проблемы. А затем нужно просто провести множество симуляций.
Проверяем, есть ли у нас нестабильность, т.е. сильно ли отличаются результаты отдельных симуляций, потому что если да, то либо проблема хаотична, потому что такое тоже может случиться. К счастью, в нашем случае это было не так.
И вообще, моделирование хаоса - не лучшая идея, или если расхождение велико, это может указывать на то, что в симуляторе есть какие-то нестабильные элементы, и их нужно найти, и исправить. Затем, когда мы видим, что стабильность усредняет результаты этих многочисленных симуляций, находя наилучшие параметры, у нас есть что-то, что, по нашему мнению, лучше всего работает в симуляторе, теперь нам нужно проверить, будет ли это лучше всего работать в реальности. Вот здесь мы и подходим к проверке реальности. Для этого мы провели классические A/B-тесты, то есть для одних заказов мы использовали новые признаки, которые придумали в симуляторе, для других - оставили старые и проверили, действительно ли улучшение было таким, как мы ожидали. Вот примерно как это происходило.
Как, например, ты знаешь, что симулятор работает по-другому, но у этого симулятора очень много разных параметров. Откуда ты знаешь, что в данном случае нужно изменить такие-то параметры, или такое-то предположение, или другое предположение. Потому что ты сделал некоторые из этих предположений. Происходит ли это уже на интуитивном уровне? Есть ли у тебя другие методы для этого? Расскажи нам об этом.
Действительно, это самая большая проблема. И так: на первом этапе я просто попытался составить карту нашего прошлого. То есть в симуляторе применимой функцией была та, которая до сих пор реализована в реальности. Я брал реальный день из прошлого и проверял, что результаты в симуляторе отражают этот день, один к одному. Сначала на самом общем уровне. Например, соответствует ли среднее медианное время прибытия реальности. Был ли не обработан аналогичный процент заказов.. Затем я спустился еще глубже. Выполнялись ли, например, примерно одинаковые заказы, не было ли такого, что симулятор хорошо ведет себя в часы пик и совершенно не отражает реальность ночью. Конечно, не то чтобы я требовал от симулятора делать все один в один, как это происходило в реальности, и некоторые отклонения допустимы, ведь это симулятор, но если система вела себя совершенно иначе, то было ясно, что симулятор работает плохо. Что ж, это был первый этап такой предварительной калибровки на будущее, когда мы еще совсем не проверяем новые гипотезы.
Я визуализировал ее на картах и смотрел, насколько логично выглядит схема, насколько логично то, что я вижу на карте. Если нет, я пытался изменить это. Позже, когда мы уже проводили A/B-тесты, в основном процедура была очень похожей, но я также тестировал стабильность системы из-за определенных параметров. То есть, если я тестировал, что произойдет, если я немного или больше изменю какой-либо параметр, сильно ли это повлияет на результат. Если эта чувствительность к данному параметру мала, то, вероятно, нет смысла возиться с этим конкретным параметром вообще, и он не так уж важен для результата. Если же она очень велика, то нужно присмотреться к ней, изучить некоторые отдельные случаи. И вот что это было, так это много поисков и попыток, подгонки этого симулятора к реальности таким образом, чтобы он был как можно ближе, но не так, как это часто пытаются сделать аналитики, так что да, я нашел что-то, что минимизирует некоторую среднюю ошибку, то есть просто что-то, что отражает реальность как можно ближе чисто физически.
Как я уже говорил ранее, у нас есть три проблемы, которые мы хотим оптимизировать, поэтому метрика успеха должна быть подобрана для каждой из них. Первый вопрос - это время на дорогу, и здесь естественным вопросом для меня было просто среднее время на дорогу. Медиана, а не среднее значение, потому что я хотел получить показатель, невосприимчивый к выбросам. Медиана - да, а среднее - нет. Второй вопрос - сколько заказов мы можем правильно обработать, и это показатель, который мы называем коэффициентом надежности, что на самом деле является отношением количества обработанных заказов ко всему спросу, который поступил, и третий вопрос - качество подаваемых такси.
И здесь, поскольку каждому из наших таксистов присваивается балл, который может меняться со временем, в зависимости от того, как их оценивают клиенты, как мы оцениваем их работу, поэтому в качестве такой метрики этого качества я взял средний балл, но средний не по таксистам, потому что это фиксировано, а по выданным заказам. То есть, высокий средний балл означает, что заказы достаются в основном тем, кто лучше по баллам таксистов. И это были три метрики.
Итак, что мне удалось сделать? Я сделал это первое предположение, так или иначе, вам придется иметь дело с многокритериальными проблемами. Либо вы можете создать некий синтетический индикатор, включающий несколько критериев, либо сделать некое предположение. Наш подход заключался в том, что мы считаем, что качество наших водителей в настоящее время является адекватным, т.е. граничное условие - не ухудшать средний балл, в то время как мы боремся за сокращение времени поездок на работу и повышение эффективности удовлетворения спроса, и оба эти фактора находятся на равном уровне.
И чего мы достигли, где мы сейчас? Сейчас мы находимся в такой точке, что по сравнению с тем, что было до симулятора, средний скоринг увеличился на 0,4%, а медиана времени в пути уменьшилась на 4,5%, а количество выданных заказов увеличилось на 3%. И что это значит? Это не очень большие значения, но даже последний показатель говорит о том, что на тех же исправлениях в алгоритме компания заработала на 3% больше.
Я просто объясню, почему так мало, сначала. А может быть, я даже начну сначала с чего-то другого. Всего два месяца назад этот рост составлял несколько процентов, тогда как сейчас разрыв сократился, и этому есть несколько вполне логичных причин.
Было намного лучше, но наша ситуация как компании значительно изменилась. Недавно наша компания выиграла тендеры на эксплуатацию Центрального и Западного железнодорожных вокзалов Варшавы и аэропорта Шопена, что привело к полному изменению ситуации. У нас совершенно другая структура заказов, чем была некоторое время назад, и вдруг выяснилось, что я должен вернуться к этому решению, потому что то, что было оптимальным до этого изменения спроса, теперь уже не оптимально. И это одна из таких причин. Вторая причина на самом деле является основной причиной того, что этот рост не так уж велик. Прежде чем я начал копаться в этом, у нас уже был довольно хороший алгоритм.
Действительно очень эффективен в выдаче заказов. Так что возможности для улучшения, конечно, есть, но они не такие, как если бы, например, у нас был такой классический, жадный алгоритм, то есть он всегда отправляет ближайшее такси. И третья причина, почему этот прирост не так велик. Тестирование того, что получается в симуляторе в таких классических A/B-тестах, должно занимать время. Мы должны помнить, что мы проводим тестирование на живом организме, и если случится так, что наш симулятор покажет, что он будет работать хорошо, но реальность этого не отразит, мы потеряем клиентов, возможно, потеряем таксистов, которые не будут получать заказы, и в целом это очень плохо скажется на нашем бизнесе, поэтому мы должны проводить эти тесты медленно и осторожно, чтобы тестирование длилось долго.
Поэтому процесс оптимизации идет не так быстро, как мне бы хотелось, мы все еще не остановились. Ты также спросил о том, к чему мы стремимся. Ну, у меня есть предположение, что в течение года - это максимально реально, и я стремлюсь к этому. Я хочу сократить время поездки на работу на 15% и уменьшить количество невыполненных заказов на 20%. Это, я абсолютно точно вижу, что это достижимо. Это требует немного изменения подхода и еще большего усложнения симуляции, потому что мы только начинаем работу над динамическим механизмом, который должен адаптироваться, и можно сказать что интеллект, или еще более модное - искусственный интеллект, применим к нынешним условиям.
То есть, к тому, сколько такси доступно, интенсивность заказов, загруженность города, т.е. для примера: если у нас вечер, город хорошо загружен, у нас много свободных такси, то, наверное, оптимально послать клиенту лучшую машину, даже если он будет ждать семь минут вместо шести. В этом случае клиент будет более удовлетворен. С другой стороны, в пиковое время, когда город парализован, мы предпочитаем не пробовать ничего другого, а просто отправить ближайшее такси, потому что разница во времени в пути будет весьма существенной. И, конечно, речь идет не о механическом утверждении, что пик приходится на каждый день, с понедельника по пятницу, между 7.30 и 9.30 утра, а о том, что система сама, исходя из состояния спроса, предложения и загруженности дорог, должна определить, какая функция должна быть использована в данный момент. То есть, чтобы была своего рода оптимизация параметров этого алгоритма в реальном времени, и здесь я вижу очень большой потенциал роста.
И, возможно, в более широком смысле в старой эконометрике, которая имела свое подразделение до того, как эконометрика превратилась в машинное обучение, а затем в искусственный интеллект, у нас было такое огромное подразделение, которое называлось исследование операций. И в принципе, там, где раньше использовалось исследование операций, именно моделирование часто является лучшим подходом.
Мм, и здесь я, вероятно, удивлю тебя, потому что мы довольно маленькая компания, так что этот симулятор был в основном построен мной. Консультировался с несколькими людьми, но большая часть такой работы все же была самостоятельной. Я создавал симулятор в течение примерно трех месяцев, но поскольку у меня также много других задач в компании, могу сказать, что реальное время составило, вероятно, около тридцати рабочих дней. Для создания и такой начальной версии. То есть в тот момент, когда у меня есть симулятор, который хорошо отражает прошлое, поэтому я знаю, что он хорошо работает для той функции, которая была раньше. А потом, после этого, вы можете начать его использовать, и тогда работа над ним уже будет непрерывной, то есть я ищу решение, я ввожу A/B тесты, я проверяю результаты, я корректирую симулятор, и так далее, и так далее, и это, конечно, может продолжаться бесконечно. Но этих тридцати дней одного человека было достаточно, чтобы построить симулятор.
Важно иметь хорошее представление и понимание проблемы, к чему мы на самом деле стремимся. И вот тут я хочу добавить еще один вопрос. Немного более обобщенно, но, скажем так, для лиц, принимающих решения, которые, возможно, слушают нас прямо сейчас. Какой совет ты можешь дать, если кто-то думает о том, чтобы начать использовать машинное обучение или так называемый искусственный интеллект? На что следует обратить внимание и как это сделать разумно?
Пожалуй, сначала я скажу о том, чего я не советую делать. Я вижу такую общую тенденцию на рынке, которую я бы назвал: "Сделай свой собственный Data Science". То есть разрабатывается все больше и больше программного обеспечения, которое позволяет ввести некоторые данные, указать, какой эффект вы хотите получить, нажать кнопку, и это программное обеспечение само выберет модель, само рассчитает, создаст прогноз, классификацию или какой-то другой результат, и все готово. Вам не нужен специалист по анализу данных, чтобы самостоятельно заниматься машинным обучением. Вам не нужно иметь никакого представления о том, как работает метод, который вы только что использовали.
И это, вероятно, очень заманчивый сценарий для многих людей, которые не хотят тратить деньги на наем аналитика. На самом деле, программное обеспечение, хотя оно тоже не дешевое, всегда будет дешевле аналитика. С другой стороны, я бы сравнил это с самостоятельным электромонтажом дома. Это легко, не так ли? Необходимо проложить кабели от источника энергии туда, где они нужны. И, возможно, даже многим из нас это сойдет с рук, а время от времени у кого-то произойдет короткое замыкание, пожар, и все сгорит. То же самое, на мой взгляд, справедливо и в отношении использования таких "черных ящиков".
Менеджер, который выбирает легкий путь, рискует получить такой пожар. Это программное обеспечение может предложить ему нечто, что очень хорошо соответствует данным, использованным для создания модели, но совершенно не отражает будущее. И наступит катастрофа. У меня не так много иллюзий. Эта тенденция будет усугубляться. Станет все проще и проще проводить сложную аналитику людьми, которые не до конца понимают, что происходит в этом черном ящике.
С другой стороны, я также считаю, что до тех пор, пока мы не получим такой настоящий искусственный интеллект, все еще будет лучше нанять хорошего аналитика на очень долгое время, чем купить программное обеспечение с большой красной кнопкой для проведения сегментации, например. Кроме того, нужно помнить, что если кто-то показывает вам такую систему, которая так красиво делает аналитику, обычно реальные бизнес-кейсы намного сложнее, чем эти академические примеры. Таким классическим академическим примером является набор Iris, который отлично подходит для демонстрации того, как, например, работает алгоритм k-means, т.е. как группировать, сегментировать определенные наблюдения в отдельные классы, но полностью на этом наборе мы не показываем, что может произойти, если мы применим алгоритм k-means, если отдельные наборы, на которые мы должны сегментировать, на самом деле невыпуклые.
Или если мы знаем, что мы должны сегментировать на два сегмента, но эти два сегмента сильно неравнозначны, например, один представляет только 1% наблюдений.
И тогда такие методы, как алгоритм k-means, который отлично работает на обработанных данных, практически могут не работать. Тогда человек, не понимающий идеи, лежащие в основе этих методов, оказывается беспомощным. Это можно свести к простому совету - нанимайте специалистов в этой области. Не рассчитывайте на то, что хорошо сделанный автомат заменит аналитика. Эти программные продукты очень полезны, но именно для аналитиков. Они могут повысить эффективность работы аналитика, поскольку он сможет работать намного быстрее, используя эти программы, но они не заменят его. Это похоже на то, как я считаю, что хороший топор повышает эффективность работы дровосека, а хорошее программное обеспечение помогает исследователю данных, но сам по себе топор не срубит дерево.
Я знаю, что технологии сильно ускоряются, но для меня это все еще короткий промежуток времени. Что точно произойдет, так это то, что машины будут лучше распознавать изображения и речь, они будут лучше распознавать контекст, у нас будет все больше и больше аудиоинтерфейсов, ботов, вещей, которые еще недавно были совершенно недоступны. То есть мы сможем хорошо автоматизировать те виды деятельности, которые являются механически повторяющимися.
Возможно, если задуматься, это тоже довольно механически повторяющийся механизм, но автономные автомобили сделают нашу жизнь проще. Многие другие процессы будут упрощены и оптимизированы. Это будет иметь социальные последствия, поскольку многие профессии могут потерять смысл своего существования или стать редкими. И такие очень разные, как, например, авиадиспетчер, потому что автомат может сделать это не хуже человека. Начальник станции, что в некотором роде похоже, а также контролер билетов в общественном транспорте может быть заменен автоматом, или другим способом автоматического сбора платы за проезд в транспорте.
Безусловно, выявление множества заболеваний с помощью автоматов может помочь нам жить дольше и болеть реже. С другой стороны, я думаю, что в какой-то момент мы начнем переживать, если уже не боимся того, к чему все это приведет. Я тоже испытываю этот страх, потому что у меня есть теория, что именно развитие искусственного интеллекта приведет к уничтожению человечества. Я имею в виду, что это не только моя теория, потому что еще в девятнадцатом веке парень по фамилии Батлер придумал нечто подобное, что люди создадут искусственный интеллект, который уничтожит человечество.
Позже эта концепция была прекрасно повторена Фрэнком Гербертом в его серии "Дюна". Это научно-фантастическая серия. Тем, кто еще не прочитал его, я советую это сделать. Это 1960-е годы, но они по-прежнему очень интересны, и можно найти очень много параллелей с тем, как трансформируется мир. Там, в Герберте, люди в какой-то момент уничтожили все мыслящие машины, избегая самих растений, и наложили очень жесткий запрет на создание любых мыслящих машин.
Я думаю, что мы по какой-то причине делаем несколько необоснованное предположение, что этот искусственный интеллект, который мы в конечном итоге выведем, будет иметь добрые намерения по отношению к нам. В конце концов, мы сами их создали. Но на самом деле я не понимаю, почему это должно быть так. Почему у него не должно быть этого классического, скажем так, менталитета дикаря из каменного века, который только и смотрит, как бы побить человечество булавой по голове и перестать о нем заботиться. Поэтому я задаюсь вопросом, в правильном ли направлении мы движемся, хотя, конечно, нельзя полностью отрицать, что сейчас в краткосрочной перспективе любое развитие этих методов, которые мы обычно называем искусственным интеллектом, делает нашу жизнь проще и будет продолжать делать это еще какое-то время.
Спасибо тебе.
Присоединяйся сейчас и начни свое комфортное обучение.