---

Конкретный момент в сопоставлении кандидатов

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

Почему эта проблема важна

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

Анализ проблемы

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

Наши первоначальные попытки

Сначала мы исследовали простой детерминистский подход к фильтрации, при котором кандидаты сопоставлялись на основе строгого набора жестко закодированных критериев. Этот метод оказался тупиковым; хотя он улучшил специфичность, ему не хватало нюансов, необходимых для эффективного ранжирования. Кроме того, он был негибким и плохо адаптирован к разнообразному языку, используемому в резюме. Мы поняли, что нам нужен более динамичный подход, который мог бы понимать контекст и семантику, что привело нас к рассмотрению больших языковых моделей (LLM) для повторного ранжирования.

Наш технический подход

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

# Псевдокод процесса сопоставления кандидатов
candidates = retrieve_candidates(filters)
ranked_candidates = llm_re_rank(candidates, job_description)
return ranked_candidates

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

Наблюдаемые изменения в продукте

После внедрения этих изменений мы заметили значительные улучшения на нашей платформе. Рекрутеры сообщили о заметном увеличении релевантности совпадений кандидатов, что привело к более быстрым процессам собеседования и более высоким уровням удовлетворенности. Кандидаты также испытали более прозрачный процесс, где их навыки лучше отражались в оценке сопоставления. Это непосредственно повлияло на нашу страницу /jobs, так как вакансии начали получать более качественные пулы соискателей, в конечном итоге улучшая пользовательский опыт для всех участников.

Ключевые уроки

В ходе этого процесса мы усвоили несколько неочевидных уроков:

• Гибкость — это ключ: строгие критерии сопоставления могут упустить квалифицированных кандидатов.
• Язык имеет значение: синонимы и жаргон могут искажать результаты; контекст имеет решающее значение.
• Старшие должности не равны старшим навыкам: объективная оценка навыков необходима для обеспечения качественных совпадений.
• Непрерывные циклы обратной связи: регулярный пересмотр логики сопоставления на основе отзывов пользователей важен для поддержания точности.
• Алгоритмическая прозрачность: кандидаты ценят понимание того, как оцениваются их навыки, что может повысить доверие к процессу.

Последствия для кандидатов

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

Последствия для рекрутеров

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

Следующие шаги

Смотрев вперед, мы отслеживаем несколько аспектов новой системы сопоставления. Мы хотим дальше усовершенствовать настройку LLM для улучшения понимания контекста и исследовать возможность более бесшовной интеграции отзывов пользователей в алгоритм. Одной из областей, на которую мы особенно нацелены, является снижение влияния перенасыщения ключевыми словами через лучший семантический анализ. Если бы нам пришлось отменить один аспект, это была бы чрезмерная зависимость от детерминистских фильтров, так как мы увидели значительные преимущества от гибкости LLM. ---