Supplement · The X algorithm · page 6 of 11

Scoring: from action probabilities to one number

The most discussed part of the system and the most misunderstood one. Here we look at what exactly the model predicts, with what weights that is combined into one score, what happens to the score afterwards — and why the ratio of the weights does not support the conclusions usually drawn from it.

1. What the model predicts

The heads of the model are grouped by meaning. Here is the full list from the README, with an explanation of what each one means.

Note the last row: «did not dwell» is a separately predicted quantity with a negative weight. Formally it is not an action of the user but its absence. We discussed such a move in the chapter «The problems of implicit data», when talking about implicit feedback: scrolling past is information too, and not using it is wasteful.

2. The weights: the real numbers

The weights are declared by the param! macro — a name, a type, a key in the configuration system, a default value. The defaults in the repository are synchronised with the production ones by a script, so these are not invented numbers.

param!(FavoriteWeight, f64, "rust_home_mixer_favorite_weight", 0.5);
param!(ReplyWeight, f64, "rust_home_mixer_reply_weight", 5.0);
param!(ShareViaCopyLinkWeight, f64, "rust_home_mixer_share_via_copy_link_weight", 20.0);
param!(ReportWeight, f64, "rust_home_mixer_report_weight", -234.0);

A fragment of param.rs · code by X, Apache 2.0, commit 28e414f

Fragments of home-mixer/params/param.rs.

3. The formula and what happens to a negative score

The arithmetic in ranking_scorer.rs is straightforward: every term is a weight times a predicted probability, the positive and negative ones are accumulated separately only for reporting, and then the difference is taken.

let mut pos = 0.0;
let mut neg = 0.0;
for t in terms {
    if t >= 0.0 { pos += t; } else { neg -= t; }
}
(pos, neg)

A fragment of ranking_scorer.rs · code by X, Apache 2.0, commit 28e414f

That is, the raw score is simply

where the weights of the negative actions are already negative. But this number is not used directly: it is passed through offset_score.

pub(crate) fn offset_score(combined_score: f64, w: &ScoringWeights) -> f64 {
    if w.total_sum == 0.0 {
        combined_score.max(0.0)
    } else if combined_score < 0.0 {
        (combined_score + w.negative_sum) / w.total_sum * NEGATIVE_SCORES_OFFSET
    } else {
        combined_score + NEGATIVE_SCORES_OFFSET
    }
}

A fragment of ranking_scorer.rs · code by X, Apache 2.0, commit 28e414f

Let us work out what this does

The constant NEGATIVE_SCORES_OFFSET equals 0.001. Let us take both branches.

The score is non-negative. 0.001 is simply added to it. So any such post gets a result of no less than 0.001.

The score is negative. It is mapped linearly by the formula

Look at the boundaries. The worst possible post is one where all the negative actions have probability 1 and the positive ones 0. Its raw score equals \(-367.22\), and the formula gives exactly 0. A score that just barely fell short of zero gives almost \(\frac{367.22}{410.54} \cdot 0.001 \approx 0.000894\).

4. The main misconception: «a report cancels out 468 likes»

The weight of a report is \(-234\), the weight of a like is \(0.5\). The ratio is 468. The number flew round the internet with the conclusion: one report destroys the effect of 468 likes.

The conclusion is wrong, and the developers deliberately added a comment about it to the code. The reason is simple: the weight is multiplied not by a count of events but by a predicted probability.

// Each weight multiplies the *predicted* probability of that
// ... the weights do not multiply raw engagement counts.
// One common misinterpretation is that you can read these weight
// ...
fn apply(score: Option<f64>, weight: f64) -> f64 {
    score.unwrap_or(0.0) * weight
}

A fragment of ranking_scorer.rs · code by X, Apache 2.0, commit 28e414f

Let us take it in numbers. Suppose that for an ordinary post the model reckons you will like it with probability 0.02 and report it with probability 0.00005. Then the contributions are:

• the like: \(0.5 \times 0.02 = +0.010\);
• the report: \(-234 \times 0.00005 = -0.0117\).

The report outweighs the like by a factor of 1.17, not 468. The ratio of 468 is reached only in one case: if the model considers a report as likely as a like. But if the model thinks so, this is no longer an ordinary post, and its place at the bottom of the feed is exactly what was intended.

5. Three corrections on top of the score

The raw sum is not yet the final order. Three multipliers come next, and the order of their application in the code is: first the boost for a little-known author, then the decay on a repeated author, then the out-of-network discount.

Decay on a repeated author

The task is obvious: do not let one author take over the whole feed. The solution in the code is a multiplier depending on how many posts by this author already stand higher by score.

fn diversity_multiplier(decay_factor: f64, floor: f64, exponent: f64) -> f64 {
    (1.0 - floor) * decay_factor.powf(exponent) + floor
}

