Наряду с бесконечным расширением электронной коммерции и онлайн-медиа в последние годы, сегодня становится все больше и больше рекомендательных систем (RS) типа программное обеспечение как услуга (SaaS). В отличие от 5 лет назад, когда использование RS было привилегией крупных компаний, создающих собственные RS, тратя колоссальный бюджет на команду специалистов по обработке данных, сегодняшняя популярность решений SaaS делает доступным использование рекомендаций даже для малых и средних предприятий. -размерные компании. Технический директор таких компаний сталкивается с вопросом при поиске подходящей SaaS RS: Какое решение лучше? Предполагая, что у вас все еще нет RS или вас не устраивает текущая версия RS, какое решение вы должны выбрать?

В этой статье я рассмотрю два подхода:

  • Офлайн-оценка в академическом мире (плюс Netflix Prize), поиск с малыми ошибками прогнозов (RMSE / MAE) и большим количеством отзывов / каталогов. TL; DR; просто знайте, что эти меры существуют, и вы, вероятно, не захотите их использовать. Но я все же дам их краткое изложение, если вам интересно.
  • Онлайн-оценка в деловом мире, поиск высоких показателей жизненной ценности клиента (CLV), прохождение A / B-тестирования, CTR, CR, рентабельности инвестиций и контроля качества. Вам следует прочитать этот раздел, если вы серьезно рассматриваете рекомендации, способствующие развитию вашего бизнеса.

Оффлайн мир = как это делают академики?

RS исследуются в академических исследованиях на протяжении десятилетий. Существует множество исследовательских работ, в которых представлены различные алгоритмы, и для того, чтобы алгоритмы были сопоставимы, в них используются академические меры. Мы называем эти меры автономными мерами. Вы ничего не запускаете в производство, вы просто играете с алгоритмами в своей песочнице и настраиваете их в соответствии с этими критериями. Я лично много исследовал эти меры, но с моей сегодняшней точки зрения они довольно доисторические. Но даже в средние века 2006 года в знаменитой премии Netflix Prize использовалась чисто академическая мера под названием RMSE (среднеквадратичная ошибка).

Чтобы кратко объяснить, как это работает, предполагается, что ваши пользователи явно оценивают ваши продукты, например, количеством звезд (1 = сильная неприязнь, 5 = сильная симпатия), и у вас есть множество таких оценок (записи говоря, что пользователь A оценил элемент X звездочками Y) из прошлого. Используется метод, называемый раздельной проверкой: вы берете только подмножество этих оценок, скажем, 80% (называемое набором поездов), строите на них RS, а затем просите RS предсказать оценки. на те 20%, которые вы скрыли (тестовый набор). И поэтому может случиться так, что тестовый пользователь оценил какой-то элемент на 4 звезды, но ваша модель предсказывает 3,5, следовательно, у него есть ошибка 0,5 в этом рейтинге, и именно отсюда берется RMSE. Затем вы просто вычисляете среднее значение ошибок для всего набора тестов, используя формулу, и получаете окончательный результат 0,71623. БИНГО! Вот насколько хороша (точнее, плохая) ваша РС. Или вы также можете использовать другую формулу и получить MAE (средняя абсолютная ошибка), которая не штрафует за большие ошибки (истинные 4 звезды, предсказанная 1 звезда), поэтому вы можете получить только 0,6134.

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

Пользователи ленивы и ничего не ставят. Они просто открывают веб-страницу, и если им нравится то, что они видят, они могут это купить / потребить; если это отстой, они уходят так же быстро, как пришли. Таким образом, у вас есть только так называемые неявные рейтинги в журнале вашего веб-сервера или в базе данных покупок, и вы не можете измерить ошибку количества звезд на них просто потому, что нет звезды. У вас есть только +1 = пользователь просмотрел деталь или купил продукт и, как правило, ничего больше. Иногда их называют унарными рейтингами, которые вы знаете по кнопке «Нравится» в Facebook: оценка либо положительная, либо неизвестная (пользователь может просто не знать, что контент существует).

Вы по-прежнему можете использовать раздельную проверку таких данных даже для собственного автономного сравнения рекомендаций SaaS. Предположим, вы берете, например, свою базу данных покупок, отправляете историю 80% пользователей в RS, а затем для каждого тестового пользователя отправляете только несколько покупок и просите RS предсказать остальные. Вы можете спрятать 4 купленных предмета и попросить у РС 10 предметов. Вы можете получить точность 0%, 25%, 50%, 75% или 100% для этого пользователя, в зависимости от того, сколько скрытых 4 появилось в рекомендованных 10. И эта точность называется Отзыв. Вы можете усреднить его по всему набору тестов и ТАДААА! Ваш результат 31,4159%, вот насколько хорош ваш RS.

