Pull to refresh

Comments 19

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

Допустим, получившийся продукт (действительно достойный) отправляется в промышленную эксплуатацию. То есть каждое поступающее резюме пропускается через этот кластеризатор, и первичное решение по нему принимается автоматически. Дальше уже оно или отправляется соответствующему специалисту с пометкой «hot», или засовывается в долгий ящик. Если в долгий ящик, то скорее всего это резюме ни один живой человек никогда глазами не увидит. Если алгоритм тупанул, триггернулся не на то, на что следовало (например, человек работал в клининговой фирме «Квант добра», и его классифицируют как физика-теоретика, со всеми вытекающими), то результативность резюме тоже существенно пострадает. Из функционирования ключевого бизнес-процесса исключается человеческий фактор, и как общий результат имеем то, что дела начинают делаться… как-то не по-человечески.

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

P.S. Пример про «Квант добра» выдуман, но по мотивам реальных событий. Раз в несколько дней мне, программисту, до сих пор от одного горемычного роботизированного хедхантера прилетает список свежих вакансий крановщиков и трактористов.
Мало вероятно, что проект будет развиваться по такому пути. Он скорее подходит для получения общей картины, чтобы, например, можно было поддерживать каталог специализаций в актуальном состоянии. Т.е. отдельные резюме не пострадают
Вопрос времени. Конкретно этот проект может быть и не станет поворотной точкой, но общая тенденция (не только в рекрутинге, но и почти везде) имеет место, и против неё грести весьма проблематично.
Есть ли код на гитхабе и данные, которые он использует, чтобы провести собственные эксперименты?
Всё равно есть потенциальные риски каких-нибудь ликов. Плюс у нас есть коммерческие услуги по анализу данных резюме. Так что для публикации должен понабиться очень особый повод. Например, несколько лет назад проводился хакатон, где что-то предсказывали по резюме. Вероятно, где-то в сети можно найти с него данные
Т.е. для того чтобы воспроизвести результаты из статьи мне потребуется купить доступ к базе резюме, и спарсить их? Или есть какой-то более удачный способ?
Парсить базу резюме на hh.ru тоже нельзя. Скорее всего акой пользователь будет заблокирован.
Отличная работа и очень грамотный последовательный стиль изложения. Побольше бы таких статей на Хабре.
Была бы карма, плюсанул бы с удовольствием.
Спасибо за статью. Давно интересуюсь вопросом, но с другой стороны.

Судя по всему, сейчас HR всё чаще применяют автоматическую обработку резюме. Проект описанный в данной статье — один из примеров.

А есть где-то открытые сервисы, хоть как-то приближённые к реальным, чтобы проверить свое резюме? Цель — подкорректировать резюме так, чтобы авто-парсер выдавал то, что я хотел донести, и чтобы резюме не было отсеяно по ошибке.
Сомневаюсь, что такие есть. Каждый алгоритм уникален и кто знает, что он куда отнесет. Я бы советовал просто заполнять резюме максимально релевантно тому, чем собираетесь заниматься
Не очень понятно зачем вам это. Насколько я понимаю логику работы ATS систем — они матчат резюме с описанием позиции и строят сортированный шортлист кандидатов. Что бы вы там не хотели донести, если данные вашего резюме не бьются с описанием позиции — его просто никто никогда не увидит. Вот есть такая тулза для быстрой проверки: www.jobscan.co

Я как-то писал подобную тулзу, которая тупо делала из резюме и позиции вектора ключевых слов и сравнивала их на cosine similarity — результат, кстати, весьма неплох был.
Что касается логики — вот их уже две:
1. Сравнение ключевых слов в резюме с ключевыми словами в описании позиции
2. Кластеризация слов по примеру как описано в этой статье

При этом еще могут быть вариации. Например, в первом случае при сравнении можно учитывать базу данных синонимов (я, кстати, что-то похожее делал, только для других целей). А если скомбинировать два способа, то можно выявить специализацию кандидата в резюме, целевую специализацию в описании позиции, и потом ранжировать кандидатов в зависимости от того, насколько они близко к целевой специализации. «Девиации» от основной специализации могут трактоваться как в плюс так и в минус кандидату. А если алгоритмы основываются на алгоритмах машинного обучения, то еще важно на каких данных была натренирована система.

Наверняка есть и другие идеи.

За www.jobscan.co спасибо. Буду пользоваться.

Если еще есть что-то на примете — делитесь.
Теперь имеет смысл перевести данные в пространство меньшей размерности, чтобы в дальнейшем алгоритм кластеризации смог их переварить за приемлемые время и память.
Не могли бы Вы пояснить, зачем снижать размерность? Ведь алгоритмическая сложность кластеризации зависит только от числа элементов (резюме), а не числа признаков у них. Число признаков влияет на время расчета расстояний между парами элементов, но всего лишь линейно, да и время требуемое на снижение размерности (Truncated SVD) все равно будет больше, чем выигрыш от «облегчения» функции расстояний.
Отличный вопрос. Кажется, вы правы. Я об этом не подумал. Надо будет проверить
Интересно было бы посмотреть кластеризацию вакансий в области ИТ по скилам, можно увидеть какие скилы люди набирают наиболее часто, а какие отстают в развитии.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
hh.ru
Employees
501–1,000 employees
Registered