Classifica Open LLM immersione profonda su DROP

La classifica dell'immersione profonda su DROP nella Open LLM

Recentemente, sono stati aggiunti tre nuovi benchmark alla Open LLM Leaderboard: Winogrande, GSM8k e DROP, utilizzando le implementazioni originali riprodotte nel EleutherAI Harness. Un’occhiata veloce ai punteggi di DROP ha rivelato qualcosa di strano: la stragrande maggioranza dei modelli otteneva un punteggio inferiore a 10 su 100 nel loro f1-score! Abbiamo approfondito per capire cosa stava succedendo, venite con noi per scoprire cosa abbiamo scoperto!

Osservazioni iniziali

DROP (Discrete Reasoning Over Paragraphs) è una valutazione in cui i modelli devono estrarre informazioni rilevanti da paragrafi in lingua inglese prima di eseguire passaggi di ragionamento discreti su di essi (ad esempio, ordinare o contare elementi per arrivare alla risposta corretta, vedere la tabella qui sotto per esempi). Le metriche utilizzate sono il punteggio f1 personalizzato e l’exact match.

L’abbiamo aggiunto alla Open LLM Leaderboard tre settimane fa e abbiamo osservato che i punteggi f1 dei modelli preaddestrati seguivano una tendenza inaspettata: quando abbiamo tracciato i punteggi di DROP rispetto alla media originale della leaderboard (di ARC, HellaSwag, TruthfulQA e MMLU), che è un proxy ragionevole per le prestazioni complessive del modello, ci aspettavamo che i punteggi di DROP fossero correlati ad esso (con modelli migliori che avevano prestazioni migliori). Tuttavia, questo era vero solo per un piccolo numero di modelli, mentre tutti gli altri avevano un punteggio f1 di DROP molto basso, inferiore a 10.

Interrogazioni di normalizzazione

Nel corso della nostra prima indagine più approfondita su questo comportamento sorprendente, abbiamo osservato che il passaggio di normalizzazione potrebbe non funzionare come previsto: in alcuni casi, questa normalizzazione ignorava le risposte numeriche corrette quando venivano seguite direttamente da un carattere di spazio bianco diverso da uno spazio (ad esempio un ritorno a capo). Guardiamo un esempio, con la generazione che è 10\n\nPassaggio: Il censimento del 2011 ha registrato una popolazione di 1.001.360, e la risposta corretta che è 10.

• Crea un’app di riconoscimento delle targhe utilizzando Streamlit
• Guidare l’impatto del prodotto con analisi praticabili
• Recensione di Circleboom il miglior strumento di social media alimentato da AI?

La normalizzazione avviene in diverse fasi, sia per la generazione che per la risposta corretta:

1. Separazione tramite separatori |, -, o .. La sequenza iniziale della generazione 10\n\nPassaggio: non contiene alcun separatore, ed è quindi considerata un’entità singola dopo questa fase.
2. Rimozione di punteggiatura Il primo token diventa quindi 10\n\nPassaggio (viene rimosso il :)
3. Omomogenizzazione dei numeri Qualsiasi stringa che può essere convertita in float viene considerata un numero e convertita in float, quindi nuovamente convertita in stringa. 10\n\nPassaggio rimane lo stesso, poiché non può essere convertito in float, mentre il valore corretto 10 diventa 10.0.
4. Altre fasi Seguono molte altre fasi di normalizzazione (rimozione di articoli, rimozione di altri spazi bianchi, ecc.) e il nostro esempio originale diventa 10 passaggio 2011.0 censimento registrato popolazione di 1001360.0.

Tuttavia, il punteggio complessivo non viene calcolato sulla stringa, ma sul bag of words (BOW) estratto dalla stringa, qui {'registrato', 'popolazione', 'passaggio', 'censimento', '2011.0', '1001360.0', '10'}, che viene confrontato con il BOW della risposta corretta, anch’esso normalizzato nel modo sopra descritto, {10.0}. Come puoi vedere, i due insiemi non si intersecano, anche se il modello ha previsto l’output corretto!

In sintesi, se un numero è seguito da qualsiasi tipo di spazio bianco diverso da uno spazio semplice, non passerà attraverso la normalizzazione dei numeri e quindi non corrisponderà mai alla risposta corretta se anche questa è un numero! Questo primo problema era probabilmente la causa di una significativa distorsione dei punteggi, ma chiaramente non era l’unico fattore che causava punteggi così bassi per DROP. Abbiamo deciso di indagare un po’ di più.

Approfondimento dei risultati

Allargando le nostre indagini, i nostri amici di Zeno si sono uniti a noi e hanno effettuato un’indagine molto più approfondita dei risultati, focalizzandosi su 5 modelli che rappresentavano i problemi che avevamo notato nei punteggi di DROP: falcon-180B e mistral-7B avevano una performance inferiore rispetto alle aspettative, Yi-34B e tigerbot-70B avevano ottime prestazioni su DROP correlate ai loro punteggi medi, e facebook/xglm-7.5B si posizionava a metà strada.

