Deep Learning per la localizzazione dei guasti. Innovazione nella verifica - Semiwiki

Deep Learning per la localizzazione dei guasti. Innovazione nella verifica – Semiwiki

Timestamp: 30 maggio 2023 9:00
Nodo di origine: 2689409

Un nuovo sguardo alla localizzazione e alla riparazione dei guasti nel debug utilizzando l'apprendimento basato su funzionalità semantiche profonde. Paul Cunningham (VP/GM senior, Verification presso Cadence), Raúl Camposano (Silicon Catalyst, imprenditore, ex CTO di Synopsys e ora CTO di Silvaco) e io continuiamo la nostra serie sulle idee di ricerca. Come sempre, feedback gradito.

Deep Learning per la localizzazione dei guasti

L'innovazione

La scelta di questo mese è Miglioramento della localizzazione degli errori e della riparazione dei programmi con funzionalità semantiche profonde e conoscenza trasferita. Gli autori hanno presentato l’articolo alla Conferenza internazionale sull’ingegneria del software del 2022 e provengono dall’Università Beihang di Pechino e dall’Università di Newcastle nel Nuovo Galles del Sud.

Il metodo va oltre le familiari tecniche di localizzazione basate sullo spettro (SBFL) e sulle mutazioni (MBFL) per utilizzare il deep learning da set di dati prequalificati di bug e correzioni confermate. L'aspetto della correzione è importante in questo caso perché dipende dalla localizzazione molto accurata di un guasto (infatti la localizzazione e la natura della correzione sono strettamente legate). Il documento utilizza le metriche SBFL e MBFL come input per il loro metodo di deep learning. Gli autori dimostrano che i loro metodi sono più efficaci degli approcci SBFL e MBFL selezionati e sostengono che ciò è dovuto al fatto che altri metodi non hanno alcuna comprensione semantica o solo una comprensione superficiale delle caratteristiche semantiche del progetto, mentre hanno intenzionalmente una comprensione più profonda.

Tuttavia, la riparazione completamente automatica potrebbe essere un passo eccessivo per il debug RTL correzioni suggerite sono già familiari per i controlli ortografici e grammaticali, suggerendo che questa funzionalità potrebbe essere utile anche nella verifica.

Il punto di vista di Paolo

Un anno dopo la nostra recensione di DeepFL, diamo uno sguardo a un altro articolo che tenta di spostare ulteriormente l'ago della bilancia. Il rilevamento automatico dei bug è ormai un argomento ricorrente tra i clienti Cadence e sono alte le aspettative che reti neurali profonde o modelli linguistici di grandi dimensioni possano essere utilizzati per migliorare notevolmente il tempo impiegato a causare bug.

DeepFL ha utilizzato un RNN per classificare il codice dei bug in base alle caratteristiche di sospettosità (basato sulla complessità, sulla mutazione, sullo spettro, sul testo). Il documento di questo mese aggiunge un ulteriore passaggio di corrispondenza del modello di bug come ulteriore funzionalità di input per migliorare la precisione. Il matcher del modello di bug è esso stesso un altro RNN che abbina le singole istruzioni di codice a uno o più degli 11 possibili modelli di bug, ad es. un controllo del puntatore null mancato, un cast di tipo errato, una posizione di istruzione errata o un operatore aritmetico errato.

Il contributo chiave dell'articolo per me è il set di dati che gli autori creano per addestrare la loro rete di corrispondenza dei modelli di bug. Estraggano l'intero repository github per trovare correzioni di bug reali che corrispondano ai loro modelli di bug. Per ogni corrispondenza richiedono che ci sia un'altra istruzione di corrispondenza altrove nello stesso file di codice sorgente che non faccia parte della correzione del bug, ovvero che il set di dati abbia corrispondenze sia positive che false positive. Il set di dati finale contiene circa 400,000 coppie di correzioni di bug positive/false positive. Carino!

Come con DeepFL, gli autori confrontano il loro strumento TRANSFER-FL utilizzando Defects4J. I risultati sembrano decenti: 171 dei 395 bug in Defects4J sono classificati tra i primi 5 da TRANSFER-FL contro 140 utilizzando DeepFL. Tuttavia, da un punto di vista commerciale 171 è ancora meno della metà del totale di 395 benchmark impostati. Se guardi la classifica media di tutti i 395 è 80, molto lontana dalla Top-5, quindi molto lontana dalla distribuzione commerciale. Non vedo l'ora di rivedere alcuni grandi documenti basati su modelli linguistici l'anno prossimo che spostano ulteriormente l'ago della bilancia 😊

Il punto di vista di Raull

Questo mese ci spostiamo nelle aree della localizzazione dei guasti e della riparazione automatica dei programmi per SW; l'articolo esaminato esplora queste tecniche per il codice Java. Nel maggio 2022 abbiamo esaminato DeepFL, che è simile a questo articolo in quanto estende le tradizionali tecniche basate sullo spettro e sulla mutazione per la localizzazione dei guasti con modelli di deep learning.

Per affermare in anticipo la mia conclusione, forse la localizzazione automatica degli errori RTL o SystemC e la riparazione del codice diventeranno routine nel prossimo futuro... Gli autori sono ottimisti riguardo all'applicabilità ad altri linguaggi, "la maggior parte dei modelli di correzione possono essere generalizzati ad altri linguaggi grazie alla rappresentazione generica di AST (Abstract Syntax Tree)” con l’avvertenza che devono essere disponibili dati sufficienti per addestrare le diverse reti utilizzate nel loro approccio. Per il documento del 2000 sono stati raccolti progetti Java open source da GitHub per costruirne 11 set di dati di localizzazione dei guasti con un totale di 392,567 campioni (dichiarazioni errate per 11 tipi di bug che hanno un commit di correzione del bug); e un set di dati di riparazione del programma con 11 categorie di correzioni di bug per un totale di 408,091 campioni, ciascun campione costituito da un'istruzione errata con il metodo contestuale e il corrispondente tipo di bug. Per eseguire questa corrispondenza viene utilizzato un AST.

L'approccio dettagliato, chiamato TRANSFER, è piuttosto complesso e richiede un po' di tempo per essere digerito, 67 riferimenti aiutano ad immergersi nei dettagli. Sfrutta gli approcci esistenti per la localizzazione dei guasti, 1) funzionalità basate sullo spettro che prendono il codice sorgente e i casi di test pertinenti come input e producono un elenco ordinato di elementi di codice ordinati in base ai punteggi di sospetto calcolati dall'esecuzione dei casi di test e 2) Basato sulla mutazione funzionalità che calcolano i punteggi di sospetto analizzando le modifiche dei risultati di esecuzione tra l'elemento di codice originale e i suoi mutanti. Aggiunge 3) funzionalità semantiche profonde ottenute utilizzando classificatori binari BiLSTM (memoria bidirezionale a lungo termine) addestrati con i set di dati di localizzazione degli errori. La riparazione del programma viene eseguita utilizzando un "messo a punto” multi-classificatore addestrato con il set di dati di riparazione del programma.

Il punto è che TRANSFER supera gli approcci esistenti, risolvendo con successo 47 bug (6 in più rispetto ai migliori approcci esistenti) sul benchmark Defects4J.

La scrittura e il debug del SW sono già assistiti regolarmente da IA ​​come GitHub Copilot; la progettazione dell'hardware, ovvero la scrittura di codice RTL o di livello superiore, non può essere troppo indietro, forse l'ostacolo più grande è la disponibilità dei dati richiesti.

Condividi questo post tramite:

Timestamp:

Di più da Semiwiki