Александр Сидоров (HeadHunter) – об архитектуре машинного обучения на Big Data Conference

Представитель HeadHunter Александр Сидоров рассказал о распределенной архитектуре поиска и машинного обучения на примере HeadHunter.

Благодаря сервису Penxy презентацию Александра Сидорова можно не только посмотреть, но и послушать:

Аудитория смогла задать свои вопросы Александру через специальный сервис WhenSpeak. Публикуем полный вариант этого интервью.

Примечание: в записи на 21:43 оговорка, имелось в виду несколько сотен миллионов кликов и несколько миллионов откликов.

Встроенная рекомендательная система вакансий работает не очень — рекомендует нерелевантные вакансии, с чем это может быть связано?

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

• с редкостью профессии (никто не откликался похожими резюме на похожие вакансии – не на чем научиться);
• с тем, что мы только начали внедрять поиск на ML, ещё за неделю до конференции он был полностью текстовым, без машинного обучения и учёта резюме. Поиск не показал подходящую вакансию на похожие резюме вверху выдачи – нет откликов – не на чем научиться;
• с тем, что в резюме не очень хорошо написано, что конкретно человек делал и сделал на последних работах, какие инструменты использовал, и вакансиях описание, что именно нужно знать и делать, написано или не очень хорошо, или очень необычно, «чтобы отличаться».

В принципе, понятно, что с этим делать, второе скоро поправим, первое и третье – тоже в некоторой степени можно, в планах.

Расскажите, пожалуйста, подробнее про модели и как к ним пришли, про предобработку данных, про алгоритмы обучения.

Обычные линейные модели (первый фильтр) и XGBoost (второй фильтр, ранжирование) со специально подобранными гиперпараметрами, чтобы score’ы по метрикам map и ndcg получались лучше.

Выгружаются данные из нескольких видов логов в Hadoop за обычный месяц, объединяются, вычищаются пользователи с признаками роботов, null’ы и NaN’ы для разных признаков обрабатываются немного по-разному.

Начали с фильтра только с линейной моделью, затем добавили ещё один фильтр на XGBoost, чтобы ранжирующий XGBoost можно было сделать более тяжёлым, не увеличивая ресурсоёмкость и время откликов.

Пришли так: сделали локальные и online-метрики качества моделей и признаков, формируем гипотезы, как можно сделать метрики лучше (что сделать с признаками, target’ами, какие алгоритмы и их наборы попробовать), ставим в план, делаем, измеряем локальные метрики, если есть прирост — измеряем online-метрики в A/B-тестах, если снова ОК, то выпускаем на всех, потом то же самое со следующей гипотезой.

Сколько обращений за резюме в день?

Если имеется в виду количество обращений к резюме из базы при формировании результатов поиска по вакансиям, то 5-8 млн в день, на пике до 12 млн, это без учёта трафика мобильных приложений и роботов. Если учесть обращения от мобильных приложений и других пользователей API, а также при формировании рассылок с рекомендуемыми вакансиями и роботов, то примерно вдовое больше.

Пару слов, как формируете фичи из резюме и как работаете с вакансиями.

Делаем признаки из полей вакансий и резюме как есть, и с обычной векторизации текста, bag of words. Пробуем разные сочетания pairwise-признаков, разную кодировку категориальных признаков, разные виды свёртки векторов из текста. Затем более сложные признаки.

Примеры фичей приведите, пожалуйста.

Зарплата «от», сколько лет опыта работы, география — регион, график работы, косинусное расстояние между векторизованным текстом резюме и вакансии.

Смотреть все презентации.