Привет, Хабр! Меня зовут Иван Воробьев, я работаю в команде рекомендаций VK Видео, AI VK. В данной статье хочу рассказать, как и зачем я переделывал систему построения I2I-рекомендаций. Поговорим о том, какие решения были поставлены в её основу, насколько они оправдались, а также причём тут якори и как они связаны со свежестью рекомендаций. 

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

Что такое I2I, или как отделить машины от котиков  

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

Предположим, что пользователь провзаимодействовал с двумя видео, одно из которых - про котиков, а второе – про машины. Если построить эмбеддинг пользователя как среднее между эмбеддингами этих видео, и потом найти к нему ближайшее видео, то им может оказаться, например, произвольное юмористическое видео. Так получается, поскольку тот самый эмбеддинг пользователя оказался в достаточно произвольной точке векторного пространства, и конкретно это видео оказалось ближе к ней, чем оба исходных или им подобные. С тем же успехом там могли попасться, например, новости. Как же тогда подобрать что-то более релевантное?

Например, можно искать видео, похожие на просмотренные пользователем документы-якори. Но искать похожие по эмбеддингу для каждого просмотренного пользователем видео будет достаточно долго. Впрочем, тут можно воспользоваться тем, что список этих похожих не зависит от самого пользователя. Значит, что такие списки (далее – I2I-рекомендации) можно построить оффлайн, и в рантайме просто доставать готовые результаты.

Общая схема: было и стало 

Подобные I2I-рекомендации уже использовались в Дзене, и я внедрял их в VK Видео и VK Клипы, но они имели несколько существенных недостатков. Например, эти рекомендации строились для небольшого множества наиболее популярных якорей, долго доставлялись до рантайма, неэффективно использовали ресурсы, да и в принципе сильно отличался от основных рекомендательных технологий. Для исправления этих недостатков и было принято решение сделать новую систему построения I2I-рекомендаций.

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

Документы, похожие и интересные

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

Релевантность – это метрика схожести самих документов, без учёта взаимодействий с ними. Модель для оценки релевантности обучается на специальной разметке, а порог для неё подбирается такой, чтобы релевантность итоговой выдачи была достаточной (обычно - в районе 80%-90%, но может отличаться для разных задач). Собственно, фильтрация по релевантности выполняет роль регуляризации, не позволяющей ранжированию вытащить произвольные документы с хорошей статистикой для неподходящих якорей.

Для ранжирования применять релевантность можно, и порой даже оправдано (для свежих документов, например), но в большинстве случаев эффективность этого подхода достаточно сомнительна. Например, наиболее релевантной к какому-то видео будет его перезаливка, но маловероятно, что пользователю захочется эту перезаливку смотреть. Поэтому для ранжирования используется модель аттрактивности, обученная на взаимодействиях пользователя с рекомендованным по I2I документами. 

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

Быстро работает, удобно настраивается

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

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

Похожесть бывает разная, или как смешать несмешиваемое

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

Например, для VK Видео я сделал отдельные I2I-рекомендации по контентным и коллаборативным данным. Кроме того, для свежих документов нужно набирать коллаборативные данные, для чего я добавлял I2I-рекомендации по отдельному критерию. Так и достигается необходимая гибкость - для разных случаев можно использовать разные конфигурации I2I-рекомендера. 

Якори, полезные и не очень

И вот, реализован I2I-рекомендер, осталось только запросить из него рекомендации к подходящим якорям. Но VK Видео есть более миллиарда разных видео. Полный цикл на них займет почти неделю с целевой скоростью обработки в 2000 якорей в секунду, что как-то не очень вяжется с требованием к реактивности обновления рекомендаций. Чтобы достичь нужной реактивности, я добавил якорям приоритеты, с целью строить I2I-рекомендации для этих якорей с пропорциональной их приоритету частотой.

Какие же якори нужно обрабатывать в первую очередь? Я вижу два основных повода перестроить I2I-рекомендации для якоря: изменились данные по якорю, и изменились данные по кандидатам. Из этой мысли родилась простая формула для приоритетов:

Тут – характерный период свежести документа, – текущее время, – время публикации документа-якоря, – различные счётчики по якорю (в частности, показы за последний день для учёта изменения данных якоря и популярность за большой срок для учёта изменений кандидатов), а и – это настраиваемые коэффициенты. Таким образом, оба фактора учтены: рекомендации для популярных якорей обновляются часто, и для свежих тоже достраиваются реактивно.  

Собираем патроны, обстреливаем рекомендер

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

Тут – уже приоритет якоря, – ограничение на учитываемое время с последнего пересчета, – текущее время, и – время последней обработки якоря. Таким образом, построение I2I-рекомендаций производится по своеобразной спирали: раз за разом она будет проходить по наиболее приоритетным якорям, но каждый раз заходить дальше и дальше…

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

Каждому – по списку

И вот, получилась готовая система построения I2I-рекомендаций, достаточно реактивная, легко масштабируемая, и весьма гибкая, чего и хотелось достичь. Осталось самое главное – построенные рекомендации отдавать в рантайме. Чтобы доставать миллионы раз в секунду списки документов для сотен миллионов разных якорей, надо хранить в памяти каждого сервера I2I-рекомендации для наиболее нужных якорей, и недостающее запрашивать из внешних хранилищ. Для этого я тоже приспособил приоритеты – по ним определяются наилучшие якори для хранения в памяти. Практика показала, что пары десятков миллионов якорей хватает, чтобы покрыть 97% позитивных взаимодействий пользователей в VK Видео, оставшиеся же 3% можно получить и по сети.

Внезапные проблемы на финишной прямой

Казалось бы, на этом проект и заканчивается, осталось лишь эксперимент провести. Тем не менее, внезапно образовалась проблема с обогащением якорей данными. Для этого используется фактор-прокси, отдельный конфигурируемый сервис для унификации запроса данных из разных источников, и его пропускная способность составила с десяток запросов (по одному якорю!) в секунду, что было сильно меньше целевого показателя в 2000 якорей в секунду. Поэтому мне пришлось всё же отойти от изначальной концепции с запросом данных по каждому якорю, и реализовать запрос данных для набора якорей из планировщика, нарезку данные на отдельные запросы, и последующую отправку их в рекомендер по одному. Для достижения целевой пропускной способности этого оказалось достаточно. Правда, поякорный запрос данных я всё же оставил, и он пригодился несколько раз во время проблем с хранилищами данных. 

Не только свежесть, но и экономия

Суммарно, на реализацию и внедрение в VK Видео всего вышеописанного ушло у меня около полугода, с учётом проведения экспериментов и полного перехода на новую систему. Существенного изменения продуктовых метрик не было, но такая и была цель. Зато получилось сэкономить приличные вычислительные ресурсы. Новая схема потребляет примерно 2000 ядер базового рекомендера (и пару сотен на остальные сервисы) для обеспечения целевой пропускной способности I2I-рекомендера в 2000 якорей в секунду для VK Видео, чего оказалось достаточно для обеспечения свежести I2I-рекомендаций порядка часа. Для сравнения, старая схема для VK Видео потребляла примерно 6000 ядер, чтобы обеспечивать примерно трехчасовую свежесть I2I-рекомендаций.

Помимо этого, новая систем позволила заметно упростить добавление новых типов I2I-рекомендаций, а также внедрение I2I в другие продукты. В частности, мне потребовалось порядка недели, чтобы внедрить новый I2I-контур в VK Клипы, так что цели по гибкости получившегося решения можно в целом считать достигнутыми. Впоследствии, новая система внедрялась и в другие продукты (например, в VK Музыку) моими коллегами, но это уже совсем другая история.