Resumo Técnico: ReproScore: Separando Preparação de Resultado na Avaliação de Reprodutibilidade de Software de Pesquisa

1. Declaração do Problema

Bibliotecas digitais (por exemplo, Zenodo, Software Heritage) curam milhões de artefatos de software de pesquisa, mas carecem de infraestrutura escalável para avaliar se esses artefatos são realmente executáveis. As ferramentas de avaliação automatizada existentes sofrem de uma falha crítica: elas confundem preparação (completude estática do repositório, como a presença de um README ou requirements.txt) com resultado (sucesso real da execução).

Essa "confusão entre preparação e resultado" leva a uma falsa suposição de que um repositório com documentação estática completa provavelmente será executado. Na realidade, um repositório pode possuir sinais estáticos perfeitos, mas falhar devido a conflitos de dependências transitivas, dados inacessíveis ou problemas de ambiente de execução que a análise estática não consegue detectar. As ferramentas atuais dependem ou de análise estática (ignorando a execução) ou exigem execução em sandbox cara e conduzida por especialistas (falta de escalabilidade). Há uma necessidade de um framework que distinga explicitamente entre o potencial de reprodutibilidade (preparação) e o resultado real da execução (resultado), fornecendo aos curadores informações diagnósticas em vez de uma previsão binária de aprovação/reprovação.

2. Metodologia: A Arquitetura do ReproScore

O ReproScore é um framework de dois níveis projetado para separar a preparação para reprodutibilidade do resultado da execução, combinando-os em uma pontuação composta adaptativa à cobertura.

Nível 1: Pontuação de Preparação para Reprodutibilidade (RRS)

O RRS é uma métrica estática, sempre disponível, calculada por meio de análise determinística e baseada em regras de um repositório clonado localmente. Não requer execução de código.

• Estrutura: O RRS compreende 26 sub-métricas atômicas agrupadas em cinco categorias:
  1. Ambiente (E, peso 0,30): Especificação de dependências, containerização e versões de tempo de execução.
  2. Dados (A, peso 0,25): Acessibilidade, ponteiros e métodos de aquisição para dados de entrada.
  3. Documentação (D, peso 0,20): Presença de instruções de execução, pontos de entrada e exemplos de uso.
  4. Portabilidade do Código (C, peso 0,15): Ausência de caminhos absolutos, credenciais codificadas e imports irresolúveis.
  5. Sinais de Reprodutibilidade (S, peso 0,10): Sinais de determinismo como gerenciamento de sementes e ordem de execução.
• Lógica de Pontuação:
  • Função de Portão: Uma função de portão de lei de potência $g(x, \tau, k)$ penaliza pontes abaixo do limiar de forma não linear. Pontuações abaixo de um limiar $\tau$ são comprimidas, refletindo uma política de curadoria de que deficiências graves (por exemplo, especificação de ambiente ausente) são desproporcionalmente prejudiciais.
  • Penalidades: Penalidades rígidas são aplicadas para a ausência completa de especificações de ambiente ou artefatos de dados ($P_{hard}$), e para operações estocásticas sem gerenciamento de sementes ($P_{seed}$).
  • Fórmula: $RRS = 100 \cdot \sum (w_i \cdot g(x_i)) - \text{penalidades}$.

Nível 2: Pontuação de Resultado de Reprodutibilidade (ROS)

O ROS é uma métrica opcional, baseada em execução, calculada quando um ambiente em sandbox (por exemplo, repo2docker, nbconvert) está disponível.

