А не фигню ли я придумал: «поиск» в продукте, часть третья

Привет! Я Женя Гурьянов, Chief Product Officer в компании DocDoc. В своих статьях я рассказываю, как внедрять и развивать «поиск» в продуктах. В этой статье я расскажу о метриках поисковой выдачи, а также о том, как можно проверить, что вы не придумали ерунды: офлайн- и онлайн-оценки поисковой выдачи.

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

Во второй статье я даю ответы на вопросы:

Итак, теперь к статье.

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

Давайте разобьём метрики на две группы: поисковые и бизнесовые (разделение больше формальное).

CTR@N — это отношениеколичества выдач, в которых был хотя бы один клик в первые N позиций в выдаче, к количеству всех выдач. Измеряется в процентах.

Давайте поясню формулой для CTR@10.

Средняя позиция клика в выдаче (если пользователь сделал несколько кликов в конкретной выдаче, то выбирается наивысший клик).

Пример: у вас три кликнутых выдачи, клики были на второй, шестой и первой позициях. Подсчёт: AHC = (2 + 6 + 1) / 3 = 3.

То есть средняя позиция наивысшего клика в нашем примере — третья. Очевидно, что кейс идеальной выдачи, это когда пользователи кликают на первую позицию в выдаче (AHC = 1).

Важно: чем меньше Average Highest Click, тем лучше.

Отношение количества всех выдач, в которых был хотя бы один клик на сниппет, к количеству всех выдач.

Также важно учитывать две следующие метрики:

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

Если не принимать в расчёт рекламу на сайтах, то основные деньги приносят продавцы (они платят за поднятия объявлений, премиум-размещения), но поисковая выдача напрямую влияет на покупателей.

Поэтому сложно привязать рост выручки непосредственно к изменению алгоритма работы поисковой выдачи (особенно в A/B- тесте). И поэтому вполне нормальным было бы привязать успех к количеству контактов или количеству покупателей в продукте.

Логика следующая: становится больше покупателей (можно проверять в разрезах: все объявления, платные объявления) → становится больше сделок → продавцы более мотивированы размещать товары и платить за рекламу.

Обычно на вершине иерархии метрик для соцсетей стоит время, в среднем проводимое пользователем в соцсети за день (timespent).

Далее метрики каскадируются. Давайте поговорим, например, про поиск людей или друзей. Как оценивать работу поисковой выдачи? Вполне резонный ответ — по количеству добавленных в друзья.

Логика следующая: чем больше у пользователя друзей в соцсети, тем больше он зависит от неё и больше проводит там времени. Рост количества друзей → рост timespent-показателя.

Деньги DocDoc приносит запись к врачу. До записи есть ещё заявка на запись. Поэтому, казалось бы, для измерения «хорошести» алгоритма поисковой выдачи можно использовать метрику «количество заявок или записей». Но не тут то было.

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

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

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

Целевым действием пользователя считаем первый контакт в день в конкретной категории (собственно, тогда можно считать пользователя покупателем в конкретной категории). Мы пытаемся сократить время или количество действий до первого контакта.

В одной из статей, написанной ранее, я предлагал потенциальную доработку в Avito и «Юле» — пробрасывать пользователя при конкретном запросе марки и модели авто в нужную ему категорию. В примере был запрос «шевроле траверс».

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

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

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

То есть в примере замедление совершения первого целевого действия не снижает счастье пользователя, а напротив, увеличивает его.

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

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

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

Теперь перейдём к более подробному ответу на вопрос, как оценивать эффективность работы алгоритма поисковой выдачи и как сравнивать два алгоритма между собой.

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

Вы фиксируете набор документов(слепок документов), на которых будете обучать и оценивать ваш алгоритм ранжирования.

На каких запросах оценивать качество работы поиска. Очевидно, что не на всех, которые вбивали пользователи за последние два года.

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

Хороший вопрос — за какой период выбирать запросы?

Ответ зависит от продукта:

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

Если в продукте есть сезонность (например, классифайд), то в идеале её стоит учитывать. В выборку могут попасть такие сезонные запросы, как «дома под ключ», «лыжи», «детские самокаты».

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

Откуда взять этих асессоров?

Во-первых, те люди, которые работают над улучшением поиска, должны понимать, как и что ищут пользователи (в первую очередь понимание должно быть у продакт-менеджера).

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

