Комментарии 19
Отличное описание реального применения!
Недавно столкнулся с похожей задачей. По-моему, проблему большого количества данных можно решать путём объединения (слияния) отдельных сэмплов, расстояние между которыми близко к нулю.
Недавно столкнулся с похожей задачей. По-моему, проблему большого количества данных можно решать путём объединения (слияния) отдельных сэмплов, расстояние между которыми близко к нулю.
Классная работа, но наталкивает на грустные размышления.
Допустим, получившийся продукт (действительно достойный) отправляется в промышленную эксплуатацию. То есть каждое поступающее резюме пропускается через этот кластеризатор, и первичное решение по нему принимается автоматически. Дальше уже оно или отправляется соответствующему специалисту с пометкой «hot», или засовывается в долгий ящик. Если в долгий ящик, то скорее всего это резюме ни один живой человек никогда глазами не увидит. Если алгоритм тупанул, триггернулся не на то, на что следовало (например, человек работал в клининговой фирме «Квант добра», и его классифицируют как физика-теоретика, со всеми вытекающими), то результативность резюме тоже существенно пострадает. Из функционирования ключевого бизнес-процесса исключается человеческий фактор, и как общий результат имеем то, что дела начинают делаться… как-то не по-человечески.
Мы живые люди. Нам время от времени приходится взаимодействовать с крупными структурами. По разным своим житейским ситуациям. В частности, искать работу. Или брать кредит. Или чинить холодильник. Или устраивать ребёнка в садик. Всё больше приходим к тому, что везде будет радикально повышена эффективность, отовсюду исключён человеческий фактор. Однажды проснувшись, мы обнаружим себя в мире, в котором буквально всё делается не по-человечески. В кафкианском «Замке» мирового масштаба.
P.S. Пример про «Квант добра» выдуман, но по мотивам реальных событий. Раз в несколько дней мне, программисту, до сих пор от одного горемычного роботизированного хедхантера прилетает список свежих вакансий крановщиков и трактористов.
Допустим, получившийся продукт (действительно достойный) отправляется в промышленную эксплуатацию. То есть каждое поступающее резюме пропускается через этот кластеризатор, и первичное решение по нему принимается автоматически. Дальше уже оно или отправляется соответствующему специалисту с пометкой «hot», или засовывается в долгий ящик. Если в долгий ящик, то скорее всего это резюме ни один живой человек никогда глазами не увидит. Если алгоритм тупанул, триггернулся не на то, на что следовало (например, человек работал в клининговой фирме «Квант добра», и его классифицируют как физика-теоретика, со всеми вытекающими), то результативность резюме тоже существенно пострадает. Из функционирования ключевого бизнес-процесса исключается человеческий фактор, и как общий результат имеем то, что дела начинают делаться… как-то не по-человечески.
Мы живые люди. Нам время от времени приходится взаимодействовать с крупными структурами. По разным своим житейским ситуациям. В частности, искать работу. Или брать кредит. Или чинить холодильник. Или устраивать ребёнка в садик. Всё больше приходим к тому, что везде будет радикально повышена эффективность, отовсюду исключён человеческий фактор. Однажды проснувшись, мы обнаружим себя в мире, в котором буквально всё делается не по-человечески. В кафкианском «Замке» мирового масштаба.
P.S. Пример про «Квант добра» выдуман, но по мотивам реальных событий. Раз в несколько дней мне, программисту, до сих пор от одного горемычного роботизированного хедхантера прилетает список свежих вакансий крановщиков и трактористов.
Есть ли код на гитхабе и данные, которые он использует, чтобы провести собственные эксперименты?
Ноутбуки с подготовкой данных и кластеризацией выложил. Выкладывать не планировал, поэтому в коде есть лишнее. Данные резюме мне выложить не позволят.
… даже если их обезличить?
Всё равно есть потенциальные риски каких-нибудь ликов. Плюс у нас есть коммерческие услуги по анализу данных резюме. Так что для публикации должен понабиться очень особый повод. Например, несколько лет назад проводился хакатон, где что-то предсказывали по резюме. Вероятно, где-то в сети можно найти с него данные
Отличная работа и очень грамотный последовательный стиль изложения. Побольше бы таких статей на Хабре.
Была бы карма, плюсанул бы с удовольствием.
Была бы карма, плюсанул бы с удовольствием.
Спасибо за статью. Давно интересуюсь вопросом, но с другой стороны.
Судя по всему, сейчас HR всё чаще применяют автоматическую обработку резюме. Проект описанный в данной статье — один из примеров.
А есть где-то открытые сервисы, хоть как-то приближённые к реальным, чтобы проверить свое резюме? Цель — подкорректировать резюме так, чтобы авто-парсер выдавал то, что я хотел донести, и чтобы резюме не было отсеяно по ошибке.
Судя по всему, сейчас HR всё чаще применяют автоматическую обработку резюме. Проект описанный в данной статье — один из примеров.
А есть где-то открытые сервисы, хоть как-то приближённые к реальным, чтобы проверить свое резюме? Цель — подкорректировать резюме так, чтобы авто-парсер выдавал то, что я хотел донести, и чтобы резюме не было отсеяно по ошибке.
Сомневаюсь, что такие есть. Каждый алгоритм уникален и кто знает, что он куда отнесет. Я бы советовал просто заполнять резюме максимально релевантно тому, чем собираетесь заниматься
Не очень понятно зачем вам это. Насколько я понимаю логику работы ATS систем — они матчат резюме с описанием позиции и строят сортированный шортлист кандидатов. Что бы вы там не хотели донести, если данные вашего резюме не бьются с описанием позиции — его просто никто никогда не увидит. Вот есть такая тулза для быстрой проверки: www.jobscan.co
Я как-то писал подобную тулзу, которая тупо делала из резюме и позиции вектора ключевых слов и сравнивала их на cosine similarity — результат, кстати, весьма неплох был.
Я как-то писал подобную тулзу, которая тупо делала из резюме и позиции вектора ключевых слов и сравнивала их на cosine similarity — результат, кстати, весьма неплох был.
Что касается логики — вот их уже две:
1. Сравнение ключевых слов в резюме с ключевыми словами в описании позиции
2. Кластеризация слов по примеру как описано в этой статье
При этом еще могут быть вариации. Например, в первом случае при сравнении можно учитывать базу данных синонимов (я, кстати, что-то похожее делал, только для других целей). А если скомбинировать два способа, то можно выявить специализацию кандидата в резюме, целевую специализацию в описании позиции, и потом ранжировать кандидатов в зависимости от того, насколько они близко к целевой специализации. «Девиации» от основной специализации могут трактоваться как в плюс так и в минус кандидату. А если алгоритмы основываются на алгоритмах машинного обучения, то еще важно на каких данных была натренирована система.
Наверняка есть и другие идеи.
За www.jobscan.co спасибо. Буду пользоваться.
Если еще есть что-то на примете — делитесь.
1. Сравнение ключевых слов в резюме с ключевыми словами в описании позиции
2. Кластеризация слов по примеру как описано в этой статье
При этом еще могут быть вариации. Например, в первом случае при сравнении можно учитывать базу данных синонимов (я, кстати, что-то похожее делал, только для других целей). А если скомбинировать два способа, то можно выявить специализацию кандидата в резюме, целевую специализацию в описании позиции, и потом ранжировать кандидатов в зависимости от того, насколько они близко к целевой специализации. «Девиации» от основной специализации могут трактоваться как в плюс так и в минус кандидату. А если алгоритмы основываются на алгоритмах машинного обучения, то еще важно на каких данных была натренирована система.
Наверняка есть и другие идеи.
За www.jobscan.co спасибо. Буду пользоваться.
Если еще есть что-то на примете — делитесь.
Теперь имеет смысл перевести данные в пространство меньшей размерности, чтобы в дальнейшем алгоритм кластеризации смог их переварить за приемлемые время и память.Не могли бы Вы пояснить, зачем снижать размерность? Ведь алгоритмическая сложность кластеризации зависит только от числа элементов (резюме), а не числа признаков у них. Число признаков влияет на время расчета расстояний между парами элементов, но всего лишь линейно, да и время требуемое на снижение размерности (Truncated SVD) все равно будет больше, чем выигрыш от «облегчения» функции расстояний.
Интересно было бы посмотреть кластеризацию вакансий в области ИТ по скилам, можно увидеть какие скилы люди набирают наиболее часто, а какие отстают в развитии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Готовим иерархическую кластеризацию или как я выявлял специализации у резюме