Wazowski Recommends

Один из важнейших типов моделей в рекомендациях на данный момент — это двух-башенные (two tower) нейросети. Они устроены так: одна часть нейросети (башня) обрабатывает всю информацию про запрос (пользователя, контекст), другая башня — про объект. Выходы этих башен — это эмббединги, которые потом перемножаются (dot product или косинус, как уже обсуждалось в этом посте). Одно из первых упоминаний применения таких сетей для рекомендаций можно найти в очень хорошей статье про YouTube. Кстати, именно эту статью я бы сейчас уже называл классикой и наиболее подходящей для входа в область рекомендаций.

Чем характерны такие сети? Они очень похожи на матричную факторизацию, которая на самом деле является частным случаем, принимая на вход только user_id и item_id. Если же сравнивать с произвольными сетями, то это ограничение на позднее связывание (не давать входам из разных башен смешиваться до самого конца) делает двух-башенные сети крайне эффективными при применении. Чтобы построить рекомендации одному пользователю, нам нужно один раз посчитать запросную башню, после чего умножить этот эмбеддинг на эмбеддинги документов, которые обычно заранее предподсчитаны. Это очень быстро. Более того, эти предподсчитанные эмбеддинги документов можно сложить в индекс (например, HNSW), чтобы по ним быстро, не проходясь по всей базе, находить хороших кандидатов.

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

Сами башни могут быть довольно навороченными. Например, в пользовательской части можно использовать механизм self-attention для обработки истории (получится трансформер для персонализации). Но чем мы платим, вводя ограничение на позднее связывание? Конечно, качеством. В том же самом attention нельзя использовать объекты, которые мы сейчас хотим оценить/порекомендовать. А ведь хотелось бы для этого как раз обратить внимание на похожие объекты в истории пользователя. Поэтому сети с ранним связыванием обычно применяют на поздних стадиях ранжирования, когда осталось несколько десятков или сотен кандидатов, а с поздним (two tower) — наоборот, на ранних стадиях и кандидато-генерации.

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

Отдельный интерес составляет лосс, с которым обучают двух-башенные сети. В принципе, их можно обучать на любой лосс с любыми таргетами и даже иметь несколько разных для разных голов (с разными эмбеддингами в каждой башне). Но один интересный вариант — это обучение с softmax-лоссом на in-batch негативах. Для каждой пары запрос-документ из датасета берутся остальные документы в том же мини-батче и в паре с тем же запросом используются как негативы в softmax loss. Это очень эффективный вариант hard negative mining.

Но важно иметь в виду вероятностную интерпретацию такого лосса (далеко не все её понимают). У обученной сети
exp(score(q, d)) ~ P(q, d) / (P(q) * P(d)) = P(d | q) / P(d),
т.е. экспонента скора будет пропорциональна не априорной вероятности документа при условии запроса, а PMI, специфичности для запроса. Более популярные документы в среднем не будут рекомендоваться чаще такой моделью, потому что во время обучения они пропорционально чаще выступают и как негативы. Если использовать скор как фичу, то это даже хорошо, но вот для финального ранжирования и для кандидато-генерации это может приводить к очень специфичным, но плохим документам.

Тот же Google в статье предлагал с этим бороться с помощью logQ correction во время обучения. Мы же обычно делали это на этапе применения, а не обучения, — просто умножая на априорную вероятность документа P(d). Но мы так и не сравнивали эти подходы, а было бы интересно сравнить.

Telegram

Wazowski Recommends

Как известно, экзамен прошёл хорошо — это когда ты не просто его сдал, но ещё и узнал на нём что-то новое.

Полгода назад я собеседовался в Microsoft. На одном из собеседований мне задали вопрос, на который я не очень-то хорошо ответил. И даже когда мне сказали…

www.tgoop.com/WazowskiRecommends/22

2.5K viewsedited  Aug 27, 2023 at 11:27

Один из важнейших типов моделей в рекомендациях на данный момент — это двух-башенные (two tower) нейросети. Они устроены так: одна часть нейросети (башня) обрабатывает всю информацию про запрос (пользователя, контекст), другая башня — про объект. Выходы этих башен — это эмббединги, которые потом перемножаются (dot product или косинус, как уже обсуждалось в этом посте). Одно из первых упоминаний применения таких сетей для рекомендаций можно найти в очень хорошей статье про YouTube. Кстати, именно эту статью я бы сейчас уже называл классикой и наиболее подходящей для входа в область рекомендаций.

Чем характерны такие сети? Они очень похожи на матричную факторизацию, которая на самом деле является частным случаем, принимая на вход только user_id и item_id. Если же сравнивать с произвольными сетями, то это ограничение на позднее связывание (не давать входам из разных башен смешиваться до самого конца) делает двух-башенные сети крайне эффективными при применении. Чтобы построить рекомендации одному пользователю, нам нужно один раз посчитать запросную башню, после чего умножить этот эмбеддинг на эмбеддинги документов, которые обычно заранее предподсчитаны. Это очень быстро. Более того, эти предподсчитанные эмбеддинги документов можно сложить в индекс (например, HNSW), чтобы по ним быстро, не проходясь по всей базе, находить хороших кандидатов.

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

Сами башни могут быть довольно навороченными. Например, в пользовательской части можно использовать механизм self-attention для обработки истории (получится трансформер для персонализации). Но чем мы платим, вводя ограничение на позднее связывание? Конечно, качеством. В том же самом attention нельзя использовать объекты, которые мы сейчас хотим оценить/порекомендовать. А ведь хотелось бы для этого как раз обратить внимание на похожие объекты в истории пользователя. Поэтому сети с ранним связыванием обычно применяют на поздних стадиях ранжирования, когда осталось несколько десятков или сотен кандидатов, а с поздним (two tower) — наоборот, на ранних стадиях и кандидато-генерации.

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

Отдельный интерес составляет лосс, с которым обучают двух-башенные сети. В принципе, их можно обучать на любой лосс с любыми таргетами и даже иметь несколько разных для разных голов (с разными эмбеддингами в каждой башне). Но один интересный вариант — это обучение с softmax-лоссом на in-batch негативах. Для каждой пары запрос-документ из датасета берутся остальные документы в том же мини-батче и в паре с тем же запросом используются как негативы в softmax loss. Это очень эффективный вариант hard negative mining.

Но важно иметь в виду вероятностную интерпретацию такого лосса (далеко не все её понимают). У обученной сети
exp(score(q, d)) ~ P(q, d) / (P(q) * P(d)) = P(d | q) / P(d),
т.е. экспонента скора будет пропорциональна не априорной вероятности документа при условии запроса, а PMI, специфичности для запроса. Более популярные документы в среднем не будут рекомендоваться чаще такой моделью, потому что во время обучения они пропорционально чаще выступают и как негативы. Если использовать скор как фичу, то это даже хорошо, но вот для финального ранжирования и для кандидато-генерации это может приводить к очень специфичным, но плохим документам.

Тот же Google в статье предлагал с этим бороться с помощью logQ correction во время обучения. Мы же обычно делали это на этапе применения, а не обучения, — просто умножая на априорную вероятность документа P(d). Но мы так и не сравнивали эти подходы, а было бы интересно сравнить.

BY Wazowski Recommends