Aprenda como os modelos causais de Judea Pearl ajudam equipes a explicar o comportamento da IA, depurar falhas e tomar decisões de produto mais claras além das correlações.
Uma equipe nota algo “óbvio” no painel: usuários que recebem mais notificações voltam com mais frequência. Então aumentam o volume de notificações. Uma semana depois, a retenção cai e as reclamações por churn aumentam. O que aconteceu?
O padrão original era real — mas enganoso. Os usuários mais engajados naturalmente disparam mais notificações (porque usam o produto mais) e também naturalmente retornam mais. As notificações não causaram a retenção; o engajamento causou ambos. A equipe agiu sobre correlação e acabou criando uma experiência pior.
Pensamento causal é o hábito de perguntar: o que causa o quê, e como sabemos? Em vez de parar em “essas duas coisas se movem juntas”, você tenta separar:
Não se trata de ser cético com dados — é ser específico sobre a pergunta. “Notificações correlacionam com retenção?” é diferente de “Enviar mais notificações aumentará a retenção?” A segunda é uma pergunta causal.
Este post foca em três áreas práticas onde a detecção de padrões costuma falhar:
Isto não é um tour pesado em matemática de inferência causal. Você não precisará aprender notação de do-calculus para tirar valor daqui. O objetivo é um conjunto de modelos mentais e um fluxo de trabalho que sua equipe pode usar para:
Se você já lançou uma mudança que “parecia boa nos dados” mas não funcionou na realidade, o pensamento causal é o elo que faltava.
Judea Pearl é um cientista da computação e filósofo da ciência cujo trabalho redesenhou como muitas equipes pensam sobre dados, IA e tomada de decisão. Antes da revolução causal dele, grande parte de “aprender com dados” em computação focava em associações estatísticas: encontre padrões, ajuste modelos, preveja o que acontece a seguir. Esse approach é poderoso — mas frequentemente quebra no momento em que você faz uma pergunta de produto ou engenharia que contém a palavra porque.
A mudança central de Pearl foi tratar a causalidade como um conceito de primeira classe, não como uma intuição vaga por cima das correlações. Em vez de apenas perguntar “quando X está alto, Y também está alto?”, o pensamento causal pergunta “se mudarmos X, Y mudará?” Essa diferença parece pequena, mas separa previsão de tomada de decisão.
Associação responde “o que tende a co‑ocorrer”. Causalidade busca responder “o que aconteceria se intervíssemos”. Isso importa em computação porque muitas decisões reais são intervenções: lançar uma feature, mudar rankings, adicionar um guardrail, alterar um conjunto de treino ou ajustar uma política.
Pearl tornou a causalidade mais prática ao enquadrá‑la como uma escolha de modelagem mais suposições explícitas. Você não “descobre” causalidade automaticamente dos dados em geral; você propõe uma história causal (frequentemente baseada em conhecimento de domínio) e então usa dados para testar, estimar e refinar essa história.
Essas ferramentas deram às equipes uma linguagem compartilhada para passar da detecção de padrões a responder perguntas causais com clareza e disciplina.
Correlação significa que duas coisas se movem juntas: quando uma sobe, a outra tende a subir (ou cair). É extremamente útil — especialmente em times orientados a dados — porque ajuda com previsão e detecção.
Se as vendas de sorvete disparam quando a temperatura sobe, um sinal correlacionado (temperatura) pode melhorar o forecast. Em trabalho de produto e IA, correlações alimentam modelos de ranqueamento (“mostrar mais do que usuários similares clicaram”), detecção de anomalias (“essa métrica normalmente acompanha aquela”) e diagnósticos rápidos (“erros sobem quando a latência sobe”).
O problema começa quando tratamos correlação como resposta a uma pergunta diferente: o que acontece se mudarmos algo de propósito? Isso é causalidade.
Uma relação correlacionada pode ser movida por um terceiro fator que afeta ambas as variáveis. Mudar X não necessariamente muda Y — porque X pode não ser a razão pela qual Y se moveu em primeiro lugar.
Imagine que você plota gasto semanal em marketing contra vendas semanais e vê forte correlação positiva. É tentador concluir “mais gasto causa mais vendas”.
Mas suponha que ambos aumentem durante feriados. A sazonalidade (um confusor) impulsiona maior demanda e também motiva orçamentos maiores. Se você aumenta gasto em uma semana sem feriados, as vendas podem não subir muito — porque a demanda subjacente não está lá.
Você está em território causal quando se pega perguntando:
Quando o verbo é mudar, lançar, remover ou reduzir, correlação é uma pista inicial — não a regra de decisão.
Um diagrama causal — frequentemente desenhado como um DAG (Grafo Acíclico Dirigido) — é uma maneira simples de tornar visíveis as suposições de uma equipe. Em vez de discutir em termos vagos (“provavelmente é o modelo” ou “talvez a UI”), você coloca a história no papel.
O objetivo não é a verdade perfeita; é um rascunho compartilhado de “como achamos que o sistema funciona” que todos podem criticar.
Suponha que você esteja avaliando se um novo tutorial de onboarding (T) aumenta ativação (A).
Um reflexo comum em analytics é “controlar todas as variáveis disponíveis”. Em termos de DAG, isso pode significar ajustar acidentalmente para:
Com um DAG, você ajusta variáveis por uma razão — tipicamente para bloquear caminhos de confusão — em vez de porque elas existem.
Comece com um quadro branco e três passos:
Mesmo um DAG grosseiro alinha produto, dados e engenharia em torno da mesma pergunta causal antes de rodar números.
Uma grande mudança no pensamento causal de Judea Pearl é separar observar algo de mudá‑lo.
Se você observa que usuários que ativam notificações retêm melhor, aprendeu um padrão. Mas ainda não sabe se notificações causam retenção, ou se usuários engajados simplesmente têm mais probabilidade de ativar notificações.
Uma intervenção é diferente: significa que você define ativamente uma variável para um valor e pergunta o que acontece em seguida. Em termos de produto, isso não é “usuários escolheram X”, é “nós lançamos X”.
Pearl costuma rotular essa diferença como:
A ideia do “do” é basicamente um lembrete mental de que você está quebrando as razões usuais pelas quais uma variável toma um valor. Quando você intervém, notificações não estão ligadas porque usuários engajados optaram por elas; estão ligadas porque você forçou a configuração (ou fez um nudge). Esse é o ponto: intervenções ajudam a isolar causa e efeito.
A maioria do trabalho real de produto tem formato de intervenção:
Essas ações visam mudar resultados, não apenas descrevê‑los. Pensamento causal mantém a pergunta honesta: “Se fizermos isto, o que mudará?”
Você não pode interpretar uma intervenção (ou mesmo desenhar um bom experimento) sem suposições sobre o que afeta o quê — seu diagrama causal, mesmo informal. Por exemplo, se sazonalidade influencia tanto gasto em marketing quanto inscrições, então “fazer” uma mudança de gasto sem controlar a sazonalidade ainda pode enganar. Intervenções são poderosas, mas só respondem perguntas causais quando a história causal subjacente é pelo menos aproximadamente correta.
Um contrafactual é um tipo específico de pergunta “e se?”: para este caso exato, o que teria acontecido se tivéssemos tomado uma ação diferente (ou se uma entrada tivesse sido diferente)? Não é “o que acontece em média?” — é “isso teria mudado para esta pessoa, este ticket, esta transação?”
Contrafactuais aparecem sempre que alguém pede um caminho para um resultado diferente:
Essas perguntas são de nível usuário. Também são concretas o suficiente para guiar mudanças de produto, políticas e explicações.
Imagine um modelo de empréstimo que rejeita uma solicitação. Uma explicação baseada em correlação poderia dizer: “Pouca poupança correlaciona com rejeição.” Um contrafactual pergunta:
Se as reservas do candidato fossem $3.000 maiores (tudo o mais igual), o modelo o aprovaria?
Se a resposta for “sim”, você aprendeu algo acionável: uma mudança plausível que inverte a decisão. Se a resposta for “não”, você evitou dar um conselho enganoso como “aumente as poupanças” quando o bloqueador real é relação dívida/renda ou histórico de emprego instável.
Contrafactuais dependem de um modelo causal — uma história sobre como variáveis influenciam umas às outras — não apenas um conjunto de dados. Você precisa decidir o que pode realisticamente mudar, o que mudaria como consequência e o que deve permanecer fixo. Sem essa estrutura causal, contrafactuais podem virar cenários impossíveis (“aumente poupanças sem mudar renda ou gastos”) e produzir recomendações inúteis ou injustas.
Quando um modelo de ML falha em produção, a causa raiz raramente é “o algoritmo piorou”. Com mais frequência, algo no sistema mudou: o que você coleta de dados, como os rótulos são produzidos, ou o comportamento dos usuários. Pensamento causal ajuda você a parar de adivinhar e a começar a isolar qual mudança causou a degradação.
Alguns reincidentes aparecem em muitas equipes:
Isso pode parecer “tudo bem” em painéis agregados porque a correlação pode continuar alta mesmo quando a razão do acerto do modelo mudou.
Um diagrama causal simples (DAG) transforma depuração em um mapa. Ele força você a perguntar: essa feature é causa do rótulo, consequência dele, ou consequência de como medimos?
Por exemplo, se Política de rotulação → Engenharia de features → Inputs do modelo, você pode ter montado um pipeline onde o modelo prevê a política em vez do fenômeno subjacente. Um DAG torna esse caminho visível para que você possa bloqueá‑lo (remover a feature, mudar instrumentação ou redefinir o rótulo).
Em vez de só inspecionar previsões, tente intervenções controladas:
Muitas ferramentas de “explicabilidade” respondem a uma pergunta estreita: Por que o modelo deu essa pontuação? Frequentemente fazem isso destacando inputs influentes (importância de features, mapas de saliência, valores SHAP). Isso pode ser útil — mas não é o mesmo que explicar o sistema em que o modelo está inserido.
Uma explicação de previsão é local e descritiva: “Este empréstimo foi recusado principalmente porque a renda era baixa e a utilização estava alta.”
Uma explicação de sistema é causal e operacional: “Se aumentarmos a renda verificada (ou reduzirmos a utilização) de uma forma que reflita uma intervenção real, a decisão mudaria — e os resultados downstream melhorariam?”
A primeira ajuda a interpretar o comportamento do modelo. A segunda ajuda a decidir o que fazer.
O pensamento causal liga explicações a intervenções. Em vez de perguntar quais variáveis correlacionam com a pontuação, você pergunta quais variáveis são alavancas válidas e que efeitos produzem quando mudadas.
Um modelo causal força você a ser explícito sobre:
Isso importa porque uma feature “importante” pode ser um proxy — útil para predição, perigosa para ação.
Explicações post‑hoc podem parecer persuasivas enquanto permanecem puramente correlacionais. Se “número de tickets de suporte” prediz fortemente churn, um gráfico de importância pode tentar a equipe a “reduzir tickets” tornando o suporte mais difícil. Essa intervenção poderia aumentar o churn, porque tickets eram sintoma de problemas subjacentes — não a causa.
Explicações corrrelacionais também são frágeis durante shifts de distribuição: quando o comportamento do usuário muda, as mesmas features destacadas podem deixar de significar o mesmo.
Explicações causais são especialmente valiosas quando decisões têm consequências e requerem responsabilidade:
Quando você precisa agir, não apenas interpretar, a explicação precisa de uma espinha dorsal causal.
Testes A/B são inferência causal em sua forma mais simples e prática. Quando você atribui usuários aleatoriamente à variante A ou B, você está realizando uma intervenção: você não está apenas observando o que as pessoas escolheram, você está definindo o que veem. Em termos de Pearl, a randomização torna “do(variant = B)” real — então diferenças nos resultados podem credivelmente ser atribuídas à mudança, não a quem acabou escolhendo.
A atribuição aleatória quebra muitos links ocultos entre características do usuário e exposição. Power users, novos usuários, hora do dia, tipo de dispositivo — esses fatores continuam existindo, mas ficam (em média) balanceados entre os grupos. Esse balanceamento é o que transforma uma diferença de métrica em uma afirmação causal.
Mesmo ótimas equipes nem sempre podem rodar testes randomizados limpos:
Nesses casos, você ainda pode pensar causalmente — só precisa ser explícito sobre suposições e incerteza.
Opções comuns incluem diferença-em-diferenças (comparar mudanças ao longo do tempo entre grupos), descontinuidade de regressão (usar uma regra de corte como “apenas usuários acima de X”), variáveis instrumentais (um empurrão natural que muda a exposição sem afetar diretamente o resultado) e matching/weighting para tornar grupos mais comparáveis. Cada método troca randomização por suposições; um diagrama causal pode ajudar você a declarar essas suposições claramente.
Antes de lançar um teste (ou um estudo observacional), escreva: a métrica primária, guardrails, população alvo, duração e regra de decisão. Pré-registro não elimina viés, mas reduz p-hacking e torna afirmações causais mais confiáveis — e mais fáceis de debater na equipe.
A maioria dos debates de produto soa como: “A métrica X se moveu depois que lançamos Y — então Y funcionou.” Pensamento causal afina isso para uma pergunta mais clara: “A mudança Y causou a métrica X a se mover, e em quanto?” Essa mudança transforma dashboards de prova em pontos de partida.
Mudança de preço: em vez de “a receita subiu após o aumento de preço?”, pergunte:
Ajuste de onboarding: em vez de “novos usuários completam onboarding com mais frequência agora”, pergunte:
Mudança no ranqueamento de recomendações: em vez de “o CTR melhorou”, pergunte:
Painéis frequentemente misturam “quem recebeu a mudança” com “quem teria se saído bem de qualquer forma”. Um exemplo clássico: você lança um novo fluxo de onboarding, mas ele é mostrado primeiro a usuários na versão mais nova do app. Se versões mais novas são adotadas por usuários mais engajados, seu gráfico pode mostrar um aumento que é em parte (ou totalmente) adoção de versão, não onboarding.
Outros confusores frequentes em analytics de produto:
Uma seção útil no PRD pode se chamar literalmente “Perguntas Causais” e incluir:
Se você usa ciclos rápidos de construção (especialmente com desenvolvimento assistido por LLM), essa seção se torna ainda mais importante: evita que “podemos lançar rápido” vire “lançamos sem saber o que causou”. Equipes que usam Koder.ai costumam embutir essas perguntas causais na fase de planejamento, então implementam variantes com feature flags rapidamente, com snapshots/rollback para manter a experimentação segura quando resultados (ou efeitos colaterais) surpreendem.
PMs definem a decisão e critérios de sucesso. Parceiros de dados traduzem isso em estimativas causais mensuráveis e checagens de sanidade. Engenharia garante que a mudança é controlável (feature flags, logging limpo de exposição). Suporte compartilha sinais qualitativos — mudanças de preço costumam “funcionar” enquanto silenciosamente aumentam cancelamentos ou volume de tickets. Quando todos concordam sobre a pergunta causal, lançar vira aprendizado — não apenas deploy.
Pensamento causal não precisa de um rollout de nível PhD. Trate‑o como um hábito de equipe: escreva sua história causal, submeta a críticas e então deixe os dados (e experimentos quando possível) confirmar ou corrigir.
Para avançar, colete quatro insumos desde o início:
Na prática, velocidade importa aqui: quanto mais rápido você transformar uma pergunta causal em uma mudança controlada, menos tempo passa discutindo padrões ambíguos. Isso é uma razão pela qual times adotam plataformas como Koder.ai para ir de “hipótese + plano” a uma implementação instrumentada (web, backend ou mobile) em dias em vez de semanas — mantendo rigor por meio de rollouts faseados, deploys e rollback.
Se quiser um refresher sobre experimentos, veja /blog/ab-testing-basics. Para armadilhas comuns em métricas de produto que imitam “efeitos”, veja /blog/metrics-that-mislead.
Pensamento causal é a mudança de “o que tende a se mover junto?” para “o que mudaria se agíssemos?” Essa mudança — popularizada em computação e estatística por Judea Pearl — ajuda equipes a evitar histórias com aparência confiante que não sobrevivem a intervenções reais.
Correlação é uma pista, não uma resposta.
Diagramas causais (DAGs) tornam suposições visíveis e passíveis de debate.
Intervenções (“do”) são diferentes de observações (“see”).
Contrafactuais ajudam a explicar casos individuais: “e se esta única coisa fosse diferente?”
Bom trabalho causal documenta incerteza e explicações alternativas.
Causalidade exige cuidado: confusores ocultos, erros de medição e efeitos de seleção podem inverter conclusões. O antídoto é transparência — escreva suposições, mostre que dados usou e aponte o que poderia falsificar sua afirmação.
Se quiser se aprofundar, navegue por artigos relacionados em /blog e compare abordagens causais com outros métodos de analytics e “explicabilidade” para ver onde cada um ajuda — e onde pode enganar.
Correlação ajuda você a prever ou detectar (por exemplo, “quando X sobe, Y frequentemente sobe também”). Causalidade responde a uma questão de decisão: “Se mudarmos X de propósito, Y mudará?”
Use correlação para previsão e monitoramento; use pensamento causal quando for para lançar uma mudança, definir uma política ou alocar orçamento.
Porque a correlação pode ser impulsionada por confusão. No exemplo das notificações, usuários altamente engajados tanto disparam/recebem mais notificações quanto retornam mais.
Se você aumenta notificações para todos, mudou a experiência (uma intervenção) sem mudar o engajamento subjacente — então a retenção pode não melhorar e pode até piorar.
Um DAG (Grafo Acíclico Dirigido) é um diagrama simples onde:
É útil porque torna explícitas as suposições, ajudando as equipes a concordar sobre o que ajustar, o que não ajustar e qual experimento realmente responderia à pergunta.
Um erro comum é “controlar tudo”, o que pode ajustar acidentalmente para mediadores ou colisores e viésar o resultado.
“See” é observar o que aconteceu naturalmente (usuários optaram, uma pontuação estava alta). “Do” é definir ativamente uma variável (lançar um recurso, forçar um padrão).
A ideia-chave: uma intervenção quebra as razões usuais pelas quais uma variável toma um valor, por isso ela pode revelar causalidade mais confiavelmente que a observação sozinha.
Um contrafactual pergunta: para este caso específico, o que teria acontecido se tivéssemos feito algo diferente.
É útil para:
Exige um modelo causal para não propor mudanças impossíveis.
Foque em o que mudou a montante e no que o modelo pode estar explorando:
Uma mentalidade causal leva você a testar intervenções direcionadas (ablações, perturbações) em vez de perseguir movimentos coincidentes de métricas.
Nem sempre. Importância de feature explica o que influenciou a previsão, não o que você deve mudar.
Uma feature muito “importante” pode ser um proxy ou sintoma (por exemplo, tickets de suporte predizem churn). Intervir no proxy (“reduzir tickets tornando o suporte mais difícil”) pode sair pela culatra. Explicações causais ligam importância a alavancas válidas e aos efeitos esperados sob intervenção.
Testes A/B randomizados são ideais quando viáveis, mas considere alternativas quando:
Nesses casos, pense em quase‑experimentos como diferença-em-diferenças, descontinuidade de regressão, variáveis instrumentais, ou matching/weighting — sendo explícito sobre as suposições.
Adicione uma seção curta que force clareza antes da análise:
Isso mantém a equipe alinhada numa pergunta causal em vez de histórias pós‑hoc baseadas em dashboards.
