Зачем разработчику знакомиться с ML 👨‍💻

Вот вы разработчик и разрабатываете, например, популярное приложение — сервис заказа такси. И вот вы знаете, как код писать грамотно, как проектировать высоконагруженные сервисы. Но возникает творческая задачка: показать пользователю подсказки места назначения. То есть, до того как он начал вводить адрес, нужно угадать и сразу предложить несколько вариантов.

Люди, вызывавшие такси ночью зимой с 1% заряда аккумулятора, точно оценят такую фичу 🙂

Задача, как я уже заметил, творческая, и вы радостно потираете руки. Первое ваше решение - всегда показывать топ 3 популярных мест пользователя. Но, конечно, оно вас не очень радует: программист вы в конце-концов или нет? Сразу рождается второе решение: а давайте, если в место человек ездил примерно в эти часы за последнюю неделю, будем добавлять варианту +1 балл. Ну и популярность мест тоже как-то пересчитаем в баллы. Хорошо, это мы время учли, а есть же еще день недели. На работу мы ездим в будни, а куда-то еще - в выходные. Отлично, тогда добавляем +2 балла, если мы ездим сюда, например по будням, а сегодня как раз будний день. А еще такие же баллы за регулярные поездки по каждому дню недели. А еще есть места, в которые мы ездим даже издалека (например, опять же, на работу), а есть места, в которые мы ездим, когда они рядом - например, в бар рядом с работой едем с работы, а в бар рядом с домом едем из дома. О, еще одно наблюдение! Важно, ОТКУДА мы едем. Там тоже можно сделать разбалловку. В итоге через пару недель наших творческих фантазий в продакшене уже куча правил, по которым мы считаем баллы каждого места, куда часто ездит пользователь, и места с самыми большими баллами мы выводим в приложении как подсказки.

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

У меня для вас хорошие новости - можно не заниматься. Берете какую-нибудь популярную ML библиотеку (например XGBoost, LightGBM или CatBoost), собираете выборку с поездками пользователей (из логов) в разные места, обучаете модель классифицировать пары (пользователь, место) на 2 класса - 0, если не поедет туда, 1 - если поедет. И весь ваш алгоритм заменяете классификатором. Либо добавляете прогноз старого алгоритма как один из признаков, и больше уже не страдаете его модификацией и улучшением.

Плюсы: ML-модель учится на данных, самостоятельно формирует правила (и их может быть тысячи). Вам не нужно лезть внутрь, просто использовать готовое решение.

Минусы: Теперь придется учиться проверять качество модели. Если раньше хватало проверки на нескольких примерах, то для ML потребуется валидационная выборка. Важно хотя бы в теории понимать, как это работает.

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

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

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

〰️〰️〰️〰️〰️〰️〰️
Автор поста: Основатель и эксперт школы MLinside, Виктор Кантор

🎓А кто из разработчиков уже готов знакомиться с ML — ждём вас на нашем курсе «База ML», старт 9 декабря!