Abri o código-fonte do algoritmo do X: like, reply e repost não valem o que todo mundo está repetindo

Todo mundo já viu a tabela. Reply vale 13,5. Retweet vale 1. Like vale 0,5. Uma resposta que o autor engaja vale 75. Portanto, comente em tudo e o algoritmo empurra a sua conta.

Eu baixei o repositório oficial twitter/the-algorithm — 7.696 arquivos, último commit público em 3 de setembro de 2025 — e o twitter/the-algorithm-ml, onde o Twitter publicou os pesos numéricos de 5 de abril de 2023. A tabela existe. O que não existe é a conclusão que as pessoas tiram dela.

Não há, no código atual, uma tabela dizendo “curtir vale X pontos, repostar vale Y, comentar vale Z e criar post vale W”. Existem vários sistemas, parâmetros controlados em runtime com default 0,0, previsões de probabilidade e grafos de relação. E a pergunta que realmente importa — interagir nos posts dos outros ajuda os meus posts? — tem uma resposta mais interessante e mais desconfortável do que um bônus de karma.

A tese deste artigo: o X não soma pontos por ação recebida. Ele prevê o que você faria com cada post candidato e, ao mesmo tempo, usa as ações que você faz para atualizar grafos, embeddings e features. Like, reply e repost entram nesses dois mundos de jeitos diferentes. Os números de 2023 comprovam uma intenção histórica. Eles não comprovam o peso live de 2026.

1 O que este artigo prova e o que ele não pode provar

O próprio README do repositório diz que o sistema de recomendações é um conjunto de serviços e jobs que alimentam várias superfícies — For You, Search, Explore, Notifications — e que o código aberto representa componentes compartilhados. A superfície principal documentada aqui é o For You. Notifications tem um stack paralelo no pushservice. Search e Explore aparecem só de relance.

Há um segundo repositório, o xai-org/x-algorithm, descrito como uma virada para um transformer no estilo Grok. Eu já escrevi sobre essa camada em outro artigo. Este texto é outra investigação: o código histórico e ainda atualizado de twitter/the-algorithm, cruzado com os pesos publicados em the-algorithm-ml.

O Heavy Ranker de 2023 avisa, no próprio README, que pode haver pequenas diferenças em relação à produção e que os dados reais de treino não foram liberados. Portanto, o GitHub permite provar arquitetura, fórmulas, defaults públicos e a existência de mecanismos. Não permite reconstruir 100% do algoritmo live do X em agosto de 2026 nem os pesos privados de runtime.

1.1 Como a leitura foi feita

Clonei os dois repositórios em uma pasta temporária, li os READMEs de cada serviço e segui os caminhos de código que respondem à pergunta de peso: Home Mixer → recuperação de candidatos → User Signal Service → UTEG / Real Graph / SimClusters → modelos de ranking → Phoenix / Heavy Ranker → rescoring e diversidade de autor. Também comparei o scorer atual com a tabela de 5 de abril de 2023.

Commits usados nesta leitura:

• twitter/the-algorithm: c54bec0, 3 de setembro de 2025, mensagem update for-you recommendations code
• twitter/the-algorithm-ml: b852108, 5 de abril de 2023, atualização da explicação dos pesos do Heavy Ranker

1.2 A fronteira entre evidência e inferência

Quando eu escrever “o código faz X”, haverá arquivo, símbolo e, quando existir, default público. Quando eu escrever uma ordem prática do tipo “70% conteúdo próprio”, isso é inferência estratégica a partir da arquitetura — não um parâmetro do X. Misturar as duas coisas é exatamente o erro que este artigo tenta desfazer.

2 A arquitetura real: vários sistemas, um feed

O README principal descreve o For You como um encadeamento. Cerca de 50% dos candidatos vêm do índice de busca in-network (Earlybird). O restante chega de fora da rede via Tweet Mixer, UTEG e Follow Recommendations Service. Depois entram Light Ranker, Heavy Ranker, Home Mixer, filtros de visibilidade e o Timeline Ranker legado.

Essa tabela já destrói a metáfora do placar. Um like pode fortalecer uma aresta no UTEG, virar label no TwHIN, atualizar o embedding SimClusters do post curtido e ainda ser uma das cabeças que o Phoenix tenta prever para outro usuário. São papéis diferentes. Nenhum deles é “+0,5 no seu próximo tweet”.

3 Home Mixer: o funil do For You

O Home Mixer é o serviço que monta For You, Following e Lists. Foi construído sobre o Product Mixer. O README do próprio serviço descreve o For You em estágios, não como um único score:

