Разработка AI-системы для прогнозирования увольнений

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

Прогнозирование увольнений почти всегда начинается одинаково: берём выгрузку из кадровой системы за несколько лет, помечаем ушедших сотрудников и обучаем модель. На демо метрики выглядят убедительно, а в проде половина «уходящих» остаётся, зато уходят те, кого модель считала лояльными. Причина не в алгоритме — в исторических данных, которые описывают прошлое состояние компании, а не текущее.

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

Второй — дисбаланс классов. Увольнения — редкое событие: на сотни сотрудников приходятся единицы случаев за период. При таком соотношении модель выгоднее предсказывать «останется» и получать высокую точность, никого не находя. Лечится не подкруткой порога, а пересборкой целевой переменной: горизонт прогноза, определение события, вес наблюдений.

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

Отдельно стоит качество исторических данных: задним числом менялись грейды и руководители, часть увольнений оформлена как «перевод», причины закрыты текстом в свободной форме. Без разбора этих артефактов прогнозирование увольнений превращается в угадывание, а не в управление текучестью персонала. Разбираем, как это закрывается на этапе подготовки данных и валидации.

Что даёт система прогнозирования увольнений бизнесу

Система прогнозирования увольнений работает не как «предсказание судьбы», а как инструмент приоритизации внимания руководителей. Модель оценивает каждого сотрудника по совокупности сигналов — динамика вовлечённости, изменения в характере задач, активность во внутренних сервисах, история повышений и ротации, поведенческие паттерны в коммуникации. На выходе — вероятность ухода в заданном горизонте предупреждения, обычно от одного до трёх месяцев. Этого достаточно, чтобы у руководителя осталось время на разговор, пересмотр условий или плановую замену, а не на тушение пожара в момент заявления.

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

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

Практический эффект складывается из трёх измеримых величин. Горизонт предупреждения даёт время на удержание сотрудников: разговор происходит до того, как человек начал активно искать, а не после оффера на руках. Доля удержанных сотрудников из числа попавших в зону риска показывает, сколько срабатываний конвертировалось в реальное решение остаться. Снижение внезапных потерь критических ролей — самая чувствительная метрика для бизнеса: она напрямую связана с простоем направлений, срывом сроков и стоимостью срочного найма.

Отдельно стоит учитывать, что система не заменяет управленческое решение, а меняет его контекст. Руководитель видит не «сотрудник уйдёт», а «вероятность выросла, вот факторы, вот динамика». Это переводит разговор о удержании из плоскости личных догадок в плоскость работы с конкретными причинами — перегрузкой, отсутствием роста, размытыми зонами ответственности.

Подходы к построению модели: сравнение вариантов

Выбор модели для прогнозирования увольнений — это компромисс между точностью, интерпретируемостью и требованиями к данным. Простые правила вида «нет повышения больше года — риск» работают как baseline: их легко объяснить, но они ловят лишь очевидные случаи и дают много ложных срабатываний. Логистическая регрессия добавляет веса признакам и остаётся прозрачной: для каждого сотрудника видно, какой фактор поднял или снизил оценку риска.

Градиентный бустинг на табличных данных обычно даёт лучшую разделяющую способность, но требует объяснения через SHAP-значения или surrogate-модель, чтобы результат оставался понятным HR-команде.

На практике мы чаще строим двухуровневую схему: бустинг даёт ранжирование риска, а логистическая регрессия или дерево на тех же признаках объясняет, почему сотрудник попал в группу внимания. Такой тандем закрывает и точность, и интерпретируемость — а значит, и регуляторные требования к обоснованию решений, влияющих на людей.

Этапы внедрения системы прогнозирования увольнений

Внедрение начинается не с модели, а с данных: без честной картины по кадровым событиям любой прогноз останется красивой демонстрацией. Поэтому процесс идёт этапами, и на каждом фиксируем критерий приёмки — иначе непонятно, что именно передаётся в эксплуатацию.

