Sistema de recomendação do Instagram: como funciona na prática

Sistema de recomendação do Instagram: como funciona na prática

Segundo o Olhardigital.com.br, o Instagram registrou crescimento de dois dígitos no tempo de tela dos usuários no segundo trimestre de 2026, e a Meta atribui parte disso às melhorias nos sistemas de recomendação do feed e do Reels. Mark Zuckerberg foi direto: a IA está tornando as sugestões mais personalizadas, exibindo conteúdo mais recente e dando mais controle sobre o que aparece. Isso me interessa não como “mais um app viciante”, mas como um estudo de caso real de um sistema de recomendação operando em escala bilionária — exatamente o tipo de arquitetura que a gente discute em projetos de machine learning, search e personalização.

Por que a IA do Instagram “funciona” tão bem (e o que devs podem aprender com isso)

Quando Zuckerberg diz que “as recomendações estão mais personalizadas”, ele está falando de três pilares técnicos que rodam em paralelo: modelos de duas torres (two-tower models), embeddings contextuais e sinais comportamentais de altíssima granularidade. Na minha experiência construindo sistemas de recomendação, o que separa um sistema mediano de um excelente não é o algoritmo em si — é a qualidade e a latência dos sinais que você coleta.

O Reels, por exemplo, usa uma arquitetura mais avançada combinada com histórico de interação. Isso é, na prática, um sistema de retrieval + ranking com duas etapas: primeiro, um modelo leve seleciona centenas de candidatos em milissegundos; depois, um modelo mais pesado reordena esses candidatos com base em sinais mais profundos. É exatamente o mesmo padrão que usamos em busca semântica com FAISS ou Pinecone.

O modelo de duas torres: a base de tudo

Esse é o coração do sistema. Você tem uma torre que codifica o usuário (features demográficas, histórico de interações, sessão atual) e outra torre que codifica o conteúdo (texto, metadados, embeddings visuais). O produto interno entre os dois vetores gera um score de relevância. A sacada é que a torre de conteúdo pode ser pré-computada offline, enquanto a torre de usuário roda em tempo real.

Para entender como isso funciona na prática, considere um exemplo simplificado em Python com PyTorch:

import torch
import torch.nn as nn

class TwoTowerModel(nn.Module):
    def __init__(self, user_feat_dim, item_feat_dim, embedding_dim=64):
        super().__init__()
        self.user_tower = nn.Sequential(
            nn.Linear(user_feat_dim, 128),
            nn.ReLU(),
            nn.Linear(128, embedding_dim),
            nn.LayerNorm(embedding_dim)
        )
        self.item_tower = nn.Sequential(
            nn.Linear(item_feat_dim, 128),
            nn.ReLU(),
            nn.Linear(128, embedding_dim),
            nn.LayerNorm(embedding_dim)
        )

    def forward(self, user_features, item_features):
        user_emb = self.user_tower(user_features)
        item_emb = self.item_tower(item_features)
        # Similaridade cosseno
        return torch.nn.functional.cosine_similarity(user_emb, item_emb)

# Exemplo de uso
model = TwoTowerModel(user_feat_dim=50, item_feat_dim=100)
user = torch.randn(1, 50)  # features do usuário
item = torch.randn(1, 100)  # features do post
score = model(user, item)
print(f"Score de relevância: {score.item():.4f}")

Esse código é simplificado, mas captura a essência. Em produção, a Meta substitui essas torres lineares por redes mais profundas, com atenção cruzada entre features e embeddings multimodais (texto, imagem, vídeo).

LLMs na curadoria de conteúdo: o detalhe que pouca gente comenta

A Meta revelou que usa modelos de linguagem de grande escala (LLMs) para analisar publicações públicas, avaliar temas e características dos posts. Isso é um divisor de águas. Antigamente, sistemas de recomendação dependiam quase exclusivamente de sinais comportamentais — cliques, tempo de tela, curtidas. Agora, com LLMs, é possível entender o conteúdo semântico de um post sem depender do histórico de quem interagiu com ele.

Isso resolve o clássico problema do “cold start”: quando um post é novo e ainda não tem engajamento, o sistema precisa de outra forma de avaliá-lo. Com embeddings gerados por LLMs, você pode inferir relevância apenas pelo conteúdo textual, classificar em tópicos e cruzar com o perfil de interesse do usuário.

Na Prática: como você implementaria isso num projeto real

Imagine que você está construindo um feed personalizado para um produto seu — um agregador de notícias para devs, por exemplo. Aqui vai um passo a passo realista:

  1. Colete sinais comportamentais: tempo de leitura, scroll depth, cliques, shares. Use um event tracker (Segment, PostHog, ou um simples Kafka).
  2. Gere embeddings de conteúdo: passe cada post por um LLM (ou modelo menor tipo BERT/SBERT) para gerar um vetor semântico. Para isso, você pode usar a API de embeddings da OpenAI ou rodar Sentence Transformers localmente.
  3. Indexe para busca por similaridade: armazene os embeddings num vector database (FAISS, Pinecone, Weaviate, Qdrant).
  4. Monte o perfil dinâmico do usuário: média ponderada dos embeddings dos posts com os quais ele interagiu, com decay temporal (interações recentes pesam mais).
  5. Faça retrieval + ranking: busque os top-K posts similares ao perfil e reordene com um modelo leve (gradient boosted trees, por exemplo) usando sinais contextuais.

