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