1. Аудит данных. Собираем источники: кадровые системы, табели, оценки, историю найма и изменения грейдов. Проверяем полноту, дубли, пропуски и расхождения между системами. На выходе — карта данных с перечнем полей, которые реально доступны на момент прогноза, без утечек из будущего.
2. Разметка целевого события. Договариваемся, что считаем увольнением: добровольный уход, истечение срока, уход по инициативе компании — это разные классы. Фиксируем горизонт прогноза и окно наблюдения, чтобы модель предсказывала событие заранее, а не констатировала его постфактум.
3. Построение и валидация модели. Обучаем на исторических периодах и проверяем на более поздних — так исключаем подгонку под прошлое. Смотрим не только точность, но и полноту по группам: модель не должна «помечать» целый отдел из-за смещения в данных.
4. Пилот на ограниченной выборке. Запускаем прогноз по части подразделений и сверяем с реальными исходами. Уточняем пороги срабатывания, чтобы сигналов было достаточно для действий, но без потока ложных тревог.
5. Внедрение в рабочий контур. Встраиваем расчёт в регулярный процесс: обновление данных, выдача списка рисков ответственным, регламент работы с сигналом. Определяем, кто и в какой срок реагирует.
6. Мониторинг и переобучение. Отслеживаем долю срабатываний, качество на новых периодах и дрейф данных. При изменении структуры или рынка модель переобучается на свежем срезе.
7. Передача и сопровождение. Отдаём документацию, регламенты и доступы, обучаем команду заказчика. Дальше — плановые проверки качества и обновление модели по согласованному циклу.

Такой порядок даёт предсказуемость: на каждом шаге видно, что уже работает и где ещё есть риск. Опишите вашу задачу — вернёмся с оценкой сроков и планом по этим этапам.

Артефакты и документация, которые остаются у заказчика

Проект заканчивается не демонстрацией модели, а передачей комплекта, по которому ваша команда сможет систему эксплуатировать, проверять и развивать без нас. Для прогнозирования увольнений это критично: признаки меняются вместе с оргструктурой, а решение должно быть объяснимым для HR и юридически защищённым. Ниже — что именно остаётся у заказчика.

• Документация модели — назначение, целевая переменная (кто считается уволившимся и в каком горизонте), границы применимости и известные ограничения. Отдельным блоком — какие решения модель принимать не должна: она ранжирует риск, а не выносит кадровые вердикты.
• Схема признаков — источник каждого признака, формула расчёта, окно агрегации, обработка пропусков. Сюда же входит перечень признаков, исключённых по этическим и правовым причинам, с обоснованием.
• Конфигурации — параметры обучения, разбиение на обучающую и контрольную выборки, пороги срабатывания, настройки регулярного пересчёта.
• Регламент переобучения — триггеры (сдвиг распределения признаков, падение качества, изменение оргструктуры), периодичность, порядок валидации перед выкаткой новой версии.
• Отчёт о качестве — метрики с разделением по группам сотрудников, а не только общая цифра: полнота и точность на редком классе, калибровка вероятностей, доля ложных срабатываний.
• Воспроизводимость — зафиксированные версии данных и кода, инструкция по локальному запуску, журнал изменений модели. Любой прошлый прогноз можно пересчитать и получить тот же результат.
• Регламент мониторинга — что смотреть в проде, какие отклонения считать деградацией, кому уходит сигнал.
• Протокол передачи — обучение вашей команды, разбор инцидентов, точки расширения.

Комплект рассчитан на инженера, который не участвовал в разработке: по нему можно поднять систему с нуля, объяснить решение проверяющему и обосновать каждую рекомендацию перед сотрудником. Опишите задачу — вернёмся с оценкой и планом.

Кейс: как снизили внезапные потери в розничной сети

Что было до внедрения

Розничная сеть с текучестью персонала в магазинах: руководители точек узнавали об уходе продавца или администратора в момент заявления, а HR — постфактум, когда вакансия уже открыта. Замена сотрудника в рознице — это смена графика, обучение новичка и просадка выручки точки на период адаптации. Управляющие тонули в ручном анализе: смотрели табели, графики отпусков и жалобы, но закономерности ускользали — сигналы были размазаны по разным системам.

Что сделали

Наши инженеры собрали модель прогнозирования увольнений, которая работает на данных, уже имеющихся в контуре компании: график смен, стаж, история переводов между точками, динамика выработки, больничные, задержки и текучесть в конкретном магазине. Отдельно учли сезонность и «эффект управляющего» — в точках с высокой ротацией руководителей риск ухода выше. Модель выдаёт не абстрактный балл, а вероятность ухода в ближайшие недели с разбивкой по факторам, чтобы HR понимал, за что зацепиться в разговоре.

Метрики до и после

