Beyond Reproducible Research: Building a Formal Representation of a Data Analysis

O artigo propõe e descreve a implementação de uma representação formal que externaliza o raciocínio lógico de uma análise de dados, permitindo avaliar a qualidade e a sensibilidade das premissas do analista sem depender apenas da execução do código ou dos dados brutos.

O essencial

Imagine que você pediu a um amigo para cozinhar um prato delicioso para você. Ele te entrega o prato pronto e diz: "Aqui está, ficou ótimo!".

A ciência reprodutível (o método atual) seria o seu amigo te entregar a receita escrita e os ingredientes que ele usou. Você poderia tentar fazer o prato de novo para ver se fica igual. Isso é bom, mas tem um problema: a receita não explica por que ele escolheu aquele tempero, por que ele achou que o sal estava no ponto, ou por que ele decidiu não usar pimenta. Se o prato estiver ruim, você só descobre depois de tentar cozinhar de novo.

Este artigo, escrito por Roger D. Peng, propõe uma nova maneira de "entregar" a análise de dados. Em vez de apenas dar a receita (o código), ele sugere que o analista entregue um "Livro de Argumentos" que explica o raciocínio por trás de cada passo, antes mesmo de você ver o resultado final.

Aqui está a explicação do conceito, usando analogias simples:

1. O Problema: O Código é uma "Caixa Preta"

Hoje, os cientistas mostram o código (as instruções) e os dados. O código é como uma lista de comandos: "Pegue o dado A, some com B, divida por C".

• O problema: Se o código rodar sem erros e mostrar um número, ninguém sabe se o cientista estava certo. Talvez ele tenha assumido que os dados eram perfeitos, ou ignorou um erro óbvio. O código diz o que foi feito, mas não explica por que aquilo faz sentido.

2. A Solução: A Análise como uma "Cadeia de Evidências"

O autor sugere tratar a análise de dados como se fosse uma prova matemática ou um caso de tribunal, e não apenas um programa de computador.

Imagine que você é um detetive tentando provar que "O suspeito estava no local".

• Método antigo: Você mostra o vídeo da câmera de segurança (o código rodando).
• Método novo (proposto): Você constrói uma estrutura lógica onde cada afirmação precisa de "provas" para ser aceita.
  • Afirmação: "O suspeito estava lá."
  • Prova 1: "O relógio dele bate com o horário do crime." (Se o relógio estiver errado, a prova falha).
  • Prova 2: "Não há ninguém com o mesmo rosto." (Se houver, a prova falha).

No artigo, isso é feito usando "Classes" no computador. É como criar um molde para cada afirmação.

• Se você diz "A média é 4,6", o computador exige que você preencha o molde com provas de que:
  1. Não há dados faltando (que poderiam estragar a média).
  2. Não há números absurdos (outliers) que puxem a média para cima.
  3. A distribuição dos dados faz sentido.

Se você não conseguir preencher esses "moldes" de prova, o sistema não deixa você declarar que a média é 4,6.

3. A Grande Vantagem: Verificar sem Cozinhar

A parte mais genial dessa ideia é que você pode verificar se a lógica está correta sem precisar rodar o código com os dados reais.

• Analogia: Imagine que você está projetando um prédio.
  • No método atual, você constrói o prédio inteiro e só depois vê se ele cai.
  • No método do autor, você desenha o plano estrutural com todas as vigas e apoios explicados. Um engenheiro pode olhar o desenho e dizer: "Se essa viga aqui for de madeira, o prédio cai, mesmo que você ainda não tenha construído nada".

Isso significa que podemos encontrar erros de raciocínio antes de gastar tempo processando dados, e até mesmo analisar estudos que usam dados confidenciais (que não podem ser compartilhados), apenas olhando para a lógica do argumento.

4. A Árvore de Decisão (O Mapa do Tesouro)

O artigo sugere visualizar essas provas como uma árvore.

• O topo da árvore é a conclusão (ex: "O remédio funciona").
• Os galhos são as provas necessárias (ex: "Os pacientes não tinham alergia", "A dose estava correta").
• Se um galho quebrar (uma prova falhar), a conclusão no topo cai.

Isso permite que qualquer pessoa veja exatamente onde o analista fez suposições e onde ele pode ter sido muito otimista.

Resumo em uma frase

Em vez de apenas mostrar "como fizemos a conta" (o código), este método exige que mostremos "por que acreditamos que a conta está certa" (a lógica e as provas), transformando a análise de dados em um argumento transparente e verificável, como uma prova matemática, em vez de apenas um programa que roda.

Por que isso importa?
Isso ajuda a evitar que cientistas (ou qualquer um que analise dados) tirem conclusões erradas sem perceber, porque o sistema os força a explicar cada passo do raciocínio, não apenas a executar a tarefa. É como trocar uma receita de bolo que só diz "misture tudo" por uma receita que explica "misture tudo, mas só se os ovos estiverem frescos e a farinha não estiver úmida, senão o bolo não cresce".

Resumo técnico

Resumo Técnico: Além da Pesquisa Reprodutível – Construindo uma Representação Formal de Análise de Dados

1. O Problema

A reprodutibilidade em ciência de dados tem sido tradicionalmente abordada através do compartilhamento de código e dados brutos. Embora essencial, essa abordagem possui limitações críticas:

