Дополнение · X-алгоритм · страница 5 из 11

Ранжирование: трансформер, который запрещает кандидатам смотреть друг на друга

Retrieval отобрал сотни постов — теперь их надо упорядочить. Разбираем ранжирующую модель Phoenix: как история и кандидаты укладываются в одну последовательность, что именно делает маска внимания, почему предсказаний много и как их обучают, если данные для разных голов приходят из разных мест.

1. Как всё укладывается в одну последовательность

Первое, что стоит уложить в голове: это не модель вида «подай пару (пользователь, пост) — получи число». За один прогон обрабатывается весь набор кандидатов сразу, и укладывается он так:

Такая укладка — прямое продолжение того, что мы разбирали в главе «Трансформеры над историей»: история пользователя как последовательность, кандидат как ещё один токен, внимание вместо ручных агрегатов. Разница в том, что здесь кандидатов сразу 64, и именно это порождает главный вопрос страницы.

2. Маска изоляции: одна строка, определяющая всю систему

На странице обзора мы упомянули, что кандидаты не видят друг друга. Теперь посмотрим, как это записано. Каждому токену присваивается сегмент:

HISTORY_SEGMENT_ID = 1
CANDIDATE_SEGMENT_ID = -1
PADDING_SEGMENT_ID = 0

segment_ids = jnp.where(padding_mask,
                        jnp.where(idx >= candidate_start_offset, -1, 1),
                        0)

А внутри ядра внимания стоит вот это:

mask = jnp.logical_or(seg_k == HISTORY_SEGMENT_ID, span_q[:, None] == span_k[None, :])

Фрагмент из ranker_attention_v2.py · код X, Apache 2.0, коммит 28e414f

Прочитаем медленно. Запрос на позиции \(q\) может смотреть на ключ на позиции \(k\) тогда и только тогда, когда выполнено хотя бы одно из двух:

• ключ принадлежит истории или профилю — seg_k == 1;
• ключ — это сам запрос — span_q == span_k.

Всё. Никаких других вариантов. Значит:

Обратите внимание: история — двусторонняя. Никакой причинной маски по умолчанию нет, событие из середины истории спокойно смотрит на более позднее. Это не языковая модель, предсказывающая следующий токен; это энкодер, и запрещать ему смотреть вперёд по истории нет причин.

acc, m_i, l_i = lax.fori_loop(0, history_upper_bound, body, (acc, m_i, l_i))

