Documentare dataset e modelli: datasheet, data statement e model card

Tre standard di documentazione si sono affermati per i dati di machine learning: data statement e datasheet per il dataset, model card per ciò che ci addestri sopra. Si sovrappongono parecchio e nessuno è facoltativo, se vuoi che i dati siano ritenuti affidabili e riutilizzati. Questa pagina è un riferimento su cosa copre ciascuno e quando conviene usarlo. Per un percorso narrativo su come scriverne uno, vedi il post di accompagnamento su come documentare il tuo dataset di annotazione; qui trovi il confronto tra gli standard.

Perché una documentazione strutturata e non un README

Un dataset annotato senza documentazione invecchia male. Sei mesi dopo nessuno sa più come è stato campionato, chi lo ha etichettato o cosa doveva significare un'etichetta, e i dati diventano una scatola nera di cui ci si fida alla cieca o che si butta via. Due costi ricorrono in particolare: l'irriproducibilità (senza metodo di campionamento, versione delle linee guida e composizione del pool di annotatori non puoi ricostruire il dataset né spiegare una discrepanza) e il bias nascosto (etichette prodotte da un pool ristretto e non documentato portano con sé punti ciechi che restano invisibili finché non emergono in produzione). I framework qui sotto servono a rendere leggibili il chi e il come prima che uno dei due presenti il conto.

I tre standard

Ogni framework si rivolge a un artefatto e a un pubblico diversi, ma sono stati pensati per incastrarsi.

I data statement (Bender e Friedman, 2018) sono lo schema specifico per l'NLP. Descrivono un dataset linguistico: motivazione della curatela, varietà di lingua e chi la parla, dati demografici degli annotatori, linee guida e uso previsto, così che chi legge possa giudicare quanto i risultati generalizzino e quali popolazioni siano sottorappresentate. Usa un data statement quando i dati sono testo e la varietà linguistica conta.

I datasheet per i dataset (Gebru et al., 2021) sono la versione generale, presa in prestito dall'elettronica, dove ogni componente viene fornito con la sua scheda tecnica. Pongono un insieme fisso di domande su motivazione, composizione, processo di raccolta, preprocessing, usi consigliati e manutenzione. Vanno bene per qualsiasi dataset di ML, testuale o no; si sovrappongono molto a un data statement, quindi su un dataset linguistico stai scegliendo attorno a quale insieme di domande organizzarti, non compilando entrambi da zero.

Le model card (Mitchell et al., 2019) documentano il modello, non i dati: l'uso previsto e, soprattutto, le prestazioni disaggregate per gruppi demografici e di altro tipo invece di un unico numero aggregato. È nella model card che un problema di equità diventa visibile.

I tre formano una catena. Un datasheet o un data statement documenta i dati; una model card documenta ciò che ci è stato costruito sopra; e la sezione sui dati demografici degli annotatori del primo è proprio ciò che rende interpretabile la valutazione per gruppi dell'ultima. Se documenti bene l'annotazione, sei già a buon punto verso una model card difendibile.

La riproducibilità è la quarta gamba

Documentazione e riproducibilità sono lo stesso obiettivo visto da due angolazioni. Pineau et al. (2021) hanno riferito sul programma di riproducibilità di NeurIPS e lo hanno condensato in una checklist di riproducibilità: riporta i dati esatti, i passi di raccolta e preprocessing, l'impianto di valutazione e abbastanza dettagli da poter rieseguire il lavoro. Per un progetto di annotazione i fatti critici sono proprio quelli che un datasheet già richiede: come sono stati campionati gli elementi, quale versione delle linee guida è stata usata, chi ha annotato e come è stato gestito il disaccordo. Se sai rispondere, il dataset è documentato e riproducibile; se non sai, è una lacuna da colmare prima del rilascio, non dopo.

Una checklist per il rilascio

Prima di pubblicare, verifica di saper rispondere a queste domande:

• Come sono stati campionati gli elementi, e da dove?
• Di quale varietà linguistica si tratta, e chi ha scritto il testo di partenza?
• Chi lo ha annotato, quante persone e qual è la composizione demografica del pool?
• Quali linee guida hanno seguito, e in quale versione?
• Il disaccordo è stato aggregato in un'etichetta gold o mantenuto come distribuzione? In entrambi i casi riporta l'accordo.
• A cosa serve questo dataset, e per cosa non andrebbe usato?

Come si fa in Potato

Gran parte della documentazione di un dataset esiste già come artefatto del progetto, quindi non parti dal foglio bianco. Il config è documentazione: il YAML registra gli schemi, gli insiemi di etichette e la struttura del task, sotto controllo di versione accanto ai dati, e le istruzioni che hai scritto sono già la sezione sulle linee guida. Se hai svolto una fase di prestudio, i dati demografici degli annotatori sono già memorizzati per annotatore: ti basta aggregarli in distribuzioni. E l'export mantiene annotatore e timestamp su ogni etichetta, così la provenienza viaggia insieme ai dati invece di andare persa:

{
  "id": "doc_001",
  "annotations": { "sentiment": "positive" },
  "annotator": "user_1",
  "timestamp": "2024-01-15T10:30:00Z"
}

Quando pubblichi sull'Hub, genera la dataset card come ultimo passo dell'export e compilane le sezioni partendo dal config, dalle linee guida e dai dati demografici del prestudio che hai già.

Approfondimenti

• Documentare il tuo dataset di annotazione, il percorso narrativo con un data statement svolto per intero.
• Raccogliere in modo responsabile i dati demografici degli annotatori, per fare bene la sezione sugli annotatori.
• Scrivere le linee guida di annotazione, che fanno anche da sezione sulle linee guida.
• Esportare le annotazioni per il machine learning, per tirare fuori etichette e metadati in modo pulito.