Всем привет! Я Владислав Урих, работаю продуктовым аналитиком в Авито, сейчас занимаюсь построением алгоритмов мэтчинга в новом транзакционном продукте — Авито Подработка.

Недавно мы полностью пересобрали алгоритмы ранжирования в Авито: добавили поведенческие признаки, отказались от оптимизации на контакты и внедрили персонализированный поиск.

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

Текст будет полезен всем продуктовым аналитикам, ML-инженерам и продакт-менеджерам, которые работают с алгоритмическими продуктами.

О чём статья:

• Как устроена Авито Работа

• Что побудило нас задуматься о проблемах

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

• Как мы проверяли гипотезу на офлайн-тестах

• Почему не раскатили алгоритм сразу, если он оказался эффективнее

• Как реализован мэтчинг-поиск технически

• Какие результаты получили после A/B

• Вся статья коротко

Как устроена Авито Работа

Авито Работа — одна из наших вертикалей наряду с Товарами, Недвижимостью, Услугами. Также в рамках Работы у нас есть две категории: Вакансии и Резюме. Сначала речь пойдёт о второй.

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

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

Что побудило нас задуматься о проблемах

Мы долго работали по схеме, описанной выше, и не трогали алгоритм. Но со временем появились сигналы о необходимости что-то поменять:

• упали метрики NPS и CSAT — работодатели хуже оценивали качество сервиса и перестали рекомендовать его другим;

• снизился retention — пользователи стали реже возвращаться, чтобы найти новых сотрудников;

• UX-исследователи присылали жалобы от пользователей. Им не нравились резюме, которые мы предоставляли.

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

Почему текущий поиск нам не подходит

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

• Оптимизируется на контакты, а не на найм.

Универсальная поисковая модель на Авито заточена на максимизацию контактов по объявлению. То есть наверх в выдаче поднимаются объявления, в которые с большей вероятностью перейдёт покупатель и откликнется по ним.

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

Старый алгоритм продвигал самые привлекательные резюме — те, в которых анкета заполнена подробнее, фотография более качественная или оформление аккуратнее. Но при этом не учитывал вероятность реального найма — в него не заложена возможность «понимать», актуален ли для кандидата поиск работы или уже нет. Из-за этого:

44% резюме вообще не получали ни одного контакта. Соискатель размещал анкету, а в ответ — тишина.

Часть резюме, наоборот, собирала по 20–30 контактов, даже если кандидат уже нашёл работу и его резюме давно уже неактуально.

• Работает по неудобному для нас паттерну поиска объявлений.

Только на Авито Работе деньги списываются с покупателя, а не с продавца, то есть компании, которая ищет сотрудника. Поэтому им важно быстро найти подходящего кандидата и не тратить бюджет «вхолостую».

• Не учитывает уникальные признаки разных категорий.

Старый поиск был построен как единая модель для всех категорий. Он не учитывал, что в каждой разные важные признаки:

1. В Товарах важна цена, качество фото и возможность доставки.

2. В Услугах — скорость отклика и отзывы.

3. В Работе — опыт работы, зарплатные ожидания, формат занятости.

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

• Работает по простому ранжированию, а нам нужен мэтчинг.

Простое ранжирование подразумевает, что продавец не может выбирать покупателей, а трафик распределяется неравномерно. Старый алгоритм учитывал только признаки продавца — то есть данные соискателя. Но найм — это всегда двусторонний процесс. У работодателей тоже есть свои требования: зарплата, график, опыт кандидата.

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

Без учёта обеих сторон сделки вероятность успешного найма низкая. А значит, покупатели могут потратить деньги впустую.

Всё это привело к трём последствиям:

1. Низкая ликвидность базы резюме.

2. Высокие затраты на найм сотрудника.

3. Снижение уровня удовлетворённости работодателей.

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

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

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

• персонализировать выдачу под каждого конкретного работодателя;

• пессимизировать неактуальные резюме — убирать их как можно ниже в результатах поиска;

• приоритизировать наиболее подходящих кандидатов, чтобы наверху были те, кто реально подходит по требованиям;

• строить настоящий мэтчинг — учитывать интересы обеих сторон и повышать вероятность найма.

Чтобы реализовать такую модель, нужно понимать, что важно конкретному работодателю и отвечает ли соискатель этим требованиям. 

Собрали поведенческие данные с обеих сторон.

• Работодатели

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

Например: работодатель купил 10 резюме с полной занятостью — и 9 из них завершились наймом. Потом купил 10 резюме с подработкой — и не нанял ни одного. Делаем вывод: ему стоит показывать в выдаче тех, кто ищет работу на полный день. 

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

• Соискатели

У каждого резюме есть история: сколько раз его покупали и отвечал ли человек на предложения работодателей. 

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

А вот если другое резюме опубликовали вчера и кандидат быстро ответил в чате — надо поднять выше.

Чтобы точнее понять, насколько соискатель активен, разбили все контакты по каналам:

• чаты;

• звонки через подменный номер;

• встроенные inApp-звонки.

Зачем нужно такое разбиение? Люди по-разному отвечают в разных каналах. Мужчины чаще берут трубку, но редко заходят в чат. Женщины редко отвечают на звонки, зато активно переписываются.

Если смотреть только на суммарную активность, можно сделать неправильный вывод. Поэтому мы оцениваем конверсию в ответ отдельно по каждому каналу.

Всё вместе это даёт нам набор признаков, на которых можно строить новый поиск и понимать: кого стоит поднять, кого опустить, кому что показать. Такой подход помогает подбирать кандидатов именно для конкретного работодателя, а не для абстрактной «средней» задачи. А значит, увеличивает вероятность найма и помогает работодателям быстрее находить своих сотрудников.

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