Честно говоря, даже несмотря на то, что Recall намного разумнее, чем RMSE, он по-прежнему приносит много боли. Допустим, тестовый пользователь смотрел 20 серий одного и того же сериала, и вы измеряете запоминаемость по ней. Итак, вы скрываете эпизоды № 18–20 и просите RS предсказать их из № 1–17. Это довольно простая задача, так как эпизоды сильно связаны, поэтому вы запоминаете на 100%. Итак, ваш пользователь открыл для себя что-то новое? Вы вообще хотите порекомендовать ей такой контент? И что в любом случае приносит вам наибольшую ценность для бизнеса? Скажите, в интернет-магазине вы хотите порекомендовать альтернативы или аксессуары? Вы должны почувствовать, что попадаете на очень тонкий лед с вспоминанием.

И еще один секрет, который я вам открою: в некоторых случаях (не всегда, зависит от вашего бизнеса!), Чтобы добиться разумного отзыва, рекомендуется рекомендовать только самые популярные в мире товары (также известные как бестселлеры). Итак, мы приступаем к покрытию каталога. Вы хотите, чтобы пользователи открывали для себя все новые и новые материалы, чтобы оставаться лояльными? Тогда вы можете порекомендовать как можно больше различных предметов. В простейшем случае, чтобы вычислить покрытие Каталога, просто возьмите своих тестовых пользователей, попросите рекомендации для каждого из них и объедините все рекомендуемые элементы. Вы получаете большой набор различных предметов. Разделите размер этого набора на общее количество позиций во всем вашем каталоге, и вы получите… 42,125%! Это та часть вещей, которую ваш RS может когда-либо порекомендовать.

Теперь рассмотрим модель-бестселлер. У него может быть неплохой отзыв, но почти нулевой охват (5 постоянных элементов?). И возьмем случайный рекомендатель. У него почти нулевой отзыв и 100% покрытие. Вы можете почувствовать, что хотите компромисса.

Приведенное выше изображение взято из моего (теперь очень устаревшего) оригинального исследования. Вы можете увидеть около 1000 различных моделей RS, нарисованных в плоскости Recall-Coverage. Гики, не так ли? :) Вы можете почувствовать головокружение при выборе лучшего, но я надеюсь, вы чувствуете, что выбор некоторых из правого верхнего угла («Парето-оптимальный фронт») может быть хорошим выбором.

Чтобы сделать офлайн-оценку еще более надежной, вы можете использовать перекрестную проверку (Xval) вместо сплит-проверки. Просто разделите пользователей на 10 складок и продолжайте цикл: всегда делайте 9 складок для построения модели и используйте оставшуюся 1 складку для проверки. Усредните результаты за эти 10 прогонов.

Теперь вы можете спросить: А как же мой бизнес? Можно было бы измерить отзыв и охват, но как они связаны с моими ключевыми показателями эффективности?

И ты прав. Чтобы разместить SaaS RS по оси X и $$$ по оси Y, мы должны покинуть автономный мир и перейти к производству!

Интернет-мир: следуйте примеру умных технических директоров

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

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

Теперь предположим, что у вас есть готовая интеграция и вы можете разделить своих онлайн-пользователей на группы A / B-тестирования. Вы можете либо использовать собственное хеширование их файлов cookie UID, либо использовать для этого какой-либо инструмент (например, VWO, Optimizely или даже GAs, хотя последний вариант немного болезненен). Чтобы провести эксперимент, вы должны определить одно хорошее место на своем веб-сайте / в приложении, где можно протестировать рекомендации, потому что вы точно не хотите проводить полную интеграцию всех кандидатов-RS на ранних этапах пилотного проекта. этап, правда? Если у вас небольшой трафик, помните, что выбранное место должно быть достаточно видимым, чтобы получить значимые результаты. В противном случае, если у вас огромный трафик, вы можете выбрать консервативную стратегию, например, выпустить только 20% вашего трафика для тестирования, сохраняя себя и остальные 80% пользователей в безопасности на случай, если некоторые из кандидатов-RS будут быть полностью сломанным и рекомендовать лишнее.

Предположим, все это запущено и работает. Что измерить? Самыми простыми измерениями являются рейтинг кликов (CTR) и коэффициент конверсии (CR) рекомендаций.

