Когда студент решает уйти, его уже не вернуть. Но можно поймать момент до этого
Онлайн-образование построено на простой арифметике: чем больше студентов доходят до конца, тем выше прибыль. Проблема в том, что большинство не доходит. Средний отток в EdTech колеблется от 30% до 70%, и Яндекс.Практикум не исключение.
Раньше они ловили отток по старинке: когда студент переставал заходить в личный кабинет, ему звонил менеджер. Срабатывало в 20% случаев. Потому что к моменту звонка решение уже было принято. Нужно было предсказывать, а не констатировать.
Типичная ошибка EdTech-стартапов: реагировать на отток, когда студент уже перестал учиться. К этому моменту его мотивация равна нулю, а шансы вернуть — минимальны.
Не спрашивайте студентов, почему они уходят. Спросите данные
Первые попытки построить модель на явных признаках провалились. Студенты не бросают курсы из-за одной причины. Это всегда комбинация факторов, которые накапливаются как снежный ком.
Яндекс.Практикум отказался от анкет и опросов. Вместо этого они стали собирать цифровой след:
- Поведение в IDE: сколько ошибок делает студент, как часто обращается к подсказкам, скорость выполнения заданий
- Активность в тренажере: время между уроками, повторные прохождения, пропуски дедлайнов
- Взаимодействие с ментором: частота обращений, время ответа, эмоциональный тон сообщений (да, это тоже анализируют)
- Внешние факторы: день недели, время суток, даже погода в городе студента
Архитектура, которая работает в реальном мире, а не в ноутбуке дата-сайентиста
Модель построена на градиентном бустинге (CatBoost, если быть точным). Почему не нейросеть? Потому что здесь важна не только точность, но и интерпретируемость. Менеджерам нужно понимать, почему модель поставила студенту высокий риск оттока.
Конвейер обработки данных выглядит так:
1 Сбор сырых данных
Каждое действие студента логгируется в реальном времени: клики, нажатия клавиш, время выполнения. Собирается около 150 признаков на человека в день.
2 Агрегация и feature engineering
Сырые данные превращаются в осмысленные метрики: «среднее время между уроками за последнюю неделю», «процент выполненных заданий с первой попытки», «тренд активности».
3 Обучение и валидация
Модель обучается на исторических данных, где известен исход: дошел студент до конца или нет. Важный нюанс — используют не случайное разбиение, а временное. Потому что поведение студентов меняется со временем (помните, как все вдруг начали учиться после новогодних праздников?).
4 Прогноз и интервенция
Каждому студенту присваивается вероятность оттока на ближайшие 14 дней. Если она превышает порог (его подбирают под бизнес-цели), система автоматически создает таск для менеджера или триггерит персонализированное уведомление.
Самое сложное — не обучить модель, а встроить её в бизнес-процессы. Если менеджеры получают 100 уведомлений в день, они начинают их игнорировать. Поэтому Яндекс настраивает порог так, чтобы флажков было не больше 10-15% от общего числа студентов.
ROC-AUC 0.85 — это хорошо или плохо? Зависит от того, что вы считаете ошибкой
Основная метрика модели — ROC-AUC. Она показывает, насколько хорошо модель отделяет «уйдущих» от «остающихся». 0.85 — достойный результат для production-системы. Но это только половина истории.
В бизнесе важнее не AUC, а precision и recall на выбранном пороге. Потому что каждая ошибка стоит денег:
| Тип ошибки | Бизнес-стоимость | Как минимизируют |
|---|---|---|
| False Positive (студент не уйдет, но мы ему позвоним) | Тратим время менеджера, раздражаем студента | Повышают порог срабатывания, добавляют «холодный период» после успешных уроков |
| False Negative (студент уйдет, но мы не заметим) | Теряем клиента, который мог бы остаться | Увеличивают частоту переобучения модели, добавляют признаки социальной активности |
Порог подбирают так, чтобы precision был не ниже 70%. Это значит, что из 10 студентов, которым система поставила высокий риск оттока, 7 действительно уйдут в ближайшие две недели. Менеджеры тратят время только на тех, кому реально нужна помощь.
Что работает, а что — нет: уроки от команды Яндекс.Практикума
За два года эксплуатации модели накопились неочевидные инсайты:
- Модель переобучается на сезонность. Новогодние праздники, летние отпуска, даже начало учебного года в школах — всё это влияет на поведение. Приходится регулярно обновлять тренировочную выборку.
- Самые важные признаки — не те, что кажутся важными. «Количество ошибок» оказалось слабым предиктором. Зато «время между открытием урока и первым действием» — сильным. Прокрастинация убивает мотивацию быстрее, чем сложность материала.
- Модель нужно «подкармливать» обратной связью. Когда менеджер звонит студенту и тот говорит «да, я планировал бросить», это отмечается в системе. Без этого обратного контура качество предсказаний деградирует за 3-4 месяца.
Что дальше? От предсказания к предотвращению
Сейчас система работает в режиме «раннего предупреждения». Но команда Яндекс.Практикума экспериментирует с более агрессивным подходом — предиктивной адаптацией контента.
Если модель видит, что студент начинает отставать по алгоритмам, но хорошо справляется с фронтендом, система может предложить ему индивидуальный учебный план. Или дать дополнительные материалы именно по слабым темам — до того, как разочарование накопится.
Это уже не просто ML-модель, а система рекомендаций, похожая на те, что используют Netflix или Spotify. Только вместо фильмов и музыки — учебный контент.
Главный риск таких систем — они могут создать «фильтрующий пузырь» в образовании. Если студент слаб в математике, а система это видит и начинает избегать сложных задач, он никогда не преодолеет свой барьер. Баланс между адаптацией и вызовом — следующая большая проблема для EdTech.
Кейс Яндекс.Практикума показывает, что ML в образовании — это не про футуристические сценарии вроде персональных AI-тьюторов. Это про скучную, но эффективную работу с данными. Про то, чтобы заметить проблему до того, как она станет критической. И про то, что иногда лучший способ помочь студенту — просто вовремя позвонить и спросить, как дела.
Если интересно, как работают подобные системы с языковыми моделями, посмотрите наш разбор выбора LLM в 2025 или кейс Нейрометеума — там тоже много интересного про production-развертывание ML-моделей.
