Evaluation-Strategy Gap in Fault Diagnosis of Deep Learning Programs

Sintesi Tecnica: Gap della Strategia di Valutazione nella Diagnosi dei Guasti di Programmi di Deep Learning

Definizione del Problema
I programmi di Deep Learning (DL) falliscono frequentemente durante l'addestramento a causa di errori di configurazione, bug di implementazione e instabilità numerica. Diagnosticare questi guasti è un compito di manutenzione costoso, solitamente affrontato con tecniche di analisi dinamica che apprendono da segnali di runtime (ad esempio, traiettorie della perdita, statistiche dei gradienti). Tuttavia, le pratiche di valutazione esistenti per queste tecniche si basano prevalentemente sulla cross-validazione intra-programma, in cui le esecuzioni dello stesso programma vengono suddivise tra i set di addestramento e di test. Questo approccio rischia di permettere ai classificatori di apprendere pattern strutturali specifici del programma piuttosto che semantiche di guasto generalizzabili. Di conseguenza, rimane poco chiaro quanto bene queste tecniche generalizzino su programmi non visti (deployment cross-programma) o quali caratteristiche di runtime (ad esempio, metriche standard rispetto a metriche basate sulla curvatura) rimangano efficaci in tali contesti.

Metodologia
Gli autori introducono DynFault, un corpus di 5.542 tracce di addestramento etichettate derivate da 38 distinti programmi di DL reali (FFNN, RNN, CNN). I guasti sono stati iniettati utilizzando operatori di mutazione che coprono sette categorie (ad esempio, iperparametri, configurazione degli strati, ottimizzatore). Lo studio confronta due strategie di valutazione:

1. Valutazione intra-programma: K-fold cross-validation stratificata in cui le esecuzioni dello stesso programma appaiono sia nei fold di addestramento che in quelli di test.
2. Valutazione con programma escluso (Program-held-out): K-fold cross-validation raggruppata dove interi programmi sono esclusi dal set di addestramento, simulando il deployment su codebase non viste.

Lo studio investiga tre compiti diagnostici:

• Classificazione del tipo di guasto: Predizione della categoria di mutazione.
• Triage dell'instabilità catastrofica: Rilevamento della divergenza numerica (loss > $10^6$).
• Rilevamento del mismatch Training/Validation (T/V): Identificazione di gap significativi tra l'accuratezza di training e quella di validation.

Sono state confrontate due configurazioni di feature di runtime:

• Feature di Curvatura (CF): Derivate da prodotti matrice-vettore dell'Hessiana (HVP), che catturano le proprietà del secondo ordine del paesaggio della perdita (loss landscape).
• Feature dell'Ottimizzatore (OF): Statistiche del gradiente del primo ordine, stati dell'ottimizzatore ed estremi delle attivazioni.

Il modello principale utilizzato è la Regressione Logistica (LR) per fornire una sonda lineare controllata delle rappresentazioni delle feature, con confronti effettuati contro classificatori Random Forest (RF) utilizzati nel lavoro precedente.

Contributi Chiave e Risultati

1. Quantificazione del Gap della Strategia di Valutazione (RQ1)
Lo studio identifica un significativo gap di performance tra le strategie di valutazione. Per il compito di diagnosi del tipo di guasto a quattro classi a $k=5$ epoche:

• Accuratezza bilanciata intra-programma: 0.469
• Accuratezza bilanciata con programma escluso: 0.279
• Gap: 0.190 (95% CI: [0.053, 0.258])

Esperimenti di controllo (predizione dell'identità del programma, permutazione delle etichette e normalizzazione per singolo programma) confermano che questo gap è guidato dalla struttura a livello di programma nelle feature. I classificatori addestrati sotto split intra-programma sfruttano firme uniche del programma invece della semantica del guasto. Quando le feature sono normalizzate per singolo programma, il vantaggio intra-programma scompare, ma la performance cross-programma rimane bassa, indicando che l'apprendimento di "scorciatoie" (shortcut learning) è la fonte primaria dei punteggi gonfiati intra-programma.

2. Generalizzabilità delle Feature di Runtime (RQ2 & RQ3)

• Rilevamento dell'instabilità: L'instabilità catastrofica avviene prevalentemente all'inizializzazione (il 96% delle esecuzioni instabili esplode all'epoca 0). Le feature di curvatura migliorano significativamente il rilevamento cross-programma dell'instabilità. L'aggiunta di CF a un modello baseline ha aumentato l'ROC-AUC da 0.918 a 0.977 a $k=1$ sotto valutazione con programma escluso. Una regola di clustering non supervisionata basata sulla geometria della curvatura all'epoca 0 ha raggiunto il 100% di precisione nel terminare esecuzioni instabili, sebbene con un basso richiamo (recall) su programmi non visti.
• Rilevamento del mismatch: Le feature dell'ottimizzatore e delle attivazioni migliorano sostanzialmente il rilevamento del mismatch T/V all'interno di un programma (ROC-AUC 0.899 $\to$ 0.971) ma degradano significativamente su programmi non visti (0.826 $\to$ 0.612), creando un gap di generalizzabilità di 0.285. Gli studi di ablazione delle feature rivelano che le statistiche di attivazione per singolo strato sono la fonte principale di queste scorciatoie specifiche del programma, poiché la loro rimozione restringe il gap. Al contrario, le sole metriche standard di loss e accuratezza forniscono la performance cross-programma più stabile.

3. Re-evaluazione delle Tecniche Esistenti (RQ4)
Gli autori hanno reimplementato quattro tecniche esistenti di diagnosi dei guasti (DeepFD, DEFault, AutoTrainer, DeepDiagnosis) su DynFault. Il gap della strategia di valutazione è stato osservato in tutte le tecniche basate sull'apprendimento. Ad esempio, utilizzando Random Forest, il gap si è ampliato a 0.34, suggerendo che classificatori con maggiore capacità catturano ancora più strutture specifiche del programma, gonfiando ulteriormente le stime di performance intra-programma.

Significatività e Implicazioni
L'articolo sostiene che la valutazione intra-programma sovrastima sostanzialmente la capacità diagnostica delle tecniche di diagnosi dei guasti DL per il deployment nel mondo reale. I risultati evidenziano un compromesso tra osservabilità e generalizzabilità: un logging più ricco (ad esempio, statistiche di attivazione) migliora le performance su programmi noti ma introduce scorciatoie non trasferibili.

Gli autori propongono tre implicazioni principali:

1. Allineare la validazione al deployment: Le affermazioni di capacità cross-programma richiedono una valutazione con programma escluso per evitare di sovrastimare le performance.
2. Valutare separatamente le configurazioni delle feature: Canali di logging aggiuntivi dovrebbero essere testati sotto valutazione raggruppata prima del deployment, poiché possono introdurre bias specifici del programma.
3. Monitorare l'instabilità all'inizializzazione: Le feature di curvatura offrono un segnale generalizzabile per il rilevamento precoce dell'instabilità, mentre le feature dell'ottimizzatore sono meno affidabili per la diagnosi cross-programma.

Lo studio conclude che, sebbene alcune informazioni correlate ai guasti siano generalizzabili, la dipendenza dai pattern di runtime specifici del programma nelle tecniche attuali richiede un cambiamento nei protocolli di valutazione e nel design delle feature per garantire la robustezza nei programmi DL non visti.