Матчинг преподавателей и учеников с помощью ML

Я работаю аналитиком в команде подбора преподавателей. Мы следим за воронкой подбора с того момента, как ученик оплатил занятия и до подбора преподавателя и проведения с ним урока. Также мы занимаемся и переподборами — кейсами, когда ученик, позанимавшись с преподавателем, решает его заменить. Наши основные метрики — это среднее время подбора, доля автоматизации подбора (т.е. доля подборов, в которых не пришлось привлекать оператора), а также метрики, которые характеризуют качество подбора, например, доля учеников, которые решили заменить преподавателя в течение первых нескольких уроков.

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

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

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

Старый подход

Изначально мы рассчитывали для каждого преподавателя рейтинг, учитывавший с некоторыми весами характеристики преподавателя, которые мы считаем важными. Например, это возраст преподавателя и ученика, размер купленного пакета, различные метрики, по которым мы оцениваем качество преподавания и т.д. Этот рейтинг обновлялся каждый день и использовался для ранжирования списка преподавателей. Мы могли как-то изменять эти веса и смотреть, как это влияет на метрики подбора в A/B тестах, и, таким образом, постепенно улучшать модель. 

Но у такого подхода есть несколько недостатков:

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

• Рейтинг не универсален для разных предметов. Рейтинг преподавателей английского плохо подходил для преподавателей математики и с добавлением новых предметов требовалось разрабатывать новый рейтинг с учетом особенностей каждого продукта. С появлением большого количества новых продуктов в школе такой подход становился очень неудобным и ресурсозатратным.

Новый подход

Поскольку нам важно, чтобы ученик не бросил заниматься после нескольких уроков, мы можем попытаться предсказать количество уроков, которое он проведет с конкретным преподавателем (далее lifetime) с помощью машинного обучения, основываясь на массиве исторических данных, который у нас накопился за несколько лет. И использовать предсказанное значение для ранжирования.

Параметров, которые влияют на lifetime довольно много. Для примера посмотрим, как он коррелирует с опытом преподавателя для разных продуктовых линеек.

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

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

Здесь уровень ученика измеряется по 10 бальной шкале, а уровень преподавателя по общепринятой европейской системе. Мы видим, что для учеников со слабым уровнем английского предпочтительны преподаватели с уровнем B1, B2. Однако, с увеличением уровня ученика увеличивается и предпочтительный уровень преподавателя. 

Давайте посмотрим, как выглядит feature importance для самой базовой модели, в которой мы собрали только основные параметры: опыт преподавателя, география, уровень языка, желаемое количество занятий в неделю, размер купленного пакета и т.д. 

Такая модель дает некоторое представление о параметрах, которые влияют на lifetime ученика, но все же имеет довольно слабую предсказательную силу. Чтобы ее улучшить, пришлось подключать дополнительную информацию, которую мы знаем о преподавателях, например: рабочий стаж, средний lifetime его учеников, среднее количество занятий в месяц, метрики качества преподавания и т.д.

Больше деталей о работе модели и будущих улучшениях сможете прочитать в моем телеграм-блоге Хороший, плохой, злой аналитик.

Развертывание

При поиске решения для реализации модели в продакшене мы исходили из следующих предпосылок:

1. Поскольку расчеты должны делаться в реальном времени, система должна быть довольно быстрой и надежной.

2. Модель должна быть изолирована от остального сервиса подбора для того, чтобы можно было быстро вносить изменения и тестировать новые версии модели, не привлекая команду разработки.

3. Не должно быть больших затрат на инфраструктуру.

Изначально я рассматривал отдельный сервер с моделью, к которому сервис подбора обращался бы по API, либо Amazon SageMaker (облачный сервис для развертывания ML моделей), который мы иногда используем для ML-задач. Однако, поскольку наша модель довольно простая и не требует больших вычислительных мощностей, мы пришли к использованию инфраструктуры Skyeng для контейнеризированных приложений. У нас был готовый скелетон для приложения на Python + Django. На нем и было реализовано API для нашей модели.

Тестирование

С помощью нашей платформы для A/B тестирования мы разбиваем учеников, которым требуется подбор преподавателя на тестовую и контрольную группы и собираем данные о работе новой версии модели. Основные метрики, на которые мы смотрим –это количество уроков, которое провел ученик в каком-то фиксированном окне, и доля тех учеников, которые переподборали преподавателя в течение первых нескольких уроков. Также мы хотим не уронить конверсию в выбор преподавателя и не увеличить время подбора.

Итог

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