Immersione nell'IA: una serie di 3 episodi
Salve, sono Kevin Séjourné, dottore di ricerca in informatica e ingegnere senior di R&D presso Cloud Temple. Come potete immaginare, ho scritto molto codice negli ultimi 20 anni. Da appassionato esploratore di LLM, mi sono reso conto che ora possono scrivere codice per me. Tanto meglio! Ma poiché sono abituato a basarmi su osservazioni scientifiche, ho deciso di testare la qualità del loro lavoro.
Guarda i 3 episodi del mio studio:
- Episodio 1: Automatizzare il mio lavoro con gli LLM
- Episodio 2: Usare LLM per correggere il codice e ricostruire algoritmi dimenticati
- Episodio 3: Completamento del programma iniziale, test, test più severi
Episodio 1: Automatizzare il mio lavoro con gli LLM
I laureati in lettere possono ora scrivere codice per me. Vi mostrerò come. Cominciamo con un compito semplice e comune: riscrivere tutta o parte di un'applicazione.
Spesso il codice deve essere riscritto per :
- Affrontare l'obsolescenza
- Correzione di un'architettura inadeguata
- Aumentare le prestazioni
- Modificare il comportamento
- Passare a un altro linguaggio di programmazione
Da dove cominciamo?
Abbiamo scelto un piccolo programma, di soli 31 Kb, circa 1000 righe, in Python. Stiamo per affrontare alcune obsolescenze ed eliminare una parte del programma che è diventata inutile. A seguito di una modifica dei requisiti, questo programma aveva due possibili compiti da eseguire invece di uno. Gradualmente, il nuovo compito ha sostituito completamente il vecchio, che dovrebbe essere rimosso per ridurre la superficie di attacco. Stiamo rivedendo leggermente l'architettura e cercando di migliorare le prestazioni e le dipendenze moderne. La venerabile libreria request ha fatto il suo tempo.
Rust è un buon candidato per la riscrittura di un programma Pitone. La tipizzazione forte in fase di compilazione è il primo vantaggio della riscrittura di LLM. Essa costringerà a individuare precocemente i problemi di generazione dell'LLM, obbligandolo a generare in modo più logico. Questo attira l'attenzione dell'LLM su una dimensione aggiuntiva. Inoltre, Rust è un linguaggio moderno che gestisce bene la concomitanza, mentre Pitone è limitato dal blocco globale dell'interprete (GIL).
Abbiamo accesso senza limiti al GPT 4o tramite il portale AI sviluppato da Cloud Temple. In caso di dubbi su una risposta, possiamo usare groq.com con Llama3 70b e Mixtral 8x7b. Un Llama3-8b_q4 locale in esecuzione su jan.ai e un RTX è disponibile per le parti riservate.
Le capacità dei modelli utilizzati guidano la dimensione del programma da convertire. Mixtral gestisce contesti fino a 32 Kb, e anche se GPT/Gemmini si occupano di contesti più ampi, sono esposti a "perdersi nel mezzo", non riescono necessariamente a prestare attenzione alle informazioni presenti nel mezzo del loro contesto. Attualmente, un programma più pesante impedisce al LLM di concentrare la sua attenzione su tutte le parti del codice.
Utilizziamo VSCode per copiare e incollare il codice generato. Qui si aggregano tutte le parti del codice.
E ora cosa facciamo?
Come faccio a dire a LLM di convertire il mio codice? Come faccio a fornirgli il codice da convertire?
Costruire un prompt significa mantenere le cose semplici. E mantenere le cose semplici è complicato. Ecco il prompt: Facendo attenzione ai commenti e ai tipi di dati e a Cargo.toml, convertiamo il seguente programma Python in Rust:
[E sì, bisogna avere il coraggio di copiare e incollare 31 Kb nella casella di immissione del testo. Ma è la cosa più semplice da fare.
Abbiamo condotto esperimenti precedenti in cui il codice è stato copiato a pezzi. Ma ci sono alcune questioni spinose:
- Quanto sono grandi i pezzi? Quale file? Funzione? Classe? Quanti KB? Quante righe?
- In che ordine devono essere inserite le canzoni? Ordine alfabetico? Ordinamento topologico? Ordinamento funzionale? E le dipendenze incrociate?
Più semplice: tutto in una volta sola. Per fare questo, abbiamo esaminato tutti i file di programma e li abbiamo concatenati in un unico grande file. In questo grande file, sono separati da un comando del tipo FILE main.py :
[seguito dal corpo del file]
Specificare i file originali è essenziale in Python, perché il nome del file viene usato per risolvere le dipendenze in questo linguaggio. Inoltre, questo elemento costituisce un utile marcatore per attirare l'attenzione del modello su una parte specifica.
Il prompt si presenta come segue :
Quando inizia la generazione del codice?
Ecco cosa succede quando si preme [enter]:
Si può notare che GPT4o non è in grado di generare l'intero output. La lunghezza massima dell'output è stata raggiunta. Abbiamo ottenuto alcune funzioni dai primi file, ma manca ancora molto codice. Inoltre, il codice generato da GPT4o è spesso più prolisso di quello iniziale, in un rapporto di 3 a 2. Questo non dipende specificamente dal sistema Python. Questo non dipende specificamente dalla coppia Python/Rust, ma è piuttosto un artefatto della generazione del codice LLM. Come per le risposte umane, gli LLM sembrano avere problemi a dare risposte brevi.
Si può semplicemente chiedere al LLM di continuare:
Il problema è che finisce per perdersi in ciò che ha già elaborato e non ancora elaborato... 31 Kb di codice + 31 Kb * 1,5 codice previsto da generare + decoratori Markdown, abbiamo già raggiunto 64 Kb di contesto nel migliore dei casi. Purtroppo, chiedendogli di continuare senza alcun punto di riferimento reale, ha finito per convertire file già elaborati. I 64 KB scivolano e finiscono per superare la finestra di 128 KB di GPT4o, con conseguente perdita di contesto.
Partiamo dall'inizio. Questa volta, però, diciamo al prompt di convertire solo il primo file. Poi, una volta ottenuto il risultato, chiediamo il secondo file e così via. In questo modo, il LLM mantiene l'intero programma nel contesto dell'elaborazione dei riferimenti, ma concentra la sua attenzione solo su una trasformazione alla volta.
A poco a poco, possiamo copiare e incollare l'intero nuovo programma in VSCode. Se LLM è prolisso, gli umani devono essere concisi.
Chiedendo gentilmente, ottengo anche Cargo.toml, che è il file che gestisce le dipendenze e la compilazione in Rust. Non è un file molto complicato, ma la sua caratteristica principale è che non esiste affatto nel programma Python originale. È una piccola aggiunta che richiede un riassunto del programma precedente, come i riassunti che spesso vengono fatti dai LLM. È importante richiedere la generazione di questo file Cargo.toml dopo che sono stati generati i file di codice Rust, altrimenti l'LLM corre il rischio di omettere le librerie. All'inizio, l'LLM non ha ancora considerato tutto ciò di cui avrà bisogno.
Miracolosamente, il programma copia-incolla sembra pronto a funzionare con la tradizionale fiducia del LLM che ci assicura di avere la verità. Non è proprio così, perché, tra le altre cose, il programma non si compila. Per correggere questo problema, inizieremo a imparare... in un prossimo articolo.
Prima fase di revisione
Come avrete notato, con LLM abbiamo passato più tempo a pianificare quello che avremmo fatto e perché lo avremmo fatto, e meno tempo a generare codice. In questa fase, il tempo dedicato al progetto è di circa 8 ore, due delle quali dedicate alla generazione di codice.