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

Конечно, мы привыкли к тому, что у нас есть метрики. Если north star растёт, а guardrail-метрики не падают — значит, всё хорошо. Так?

К сожалению, часто так бывает, что приходит топ-менеджер и, не смотря ни на какие метрики, жалуется: «Какого черта вы порекомендовали мне ЭТО? Ваш алгоритм никуда не годится!» Знакомо? Особенно это распространено среди авторитарных руководителей (я за свою карьеру троих-четверых таких застал). Я также видел многих сильных инженеров, которые, устав именно от таких набросов, больше не хотели заниматься рекомендациями вообще.

Как реагировать на такие набросы? Есть две крайности. Первая — игнорировать их и говорить, что мнение одного (не)случайного пользователя не имеет никакой силы по сравнению со статистикой. Вторая — паниковать из-за того, что топ-менеджер недоволен, и быстро фиксить нежелательное поведение очередным костылём (в максимальном варианте — по условию конкретного user_id).

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

Не надо так. А как надо?

➡️ Попытаться сформулировать проблему в более общих терминах и оценить её массовость. Например: часто рекомендуем мужчинам женские товары.
➡️ Если она массовая и фиксить её нужно срочно — можно и костылём. Но потом сразу же заменять его на более долгосрочное решение (как бы наивно это ни звучало).
➡️ Как и в медицине, самое главное — поставить правильный диагноз, т.е. определить root cause. И сильные команды отличаются от слабых именно тем, насколько хорошо они умеют это делать.
➡️ В частности, надо определить в каком компоненте проблема. Для этого надо четко понимать, какой компонент за что именно отвечает.
➡️ Например, часто проблему объясняют тем, из какого источника кандидатов пришёл порекомендованный объект. Но это — как «искать под фонарём». Такое объяснение очень простое, однако это не root cause. Отсутствие плохих кандидатов — не задача этой стадии. Это задача ранжирования.
➡️ Дебаг ранжирующей модели — вещь сложная. В общем случае — не решаемая. Однако часто достаточно просто посмотреть на входы и выходы и увидеть, что что-то сломано. Например, какие-то фичи.
➡️ Полезно посмотреть на статистики по интересующему срезу: метрики ошибок и откалиброванность модели (среднее предсказание минус средний таргет).
➡️ Иногда полезно найти в истории пользователя самый похожий объект на порекомендованный. Это может указать на проблему в сборе истории.
➡️ Для такого дебага важно иметь подходящие тулзы.
➡️ Стоит задуматься: это ошибка системы или несогласованность оптимизируемой метрики желаемым впечатлениям? Частый философский вопрос: «вам шашечки или ехать?» Таймспент/деньги или вайб? И почти всегда в моей практике в качестве north star выбирали не ту метрику, которая более согласована с воспринимаемым качеством. Но в то же время чаще всего проблема не в этом. А в ошибке системы.
➡️ Надо заводить метрики, показывающие подобные проблемы. Например, свежесть контента. Или популярность. Вот только совсем не всегда их надо напрямую оптимизировать. Чаще всего проблема в том, что система плохо оптимизирует основную метрику.
➡️ Кстати, топ-менеджеры обычно не дураки и сами не очень хотят, чтобы в систему добавляли костыли. Они понимают, что AI/ML-системы должны работать не по ручным правилам (если нет, то у вас более серьёзная проблема). Чем лучше они понимают архитектуру системы и ее текущие проблемы, тем проще преодолеть возможный кризис недоверия метрикам. Повышайте прозрачность.
➡️ А ещё надо стремиться получать такие баг-репорты не от топ-менеджеров. Надо пользоваться своим продуктом. Надо активно собирать фидбек. И регулярно (не в авральном режиме) его дебажить.