Puoi provare ad analizzare i risultati nel progetto Zeno qui, se vuoi!

Il team di Zeno ha scoperto due caratteristiche ancora più preoccupanti:

1. Nessun modello ha ottenuto un risultato corretto su risposte a virgola mobile
2. I modelli di alta qualità che generano risposte lunghe hanno effettivamente un punteggio f1 più basso

A questo punto, abbiamo creduto che entrambi i casi di insuccesso fossero causati dallo stesso fattore principale: l’utilizzo di . come token stopword (per terminare le generazioni):

1. Le risposte a virgola mobile vengono interrotte sistematicamente prima che la loro generazione sia completata
2. I modelli di alta qualità, che cercano di adattarsi al formato di prompt few-shot, genereranno Risposta\n\nPrompt plausibile per la prossima domanda., e si fermeranno solo durante la continuazione del prompt plausibile dopo la risposta effettiva sul primo ., generando quindi troppe parole e ottenendo un cattivo punteggio f1.

Abbiamo ipotizzato che entrambi questi problemi potessero essere risolti utilizzando \n invece di . come parola di fine generazione.

Cambiare il token di fine generazione

Allora abbiamo provato! Abbiamo esaminato l’uso di \n come token di fine generazione sui risultati disponibili. Abbiamo diviso la risposta generata sul primo \n contenuto, se presente, e ricalcolato i punteggi. Nota che questo è solo un’approssimazione del risultato corretto, poiché non correggerà le risposte che sono state tagliate troppo presto su . (ad esempio, risposte a virgola mobile) – ma allo stesso tempo non darà un vantaggio ingiusto a nessun modello, poiché tutti sono stati influenzati da questo problema. Tuttavia, è il meglio che potevamo fare senza eseguire nuovamente i modelli (poiché volevamo tenere la comunità informata il prima possibile).

I risultati che abbiamo ottenuto sono i seguenti: la divisione su \n correla molto bene con gli altri punteggi e quindi con le prestazioni complessive.

Quindi cosa faremo ora?

Un calcolo rapido mostra che eseguire nuovamente la valutazione completa di tutti i modelli sarebbe molto costoso (l’aggiornamento completo ha richiesto 8 anni di tempo GPU, e gran parte di esso è stato impiegato da DROP), quindi abbiamo stimato quanto costerebbe eseguire nuovamente solo gli esempi falliti.

Nel 10% dei casi, la risposta corretta è un numero decimale (ad esempio 12.25) e le previsioni del modello iniziano con l’inizio corretto (per il nostro esempio, 12) ma vengono interrotte su un . – queste previsioni probabilmente sarebbero state effettivamente corrette se la generazione fosse continuata. Dovremmo sicuramente eseguire nuovamente quelle previsioni! La nostra stima non tiene conto delle frasi generate che terminano con un numero che è stato eventualmente interrotto (il 40% delle altre generazioni), né di alcuna previsione compromessa dalla sua normalizzazione.

Per ottenere risultati corretti, dovremmo quindi eseguire nuovamente più del 50% degli esempi, una quantità enorme di tempo GPU! Dobbiamo essere certi che l’implementazione che eseguiremo sia corretta questa volta.

Dopo aver discusso con il fantastico team di EleutherAI (sia su GitHub sia internamente), che ci ha guidato attraverso il codice e ci ha aiutato nelle nostre indagini, è diventato molto chiaro che l’implementazione di LM Eval Harness segue molto strettamente il codice “DROP ufficiale”: quindi è necessario sviluppare una nuova versione di questa valutazione del benchmark! Pertanto abbiamo preso la decisione di rimuovere DROP dalla Open LLM Leaderboard fino a quando non ne verrà sviluppata una nuova versione.

Un insegnamento di questa indagine è il valore di avere tanti occhi della comunità che collaborano per investigare un benchmark al fine di individuare errori che erano passati inosservati in precedenza. Ancora una volta, il potere del software open-source, della comunità e dello sviluppo aperto si mostra nel consentire di indagare in modo trasparente la causa principale di un problema su un benchmark che è stato lì per un paio di anni.

Speriamo che i membri interessati della comunità si uniscano agli accademici che lavorano sulla valutazione di DROP per correggere sia il punteggio che la normalizzazione. Ci piacerebbe che diventi utilizzabile di nuovo, poiché il set di dati stesso è davvero molto interessante e geniale. Ti incoraggiamo a fornire feedback su come dovremmo valutare DROP su questa pagina.

Grazie ai molti membri della comunità che hanno segnalato problemi sui punteggi di DROP, e molti ringraziamenti ai team di EleutherAI Harness e Zeno per il loro grande aiuto su questa questione.