The Pulse
Hugging Face propone i Model Integration Contracts per i test
Hugging Face ha proposto i Model Integration Contracts, piccole fixture eseguibili che consentono a Transformers di testare il comportamento dei modelli su CPU durante le pull request. La proposta arriva dopo un bug silenzioso nell’attenzio
AI.info Team · Scritto con l’IA · verificato ·
«L’LLM prepara la bozza; non la approva».
Tarek Ziadé, autore del post di Hugging Face
Il 3 novembre Hugging Face ha proposto i Model Integration Contracts, un metodo per testare il comportamento dei modelli nelle pull request di Transformers senza caricare checkpoint completi. I contratti abbinano una fixture ridotta del modello a un esempio eseguibile e a output attesi verificati da una persona, con l’obiettivo di individuare le regressioni su runner CPU poco costosi prima che il codice raggiunga il branch principale. La proposta è nata da un bug che consentiva a un modello linguistico di prestare attenzione ai token futuri durante l’addestramento, senza produrre un errore evidente.
Una regressione di UMT5 ha superato i controlli ordinari
Il 30 luglio, Transformers ha abilitato per T5 la scaled dot-product attention di PyTorch. La modifica ha anche consentito al decoder di UMT5 di vedere, durante l’addestramento, i token futuri: le risposte che avrebbe dovuto prevedere. Nulla si è bloccato e il difetto è rimasto nel branch principale del codice fino a una correzione del 28 settembre.
Hugging Face afferma che una piccola fixture di UMT5 eseguita su CPU ha segnalato il problema quando il team ha rieseguito precedenti commit del codice. Le differenze rilevate rispetto alla baseline verificata erano di 1,22 nelle log-probabilità delle etichette e di circa 0,20 nella loss di addestramento. Il test doveva usare il percorso della scaled dot-product attention: eseguendo soltanto la variante eager dell’attenzione, il bug non veniva rilevato.
L’episodio evidenzia un divario tra i test che confermano che un modello funziona e quelli che verificano se continua a comportarsi come previsto. Transformers supporta più di 750 tipi di modelli e il post del progetto conta oltre 88.000 test su CPU nel branch principale e più di 200.000 test su GPU in un’esecuzione giornaliera. Eseguire tutti i test di integrazione con checkpoint completi per ogni modifica proposta al codice richiederebbe una capacità di calcolo su GPU continuativa, quindi molti di questi controlli avvengono in un secondo momento.
Ogni contratto abbina una fixture a un compito reale
Un Model Integration Contract, o MIC, è composto da tre parti: una fixture più piccola costruita a partire dalla configurazione di un checkpoint reale, un esempio eseguibile in Markdown di un compito del modello e output di baseline verificati da una persona. La fixture preserva i diversi tipi di layer del modello e mantiene invariati i file del tokenizer e del processor. Se l’esempio non produce più le baseline registrate, il contratto fallisce.
Gli esempi sono pensati per verificare più del caricamento del modello e di un forward pass. L’esempio di SmolLM di Hugging Face genera token a partire da un prompt e li confronta con gli ID dei token registrati; i suoi controlli coprono anche la loss di addestramento, i gradienti finiti e la verifica che un passaggio dell’ottimizzatore modifichi i pesi. Un dataset sull’Hub vincola ogni contratto a una revisione fissa e registra le versioni dei pacchetti usate per produrre le relative baseline, dando alle esecuzioni CI un riferimento riproducibile.
In un caso sperimentale su UMT5, la fixture conteneva 66 megabyte di pesi, contro i 1.227 megabyte del checkpoint di origine. Dopo l’annullamento della correzione su un branch di prova, il contratto T5 selezionato è fallito come previsto; il passaggio del runner ha richiesto 13,4 secondi su CPU, esclusa la configurazione. Hugging Face afferma che le fixture forniscono un rapido segnale per le pull request, ma non sostituiscono i test sui checkpoint completi.
Hugging Face lascia il controllo CI non bloccante
Lo strumento a riga di comando tmic del progetto può preparare una bozza del contratto e costruire la relativa fixture. Un modello linguistico prepara la bozza del codice di utilizzo e del manifest, ma sono le persone a verificare i risultati attesi modificati prima dell’approvazione. Hugging Face afferma che il suo flusso di lavoro locale si interrompe prima di caricare qualsiasi elemento; la generazione della bozza iniziale per un nuovo modello usa Inference Providers ed è addebitata all’account dell’utente.
I limiti della proposta sono ancora in fase di valutazione. Al 1º novembre, il job MIC nella CI di Transformers segnalava i fallimenti ma non bloccava le pull request. Hugging Face afferma di dover ancora stabilire con quale frequenza i controlli individuino bug reali nelle modifiche in arrivo, con quale frequenza producano falsi allarmi e quanto tempo richiedano le verifiche delle baseline. Anche la copertura delle famiglie di modelli e dei percorsi di utilizzo più comuni è parziale.
Un esperimento separato su Whisper offre un motivo per essere cauti riguardo a ciò che le piccole fixture possono dimostrare. Le fixture con pesi casuali hanno individuato 18 dei 24 difetti inseriti; quelle addestrate su pochi esempi li hanno individuati tutti e 24, ma si trattava di difetti sintetici ed entrambi gli approcci non hanno rilevato un bug nella decodifica assistita emerso con il checkpoint reale di Whisper. La proposta di Hugging Face aggiunge quindi un livello di test anticipato, mantenendo i test sui checkpoint completi e la necessità di raccogliere le evidenze per decidere se i fallimenti dei MIC debbano bloccare una pull request.