Главная проблема поиска сотрудников — предвзятость. Порой кажется, что наше резюме подходит под свою роль на 100 %, а рекрутер отклоняет его. Проблема с противоположной стороны баррикад: рекрутер должен отсмотреть по 200, 300 и более резюме в день. По разным данным, на каждое уходит всего лишь 6–10 секунд.
А что если можно решить эти две проблемы с помощью ML? Сделать модель, которая исключит любой байес и поможет рекрутеру объективно отбирать подходящих кандидатов (где «подходящесть» обусловлена красивой математикой!).
Мы это сделали. Оказалось, что если вы хотите добиться непредвзятости, то вам придётся внести в систему предвзятость. Оксюморон в статистике!
Что мы увидели:
- Женатые и замужние — в топе: пока вы не уходите глубоко в анализ, этот быстрый фактор повышает ранг. Чем точнее ваша модель, тем меньше его вес.
- Английский — плохо: знание английского почему-то работало как антипаттерн, снижая релевантность.
- ОГУРЕЦ: кто-то зачем-то написал это слово в резюме. Оно попало в словарь модели и получило большой вес.
- Иксель — люди пишут Excel как угодно, и само слово в правильном написании оказалось снижающим оценку.
- К резюме может быть приложено много мусора. Самый эпичный пример: авиабилет Москва — Челябинск вместо резюме.
Но давайте начну с начала.
Контекст подбора в Росатом
Для Росатома нужно нанимать много людей: сейчас мы уже много чего сделали для отрасли в направлении HR Tech: собрали базу данных по кандидатам, развернули карьерный портал. Про функционал внутри него сегодня и пойдёт речь.
Мы увидели проблему: уходит какое-то нереальное количество времени на попытки понять, что в резюме кандидата совпадает с требованиями, а что — нет. Эйчары даже прикалывались, что если они ищут кандидата в своей базе, то нужно посмотреть 100 резюме, а если на Хедхантере — всего 10.
Так появился проект по прикручиванию ML-модели к внутренней базе кандидатов Skillaz для ранжирования резюме по степени сходства с требованиями.
Базовая этика
История с алгоритмом Amazon 2018 года, который дискриминировал женщин при отборе кандидатов, стала хрестоматийным примером рисков непрозрачных алгоритмов. Прежде чем приступать к оценке, мы обсудили базовые этические принципы:
- Окончательное решение — за HR-человеком, а модель лишь помогает, но не заменяет.
- Модель оптимизируется по соответствию вакансии без учёта факторов вроде долей меньшинств или категорий населения, которых нужно нанять.
- Не используем бонусных баллов за выслугу или другие факторы, учитываем только объективное соответствие вакансии.
- Для модели используем только внутренние данные — никакого парсинга соцсетей и других внешних источников.
- Добавляем метрику «Нестандартный кандидат», которая предсказывает возможную ошибку модели, если резюме не укладывается в стандартную модель.
Заказчики:
- HR-отдел. Нужен инструмент, чтобы снизить рутину и быстрее находить подходящих кандидатов из внутренней базы.
- Бизнес. Для тех, кто объявляет вакансию, важно как можно быстрее закрыть её, чтобы не тормозить процессы.
- Руководство. Как только начинается цифровизация, внимание к проекту возрастает в разы.
Как строили модель
Источником данных была наша внутренняя система Skillaz. В ней около 20 NoSQL-таблиц, описывающих заявки, кандидатов и их статусы в воронке. Информация поступала из нескольких каналов: интеграции с HeadHunter, единого карьерного портала Росатома, и немного дополнительных источников.
Проблемы начались сразу. Во-первых, не было подробного документа по структуре данных и связям между сущностями. Пришлось постоянно дёргать коллег из HR, чтобы разобраться, и параллельно самим документировать всё на ходу. Во-вторых, качество данных сильно разнилось. Резюме с HH и портала были чистыми и структурированными. А вот ручные загрузки — часто это просто текст без какого-либо шаблона.
Самой серьёзной проблемой при обработке текстовых полей резюме оказалось отсутствие единого шаблона. Люди разных профессий пишут резюме совершенно по-разному. Некоторые используют стандартные шаблоны с сайтов интернет-рекрутмента, но очень часто встречаются резюме, созданные с помощью сайтов «сделай мне красиво», которые невозможно нормально обрабатывать и разбивать на сущности. А ещё встречается откровенный мусор, о котором — ниже.
Для очистки пришлось применять стандартный набор:
- Удаление HTML, лишних пробелов и т. п.
- Лемматизация, нижний регистр (для Bag-of-Words).
- Отсечение аномально коротких (две-три строки) и длинных (10 + страниц) текстов.
- Удаление найденного мусора (вроде загруженных авиабилетов).
Критерии выбирали сами, без глубокой валидации, кроме контрольной выборки для тестов: её вычистили до блеска.
Как ранжировать — это был один из самых сложных моментов. По «похожести»? По вероятности найма?
- «Похожесть» по навыкам не взлетела: не все поля в базе были заполнены. Сравнивать нечего, когда данных нет.
- Вероятность трудоустройства — нереально: модель не видит результатов собеседований, проверок службы безопасности и других этапов.
- Вероятность согласия на собеседование — не то, что нужно HR.
После долгих обсуждений мы решили опираться на историю продвижения кандидата по воронке. В нашей базе используются статусы и связанное с ними поле order (число от 1 до 18, чем выше — тем дальше кандидат прошёл). Однако использовать бинарную метку (принят/не принят) по эталонным статусам не получилось: данных мало, классы несбалансированы, а статусы вели не всегда аккуратно.
Мы решили нормализовать значение поля order в диапазон [0, 1] и поставили задачу регрессии: предсказать это значение для каждой пары «заявка — резюме». Чем больше значение, тем выше кандидат в итоговом списке.
Алгоритмы
Мы начали с TF-IDF (Term Frequency-Inverse Document Frequency) — базового метода обработки текстов. Он представляет резюме и заявку как наборы слов, взвешивая каждое по его важности: слово тем важнее, чем чаще оно встречается в этом документе, но реже — во всех остальных документах базы. Это позволяет выделить ключевые термины. Хотя этот метод не понимает смысла или синонимов, он быстрый и часто даёт неплохой старт.
Процесс выглядел так:
- Превращали текст резюме и текст заявки в векторы TF-IDF.
- Сравнивали эти векторы через косинусное сходство: измеряли, насколько векторы «смотрят» в одну сторону. Чем ближе к единице, тем больше общих важных слов.
- Подавали эти TF-IDF-векторы (вместе с другими категориальными признаками, если таковые были) на вход классических ML-моделей (XGBoost, CatBoost), чтобы они научились предсказывать наш целевой скор order.
- Экспериментировали с Pairwise TF-IDF (специальный вариант для сравнения пар документов).
Стандартный способ формирования словаря — просто отсечь слишком частые и слишком редкие слова — показал себя плохо. В итоговом словаре оставались названия компаний, городов и всего того, из-за чего модель запоминала не навыки кандидатов, а конкретные компании. Мы пошли другим путём: выбрали только те слова (токены), частота которых коррелировала (положительно или отрицательно) с нашей целевой переменной (order). В результате это дало гораздо более чистый и релевантный словарь.
Полнота базы данных характеристик кандидатов
Полнота базы данных характеристик заявок
Полнота базы данных характеристик вакансий
Эти подходы дали какое-то базовое качество, но оно всё ещё заставляло желать лучшего. Особенно для сложных случаев, где важен не просто набор ключевых слов, а их смысл и контекст. Мы искали универсальное решение, работающее на разных типах вакансий и резюме, а TF-IDF был слишком поверхностным.
BERT-архитектуры
Нужно было научить систему понимать нюансы языка, распознавать синонимы и улавливать контекст. Например, что «ML Engineer» и «Инженер по машинному обучению» — это одно и то же, чего TF-IDF не поймёт. Мы двинулись к трансформерам, в частности, к моделям на основе BERT (Bidirectional Encoder Representations from Transformers). Это большие нейросети, предварительно обученные на гигантских объёмах текстов (Википедия, книги и т. д.). Они умеют улавливать семантические связи между словами и превращать тексты в векторы (эмбеддинги), которые отражают их смысл.
Мы попробовали разные подходы: Multilingual E5, TinyBERT, BGE-M3 и другие, ориентируясь на те, что хорошо работают с русским языком (например, по бенчмаркам encodechka).
Baseline (просто эмбеддинги). Для начала проверили, даёт ли сама по себе семантика BERT прирост по сравнению с TF-IDF. Взяли предобученную модель, получили эмбеддинги для резюме и заявки, сравнили их косинусным сходством.
Feature Extraction. Затем попробовали использовать эмбеддинги от BERT как входные признаки для XGBoost/CatBoost. Идея была в том, чтобы совместить глубокое понимание текста от нейросети с мощностью градиентного бустинга для предсказания order.
Cross Encoder (прямое сравнение парой). Подавали сцепленный текст (например, «[CLS] текст заявки [SEP] текст резюме [SEP]») прямо на вход BERT, чтобы модель сразу училась оценивать релевантность этой пары. Этот подход обычно самый точный, но он оказался слишком медленным для нашей задачи из-за большой длины резюме и заявок.
MLP поверх эмбеддингов. Получали отдельные эмбеддинги для заявки и резюме с помощью BERT, объединяли их и подавали на вход простого многослойного перцептрона, который уже предсказывал скор order.
Сиамские сети (Sentence-BERT) с Triplet Loss. Этот элегантный подход эффективен при поиске по большой базе и подходит для задач поиска и сравнения. Мы обучали две идентичные BERT-модели (сиамские близнецы) так, чтобы они генерировали эмбеддинги, где релевантные пары (подходящее резюме для заявки) располагались близко в векторном пространстве, а нерелевантные — далеко друг от друга. При дообучении BERT-моделей мы использовали техники вроде заморозки части слоёв (чтобы обучать только верхние слои: это быстрее и требует меньше ресурсов) и подбирали планировщик скорости обучения (learning rate scheduler, например, для AdamW), чтобы оно было стабильным. Из-за ограничения на длину текста (многие BERT-модели принимают до 512 токенов) мы подбирали модели, работающие до 2 048 токенов, чтобы охватить большинство резюме и заявок.
Экспериментов было много. Чтобы не потеряться, использовали MLOps-платформу ClearML: логировали все параметры, метрики и артефакты каждого эксперимента, используя систему тегов для фильтрации (bert, tfidf, cb, feature_extraction и т. д.).
Когда пришло время выбирать финальную модель, нужно было убедиться, что она будет работать быстро и стабильно в реальных условиях. Мы перевели лучшие модели в формат ONNX, запаковали их в Docker-контейнеры с такими же ограничениями ресурсов, как на проде, и провели нагрузочное тестирование с помощью Locust. Это помогло понять реальную производительность и требования к инфраструктуре.
После всех тестов и сравнений по нашей кастомной метрике лучшим компромиссом между качеством понимания текста, скоростью работы и ресурсоёмкостью оказалась архитектура на основе дообученного Tiny Sentence BERT с небольшим MLP поверх эмбеддингов. Она достаточно хорошо понимала семантику, работала быстро и создавала не слишком большие эмбеддинги, что было удобно для хранения и поиска.
Ранжирование
Стандартные метрики ранжирования нам не подошли, т. к.:
- По многим заявкам данных было откровенно мало.
- Проблема ничьих: часто у нескольких кандидатов была одинаковая истинная оценка, и тогда метрика (то есть порядок рекомендаций для эйчара) зависела от случайного порядка этих кандидатов.
Мы разработали свою метрику, которую внутренне назвали SmartAdaptPrecision@K. Наша метрика сравнивает топ предсказанных и топ эталонных кандидатов, но обходит проблему ничьих. Если у нескольких кандидатов одинаковый ранг, то метрика не просто тупо считает совпадения, а аналитически вычисляет вероятность совпадения, учитывая количество кандидатов с одинаковыми рангами.
Это делает оценку стабильной: каждый запуск выдаёт один и тот же результат, даже если кандидаты с равными баллами случайно меняются местами. Результат нормализуется от нуля до единицы с помощью стандартной min-max-нормализации. Чем ближе результат к единице — тем точнее модель отражает истинное ранжирование рейтинга кандидатов.
Модель vs эйчары
Разработав и обучив модель, мы перешли к сравнению её с людьми. Сделали так:
- Отобрали в базе ~ 10 исторических заявок из разных специализаций с сотней резюме, тщательно почистили.
- Привлекли рекрутеров, специализирующихся на разных направлениях, включая ИТ и массовый подбор.
- Каждому HR дали набор заявок (часть — из их профильной области, часть — из чужой) и список кандидатов к ним (без реальных итогов). Им было нужно выбрать топ-5 и отранжировать его по приоритету.
- Параллельно на тех же данных запустили нашу модель.
- Сравнили ранжирование модели и каждого HR с историческим эталоном.
Получилось так, что наша моделька в среднем отработала чуть хуже, чем HR-специалист в своей категории: модель — 78 %, профильный HR из отрасли — 84 %. Но модель показала себя лучше, чем средний кадровик на чужой территории, где точность не превышает 70 %. Другими словами, модель не превосходит узкого специалиста на его поле, но стабильно держит хороший уровень по всем направлениям и помогает там, где у человека нет глубокой экспертизы. Это подтверждает её ценность.
Работает, но местами костыльно
Сейчас HR-рутина автоматизирована, и система исправно выдаёт рекомендацию в виде ранга подходящих кандидатов из внутренней базы. Сейчас модель пока стоит «немножко сбоку» от основной базы данных, из-за этого пользоваться ею не очень удобно. Но полноценная интеграция — впереди.
Мы собираем обратную связь от HR. Массовую аналитику и ROI будем считать после полной интеграции, когда системой начнут активно пользоваться. Но первые отзывы — позитивные: рекрутеры отмечают, что стало проще находить релевантных кандидатов и сократилось время подбора — не кардинально, но ощутимо. Точные цифры обязательно приведём в следующей статье, когда отработаем на больших данных.
Теперь думаем над тем, как всё это улучшить. Вот наш ту-ду-лист:
- Полноценная интеграция модели в основную HR-систему.
- Улучшение качества исторических данных и процессов.
- Тест LLM для анализа текстов резюме и вакансий — если пройдём по экономике и безопасности.
- Расчёт реальной экономии времени и денег после внедрения.
- Отладка метрик, по которым HR-специалисты смогут понимать, почему модель выдала те или иные рекомендации.
Если у вас был опыт внедрения похожих систем — расскажите: что ждёт нас дальше? Что у вас сработало, а что — нет? Какие подводные камни появились после интеграции? Мы будем рады обсудить это в комментариях.
Комментарии (20)
Zara6502
17.06.2025 07:46мне кажется подбор персонала по резюме это оксюморон, так как система легко ломается когда кандидаты знают об этом (а в РФ уже наступила эпоха, когда кандидаты это знают, например в 90-е было забавно читать истории трудоустройства в США, когда люди платили деньги компаниям которые составляли резюме).
Соответственно систем опирающаяся на резюме автоматически рождает три их вида:
Резюме полное, но содержит исключительно удобную для HR информацию, сам кандидат не имеет нужных навыков;
Резюме полное, не содержит нужной информации для HR, сам кандидат не имеет нужных навыков;
Резюме полное, содержит удобную информацию для HR, сам кандидат имеет нужные навыки;
Резюме полное, не содержит нужной информации для HR, сам кандидат имеет нужные навыки;
То же самое для неполного резюме. В итоге мы имеем только 25% удобный вход. У вас 75% мусора и каждый второй специалист отсеивается, хотя он бы подошёл.
Это всё конечно грубо, но думая сама мысль понятна.
Для меня показательной деградацией современного корпоративного HR стала попытка трудоустройства в Дом.ру примерно в 2010 году. Когда меня сначала посадили в общий зал, мы там должны были в игровой форме разговаривать друг с другом (я просто игнорировал), был один "ведущий" и один специалист что-то фиксировал. Потом я прошёл предварительное собеседование, в основном у меня спрашивали какие-то общие вопросы и что-то про мои увлечения. Потом через 2-3 дня пригласили на тестирование онлайн, меня посадили за ПК и я прошёл тест через вэб-форму. Так как я уже не хотел тут работать (это же какой-то дом сумасшедших), то я был не искренен в ответах. Но и там не было ни одного вопроса по Linux, AD, Windows, TCP/IP и т.п. Там всё так же были вопросы поведенческого профиля и т.п. ерунда. Еще через пару дней меня пригласили на собеседование к профильному специалисту, это был непосредственный начальник. С порога он спросил - смогу ли я администрировать почтовый сервер на FreeBSD, я ответил что нет. Собеседование закончилось. А теперь давайте посчитаем сколько денег в месяц тратится на HR и сколько времени убивается на эти бесполезные мероприятия вместо того, чтобы 1) в вакансии указать правильно требования, 2) после короткого звонка от HR чтобы я так же по телефону прошел быстрое собеседование с профильным специалистом.
Молчу о том сколько хороших специалистов просто не имеют "удобного" для HR резюме.
pnmv
17.06.2025 07:46что означает "полное/неполное резюме"?
Zara6502
17.06.2025 07:46Как сам автор пишет об этом:
Самой серьёзной проблемой при обработке текстовых полей резюме оказалось отсутствие единого шаблона. Люди разных профессий пишут резюме совершенно по-разному. Некоторые используют стандартные шаблоны с сайтов интернет-рекрутмента, но очень часто встречаются резюме, созданные с помощью сайтов «сделай мне красиво», которые невозможно нормально обрабатывать и разбивать на сущности. А ещё встречается откровенный мусор, о котором — ниже.
то есть резюме полное, когда любая система или сам специалист OK получают из него исчерпывающую информацию.
например я никогда не пишу информацию о своих достижениях на прошлом месте работы, так как не вижу в этой информации никакого практического смысла. Меня нанимают на работу выполнять задачи по должностной инструкции, а не креативно создавать контент. Я в жизни еще ни разу ни на одной работе не делал что-то, что совпадало бы с работой на предыдущем месте, даже если например какой-то навык и пригождался. Базовые навыки я не учитываю, так как без них вы в принципе не сможете работать.
pnmv
17.06.2025 07:46с общими фразами я и так знаком. думал, существует какая-нибудь конкретика.
несколько лет назад, постарался, прикинул, что к чему, составил себе отдельное "продающее резюме". хватило на полтора трудоустройства. но, пока я работал на тех работах, подход перестал работать. откликов, всё ещё, собирает больше, чем любые другие потуги, но предложений поработать маловато.
Zara6502
17.06.2025 07:46а я совсем не знаю что нужно написать в резюме чтобы прилетело предложение о работе, мне кажется это сугубо привилегия определенных специалистов, которых "днём с огнём". ну и с другой стороны я никогда о себе не пишу ничего, что делать не умею, но что прибавило бы мне очков. а запихать в резюме всё что я умею - это бумаги не хватит.
pnmv
17.06.2025 07:46длинные резюме не читают (очень быстро устают), но если написано мало, тоже, сразу отказ. вот, поиск золотой середины - это самое трудное. сильно больше, чем пресловутое "O(n)".
ksidorov Автор
17.06.2025 07:46Согласен, что опора только на резюме — неэффективна, и в лучшем случае это лишь первый фильтр для HR, позволяющий быстро обработать большой поток откликов.
Лучшие практики подбора персонала сегодня включают несколько этапов: короткое телефонное интервью, техническое тестирование, а затем уже встречу с руководителем. Такой подход помогает снизить "шум" и быстрее находить подходящих кандидатов, не теряя сильных специалистов из-за формальностей. Современные компании всё чаще внедряют именно такие многоступенчатые процессы, чтобы повысить эффективность отбора и не упустить ценных кандидатов.
Zara6502
17.06.2025 07:46и в лучшем случае это лишь первый фильтр для HR, позволяющий быстро обработать большой поток откликов
так он же неэффективный абсолютно, он опирается на ошибочную предпосылку о том, что все резюме всех кандидатов обладают исчерпывающей и главное правдивой информацией.
короткое телефонное интервью
почти всегда бесполезно, так как это телефонная версия резюме, проблема здесь в том, что вас фильтрует человек который вас не нанимает, это просто говорящая голова почему-то наделённая сверхполномочиями.
техническое тестирование
а это зависит от самой специальности, например хирурга так желательно протестировать, но я скорее всего ни один тест не пройду, так как я учился в 90-е и на планете немножко всё поменялось и я уже давно забыл теорию, а практика такова, что при тестировании не спрашивают о том, с чем ты будешь работать. В общем я к таким проверкам отношусь скептически.
а затем уже встречу с руководителем
Я вырос в эпоху без HR и я много сам оформлял вакансии и проводил собеседования и пока я не увидел чтобы HR в этом направлении сделал что-то полезное. А вот в вопросе релокации кандидатов, помощи с визами, квартирами и т.п. - это да, незаменимые люди.
Такой подход помогает снизить "шум" и быстрее находить подходящих кандидатов, не теряя сильных специалистов из-за формальностей
очень сомневаюсь. так как сильные специалисты это скорее всего штучный товар, то знать вы их будете пофамильно и заранее, нежели выбирать из кучи резюме. У таких еще и публикации скорее всего будут, а может и ученая степень.
Современные компании всё чаще внедряют именно такие многоступенчатые процессы, чтобы повысить эффективность отбора и не упустить ценных кандидатов.
пока я не видел убедительных доводов в защиту этого.
я самолично брал на работу людей с минимумов знаний только потому что в процессе собеседования я от них получал обратную реакцию, замечал пытливый ум, сообразительность, умение решать задачи и т.п. Это сильно эффективнее чем изучение холодных резюме девочками очень далекими от профессии. Последний кандидат которого я нанимал имел 9 классов образования и какой-то колледж за плечами. Сейчас он имеет высшее образование и работает на моей должности (я оттуда ушёл). И учитывая что он младше меня на 20 лет, то я уверен что еще через 5 лет он будет лучше меня по основным направлениям. Такой кандидат не прошёл бы через HR.
PS: не слишком по теме - еще лет 7 назад, когда я стал подбираться к 45 мне отказали в трудоустройстве, где я подходил на почти 90%. В моей практике это было впервые (если что у меня трудовая уже на три вкладыша). Я смог разговорить девушку из ОК и она сказала, что в моём возрасте я представляю большие риски для компании, так как мне уже скоро на пенсию. XD
vadimr
17.06.2025 07:46Английский — плохо: знание английского почему-то работало как антипаттерн, снижая релевантность.
Ну так если нечего написать о профессиональных достижениях, релевантных для Росатома, то человек пишет про английский язык, права категории B и прочую фигню. А когда объём резюме ограничен, то более значительные достижения вытесняют менее значительные.
Другое дело, если б человек в филиал американской фирмы устраивался, там бы английский, вероятно, не имел отрицательного веса.
ksidorov Автор
17.06.2025 07:46Разные профессии требуют учёта различных критериев и информации при подборе персонала. Нужно разделять резюме кандидатов на кластеры по профобластям и строить алгоритмы, которые учитывают специфику каждой сферы. Это позволяет учитывать реально важное инфо и отбраковывать инфомусор.
Знание английского языка или водительские права вполне могут быть критичны для каких-то вакансий. Для других — "ну пригодится". А для третьих — это излишки. Гибкие и адаптированные алгоритмы помогают повысить точность отбора и сделать процесс подбора более эффективным и, скажем так, "справедливым".
Edwward
17.06.2025 07:46Можете привести конкретные примеры? По каким параметрам модель решает подходит ли кандидат или нет? Несколько псевдореальных резюме, для примера, и как модель их отработает? Пока у меня "ощущение", что это "алгортим ради алгоритма". В реальности Ваша система будет отбирать "гладкие" резюме, написанные LLM.
ksidorov Автор
17.06.2025 07:46Получилось так, что наша моделька в среднем отработала чуть хуже, чем HR-специалист в своей категории: модель — 78 %, профильный HR из отрасли — 84 %. Но модель показала себя лучше, чем средний кадровик на чужой территории, где точность не превышает 70 %. Другими словами, модель не превосходит узкого специалиста на его поле, но стабильно держит хороший уровень по всем направлениям и помогает там, где у человека нет глубокой экспертизы. Это подтверждает её ценность.
Модель сравнивали с реальными HR-специалистами: по точности ранжирования модель немного уступает профильному HR (78% против 84%), но стабильно лучше справляется, чем HR вне своей специализации (около 70%).
Модель действительно может отдавать предпочтение "гладким" резюме, особенно если они написаны с учётом ключевых слов и современных шаблонов, в том числе с помощью LLM.
Можно дополнительно использовать LLM для выявления "слишком шаблонных" резюме (например, если текст совпадает с популярными шаблонами или сгенерирован LLM). Но это TODO задача, на данный момент не так много кандидатов пользуются этим инструментом
adminNiochen
17.06.2025 07:46Нанимать в ядерные технологии, доверяя аишке - это надо быть мегамозгом конечно. Надеюсь ума хватит хотя бы код для реакторов из чата гпт не копипастить.
onets
17.06.2025 07:46С наступлением эпохи рынка работодателя такое станет еще популярнее. См ATS системы.
Но ее можно немного обмануть - белым цветом шрифта на белом фоне вписать синонимы и некоторые другие ключевые слова - для человека неочевидно, но система распарсит.
В некоторых случаях лучше ее обманывать - я встречал ошибки в вакансии. Например postgre или postgres вместо postgresql. Но в моем-то резюме правильно написано.
vlk1
17.06.2025 07:46Лет пять назад успешно прошел два собеса в РА, но для непосредственного приема они требовали от руки написанную автобиографию. Почуяв неладное я пошел в другое место. После этой статьи вектор развития их hr технологий меня несколько пугает)
avshkol
17.06.2025 07:46Интересное исследование.
1) Если ОГУРЕЦ получил большой вес, но, очевидно, использовался один раз у того, кто прошел отбор, не лежат ли в модели еще какие-то редкие Cobol-ы, которые случайно тоже получили большой вес (но HR часто не может понять, чем кобол от питона отличается...)?
2) Вы учили на тех, кто прошел отбор и зачислен в штат или на тех, кто в принципе одобрен, но не зачислен (например, искали одного человека, пришло 10, из которых в принципе подходят 4, но взяли только одного, ибо одна вакансия - тогда не искажают ли 3 подходящих, но неприятных, модель???)
Edwward
17.06.2025 07:46Спасибо за ответ. Но я ничего не понял. 84 % - это что? По каким критериям? И какой размер выборки? Как сравниваются резюме? Покажите на примере. И какой ожидаемый экономический эффект?
Вас обязательно ожидают подобные вопросы. И что бы Ваш проект не закрыли, и "дали денех" на дальнейшее развитие, Вы должны ответить четко на два вопроса :
Как это работает?
Сколько принесет денег?
Ответы должны быть такие, что бы "бабушка с Дормидонтовки" поняла. И пожалуйста, без процентов, в отрыве от реальных количеств( резюме в метрах, деньги в мешках)).
Не воспринимайте мои комментарии негативно. Вы пытаетесь решить очень сложную задачу( а решаема ли она вообще?). Я пытаюсь понять. Не одну тысячу резюме просмотрел.
CBET_TbMbI
Зашёл почитать про огурец в резюме, а тема огурца оказалась не раскрыта:(