Далее я хочу рассмотреть два подхода к офлайн-оценке: поточечный (pointwise approach) и попарный (pairwise approach).

В данном подходе каждой паре «запрос пользователя — выданный документ» поставлена в соответствие числовая оценка. Один из подходов к варианту оценки:

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

Чтобы стало ещё понятнее, давайте разберём на примере «Юлы». Пользователь ищет услуги ремонта для смартфона. Есть вероятность, что у него что-то с экраном телефона (но это не точно).

Предположим, наш алгоритм выбрал и отранжировал из базы объявлений следующие:

Я немного поработал асессором и проставил оценки (красным цветом). К сожалению, я посчитал, что в выдаче не было ни одной «двойки», но и такое бывает.

Надеюсь, стало понятнее, что означают оценки и как они расставляются. Допустим, вы получили оценки для всех пар «запрос — документы». Идём дальше.

Есть несколько метрик качества ранжирования. Перечислю для наиболее пытливых читателей: DCG, NDCG, MAP, precision@N, NDCG@N, pFound (подробнее в статье на «Википедии»).

Для общего понимания я бы остановился на NDCG (Normalized Discounted Cumulative Gain.). Да и то с целью качественно пояснить, как работает и рассчитывается данная метрика.

Допустим, что на запрос X алгоритм вернул выдачу, результаты которой оценены асессорами следующим образом:

Для примера рассмотрим десять первых результатов. Будем рассчитывать NDCG@10.

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

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

Для этого я вас проведу по вычислениям cumulative gain (CG), discounted cumulative gain (DCG) и nDCG@10.

Первый показатель — просто сумма всех десяти оценок (CG@10 = 0 + 2 + 0 + 1 + 1 + 2 + 0 + 0 + 1 + 0 = 7)

При последующем подсчёте учитывается принцип «пользователи просматривают документы сверху вниз».

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

Таким образом подсчитываем то, что называется DCG.

Тогда nDCG@10 равен 0,675 (3,093 ÷ 4,579).

Очевидно, что максимально достижимый nDCG равен единице (если бы наша выдача совпадала с идеальной). Поэтому тот nDCG, который мы получили, — некая мера того, насколько мы приблизились к идеальной выдаче.

На этом мы закончили рассмотрение поточечного подхода к оценке нашей выдачи. Перейдём к краткому рассмотрению попарного подхода.

В поточечном подходе каждому документу в выдаче мы выставляли одну из трёх цифр для оценки (0, 1, 2). Но в таком подходе есть две проблемы:

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

После достаточно большого количества попарных сравнений можно определить точнее идеальный порядок врачей в выдаче.

В наш самый первый подход к «Толоке» мы не стали заморачиваться на долгой подготовке инструкции и контрольных заданий (golden dataset) для асессоров. Мы запустили небольшую порцию заданий на асессоров и затем руками проверили качество ответов (некое MVP). Результат оказался печальным. Зато задания были выполнены практически мгновенно :)

Почему это происходит? Мы сталкивались с двумя проблемами:

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

Над чем я рекомендую поработать:

Если вы решите работать для оценки заданий с «Толокой», то подробнее про настройку работы с качеством можно почитать в разделе «Контроль качества».

Допустим, что мы протестировали наш новый алгоритм в офлайне и теперь готовы тестировать на реальных пользователях.

Как измерить результат вашей работы в онлайне? Тут нам помогут старые-добрые А/B-тесты. Разбиваем пользователей на две группы:

В одном из предыдущих разделов я рассказывал про метрики поисковой выдачи.

Они могут могут отличаться у разных продуктов.

Примеры:

Далее смотрим на кликовые метрики: CTR@5, CTR@10, Average Highest Click, долю кликнутых выдач, долю нулевых выдач.

Вместе с аналитиками делаем выводы и не забываем про проверку статистической значимости результатов.

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

Например. Пользователь ищет на «Юле» «чёрный iPhone 8». Вдруг среди чёрных iPhone в выдаче пользователь видит белый iPhone 8, но дешёвый, в хорошем состоянии да ещё и в соседнем доме. Пользователь заходит в объявление и покупает товар.

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

Смотрим на то, какие факторы влияют на выбор товара пользователем, смотрим на товары субституты. Например:

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

В своей следующей статье я опишу работу над формированием поисковой выдачи врачей в DocDoc. Мы пройдём весь продуктовый путь — от приоритизации доработки до проверки придуманного нами решения!

#docdoc #выдача