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

Разметка и видимость: можно ли показать этот пост

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

1. Три ответа вместо двух

pub enum VfAction {
    Allow,
    Drop(FilteredReason),
    Interstitial(FilteredReason),
}

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

Промежуточный вариант — заглушка, которую пользователь может нажать и посмотреть содержимое, — это не мелочь интерфейса, а важное проектное решение.

2. Как вычисляется вердикт

fn evaluate_rules(rules: &[Box<dyn Rule>], context: &RuleContext<'_>) -> Verdict {
    let mut worst = VfAction::Allow;
    let mut decided_by = None;
    for rule in rules {
        match rule.evaluate(context) {
            VfAction::Drop(reason) => {
                return Verdict { action: VfAction::Drop(reason), decided_by: Some(rule.name()) };
            }
            VfAction::Interstitial(reason) => {
                if matches!(worst, VfAction::Allow) {
                    worst = VfAction::Interstitial(reason);
                    decided_by = Some(rule.name());
                }
            }
            VfAction::Allow => {}
        }
    }
    ...
}

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

Три свойства, каждое со смыслом.

• Запрет обрывает проверку немедленно. Как только правило сказало «не показывать», функция возвращается — остальные двадцать восемь правил не вычисляются. Это экономия: правила ходят за лейблами, и лишние обращения стоят денег.
• Заглушка не обрывает. Она запоминается как текущий худший вердикт, но перебор продолжается — потому что дальше может встретиться запрет, а он строже.
• Побеждает первая заглушка, а не последняя. Условие if matches!(worst, VfAction::Allow) означает, что второе правило с заглушкой уже ничего не изменит.

3. Два набора правил: почему подписчику показывают больше

Правила разбиты на политики по уровню строгости:

pub struct Policies {
    filter_all: Vec<Box<dyn Rule>>,
    timeline_home: Vec<Box<dyn Rule>>,
    timeline_home_recommendations: Vec<Box<dyn Rule>>,
}

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

Базовый набор — 29 правил, применяемых ко всему в ленте. Второй набор — дополнительный, только для рекомендаций, то есть постов от тех, на кого зритель не подписан.

Посмотрите на состав второго набора — в нём систематически встречается слово «high recall»:

4. Откуда берутся лейблы

Правила читают лейблы. Лейблы производит вторая дорожка системы — та, что работает непрерывно и к вашему запросу отношения не имеет.

Репутация по реакции других

Первый способ оценить аккаунт — посмотреть, как на его посты реагируют. В коде видны названия метрик: ReportsPerFav, SpamReportsPerFav, окно наблюдения — 30 дней.

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

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

Репутация по графу

Второй способ вообще не смотрит на содержимое. Он запускает PageRank по графу подписок и взаимодействий, получая для каждого аккаунта «массу», а из неё — скор:

private val ScoreSlope = 7.07
private val ScoreIntercept = 165.2

val score = if (mass <= 0) 0.0 else ScoreIntercept + ScoreSlope * scala.math.log(mass)

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

Ценность этого сигнала в том, что он дорог в подделке. Написать спамный текст ничего не стоит, а вот попасть в центр графа подписок нельзя без того, чтобы на тебя реально подписались живые люди. Накрутка подписчиков ботами тут почти не помогает: PageRank учитывает вес источника, а масса самих ботов близка к нулю.

Репутация по собственному поведению

Третий способ — самый интересный для нас, потому что архитектурно он повторяет рекомендательную модель. Из описания в репозитории:

Трансформер над последовательностью действий, определяющий неаутентичные аккаунты — ботов, спам, скоординированное поведение — по потоку их поведенческих событий.

Движок правил

Лейблы ставят не модели напрямую, а движок правил: botmaker — язык, компилятор и исполнитель, scarecrow — сервис, который применяет правила к событиям по мере их поступления. Правило читается как «на такое событие, если выполнены такие условия, поставить такой лейбл».

Зачем отдельный язык, если можно писать на обычном? Затем же, зачем правила видимости вынесены из модели: чтобы изменение можно было раскатить без выкатки кода, чтобы оно было читаемо не только программистами, и чтобы его можно было проверить и оспорить.

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

5. Отчёт пользователю как часть системы

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

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

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

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

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

• rules/registry.rs — все правила и разделение на политики.
• UserCredV2.scala — превращение массы PageRank в скор.
• bdsm/README.md — трансформер над последовательностью действий аккаунта.
• agatha/scalding/RateBasedBuildJob.scala — метрики вида «жалоб на лайк» за 30 дней.
• Курс: глава «AUC и калибровка» о компромиссе точности и полноты, глава «Трансформеры над историей» о трансформерах над последовательностями, глава «Длинный хвост и степенной закон» о степенных законах.