2026-10-22

Other changes reviewed today:

• X added a filter, off by default, that shrinks candidates by the same ratio per source when they exceed the Phoenix scoring budget of 2800.
• X built a path that sends value model weights with the retrieval request, but the default is empty, so it currently sends none.
• Kuaishou reported +0.613% in app usage time from a ranking that shrinks a 100,000-length user history with a distillation selector.

1Instagram Feed weights prediction baselines and increments separately — Instagram

• The score of Instagram Feed late-stage ranking (the final stage, which scores hundreds of candidates per request) is a weighted sum of engagement predictions verified — HTML version §1.

  • The target VMs are MainRank, which orders most of the feed, and TopRank, which fills the top of the session.
  • Weights are tuned to a few north-star metrics with online Bayesian optimization (an optimization that picks weight combinations one after another while watching experiment results).
  • Deployed VMs sometimes multiply some groups of terms, but the paper does not cover that structure.

• The paper leaves the original prediction term as it is and adds the increment Δ beyond the baseline as a term with a separate weight verified — same paper §1.

  • The original formula and the modified one are as follows (the original MathML was transcribed as text):

  s(c) = Σ_j w_j p_j(c)
  s(c) = Σ_j [ w_j^r p_j(c) + w_j^i Δ_j(c) ]
  

• There are three kinds of baselines verified — same paper §3.

  • The viewer baseline is that viewer's past action rate. The Feed like prediction has a rank correlation of 0.69 with the viewer's own past like rate.
  • The item baseline is item popularity (popularity bias) or structural attributes such as format and size.
  • The request baseline is the prediction statistics of the candidates in the same request.

• All three baselines are expressed by one operator, and the deployed forms are three verified — same paper §3.

  • The general form is Δ = m(p,b)[σ(k·d(p,b)) − shift], and for probabilities it uses d = logit(p) − logit(b).
  • The deployed forms are p σ(logit p − logit b), m σ(ŷ − b), and max(0, p − b), all with shift 0.
  • For the demotion term, it states that using m=p makes the penalty vanish when the prediction is at the floor, so it uses a form with a constant magnitude and the comparison direction flipped.

"The baseline is not a defect but a second signal that needs its own weight (§3). A habitual liker's likes are real engagement, and a broadly loved post deserves reach. But one coefficient w_j cannot trade the two components off, and the right trade-off is unknown a priori and differs by signal." — arXiv 2610.27423 (HTML), 2026-10-20

• Format bias such as video length is handled not by a VM term but by a label that counts as positive only when the item is in the top within the same format-and-size bucket verified — same paper §4.4.
  • Buckets are split by length for videos, by card count for carousels, and by OCR word count for photos. Exceeding the p75 of dwell time within the bucket makes the label positive.
  • It explains that popularity bias is a single item statistic of the same signal, so a VM term suffices, whereas format bias distorts the label itself, so it is fixed in the label.
  • The correlation between the video label and video length is r≈−0.017, smaller than the +0.216 of the original log dwell time prediction verified. It states that photo and carousel labels were not audited.

• Each term has four arms (both terms off, original term only, incremental term only, both), compared with 3% of traffic per arm verified — same paper §6.
  • Measurement covers the same 7-day window in which all 6 experiments were on, and each experiment ran 12–17 days.
  • Of the 13 (term, metric) pairs judged, in 11 the both-terms arm beat both single-term arms on point estimates. Seven pairs have both contrasts significant.
  • Of 26 direct contrasts, 17 were significantly favorable and 1 (impressions) was significantly unfavorable.
• The paper itself states the limitation that the single-term arms were not re-tuned verified — same section.

"Neither single-term arm was re-tuned. This favours both over incremental, whose weight was set beside the raw term. The design thus tests whether either term is redundant at the deployed point, not whether a re-tuned single-term VM could match it." — arXiv 2610.27423 (HTML), 2026-10-20

• The 6 deployed terms and the launch-decision metrics are listed below verified — same paper §5 Table 4.
  • The format bucket label launched with feed dwell time +0.447%, and the item-axis dwell gate (MainRank) with impressions +0.665%.
  • The see-more request term launched with an unconnected-post interest ratio of +0.63% (feed dwell time −0.118%), and the external-share viewer term with sessions +0.030%.
• The conclusion is that offline diagnostics (the correlation between prediction and baseline) should be used only to filter candidates, not to rank them verified — same paper §7. One tested term ranked 9th offline among 10 on the same axis.

• This structure ran in Instagram Feed production for nearly 1 year, and all 6 terms are on as of paper submission verified — same paper §5.
• Reels launched all three axes in both early-stage and late-stage, Threads launched in late-stage, and Facebook is testing it in ongoing experiments verified — same paper §8.
  • Reels launch examples include the late-stage viewer-axis like calibration (sessions +0.083%, DAU +0.042%) and content-calibrated skip demotion.

"Furthermore, Threads has launched debiased signals in late-stage ranking, and Facebook is testing debiased terms in ongoing experiments." — arXiv 2610.27423 (HTML), 2026-10-20

↑ Contents

2A filter that shrinks every source by the same ratio when candidates overflow — X

• The new filter groups candidates by served type (the source path a candidate came in through) and, when the total exceeds the budget, sets the number to keep in proportion to group size verified — home-mixer/filters/fair_share_ranking_filter.rs.
  • Division remainders are given out one at a time in descending order (largest remainder). Within a group, the first N in the current order are kept.
  • The budget is PhoenixScoresResultSize=2800 — params/param.rs:1189-1193.
  • A test pins that reducing in-network 440, SimClusters 220, and Phoenix retrieval 440 candidates (total 1100) to a budget of 1000 leaves (400, 200, 400).