1. Geração de candidatos — Earlybird, User Tweet Entity Graph, Cr Mixer, Follow Recommendations Service
2. Hidratação de features — “fetch the ~6000 features needed for ranking”
3. Scoring e ranking com modelo de ML
4. Filtros e heurísticas — diversidade de autor, equilíbrio in-network versus out-of-network, fadiga de feedback, deduplicação, visibilidade
5. Mistura com ads, who-to-follow e prompts
6. Módulos de conversa para replies, contexto social, tweets editados, paginação

3.1 Recuperação, hidratação, score, heurísticas e mistura

O pipeline concreto do For You, em home-mixer/README.md, encadeia ForYouProductPipelineConfig → ForYouScoredTweetsMixerPipelineConfig → ScoredTweetsRecommendationPipelineConfig. Os candidatos vêm de quatro fontes nomeadas:

• ScoredTweetsInNetworkCandidatePipelineConfig — contas que você segue
• ScoredTweetsTweetMixerCandidatePipelineConfig — coordenação out-of-network
• ScoredTweetsUtegCandidatePipelineConfig — travessia do grafo usuário↔post
• ScoredTweetsFrsCandidatePipelineConfig — autores que o FRS acha que você pode seguir

Se o pipeline de scored tweets falha, existe um backup cronológico de conversas. Ads e who-to-follow entram depois, na mistura. Following e Lists são outra lógica: ordem reversa no tempo, sem esse ranking pesado.

4 Recuperação de candidatos: de cerca de 1 bilhão para alguns milhares

O arquivo RETREIVAL_SIGNALS.md — o nome oficial tem um typo, “RETREIVAL” — descreve a primeira triagem. O objetivo é reduzir “approximately 1 billion” itens para “just a few thousand”. O insumo principal é comportamento. Sem essa etapa, o Heavy Ranker e o Phoenix sequer vêem o post.

Isso muda a pergunta prática. Um post bem escrito que ninguém do seu grafo toca pode morrer na recuperação. Um post mediano que pessoas relacionadas curtem, respondem ou repostam pode entrar na disputa de milhares de outras timelines via UTEG ou SimClusters.

4.1 Os sinais oficiais de like, reply, quote e retweet

A tabela oficial lista, entre outros, Tweet Favorite, Retweet, Quote Tweet e Tweet Reply, e mostra em quais sistemas cada um vira feature, label ou os dois:

Essa é uma das provas mais fortes do repositório de que interagir com outras pessoas muda a representação que o sistema tem de você. Curtir é o sinal mais transversal. Reply não entra como label no TwHIN nem no Light Ranking, mas entra como feature em USS, TwHIN, UTEG, FRS e Light Ranking. Quote e retweet andam quase juntos.

Também existem sinais que a conversa popular ignora e o código trata com o mesmo respeito: Tweet Click, Video Watch, Bookmark, Share, Notification Open, Mute, Block, Report e “Don’t like”. O ranking atual tenta prever vários deles. O grafo consome os explícitos.

5 As cerca de 6.000 features e o que elas realmente medem

O número “~6000” não é lenda de thread. Está no README do Home Mixer. O FEATURES.md do Heavy Ranker, com 2.267 linhas, explica de onde vem essa explosão: agregados cartesianos. Para cada grupo — autor, usuário, par usuário-autor — o sistema cruza escopo de engajamento, feature agregada e janela de tempo.

Um exemplo oficial é user_aggregate_v2.pair.recap.engagement.is_favorited.engagement_features.in_network.replies.count.50.days.count: para cada usuário, sobre tweets que ele favoritou, quantas replies in-network ele enviou nos últimos 50 dias. Outro grupo, author_aggregate, rastreia quantos tweets de um autor foram favoritados, retweetados, clicados, recusados ou “dwelled” em janelas de 30 minutos e 50 dias.

Isso importa por um motivo concreto. O modelo não olha “este post tem 40 likes”. Ele olha o histórico cruzado entre você e aquele autor, entre você e aquele tipo de engajamento, entre aquele autor e o restante da rede. O arquivo também lista contagens ponderadas do Earlybird: weighted_fav_count, weighted_reply_count, weighted_retweet_count, weighted_quote_count.

O diretório de prediction features avisa que nem todas as features definidas entram no modelo; muitas são experimentais ou depreciadas. Mesmo assim, a filosofia é clara: o ranking é um vetor enorme de comportamento, não um placar de três botões.

6 Dois rankers no mesmo repositório

