WAZOWSKIRECOMMENDS Telegram 28
Forwarded from Knowledge Accumulator
Как и зачем делать exploration в рекомендациях

В схеме Learning to Rank мы обучаем модель Score(user, item), выдающую оценку релевантности каждого из кандидатов. Рассмотрим пример сценария применения такой модели:

Этап кандидатогенерации, к примеру, HNSW, принёс нам 1000 кандидатов. К каждому мы применили нашу модель релевантности и получили 1000 чисел. В качестве результата выполнения запроса мы должны отдать пользователю 10 объектов. Простейшая опция - это отдать пользователю 10 объектов с наибольшей релевантностью. Но у этого есть проблема.

Дело в том, что для качественного обучения модели Score(user, item) у неё должен быть разнообразный набор данных. Если мы всем пользователям выдаём только самые релевантные треки, то может образоваться много треков, которые вообще не попадали в выдачу никому, и тогда модель на них может выдавать нереалистично маленький или большой результат - обе эти ситуации нежелательны и могут привести к плохой выдаче в будущем.

Возникает trade-off - с одной стороны, мы хотим формировать релевантную выдачу, с другой, мы хотим её немного разнообразить для улучшения качества датасета. Этот баланс на практике можно регулировать таким образом:
1) 1000 скоров кандидатов превращаются в вероятности попадания в выдачу: p = exp(score/T) / Z, где T - температура, а Z - нормировочная константа.
2) Применяется специальный алгоритм по генерации выборки из такого распределения.
Если T равна 0, мы получаем просто топ-10, и чем она больше, тем больше всё сглаживается в сторону равномерной выдачи.

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

Сначала предполагаем на глаз, какой уровень "гладкости" выдачи мы хотим. А затем уже подгоняем T, чтобы был нужный эффект, и по надобности иногда переподгоняем. Вот такая наука.

@knowledge_accumulator



tgoop.com/WazowskiRecommends/28
Create:
Last Update:

Как и зачем делать exploration в рекомендациях

В схеме Learning to Rank мы обучаем модель Score(user, item), выдающую оценку релевантности каждого из кандидатов. Рассмотрим пример сценария применения такой модели:

Этап кандидатогенерации, к примеру, HNSW, принёс нам 1000 кандидатов. К каждому мы применили нашу модель релевантности и получили 1000 чисел. В качестве результата выполнения запроса мы должны отдать пользователю 10 объектов. Простейшая опция - это отдать пользователю 10 объектов с наибольшей релевантностью. Но у этого есть проблема.

Дело в том, что для качественного обучения модели Score(user, item) у неё должен быть разнообразный набор данных. Если мы всем пользователям выдаём только самые релевантные треки, то может образоваться много треков, которые вообще не попадали в выдачу никому, и тогда модель на них может выдавать нереалистично маленький или большой результат - обе эти ситуации нежелательны и могут привести к плохой выдаче в будущем.

Возникает trade-off - с одной стороны, мы хотим формировать релевантную выдачу, с другой, мы хотим её немного разнообразить для улучшения качества датасета. Этот баланс на практике можно регулировать таким образом:
1) 1000 скоров кандидатов превращаются в вероятности попадания в выдачу: p = exp(score/T) / Z, где T - температура, а Z - нормировочная константа.
2) Применяется специальный алгоритм по генерации выборки из такого распределения.
Если T равна 0, мы получаем просто топ-10, и чем она больше, тем больше всё сглаживается в сторону равномерной выдачи.

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

Сначала предполагаем на глаз, какой уровень "гладкости" выдачи мы хотим. А затем уже подгоняем T, чтобы был нужный эффект, и по надобности иногда переподгоняем. Вот такая наука.

@knowledge_accumulator

BY Wazowski Recommends


Share with your friend now:
tgoop.com/WazowskiRecommends/28

View MORE
Open in Telegram


Telegram News

Date: |

The administrator of a telegram group, "Suck Channel," was sentenced to six years and six months in prison for seven counts of incitement yesterday. Just at this time, Bitcoin and the broader crypto market have dropped to new 2022 lows. The Bitcoin price has tanked 10 percent dropping to $20,000. On the other hand, the altcoin space is witnessing even more brutal correction. Bitcoin has dropped nearly 60 percent year-to-date and more than 70 percent since its all-time high in November 2021. Each account can create up to 10 public channels The creator of the channel becomes its administrator by default. If you need help managing your channel, you can add more administrators from your subscriber base. You can provide each admin with limited or full rights to manage the channel. For example, you can allow an administrator to publish and edit content while withholding the right to add new subscribers. So far, more than a dozen different members have contributed to the group, posting voice notes of themselves screaming, yelling, groaning, and wailing in various pitches and rhythms.
from us


Telegram Wazowski Recommends
FROM American