Скрининг, который не теряет сильных кандидатов в потоке откликов

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

Дальше текст резюме нужно превратить в данные. Здесь работает связка извлечения и нормализации: языковая модель вытаскивает из свободного текста периоды, компании, проекты и технологии, а справочник навыков приводит их к единым названиям. Без справочника модель будет считать «PostgreSQL» и «Postgres» разными навыками, а «1С:УПП» и «1С УПП 8.3» — несовместимыми. Нормализованные данные сравниваются с профилем, и на выходе рекрутер получает не оценку «подходит/не подходит», а обоснованный список с указанием выполненных и невыполненных требований.

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

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

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

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