O código atual não aposentou o Heavy Ranker para colocar o Phoenix no lugar. Os dois convivem, com Feature Switches escolhendo qual score sobe para a heurística final.

6.1 Heavy Ranker / Recap

O Heavy Ranker, documentado em the-algorithm-ml/projects/home/recap/README.md, é uma MaskNet paralela que recebe features do tweet e do usuário e devolve números entre 0 e 1. Cada saída é a probabilidade de um tipo de engajamento. A lista de 2023 inclui favorite, retweet, reply, good profile click, video playback 50, reply engaged by author, good click, good click v2, negative feedback e report.

No Home Mixer atual, o arquivo product/scored_tweets/scorer/PredictedScoreFeature.scala ainda enumera essas cabeças clássicas, inclusive PredictedReplyEngagedByAuthorScoreFeature, PredictedReportedScoreFeature, PredictedVideoPlayback50ScoreFeature e feedbacks negativos fraco e forte. Um segundo arquivo, model/PredictedScoreFeature.scala, acrescenta dwell, bookmark, share, video quality view, watch time e reply engaged by author.

6.2 Phoenix

O Phoenix é a camada mais nova dentro deste mesmo repositório. PhoenixPredictedScoreFeature.scala lista as cabeças usadas no reranking:

• Favorite
• Reply
• Retweet
• Clique com engajamento
• Clique com dwell
• Clique bom no perfil
• Video quality view
• Share
• Dwell
• Abrir link
• Screenshot
• Bookmark
• Feedback negativo (not interested, block, mute, report)

Dwell e video quality view são mutuamente exclusivos no Phoenix: se o post tem vídeo com pelo menos 10 segundos, vale VQV; senão, vale dwell. Screenshot, no código atual, reutiliza o peso de OpenLinkParam — um detalhe que parece placeholder, não uma decisão de produto documentada.

O HeuristicScorer escolhe entre PhoenixScoreFeature e ScoreFeature conforme EnablePhoenixScorerParam e EnablePhoenixScoreParam. Os dois modelos podem coexistir; a configuração live decide qual nota entra nas heurísticas.

7 A fórmula: probabilidade vezes peso, não pontos por ação

O scorer não espera a ação acontecer para creditar pontos. Ele prevê a probabilidade de cada ação e multiplica pelo peso configurado para aquele viewer, naquela request.

No NaviModelScorer, o trecho é literal:

val weight = query.params(predictedScoreFeature.modelWeightParam)
val weightedScore = predictedScoreOpt.getOrElse(0.0) * weight

No Phoenix, PhoenixModelRerankingScorer faz o mesmo e depois chama aggregateWeightedScores. A combinação positiva é:

combinedScore + score * weight

Conceitualmente:

score do post para este usuário ≈ Σ P(ação_i) × peso_i

Há mais dois detalhes que a tabela viral omite. Primeiro, pesos negativos não entram como uma simples subtração: o agregador pode filtrar cabeças negativas acima de um limiar, normalizar pelo máximo da cabeça no lote e, se a soma final ficar negativa, remapear o valor para um intervalo pequeno e positivo. Segundo, existe um Epsilon de 0,001 somado ao score positivo — um empate técnico, não um bônus de conteúdo.

Por isso a frase “recebeu uma reply, ganhou 13 pontos” está errada em dois níveis. O peso 13,5, quando existiu, multiplicava a probabilidade prevista de alguém responder, não a reply real. E essa probabilidade é específica do par viewer–tweet: o mesmo post pode ter P(reply) = 0,03 para Ana e 0,003 para Carlos.

8 Os pesos que o Twitter publicou em 5 de abril de 2023

O único lugar em que o Twitter escreveu números explícitos de produção — com data — é o README do Heavy Ranker. A frase é direta: “the current weighting of probabilities (April 5, 2023) is as follows”.

Olhando só os coeficientes brutos daquele dia: reply = 27× like, retweet = 2× like, reply com o autor voltando = 150× like. O próprio Twitter, no mesmo arquivo, avisa a pegadinha: as probabilidades-base são diferentes e os pesos foram calibrados para que as contribuições médias fossem aproximadamente semelhantes. Depois, os pesos foram ajustados periodicamente para métricas da plataforma.

13,5 numa reply não significa que uma reply real vale 27 curtidas reais. Uma reply é bem menos provável do que um like, então P(reply) tende a ser menor. O que a tabela prova é outra coisa: o modelo foi deliberadamente calibrado para valorizar ações de maior intenção, e replies tinham coeficiente muito maior que likes e retweets.