Esse pipeline é exatamente o que o Instagram faz, só que em escala de bilhões. A diferença é que eles rodam tudo em hardware customizado e com otimizações de inferência agressivas (quantização, batching, caching de embeddings).

Os erros clássicos que devs cometem em sistemas de recomendação

Depois de ver dezenas de implementações em produção, posso listar os deslizes mais frequentes:

  • Confundir precisão com retenção: um modelo com ótima AUC pode gerar feed genérico e entediar o usuário. Otimize para engajamento de longo prazo, não para cliques imediatos.
  • Ignorar o feedback loop: se você recomenda só o que o usuário já viu, ele fica preso numa bolha. O Instagram mitiga isso injetando diversidade explícita (exploration).
  • Não tratar drift de dados: preferências mudam, trends mudam. Re-treine o modelo com frequência e monitore distribuição de features.
  • Esquecer do cold start do usuário: no primeiro acesso, você não tem histórico. Use sinais contextuais (localização, horário, dispositivo) e conteúdo popular como fallback.
  • Acumular features sem ablation: é tentador jogar 200 features no modelo. Faça ablation studies sérios. Features ruidosas degradam performance mais do que ajudam.

O detalhe da “freshness” que a Meta está investindo

Zuckerberg mencionou que o sistema passou a recomendar conteúdo mais recente com maior precisão. Isso é crítico porque redes neurais tradicionais tendem a popularizar conteúdos antigos que já acumularam engajamento — um viés perigoso. A solução envolve:

  • Decay temporal no ranking: penalizar posts muito antigos, mesmo que tenham alta probabilidade de clique.
  • Boost explícito para novos conteúdos: dar um “bônus” inicial para posts com menos de N horas, parecido com o que o Twitter faz com o tab “For You”.
  • Modelos de tendência: detectar topics em ascensão e dar peso extra a eles no retrieval.

Comparação com alternativas open source

Se você quiser montar algo parecido sem reinventar a roda, vale conhecer:

  • RecBole: framework acadêmico com dezenas de modelos de recomendação prontos.
  • TensorFlow Recommenders (TFRS): do Google, com suporte a retrieval e ranking.
  • Implicit: biblioteca Python focada em collaborative filtering com ALS, leve e eficiente.
  • Gorse: sistema de recomendação open source em Go, com dashboard e API pronta.

Nenhum deles vai te dar a performance do Instagram, mas para produtos de médio porte (até alguns milhões de usuários), são alternativas sólidas e bem documentadas.

FAQ — Perguntas que devs realmente fazem

1. Qual a diferença entre collaborative filtering e modelos de duas torres?

Collaborative filtering clássico (matrix factorization, ALS) trabalha com a matriz usuário-item diretamente. Modelos de duas torres aprendem representações separadas para usuário e item, permitindo usar features adicionais e generalizar melhor para itens novos (graças à torre de conteúdo).

2. É viável rodar um sistema de recomendação em tempo real sem GPU?

Para retrieval, sim — com FAISS rodando em CPU e vetores quantizados (int8), você consegue sub-10ms para milhões de itens. O gargalo é o ranking final, onde modelos mais pesados podem exigir GPU ou otimização agressiva (ONNX, TensorRT).

3. Como evitar bolha de filtro?

Injete diversidade explícita no retrieval (não retorne os top-K mais similares, mas garanta cobertura de clusters). Use bandit algorithms (epsilon-greedy, UCB) para balancear exploration e exploitation. Monitore a distribuição de topics recomendados por usuário.

4. Vale a pena usar LLMs para gerar embeddings de recomendação?

Depende do caso. Para texto puro (notícias, posts), sim — embeddings de LLMs capturam semântica que bag-of-words não alcança. Para sinais puramente comportamentais, modelos menores (como embeddings aprendidos directly na two-tower) são mais eficientes.

5. Como a Meta mede o sucesso dessas melhorias?

Combina métricas offline (AUC, NDCG, recall@K) com online (watch time, retention, DAU). A+B tests rigorosos com holdouts de longo prazo são padrão. Sem isso, você não sabe se a melhoria no modelo é só overfitting em métrica.

Vale a pena estudar o Instagram a fundo?

Na minha opinião, sim. Mesmo que você nunca vá trabalhar na Meta, entender como eles operam te dá um norte sobre o estado da arte em sistemas de recomendação. Não é sobre copiar — é sobre entender os trade-offs que empresas desse tamanho fazem entre latência, custo, precisão e diversidade. Esses trade-offs aparecem em qualquer projeto de personalização, do feed de um marketplace ao ranking de resultados de busca interno.

Cuidado com a armadilha de achar que basta jogar um modelo de deep learning em cima dos dados e o feed vai melhorar. Na prática, 80% do ganho vem da qualidade dos sinais e da engenharia de features — não da arquitetura do modelo. O Instagram investiu pesado em coleta de dados e em pipelines de feature store antes de brilhar nos modelos. Esse é o caminho.

Se você quer se aprofundar, recomendo começar pelo paper clássico do YouTube sobre deep neural networks for YouTube recommendations (de 2016, ainda relevante) e migrar depois para os papers mais recentes sobre two-tower models e sequential recommenders. E, óbvio, ler com atenção os releases notes e posts técnicos da Meta quando eles aparecem.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.

Y

Yuri Sousa

Front-End Developer / Designer

Desenvolvedor apaixonado por criar experiências digitais acessíveis e visualmente perfeitas. Escrevo sobre desenvolvimento web, design e tecnologia.