Обзор ML-митапа “FunCorp”
Введение
9 февраля компания FunCorp провела митап, посвящённый машинному обучению (анонс митапа на Хабре). В этом обзоре я расскажу про основные моменты всех докладов, которые были на этом митапе.
«Опыт запуска Discover для 90 млн пользователей: пять рекомендаций ML-разработчикам», Андрей Законов, vk.com
Важна не только модель: правильно формулируем задачи и выбираем метрики.
Разные способы оптимизировать свои решения под нагрузки.
Правильно оцениваем эксперименты: изучаем графики и работаем с обратной связью.
Очень подробный и обстоятельный доклад (он длился почти час), описывающий проблемы, которые связаны с использованием ML в продакшене. Мне он показался наиболее практичным из всех.
При работе с машинным обучением сложно оценить сроки реализации проекта и качество, которое получится на выходе. Заранее стоит подумать о связанных задачах, которые могут появиться, После внедрения алгоритма рекомендаций на VK (на примере которого был построен весь доклад) быстро появились задачи по борьбе со спамом и накрутками, выявлению дублирующегося контента и т.д.
Сразу нужно выяснять, какую конкретно задачу решаем, какие входные данные есть, какова нагрузка и требования по времени ответа и каковы продуктовые приоритеты.
При работе с машинным обучением часто проблемы возникают не на этапе выбора модели и её обучения, а на остальных “скучных” этапах: выборе конкретных задач и метрик, сборе и подготовке данных, оценке результатов эксперимента в продакшене. Общий результат определяется “самым слабым звеном” среди всех этапов.
Качество получившегося результата можно проверить только на продакшене, поэтому стоит как можно быстрее выбрать и разработать какое-то MVP для решаемой задачи, запустить его на небольшой тестовой группе и получить реальные данные. Если результат окажется плохим, то можно будет сделать новое решение. Важно заранее понимать, сколько должен длиться тест и как будем интерпретировать результаты (чтобы не тратить на обкатку плохих решений больше времени, чем реально необходимо)
Возможные варианты запуска ML функционала в продакшене: только алгоритм: его можно безболезненно заменить и пользователь ничего не заметит) алгоритм + новый UI: в этом случае просто выключить новый функционал сложнее, поэтому нужно запускаться на небольшой тестовой группе “point of no return” (например, внешний маркетинг нового функционала): в таком случае следует обложить всё метриками и подготовить несколько моделей, чтобы была возможность перейти с совсем плохой на модель получше.
Полезно иметь какой-то план Б, который можно использовать, если модель работает совсем плохо. Это может быть какой-то упрощенный функционал, решающий задачу простейшим образом (в случае рекомендаций это может быть какие-то популярные посты). Мне это напомнило сервисы-“тыквы” с митапа “Яндекс.Такси”.
Требования к качеству модели можно регулировать самим продуктом:
Обязательно нужно собирать различные метрики по работе функционала в продакшене и собирать информацию о реакции пользователей на новый функционал. Опираться только на суммарные значения метрик нельзя, т.к. могут быть задеты интересы небольших, но важных групп (например, каких-то инфлюэнсеров).
Проверять качество работы функционала только после внедрения неправильно, т.к. через сравнительно долгое время могут проявиться какие-то отложенные эффекты. Нужно периодически оценивать результаты работающих алгоритмов на продакшене и, возможно, иногда включать старые “неэффективные” алгоритмы чтобы перепроверить их результаты и сравнить с текущими.
«Как научить поисковики читать мемы», Григорий Кузовников, FunCorp
iFunny — приложение со смешными картинками и видео. Для привлечения трафика с поисковиков, мы извлекаем текст с картинок. Специально для этого был создан сервис, который:
- находит на картинке область, содержащую «основную шутку»
- извлекает текст из этой области
- проверяет качество распознанного текста.
Основной контент в приложении iFunny - это картинки-мемы, загружаемые пользователями. Текстовое описание шутки с картинки помогает привлекать поисковый трафик, но обрабатывать все картинки “руками” дорого, поэтому Гриша реализовал автоматическое решение, распознающее текст с картинок.
Для распознавания текста стали использовать Tesseract OCR от Google. Он распознавал много лишнего (т.к. кроме текста самой шутки на картинке может быть “текстовый шум”), поэтому надо было выделять на картинке область именно с шуткой, которую впоследствии распознать с помощью Tesseract. Мемы были предварительно проанализированы и было понятно, что одного блока с текстом будет достаточно.
Для решения этой задачи использовали нейросеть, обученную на 3000 картинок, которые были размечены руками с помощью инструмента MS VoTT. Насколько я понял, вся размеченная выборка использовалась в обучении и потом Гриша вручную анализировал качество (кажется, что тут можно было избавиться от ручного анализа, разделив размеченные картинки на training, test и validation set или используя кросс-валидацию).
На базе этого решения был сделан сервис на Python, который скачивает картинки (в несколько потоков) и распознаёт на них текст (в один поток, т.к. распознавание в несколько потоков почему-то работает неэффективно). В итоге удалось добиться распознавания текста примерно на 60% загружаемых картинок и повышения поискового трафика.
Гриша также рассказывал про архитектуру сети, определяющей область с шуткой, и выбор фич, которые подаются на вход этой сети, но я плохо понял эти моменты.
«Production в ML», Марк Андреев, Conundrum.ai
В докладе пойдёт речь:
- о видах предсказаний: realtime, offline, realtime + offline
- о том, как от прототипа в Jupyter Notebook дойти до контейнера
- о масштабировании решения и о контроле качества.
Формат доклада был очень похож на lightning talk, т.е. он был очень коротким (около 10 минут) и в нём кратко обрисовывались основные моменты по переходу от модели из Jupyter Notebook к микросервису с “замороженным” окружением. Подробнее описывать не буду - полезнее будет просто посмотреть презентацию.
Марк предложил интересный приём по работе с фичами, использующимися в модели. Conundrum использует ML в производстве (в буквальном смысле слова - на заводах) в том числе для предсказания необходимости обслуживания станков. У этой области есть два нюанса:
- датчики, с которых они получают данные, могут выйти из строя как “планово”, так и из-за какого-то сбоя (например, если его случайно сломают);
- обслуживание станков происходит редко и из-за этого возникает “отложенный эффект” (т.е. нельзя быстро выловить проблему по ошибке в целевой переменной.
Чтобы решить эту проблему при использовании фич они отслеживают изменения в распределении значений. Если распределение резко меняется, то они перестают использовать эту фичу в оценке.
Мне показалось, что этот доклад стоило пустить в самом начале для того, чтобы подготовить аудиторию к более серьёзным и длительным докладам.
«Машинное обучение в Yandex.Taxi», Роман Халкечев, Yandex.Taxi
В докладе пойдёт речь про устройство Яндекс.Такси.
Будет подробный рассказ:
- про задачи, которые мы решаем с помощью анализа данных и технологий машинного обучения
- про наш конвейер разработки, тестирования и запуска в продакшн моделей машинного обучения
- пройдёмся по всем этапам: от экспериментов в Jupyter Notebook до полноценного ML-продакшна.
Рассказ Романа состоял из двух частей: подробного описания тех задач, которые в Яндекс.Такси решаются с помощью машинного обучения, и краткого обзора того, как модели работают в продакшене.
Задачи, которые мне запомнились:
- Предсказание времени подачи машины до размещения заказа и связанный с ним выбор конкретной машины после размещения заказа (механизм выбора машины подробно описан в статье на Хабре)
- Рекомендации точек посадки (упрощает интерфейс заказа и снижает время ожидания для пользователя, уменьшает время “холостого пробега” для водителя) и точек назначения (исходя из истории заказов, предыдущих действий и т.д.).
- Предсказание спроса на такси (позволяет перераспределить имеющиеся машины в место, где скоро будет повышенный спрос).
- Предсказание оттока пользователей и водителей (позволяет повысить лояльность или вернуть их в систему с помощью механизмов реактивации).
- Частичная автоматизация дистанционного контроля качества (ДКК) автомобиля: это набор классификаторов, которые определяют чистая ли машина, не битая ли она, соответствуют ли номера указанным и т.д. По части случаев система принимает решение сама, часть передаёт на ручную проверку в Яндекс.Толока, результаты которой перепроверяют асессоры Яндекс.Такси, которые хорошо знают специфику работы (позволяет увеличить качество сервиса для пользователей и уменьшить количество ручной работы для асессоров).
- Снижение нагрузки на службу поддержки: выделение обращений, на которые не нужны ответы, автоматическая классификация обращений по срочности (с передачей обращений в приоритетную или обычную очередь для обработки), рекомендация шаблонов ответов для сотрудников службы поддержки, автоматический ответ на некоторые обращения (позволяет снизить нагрузку на службу поддержки и ускорить получение ответа для пользователей с важными проблемами).
Рассказ про работу с ML в продакшене был сравнительно небольшой и мне показалось, что Роман подробнее раскрыл этот вопрос на митапе Яндекс.Такси в прошлом декабре, обзор на который я уже писал. Писать про это еще раз я не буду, прочитайте предыдущий обзор, если вам интеерсная эта тема.
«Избавляемся от проклятия Sklearn: пишем XGBoost с нуля», Артём Хапкин, Mail.ru Group
Рассказ про бустинг. Что нужно знать, чтобы самому его написать. Какие есть подводные камни, как можно улучшать его работу.
В этом докладе мы разберём принципы работы алгоритма, и, двигаясь от простого к сложному, реализуем свой собственный алгоритм Xgboosting’а, который потом можно будет подстраивать для любых задач машинного обучения — классификации, регрессии, ранжирования и т.д.
Этот доклад был самым хардкорным по содержимому. Состоял из двух частей: рассказа про устройство решающих деревьев и реализацию бустинга на их основе. Общий посыл заключался в том, что все просто используют готовые алгоритмы из sklearn, плохо разбираются, как они работают и поэтому не понимают, какого результата от них можно ждать и как его улучшать.
Я не буду пересказывать доклад своими словами, а просто дам ссылки на серию статей автора на “Хабре”, в которых он подробно раскрывает обе темы:
Сам доклад из-за большого числа формул (и того, что он был последним) я понял плохо, но статьи воспринимаются гораздо лучше (плюс в них есть не только формулы, но и примеры кода, что упрощает понимание).