Wazowski Recommends

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

Мы будем здесь рассматривать последнюю стадию ранжирования — когда осталось уже не слишком много документов (скажем, от нескольких десятков до пары сотен) и мы хотим из них набрать наилучший набор. Эта стадия примечательна тем, что мы пытаемся не просто как можно точнее оценить каждый документ в текущем контексте, но и учитывать сочетаемость документов друг с другом. Именно в этот момент начинается listwise-ранжирование (не путать с listwise-обучением для learning-to-rank, в котором только лосс-функция зависит от всех документов в запросе, но не ранжирующая функция). Типичное применение этого listwise-подхода — повышение разнообразия выдачи.

Вот основные принципы подхода.

1. Мы будем строить выдачу итеративно от первой позиции до последней. На каждой итерации мы будем выбирать наилучший (в каком-то смысле) документ для очередной позиции. Более-менее все подходы к переранжированию, которые я знаю, включая известный алгоритм разнообразия DPP, именно так и работают. Если выдача имеет нелинейный вид, то позиции можно упорядочить по значимости.

2. На каждой итерации мы берём все оставшиеся документы и сортируем их по некоторой функции полезности, value function. Это может быть как нечто простое, вроде выхода кликовой модели, до более сложного: комбинация нескольких выходов модели (или нескольких моделей), предсказывающих разные события, компоненты разнообразия (сходство с предыдущими документами), ручные бусты и т.д. Value function может перевычисляться на каждой итерации и поэтому — зависеть от позиции и от уже набранных в итоговую выдачу документов. Она должна относительно быстро вычисляться. Правильный дизайн такой функции — отдельная богатая тема, фреймворк это никак не ограничивает (и поэтому не снижает сложности).

3. Продуктовые правила выражаются в таком виде: на подмножестве позиций X количество документов со свойством f должно быть не меньше или не больше порога C. Обычно X — это начальный отрезок позиций, например от 1 до 10 (первая страница). Свойство f лучше всего выражать пороговым правилом какой-то фичи, т.е. [feature(doc) > threshold]. Если требуется, можно этот формат обобщить и до небинарных свойств.

4. Правила имеют приоритет. Если мы не можем выполнить все правила, то отбрасываем наименее приоритетные. А точнее: если на данной позиции самое приоритетное правило выполнимо, то оно точно будет выполнено, иначе — не будет. Если правило со следующим приоритетом выполнимо в этих условиях, то оно будет выполнено, иначе — пропускаем. И так далее. Т.е. выбираем старшую в лексикографическом порядке маску выполненных правил.

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

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

Стоит также заметить, что правила вида “на первых 10 позициях должно быть хотя бы 5 документов с каким-то свойством” будут приводить к тому, что на первых 5 позициях будут документы без этого свойства, а на следующих 5 — с ним. Чтобы сделать это более равномерно, надо добавить правила на промежуточные отрезки: на первых 2 позициях хотя бы 1, на первых 4 — хотя бы 2, и так далее.

Конечно, повышению debuggability и контролируемости системы сильно способствует логирование всех выполненных и невыполненных правил.

Telegram

Wazowski Recommends

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

www.tgoop.com/WazowskiRecommends/18

2.2K viewsedited  Aug 13, 2023 at 10:00

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

Мы будем здесь рассматривать последнюю стадию ранжирования — когда осталось уже не слишком много документов (скажем, от нескольких десятков до пары сотен) и мы хотим из них набрать наилучший набор. Эта стадия примечательна тем, что мы пытаемся не просто как можно точнее оценить каждый документ в текущем контексте, но и учитывать сочетаемость документов друг с другом. Именно в этот момент начинается listwise-ранжирование (не путать с listwise-обучением для learning-to-rank, в котором только лосс-функция зависит от всех документов в запросе, но не ранжирующая функция). Типичное применение этого listwise-подхода — повышение разнообразия выдачи.

Вот основные принципы подхода.

1. Мы будем строить выдачу итеративно от первой позиции до последней. На каждой итерации мы будем выбирать наилучший (в каком-то смысле) документ для очередной позиции. Более-менее все подходы к переранжированию, которые я знаю, включая известный алгоритм разнообразия DPP, именно так и работают. Если выдача имеет нелинейный вид, то позиции можно упорядочить по значимости.

2. На каждой итерации мы берём все оставшиеся документы и сортируем их по некоторой функции полезности, value function. Это может быть как нечто простое, вроде выхода кликовой модели, до более сложного: комбинация нескольких выходов модели (или нескольких моделей), предсказывающих разные события, компоненты разнообразия (сходство с предыдущими документами), ручные бусты и т.д. Value function может перевычисляться на каждой итерации и поэтому — зависеть от позиции и от уже набранных в итоговую выдачу документов. Она должна относительно быстро вычисляться. Правильный дизайн такой функции — отдельная богатая тема, фреймворк это никак не ограничивает (и поэтому не снижает сложности).

3. Продуктовые правила выражаются в таком виде: на подмножестве позиций X количество документов со свойством f должно быть не меньше или не больше порога C. Обычно X — это начальный отрезок позиций, например от 1 до 10 (первая страница). Свойство f лучше всего выражать пороговым правилом какой-то фичи, т.е. [feature(doc) > threshold]. Если требуется, можно этот формат обобщить и до небинарных свойств.

4. Правила имеют приоритет. Если мы не можем выполнить все правила, то отбрасываем наименее приоритетные. А точнее: если на данной позиции самое приоритетное правило выполнимо, то оно точно будет выполнено, иначе — не будет. Если правило со следующим приоритетом выполнимо в этих условиях, то оно будет выполнено, иначе — пропускаем. И так далее. Т.е. выбираем старшую в лексикографическом порядке маску выполненных правил.

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

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

Стоит также заметить, что правила вида “на первых 10 позициях должно быть хотя бы 5 документов с каким-то свойством” будут приводить к тому, что на первых 5 позициях будут документы без этого свойства, а на следующих 5 — с ним. Чтобы сделать это более равномерно, надо добавить правила на промежуточные отрезки: на первых 2 позициях хотя бы 1, на первых 4 — хотя бы 2, и так далее.

Конечно, повышению debuggability и контролируемости системы сильно способствует логирование всех выполненных и невыполненных правил.

BY Wazowski Recommends