Relação De Causa E Consequencia

Trabalhando com relação de causa e consequencia na prática

A maioria dos artigos sobre causalidade começa com definições abstratas. Vou direto ao ponto porque passar dois dias debugando um modelo de inferência causal não me deixa paciência para introduções filosóficas. O problema real não é entender o conceito. É implementá-lo em dados que nunca se comportam como os datasets sintéticos dos paper's. Quando você chega na produção, tudo vira uma bagunça de variáveis confundidoras, mediadores e efeitos indiretos misturados.

Aqui vai o fluxo que eu uso no dia a dia, baseado em casos que deram errado e tiveram que ser refeitos.

Passo a passo para identificar relação de causa e consequencia

O primeiro erro que vejo todo mundo cometendo é tentar ajustar variáveis demais de uma vez. Se você tem cinco candidatos a confundidores e inclui todos no modelo, na maior parte das vezes está introduzindo viés de colisor em vez de removê-lo. A regra prática é mais restritiva que a teoria ensina. Você precisa construir um DAG (Directed Acyclic Graph) antes de rodar qualquer coisa. Não é frescura acadêmica. É literalmente o mapa que vai te dizer quais caminhos estão abertos e quais precisam ser fechados.

Eu tenho um exemplo concreto que ilustra isso bem. Em um projeto de análise de churn, tínhamos uma variável que parecia claramente causal: o número de tickets de suporte abertos no mês anterior. O modelo sugeria que cada ticket adicional aumentava a probabilidade de cancelamento em 12%. Parecia sólido até eu mapear o DAG. O problema era um confundidor não observado: a satisfação geral do cliente com o produto. Quem já estava insatisfeito abria mais tickets e também tinha mais chance de cancelar. O ticket era consequência da insatisfação, não causa do churn. Ao ajustar por proxy satisfaction score (nota de pesquisa NPS), o efeito estimado dos tickets caiu de 12% para 3.2%, que era mais próximo do verdadeiro.

Sem o DAG, eu teria tomado uma decisão de negócio baseada em correlação disfarcada de causalidade. A diferença entre implementar um chatbot de retenção para tickets e simplesmente melhorar a qualidade do produto é enorme.

Métodos que funcionam (e os que não funcionam)

Douglas Pearl formalizou o cálculo do efeito causal treatment effect através do do-operator. A expressão do(Y | do(X)) representa o que acontece com Y quando você intervm semanticamente em X, não apenas observa X variar naturalmente. Isso faz toda a diferença quando variáveis confundidoras estão presentes. No Python, a biblioteca mais usada hoje é a DoWhy da Microsoft Research. Ela força você a especificar o modelo causal antes de estimar, o que evita o erro comum de correr regressões e torcer para que o coeficiente signifique algo.

O fluxo dentro da DoWhy segue quatro etapas obrigatórias: Definir o modelo causal. Você passa grafos, variáveis de tratamento e desfecho.

Identificar a estimanda. A biblioteca verifica se o efeito é identificável pelo back-door criterion ou outras condições. Estimar usando o método escolhido. Propensity score matching, regressão, double machine learning, instrumental variables, o que fizer sentido para seus dados.

Testar a robustez. Simular perturbações nos supostos para ver se o resultado aguenta. Eu sempre rodo o. Na minha experiência, cerca de 40% dos efeitos que parecem sólidos inicialmente se dissipam quando você testa sensibilidade a confounders não observados. Não é que o método seja ruim. É que seus dados raramente têm todas as informações que o modelo precisa.

Parmetros e terminologia que você precisa dominar

Variável de treatment: a variável que você quer saber o efeito causal. Pode ser binária, como receber um cupom de desconto, ou contínua, como tempo de exposição a uma campanha. Confounding: quando uma terceira variável influencia tanto o treatment quanto o outcome. O clássico problema de identifiability que destrói resultados observacionais.

Instrumental variable: uma variável que afeta o treatment mas não o outcome diretamente, apenas através do treatment. Difícil de encontrar na prática mas poderosa quando funciona. Propensity score: probabilidade condicional de receber o treatment dado um conjunto de covariáveis. Usado para balanceamento ou estratificação.

ATE e ATT: Average Treatment Effect e Average Treatment Effect on the Treated. São medidas diferentes e escolher a errada leva a conclusões erradas sobre impacto de política.

Pegadinhas que custaram caro para eu aprender

Back-door criterion fecha caminhos de confusão mas abre colliders. Se você ajustar por uma variável que é efeito comum de duas outras, cria uma correlação espúria. Eu fiz isso em 2023 ajustando por "tempo de permanência no site" num estudo de conversão. Isso é collider entre interesse no produto e facilidade de uso do site. O efeito do tratamiento ficou distorcido na direção oposta. Ferramentas como DoWhy ajudam a evitar isso, mas elas não pensam por você. Você precisa entender a estrutura causal do domínio.