Отображен набор из N рекомендаций 20 раз, из которых 3 раза пользователь нажимал хотя бы один из рекомендованных элементов? Тогда ваш CTR составляет 15%. Действительно, щелкать мышью - это приятно, но, вероятно, это привело пользователя на страницу с подробностями, и вы, возможно, захотите узнать, что произошло дальше. Действительно ли контент показался пользователю интересным? Посмотрела ли она все видео, прослушала всю песню, прочитала всю статью, ответила на предложение о работе, положила товар в корзину и действительно заказала его? Это коэффициент конверсии = количество рекомендаций, которые порадовали и вас, и вашего пользователя.

CTR и CR могут дать вам хорошую оценку эффективности рекомендателя, но вам следует оставаться осторожным и не забывать о своем продукте. Возможно, вы управляете новостным порталом и размещаете самые свежие новости на главной странице. Это может не дать вам максимально возможного CTR, но сохранит качество и чувство, которое вы и ваши пользователи испытываете к вашим услугам. Теперь вы можете поместить туда RS, и он может начать показывать различный контент, например, желтые журналистские статьи или забавные статьи о «очень быстрых собаках, бегающих с невероятной высокой скоростью». Это может увеличить ваш немедленный CTR в 5 раз, но это повредит вашему имиджу и вы можете потерять своих пользователей в долгосрочной перспективе.

А вот и эмпирическая оценка RS. Просто запустите новый сеанс с пустыми файлами cookie, смоделируйте поведение пользователя и проверьте правильность рекомендаций. Если у вас есть команда QA, заставьте ее приступить к работе! Эмпирическая оценка одновременно сложна и легка. Это сложно, потому что не выдает никаких цифр, которые вы могли бы представить на товарной доске. Но это также легко, потому что благодаря вашей человеческой интуиции вы просто поймете, какие рекомендации хороши, а какие плохи. Если вы выберете странно работающий рекомендатель, в будущем вы столкнетесь с множеством неприятностей, даже если CTR / CR в данный момент высоки.

Но, конечно же, помимо качества, вы должны заботиться о окупаемости инвестиций (ROI).

Проще говоря, вы могли определить, что кратность №1 A / B-тестирования привела к увеличению коэффициента конверсии на X% по сравнению с исходной кратностью №0 (ваше текущее решение), и ваша маржа составила $ Y для среднего количества успешно рекомендованных элементов, и что для этого требовалось Z запросов рекомендаций. Посчитайте, спроецируйте расходы / доходы в случае, если вы положите данный RS на 100% своего трафика, интегрируя также в другие разделы вашего веб-сайта / приложения.

Одно предупреждение о расчете рентабельности инвестиций: он очень расплывчатый и зависит от большого количества неизвестных: будет ли CR одинаковым в других местах моего веб-сайта / приложения? (Простой ответ = нет, не будет, в разных местах разный CTR / CR). Как изменится CR, если выставить рекомендации на более-менее привлекательную позицию? (Простой ответ = много). Как CR будет развиваться со временем? Научятся ли пользователи пользоваться рекомендацией и доверять ей, или CR откажется?

Это приводит к окончательному, но наиболее сложному измерению: Пожизненная ценность клиента (CLV). Вы ищете беспроигрышную ситуацию. Вы хотите, чтобы вашим пользователям понравился ваш сервис, они чувствовали себя комфортно, счастливы и готовы вернуться. Вместе с этим вы хотите, чтобы RS улучшил UX, помогая пользователям находить интересный контент / продукты, которые им нравятся. Как достичь высокого CLV с помощью RS?

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

Заключение

Я попытался охватить наиболее важные аспекты оценки RS. Возможно, вы видели, что это непростая задача и есть над чем подумать, но я надеюсь, что хотя бы дал вам некоторые подсказки, чтобы ориентироваться в этом районе. Вы можете протестировать RS в автономном режиме еще до запуска в производство или провести производственное A / B-тестирование с оценкой CTR / CR и ROI. Всегда включайте QA, потому что один только CTR / CR / ROI может вводить в заблуждение и не гарантирует совместимость с видением вашего продукта.

Многое было упущено только для того, чтобы текст оставался бесконечно длинным. Помимо CTR / CR / ROI / качества рекомендаций, вам следует быстро взглянуть на общие возможности рассматриваемого RS. Возможно, вы захотите включить рекомендации в свои рассылки по электронной почте в будущем. Это будет работать? Есть ли у него возможность чередовать рекомендации, чтобы конкретный пользователь не получал одинаковый набор рекомендаций в каждом электронном письме? Можете ли вы удовлетворить все ваши бизнес-требования, можете ли вы повлиять на рекомендации, улучшить какой-либо тип контента, отфильтровать его по различным критериям? Эти темы не освещены, но вы можете подумать и о них.

Автор является соучредителем Recombee, сложной системы рекомендаций SaaS.