Os sinais negativos daquele modelo são brutais no papel. Report a −369 e negative feedback a −74 existem para puxar para baixo conteúdo que o sistema acredita que o viewer vai rejeitar. Um post “viral” que também dispara mute e “show less” pode perder no score combinado.

9 O que o código de 2025 realmente expõe: default 0,0

Aqui está a descoberta que invalida a maior parte das threads de 2026. Em HomeGlobalParams.scala, os pesos atuais são Feature Switches:

object FavParam extends FSBoundedParam[Double](
  name = "home_mixer_model_weight_fav",
  default = 0.0, min = -10000.0, max = 10000.0)

object RetweetParam extends FSBoundedParam[Double](
  name = "home_mixer_model_weight_retweet",
  default = 0.0, min = -10000.0, max = 10000.0)

object ReplyParam extends FSBoundedParam[Double](
  name = "home_mixer_model_weight_reply",
  default = 0.0, min = -10000.0, max = 10000.0)

O mesmo vale para good profile click, video quality view, reply engaged by author, good click, dwell, bookmark, share, open link, screenshot, negative feedback e report. Default público = 0,0. Intervalo amplo o suficiente para a configuração live colocar 13,5, 75, −369 ou qualquer outro número sem commitar o valor no GitHub.

Zero no default não significa que like, reply e retweet valem zero em produção. Significa que o scorer busca query.params(...) e que essa configuração não está no repositório público. Quem afirma “em 2026 uma reply vale 13,5” está usando um snapshot de 2023 como se fosse o arquivo live.

O README de 2023 já apontava para ScoredTweetsParam.scala como o arquivo de pesos. Esse arquivo hoje guarda scale factors e diversidade, não a tabela 0,5 / 1,0 / 13,5. Os pesos migraram para HomeGlobalParams.Scoring.ModelWeights, com defaults zerados. Isso é evidência de que a empresa trata esses coeficientes como knobs operacionais, não como constantes do código.

10 Favorite, Reply e Retweet no Phoenix atual

As três ações da sua pergunta continuam explícitas no Phoenix:

object PhoenixPredictedFavoriteScoreFeature {
  featureName = "fav"
  actions = Seq(SERVER_TWEET_FAV)
  modelWeightParam = ModelWeights.FavParam
}

object PhoenixPredictedReplyScoreFeature {
  featureName = "reply"
  actions = Seq(SERVER_TWEET_REPLY)
  modelWeightParam = ModelWeights.ReplyParam
}

object PhoenixPredictedRetweetScoreFeature {
  featureName = "retweet"
  actions = Seq(SERVER_TWEET_QUOTE, SERVER_TWEET_RETWEET)
  modelWeightParam = ModelWeights.RetweetParam
}

O Phoenix não prevê “o autor publicou um post”. Ele prevê o que o viewer fará com o post: favoritar, responder, repostar/quotar, clicar, ficar, compartilhar, salvar, rejeitar. Publicar cria o candidato. Engajar é o que o modelo tenta antecipar.

10.1 Quote e Retweet compartilham a mesma cabeça

No Phoenix, quote não tem cabeça própria. SERVER_TWEET_QUOTE e SERVER_TWEET_RETWEET alimentam PhoenixPredictedRetweetScoreFeature. Na recuperação, Quote Tweet e Retweet aparecem como linhas separadas na tabela de sinais, ambas muito presentes em USS, TwHIN, UTEG, FRS e Light Ranking. Ou seja: quote é tratado como irmão do retweet no score Phoenix e como sinal explícito próprio nos grafos.

10.2 O famoso peso 75 ainda existe — mas não no Phoenix

ChatGPT e várias threads tratam o 75 como se tivesse sumido. O código é mais preciso. PhoenixPredictedScoreFeatures não inclui reply engaged by author. Já o Heavy Ranker atual ainda tem:

object PredictedReplyEngagedByAuthorScoreFeature {
  statName = "reply_engaged_by_author"
  modelWeightParam = ModelWeights.ReplyEngagedByAuthorParam
}

E home_mixer_model_weight_reply_engaged_by_author continua declarado, default 0,0. Conclusão honesta: o 75 é histórico do Recap de 2023; a cabeça ainda existe no ranker clássico; o Phoenix publicado não a enumera. Tratar 75 como peso atual do For You é especulação.

11 Depois do modelo: o HeuristicScorer multiplica tudo de novo

Mesmo depois da soma ponderada, o score ainda não é o da timeline. O HeuristicScorer multiplica a nota por uma cadeia de fatores. A lista pública inclui:

• RescoreOutOfNetwork
• RescoreReplies
• RescoreMTLNormalization
• Diversidade listwise de autor, mídia, cluster de imagem e fonte de candidato
• ImpressedAuthorDecayRescoringProvider
• GrokSlopScoreRescorer
• RescoreFeedbackFatigue
• Rescorers de Control AI
• RescoreLiveContent — o próprio comentário diz “Disabled in production”

O código faz o produto de todos os fatores e só então grava ScoreFeature:

val scaleFactor = rescorers.map(_(query, candidate)).product
val updatedScore = scoreOpt.map { score =>
  if (score < Epsilon && noNegHeuristic) score else score * scaleFactor
}

Um post pode “ganhar” no modelo e perder na heurística. Isso é tão importante quanto a tabela de 2023.

11.1 RescoreReplies: reply como candidato recebe 0,75

Receber uma reply no seu post e publicar uma reply em outro post são fenômenos diferentes. O código trata o segundo caso assim:

object RescoreReplies extends RescoringFactorProvider {
  def selector(...) =
    candidate.features.getOrElse(InReplyToTweetIdFeature, None).isDefined
  def factor(...) = query.params(ReplyScaleFactorParam)
}

ReplyScaleFactorParam tem default público 0,75. Se o candidato é uma reply — tem InReplyToTweetIdFeature — o score é multiplicado por 0,75, salvo configuração live diferente. Isso destrói a leitura “se replies têm peso alto, publique só replies”. O modelo pode valorizar a probabilidade de alguém responder o seu post e, ao mesmo tempo, a heurística pode descontar a sua reply quando ela compete como candidato no feed de outra pessoa.

11.2 Fora da rede também começa em 0,75

RescoreOutOfNetwork aplica OutOfNetworkScaleFactorParam, default 0,75, a qualquer candidato com InNetworkFeature = false. Sair da bolha de quem te segue tem um pedágio explícito no código público — do mesmo tamanho do pedágio da reply. Os parâmetros CreatorInNetworkMultiplierParam e CreatorOutOfNetworkMultiplierParam existem, default 1,0, mas no snapshot que eu li eles só estão registrados no config; não achei aplicação no scorer público. Não vou fingir que são um boost de creator ativo.

11.3 Diversidade de autor: postar 10 vezes não vale 10 feeds

Vários posts seus na mesma seleção sofrem desconto exponencial por posição. A fórmula publicada em AuthorDiversityDiscountProvider e AuthorBasedListwiseRescoringProvider é:

(1 - floor) * Math.pow(decay, index) + floor

Defaults públicos: decay = 0,5, floor = 0,25. Há variantes para grafo pequeno (≤ 50 follows), in-network e out-of-network, todas com os mesmos defaults. Com esses números:

ImpressedAuthorDecayRescoringProvider vai além: se a pessoa já viu posts seus nesta sessão, o índice efetivo soma essas impressões. O segundo post não compete só com o primeiro candidato; compete com o que já foi servido. O param EnableImpressionBasedAuthorDecay liga esse comportamento.

11.4 Feedback fatigue, Grok slop e Control AI

RescoreFeedbackFatigue desconta autores, likers, followers e retweeters ligados a um “See fewer” recente. Se muita gente pede para ver menos você — ou menos gente que te curte — o multiplicador cai.

GrokSlopScoreRescorer aplica GrokSlopScoreDecayValueParam quando a feature vale 3. O default do decay é 1,0, ou seja, neutro até alguém configurar um valor menor que 1. É evidência de que o stack atual já tem um knob para rebaixar conteúdo classificado como slop pelo Grok. Não é evidência de qual limiar está ligado em produção.

Control AI é o contrário de um algoritmo invisível: o usuário pode pedir mais ou menos de um tema. Defaults públicos: mostrar menos multiplica por 0,05; mostrar mais multiplica por 20, com limiar de similaridade 0,67. Quem usa esses controles está literalmente reescrevendo o score.

12 Onde like, reply e retweet entram de verdade: os grafos

Se o ranking é previsão, a recuperação é memória. É aqui que a sua atividade nos posts dos outros deixa rastros mensuráveis.

12.1 User Signal Service

O USS se descreve como plataforma centralizada de sinais explícitos — favoritar, retweetar, responder — e implícitos — clique, visualização de vídeo, visita a perfil. Esses sinais padronizados alimentam recuperação de candidatos e features de ranking. Unified User Actions é o rio em tempo real por trás: favorites, retweets, replies, bookmark, impression, video view, replicados para Kafka, HDFS e BigQuery.