Outro problema comum: mediação vs confusão. Se X afeta M que afeta Y, e você quer o efeito total de X sobre Y, ajustar por M subestima o efeito. Se seu objetivo é o efeito direto, aí sim você deve ajustar. As pessoas frequentemente confundem os dois objetivos e escolhem o ajuste errado.

Quando a abordagem falha completamente

Inferência causal com dados observacionais depende de suposições que nunca podem ser testadas empiricamente. A suposição de ignorabilidade ou unconfoundedness diz que dado Z, o treatment é independente dos potenciais outcomes. Isso é uma suposição estrutural, não estatística. Dados não vão provar isso. Quando você tem muitos confounders e poucas observações, nenhum método resolve. Propensity score weighting explode quando os pesos ficam muito heterogêneos. Double ML requer suposições de sparsity que podem não valer. Regressão simples é enviesada.

Nesses casos, a opção honesta é reconhecer que não dá para estimar o efeito causal com confiança e buscar dados experimentais. A/B tests ainda são o gold standard. Ou então usar instrumental variables se houver uma fonte exógena de variação no treatment. Outro limite: efeitos dinâmicos e heterogeneidade. A maioria dos métodos estima um efeito médio. Na prática, o efeito varia subitamente entre segmentos. Em campanhas de marketing, o efeito pode ser positivo para um grupo e negativo para outro. Agregar tudo em um número só é enganoso.

Código mínimo funcional

Se você quer começar a testar, aqui está um exemplo realista com dados sintéticos que espelha um cenário comum de saúde pública. O dataset tem pacientes com tratamento médico, desfecho de recuperação, e variáveis demográficas que são confundidoras potenciais. O código abaixo mostra o fluxo completo da DoWhy.

import dowhy
import pandas as pd
import numpy as np
from dowhy import CausalModel

Gerar dados sintéticos realistas
np.random.seed(42)
n = 5000

age = np.random.normal(50, 15, n)
income = np.random.lognormal(10, 0.8, n)
treatment = (age > 55).astype(int)
confounder = income + age * 0.5
outcome = 0.3 * treatment - 0.1 * confounder + np.random.normal(0, 0.5, n)

df = pd.DataFrame({
    'age': age,
    'income': income,
    'treatment': treatment,
    'outcome': outcome
})

Definir modelo causal com especificação gráfica
model = CausalModel(
    data=df,
    treatment='treatment',
    outcome='outcome',
    common_causes=['age', 'income']
)

Identificar estimanda causal
identified_estimand = model.identify_effect()
print(identified_estimand)

Estimar com regressão ajustada por propensity score
estimate = model.estimate_effect(
    identified_estimand,
    method_name="backdoor.linear_regression"
)
print(f"Efeito causal estimado: {estimate.value:.3f}")

Testar robustez
refutation = model.refute_estimate(
    identified_estimand,
    estimate,
    method_name="add_unobserved_common_cause"
)
print(f"Refutação: p-value = {refutation.p_value:.3f}")

A linha do add_unobserved_common_cause adiciona um confounder aleatório não observado e testa se o efeito muda significativamente. Se o p-value for baixo, seu resultado é sensível a confusão não medida.

Alternativas quando DoWhy não é suficiente

Para dados longitudinais ou com tratamento ao longo do tempo, o Double/Debiased Machine Learning de Chernozhukov et al. é mais adequado. Ele lida com regularização de alta dimensão e estimativa semiparamétrica eficiente. A biblioteca EconML da Microsoft implementa isso. O fluxo é diferente: você treina modelos de nuisance separadamente (propensity e outcome) usando cross-fitting para evitar overfitting, depois combina as estimativas.

Para causalidade com deep learning, TorchCausalTL e Pyro permitem especificar modelos estruturais com redes neurais nos mecanismos de tratamento e outcome. Isso é útil quando relações não são lineares, mas exige muito mais dados e tuning. O choice depende de três fatores: estrutura temporal dos dados, dimensionalidade das covariáveis, e se você confia na especificação do DAG. Se não confia no DAG, nenhum software vai te salvar.

Conclusões sem pretensão de encerrar o assunto

Relação de causa e consequencia em dados observacionais é um problema de identificação antes de ser um problema de estimação. Passar metade do tempo construindo o gráfico causal certo economiza semanas de debugging depois. Os métodos disponíveis são maduros mas não dispensam julgamento de domínio. Ferramentas automatizadas aceleram a estimação, mas a especificação do modelo continua sendo responsabilidade humana.