0x00 한

Research / Daily reports

  • Sources read: 2
  • Canon files updated: 2
  • Radar entries: 1
In one lineX built a path that orders the For You video carousel with a dedicated CTR model and a filter that removes videos watched within three days. Both are off by default, so current behavior is unchanged.

Other changes reviewed today:

  • X's mention and reply notifications are no longer sent to recipients who do not follow the author of a post carrying a risky reply label.
  • Alibaba reported deploying a re-ranking evaluator that treats impressions and clicks as a single chain to all Taobao traffic.

Source xai-org/x-algorithm 2e2295b — X (xAI), 2026-11-06, code. In these notes' numbering, this is Gen4+Gen58.4+N is the number these notes assigned in order to commits after the 2026-08-13 Gen4 release).

Background X For You (a recommendation timeline that mixes in posts from accounts the user does not follow) has a carousel module that places 3–5 vertical videos as a bundle in the 6th slot of the feed. After it was introduced off by default on 2026-10-08, the order of videos in the carousel has been set by a value that sums the probabilities predicted by Phoenix (X's Grok-based ranking Transformer) multiplied by weights. Until now only the weight of "probability of opening the video" was not 0, so the order was effectively that probability. This commit added, off by default, a path that can replace that weighted sum with a carousel-specific CTR (click-through rate) model, and a filter that removes recently watched videos from the carousel.

What we learnedA. A dedicated logistic regression model that sets the carousel order was introduced

  • When the switch is on, the score of a carousel video is the output of a linear model that takes "the logit of the probability of opening the video and the video embedding" as input, instead of the weighted sum verified — home-mixer/util/video_carousel_ctr_model.rs:20-34.

    • The video embedding has 1024 dimensions, and the model is discarded if the number of weights in the model file is not 1024.
    • The open probability is clipped to 1e-6–1−1e-6 and then converted to a logit, which is kept from falling below the lower bound set by the model (video_open_logit_min).
    self.intercept + self.video_open_weight * video_open_logit + embedding_term
    // embedding_term = Σ embedding[i] * embedding_weights[i]
    
  • The model is not in the code; home-mixer (the service that receives For You requests) fetches it by name from VMRanker (a separate service that handles slate reordering) verified — query_hydrators/video_carousel_ctr_model_query_hydrator.rs:23-64.

    • The fetched model is re-fetched in the background every 60 seconds. The first request is handled with the existing weighted sum, without a model.
    • The model is not used if the embedding version it was trained with differs from the embedding version in the serving configuration. The example version name in the test is v8_search_1.
    • The switch EnableVideoCarouselCtrModel is false by default, and the model name VideoCarouselCtrModelName is an empty string — params/param.rs.
  • In the same commit, a fifth term, "probability of opening the video × expected seconds of continued home video viewing", was also added to the weighted-sum side, and the default weight is 0.0 verified — util/video_carousel.rs:58-74.

    • The continuation seconds are the value of the home excursion head (time spent continuing to watch a video opened in the home feed), which the home ranker began predicting in the 2026-11-04 commit. A missing value counts as 0.
    • The parameter is VideoCarouselVideoContinuationWeight (default 0.0).

What we learnedB. A filter that does not re-insert videos watched in the carousel within the last 3 days was introduced

  • When the switch is on, it reads the per-user carousel watch record from Redis and removes from the carousel candidates the videos watched in the carousel within the past 3 days and their original posts verified — query_hydrators/video_carousel_seen_query_hydrator.rs:9-46.
    • The constants are SEEN_WINDOW_MS = 3 days and MAX_IDS = 2_000. The key prefix is vcs:1:.
    • The same record is used in both the carousel candidate filter and the extra carousel candidates of the top-K selector — filters/video_carousel_filter.rs, selectors/top_k_score_selector.rs.
    • The switch EnableVideoCarouselSeenFilter is false by default. If the Redis connection fails, the filter is replaced by a client that does nothing.
  • This commit has no code that writes the record inferred. The basis is that the only code in the diff that writes to this key is the zadd_prune_expire call in a test.

What we learnedC. Visibility rules for notifications and the Home timeline changed slightly

  • Mention and reply notifications are not sent for a post carrying the RISKY_HIGH_VIZ_REPLY label (a safety label attached to high-impression risky replies) when the recipient does not follow the author verified — visibility-filtering/rules/tweet_rules.rs:1022-1027.
    • The new rule was added only to the two levels NOTIFICATIONS_WRITER_V2_MENTION and _REPLY — rules/levels.rs:217, 261.
    • The golden corpus (expected-value tests that pin rule outcomes) pins that the post remains visible to followers and to the author themselves.
  • The region-restricted media (media that cannot be viewed in the requesting country) rule no longer applies to the author themselves, and was newly added to the TimelineHome level as well verified — tweet_rules.rs:891-896.
    • The rule's target changed from Everyone to NonAuthors.
    • TimelineHomeRecommendations originally had this rule inside the media takedown bundle, and this time that bundle was unpacked so the rule is applied earlier — levels.rs:313, 346.

What we learnedOther changes

  • The cron mirror (a file that syncs production configuration defaults to the repo daily) sync time changed to 2026-11-05T16:00:35Z, and ranking weights did not change verified — params/param.rs.
    • Experiment22Fou and Experiment23Fou were added at a 0.3 ratio to the shadow traffic targets (a path that also sends some real requests to experiment models and records scores only in logs).
  • The visibility verdict for Like and Repost notifications now looks at the recipient's own post as well as the acting account verified — rules/notification_kind.rs.
  • Four fields, eta, nuAuthor, nuSid and priorTau, were added to the page decode re-ranking request, and home-mixer sends all of them empty verified — scorers/page_decode_rerank_scorer.rs.
    • Judging by the names, they are a repeat penalty per author and per SID (semantic ID, a representation of an item as a hierarchical code) and a prior-distribution temperature inferred. The only basis is the field names.
  • DENSE_WITH_RECENT_IMPRESSIONS was added to the history aggregation kinds in the proto, and nothing uses it yet verified — recsys.proto.
  • An option to read ad campaign, line item and creative format as hashed IDs was introduced in the training data, off by default verified — phoenix/xrex/data/recsys/ad_side_ids.py.
    • Campaign and line item are hashed into 2^19 buckets. The creative format is 48 card types and 8 media types.
  • The candidate bundle size in the immersive surface page RL training preset was fixed to 128 from [32, 128] verified — phoenix/xrex/configs/xrecsys.py.
  • Ten filters were changed to use a shared split function, with no policy change verified — candidate-pipeline/filter.rs.
  • DSCP (network packet priority marking) settings were introduced for the checkpoint server and the Phoenix prediction server verified — checkpoint_server.rs.

Canon update services/x.md In the carousel ranking score sub-bullets under ## Feed surfaces, added two lines for the continuation term and the CTR model path, and added a bullet for the 3-day watch filter under the carousel item. After the introduction of ## Safety / visibility-filtering / labeling pipeline, added a paragraph on region-restricted media and notification rules. Raised the git log reference in ## Sources to 2e2295b, and added a Gen4+58 row to the change log summary table.

Why it matters X is preparing to move the carousel order from a hand-tuned weighted sum to a trained model. The basis is that it has already built a path that fetches the model from outside the service and refreshes it every 60 seconds. However, the carousel itself and both features are off by default, so actual For You behavior does not change as of 2e2295b.

2A re-ranking evaluator that sees impressions and clicks as one chain — Alibaba

Source Beyond Independent Predictions: Learning the Browsing Journey for Sequence-Level Re-ranking — Alibaba Taobao & Tmall Group, 2026-11-05 v1, paper.

Background In the Generator–Evaluator approach to re-ranking, several candidate slates (sets of items shown at once) are generated and an evaluator picks the best one. Usually the evaluator predicts CTR for each item separately and sums them, so it cannot reflect whether the user scrolls down to the lower items. This paper has the evaluator jointly model the chain "show → actually view → click".

What we learnedA. The paper writes that clicks and revenue rose in a Taobao app A/B test and that it was deployed to full traffic

  • It reports +0.70% clicks and +3.67% revenue in a 14-day online A/B test verified — arXiv HTML.
    • It writes that the latency increase is under 0.5ms.
  • Five of the seven authors are affiliated with Alibaba verified — same HTML.

"together with a 14-day online A/B test in the Taobao App (+0.70% clicks, +3.67% revenue) and full-traffic deployment, validate the effectiveness and robustness of our approach" — Beyond Independent Predictions (paper), 2026-11-05

Canon update It is not directly tied to a tracked service, so it was added only as an "Alibaba ICE" entry in radar.md ## New this month.

Why it matters There is one more piece of evidence that slate-level evaluation is used in e-commerce feed production. ByteDance's OneTrans-GSR from the same week also uses a reward model that evaluates the whole slate. X's VMRanker does DPP slate reordering with a different approach, so we put this under watching.

Radar

What to check next