A fragment of ranking_scorer.rs · code by X, Apache 2.0, commit 28e414f

Substituting:

The shape of the formula is worth taking apart. It is not simply \(\text{decay}^k\) — otherwise the multiplier would go to zero and a sufficiently active author would disappear from the feed entirely. The construction \((1-\text{floor}) \cdot \text{decay}^k + \text{floor}\) is geometric decay raised onto a floor: it falls fast on the first repeats and comes to rest at 0.25.

The out-of-network discount

Posts from people the viewer does not follow are multiplied by 0.75. The logic: such a post has to be noticeably better than «one of your own» to take its place, because the risk of a miss is higher.

But more interesting than the multiplier itself is the condition under which it applies:

let oon_applies = |c: &PostCandidate| match c.in_network {
    Some(false) => true,
    Some(true) => {
        deboost_in_network_replies_retweets
            && (c.in_reply_to_tweet_id.is_some() || c.retweeted_tweet_id.is_some())
    }
    None => false,
};

A fragment of ranking_scorer.rs · code by X, Apache 2.0, commit 28e414f

The discount is received not only by other people's posts but also by replies and reposts from those you do follow (the flag is on by default). That is a subtle and correct move: by following a person you agreed to read their posts, not everything they comment on and forward. Without this line the feed of your follows would quickly turn into a stream of other people's conversations.

There are two more cases:

• if the request goes by a particular topic, the multiplier is different — 0.5: in a topical feed follows mean less and the requirements on someone else's post are stricter;
• for new users with enough follows a separate, milder multiplier applies — an obvious correction for the cold start of a viewer: there are few follows yet, and without other people's posts there would simply be no feed.

Lifting a little-known author

Here the mechanics work quite differently from what people usually assume, and that is worth going through carefully.

It is not a multiplier and it is applied not to all the posts of newcomers. Out of all the candidates the suitable ones are selected: an author with a follower count below a threshold (1000), a post with an impression count below a threshold (1000), fresh enough (no older than a day) and standing not too low in the current order. Out of those exactly one is taken — the best by score — and its score is set equal to the one standing at position 15–16 of the sorted list.

fn cold_start_target(query: &ScoredPostsQuery, scores: &[f64]) -> Option<f64> {
    let mut ranked = scores.to_vec();
    ranked.sort_by(|a, b| b.total_cmp(a));
    let hi = (query.params.get(ColdStartSlotMax) as usize).min(ranked.len());
    let lo = (query.params.get(ColdStartSlotMin) as usize).min(hi);
    if lo >= hi { return None; }
    Some(ranked[rand::rng().random_range(lo..hi)])
}

A fragment of author_cold_start.rs · code by X, Apache 2.0, commit 28e414f

It reads transparently: the target is not the first position but the middle of the visible part of the feed. The point is not «make the newcomer a star» but «give one of their posts a chance to be seen», so that the system gets any signal about it at all.

6. Re-ranking: DPP over embeddings

After the score has been computed and the corrections applied, a separate service is called. It selects posts by a determinantal point process — that same DPP we discussed in the chapter «Diversity and re-ranking» alongside MMR.

Let us recall the idea. A kernel \(L\) is built in which the quality of an item stands on the diagonal and the similarity off it. The determinant of the submatrix of the chosen set is maximised, and a determinant is the squared volume of the parallelepiped on the set's vectors. The length of an edge is set by quality, the angle between edges by dissimilarity. Two nearly identical posts give nearly collinear edges, the volume collapses — and the duplicate is filtered out by itself, with no separate penalty term.

The parameters this is called with live in two places, and that is worth distinguishing:

The first column is the defaults of the service's own arguments, the second the parameters the feed sends. The caller wins, so in production 0.65 and 150 are what work. The discrepancy is not a mistake: the service is standalone and has its own defaults in case it is run separately.

The restriction max_selected_rank deserves attention. Re-ranking does not touch the whole list — only the first 150 positions. There is no point beyond that: the user will not get there, and computing determinants is expensive.

Common mistakes and hidden rocks

Interview questions

One-screen cheat sheet

Primary sources

• home-mixer/params/param.rs — all the weights and parameters with the authors' comments on how to read them.
• home-mixer/scorers/ranking_scorer.rs — the arithmetic of the score, offset_score, the decay, the OON discount.
• home-mixer/scorers/author_cold_start.rs — lifting a little-known author and Thompson sampling.
• vm-ranker/dpp.rs and args.rs — the re-ranking and its parameters.
• The course: the chapter «Multi-task learning» on multi-task learning, the chapter «Diversity and re-ranking» on MMR and DPP, the chapter «Thompson sampling» on Thompson sampling.