• Foco Dinâmico vs. Estático: A reprodutibilidade atual trata a análise como um programa de computador a ser executado (dinâmico). Se o código roda sem erros, assume-se que a análise está correta. No entanto, isso não valida o raciocínio por trás da análise, as premissas do analista ou as expectativas sobre os dados.
• Ocultação do Raciocínio: O código imperativo (sequência de comandos) mostra o que foi feito, mas não explica por que certas afirmações sobre os dados são consideradas verdadeiras. Premissas, expectativas e suposições lógicas ficam implícitas ou ausentes.
• Dependência de Execução: Para verificar a validade de uma afirmação de análise de dados (ex: "a média é 4.6"), é necessário executar o código sobre os dados. Isso é problemático quando os dados são sensíveis, indisponíveis ou quando se deseja uma avaliação estática da lógica antes da execução.
• Erros Silenciosos: Operações comuns (como junção de tabelas) podem produzir resultados inesperados sem gerar erros de sintaxe, levando a conclusões falsas que o código por si só não consegue prevenir.

O autor argumenta que é necessário ir além da simples reprodutibilidade para uma representação formal estática que externalize a construção lógica da análise.

2. Metodologia

O artigo propõe um sistema onde as afirmações de análise de dados são tratadas como definições de classes em um ambiente de programação orientada a objetos (especificamente usando o sistema de classes S4 em R). A metodologia baseia-se em três princípios fundamentais:

• Análise de Dados como Afirmações com Evidências: Em vez de ver a análise como "entrada $\to$ saída", ela é vista como a geração de uma afirmação que requer evidências. O código deve declarar explicitamente o que se espera que seja verdadeiro.
• Afirmações como Definições de Classes: Cada afirmação de análise (ex: "a primeira coluna não tem valores ausentes") é modelada como uma classe de objetos. A criação de um objeto dessa classe serve como prova de que a afirmação é verdadeira.
  • O sistema utiliza métodos de validação (validity) dentro das classes. Se os dados não satisfizerem as condições da classe, o objeto não é criado e um erro é lançado.
• Premissas de Suporte como Extensões de Classe: Para apoiar uma afirmação principal, definem-se classes de premissas (evidências). A estrutura hierárquica é construída onde uma classe principal contém "slots" (espaços) para objetos de classes de premissas.
  • Abordagem Direta: Identificar afirmações que implicam diretamente a conclusão.
  • Abordagem Indireta: Identificar condições que tornariam a afirmação falsa (hipóteses alternativas) e criar premissas que eliminam essas condições (ex: provar que não há outliers ou que a distribuição não é enviesada).

Implementação Técnica:
O autor implementa esse sistema em R utilizando classes S4. O fluxo de trabalho envolve:

1. Definir uma classe para a afirmação final.
2. Definir classes para as premissas de suporte (e suas próprias premissas, recursivamente).
3. Vincular as premissas à afirmação principal através da herança de classes e slots.
4. Executar o código apenas para instanciar os objetos; se a instância for criada com sucesso, a cadeia lógica de evidências é validada.

3. Principais Contribuições e Resultados

• Análise Estática de Código: O sistema permite avaliar a qualidade e a lógica de uma análise sem executar o código sobre os dados reais. Ao ler as definições das classes, é possível entender as expectativas do analista e verificar se as premissas cobrem os cenários de erro possíveis.
• Visualização da Estrutura Lógica: A hierarquia de classes pode ser visualizada como uma árvore de premissas (similar a uma árvore de falhas invertida). Isso permite identificar rapidamente lacunas no raciocínio ou premissas fracas.
• Prevenção de Erros Silenciosos: O uso de métodos de validação explícitos impede que objetos sejam criados se os dados não atenderem aos critérios esperados (ex: número de linhas após uma junção de dados, ausência de valores NA). Isso transforma erros de lógica em erros de execução imediatos.
• Análise de Sensibilidade: O framework facilita a simulação de dados com características inesperadas (outliers, não-linearidade) para testar se as premissas definidas são robustas o suficiente para suportar a conclusão.
• Exemplos Práticos:
  • Média de uma Coluna: Demonstrou como validar que a média é 4.6, provando simultaneamente que não há valores ausentes, que a mediana é próxima e que não há outliers significativos.
  • Regressão Linear Simples: Mostrou como estruturar a afirmação de um coeficiente de inclinação, exigindo premissas sobre a ausência de não-linearidade, outliers e a adequação dos gráficos de resíduos.

4. Significado e Impacto

• Mudança de Paradigma: O artigo propõe mudar o foco da reprodutibilidade (reproduzir resultados) para a verificabilidade do raciocínio. A análise torna-se um argumento lógico construído, não apenas um script executável.
• Transparência e Crítica: Ao externalizar as premissas, outros pesquisadores podem criticar e avaliar a qualidade do raciocínio do analista sem precisar acessar os dados brutos ou reexecutar o código.
• Relação com Engenharia de Sistemas: A estrutura de árvores de premissas é análoga às "árvores de falha" (fault trees) usadas em engenharia de sistemas e aviação, mas invertida: em vez de listar o que causa um erro, lista-se o que deve ser verdade para que o sucesso ocorra.
• Limitações e Futuro: O autor reconhece que a implementação atual em R (S4) é verbosa e gera sobrecarga de código. No entanto, o valor está na especificação explícita do que é esperado. O trabalho sugere que futuros sistemas poderiam automatizar essa estrutura ou integrar melhor a validação de gráficos (uma área desafiadora).

Conclusão:
O artigo não propõe uma ferramenta para fazer análise de dados, mas sim uma representação formal para documentar e validar o raciocínio da análise. Ao tratar afirmações de dados como tipos de dados com validação rigorosa, o sistema permite uma avaliação estática da lógica, tornando o processo analítico mais transparente, robusto e menos dependente da execução cega de scripts.