Методология · Релевантность
Как определяется релевантность и роль вакансии
За разбором стоит словарь из 80+ ролей и смежных доменов. Задача — найти все подходящие вакансии и не отправить отклик на неподходящую. Ниже — как именно устроена проверка.
Роль
Словарь ролей и ключевых слов
Роль вакансии определяется по заголовку через словарь ролей, ключевых слов и смежных доменов — например, Backend ↔ Fullstack или Data Analyst ↔ Analytics Engineer. Словарь учитывает и русские, и английские названия. Так вакансия «Staff Software Engineer» матчится на Software Engineer, а не только на дословное совпадение.
Основная и смежные
Одна основная роль, остальные — смежные
Одна вакансия может подходить под несколько ролей. Мы выделяем основную роль — ту, что точнее всего совпадает с заголовком, — и показываем её отдельно, а остальные помечаем как смежные. Это не превращает каждое упоминание аналитики или инфраструктуры в самостоятельную роль.
Поля
Грейд, формат, город — и принцип «неизвестно → пропускаем»
- После роли вакансия проверяется по грейду, формату работы и городу из твоего сценария.
- Если поле у вакансии неизвестно — оно не блокирует показ. Мы не отсеиваем вакансию из-за отсутствующего значения и не додумываем его.
- Обязательные ключевые слова роли работают как фильтр от ложных совпадений (например, чтобы «Product Designer» не попал в «Product Manager»).
Двойная проверка
Проверка перед самим откликом
Релевантность проверяется не один раз: при попадании в каталог — по заголовку, а перед самой отправкой отклика — ещё раз по полному тексту вакансии. Ошибка разбора может потратить место в очереди, но не приведёт к отклику на нерелевантную позицию.
Источники, частота сканирования, дедупликация, статус вакансии и что мы не показываем.
Вилка работодателя против оценки Lumio, российский и зарубежный рынок, грейд, регион и уверенность оценки.
Свежесть, устаревшие источники, ошибки распознавания, что мы не выдумываем и как сообщить об ошибке.