Алексей Осипов
Руководитель группы разработки
Меня зовут Алексей, я развиваю направление искусственного интеллекта и машинного обучения в ГК Юзтех. В этой статье я расскажу о полезном инструменте для рекрутеров, который реализовала наша ML-команда. Теперь наши HR-специалисты не тратят кучу времени на поиск по фильтрам, а доверяют сервису, который за секунды выполняет поиск по базе из 300 000 кандидатов.
Про исследования и проблемы найма
Конкуренция на рынке труда достигает небывалых масштабов, крупные компании получают сотни, а порой и тысячи резюме на каждую открытую вакансию. Нагрузка на HR-отдел экстремальная, специалисты вынуждены вручную просматривать каждое резюме, анализируя опыт, навыки и соответствие требованиям вакансии.
По данным Хантфлоу скрининг резюме опытным рекрутером составляет около 5–10 секунд. Рекрутеру с меньшей осведомленностью понадобится около минуты. Несложно подсчитать, что, если на вакансию получено около 100 резюме, время на первичный отбор занимает от 15 минут до 100 минут. Однако, если рассматривать нестандартные вакансии по разработке узкоспециализированных систем, HR тратит около 10 минут на изучение, а это почти 17 часов на 100 резюме.
Немного о задаче
У нашей компании есть база данных, где хранится несколько сотен тысяч резюме кандидатов, сориентироваться в этой базе HR-специалисту достаточно сложно. Мы решили освободить наших коллег от рутинных операций поиска и разработать систему интеллектуального поиска резюме. Основные критерии для сервиса – удобство, быстрота и симпатичный интерфейс. Инструмент для поиска кандидата на вакансию должен значительно экономить время специалистов и делать их работу проще.
Что хотели получить HR-специалисты?
Рекрутер задает запрос в свободной форме, например, “разработчик Python с опытом работы в финтехе более 2-х лет”, или просто указывает набор ключевых слов – “data science, machine learning, TensorFlow”. Сервис обрабатывает запрос за пару секунд и выдает результат – список наиболее подходящих кандидатов на вакансию.
В итоге, мы определили основные требования к нашей системе:
-
На вход система должна принимать запрос на специалиста в произвольной текстовой форме (на русском, английском и их смеси).
-
Система должна выдавать упорядоченный короткий список кандидатов (вплоть до 1000 человек), удовлетворяющих запросу, при этом каждому кандидату сопоставляется процент релевантности.
-
Для процента релевантности запросу должна предоставляться интерпретация, т.е. реализована разбивка на составляющие: навыки, специальность, образование, компания, локация и др.
С командой мы решили сделать еще одну функциональную возможность – поиск похожих кандидатов. То есть рекрутер загружает резюме идеально подходящего кандидата на платформу, сервис анализирует его содержание, выделяет ключевые параметры и на основе анализа подбирает кандидатов с максимально схожим профилем.
Схема решения
Наше решение состоит из компонент, указанных на схеме ниже.
-
парсер резюме
-
парсер запросов
-
фильтрация
-
скоринг
Основная логика сервиса может быть разбита на 4 ключевые блока, рассмотрим каждый из них более подробно.
Парсер резюме
Задача парсера состоит в выделении нескольких десятков признаков из резюме. Эти признаки используются как в системе моделей, так и выводятся на UI. Для простых признаков, вроде занятости, мы использовали регулярные выражения. Для более сложных признаков, вроде компаний, в которых работал кандидат, использовали NER-модели, для уточнения признаков – LLM. LLM использовался, например, в тех случаях, когда мы не смогли определить пол кандидата обычными методами.
Парсинг резюме в системе запускается только для новых резюме и происходит ночью. Кроме того, в конце парсинга создаются и обновляются определённые структуры, для того чтобы последующий поиск был более эффективным и можно было быстро найти кандидатов, например, владеющих Pega, или работавших на Мосбиржу.
Стоит отметить, что не все резюме легко распарсить даже человеку:
В Хантфлоу резюме попадают из самых разных систем, и в некоторых случаях слова склеиваются. Кроме того, бывает, что в систему резюме загружают вручную, что может создавать ещё бОльшие проблемы, так в раздел “О себе” может попасть практически всё резюме.
Парсер запросов
Задача данного парсера состоит в выделении ключевых требований из запроса. Основная ставка делается на выделение ключевых навыков, однако также мы выделяем специальность кандидата, грейд кандидата, компанию, в которую ищут сотрудника, а также ряд других факторов. В парсере активно используется LLM. Парсер способен эффективно работать с запросами разной длины от одного слова до pdf-файла из нескольких страниц. Функциональность поиска похожих кандидатов экономит кучу времени. Запрос на поиск похожего специалиста с резюме из 6 страниц сжимается до 3 строк. LLM извлекает важные параметры и система ищет в базе данных кандидатов с максимально схожим профилем, предлагая релевантный список альтернативных вариантов.
Запрос может быть в любой форме, однако не на все запросы можно будет найти кандидатов.
Фильтрация
База данных нашей компании содержит несколько сотен тысяч кандидатов. Большинство из них нет никакого смысла скорить на конкретную вакансию. Если рекрутеры ищут Backend-разработчика, то нет смысла рассматривать тестировщиков. Поэтому мы разработали классификационные модели, которые определяют специализацию кандидата (пара десятков специализаций), а также грейд кандидата. Далее происходит фильтрация кандидатов – оставляем только тех, чья специализация соответствует специализации запроса, и чей грейд не сильно отличается от грейда запроса.
На этом же этапе фильтрации с помощью LLM определяется ведущий навык. Мы сталкивались с ситуацией, когда количество кандидатов, удовлетворяющих всем фильтрам слишком мало, тогда фильтрация по специализации и грейду отключается, происходит поиск по всем кандидатам, обладающих ведущим навыком. Специализации и грейды кандидатов определяются в конце парсинга резюме ночью, когда готовится база, поэтому фильтрация происходит за считанные секунды.
Скоринг
На этапе скоринга просчитывается процент соответствия кандидата вакансии. Состоит он из нескольких компонент:
-
скор по ключевым словам
-
скор по образованию
-
скор по компании
-
скор по грейду
-
скор по специализации
-
и еще скор, скор, скор по другим параметрам
Это самый длительный этап поиска в цепочке, весь поиск в среднем занимает около минуты. С одной стороны, нам необходимо сделать так, чтобы скоры считались максимально быстро, а с другой стороны, чтобы они были максимально интерпретируемыми, как и финальный процент соответствия вакансии.
В первой версии прототипа скор мог быть выше 100%.
Эволюция сервиса
Наш первый прототип был сделан на shiny, процент соответствия был произвольным числом, мы не следили за форматированием, поиск производился примерно за 3 минуты.
Со временем наш UI эволюционировал в Swagger.
А наш сервис стал частью большого приложения, где поиск выполняется за минуту, нет проблем с форматированием, а процент соответствия не может быть больше 100%.
Вместо заключения
Созданный нами сервис для рекрутеров анализирует данные о кандидатах, подбирает релевантные резюме даже на специфические вакансии, минимизирует влияние человеческих предвзятостей. Сервис тратит секунды на поиск 100 релевантных кандидатов по базе из 300 000 кандидатов на позицию, а наши HR-специалисты не страдают от рутинного поиска, а уделяют еще больше внимания поддержанию корпоративной культуры и мотивации в нашей компании.
И кстати, с помощью сервиса по поиску кандидатов мы нашли классного ML-разработчика к нам в команду!
Автор: Usetech