• Componentes: Agrega até seis sondas: Sucesso de instalação ($I$), Sucesso de execução ($X$), Determinismo de saída ($\Delta$), Taxa de execução de notebook ($N$), Taxa de sucesso de importação ($E'$) e Taxa de aprovação de testes ($T$).
• Normalização: O ROS é uma soma ponderada dos componentes disponíveis, permitindo que a pontuação seja calculada mesmo se apenas dados parciais de execução estiverem disponíveis.

Pontuação Composta (RCS)

A Pontuação Composta ReproScore (RCS) combina RRS e ROS com base na quantidade de evidências de execução coletadas.

• Peso de Cobertura ($\alpha$): Um parâmetro que escala de 0 (sem execução) para um máximo de 0,70. Garante que a preparação estática nunca seja totalmente dominada por resultados de execução, reconhecendo que uma execução bem-sucedida não valida documentação ou portabilidade.
• Fórmula: $RCS = (1 - \alpha) \cdot RRS + \alpha \cdot ROS$. Se não houver dados de execução, $RCS = RRS$.

Mecanismo de Rubrica da Comunidade

O ReproScore externaliza prioridades de avaliação por meio de um perfil YAML versionado. Isso permite que diferentes comunidades (por exemplo, bioinformática versus software geral) substituam pesos padrão e limiares de portão sem modificar o código-fonte. Isso torna as políticas de curadoria explícitas, auditáveis e portáteis entre instituições.

3. Contribuições Principais

1. Separação Conceitual: Uma arquitetura formal de dois níveis (RRS/ROS/RCS) que desacopla a preparação estática do resultado da execução, abordando a confusão entre preparação e resultado nos fluxos de trabalho de bibliotecas digitais.
2. Modelo de Preparação: Um modelo de 5 categorias e 26 sub-métricas (RRS) com pesos informados por especialistas, portão não linear e proveniência de evidências em nível de arquivo.
3. Mecanismo de Governança: Um sistema de rubrica da comunidade que permite que prioridades de avaliação sejam definidas como artefatos citáveis e versionados.
4. Validação Empírica: Uma avaliação em 423 repositórios do GitHub (Python/Jupyter) demonstrando que a preparação estática discrimina fortemente entre modos de falha, mas exibe correlação próxima de zero com sucesso de execução binário.

4. Resultados da Avaliação

O framework foi avaliado em uma amostra estratificada de 423 repositórios de um corpus de verdade fundamental, categorizados em cinco modos de falha: Sucesso, Erros de Dependência de Instalação, Módulos Ausentes, Dados Ausentes e Erros de Código.

• Discriminação de Modo de Falha: A categoria Ambiente (E) mostrou a maior capacidade de discriminar entre modos de falha (Kruskal-Wallis $H = 96,89, p < 0,001$).
  • O Paradoxo da Detecção: Repositórios com erros de dependência de instalação (install_dep) obtiveram as pontuações mais altas em Ambiente (média 22,8) porque especificaram explicitamente ambientes, mas falharam devido a conflitos de versão. Por outro lado, repositórios bem-sucedidos obtiveram pontuações mais baixas (média 10,3) porque frequentemente careciam de especificações explícitas. Isso confirma que o RRS caracteriza que tipo de problema existe, não se ele terá sucesso.
• Correlação Binária: A correlação entre RRS e sucesso de execução binário foi próxima de zero ($r_{pb} = -0,014$). Isso quantifica empiricamente a lacuna entre preparação e resultado: uma pontuação estática alta não prevê uma execução bem-sucedida.
• Robustez:
  • Estabilidade de Peso: As classificações de repositórios permaneceram estáveis ($\tau \ge 0,911$) mesmo quando os pesos foram perturbados em $\pm 50\%$.
  • Insensibilidade do Portão: A função de portão teve impacto negligenciável na previsão binária (faixa AUC $\approx 0,008$), confirmando seu papel como ferramenta de política normativa em vez de mecanismo preditivo.
  • Deixar-Uma-Categoria-De-Lado: Remover as categorias Ambiente ou Dados na verdade melhorou o AUC binário, provando ainda mais que essas categorias são projetadas para caracterizar tipos de falha, não prever sucesso binário.
• Validação Composta: Na validação parcial do ROS, o RCS reclassificou corretamente os repositórios. Por exemplo, repositórios install_dep tiveram um RRS moderado (26,8) mas um ROS próximo de zero (13,5), resultando em um RCS baixo (19,8), refletindo com precisão sua falha de execução apesar da completude estática.

5. Significado e Alegações

O artigo posiciona o ReproScore como um instrumento diagnóstico para curadores de bibliotecas digitais, em vez de um preditor binário de sucesso.

• Necessidade Arquitetônica: O estudo valida que separar preparação de resultado é tanto necessário quanto não trivial. Sinais estáticos capturam diferenças estruturais significativas (por exemplo, distinguir um módulo ausente de um conflito de versão) que métricas de sucesso binário obscurecem.
• Utilidade Curatorial: Ao fornecer um perfil em nível de categoria, o ReproScore permite remediação direcionada. Uma pontuação baixa de Ambiente sugere que é necessário fixar dependências; uma pontuação baixa de Dados sugere ponteiros ausentes. Isso é mais acionável do que uma única pontuação de "reprodutibilidade".
• Escalabilidade: A abordagem baseada em estático (RRS) permite que bibliotecas triagem milhões de depósitos sem o custo computacional de execução em sandbox, reservando recursos de execução para artefatos que mostram promessa ou exigem validação específica.
• Transparência de Política: O mecanismo de rubrica da comunidade transforma heurísticas de pontuação de código opaco em políticas auditáveis e citáveis, facilitando a comparação entre instituições e a adaptação específica de domínio (por exemplo, priorizando acessibilidade de dados em bioinformática).

Os autores concluem que um framework que nomeia explicitamente a lacuna entre preparação e resultado é mais informativo para fluxos de trabalho de curadoria do que aquele que os colapsa. O ReproScore fornece a infraestrutura para gerenciar essa lacuna, apoiando as entidades Ingestão e Armazenamento de Arquivo do OAIS com métricas computáveis e escaláveis.