X liberou como código aberto o núcleo do sistema de recomendação que monta o feed “For You”. Na prática, é o “cérebro” que precisa resolver uma pergunta gigantesca toda vez que você abre o app: entre centenas de milhões de posts, quais entram no seu feed agora?
A grande virada do projeto é a promessa de simplificar o que antes era cheio de ajustes manuais. Segundo a descrição do repositório, saem de cena as features feitas “na mão” e a maior parte das heurísticas (regrinhas de ajuste). Em vez disso, entra um modelo baseado em transformer do tipo Grok, que aprende relevância olhando para o seu histórico de engajamento: o que você curtiu, respondeu, repostou, clicou e até sinais negativos, como bloquear ou silenciar.
Repositório oficial: https://github.com/xai-org/x-algorithm
Como o sistema é organizado por dentro: a visão geral
O repositório chama esse conjunto de “X For You Feed Algorithm” e explica que o feed mistura conteúdo de duas fontes e depois faz a ordenação (ranking):
- In-Network (dentro da sua rede): posts de contas que você segue, vindos do Thunder.
- Out-of-Network (fora da sua rede): posts descobertos no “corpus global” via Phoenix Retrieval, com busca por similaridade usando machine learning.
Depois que esses candidatos são reunidos, entra o Phoenix (com um transformer baseado no Grok) para prever probabilidades de engajamento em várias ações e transformar isso em uma pontuação final.
O código também aponta que a implementação do transformer foi portada do release open source do Grok-1 da xAI, adaptado para casos de uso de recomendação.
O “pipeline” em dois estágios: buscar candidatos e depois ranquear
O funcionamento descrito se divide em dois momentos principais, que acontecem em sequência:
- Retrieval (busca de candidatos)
- Ranking (ranqueamento/ordenação)
A ideia é simples de entender: primeiro você reduz milhões de posts para algo em torno de ~1000 candidatos. Depois, com esse conjunto “possível”, você calcula quem merece aparecer antes no feed.
1) Retrieval: reduzindo milhões para ~1000 candidatos
A etapa de retrieval junta candidatos de duas fontes, com perfis bem diferentes.
Thunder é o lado “rápido e direto” do sistema: um armazenamento em memória (in-memory) que permite buscar posts recentes das contas que você segue com latência muito baixa (o texto fala em consultas em “sub-millisecond”). Ele existe justamente para servir o conteúdo “da sua rede” sem precisar bater em banco externo.
Já o Phoenix Retrieval é o lado “descoberta”: ele tenta achar posts relevantes de contas que você não segue. Para isso, usa um two-tower model (modelo de duas torres), com uma lógica de embeddings e busca por similaridade.
- User tower: transforma seus sinais (incluindo histórico de engajamento) em um embedding normalizado.
- Candidate tower: transforma os posts do corpus em embeddings.
- Similarity search: recupera os melhores candidatos usando similaridade por dot product (produto escalar).
Na prática, isso significa que o sistema tenta aproximar “você” e “posts” no mesmo espaço numérico (os embeddings), e pega os mais próximos para virar candidato ao feed.
2) Ranking: o transformer prevê o que você tende a fazer
Com os candidatos em mãos, o ranqueamento é feito por um transformer baseado em Grok. Ele recebe o seu contexto (principalmente a sequência de ações/histórico de engajamento) e os posts candidatos, e prevê probabilidades para várias ações — não só ações “boas”, mas também sinais negativos.
O repositório descreve uma lista de previsões de probabilidade (por exemplo):
- P(favorite)
- P(reply)
- P(repost)
- P(quote)
- P(click)
- P(profile_click)
- P(video_view)
- P(photo_expand)
- P(share)
- P(dwell)
- P(follow_author)
- P(not_interested)
- P(block_author)
- P(mute_author)
- P(report)
Depois, essas probabilidades viram uma nota final por meio de um cálculo de soma ponderada. O próprio documento descreve a fórmula assim:
Final Score = Σ (weight_i × P(action_i))
Ou seja: ações positivas (curtir, repostar, compartilhar) recebem pesos positivos; ações negativas (bloquear, silenciar, denunciar) recebem pesos negativos. O efeito direto é empurrar para baixo conteúdos que o sistema acredita que você vai rejeitar.
É esse “mix” que explica por que o feed não é só “posts que você pode curtir”: ele também tenta evitar posts que têm chance alta de gerar sinais negativos.
E tem uma leitura bem direta do que está acontecendo: seu histórico de engajamento está sendo processado por uma arquitetura de transformer — que nasceu para modelagem de linguagem — e foi reaproveitada para prever o que te faz continuar rolando o feed 🤔
Quem coordena tudo: o Home Mixer e o fluxo completo
O repositório descreve um componente chamado Home Mixer, que funciona como camada de orquestração do feed “For You”. Ele usa um framework chamado CandidatePipeline, que organiza o processo em etapas bem claras.
O fluxo, em termos simples, fica assim:
- Query Hydration: busca contexto do usuário, como a sequência de ações (engagement history) e user features (por exemplo, lista de contas seguidas e preferências).
- Candidate Sources: puxa candidatos do Thunder (rede) e do Phoenix Retrieval (fora da rede via ML).
- Hydration: “enriquece” cada candidato com dados extras (metadados do post, info do autor, entidades de mídia etc.).
- Filtering: remove o que não deve entrar (duplicados, posts antigos, posts do próprio usuário, autores bloqueados, palavras silenciadas etc.).
- Scoring: roda o Phoenix Scorer para prever probabilidades e o Weighted Scorer para combinar tudo na nota final.
- Selection: ordena por pontuação e escolhe o top K.
- Filtering (Post-Selection): faz checagens finais de visibilidade (como removidos/spam/violência/gore etc.) e deduplicação.
O texto também menciona que o servidor expõe um endpoint gRPC chamado ScoredPostsService, que retorna os posts já ranqueados para um usuário.
Thunder: posts recentes em memória e ingestão em tempo real
O Thunder é descrito como um armazenador de posts em memória e um pipeline de ingestão em tempo real. Ele:
- Consome eventos de criação/remoção de posts via Kafka.
- Mantém “stores” por usuário para posts originais, replies/reposts e posts de vídeo.
- Entrega candidatos “in-network” (de quem você segue).
- Remove automaticamente posts mais velhos do que o período de retenção.
Aqui o foco é desempenho: servir rapidamente conteúdo da sua rede sem depender de consultas pesadas em banco.
Phoenix: recuperação fora da rede e ranqueamento com transformer
O Phoenix aparece como o componente de ML com duas funções principais:
- Retrieval com two-tower model (usuário e candidatos em embeddings, busca por similaridade via dot product).
- Ranking com transformer (baseado em Grok) para prever probabilidades de ações e apoiar o cálculo do score.
Um detalhe técnico importante que o repositório destaca é o uso de “isolamento de candidatos” durante a inferência do transformer: existe um mascaramento de atenção (attention masking) para que os candidatos não “olhem” uns para os outros, apenas para o contexto do usuário. A promessa aqui é consistência: o score de um post não depende de quais outros posts entraram no mesmo lote de avaliação, o que ajuda a tornar os resultados mais estáveis e até cacheáveis.
Candidate Pipeline: um framework “encaixável” para montar recomendação
Além dos componentes principais, o repositório descreve um framework reutilizável chamado candidate-pipeline, com “traits” (papéis) para montar pipelines de recomendação por composição:
- Source: busca candidatos em uma fonte.
- Hydrator: enriquece candidatos com dados adicionais.
- Filter: remove o que não deve aparecer.
- Scorer: calcula scores de ranking.
- Selector: ordena e seleciona os melhores.
- SideEffect: efeitos assíncronos (cache, logging).
O texto diz que o framework consegue rodar fontes e hidratações em paralelo quando possível, com tratamento de erro e logging configuráveis.
Filtros: o que sai antes e depois do ranking
A filtragem aparece em dois momentos: antes do score e depois da seleção final.
Entre os filtros “pré-score”, o repositório lista exemplos como:
- DropDuplicatesFilter (remover IDs duplicados)
- CoreDataHydrationFilter (tirar posts que falharam ao hidratar metadados)
- AgeFilter (remover posts antigos)
- SelfpostFilter (remover posts do próprio usuário)
- RepostDeduplicationFilter (deduplicar reposts do mesmo conteúdo)
- IneligibleSubscriptionFilter (remover conteúdo pago sem elegibilidade)
- PreviouslySeenPostsFilter e PreviouslyServedPostsFilter (evitar repetir conteúdo)
- MutedKeywordFilter (remover palavras silenciadas)
- AuthorSocialgraphFilter (remover autores bloqueados/silenciados)
Depois da seleção, entram filtros finais de visibilidade e deduplicação de conversas, como:
- VFFilter (conteúdo deletado/spam/violência/gore etc.)
- DedupConversationFilter (deduplicar múltiplos ramos da mesma thread)
Decisões de design: o que o projeto faz questão de frisar
O repositório lista algumas decisões que explicam a filosofia do sistema:
- No Hand-Engineered Features: a relevância fica por conta do transformer, sem “engenharia manual” de features para relevância de conteúdo.
- Candidate Isolation: candidatos isolados no ranking, evitando dependência do batch.
- Hash-Based Embeddings: uso de múltiplas funções de hash para lookup de embeddings em retrieval e ranking.
- Multi-Action Prediction: em vez de prever um único número de “relevância”, prevê várias probabilidades de ações.
- Composable Pipeline Architecture: pipeline flexível, com separação de execução/monitoramento da lógica e facilidade para adicionar fontes, hidratações, filtros e scorers.
Um exemplo direto do score, do jeito que o repositório descreve
O texto não traz valores de pesos, mas deixa claro o formato: você tem várias probabilidades previstas e combina tudo com weights. Um post com alta chance de P(repost), P(reply) e P(dwell) tende a subir; um post com maior chance de P(block_author) ou P(mute_author) tende a cair.
É uma lógica que tenta equilibrar “o que você gosta” e “o que você provavelmente vai rejeitar”, para decidir o que ocupa as primeiras posições do feed.
Conclusão
Ao abrir o código do algoritmo do feed “For You”, X expõe um sistema que se apoia em dois pilares: uma busca rápida do que vem da sua rede (via Thunder) e uma descoberta fora da rede por similaridade (via Phoenix Retrieval com two-tower model). Depois, tudo passa por um ranqueamento com transformer baseado em Grok, que prevê várias ações possíveis e combina isso num score final, com pesos positivos e negativos.
No fim das contas, o feed que aparece na sua tela é o resultado de um pipeline grande, com hidratação de dados, filtros em duas fases e um modelo que tenta transformar seu histórico de engajamento em uma previsão do que você vai fazer com cada post — e, com isso, decidir o que merece aparecer primeiro.