Wazowski Recommends

Из необычных, но прикольных примеров рекомендательных систем в повседневной жизни: динамические обои на лок-скрине iPhone.

Конечно, это огромная натяжка — называть это рекомендательной системой. Технологии там совсем другие, и никакой персонализации на самом деле нет (персонален контент, а не ранжирование).

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

Я снимаю ненулевое количество фото, но разбирать их мне всегда лень. (Иногда вот только жена проходится по ним и лайкает что-нибудь.)

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

Если кто хочет тоже себе такое настроить: Settings -> Wallpaper -> Add New Wallpaper -> Photo Shuffle -> выбрать интересующие категории фото (например, я выбрал и природу, и города, и свою семью). Для Android такое тоже наверняка есть, да?

Обычно у рекомендательных сервисов есть главная метрика, которую они пытаются растить, north star. Насколько я могу судить (и когда-то я уже писал об этом), в большинстве случаев это одна из четырех:
1) Time spent (сколько времени пользователи проводят на сервисе)
2) Транзакции (количество или суммарная стоимость, GMV)
3) Подписки
4) DAU (или похожие метрики user retention)

Конечно же, это исходит от бизнес-модели сервиса.

У меня есть мнение (или лучше сказать — гипотеза), что среди этих метрик самая близкая к «чистому качеству» рекомендаций (user satisfaction, «счастью пользователей» и т.п.) — это именно DAU.

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

Не очень сложно представить, как можно накрутить time spent. GMV — наверно, тоже (хотя тут слово «накрутить» не обязательно означает что-то плохое, деньги же тоже нужно зарабатывать, просто это может быть не сонаправленно с user satisfaction). Подписки — легко, если на сервисе есть контент, доступный только подписчикам (а если нет, то и оптимизировать эту метрику будет на порядок сложнее, чем остальные).

Для DAU тоже есть известный простой способ накрутки — присылать пуши (не говоря уже про дистрибуцию). Но это всё-таки немного про другой сценарий. А вот может ли система (или команда), которая управляет только тем, какой контент она рекомендует, накрутить DAU (т.е. заставить пользователей больше возвращаться в последующие дни), но понизить при этом user satisfaction? Я простых способов не знаю.

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

Расскажите, знаете ли вы способы накрутки DAU и что вообще думаете про метрики верхнего уровня для рекомендаций?

Школа Анализа Данных славится в первую очередь тем, что готовит специалистов по машинному обучению. Но когда я в неё пошёл в 2007, я и слов-то таких не знал. Я шёл туда, чтобы изучать computer science, просто потому что было очень интересно. (Хотя ещё за год до этого я и про словосочетание computer science ухмылялся: что это ещё за наука такая — о компьютерах?)

И вот только к концу моего обучения в ШАД пригласили Константина Воронцова читать лекции по машинному обучению. У нашего потока оставался всего один семестр, поэтому Воронцову пришлось для нас ужать курс вдвое. Но мне этого хватило, чтобы понять, что это именно то, чем я и хотел бы заниматься.

Семинары по ML тогда вёл Александр Дьяконов и делал это, надо сказать, не очень хорошо. Многим не нравилось. И когда я закончил ШАД, внезапно оказалось, что Дьяконов уходит писать докторскую и больше вести семинары не будет. Надо искать нового семинариста. И Воронцов вместе с Леной Буниной подумали-подумали и почему-то решили, что никого лучше свежего выпускника ШАД, прошедшего только укороченный курс и ещё даже не окончившего мехмат, с неуспешным опытом применения ML в рабочем проекте, но зато с горящими глазами — им на эту роль не найти!

Так я и стал семинаристом. Совсем без опыта. Пришлось учиться по ходу самому, по бразильской системе. Это было довольно сложно и очень трудоёмко. В целом, получилось даже не так плохо. Кажется, лучше, чем у моего предшественника. Но сильно хуже, чем стали вести ML несколько лет спустя.

Меня хватило на два года. После этого я понял, что быть преподавателем — это не совсем моё, удовлетворения от процесса я получаю сильно меньше, чем трачу сил на подготовку к семинарам и проверку домашек. Но была и польза: меня стали узнавать почти все студенты ШАДа, что помогло мне получить неплохую репутацию в Яндексе (у вас тоже так бывает, что с вами здороваются незнакомые вам люди?) и, в частности, лучше нанимать к себе в команду.

Но только я перестал быть семинаристом, как Лена нашла мне новую роль в ШАДе: я стал вести научный семинар по машинному обучению и информационному поиску, где мы со студентами разбирали статьи. В результате чего у меня появилось несколько студентов в научном руководстве. И один из них (не будем показывать пальцем; привет, Рома!) даже весьма успешно защитил магистерскую.

Года через два мне и эта роль надоела.

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

А еще через год я попал в учёный совет ШАДа и пробыл там ещё много лет.

А находясь в совете, я даже слегка зацепил движуху по открытию ФКН ВШЭ.

А в 2015 я выступил на конференции ШАД в Берлине, где получил от коллег прозвище «Доктор Майкл Ройзнер».

А ещё я всё это время ходил вольнослушателем на разные курсы ШАДа. Оказалось, что после моего выпуска появилось даже ещё больше интересных курсов, чем было вначале. Причем настолько интересных, что можно даже отвлечься от работы и пойти в соседнее здание послушать лекцию раз в неделю.

Одним словом, трудно переоценить, сколько полезных знаний и знакомств мне дал ШАД. Я не знаю, как бы сложилась моя карьера (да и личная жизнь, чего уж там 😁), если бы не он. Наверняка не так интересно.

💛🔴⬛

#lifestories

Я уже пару раз писал про счётчики и про то, как убирать из них смещение. Но так и не затронул некоторые важные технические моменты. А именно — что счётчики занимают место в профилях пользователей и объектов. (Профиль объекта — это вся накопленная информация про объект; он не обязательно должен быть физически одной структурой.) И это значит, что мы не можем хранить бесконечное число счётчиков. Например, если профиль пользователя занимает 1 Мб, то с этим уже довольно сложно работать в realtime-системе.

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

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

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

Кстати, в нашей платформе в Яндексе мы сделали более эффективную по месту реализацию фильтра — quotient filter.

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

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

Можно! Это называется count-min sketch, и это простое обобщение фильтра Блума (counting Bloom filter) с той же самой идеей использовать несколько хеш-функций. И, кстати, с экспоненциальным затуханием прекрасно совмещается.

К сожалению, у меня нет практического опыта с этим, чтобы сказать — эффективнее ли для фичей использовать count-min sketch или обычное обрезание счётчиков.