Как в hh.ru тестируют поиск по вакансиям

Я уже делился рассказом о нашем опыте применения искусственного интеллекта в поиске на hh.ru, а сегодня хотел бы остановиться на измерении качества этого поиска поподробнее.

Для нормальной работы поиска крайне важна система метрик — локальных, A/B-тестов, очередей на проде и т. д., и эта система требует отдельного внимания и ресурсов. Неправильно думать, что достаточно просто запилить крутой ML и прикрутить все эти метрики «скотчем»; недостаточно также измерять качество работы уже работающей системы — не так уж важно, использует ли она ML или представляет собой Lucene «из коробки».

Мы отказались от старых решений в поиске не из-за того, что они казались нам устаревшими, или потому что ML — это стильно, модно и молодежно. Старому поиску не хватало локальных метрик качества, по которым можно было бы измерять пользу от изменений до их запуска в длительные эксперименты; кроме того, было непонятно, что изменять и измерять, чтобы организовать процесс постоянного улучшения.

Когда мы начали строить систему поиска на ML, сразу предусмотрели систему локальных метрик. В процессе разработки мы сравнивали качество нового поиска на ML со скорами от моделей, прогнозирующих вероятность отклика, с качеством старого поиска по ключевым словам, который использовал только скоры по текстовому соответствию запроса и вакансии. Для этого мы использовали обычные локальные метрики: MAP, NDCG, ROC-AUC. Кроме того, в процессе мы расширили количество метрик и когорт в A/B-тестах и покрыли новый поиск автотестами. В этом материале я расскажу о том, как мы отслеживаем качество работы наших рекомендательных моделей — вполне возможно, что опыт HeadHunter пригодится и вам, потому что, повторюсь, нет так уж и важно, на ML построен ваш поиск или нет.

Статистические тесты

В первую очередь мы стали измерять качество моделей с помощью локальных метрик MAP, NDCG, ROC-AUC и заметили значительное улучшение от перехода с поиска по ключевым словам к поиску, основанному на ML. Объясняется это тем, что традиционный поиск, основанный на Lucene или Sphinx, не умеет прогнозировать вероятности целевых действий и ранжировать по ней. Например, не умеет учитывать роль зарплаты, указанной в вакансии и в резюме соискателя; не соотносит между собой ключевые навыки в резюме и в требованиях к вакансии, не учитывает смысловых связей при сравнении слов. Это видно на метриках качества поиска, если сравнить скоры текстового соответствия в Lucene со скорами от моделей, которые подобраны с помощью ML и обеспечивают ранжирование и фильтрацию по вероятности отклика и приглашения:

Значения локальных метрик могут прогнозировать значения продуктовых настолько хорошо, насколько корректно эти локальные метрики измеряются. Например, при переходе на разделение сплитов по времени и пользователю при кросс-валидации значения метрик уменьшились, но они стали лучше предсказывать будущие изменения в A/B-тестах.

За прошлый год, улучшив качество поиска и рекомендаций, мы увеличили успешность поисковых сессий в приложении, на мобильном сайте и на десктопе в среднем на 22% (провал на графике — новогодние праздники).

Автотесты

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

A/B

Основное назначение системы A/B-тестирования для нас — контроль и принятие решений (выкатывать ли новую модель, интерфейс и т. д.). Для контроля (проверки качества уже работающей модели) мы проводим обратные тесты, когда в качестве эксперимента включается старая модель. Так можно быть уверенными в том, что текущая модель по-прежнему лучше, чем старая.

Мы используем систему A/B-тестов собственной разработки уже довольно долго. Например, после самого первого запуска альфа-версии рекомендаций на ML она позволила нам увидеть, что успешность рекомендаций выросла на 30%. К слову, качество системы A/B-тестирования и используемых метрик мы исследовали отдельно в статье.

Производительность

Но «победа» новой модели в локальных метриках или в A/B-тесте еще не значит, что эта модель будет работать в проде: модель может оказаться слишком ресурсоемкой, что для hh.ru, высоконагруженного сайта, было бы совершенно неприемлемо. Для измерения ресурсоемкости мы сделали мониторинг всех стадий вычисления скора документа.

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

И другие показатели

Самой главной задачей поисково-рекомендательной системы является подбор вакансий, на которые пользователь откликнется с наибольшей вероятностью. Мы хотим, чтобы количество откликов на вакансии увеличивалось и люди быстрее находили себе работу. Поэтому, кроме CTR и количества успешных поисковых сессий, важнейшим показателем работы поиска стало абсолютное количество откликов на вакансии. При включении новой модели количество откликов начинало резко расти: сейчас на hh.ru в среднем в день пользователи делают больше 600 000 откликов на вакансии. Это плавающий показатель — бывают дни, когда мы фиксируем более миллиона откликов. Успехом мы также можем считать добавление кандидатом вакансии в избранное или, например, просмотр контактов в предложенной вакансии.

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

Автор: Александр Сидоров

Источник