• The switch EnableFairShareRanking is off by default (false) verified — params/param.rs:1194-1199.
  • Even when on, it does not act if the request is for cached posts or the Phoenix ranker kill switch is on.
  • It was placed at the very end of the pre-scoring filter list, right after FavHoldoutFilter — phoenix_candidate_pipeline.rs:437. It was also added to the score-only pipeline.
• While it is off, the Phoenix request currently sends only the first 2800 of the list verified — util/phoenix_request.rs:20, 192. With the filter on, the later sources in the list are likely no longer all cut; instead each source is cut by the same ratio inferred. The evidence is that the budget equals this 2800 and a test is named "drops_the_same_fraction_of_each_served_type".

let product = count as u128 * budget_u;
let keep = (product / total) as usize;
remainders.sort_by(|left, right| right.0.cmp(&left.0).then(left.1.cmp(&right.1)));

• The Phoenix retrieval request proto gained a per-name weight map field, and home-mixer parses a parameter value to fill it verified — sources/phoenix_source.rs:137-138.
  • The field is RetrieveTopKCandidatesRequest.value_model_weights = 17 — recsys.proto:298.
  • The parameter RetrievalValueModelWeights is a JSON object string whose default is an empty string — params/param.rs:281-286. If it is empty or malformed, nothing is sent.
• This commit has no code where the retrieval server reads this field verified. Because two-tower (a retrieval model that embeds user and post separately) has had multiple heads since the 2026-10-13 commit (Gen4+40), we infer this is preparation for varying head weights per request inferred. The evidence is that the field name matches the ranker's value model.

• Added a side effect (a stage that leaves only logs without changing the response) that records the position and score of carousel videos to Kafka in responses where the carousel was actually served. The switch is off by default verified — video_carousel_candidates_kafka_side_effect.rs.
  • The switch is EnableVideoCarouselCandidatesLogging=false (param.rs:1150-1155), and the carousel itself is off by default.
• The topic novelty measurement introduced in the 2026-10-20 commit now also measures the share of posts in languages the viewer does not use. It is still off because the history topic switch is false by default verified — serendipity_stats_side_effect.rs:19, 145-176.
  • The viewer's languages are those that make up at least 5% of engagement history (MIN_USER_LANGUAGE_SHARE = 0.05) plus the app language. The new metrics are CrossLanguageShare, CrossLanguageShareTop10, and others.
• The candidate-packing option name in Phoenix training was renamed and is turned on only in the H100 preset, and the candidate-region attention kernel also supports SM100 (the GB200/GB300 GPU generation). The model structure and loss are unchanged verified — configs/xrecsys.py:463-474.
• VF (visibility-filtering, a service that decides whether each post can be shown) verdicts now carry the rule ID directly, and an account-level verdict path was added as code not yet in use verified — models/verdict.rs:37.
  • If the author-relationship lookup of a quoted post fails, both user rules and post rules now read that value as "unknown" — rules/engine.rs:427-440, 628. We infer the visible result is the same because the default is false inferred.
• The backfill limit of abuse-enforcement-service moved from GrowthBook to a stored config record, and the rate is 0 until someone sets it verified — service-lib/src/backfill.rs:112-117. It is unrelated to feed ranking.

↑ Contents

3A distillation selector shrinks a 100,000-length history and raises app usage time — Kuaishou

• A 7-day A/B (5% of traffic) on Kuaishou's largest short-video surface recorded total app usage time +0.613% and per-user app usage time +0.640% verified — HTML version §4.6.
  • It states that this surface has more than 400 million DAU and more than 50 billion interaction logs per day.
• The baseline system being compared already uses TWIN-family retrieval and sequence compression verified — same section.
• It states that it cut online sequence-branch FLOPs by about 160× relative to a representative end-to-end model at L=100K verified — abstract.

"Notably, the existing production system already incorporates advanced long-sequence modeling techniques, including TWIN-based behavior retrieval and sequence compression mechanisms similar to C-Former and SequenceO1." — arXiv 2610.28569 (HTML), 2026-10-20

↑ Contents

Radar

• ECHO (arXiv 2610.28569): Added Kuaishou's 100,000-length history ranking to ## New this month.
• SPAR (arXiv 2610.27898): Youku retrieves long-term history matching the prefix at each SID (an ID that represents an item as a sequence of semantic tokens) decoding step and reduces branch skew, gaining watch time +3.95% in a 10% traffic A/B. Attached as additional evidence to the generative retrieval thread (only the abstract was read).

↑ Contents

What to check next

↑ Contents

Lookup status

• X: There was 1 new commit (7f2ca2b) in xai-org/x-algorithm. Releases were not checked.
• Meta: The latest post in the engineering.fb.com RSS is dated 2026-10-19 and was already checked in the 2026-10-21 batch. ai.meta.com/blog and transparency.meta.com were not checked this time.
• Netflix: The latest post in the RSS is dated 2026-10-16 and was already checked. research.netflix.com/publications was not checked.
• arXiv cs.IR: Parsed 30 entries. The latest submission is 2026-10-20, and 3 passed: the Instagram paper (canon update), ECHO, and SPAR. A paper designing generative retrieval SIDs with LLM evolutionary search was dropped because it has only public benchmarks.
• WebSearch cross-checking was not done this time.

↑ Contents