Riepilogo Tecnico: ReproScore: Separazione della Prontezza dal Risultato nella Valutazione della Riproducibilità del Software di Ricerca

1. Enunciato del Problema

Le biblioteche digitali (ad esempio, Zenodo, Software Heritage) curano milioni di artefatti software di ricerca ma mancano di un'infrastruttura scalabile per valutare se tali artefatti siano effettivamente eseguibili. Gli strumenti di valutazione automatizzata esistenti soffrono di un difetto critico: confondono la prontezza (completezza statica del repository, come la presenza di un README o di un requirements.txt) con il risultato (il successo effettivo dell'esecuzione).

Questa "confusione prontezza-risultato" porta a un'assunzione falsa secondo cui un repository con documentazione statica completa sia probabile che venga eseguito. In realtà, un repository può possedere segnali statici perfetti ma fallire a causa di conflitti di dipendenze transitive, dati inaccessibili o problemi dell'ambiente di runtime che l'analisi statica non può rilevare. Gli strumenti attuali si affidano o all'analisi statica (ignorando l'esecuzione) o richiedono un'esecuzione in sandbox costosa e guidata da esperti (mancando di scalabilità). È necessario un framework che distingua esplicitamente tra il potenziale di riproducibilità (prontezza) e il risultato effettivo dell'esecuzione (risultato), fornendo ai curatori informazioni diagnostiche piuttosto che una previsione binaria di successo/fallimento.

2. Metodologia: L'Architettura di ReproScore

ReproScore è un framework a due livelli progettato per separare la prontezza alla riproducibilità dal risultato dell'esecuzione, combinandoli in un punteggio composito adattivo alla copertura.

Livello 1: Punteggio di Prontezza alla Riproducibilità (RRS)

Il RRS è una metrica statica, sempre disponibile, calcolata tramite un'analisi deterministica e basata su regole di un repository clonato localmente. Non richiede l'esecuzione del codice.

• Struttura: Il RRS comprende 26 sub-metriche atomiche raggruppate in cinque categorie:
  1. Ambiente (E, peso 0,30): Specifica delle dipendenze, containerizzazione e versioni del runtime.
  2. Dati (A, peso 0,25): Accessibilità, puntatori e metodi di acquisizione per i dati di input.
  3. Documentazione (D, peso 0,20): Presenza di istruzioni di esecuzione, punti di ingresso ed esempi di utilizzo.
  4. Portabilità del Codice (C, peso 0,15): Assenza di percorsi assoluti, credenziali hardcoded e importazioni irrisolvibili.
  5. Segnali di Riproducibilità (S, peso 0,10): Segnali di determinismo come la gestione dei seed e l'ordine di esecuzione.
• Logica di Punteggio:
  • Funzione di Soglia: Una funzione di soglia a legge di potenza $g(x, \tau, k)$ penalizza in modo non lineare i punteggi al di sotto della soglia. I punteggi al di sotto di una soglia $\tau$ vengono compressi, riflettendo una politica di curatela secondo cui carenze gravi (ad esempio, specifica dell'ambiente mancante) sono sproporzionatamente dannose.
  • Penalità: Vengono applicate penalità severe per l'assenza completa di specifiche dell'ambiente o di artefatti di dati ($P_{hard}$), e per operazioni stocastiche senza gestione del seed ($P_{seed}$).
  • Formula: $RRS = 100 \cdot \sum (w_i \cdot g(x_i)) - \text{penalità}$.

Livello 2: Punteggio di Risultato della Riproducibilità (ROS)

Il ROS è una metrica opzionale basata sull'esecuzione, calcolata quando è disponibile un ambiente in sandbox (ad esempio, repo2docker, nbconvert).

• Componenti: Aggrega fino a sei sonde: successo dell'installazione ($I$), successo dell'esecuzione ($X$), determinismo dell'output ($\Delta$), tasso di esecuzione del notebook ($N$), tasso di successo degli import ($E'$) e tasso di passaggio dei test ($T$).
• Normalizzazione: Il ROS è una somma ponderata dei componenti disponibili, consentendo il calcolo del punteggio anche se sono disponibili solo dati di esecuzione parziali.

Punteggio Composito (RCS)

Il ReproScore Composito (RCS) fonde RRS e ROS in base alla quantità di prove di esecuzione raccolte.

• Peso di Copertura ($\alpha$): Un parametro che scala da 0 (nessuna esecuzione) a un massimo di 0,70. Garantisce che la prontezza statica non sia mai completamente dominata dai risultati dell'esecuzione, riconoscendo che un'esecuzione riuscita non convalida la documentazione o la portabilità.
• Formula: $RCS = (1 - \alpha) \cdot RRS + \alpha \cdot ROS$. Se non esistono dati di esecuzione, $RCS = RRS$.

Meccanismo di Rubrica della Comunità

ReproScore esternalizza le priorità di valutazione tramite un profilo YAML versionato. Ciò consente a diverse comunità (ad esempio, bioinformatica vs. software generale) di sovrascrivere i pesi predefiniti e le soglie di soglia senza modificare il codice sorgente. Questo rende le politiche di curatela esplicite, verificabili e portabili tra le istituzioni.

3. Contributi Chiave

1. Separazione Concettuale: Un'architettura formale a due livelli (RRS/ROS/RCS) che disaccoppia la prontezza statica dal risultato dell'esecuzione, affrontando la confusione prontezza-risultato nei flussi di lavoro delle biblioteche digitali.
2. Modello di Prontezza: Un modello a 5 categorie e 26 sub-metriche (RRS) con pesi informati da esperti, gating non lineare e provenienza delle prove a livello di file.
3. Meccanismo di Governance: Un sistema di rubrica della comunità che consente di definire le priorità di valutazione come artefatti citabili e versionati.
4. Validazione Empirica: Una valutazione su 423 repository GitHub (Python/Jupyter) che dimostra come la prontezza statica discrimini fortemente tra le modalità di fallimento ma mostri una correlazione vicina allo zero con il successo binario dell'esecuzione.

4. Risultati della Valutazione

Il framework è stato valutato su un campione stratificato di 423 repository provenienti da un corpus di verità fondamentale, categorizzati in cinque modalità di fallimento: Successo, Errori di Dipendenza di Installazione, Moduli Mancanti, Dati Mancanti ed Errori di Codice.

• Discriminazione delle Modalità di Fallimento: La categoria Ambiente (E) ha mostrato la maggiore capacità di discriminare tra le modalità di fallimento (Kruskal-Wallis $H = 96,89, p < 0,001$).
  • Il Paradosso della Rilevazione: I repository con errori di dipendenza di installazione (install_dep) hanno ottenuto i punteggi più alti nella categoria Ambiente (media 22,8) perché specificavano esplicitamente gli ambienti, ma fallivano a causa di conflitti di versione. Al contrario, i repository di successo hanno ottenuto punteggi più bassi (media 10,3) perché spesso mancavano di specifiche esplicite. Ciò conferma che il RRS caratterizza che tipo di problema esiste, non se avrà successo.
• Correlazione Binaria: La correlazione tra RRS e successo binario dell'esecuzione è vicina allo zero ($r_{pb} = -0,014$). Ciò quantifica empiricamente il divario prontezza-risultato: un alto punteggio statico non prevede un'esecuzione riuscita.
• Robustezza:
  • Stabilità dei Pesi: Le classifiche dei repository sono rimaste stabili ($\tau \ge 0,911$) anche quando i pesi sono stati perturbati del $\pm 50\%$.
  • Insensibilità della Soglia: La funzione di soglia ha avuto un impatto trascurabile sulla previsione binaria (intervallo AUC $\approx 0,008$), confermando il suo ruolo come strumento normativo di policy piuttosto che come meccanismo predittivo.
  • Leave-One-Category-Out: La rimozione delle categorie Ambiente o Dati ha effettivamente migliorato l'AUC binario, dimostrando ulteriormente che queste categorie sono progettate per caratterizzare i tipi di fallimento, non per prevedere il successo binario.
• Validazione Composita: Nella validazione parziale del ROS, l'RCS ha correttamente riproposto la classificazione dei repository. Ad esempio, i repository install_dep avevano un RRS moderato (26,8) ma un ROS vicino allo zero (13,5), risultando in un RCS basso (19,8), riflettendo accuratamente il loro fallimento nell'esecuzione nonostante la completezza statica.

5. Significato e Affermazioni

Il documento posiziona ReproScore come uno strumento diagnostico per i curatori delle biblioteche digitali piuttosto che come un predittore binario di successo.

• Necessità Architettonica: Lo studio convalida che separare la prontezza dal risultato è sia necessario che non banale. I segnali statici catturano differenze strutturali significative (ad esempio, distinguere un modulo mancante da un conflitto di versione) che le metriche di successo binario oscurano.
• Utilità Curatoriale: Fornendo un profilo a livello di categoria, ReproScore consente un rimedio mirato. Un punteggio Ambiente basso suggerisce la necessità di un fissaggio delle dipendenze; un punteggio Dati basso suggerisce puntatori mancanti. Questo è più azionabile di un singolo punteggio di "riproducibilità".
• Scalabilità: L'approccio basato prima sullo statico (RRS) consente alle biblioteche di triage milioni di depositi senza il costo computazionale dell'esecuzione in sandbox, riservando le risorse di esecuzione agli artefatti che mostrano promesse o richiedono una convalida specifica.
• Trasparenza delle Politiche: Il meccanismo di rubrica della comunità trasforma le euristiche di punteggio da codice opaco in politiche verificabili e citabili, facilitando il confronto interistituzionale e l'adattamento specifico di dominio (ad esempio, dando priorità all'accessibilità dei dati in bioinformatica).

Gli autori concludono che un framework che nomina esplicitamente il divario tra prontezza e risultato è più informativo per i flussi di lavoro di curatela rispetto a uno che li collassa. ReproScore fornisce l'infrastruttura per gestire questo divario, supportando le entità OAIS Ingest e Archival Storage con metriche calcolabili e scalabili.