12.2 UTEG e o “XXX Liked”

O User Tweet Entity Graph mantém em memória as interações das últimas 24 a 48 horas e faz travessias colaborativas. O README dá o exemplo famoso: gerar os tweets out-of-network do tipo “XXX Liked”. A entrada é o grafo ponderado de follows; a saída são os tweets mais pesados segundo quantidade e peso de quem interagiu.

Uma curtida sua, portanto, pode:

1. fortalecer a associação você ↔ aquele post;
2. fazer aquele post entrar como candidato para pessoas relacionadas a você;
3. treinar o seu grafo para as próximas recuperações.

Isso ajuda o conteúdo que você curtiu. Não achei transferência direta de “autoridade” para o seu próximo post original.

O Graph Feature Service responde perguntas do tipo “quantos followings de A favoritaram C” e “o quanto C se parece com usuários que A favoritou”. De novo: a curtida descreve relações, não um saldo na sua conta.

12.3 Real Graph: probabilidade de A interagir com B

O Real Graph não é um score de amizade. É um classificador — gradient boosting — que prevê a probabilidade de um usuário interagir com outro. As arestas são direcionais. As features incluem tweets, follows, favorites e outras métricas. Há agregação diária com soma decaída e um score ML ao lado dessa soma.

Se você responde João com frequência, o sistema pode aprender P(Paulo interage com João). Essa aresta depois participa de recomendações. O Earlybird in-network inclusive consulta RealGraphInNetworkScoresFeature na query. Relação prevista ≠ bônus automático no seu próximo tweet. Mas é o mecanismo mais próximo de “o algoritmo te coloca perto de alguém”.

12.4 SimClusters: cada like atualiza o embedding do post

SimClusters detecta cerca de 145 mil comunidades a partir do grafo de follows e representa usuários e tweets como vetores esparsos nessas comunidades. O detalhe que mais importa para a sua pergunta está no README:

When a tweet is created, its tweet embedding is initialized as an empty vector. Tweet embeddings are updated each time the tweet is favorited. Specifically, the InterestedIn vector of each user who Fav-ed the tweet is added to the tweet vector.

O like, aqui, não pontua o autor. Ele empurra o post para as comunidades de quem curtiu. Posts com likes de pessoas do seu nicho ficam mais fáceis de recuperar para outras pessoas do mesmo nicho. É o mecanismo mais literal de “curtir ajuda aquele conteúdo a viajar”.

TwHIN, no repositório de ML, é o outro embedding: um grafo de conhecimento denso de users e posts, citado no README principal e alimentado por favorite, retweet, quote e reply como feature ou label.

12.5 Tweepcred: reputação por PageRank, não karma de likes dados

Tweepcred calcula influência com PageRank sobre interações — mentions, retweets e o grafo de follows. Depois ajusta quem tem muitos followings e poucos followers. O Light Ranker usa tweepcred como feature estática, ao lado de “é reply?”, “tem link?”, qualidade de texto, e das contagens realtime de likes, replies e retweets do próprio tweet.

Isso é reputação de grafo, não “quanto mais você curte, mais o X entrega o que você publica”. Procurei no repositório inteiro por mecanismos do tipo creator_score += number_of_likes_given ou next_tweet_score += replies_made_today. Não existem.

13 Interagir nos posts dos outros ajuda os meus?

Sim — e não do jeito que o marketing de crescimento descreve.

O que o código prova:

• Suas ações entram no USS e viram feature de recuperação e de ranking.
• Favorite, retweet, quote e reply alimentam UTEG, TwHIN e FRS.
• Real Graph atualiza P(você interage com aquela pessoa).
• Agregados user_author_aggregate guardam o histórico do par você–autor.
• Uma reply sua é, ao mesmo tempo, sinal e novo post candidato, com módulo específico de conversa no Home Mixer.

O que o código não prova:

• Que curtir 50 posts dá bônus de alcance ao seu próximo original.
• Que existe um saldo de karma.
• Que “dar engajamento para receber engajamento” seja uma regra implementada.

O efeito é indireto. Se você responde gente do seu nicho com densidade e qualidade, o sistema passa a ter arestas Paulo → essas contas, e essas contas — se retribuírem — passam a ter arestas de volta. UTEG e Real Graph trabalham melhor quando a relação é mútua e recente. Curtir sozinho ajuda o post curtido a viajar; raramente constrói uma aresta tão informativa quanto uma reply.