candidate_lower_bound = jnp.maximum(history_upper_bound, offset_q // block_k)
candidate_upper_bound = (offset_q + block_q - 1) // block_k + 1
acc, m_i, l_i = lax.fori_loop(candidate_lower_bound, candidate_upper_bound, body, (acc, m_i, l_i))

Чем за это платят

Размен стоит проговорить честно, потому что на собеседовании обычно спрашивают именно про обратную сторону.

Модель, которая видит слейт целиком, принципиально сильнее. Она может заметить, что три поста подряд про одно и то же, что второй пост дублирует первый, что после длинного видео стоит поставить короткий текст. Это списочная постановка, и она даёт лучшее качество при прочих равных.

Отказавшись от неё, система получает четыре вещи:

1. Кэшируемость. Скор пары (пользователь, пост) можно сохранить и переиспользовать при следующем запросе. В коде ленты есть отдельный источник закэшированных отранжированных постов — он существует именно благодаря этому свойству.
2. Воспроизводимость. Два одинаковых запроса дают одинаковый порядок. Без изоляции порядок зависел бы от того, как посты разбились по батчам.
3. Объяснимость. На вопрос «почему этот пост оказался ниже» есть ответ, не содержащий слов «потому что рядом оказался другой пост».
4. Скорость. Квадратичный член по кандидатам исчезает.

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

3. Головы: что именно предсказывается

С каждой позиции кандидата снимается два набора чисел.

Дискретные головы — вероятности действий: лайк, ответ, репост, цитата, клик, разворот фото, открытие видео, подписка на автора, жалоба, блокировка, скрытие, «не интересно» и так далее. Полный список и веса, с которыми они сводятся, — на странице скоринга.

Непрерывные головы — величины, у которых нет «случилось или нет»: время задержки на посте, время после клика, активные секунды. Это регрессия. В конфиге их восемь.

4. Самое интересное: головы учатся на разных подвыборках

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

Конверсии — только на кликнутых

if self.config.condition_conversion_on_click:
    has_click = targets[:, :, CLICK_ACTION_INDEX]
    no_click = 1 - has_click
    conv_head_mask = jnp.zeros(num_actions).at[jnp.array(CLICK_CONDITIONED_ACTION_INDICES)].set(1.0)
    conv_zero_mask = no_click[:, :, None] * conv_head_mask
    loss_mask = loss_mask * (1 - conv_zero_mask)

Фрагмент из recsys_model.py · код X, Apache 2.0, коммит 28e414f

Читается так: если по посту не было клика, то лосс конверсионных голов на этом примере обнуляется. Они не получают градиента вовсе.

Логика железная. Что означает «конверсия не произошла» для поста, по которому не кликали? Ничего. Пользователь не отказался от действия — у него просто не было возможности его совершить. Обучать голову на таком примере значит учить её, что «отсутствие возможности» — это «отказ».

Это ровно та задача сдвига выборки, ради которой в главе «ESMM и сдвиг выборки» придумали ESMM: там показывалось, что модель конверсии, обученная только на кликах, при выкатке на все показы систематически ошибается. Решения два — либо моделировать всю цепочку целиком через произведение вероятностей, либо честно ограничить обучающую выборку. Здесь выбран второй путь, но с важным дополнением: обучение идёт совместно, в одной модели, поэтому общее тело всё равно видит все примеры, а специализируется только голова.

Негативная обратная связь — только на реальных показах

if self.config.mask_neg_feedback_on_negatives:
    neg_head_mask = jnp.zeros(num_actions).at[jnp.array(NEGATIVE_FEEDBACK_HEAD_INDICES)].set(1.0)
    zero_mask = negative_sample_mask[:, :, None] * neg_head_mask
    loss_mask = loss_mask * (1 - zero_mask)

Фрагмент из recsys_model.py · код X, Apache 2.0, коммит 28e414f

Здесь та же идея с другой стороны. В обучающую выборку добавляют засэмплированные негативы — посты, которые пользователю никогда не показывали. Для голов вроде «лайкнет ли» это нормально: не показали — значит, почти наверняка не лайкнул бы.

Но для головы «пожалуется ли» такой пример ядовит. Отсутствие жалобы на непоказанный пост — не свидетельство того, что жалобы бы не было. Обучив на этом, мы получим модель, уверенную, что жалуются редко, — и она будет права статистически и бесполезна практически.

Поэтому головы негативной обратной связи на засэмплированных негативах не обучаются вовсе. Разбирали ровно эту ловушку в главе «Проблемы implicit-данных»: отсутствие сигнала и отрицательный сигнал — разные вещи, и путать их дорого.

zero_mask = has_negative_feedback_action_expanded & non_negative_feedback_action_mask
targets_for_loss = jnp.where(zero_mask, False, targets_for_loss)

5. Признаки: что модель знает о посте и о моменте

Блок FeaturePrepConfig в конфиге — это, по сути, список всего, что подаётся модели помимо истории и идентификаторов.

Две строчки заслуживают отдельного разбора.

hour_of_day_dither_fraction: 0.1

post_age_granularity_mins: 60

6. Обучение

Здесь несколько решений, каждое из которых заслуживает пояснения.

Два оптимизатора для одной модели

optim_config=RecsysDenseOptimConfig(
    optim="muon",
    muon_consistent_rms=0.2,
    muon_matrix_weight_decay=0.014,
    b1=0.95, b2=0.98,
),
emb_optim_config=RecsysEmbeddingOptimConfig(
    rowwise_adagrad=RecsysRowwiseAdagradConfig(
        learning_rate=0.28, half_life_steps=2500, lazy_decay=True, weight_decay=2.8e-4,
    ),
),

Фрагмент из xrecsys.py · код X, Apache 2.0, коммит 28e414f

Плотные слои учатся Muon, таблицы эмбеддингов — построчным Adagrad. Это не эклектика, а следствие того, что у них принципиально разная структура градиента.

• Плотная матрица получает градиент на каждом примере батча. Muon — сравнительно новый оптимизатор, работающий с матрицей весов как с матрицей, а не как с плоским вектором параметров: он выравнивает спектр обновления, не давая одному направлению доминировать. Скорость обучения 7.1e-4.
• Строка таблицы эмбеддингов получает градиент только когда её айтем попал в батч, — то есть в тысячи раз реже. Ей нужен большой шаг (0.28, в четыреста раз больше!) и индивидуальная адаптация: Adagrad накапливает историю градиентов по каждой строке отдельно.

Параметр half_life_steps: 2500 задаёт период полураспада накопленной статистики Adagrad: без забывания знаменатель растёт монотонно, шаг уходит в ноль, и старые строки перестают обучаться. С забыванием модель остаётся способной адаптироваться к изменившемуся поведению — прямой ответ на дрейф данных.

А lazy_decay: True означает, что забывание применяется к строке лениво, в момент её следующего обновления, а не ко всей таблице каждый шаг. Для таблицы на миллионы строк это разница между «дорого» и «бесплатно».

Упаковка последовательностей

Истории у людей разной длины, а тензор прямоугольный. Наивное решение — дополнять всех до максимума — означает, что при средней длине 510 и максимуме 1022 половина вычислений уходит на паддинг.

В конфиге включён use_seqpack с распределением длин Beta от 126 до 1022 со средним 510. Несколько коротких историй укладываются в один физический ряд, а разделяются они теми самыми сегментными идентификаторами, которые мы разбирали в маске. Внимание не даёт им перетечь друг в друга.

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

LogQ-коррекция и здесь

В конфиге ранжирования стоит log_q_correction: True. Может показаться странным: коррекция обсуждалась в контексте retrieval, где негативы сэмплируются из батча. Но в обучении ранкера тоже есть засэмплированные негативы — посты, которые пользователю не показывали, добавленные, чтобы модель видела не только выданное.

Сэмплируются они не равномерно, и без поправки ранкер унаследует то же смещение к популярному. Механика та же, что подробно разобрана на странице retrieval и в виджете LogQ.

7. Конфигурация ранкера против ретривера

Строка про нормировку запросов и ключей стоит комментария. qk_norm нормирует векторы перед вычислением скалярного произведения, ограничивая величину логитов внимания сверху. Альтернатива — жёстко обрезать логиты, что и делает ретривер параметром 80.0. Оба приёма лечат одну болезнь: расходящееся внимание, когда один логит убегает вперёд, софтмакс схлопывается в дельта-функцию и градиент умирает. В ранкере выбрали более мягкий из двух.

Частые ошибки и подводные камни

Вопросы с собеседований

Шпаргалка одним экраном

Первоисточники

• recsys_model.py — модель, сегментные идентификаторы, маски лосса по головам.
• ranker_attention_v2.py — ядро внимания и та самая строка маски.
• xrecsys.py — продовый конфиг: размеры, признаки, оптимизаторы.
• ranker_attention_fa4.py — блочно-разреженная раскладка внимания для новых GPU.
• Курс: глава «Трансформеры над историей» о трансформерах над историей, глава «ESMM и сдвиг выборки» об ESMM и сдвиге выборки, глава «Списочные лоссы» о списочных постановках.