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

Источники: откуда вообще берутся посты

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

1. Почему источников несколько

Вопрос законный: если есть обученная модель, которая умеет находить релевантные посты, зачем к ней что-то ещё?

Ответ проще, чем кажется: у каждого способа поиска своя слепая зона, и они не пересекаются.

Особенно показательна вторая строка. Модель retrieval прекрасна, но её индекс, как мы разбирали на странице про retrieval, обновляется только при сохранении чекпоинта. Пост, опубликованный пять минут назад, в нём физически отсутствует — а именно такие посты и составляют ленту соцсети.

2. Thunder: посты подписок в оперативной памяти

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

Что именно лежит в памяти

pub struct PostStore {
    posts: Arc<DashMap<i64, Arc<CompactPost>>>,
    original_posts_by_user: Arc<DashMap<i64, VecDeque<TinyPost>>>,
    secondary_posts_by_user: Arc<DashMap<i64, VecDeque<TinyPost>>>,
    video_posts_by_user: Arc<DashMap<i64, VecDeque<TinyPost>>>,
    deleted_posts: Arc<DashMap<i64, bool>>,
    retention_seconds: u64,
    request_timeout: Duration,
}

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

Пять структур, и каждая объяснима.

• posts — сам пост по идентификатору. Обратите внимание на тип: CompactPost — это структура из одиннадцати полей фиксированного размера, без текста. Идентификаторы, время, флаги «репост», «ответ», «есть видео».
• Три раздельных индекса по автору: оригинальные посты, вторичные (ответы и репосты) и видео. В каждом — очередь из TinyPost, а это всего два поля: идентификатор и время создания.
• deleted_posts — надгробия для удалённого.

Как это наполняется

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

Старое вычищается по времени хранения: есть фоновая задача trim_old_posts, которая обходит очереди и выбрасывает то, что вышло за окно. Плюс sort_all_user_posts — периодическая пересортировка, потому что события Kafka приходят не строго по порядку.

3. SimClusters: кластеризация социального графа

Самый старый и самый концептуально интересный источник. Идея: если разбить пользователей на сообщества по тому, кто за кем следит и кто с кем взаимодействует, то «интересное для вас» можно искать в пространстве сообществ, а не в пространстве постов.

В названиях датасетов зашита конфигурация модели: Model20M145K2020 — 20 миллионов пользователей раскладываются по 145 тысячам кластеров.

Разреженная бинарная факторизация

В коде метод называется SBF, и в его основе лежит SparseBinaryMatrix. Разберём, чем это отличается от привычной матричной факторизации из главы «Матричная факторизация».

Ключевое отличие — интерпретируемость. Координата обычного эмбеддинга не означает ничего; про неё нельзя сказать «это про астрономию». Кластер SimClusters означает конкретное сообщество, у него есть состав, его можно посмотреть глазами, ему можно дать имя, на него можно пожаловаться.

Второе отличие — разреженность. Аккаунт принадлежит нескольким сообществам из 145 тысяч, а не имеет 145 тысяч слабых весов. Это даёт и экономию, и инвертированный индекс: по сообществу можно быстро получить всех, кто в него входит.

4. Лимиты источников: распределение бюджета

У каждого источника в конфигурации стоит потолок на число возвращаемых постов.

Эти числа — не технические ограничения, а продуктовое решение, выраженное в конфиге. Они задают, из какого материала система вообще может собрать ленту.

Прикиньте пропорцию: 1200 постов от подписок против примерно 2000 из всех прочих источников. Если бы Thunder отдавал 5000, а retrieval 200, лента была бы принципиально другой — почти целиком из подписок, — при абсолютно тех же весах ранжирования и той же модели.

5. Кеш отранжированного как источник

Отдельного внимания заслуживает CachedPostsSource. Он возвращает посты, уже отранжированные в предыдущем запросе.

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

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

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

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

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

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

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

• thunder/posts/post_store.rs — структуры в памяти, индексы по авторам, вычистка старого.
• UpdateKnownForSBFRunner.scala — построение сообществ разреженной бинарной факторизацией.
• InterestedInFromKnownFor.scala — интересы пользователя из сообществ авторов, недельный пересчёт.
• home-mixer/sources/ — подключение всех источников к ленте.
• Курс: глава «Виды кандидатогенераторов» о видах кандидатогенераторов, глава «Матричная факторизация» о матричной факторизации, глава «Два контура и лямбда-архитектура» о двух контурах.