Por isso replies genuínas dentro do nicho são tecnicamente mais interessantes do que espalhar likes. Não porque exista um +13,5 no seu perfil. Porque você gera conteúdo novo e, ao mesmo tempo, ensina o grafo quem está relacionado a quem.

14 E criar um post próprio?

Publicar não aparece como model_weight_post_created. O Phoenix atual não tem cabeça “o autor postou = +X”. Publicar coloca uma peça nova no conjunto de candidatos. A partir daí, cada viewer recebe um vetor diferente de probabilidades.

Para Ana, o mesmo post pode ter P(like) = 0,20, P(reply) = 0,03, P(retweet) = 0,02. Para Carlos, tudo muda. Perguntar “quanto vale fazer um post?” não tem a mesma natureza de perguntar “quanto vale alguém dar like no post?”. O primeiro cria o candidato. O segundo é uma ação que o modelo tenta prever.

O Light Ranker ainda usa, no tweet já publicado, as contagens realtime de likes, replies e retweets — e se o tweet é reply, retweet, tem link, tem trend, além de tweepcred e scores de toxicidade. Depois que o post existe, receber engajamento real ajuda a recuperação e o light ranking daquele mesmo post. Não reescreve magicamente o score dos seus posts futuros.

E publicar demais, na mesma seleção, sofre o desconto de diversidade. Dez posts não compram dez vezes a mesma timeline.

15 Afinal, o que tem mais peso?

É preciso separar três perguntas que as threads misturam.

1. Qual engajamento recebido o modelo histórico mais valorizava?

A evidência pública mais concreta, com data, é a do Heavy Ranker em 05/04/2023:

Reply (13,5) > Retweet (1,0) > Like (0,5).

E, naquele modelo, reply que gerava interação posterior do autor tinha sinal ainda maior: 75. Visitar perfil e ficar na conversa pesavam na mesma ordem de grandeza da reply simples. Report e “show less” pesavam negativamente de forma brutal.

2. Qual ação sua, nos posts dos outros, mais altera o sistema?

Pela amplitude de uso nos grafos e pela dualidade reply = sinal + novo conteúdo, a ordem que o código sugere — aqui já misturando evidência e leitura de arquitetura — é:

3. Os números de 2023 ainda valem em 2026?

O repositório atual não permite provar isso. Os knobs existem. Os defaults públicos são 0,0. A configuração de produção não está no GitHub.

16 O que eu faria com essa evidência

Esta seção é inferência. Não é parâmetro do algoritmo.

Se o objetivo é crescer uma conta técnica no X, eu concentraria o esforço em construir arestas e candidatos de alta intenção, não em farmar cliques:

• Cerca de 70% do esforço em originais que provoquem resposta, permanência, visita ao perfil e compartilhamento. O modelo histórico pagava caro por conversa e por perfil. O Phoenix atual ainda prevê exatamente essas cabeças. Sem original, você só alimenta o grafo dos outros.
• Cerca de 20% respondendo gente do mesmo nicho, com informação nova — não “legal!” nem “concordo”. A reply constrói aresta e vira conteúdo. Evitaria transformar a conta numa fábrica de replies: o RescoreReplies existe.
• Cerca de 10% em likes, reposts e quotes para marcar relação e ajudar descoberta. Like não é inútil; é o combustível do SimClusters e do UTEG. Só não é um multiplicador do seu próximo post.

Eu não faria uma estratégia baseada em “quanto mais eu interajo, mais o X me entrega”. O código mostra outra máquina:

suas ações → criam sinais → atualizam relações usuário/conteúdo → alteram candidate retrieval e features → o modelo entende melhor quem está relacionado a quem → cada post candidato é ranqueado individualmente para cada viewer.

A descoberta que mais mudaria o meu uso do X é esta: não pense “preciso dar engajamento para ganhar engajamento”. Pense “preciso fazer o algoritmo construir arestas relevantes entre a minha conta, as pessoas do meu nicho e os conteúdos do meu nicho”.

Há uma razão técnica para priorizar conversa. O histórico público mostra que o sistema valorizava interações de intenção elevada. A arquitetura atual continua tratando Favorite, Reply e Retweet como cabeças separadas. O sistema de sinais continua usando replies na recuperação e nos modelos. E o peso negativo de rejeição, no único snapshot numérico que temos, era grande o suficiente para anular dezenas de likes previstos.

17 O que o GitHub público não permite afirmar

