Le mie informazioni di contatto
Posta[email protected]
2024-08-14
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Rapporto sul cuore della macchina
Editore: Zhang Qian, Xiaozhou
Qualcuno ha detto: "Ci aspettavamo le fragole, ma hanno rilasciato il cavolo riccio. Vediamo a cosa serve questo "cavolo".
Le capacità di programmazione dei modelli di grandi dimensioni hanno sempre attirato molta attenzione e l'emergere del super potente programmatore di intelligenza artificiale Devin ha portato in primo piano il tema "L'intelligenza artificiale può sostituire i programmatori". Recentemente Devin ha anche introdotto un nuovo avversario: un programmatore di intelligenza artificiale indipendente lanciato dalla start-up CosineGenio. La società ha affermato che Genie ha facilmente sovraperformato Devin, segnando il 30% sul benchmark SWE di terze parti, mentre Devin ha ottenuto solo il 13,8%.
Questo SWE-Bench è un set di dati di riferimento utilizzato per valutare la capacità di LLM di risolvere problemi software reali su GitHub. Raccoglie 2.294 coppie Issue-Pull Request da 12 popolari repository Python. Durante il test, LLM riceverà una base di codice e una descrizione del problema, quindi genererà una patch per risolvere il problema descritto nel problema. Questo set di dati è stato ampiamente utilizzato nella valutazione delle capacità di programmazione dell’IA.
Man mano che le capacità di programmazione dell'intelligenza artificiale si evolvono, si evolve anche questo benchmark. Questa mattina presto, il modello OpenAI "Strawberry" segnalato online è stato nuovamente ritardato, ma OpenAI ha rilasciato qualcosa di nuovo, ovvero una versione migliorata di SWE-Bench - SWE-bench Verified.
OpenAI ha sottolineato che il banco SWE originale presentava alcuni problemi che potrebbero aver portato a sottovalutare le capacità di ingegneria del software autonomo del modello. Pertanto, durante il processo di miglioramento, hanno collaborato con gli autori originali di SWE-Bench per eseguire screening e miglioramenti manuali per garantire che l'ambito dei test unitari fosse appropriato e che la descrizione del problema fosse chiara.
Nei nuovi test condotti su SWE-bench Verified, molti agenti di programmazione AI hanno ottenuto punteggi più alti di prima. Tra questi, la soluzione Agentless dell'UIUC ha addirittura raddoppiato il punteggio. OpenAI ritiene che ciò dimostri che il benchmark precedente ha il difetto di sottovalutare le capacità di programmazione dell'IA.
Ma per gli utenti della rete di tutto il mondo che guardano "Strawberry", questa pubblicazione è ancora troppo superficiale. Qualcuno ha detto: "Ci aspettavamo le fragole, ma hanno rilasciato il cavolo riccio".
Conoscenza di base del banco SWE
Ogni esempio nel set di test del banco SWE è stato creato da un problema GitHub risolto in 12 repository di codice Python open source su GitHub. A ogni campione è associata una richiesta pull (PR) che include il codice della soluzione e test unitari per verificare la correttezza del codice. Questi test unitari sono chiamati test FAIL_TO_PASS perché falliscono prima che il codice della soluzione nel PR venga aggiunto e passano dopo che è stato aggiunto. Ogni esempio include anche test PASS_TO_PASS che vengono eseguiti prima e dopo l'unione del PR per verificare se il PR interrompe altre funzionalità nella codebase che non sono correlate al problema.
In SWE-bench, l'agente AI ottiene il testo originale dal problema di GitHub, che è la dichiarazione del problema, e ha accesso alla base di codice. Date queste informazioni, l'agente deve modificare i file nella codebase per risolvere il problema.
Le modifiche fornite dall'agente AI verranno valutate eseguendo i test FAIL_TO_PASS e PASS_TO_PASS. Se il test FAIL_TO_PASS viene superato, significa che l'editor ha risolto il problema. Se il test PASS_TO_PASS viene superato, significa che la modifica non ha interrotto parti estranee del codice base. Per risolvere completamente il problema originale di GitHub, è necessario superare entrambe le serie di test.
Tre direzioni di miglioramento per migliorare la robustezza e l'affidabilità del banco SWE
Al fine di migliorare la robustezza e l'affidabilità del banco SWE. Il team di sviluppo ha identificato tre principali direzioni di miglioramento:
SWE-bench verificato
Per risolvere questi problemi, OpenAI ha avviato una campagna di annotazioni manuali da parte di sviluppatori di software professionisti, esaminando ogni campione nel set di test SWE-bench per garantire che i test unitari avessero una portata adeguata e che le descrizioni dei problemi fossero chiare e inequivocabili.
Insieme agli autori di SWE-bench, hanno pubblicato SWE-bench Verified: un sottoinsieme del set di test originale di SWE-bench, contenente 500 campioni che sono stati verificati da annotatori umani. Questa versione sostituisce i set di test originali SWE-bench e SWE-bench Lite. Inoltre, stanno rilasciando annotazioni umane per tutti i campioni di test al banco SWE.
Hanno inoltre collaborato con gli autori di SWE-bench per sviluppare un nuovo strumento di valutazione per SWE-bench che utilizza un ambiente Docker containerizzato per rendere la valutazione su SWE-bench più semplice e affidabile.
Metodo di miglioramento
OpenAI ha collaborato con 93 sviluppatori di software con esperienza Python per esaminare manualmente i campioni del banco SWE e annotare 1699 campioni casuali nel set di test del banco SWE, ottenendo infine la verifica del banco SWE.
Il loro approccio consiste nell'annotare i campioni nel set di test al banco SWE per garantire l'equità e l'accuratezza del test. Nello specifico, si concentrano su due punti chiave: in primo luogo, valutare se la descrizione del problema è sufficientemente dettagliata da evitare che una descrizione eccessivamente vaga causi test ingiusti; in secondo luogo, verificare se lo unit test FAIL_TO_PASS filtrerà erroneamente le soluzioni valide;
Ogni criterio di annotazione ha un'etichetta nell'intervallo [0, 1, 2, 3] con gravità crescente. Le etichette 0 e 1 sono minori; le etichette 2 e 3 sono gravi, indicando che il campione è in qualche modo inadeguato e deve essere scartato.
Inoltre, OpenAI valuta la difficoltà di ciascun campione chiedendo agli annotatori di stimare quanto tempo impiegherebbero gli sviluppatori per decidere e implementare una soluzione, presupponendo che il campione sia privo di problemi. Infine, OpenAI fornisce un'opzione di input in formato libero per segnalare eventuali altri problemi importanti con l'esempio.
Per creare SWE-bench Verified, OpenAI filtra tutti i campioni dal set di test originale con una dichiarazione di problema o una gravità del test unitario FAIL_TO_PASS pari o superiore a 2 e filtra anche tutti i campioni contrassegnati con altri problemi gravi.
Annota i risultati
Secondo i nuovi standard, gran parte dei campioni nel banco SWE originale non sono qualificati. Come mostrato nella figura, il 38,3% dei campioni è stato contrassegnato perché l'enunciazione del problema non era sufficientemente chiara e il 61,1% è stato contrassegnato perché i test unitari potevano ingiustamente contrassegnare soluzioni valide come errate (Gravità 2, 3 La somma dei due livelli) . Nel complesso, il processo di annotazione ha comportato l'esclusione del 68,3% dei campioni del banco SWE a causa di dichiarazioni di problemi poco chiari, test unitari ingiusti o altri problemi.
La figura seguente confronta la distribuzione della difficoltà del set di dati SWE-bench originale e del nuovo set di dati SWE-bench Verified. Stimano la distribuzione della difficoltà del banco SWE sulla base di un sottoinsieme casuale di 1699 campioni.
Come si può vedere dalla figura, nel set di dati originale del banco SWE, il tempo stimato di completamento della maggior parte dei campioni (77,8%) è inferiore a un'ora di lavoro per un ingegnere del software esperto. SWE-bench Lite e il nuovo set di dati SWE-bench Verified aumentano ulteriormente questa percentuale, con meno del 10% dei problemi che dovrebbero richiedere più di un'ora per essere risolti. Tuttavia, i meccanismi alla base di questo cambiamento sono piuttosto diversi: SWE-bench Lite è un sottocampionamento del set di dati originale per rendere più semplice il benchmarking, mentre SWE-bench Verified tenta di rimuovere le funzionalità non realizzabili dal campione del set di dati.
Prestazioni verificate di ciascun agente sul banco SWE
Sul nuovo set di dati verificato di SWE-bench, il team di sviluppo ha testato le prestazioni di GPT-4o utilizzando più scaffold open source che hanno ottenuto buoni risultati nella classifica originale di SWE-bench.
È stato riscontrato che le prestazioni di GPT-4o sullo scaffold con le migliori prestazioni hanno raggiunto il 33,2% su SWE-bench Verified, più del doppio del punteggio del 16% sullo SWE-bench originale. Nel complesso, ciò conferma il sospetto iniziale di OpenAI che il banco SWE originale sottostimasse le capacità dell'agente.
Vale la pena notare che il passaggio da SWE-bench Lite a SWE-bench Verified non è così ovvio, perché dopo il filtraggio, SWE-bench Lite è già più semplice dell'intero set di dati.
Analisi della performance stratificata per difficoltà
Il miglioramento delle prestazioni valutate su SWE-bench Verified può essere in parte dovuto alla distribuzione dei campioni di prova sbilanciata verso campioni più semplici.
OpenAI ha studiato questo aspetto tracciando le prestazioni stratificate per difficoltà. Se il nuovo set di dati modifica semplicemente la distribuzione della difficoltà per includere campioni più semplici, la prestazione stratificata all'interno di ciascuna categoria non cambia, come nel caso dello SWE-bench originale allo SWE-bench Lite.
Al contrario, OpenAI ha osservato che le prestazioni dell'agente sono migliorate in tutte le categorie di difficoltà quando si passa a SWE-bench Verified, in linea con l'effetto atteso di rimuovere campioni impossibili da tutte le categorie anziché semplicemente spostare Rimuovi campioni difficili.
Link di riferimento: https://openai.com/index/introducing-swe-bench-verified/