Как мы проверяли гипотезу на офлайн-тестах

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

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

Дальше сравниваем: как отработал текущий алгоритм, а как сработал бы новый, если бы мы применили его к тем же запросам.

И в финале смотрим, кто поднялся выше в списке: те, по кому потом был найм, или другие.

Чтобы сравнить алгоритмы, нужна метрика. Мы используем NDCG — Normalized Discounted Cumulative Gain. Это мера «идеальности» выдачи, которая показывает, насколько хорошо алгоритм расположил объявления по сравнению с идеальной ситуацией.

Как это работает — на примере:

DCG (Discounted Gain) — это сумма весов объявлений, по которым была сделка, с поправкой на позицию. Чем ниже в списке, тем меньший вклад.

Ideal DCG — то же самое, но для ситуации, когда все «успешные» резюме стоят на первых строчках.

NDCG = DCG / Ideal DCG. Максимальное значение — 1. Означает, что алгоритм выдал все релевантные объявления в самом верху.

В нашем случае получились такие значения метрик:

• DCG = 2.18;

• Ideal DCG = 2.63;

• NDCG = 0.83 — это уже хороший результат.

Но главное — разница между новым и старым алгоритмом. Мы сравнили их по этой метрике на большом количестве поисковых сессий и увидели аплифт — рост качества выдачи.

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

• В категории Резюме новый алгоритм дал прирост NDCG +8,5%.

• В Вакансиях, где, наоборот, работодатели — это продавцы, а соискатели — покупатели, аплифт оказался даже выше — +9,7%.

Почему не раскатили алгоритм сразу, если он оказался эффективнее

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

L1-ранжирование. Всё начинается с огромного корпуса, где миллионы объявлений. Из них сначала отбираются топ-500 кандидатов. Это делается без сортировки — просто фильтрация по нужным условиям.

L2-ранжирование. Именно здесь мы определяем, кто должен быть выше в списке, а кто ниже. Но даже это — не финальный шаг.

Подмешивание продвижений. Продавцы платят за то, чтобы их резюме или вакансия оказались в топе: у кого ставка и CTR выше, тот получит место повыше, даже если его объявление не самое релевантное.

Если интересна эта тема, читайте статью моего коллеги: «Как работает поисковое ранжирование для миллионов объявлений Авито»

В результате итоговая выдача уже не такая, как рассчитала модель. И те улучшения, которые показал офлайн-тест, могут «съесться» коммерческими механиками.

Поэтому прежде чем выкатывать новую систему на всех, мы запустили полноценное A/B-тестирование. Только так можно объективно понять, как работает алгоритм в реальных условиях, как он взаимодействует с другими слоями логики и даёт ли устойчивый рост метрик в реальном трафике.

Как реализован мэтчинг-поиск технически

Даже после успешного офлайн-теста непонятно, как всё это внедрить в реальную систему. Признаки нужно доставлять в поиск в реалтайме, а модель построить отдельно, только под категорию Резюме. 

До нас никто в Авито не решал подобную задачу: обычно все использовали единые алгоритмы на все вертикали. Поэтому нужно было понять, как подступиться к такому проекту.

Мы начали с самого простого — проверки гипотезы, а затем шаг за шагом прошли весь путь до продакшена.

Шаг 1. Проверили ценность алгоритма. Об этом рассказал в разделе про офлайн-тесты выше.

Шаг 2. Построили аналитические витрины. На этом этапе собрали нужные признаки. По работодателям — историю их покупок и успешных наймов. По соискателям — количество предыдущих контактов, ответов и наймов.

Шаг 3. Доставили признаки до поиска. Для этого инженерам пришлось разработать хранилища для новых признаков и написать код доставки данных из аналитических витрин до новых хранилищ. Теперь они доступны в реалтайме, а алгоритм может использовать их при формировании выдачи.

Шаг 4. Обучили модель и зарегистрировали её в реестре. Построили новую ML-модель: она учитывает интересы обеих сторон — работодателя и соискателя — и оптимизируется на вероятность найма. Обучили её только на данных Резюме и зарегистрировали в MLflow.

Шаг 5. Запустили A/B-тест. Проверили, как модель работает в бою. Сравнили старый и новый алгоритм на реальном трафике и узнали, какой даёт больше целевых действий и наймов.

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

Какие результаты получили после A/B

Отдельно собирали данные для Резюме и для Вакансий:

В результате работы можно сделать вывод — подход работает. Мэтчинг-поиск помогает работодателям и соискателям встречаться друг с другом, увеличивает количество сделок и удовлетворённость пользователей Авито. 

После полученных результатов мы стали активно применять эту методологию в других вертикалях и категориях и ждём результаты коллег.

Вся статья коротко

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

Мы захотели улучшить алгоритм поиска и решили мэтчить работодателей с соискателями. 

Мэтчинг-поиск — это алгоритм, который ранжирует объявления не по привлекательности, а по вероятности найма. Он учитывает интересы обеих сторон: работодателя и соискателя. 

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

Провели офлайн-тесты. На исторических данных они показали значимый аплифт в метрике NDCG, особенно в зеркальной категории Вакансии — 9,7%.

Реализовали полноценную масштабируемую систему: собрали аналитические витрины, доставили признаки в поиск, обучили и зарегистрировали модель в реестре, а потом провели A/B-тесты. 

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

Больше внутрянки и подробностей о работе в Авито есть в телеграм-канале — «Коммуналка аналитиков». Заглядывайте!

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