• Os pesos live de like, reply e retweet em agosto de 2026.
• Se o Phoenix de produção usa a lista publicada ou um superset privado.
• Se ReplyScaleFactorParam = 0,75 e os decays de diversidade estão ligados para todos os usuários.
• O comportamento interno do Visibility Filtering — o README admite que parte do código foi removida e está em reconstrução.
• O Light Ranker é legado: o próprio time escreveu que o modelo foi treinado há anos, usa features estranhas e está sendo substituído.
• Search, Explore e Ads têm lógicas que este repositório não entrega por completo.
• O xai-org/x-algorithm pode já ser a camada dominante do For You para parte dos usuários; este artigo não reconstrói esse runtime.

O que o GitHub permite afirmar, com arquivo e linha, é a arquitetura, a fórmula, a coexistência dos dois rankers, a lista de cabeças, os defaults, as heurísticas, a tabela de sinais e a ausência de um sistema de karma.

18 Conclusão

O algoritmo do X não é uma tabela de pontos. É um funil: recuperar, hidratar cerca de 6.000 features, prever dezenas de ações, somar pesos que moram fora do GitHub e só então aplicar diversidade, pedágio de reply, pedágio out-of-network, fadiga e filtros.

Em 5 de abril de 2023, o Twitter publicou a única tabela numérica oficial e ela privilegiava reply sobre retweet sobre like — com um prêmio enorme para reply que o autor retribuía e um castigo enorme para denúncia. Em 3 de setembro de 2025, o código público ainda enumera Favorite, Reply e Retweet, ainda tem o knob do reply engaged by author no ranker clássico, e ainda busca cada peso em Feature Switch com default 0,0.

Curtir os outros ajuda o conteúdo curtido a viajar e treina o seu grafo. Responder gente relevante constrói aresta e cria um post novo. Publicar original é o que coloca a sua ideia no conjunto de candidatos. Nenhuma dessas ações é um depósito na conta de alcance.

Se uma única frase tiver de sobrar, que seja esta: o X não te paga por distribuir likes. Ele tenta aprender com quem você se relaciona e o que cada viewer faria com o próximo post que entrar na disputa.

19 Referências

• X / Twitter — the-algorithm. Commit lido: c54bec0 (3 set. 2025).
• X / Twitter — the-algorithm-ml. Commit lido: b852108 (5 abr. 2023).
• X Engineering — Twitter's Recommendation Algorithm.
• X — A new era of transparency for Twitter.
• home-mixer/README.md — funil do For You e as ~6.000 features.
• RETREIVAL_SIGNALS.md — sinais de favorite, reply, quote e retweet na recuperação.
• home-mixer/.../model/PhoenixPredictedScoreFeature.scala — cabeças atuais do Phoenix.
• home-mixer/.../model/PredictedScoreFeature.scala e product/scored_tweets/scorer/PredictedScoreFeature.scala — cabeças do Heavy Ranker, inclusive reply engaged by author.
• home-mixer/.../param/HomeGlobalParams.scala — home_mixer_model_weight_* com default 0,0.
• home-mixer/.../scorer/NaviModelScorer.scala e util/RerankerUtil.scala — score * weight.
• home-mixer/.../scorer/HeuristicScorer.scala, RescoringFactorProvider.scala, AuthorBasedListwiseRescoringProvider.scala, ImpressedAuthorDecayRescoringProvider.scala — replies, out-of-network e diversidade.
• the-algorithm-ml/projects/home/recap/README.md — pesos de 5 de abril de 2023 e o aviso de calibração.
• the-algorithm-ml/projects/home/recap/FEATURES.md — agregados e contagens ponderadas.
• user-signal-service/README.md, unified_user_actions/README.md, src/scala/com/twitter/recos/user_tweet_entity_graph/README.md, src/scala/com/twitter/interaction_graph/README.md, src/scala/com/twitter/simclusters_v2/README.md, src/scala/com/twitter/graph/batch/job/tweepcred/README, graph-feature-service/README.md.
• Earlybird Light Ranker — src/python/twitter/deepbird/projects/timelines/scripts/models/earlybird/README.md.
• SimClusters — El-Kishky et al., KDD 2020, Community-based Representations for Heterogeneous Recommendations.
• TwHIN — Embedding the Twitter Heterogeneous Information Network.
• MaskNet — MaskNet: Introducing Feature-wise Multiplication to CTR Ranking Models.
• GraphJet — Sharma, A. et al. GraphJet: Real-Time Content Recommendations at Twitter. VLDB, 2016.
• xAI — x-algorithm, camada mais nova do For You, fora do escopo desta leitura de código.