Срок предупреждения вырос до нескольких недель — этого хватает, чтобы подготовить замену, передать дела и не потерять выручку точки. Нагрузка на HR сместилась с ручного просмотра данных на работу с приоритетным списком: система сама подсвечивает, где риск критичен, а где можно не вмешиваться.

Что это дало бизнесу

Сеть перестала терять людей «внезапно»: уходы, которые можно было предотвратить, теперь видны заранее, а те, что неизбежны, закрываются по плану. Руководители точек получили понятный сигнал, HR — инструмент приоритизации, а бизнес — предсказуемость в графике и выручке. Модель дообучается на новых данных, поэтому точность предупреждений со временем растёт, а не деградирует.

Чем отличается прогнозирование увольнений от анализа текучести?

Анализ текучести отвечает на вопрос «что уже произошло»: считает долю ушедших за период, разбивает её по подразделениям, грейдам, стажу, сравнивает с прошлым кварталом. Это ретроспектива — отчёт по факту, где событие увольнения уже случилось и повлиять на него нельзя. Ценность такого анализа в диагностике: он показывает, где проблема хроническая, но не даёт времени на реакцию.

Прогнозная аналитика отвечает на другой вопрос — «кто уйдёт в ближайшие недели и почему». Модель оценивает каждого сотрудника по совокупности сигналов: динамика вовлечённости, изменение характера коммуникаций, переработки, паузы в активности, смена поведения в рабочих системах, история повышений и обратной связи. На выходе — вероятность ухода с горизонтом прогноза, обычно от нескольких недель до квартала. Чем короче горизонт, тем выше точность, но тем меньше времени на упреждающие меры.

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

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

Частые технические сомнения перед стартом

Сомнения обычно одни и те же: хватит ли исторических данных, не придётся ли перестраивать учёт, кто увидит персональные выводы и что будет с моделью через полгода. Ниже — как мы закрываем каждое из них на уровне архитектуры, а не обещаний.

Придётся ли менять HR-систему или заводить вторую базу?

Нет. Мы подключаемся к существующему контуру через штатные выгрузки и программные интерфейсы, которые уже поддерживает ваша система учёта. Данные забираются по расписанию, приводятся к единой схеме и складываются в отдельное хранилище — рабочая база остаётся нетронутой, нагрузка на неё не растёт. Если учёт разнесён по нескольким источникам, сводим их по устойчивому идентификатору сотрудника.

Кто получит доступ к персональным выводам?

Прогноз виден только тем ролям, которым он нужен по должности, — как правило, это HR-партнёр и прямой руководитель. Рядовые сотрудники и смежные отделы данных не видят. В интерфейсе показываем факторы риска в обезличенном виде: «смена руководителя», «отсутствие роста», а не сырые персональные записи. Все обращения к прогнозам пишутся в журнал — видно, кто и когда смотрел карточку.

Что будет с моделью, когда изменятся процессы и рынок?

Модель устаревает вместе с данными, поэтому мы закладываем контроль переобучения: раз в квартал считаем качество на свежем срезе и сравниваем с прошлым периодом. Если точность проседает, модель переобучается на актуальной истории, а старая версия остаётся для отката. Ручные корректировки HR-специалистов возвращаются в обучение как разметка — система со временем точнее отражает вашу специфику.

Опишите, какие данные и системы у вас уже есть, — вернёмся с оценкой реалистичности прогноза и планом работ.

Обсудим вашу задачу прогнозирования увольнений

Чтобы разговор был предметным, а не «расскажите про ваши задачи», полезно заранее собрать минимум вводных. Они не требуют выгрузки персональных данных — достаточно структуры и объёмов.

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

Дальше работа идёт по понятному плану. Сначала разбираем задачу и договариваемся, что считаем оттоком и какой горизонт прогноза нужен бизнесу. Затем смотрим доступные данные, оцениваем их полноту и качество — часто именно здесь выясняется, что часть признаков не собирается или собирается нерегулярно. После этого фиксируем план работ, состав модели, способ проверки качества и формат, в котором результат попадёт к руководителям. На этом этапе вы получаете оценку сроков и понимание, какие шаги зависят от нас, а какие — от готовности ваших систем.

Обсуждение занимает одну встречу: разбираем вводные, задаём уточняющие вопросы и возвращаемся с оценкой и планом. Если данных пока недостаточно, честно скажем, что нужно подготовить в первую очередь, — это тоже часть ответа.