В реальных системах итоговые рекомендации строятся не только машинно-обученными моделями, но и с учётом некоторых эвристических правил. Их называют продуктовыми правилами, бизнес-правилами или просто костылями 🙂
Например:
- нельзя рекомендовать треки одного и того же исполнителя слишком часто;
- надо вставлять в ленту документы из подписок, но при этом не заполонять ими всю ленту;
- если пользователь уже дизлайкал какую-то категорию или автора, то соответствующие документы нужно пенализировать или вообще фильтровать;
- нельзя рекомендовать откровенный контент (кроме специальных случаев).
Правила бывают двух видов: жесткие и мягкие. Жесткие правила — это фильтры, они запрещают рекомендовать какие-то документы в каком-то контексте, иначе это будет восприниматься как баг продукта. В таких правилах нет ничего плохого. Их количество просто нужно ограничивать. Кроме того, их нужно применять на как можно более ранней стадии ранжирования (генерации кандидатов или даже построения индекса). Мягкие же правила имеют такой вид: рекомендовать такое можно, но нежелательно или не слишком много (или наоборот, рекомендовать такое надо больше). Если таких правил становится много, то отлаживать и развивать систему становится очень сложно.
Правила — это техдолг.
Количество таких правил в системе, как мне кажется, часто зависит от соотношения сил в команде: продактам удобнее выражать ограничения через правила, а инженеры обычно такие костыли не любят. В своей прошлой команде я гордился тем, что нам удавалось сводить количество таких правил к минимуму.
На своей практике я достаточное количество раз сталкивался с общим симптомом. У инженерной команды не получалось обучить систему так, чтобы рекомендации были хорошими (в целом или в каком-то конкретном аспекте). Продуктовой команде после этого ничего не остаётся, кроме как лечить такие проблемы тем способом, которым она умеет, — добавлением новых правил. Когда проблему нужно решать быстро, такие заплатки вполне оправданы. Но выпиливать их потом сложно. И система часто так и застревает в заплаточном состоянии, пока не произойдёт большой рефакторинг. Всё как с обычным техдолгом.
Мораль — не скупитесь на сильных инженеров 🙂
В идеальной системе таких правил быть не должно, всю нечёткую логику должна выполнять достаточно продвинутая модель. Я мечтаю, что когда-нибудь мы доживём до такого состояния технологий (и у меня есть гипотеза, как именно этого добиться). Но на текущий момент это малореалистично. Поэтому вместо того, чтобы полностью запрещать такие правила, в следующем посте я расскажу о подходе, который позволяет хоть немного их упорядочивать и ограничивать хаос.
(Я хотел и в этом посте написать про этот подход, но Телеграм ограничивает длину постов. Возможно, это и к лучшему.)
Например:
- нельзя рекомендовать треки одного и того же исполнителя слишком часто;
- надо вставлять в ленту документы из подписок, но при этом не заполонять ими всю ленту;
- если пользователь уже дизлайкал какую-то категорию или автора, то соответствующие документы нужно пенализировать или вообще фильтровать;
- нельзя рекомендовать откровенный контент (кроме специальных случаев).
Правила бывают двух видов: жесткие и мягкие. Жесткие правила — это фильтры, они запрещают рекомендовать какие-то документы в каком-то контексте, иначе это будет восприниматься как баг продукта. В таких правилах нет ничего плохого. Их количество просто нужно ограничивать. Кроме того, их нужно применять на как можно более ранней стадии ранжирования (генерации кандидатов или даже построения индекса). Мягкие же правила имеют такой вид: рекомендовать такое можно, но нежелательно или не слишком много (или наоборот, рекомендовать такое надо больше). Если таких правил становится много, то отлаживать и развивать систему становится очень сложно.
Правила — это техдолг.
Количество таких правил в системе, как мне кажется, часто зависит от соотношения сил в команде: продактам удобнее выражать ограничения через правила, а инженеры обычно такие костыли не любят. В своей прошлой команде я гордился тем, что нам удавалось сводить количество таких правил к минимуму.
На своей практике я достаточное количество раз сталкивался с общим симптомом. У инженерной команды не получалось обучить систему так, чтобы рекомендации были хорошими (в целом или в каком-то конкретном аспекте). Продуктовой команде после этого ничего не остаётся, кроме как лечить такие проблемы тем способом, которым она умеет, — добавлением новых правил. Когда проблему нужно решать быстро, такие заплатки вполне оправданы. Но выпиливать их потом сложно. И система часто так и застревает в заплаточном состоянии, пока не произойдёт большой рефакторинг. Всё как с обычным техдолгом.
Мораль — не скупитесь на сильных инженеров 🙂
В идеальной системе таких правил быть не должно, всю нечёткую логику должна выполнять достаточно продвинутая модель. Я мечтаю, что когда-нибудь мы доживём до такого состояния технологий (и у меня есть гипотеза, как именно этого добиться). Но на текущий момент это малореалистично. Поэтому вместо того, чтобы полностью запрещать такие правила, в следующем посте я расскажу о подходе, который позволяет хоть немного их упорядочивать и ограничивать хаос.
(Я хотел и в этом посте написать про этот подход, но Телеграм ограничивает длину постов. Возможно, это и к лучшему.)