Давно веду канал, а так до сих пор и не написал про метрики ранжирования.
В рекомендациях с метриками всё непросто. Человечество не придумало идеальной офлайн-метрики. На то есть фундаментальная причина: новая модель рекомендовала бы что-то другое, чем та, которая в продакшене, и мы в точности не знаем, как пользователи бы на это отреагировали (ground truth). А именно реакция пользователей нам важнее всего.
В то же время, как известно, all models are wrong, but some are useful. И на практике все используют какие-то метрики для оценки качества моделей на исторических данных. Это позволяет хоть как-то сравнивать модели между собой, выбирать наиболее перспективные, подбирать гипер-параметры и запускать их в онлайн-эксперимент, в котором мы уже узнаем правильный ответ (на самом деле — тоже не совсем).
Если говорить про конкретные метрики (их формулы), есть разные варианты. Но они не очень сильно отличаются друг от друга, и я считаю, что можно всё упростить и считать, что есть более-менее одно семейство метрик — DCG. Многие другие метрики (например, HitRate, Recall@k, MRR) — это всё частные случаи.
Идея метрики очень простая — у каждого документа в группе есть какая-то релевантность (например, 1 у кликнутых документов, 0 — у остальных), и мы суммируем эти релевантности с дисконтированием, которое зависит от того, на какое место наша модель поставила этот документ (чем ниже отранжировала, тем меньший бонус мы получим за релевантный документ). Вид дисконтирования можно выбирать по вкусу (или по данным): логарифмическое, экспоненциальное, гармоническое, линейное, ступенчатое.
Очень часто используют нормированный вариант метрики — NDCG. Но на самом деле это чаще вредит, чем помогает. Если релевантность не бинарная (например, у клика вес 1, у лайка — 10), то NDCG забудет про разные веса, когда они не в одной группе. Т.е. поставить на первое место лайк в одной группе или клик в другой — для NDCG одно и то же.
Ещё один частный случай метрики, который лично я часто использовал на практике — это AUC. Почти тот самый всем известный ROC AUC, только посчитанный не сразу для всех примеров, а отдельно для всех групп, а потом усредненный между группами. У AUC есть хорошая интерпретация — это доля правильно отранжированнах пар объектов с разными таргетами. Если использовать эту интерпретацию, то можно даже убрать ограничение на бинарность таргета. И если задуматься, то такой AUC — тоже частный случай DCG (точнее, NDCG), просто с линейным дисконтированием.
Но конкретный вид метрики не так важен, как то, на каких примерах мы её измеряем, как их объединяем в группы и какие значения релевантности для разных событий используем.
Например, не стоит включать в примеры те объекты, которые мы порекомендовали, но пользователь не увидел. Мы не знаем реакцию пользователя на них.
Какие веса раздать разным типам действий пользователя — может сильно повлиять на итоговый результат. И это напрямую зависит от того, какую бизнес-метрику мы хотим оптимизировать. Некоторые ML-инженеры даже работают в парадигме, что эти веса даны свыше, «продакты так сказали». Но это неправильно (точнее, это правильно только в контексте работы над некоторыми компонентами рекомендательной системы).
Наконец, одна из популярных ошибок — в разбиении на более крупные группы ранжирования — по сессии или даже по пользователю. Мотивация в этом понятна, но это ведёт к проблеме — лику данных. А именно — в одной группе в фичах одних примеров (более поздних) будет содержаться информация про таргет других примеров (более ранних). Для иллюстрации, представьте датасет, в котором в сессиях по два события (при этом во втором событии в сессии в фичах учитывается итог первого события), и модель, выдающую просто историческую долю нулей у пользователя. Такая модель получит идеальное значение метрики, но не будет уметь ранжировать вообще. Поэтому разбивать лучше всего по реквестам.
Эта ошибка не всегда критична, но чем более продвинутая модель будет оптимизировать такую неправильную метрику, тем сильнее эта проблема будет проявляться.
В рекомендациях с метриками всё непросто. Человечество не придумало идеальной офлайн-метрики. На то есть фундаментальная причина: новая модель рекомендовала бы что-то другое, чем та, которая в продакшене, и мы в точности не знаем, как пользователи бы на это отреагировали (ground truth). А именно реакция пользователей нам важнее всего.
В то же время, как известно, all models are wrong, but some are useful. И на практике все используют какие-то метрики для оценки качества моделей на исторических данных. Это позволяет хоть как-то сравнивать модели между собой, выбирать наиболее перспективные, подбирать гипер-параметры и запускать их в онлайн-эксперимент, в котором мы уже узнаем правильный ответ (на самом деле — тоже не совсем).
Если говорить про конкретные метрики (их формулы), есть разные варианты. Но они не очень сильно отличаются друг от друга, и я считаю, что можно всё упростить и считать, что есть более-менее одно семейство метрик — DCG. Многие другие метрики (например, HitRate, Recall@k, MRR) — это всё частные случаи.
Идея метрики очень простая — у каждого документа в группе есть какая-то релевантность (например, 1 у кликнутых документов, 0 — у остальных), и мы суммируем эти релевантности с дисконтированием, которое зависит от того, на какое место наша модель поставила этот документ (чем ниже отранжировала, тем меньший бонус мы получим за релевантный документ). Вид дисконтирования можно выбирать по вкусу (или по данным): логарифмическое, экспоненциальное, гармоническое, линейное, ступенчатое.
Очень часто используют нормированный вариант метрики — NDCG. Но на самом деле это чаще вредит, чем помогает. Если релевантность не бинарная (например, у клика вес 1, у лайка — 10), то NDCG забудет про разные веса, когда они не в одной группе. Т.е. поставить на первое место лайк в одной группе или клик в другой — для NDCG одно и то же.
Ещё один частный случай метрики, который лично я часто использовал на практике — это AUC. Почти тот самый всем известный ROC AUC, только посчитанный не сразу для всех примеров, а отдельно для всех групп, а потом усредненный между группами. У AUC есть хорошая интерпретация — это доля правильно отранжированнах пар объектов с разными таргетами. Если использовать эту интерпретацию, то можно даже убрать ограничение на бинарность таргета. И если задуматься, то такой AUC — тоже частный случай DCG (точнее, NDCG), просто с линейным дисконтированием.
Но конкретный вид метрики не так важен, как то, на каких примерах мы её измеряем, как их объединяем в группы и какие значения релевантности для разных событий используем.
Например, не стоит включать в примеры те объекты, которые мы порекомендовали, но пользователь не увидел. Мы не знаем реакцию пользователя на них.
Какие веса раздать разным типам действий пользователя — может сильно повлиять на итоговый результат. И это напрямую зависит от того, какую бизнес-метрику мы хотим оптимизировать. Некоторые ML-инженеры даже работают в парадигме, что эти веса даны свыше, «продакты так сказали». Но это неправильно (точнее, это правильно только в контексте работы над некоторыми компонентами рекомендательной системы).
Наконец, одна из популярных ошибок — в разбиении на более крупные группы ранжирования — по сессии или даже по пользователю. Мотивация в этом понятна, но это ведёт к проблеме — лику данных. А именно — в одной группе в фичах одних примеров (более поздних) будет содержаться информация про таргет других примеров (более ранних). Для иллюстрации, представьте датасет, в котором в сессиях по два события (при этом во втором событии в сессии в фичах учитывается итог первого события), и модель, выдающую просто историческую долю нулей у пользователя. Такая модель получит идеальное значение метрики, но не будет уметь ранжировать вообще. Поэтому разбивать лучше всего по реквестам.
Эта ошибка не всегда критична, но чем более продвинутая модель будет оптимизировать такую неправильную метрику, тем сильнее эта проблема будет проявляться.
👍39🔥8❤1
С начала 2012 года (где-то в период «map к новому году») я начал заниматься одним из любимых видов спорта (чем-то напоминающим спортивное программирование) — хождением по собеседованиям. В ту пору бигтех-компании периодически приезжали в Москву с hiring event-ами. Сначала я успешно прособеседовался в Бинг (и отказался потом от оффера). А вот с Амазоном у меня не получилось. Во-первых, в этот раз они прицельно нанимали в AWS, а я на каждом собеседовании на вопросы общего характера отвечал, что хотел бы заниматься ML. Во-вторых, я провалил оба систем-дизайна (не уверен, что он тогда уже так назывался): не спроектировал ни систему парковки, ни диспетчеризацию лифтов. Даже не понял, что вообще от меня хотят. И очень негодовал от таких бессмысленных секций.
И я, и многие мои знакомые действительно воспринимали это как вид спорта. Но параллельно я попробовал пойти за своей старой мечтой и собеседоваться в Гугл — уже с серьёзными намерениями. Тогда ещё был офис в Москве.
Месяца через три меня обрадовали оффером. А я «обрадовал» Макса и Лену Бунину тем, что хочу уходить. Макс понимал, что меня надо отпустить из команды YT (на самом деле, его и самого в это же время хантили в Гугл). Но Лена не была готова отпустить меня просто так из Яндекса и попыталась найти мне более удачное место.
Несколько недель я встречался с разными командами Яндекса, а также несколько раз ездил в офис Гугла, чтобы узнать, что же конкретно мне предлагают там.
Среди команд в Яндексе чего-то зажигательного для меня не нашлось.
А вот в Гугл меня звали в команду Пети Митричева (первая ракетка мира в спортивном программировании на тот момент). Но только на вопрос, каким проектом я буду там заниматься, всё, что мне смогли ответить: это проект, связанный с ML. И на вопрос, хотя бы на каком языке надо будет программировать, ответили, что в Гугле, как известно, используют C++, Java и Python (Go тогда ещё не было), поэтому — «на каком-то подмножестве из этих трёх языков». Ладно, потом Петя сжалился и раскрыл страшный секрет, что Java в этом подмножестве нет.
Как-то в процессе обсуждений я обмолвился Лене, что у меня вообще-то есть давняя мечта сделать рекомендательный сервис. (Напомню, что никаких рекомендаций в Яндексе тогда ещё не было.) Она предложила мне описать эту идею текстом. И я написал документ. Показал его Лене и ещё одному другу. Им вроде понравилось. Лена даже решила показать этот документ Аркадию Воложу.
Но Волож, прочитав его, высказал только претензию Лене:
А могли бы сейчас жить в мире с нормальной системой рекомендаций!
И всё-таки Лена смогла найти одну команду, которая как раз в перспективе хотела заниматься рекомендациями — рекомендациями фильмов.
Настал первый в моей карьере момент серьёзного выбора — выбора 2012. Пойти в компанию мечты, в сильную команду, но заниматься неизвестно чем на «каком-то подмножестве из трёх языков», или же остаться в Яндексе и заниматься задачей, о которой давно мечтал.
Компания мечты или задача мечты?
Я выбрал задачу.
Кажется, не прогадал. Но A/B-тестов в нашей жизни не бывает. Поэтому могу только сказать, что не жалею о своём выборе.
#lifestories
И я, и многие мои знакомые действительно воспринимали это как вид спорта. Но параллельно я попробовал пойти за своей старой мечтой и собеседоваться в Гугл — уже с серьёзными намерениями. Тогда ещё был офис в Москве.
Месяца через три меня обрадовали оффером. А я «обрадовал» Макса и Лену Бунину тем, что хочу уходить. Макс понимал, что меня надо отпустить из команды YT (на самом деле, его и самого в это же время хантили в Гугл). Но Лена не была готова отпустить меня просто так из Яндекса и попыталась найти мне более удачное место.
Несколько недель я встречался с разными командами Яндекса, а также несколько раз ездил в офис Гугла, чтобы узнать, что же конкретно мне предлагают там.
Среди команд в Яндексе чего-то зажигательного для меня не нашлось.
А вот в Гугл меня звали в команду Пети Митричева (первая ракетка мира в спортивном программировании на тот момент). Но только на вопрос, каким проектом я буду там заниматься, всё, что мне смогли ответить: это проект, связанный с ML. И на вопрос, хотя бы на каком языке надо будет программировать, ответили, что в Гугле, как известно, используют C++, Java и Python (Go тогда ещё не было), поэтому — «на каком-то подмножестве из этих трёх языков». Ладно, потом Петя сжалился и раскрыл страшный секрет, что Java в этом подмножестве нет.
Как-то в процессе обсуждений я обмолвился Лене, что у меня вообще-то есть давняя мечта сделать рекомендательный сервис. (Напомню, что никаких рекомендаций в Яндексе тогда ещё не было.) Она предложила мне описать эту идею текстом. И я написал документ. Показал его Лене и ещё одному другу. Им вроде понравилось. Лена даже решила показать этот документ Аркадию Воложу.
Но Волож, прочитав его, высказал только претензию Лене:
Почему у вас сильные разработчики занимаются какой-то фигней, а не качество поиска улучшают?
А могли бы сейчас жить в мире с нормальной системой рекомендаций!
И всё-таки Лена смогла найти одну команду, которая как раз в перспективе хотела заниматься рекомендациями — рекомендациями фильмов.
Настал первый в моей карьере момент серьёзного выбора — выбора 2012. Пойти в компанию мечты, в сильную команду, но заниматься неизвестно чем на «каком-то подмножестве из трёх языков», или же остаться в Яндексе и заниматься задачей, о которой давно мечтал.
Компания мечты или задача мечты?
Я выбрал задачу.
Кажется, не прогадал. Но A/B-тестов в нашей жизни не бывает. Поэтому могу только сказать, что не жалею о своём выборе.
#lifestories
❤57👍26🔥10😱1
Когда работаешь над рекомендательным сервисом, одна из самых частых и сложных проблем — понять (и договориться с остальными), что такое хорошие рекомендации.
Конечно, мы привыкли к тому, что у нас есть метрики. Если north star растёт, а guardrail-метрики не падают — значит, всё хорошо. Так?
К сожалению, часто так бывает, что приходит топ-менеджер и, не смотря ни на какие метрики, жалуется: «Какого черта вы порекомендовали мне ЭТО? Ваш алгоритм никуда не годится!» Знакомо? Особенно это распространено среди авторитарных руководителей (я за свою карьеру троих-четверых таких застал). Я также видел многих сильных инженеров, которые, устав именно от таких набросов, больше не хотели заниматься рекомендациями вообще.
Как реагировать на такие набросы? Есть две крайности. Первая — игнорировать их и говорить, что мнение одного (не)случайного пользователя не имеет никакой силы по сравнению со статистикой. Вторая — паниковать из-за того, что топ-менеджер недоволен, и быстро фиксить нежелательное поведение очередным костылём (в максимальном варианте — по условию конкретного user_id).
Как нетрудно догадаться, ни первая, ни вторая крайности не приведут вас к успеху. Вероятно, во второй можно чуть дольше продержаться, не потеряв работу. Но в ней вы очень быстро придёте в ситуацию, когда в системе более сотни бизнес-правил (ситуация из жизни), никто в точности не понимает, как вся система работает целиком, и уж тем более — как её дальше развивать.
Не надо так. А как надо?
➡️ Попытаться сформулировать проблему в более общих терминах и оценить её массовость. Например: часто рекомендуем мужчинам женские товары.
➡️ Если она массовая и фиксить её нужно срочно — можно и костылём. Но потом сразу же заменять его на более долгосрочное решение (как бы наивно это ни звучало).
➡️ Как и в медицине, самое главное — поставить правильный диагноз, т.е. определить root cause. И сильные команды отличаются от слабых именно тем, насколько хорошо они умеют это делать.
➡️ В частности, надо определить в каком компоненте проблема. Для этого надо четко понимать, какой компонент за что именно отвечает.
➡️ Например, часто проблему объясняют тем, из какого источника кандидатов пришёл порекомендованный объект. Но это — как «искать под фонарём». Такое объяснение очень простое, однако это не root cause. Отсутствие плохих кандидатов — не задача этой стадии. Это задача ранжирования.
➡️ Дебаг ранжирующей модели — вещь сложная. В общем случае — не решаемая. Однако часто достаточно просто посмотреть на входы и выходы и увидеть, что что-то сломано. Например, какие-то фичи.
➡️ Полезно посмотреть на статистики по интересующему срезу: метрики ошибок и откалиброванность модели (среднее предсказание минус средний таргет).
➡️ Иногда полезно найти в истории пользователя самый похожий объект на порекомендованный. Это может указать на проблему в сборе истории.
➡️ Для такого дебага важно иметь подходящие тулзы.
➡️ Стоит задуматься: это ошибка системы или несогласованность оптимизируемой метрики желаемым впечатлениям? Частый философский вопрос: «вам шашечки или ехать?» Таймспент/деньги или вайб? И почти всегда в моей практике в качестве north star выбирали не ту метрику, которая более согласована с воспринимаемым качеством. Но в то же время чаще всего проблема не в этом. А в ошибке системы.
➡️ Надо заводить метрики, показывающие подобные проблемы. Например, свежесть контента. Или популярность. Вот только совсем не всегда их надо напрямую оптимизировать. Чаще всего проблема в том, что система плохо оптимизирует основную метрику.
➡️ Кстати, топ-менеджеры обычно не дураки и сами не очень хотят, чтобы в систему добавляли костыли. Они понимают, что AI/ML-системы должны работать не по ручным правилам (если нет, то у вас более серьёзная проблема). Чем лучше они понимают архитектуру системы и ее текущие проблемы, тем проще преодолеть возможный кризис недоверия метрикам. Повышайте прозрачность.
➡️ А ещё надо стремиться получать такие баг-репорты не от топ-менеджеров. Надо пользоваться своим продуктом. Надо активно собирать фидбек. И регулярно (не в авральном режиме) его дебажить.
Конечно, мы привыкли к тому, что у нас есть метрики. Если north star растёт, а guardrail-метрики не падают — значит, всё хорошо. Так?
К сожалению, часто так бывает, что приходит топ-менеджер и, не смотря ни на какие метрики, жалуется: «Какого черта вы порекомендовали мне ЭТО? Ваш алгоритм никуда не годится!» Знакомо? Особенно это распространено среди авторитарных руководителей (я за свою карьеру троих-четверых таких застал). Я также видел многих сильных инженеров, которые, устав именно от таких набросов, больше не хотели заниматься рекомендациями вообще.
Как реагировать на такие набросы? Есть две крайности. Первая — игнорировать их и говорить, что мнение одного (не)случайного пользователя не имеет никакой силы по сравнению со статистикой. Вторая — паниковать из-за того, что топ-менеджер недоволен, и быстро фиксить нежелательное поведение очередным костылём (в максимальном варианте — по условию конкретного user_id).
Как нетрудно догадаться, ни первая, ни вторая крайности не приведут вас к успеху. Вероятно, во второй можно чуть дольше продержаться, не потеряв работу. Но в ней вы очень быстро придёте в ситуацию, когда в системе более сотни бизнес-правил (ситуация из жизни), никто в точности не понимает, как вся система работает целиком, и уж тем более — как её дальше развивать.
Не надо так. А как надо?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥62✍17❤13💯7👏1
Forwarded from Свет из чёрного ящика
Во что мы верим: Scaling Hypothesis (часть 1)
В области рекомендательных систем до сих пор существует довольно большой скепсис к масштабированию нейросетей. Мы же в команде верим, что рост вычислительной сложности алгоритмов - это путь прогресса. В этом посте попробую снизить уровень скепсиса к скейлингу в сообществе. Заметка обзорная, об отдельных тезисах и конкретных статьях поговорим в следующий раз.
Вообще я и сам 3 года назад был был большим скептиком масштабирования, особенно в рекомендательных системах. Сама идея, что для выдающегося результата надо меньше изобретать хитрые алгоритмы и больше жечь ресурсы кажется слишком глупой, чтобы работать. На практике же каждое следующее поколение моделей работает всё лучше и требует всё больше вычислений. Рекомендательные системы прошли такой же путь: от счётчиков через матричные факторизации к нейросетям.
Почему скейлинг работает? Вопрос, на который довольно много разнообразных ответов: от очень философских до инженерных (Explaining Neural Scaling Laws). Начать погружение в мир масштабирования рекомендую с 2 эссе: The Bitter Lesson и The Scaling Hypothesis. Во втором Гверн даёт классную интуицию претрейну, критикует скепткиков скейлинга, а ещё у него есть классная подборка статей про MLP "representing a possible future Bitter Lesson".
Можно не пытаться задаваться вопросом "почему", а просто наблюдать эмпирические свойства - большие модели уже давно доминируют во многих ML областях:
- NLP: Deep Learning Scaling is Predictable, Empirically, Scaling Laws for Neural Language Models
- CV: Scaling Vision Transformers
- Speech: Better speech synthesis through scaling
Выше я специально привожу статьи, в которых используются трансформеры, чтобы дополнительно усилить тезис: дело не в очень сложной, хитрой нейронной архитектуре. Да, подбор правильной функции активации может выиграть нам несколько процентов качества и мы обязательно его делаем в нашей повседневной работе, однако он никогда не улучшит модель многократно. Революционные изменения достигаются в основном через вложения компьюта, причём даже в весьма простую архитектуру.
"Тупое" изменение гипрепараметров конфига на самом деле представляет из себя нетривиальную инженерную задачу. Каждый следующий порядок размера вызывает следующего порядка сложности, которые приходится преодолевать. Кроме того, масштабируемость архитектуры надо ещё обеспечить: сформулировать правильную оптимизационную задачу, сформировать датасет. Об этом поговорим во второй части заметки.
В области рекомендательных систем до сих пор существует довольно большой скепсис к масштабированию нейросетей. Мы же в команде верим, что рост вычислительной сложности алгоритмов - это путь прогресса. В этом посте попробую снизить уровень скепсиса к скейлингу в сообществе. Заметка обзорная, об отдельных тезисах и конкретных статьях поговорим в следующий раз.
Вообще я и сам 3 года назад был был большим скептиком масштабирования, особенно в рекомендательных системах. Сама идея, что для выдающегося результата надо меньше изобретать хитрые алгоритмы и больше жечь ресурсы кажется слишком глупой, чтобы работать. На практике же каждое следующее поколение моделей работает всё лучше и требует всё больше вычислений. Рекомендательные системы прошли такой же путь: от счётчиков через матричные факторизации к нейросетям.
Почему скейлинг работает? Вопрос, на который довольно много разнообразных ответов: от очень философских до инженерных (Explaining Neural Scaling Laws). Начать погружение в мир масштабирования рекомендую с 2 эссе: The Bitter Lesson и The Scaling Hypothesis. Во втором Гверн даёт классную интуицию претрейну, критикует скепткиков скейлинга, а ещё у него есть классная подборка статей про MLP "representing a possible future Bitter Lesson".
Можно не пытаться задаваться вопросом "почему", а просто наблюдать эмпирические свойства - большие модели уже давно доминируют во многих ML областях:
- NLP: Deep Learning Scaling is Predictable, Empirically, Scaling Laws for Neural Language Models
- CV: Scaling Vision Transformers
- Speech: Better speech synthesis through scaling
Выше я специально привожу статьи, в которых используются трансформеры, чтобы дополнительно усилить тезис: дело не в очень сложной, хитрой нейронной архитектуре. Да, подбор правильной функции активации может выиграть нам несколько процентов качества и мы обязательно его делаем в нашей повседневной работе, однако он никогда не улучшит модель многократно. Революционные изменения достигаются в основном через вложения компьюта, причём даже в весьма простую архитектуру.
"Тупое" изменение гипрепараметров конфига на самом деле представляет из себя нетривиальную инженерную задачу. Каждый следующий порядок размера вызывает следующего порядка сложности, которые приходится преодолевать. Кроме того, масштабируемость архитектуры надо ещё обеспечить: сформулировать правильную оптимизационную задачу, сформировать датасет. Об этом поговорим во второй части заметки.
👍5❤3
Forwarded from Свет из чёрного ящика
Во что мы верим: Scaling Hypothesis (часть 2)
Есть ли области, в которых масштабирование до сих пор не работало? Робототехника одна из них: от автономных машин до гуманойдных роботов. Главная проблема этой области - количество данных. Из всех статей про скейлинг мы видим, что 3 оси должны масштабироваться в линейной пропорции: размер модели, количество данных, количество вычислений. Однако и тут, как только с данными разобрались, всё заработало (GR00T N1: An Open Foundation Model for Generalist Humanoid Robots), куча компаний бросились в гонку роботов (Humanoid Robots at work: where are we ?).
Где-то в русскоязычном телеграм сообществе я видел мнение, что рекомендательные датасеты тоже малы. Может это и справедливо для открытых датасетов, а также для каких-то небольших доменов, однако в корне неверно для крупных систем. Yambda-5b содержит, как следует из названия, миллиарды событий. Наш реальный датасет, на котором обучался Argus - в десятки раз больше. Учитывая, что каждое событие несет в себе намного больше информации, чем один текстовый токен, такого количества данных уж точно должно хватить для обучения энкодера размером в десятки миллиардов параметров (Training Compute-Optimal Large Language Models). Если же вы используете типичную инженерную парадигму в виде feature store над залогированными признаками, ваш датасет скорее всего действительно мал.
В нашей области можно выделить следующие основные оси масштабирования:
1. Размер sparse части (размер матрицы эмбеддингов)
2. Размер энкодера
3. Размерность входа (количество признаков / контекстное окно)
4. Размер датасета
5. Архитектурные усложнения (например раннее связывание)
Про каждую из них мы ещё поговорим отдельно. В этом посте сфокусируемся на размере энкодера.
Почему энкодеры в рекомендациях до сих пор не удавалось масштабировать?
(Understanding Scaling Laws for Recommendation Models, Breaking the Curse of Quality Saturation with User-Centric Ranking)
Я выделяю несколько причин:
1. Большой inductive bias, присущий любым моделям, использующим ручное признаковое пространство
2. Сложно сформулировать простую, масштабируемую задачу обучения (такую как NTP)
3. Ограниченного размера датасеты (если вы используете залогированные ручные признаки)
4. Ограничения на latency и throughput реальных систем, любое улучшение должно себя окупать
Последний год (с момента выхода Actions Speak Louder than Words) учит нас тому, что рекомендации, по всей видимости, не какой-то особый домен, в котором большие модели не работают. Вслед за лидерами побежали все остальные и сейчас довольно много компаний показали scaling laws своих моделей, некоторые уже заявляют, что замасштабировали энкодеры до миллиарда параметров (LinkedIn, ByteDance, KuaiShou, Pinterest, Netflix). Мы тоже рассказали о своих результатах в этом направлении.
Итак вроде проблемы преодолели, модели начали масштабироваться, данных куча. Остаётся небольшой слон в комнате: где же 7b+ рекомендательные модели? Ответ на него мне самому очень интересен и мы активно исследуем эту область, будем делиться результатами. Пока же никто (из того, что я читал или слышал) не показал насыщения за границами 1b.
В следующем посте перейдём от обзорных идей к конкретным. Разберём на примере одной свежей статьи из индустрии, как масштабировать рекомендательные трансформеры.
Есть ли области, в которых масштабирование до сих пор не работало? Робототехника одна из них: от автономных машин до гуманойдных роботов. Главная проблема этой области - количество данных. Из всех статей про скейлинг мы видим, что 3 оси должны масштабироваться в линейной пропорции: размер модели, количество данных, количество вычислений. Однако и тут, как только с данными разобрались, всё заработало (GR00T N1: An Open Foundation Model for Generalist Humanoid Robots), куча компаний бросились в гонку роботов (Humanoid Robots at work: where are we ?).
Где-то в русскоязычном телеграм сообществе я видел мнение, что рекомендательные датасеты тоже малы. Может это и справедливо для открытых датасетов, а также для каких-то небольших доменов, однако в корне неверно для крупных систем. Yambda-5b содержит, как следует из названия, миллиарды событий. Наш реальный датасет, на котором обучался Argus - в десятки раз больше. Учитывая, что каждое событие несет в себе намного больше информации, чем один текстовый токен, такого количества данных уж точно должно хватить для обучения энкодера размером в десятки миллиардов параметров (Training Compute-Optimal Large Language Models). Если же вы используете типичную инженерную парадигму в виде feature store над залогированными признаками, ваш датасет скорее всего действительно мал.
В нашей области можно выделить следующие основные оси масштабирования:
1. Размер sparse части (размер матрицы эмбеддингов)
2. Размер энкодера
3. Размерность входа (количество признаков / контекстное окно)
4. Размер датасета
5. Архитектурные усложнения (например раннее связывание)
Про каждую из них мы ещё поговорим отдельно. В этом посте сфокусируемся на размере энкодера.
Почему энкодеры в рекомендациях до сих пор не удавалось масштабировать?
(Understanding Scaling Laws for Recommendation Models, Breaking the Curse of Quality Saturation with User-Centric Ranking)
Я выделяю несколько причин:
1. Большой inductive bias, присущий любым моделям, использующим ручное признаковое пространство
2. Сложно сформулировать простую, масштабируемую задачу обучения (такую как NTP)
3. Ограниченного размера датасеты (если вы используете залогированные ручные признаки)
4. Ограничения на latency и throughput реальных систем, любое улучшение должно себя окупать
Последний год (с момента выхода Actions Speak Louder than Words) учит нас тому, что рекомендации, по всей видимости, не какой-то особый домен, в котором большие модели не работают. Вслед за лидерами побежали все остальные и сейчас довольно много компаний показали scaling laws своих моделей, некоторые уже заявляют, что замасштабировали энкодеры до миллиарда параметров (LinkedIn, ByteDance, KuaiShou, Pinterest, Netflix). Мы тоже рассказали о своих результатах в этом направлении.
Итак вроде проблемы преодолели, модели начали масштабироваться, данных куча. Остаётся небольшой слон в комнате: где же 7b+ рекомендательные модели? Ответ на него мне самому очень интересен и мы активно исследуем эту область, будем делиться результатами. Пока же никто (из того, что я читал или слышал) не показал насыщения за границами 1b.
В следующем посте перейдём от обзорных идей к конкретным. Разберём на примере одной свежей статьи из индустрии, как масштабировать рекомендательные трансформеры.
👍8❤4🔥1
Канал Коли, из которого два предыдущих поста, обещает быть интересным.
Когда я уходил из Яндекса почти три года назад, Коля приходил (возвращался) практически как моя замена. С тех пор служба рекомендательных технологий выросла раза в два и продолжает демонстрировать весьма достойные результаты.
Когда я уходил из Яндекса почти три года назад, Коля приходил (возвращался) практически как моя замена. С тех пор служба рекомендательных технологий выросла раза в два и продолжает демонстрировать весьма достойные результаты.
Telegram
Свет из чёрного ящика
Открытый разговор о внедрении передовых рекомендательных технологий в экосистему Яндекса от @NikolaySav
👍16❤6✍6🔥2
Экс-Экс
Многие из вас могут помнить, как почти год назад я расписывал, насколько классно мне работалось в X.
И вот, это путешествие подошло к концу — я больше не работаю в Х.
Сейчас у меня небольшой отдых, а что будет дальше — stay tuned.
Многие из вас могут помнить, как почти год назад я расписывал, насколько классно мне работалось в X.
И вот, это путешествие подошло к концу — я больше не работаю в Х.
Сейчас у меня небольшой отдых, а что будет дальше — stay tuned.
7😱93❤28🥰19👍12😢8❤🔥4🐳3✍2🍾2
На этой неделе я начал работать в организации-которую-нельзя-называть-без-звёздочки.
По многим аспектам новый работодатель кажется полной противоположностью предыдущего. Например, по размеру.
От области рекомендаций я ушёл совсем недалеко: буду заниматься рекламой. Причём одной из моих любимых тем — long-term value optimization.
Мой менеджер пытался меня нанять ещё с 2021 года. На третий раз я всё-таки согласился 😊
По многим аспектам новый работодатель кажется полной противоположностью предыдущего. Например, по размеру.
От области рекомендаций я ушёл совсем недалеко: буду заниматься рекламой. Причём одной из моих любимых тем — long-term value optimization.
Мой менеджер пытался меня нанять ещё с 2021 года. На третий раз я всё-таки согласился 😊
2👏75🔥46🏆6❤5👍3💩2🥱2
Регрессия и распределение шума
В задачах регрессии обычно предполагают, что есть какая-то неизвестная нам «настоящая» зависимость таргета от входа, а наблюдаемые таргеты получаются из «настоящих» добавлением нормального шума с нулевым матожиданием и постоянной дисперсией. Это предположение ведет к квадратичной функции потерь (L2).
Но часто это предположение ломается: дисперсия шума может быть непостоянной, а само распределение — не нормальным. Например, так распределены деньги, которые пользователи приносят сервису за какой-то период.
Если у вас есть задача регрессии, вы можете построить гистограмму ошибок и проверить, похожа ли она на нормальное распределение.
Интуитивно хочется к таким криво распределенным таргетам сначала применить какое-то преобразование (скажем, логарифм), после которого они станут относительно нормальными, решить задачу регрессии в преобразованной шкале, а потом уже предсказания перевести в исходную шкалу.
Когда-то в Яндексе Миша Парахин всем советовал в таких ситуациях чуть более принципиальный подход: в качестве этого преобразования использовать CDF (функцию распределения) исходного распределения таргетов (оцененную по датасету) и затем обратную CDF нормального распределения. Тогда преобразованные таргеты как раз будут нормально распределены (правда, тут некоторая подмена понятия — вообще говоря, нам нужно нормальное распределение шума/ошибок, а не самих таргетов).
Но у этих подходов есть проблема — они не mean-proper. Mean-proper функции ошибок — это у которых минимум достигается, когда предсказание равно матожиданию таргета. Например, L2 (MSE) или Binary Cross-Entropy (в случае бинарных таргетов) — mean-proper. А вот L1 (MAE), MAPE, MSE логарифмов — нет. Попросту говоря, при использовании таких лоссов предсказания будут смещенными. Я когда-то уже писал про это для логарифмов.
Это свойство (mean-proper) часто довольно важно. Например, хотелось бы, чтобы сумма наших предсказаний доходов по какому-то сегменту пользователей примерно попадала в настоящие суммарные доходы.
Поэтому я к этим трюкам с преобразованием таргета всегда относился скептически — не хочется терять калиброванность из-за того, что шум как-то не так распределен. И вообще, казалось бы, как бы ни был распределен шум, практика нас обычно учит: что вы хотите улучшить на test set — то и оптимизируйте на train set. Хотите MSE — используйте MSE. Просто разные лоссы ведут к разным компромиссам, когда не получается точно описать данные. Так ведь?
Оказалось — нет. За последние несколько дней я провёл небольшой эксперимент на искусственных данных. Пусть у нас одномерный случай, x распределен равномерно на [0, 1], «настоящая» зависимость выглядит как z = exp(a*x + b), а наблюдаемые таргеты сэмплируются не из нормального, а из экспоненциального распределения с матожиданием z(x). Обучаем модель y_pred = exp(a*x + b), т.е. просто подбираем параметры a и b по датасету, используя либо обычный L2 loss, либо специальный экспоненциальный лосс log(y_pred) + y / y_pred — это negative log-likelihood экспоненциального распределения (он тоже mean-proper!).
И оказалось, что экспоненциальный лосс даёт лучшее качество, чем L2, даже по MSE! Особенно, когда обучающих данных немного (когда много — L2 догоняет по качеству).
Конечно, в реальных случаях у нас данных сильно больше, чем тут. Но и зависимости у нас сложнее, и фичей сильно больше, и особенно для спарс-фичей — разреженность данных может быть ещё сильнее.
Эксперимент показал, что лосс, адаптированный к настоящему распределению шума, ведёт именно к лучшей генерализации — а не просто к другому компромиссу.
Иллюстрация (cherry-pick) — ниже. Типичная чувствительность L2 к выбросам.
P.S. Эксперимент выглядит очень простым. Но пока я его делал, я напоролся на несколько удивительных подводных камней. Оказалось, что использование
1) линейной зависимости z = a*x + b (без exp)
2) оптимизаторов Adam и (S)GD
3) mean(x) ± 2 * std(x) / sqrt(N) в качестве доверительного интервала среднего
— всё это делает эксперимент очень нестабильным. Угадайте, почему 😉
В задачах регрессии обычно предполагают, что есть какая-то неизвестная нам «настоящая» зависимость таргета от входа, а наблюдаемые таргеты получаются из «настоящих» добавлением нормального шума с нулевым матожиданием и постоянной дисперсией. Это предположение ведет к квадратичной функции потерь (L2).
Но часто это предположение ломается: дисперсия шума может быть непостоянной, а само распределение — не нормальным. Например, так распределены деньги, которые пользователи приносят сервису за какой-то период.
Если у вас есть задача регрессии, вы можете построить гистограмму ошибок и проверить, похожа ли она на нормальное распределение.
Интуитивно хочется к таким криво распределенным таргетам сначала применить какое-то преобразование (скажем, логарифм), после которого они станут относительно нормальными, решить задачу регрессии в преобразованной шкале, а потом уже предсказания перевести в исходную шкалу.
Когда-то в Яндексе Миша Парахин всем советовал в таких ситуациях чуть более принципиальный подход: в качестве этого преобразования использовать CDF (функцию распределения) исходного распределения таргетов (оцененную по датасету) и затем обратную CDF нормального распределения. Тогда преобразованные таргеты как раз будут нормально распределены (правда, тут некоторая подмена понятия — вообще говоря, нам нужно нормальное распределение шума/ошибок, а не самих таргетов).
Но у этих подходов есть проблема — они не mean-proper. Mean-proper функции ошибок — это у которых минимум достигается, когда предсказание равно матожиданию таргета. Например, L2 (MSE) или Binary Cross-Entropy (в случае бинарных таргетов) — mean-proper. А вот L1 (MAE), MAPE, MSE логарифмов — нет. Попросту говоря, при использовании таких лоссов предсказания будут смещенными. Я когда-то уже писал про это для логарифмов.
Это свойство (mean-proper) часто довольно важно. Например, хотелось бы, чтобы сумма наших предсказаний доходов по какому-то сегменту пользователей примерно попадала в настоящие суммарные доходы.
Поэтому я к этим трюкам с преобразованием таргета всегда относился скептически — не хочется терять калиброванность из-за того, что шум как-то не так распределен. И вообще, казалось бы, как бы ни был распределен шум, практика нас обычно учит: что вы хотите улучшить на test set — то и оптимизируйте на train set. Хотите MSE — используйте MSE. Просто разные лоссы ведут к разным компромиссам, когда не получается точно описать данные. Так ведь?
Оказалось — нет. За последние несколько дней я провёл небольшой эксперимент на искусственных данных. Пусть у нас одномерный случай, x распределен равномерно на [0, 1], «настоящая» зависимость выглядит как z = exp(a*x + b), а наблюдаемые таргеты сэмплируются не из нормального, а из экспоненциального распределения с матожиданием z(x). Обучаем модель y_pred = exp(a*x + b), т.е. просто подбираем параметры a и b по датасету, используя либо обычный L2 loss, либо специальный экспоненциальный лосс log(y_pred) + y / y_pred — это negative log-likelihood экспоненциального распределения (он тоже mean-proper!).
И оказалось, что экспоненциальный лосс даёт лучшее качество, чем L2, даже по MSE! Особенно, когда обучающих данных немного (когда много — L2 догоняет по качеству).
Конечно, в реальных случаях у нас данных сильно больше, чем тут. Но и зависимости у нас сложнее, и фичей сильно больше, и особенно для спарс-фичей — разреженность данных может быть ещё сильнее.
Эксперимент показал, что лосс, адаптированный к настоящему распределению шума, ведёт именно к лучшей генерализации — а не просто к другому компромиссу.
Иллюстрация (cherry-pick) — ниже. Типичная чувствительность L2 к выбросам.
P.S. Эксперимент выглядит очень простым. Но пока я его делал, я напоролся на несколько удивительных подводных камней. Оказалось, что использование
1) линейной зависимости z = a*x + b (без exp)
2) оптимизаторов Adam и (S)GD
3) mean(x) ± 2 * std(x) / sqrt(N) в качестве доверительного интервала среднего
— всё это делает эксперимент очень нестабильным. Угадайте, почему 😉
👍20🤓12❤10✍3🤯1🤮1
Вместо итогов года, хочу поделиться моим списком лучших — самых значимых или просто понравившихся — статей, которые я прочитал за последние два года (про 2024 раньше не писал). В порядке прочтения.
Unified Embedding
Статья DeepMind о том, что можно использовать одну универснальную таблицу эмбеддингов для многих sparse фичей. Полезная практическая статья.
Обзоры в Рекомендательной и у Дани.
Actions Speak Louder than Words
Громкая статья от Meta. Первая показала, что можно обучать огромные модели для рекомендаций. Ввела HSTU и новое представление истории. Лично для меня это был первый намёк на то, что когда-нибудь мы сможем отказаться от всех ручных фичей.
Обзоры в Рекомендательной и у Даши.
Revisiting Neural Retrieval on Accelerators
Meta показала, что retrieval можно делать на GPU без индекса. Также вводят для второй стадии модель mixture-of-logits (MoL), которая является более выразительной, но всё ещё относительно дешевой в вычислениях функцией. Для меня это была первая статья, показавшая, что retrieval можно делать лучше, чем всем привычным HNSW. И я сам потом работал над этим подходом. Обзоры у меня и у Саши.
А в последующей статье показали, что можно всё-таки и с индексами и без GPU напрямую искать топ по MoL. Обзор в Рекомендательной.
Серия Semantic IDs от DeepMind
- Generative Retrieval (обзоры у Саши и в Рекомендательной)
- Better Generalization (обзор у Дани)
- PLUM (обзоры у Кирилла и в Рекомендательной)
Номер 1 по значимости, самый существенный сдвиг парадигмы последнего времени. Токенизатор рекомендательного мира, представляющий контентную информацию об объектах в виде кодов из конечного словаря, полученного из иерархической кластеризации (RQ-VAE). Использование этой токенизации для нового метода retrieval, для более эффективных эмбеддингов в ранжировании и для связи с LLM. Уже повлияло на всю индустрию. Must read.
Streaming Vector Quantization Retriever
Одна вещь, которая меня больше всего смущала в Semantic IDs, — что RQ-VAE обучается отдельно, не end-to-end совместно с рекомендательной задачей. В этой статье ByteDance как раз исправили это. Правда, тут не иерархический RQ-VAE, а одноуровневый VQ-VAE. Зато real-time.
Обзор в Рекомендательной.
Stop Regressing
Единственная статья не про рекомендации, хотя и в рекомендациях тоже может быть полезной. DeepMind о том, как в задачах регресии (на примере value function в RL) моделирование распределения таргета (вместо точечной оценки) с помощью Histogram Loss улучшает масштабируемость. Про сам Histogram Loss можно прочитать и в оригинальной статье. Для меня это теперь достаточно близкая тема.
Про статью я узнал из выступления Дмитрия Бабаева на ICML Recap (а также в ML Underhood).
Серия OneRec от Kuaishou
- OneRec
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneRec-Think
(и ещё какое-то количество статей, но я, признаюсь, даже последние две ещё только собираюсь прочитать)
Не называю это номером 1 по значимости только лишь потому, что оно во многом является продолжением Semantic IDs. Но всё же доводит их до того, что многие уже называют революцией — первая индустриальная end-to-end рекомендательная система, без нескольких стадий ранжирования. Вот примерно так будут выглядеть системы нового поколения. Must read.
Обзоры у Саши, в Рекомендательной и у Коли (1, 2, 3).
Correcting the LogQ Correction
Приз моей личной симпатии, потому что
1) улучшили знаменитую технику Гугла LogQ-коррекции,
2) я сам какое-то время думал на эту тему,
3) я рад за Кирилла и команду 😉
Обзор у автора.
На этом всё. Надеюсь, это будет кому-нибудь полезно. Мне самому было бы очень полезно, если бы авторы дружественных каналов позаимствовали такой формат! (только не «лучшие посты года»...)
Unified Embedding
Статья DeepMind о том, что можно использовать одну универснальную таблицу эмбеддингов для многих sparse фичей. Полезная практическая статья.
Обзоры в Рекомендательной и у Дани.
Actions Speak Louder than Words
Громкая статья от Meta. Первая показала, что можно обучать огромные модели для рекомендаций. Ввела HSTU и новое представление истории. Лично для меня это был первый намёк на то, что когда-нибудь мы сможем отказаться от всех ручных фичей.
Обзоры в Рекомендательной и у Даши.
Revisiting Neural Retrieval on Accelerators
Meta показала, что retrieval можно делать на GPU без индекса. Также вводят для второй стадии модель mixture-of-logits (MoL), которая является более выразительной, но всё ещё относительно дешевой в вычислениях функцией. Для меня это была первая статья, показавшая, что retrieval можно делать лучше, чем всем привычным HNSW. И я сам потом работал над этим подходом. Обзоры у меня и у Саши.
А в последующей статье показали, что можно всё-таки и с индексами и без GPU напрямую искать топ по MoL. Обзор в Рекомендательной.
Серия Semantic IDs от DeepMind
- Generative Retrieval (обзоры у Саши и в Рекомендательной)
- Better Generalization (обзор у Дани)
- PLUM (обзоры у Кирилла и в Рекомендательной)
Номер 1 по значимости, самый существенный сдвиг парадигмы последнего времени. Токенизатор рекомендательного мира, представляющий контентную информацию об объектах в виде кодов из конечного словаря, полученного из иерархической кластеризации (RQ-VAE). Использование этой токенизации для нового метода retrieval, для более эффективных эмбеддингов в ранжировании и для связи с LLM. Уже повлияло на всю индустрию. Must read.
Streaming Vector Quantization Retriever
Одна вещь, которая меня больше всего смущала в Semantic IDs, — что RQ-VAE обучается отдельно, не end-to-end совместно с рекомендательной задачей. В этой статье ByteDance как раз исправили это. Правда, тут не иерархический RQ-VAE, а одноуровневый VQ-VAE. Зато real-time.
Обзор в Рекомендательной.
Stop Regressing
Единственная статья не про рекомендации, хотя и в рекомендациях тоже может быть полезной. DeepMind о том, как в задачах регресии (на примере value function в RL) моделирование распределения таргета (вместо точечной оценки) с помощью Histogram Loss улучшает масштабируемость. Про сам Histogram Loss можно прочитать и в оригинальной статье. Для меня это теперь достаточно близкая тема.
Про статью я узнал из выступления Дмитрия Бабаева на ICML Recap (а также в ML Underhood).
Серия OneRec от Kuaishou
- OneRec
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneRec-Think
(и ещё какое-то количество статей, но я, признаюсь, даже последние две ещё только собираюсь прочитать)
Не называю это номером 1 по значимости только лишь потому, что оно во многом является продолжением Semantic IDs. Но всё же доводит их до того, что многие уже называют революцией — первая индустриальная end-to-end рекомендательная система, без нескольких стадий ранжирования. Вот примерно так будут выглядеть системы нового поколения. Must read.
Обзоры у Саши, в Рекомендательной и у Коли (1, 2, 3).
Correcting the LogQ Correction
Приз моей личной симпатии, потому что
1) улучшили знаменитую технику Гугла LogQ-коррекции,
2) я сам какое-то время думал на эту тему,
3) я рад за Кирилла и команду 😉
Обзор у автора.
На этом всё. Надеюсь, это будет кому-нибудь полезно. Мне самому было бы очень полезно, если бы авторы дружественных каналов позаимствовали такой формат! (только не «лучшие посты года»...)
🔥50❤20👍9✍4