```html Autori: Mayank Mishra⋆, IBM Matt Stallone⋆, IBM Gaoyuan Zhang⋆, IBM Yikang Shen, IBM Aditya Prasad, IBM Adriana Meza Soria, IBM Michele Merler, IBM Parameswaran Selvam, IBM Saptha Surendran, IBM Shivdeep Singh, IBM Manish Sethi, IBM Xuan-Hong Dang, IBM Pengyuan Li, IBM Kun-Lung Wu, IBM Syed Zawad, IBM Andrew Coleman, IBM Matthew White, IBM Mark Lewis, IBM Raju Pavuluri, IBM Yan Koyfman, IBM Boris Lublinsky, IBM Maximilien de Bayser, IBM Ibrahim Abdelaziz, IBM Kinjal Basu, IBM Mayank Agarwal, IBM Yi Zhou, IBM Chris Johnson, IBM Aanchal Goyal, IBM Hima Patel, IBM Yousaf Shah, IBM Petros Zerfos, IBM Heiko Ludwig, IBM Asim Munawar, IBM Maxwell Crouse, IBM Pavan Kapanipathi, IBM Shweta Salaria, IBM Bob Calio, IBM Sophia Wen, IBM Seetharami Seelam, IBM Brian Belgodere, IBM Carlos Fonseca, IBM Amith Singhee, IBM Nirmit Desai, IBM David D. Cox, IBM Ruchir Puri†, IBM Rameswar Panda†, IBM Abstract I modelli linguistici di grandi dimensioni (LLM) addestrati sul codice stanno rivoluzionando il processo di sviluppo del software. Sempre più spesso, gli LLM di codice vengono integrati negli ambienti di sviluppo del software per migliorare la produttività dei programmatori umani, e gli agenti basati su LLM stanno iniziando a mostrare promesse per la gestione autonoma di compiti complessi. Per realizzare il pieno potenziale degli LLM di codice è necessaria un'ampia gamma di capacità, tra cui la generazione di codice, la correzione di bug, la spiegazione e la documentazione del codice, la manutenzione dei repository e altro ancora. In questo lavoro, introduciamo la serie Granite di modelli di codice solo decoder per attività generative di codice, addestrati con codice scritto in 116 linguaggi di programmazione. La famiglia di modelli Granite Code è composta da modelli di dimensioni variabili da 3 a 34 miliardi di parametri, adatti per applicazioni che vanno da complessi compiti di modernizzazione delle applicazioni a casi d'uso con vincoli di memoria sul dispositivo. La valutazione su un set completo di attività dimostra che i modelli Granite Code raggiungono costantemente prestazioni allo stato dell'arte tra gli LLM di codice open-source disponibili. La famiglia di modelli Granite Code è stata ottimizzata per i flussi di lavoro di sviluppo del software aziendale e funziona bene in una vasta gamma di attività di codifica (ad es. generazione, correzione e spiegazione del codice), rendendola un modello di codice versatile "tuttofare". Rilasciamo tutti i nostri modelli Granite Code con licenza Apache 2.0 sia per uso di ricerca che commerciale. https://github.com/ibm-granite/granite-code-models 1 Introduzione Negli ultimi decenni, il software è stato tessuto nel tessuto di ogni aspetto della nostra società. Poiché la domanda di sviluppo software aumenta, è più critico che mai aumentare la produttività dello sviluppo software, e gli LLM forniscono un percorso promettente per aumentare i programmatori umani. I casi d'uso aziendali di spicco per gli LLM nella produttività dello sviluppo software includono la generazione di codice, la spiegazione del codice, la correzione del codice, la generazione di test unitari e documentazione, la modernizzazione delle applicazioni, il rilevamento di vulnerabilità, la traduzione del codice e altro ancora. Negli ultimi anni si sono registrati rapidi progressi nella capacità degli LLM di generare e manipolare codice, e oggi sono disponibili una serie di modelli con impressionanti capacità di codifica. I modelli variano in dimensioni da pochi miliardi di parametri (ad es. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), ecc.) a centinaia di miliardi: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), e variano nella generalità dell'uso previsto, con alcuni modelli che mirano a coprire una gamma di usi al di fuori del codice, mentre altri si concentrano principalmente su attività relative alla codifica (ad es. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), e CodeGemma (CodeGemma Team et al., 2024)). Tuttavia, persistono importanti lacune nel campo attuale degli LLM per il codice, specialmente nel contesto dello sviluppo del software aziendale. In primo luogo, mentre gli LLM generalisti molto grandi possono ottenere eccellenti prestazioni di codifica, le loro dimensioni li rendono costosi da implementare. Modelli di codice più piccoli focalizzati ( , ; , ; , ; , ; , ) possono raggiungere eccellenti prestazioni di generazione di codice in un pacchetto più piccolo e flessibile, ma le prestazioni nelle attività di codifica oltre la generazione (ad es. correzione e spiegazione) possono essere inferiori alle prestazioni di generazione di codice. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 In molti contesti aziendali, l'adozione di LLM per il codice può essere ulteriormente complicata da fattori che vanno oltre le prestazioni dei modelli. Ad esempio, anche i modelli aperti sono talvolta afflitti da una mancanza di trasparenza riguardo alle fonti dei dati e ai metodi di elaborazione dei dati che sono entrati nel modello, il che può erodere la fiducia nei modelli in contesti critici e regolamentati. Inoltre, i termini di licenza negli LLM aperti odierni possono ostacolare e complicare la capacità di un'azienda di utilizzare un modello. Qui presentiamo i modelli Granite Code, una serie di LLM di codice altamente capaci, progettati per supportare lo sviluppo del software aziendale in un'ampia gamma di attività di codifica. I modelli Granite Code hanno due varianti principali che rilasciamo in quattro diverse dimensioni (3B, 8B, 20B e 34B): modelli fondazionali di base per attività relative al codice; Granite Code Base: modelli che seguono istruzioni, ottimizzati utilizzando una combinazione di commit Git accoppiati con istruzioni umane e dataset di istruzioni di codice sintetizzati open-source. Granite Code Instruct: I modelli di base della serie sono stati addestrati da zero con una strategia di addestramento in due fasi. Nella fase 1, il nostro modello è addestrato su 3-4 trilioni di token provenienti da 116 linguaggi di programmazione, garantendo una comprensione completa dei linguaggi di programmazione e della sintassi. Nella fase 2, il nostro modello è ulteriormente addestrato su 500 miliardi di token con un mix attentamente progettato di dati di alta qualità provenienti dai domini del codice e del linguaggio naturale per migliorare la capacità di ragionamento del modello. Utilizziamo l'obiettivo di modellazione del linguaggio non supervisionata per addestrare i modelli di base in entrambe le fasi di addestramento. I modelli instruct derivano dall'ulteriore fine-tuning dei modelli di base addestrati su una combinazione di una variante filtrata di CommitPack ( , ), dataset di istruzioni in linguaggio naturale (OASST ( , ), HelpSteer ( , )) e dataset di codice sintetizzati open-source per migliorare le capacità di seguire istruzioni e di ragionamento. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Conduciamo valutazioni approfondite dei nostri LLM di codice su un set completo di benchmark, tra cui HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ), e altro ancora. Questo set di benchmark comprende molti diversi tipi di attività di codifica oltre alla semplice sintesi di codice in Python, ad es. correzione del codice, spiegazione del codice, modifica del codice, traduzione del codice, ecc., nella maggior parte dei principali linguaggi di programmazione (Python, JavaScript, Java, Go, C++, Rust, ecc.). Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 I nostri risultati rivelano che, tra i modelli open-source, i modelli Granite Code mostrano prestazioni complessivamente molto elevate in tutti gli insiemi di modelli e benchmark (superando spesso altri modelli di codice open-source che sono due volte più grandi di Granite). Come illustrazione, la figura (in alto) mostra un confronto tra Granite-8B-Code-Base e altri LLM di codice di base open-source, inclusi recenti LLM di base generalisti ad alte prestazioni come Mistral ( , ) e LLama-3 ( , ) su HumanEvalPack ( , ). Mentre CodeGemma e StarCoder2 si comportano ragionevolmente bene nella generazione di codice, si comportano in modo significativamente peggiore nelle varianti di correzione e spiegazione del codice di HumanEvalPack. In media, Granite-8B-Code-Base supera il modello CodeGemma-8B più competitivo di quasi 12 punti su HumanEvalPack (33,2% contro 21,3%), pur essendo addestrato su un numero significativamente inferiore di token (4,5T contro 7,5T token). Oltre ai modelli di base, le varianti ottimizzate per le istruzioni dei nostri modelli Granite Code mostrano anche prestazioni elevate su HumanEvalPack, superando altri modelli instruct open-source (di codice), dimostrando i benefici per un set più ampio di attività di codifica con istruzioni in linguaggio naturale (vedi figura (in basso)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Inoltre, poiché il ragionamento è fondamentale per risolvere problemi e compiti complessi, testiamo anche il nostro modello Granite-8B-Code-Base su sei benchmark matematici, tra cui MATH ( , ), GSM8K ( , ) e problem solving con accesso a strumenti computazionali, dove il nostro modello Granite 8B ottiene prestazioni migliori rispetto alla maggior parte degli LLM all'avanguardia da 7B o 8B. Ad esempio, Granite-8B-Code-Base supera Llama-3-8B-Base di circa 12 punti su GSM8K e circa 6 punti su MATH (vedi tabella ). Cobbe et al. 2021 Cobbe et al. 2021 15 I principali vantaggi dei modelli Granite Code includono: i modelli Granite Code raggiungono prestazioni competitive o allo stato dell'arte su diversi tipi di attività relative al codice, tra cui generazione di codice, spiegazione, correzione, modifica, traduzione, ecc., dimostrando la loro capacità di risolvere diverse attività di codifica; LLM di codice tuttofare: tutti i nostri modelli sono addestrati su dati con licenza permissiva raccolti secondo i principi di etica AI di IBM e guidati dal team legale aziendale di IBM per un uso aziendale affidabile. Tutti i modelli Granite Code sono rilasciati con licenza Apache 2.0. LLM affidabile di livello enterprise: 1 Descriviamo l'intero processo di raccolta, filtraggio ed elaborazione dei dati nella sezione . La sezione descrive i dettagli dell'architettura del modello, seguiti dai dettagli di addestramento nella Sezione . La sezione fornisce i dettagli sull'ottimizzazione delle istruzioni, e la sezione descrive gli esperimenti e i risultati che confrontano i modelli Granite Code con altri LLM open-source. 2 3 4 5 6 2 Raccolta Dati In questa sezione, descriviamo il processo di crawling e filtraggio (Sez. ), deduplicazione (Sez. ), filtraggio HAP/PII (Sez. ) utilizzati per preparare i dati di codice per l'addestramento del modello. Forniamo inoltre una panoramica dei dati in linguaggio naturale di alta qualità utilizzati per migliorare la comprensione del linguaggio e le capacità di ragionamento matematico del modello. 2.1 2.2 2.3 2.1 Crawling e Filtraggio Dati I dati di codice pre-addestrato sono stati reperiti da una combinazione di dataset pubblicamente disponibili come Github Code Clean , StarCoderdata , e repository e issue pubbliche aggiuntive da GitHub. Filtriamo i dati grezzi per mantenere un elenco di 116 linguaggi di programmazione su oltre 300 lingue, come elencato nell'Appendice . L'assegnazione dei dati ai linguaggi di programmazione viene eseguita esclusivamente in base all'estensione del file, simile a StarCoder ( , ). Dopo il filtraggio linguistico, applichiamo quattro regole di filtraggio chiave per eliminare codice di bassa qualità ( , ): (1) rimuovere file con meno del 25% di caratteri alfabetici, (2) ad eccezione del linguaggio XSLT, filtrare i file in cui la stringa “<?xml version=” compare entro i primi 100 caratteri, (3) per i file HTML, mantenere solo i file in cui il testo visibile costituisce almeno il 20% del codice HTML e ha una lunghezza minima di 100 caratteri, (4) per i file JSON e YAML, mantenere solo i file che hanno un conteggio di caratteri compreso tra 50 e 5000 caratteri. Filtriamo anche le issue di GitHub utilizzando un set di metriche di qualità che includono la rimozione di testo generato automaticamente, il filtraggio di issue non in inglese, l'esclusione di commenti da bot e l'utilizzo del numero di utenti coinvolti nella conversazione come indicatore di qualità. Annotiamo anche ogni file di codice con informazioni di licenza associate al rispettivo repository, trovate tramite le API di Github e manteniamo solo i file con licenze permissive per l'addestramento del modello. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Deduplicazione Esatta e Fuzzy Adottiamo una strategia di deduplicazione aggressiva, inclusa la deduplicazione sia esatta che fuzzy, per rimuovere documenti con contenuto di codice (quasi) identico nel nostro set di addestramento. Per la deduplicazione esatta, calcoliamo prima l'hash SHA256 sul contenuto del documento e rimuoviamo i record con hash identici. Dopo la deduplicazione esatta, applichiamo la deduplicazione fuzzy con l'obiettivo di rimuovere file di codice che potrebbero presentare leggere variazioni e quindi ridurre ulteriormente il bias dei dati. Applichiamo un metodo in due fasi per questo: (1) calcolare i MinHash di tutti i documenti e quindi utilizzare il Locally Sensitive Hashing (LSH) per raggruppare i documenti in base alle loro impronte MinHash, (2) misurare la similarità Jaccard tra ogni coppia di documenti nello stesso bucket e annotare i documenti, tranne uno, come duplicati in base a una soglia di similarità di 0,7. Applichiamo questo processo di quasi-deduplicazione a tutti i linguaggi di programmazione, incluse le issue di GitHub, per migliorare la ricchezza e la diversità del dataset di addestramento. 2.3 Filtraggio HAP, PII, Malware Per ridurre la probabilità di generare linguaggio odioso, offensivo o profano (HAP) dai modelli, ci sforziamo diligentemente di filtrare i contenuti HAP dal set di addestramento. Creiamo innanzitutto un dizionario di parole chiave HAP e quindi annotiamo ogni documento di codice con il numero di occorrenze di tali parole chiave nel contenuto, inclusi i commenti. Filtriamo i documenti che superano la soglia HAP, calcolata sulla base di un'analisi distribuzionale e di un'ispezione manuale dei file di codice. Inoltre, per proteggere la privacy, seguiamo StarCoder ( , ) e ci sforziamo diligentemente di redigere le Informazioni Personalmente Identificabili (PII) dal set di addestramento. Nello specifico, sfruttiamo il modello StarPII per rilevare indirizzi IP, chiavi, indirizzi email, nomi, nomi utente e password trovati nel contenuto. Il passaggio di redazione PII sostituisce il testo PII con i token corrispondenti NAME , EMAIL , KEY , PASSWORD e modifica l'indirizzo IP con un indirizzo IP generato sinteticamente, come in Li et al. (2023a). Scansioniamo anche i nostri dataset per identificare e rimuovere istanze di malware nel codice sorgente. Li et al. 2023a 4 2.4 Dataset in Lingua Naturale Oltre alla raccolta di dati di codice per l'addestramento del modello, curiamo diversi dataset di alta qualità in lingua naturale pubblicamente disponibili per migliorare la competenza del modello nella comprensione del linguaggio e nel ragionamento matematico. Dataset rappresentativi di questa categoria includono documenti web (Stackexchange, CommonCrawl), testi matematici web (OpenWeb-Math; ( ), StackMathQA; ( )), testi accademici (Arxiv, Wikipedia), e dataset di ottimizzazione delle istruzioni (FLAN; ( ), HelpSteer ( , )). Non deduplichiamo questi dataset di lingua naturale già pre-elaborati. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Architettura del Modello Addestriamo una serie di modelli di codice di varie dimensioni basati sull'architettura transformer decoder ( , ). Gli iperparametri del modello per questi modelli sono riportati nella Tabella . Per tutte le architetture del modello, utilizziamo la pre-normalizzazione ( , ): normalizzazione applicata all'input dei blocchi di attenzione e MLP. Vaswani et al. 2017 1 Xiong et al. 2020 : Il modello più piccolo della famiglia di modelli Granite-code è addestrato con embedding RoPE ( , ) e Multi-Head Attention ( , ). Questo modello utilizza la funzione di attivazione swish ( , ) con GLU ( , ) per l'MLP, comunemente noto anche come swiglu. Per la normalizzazione, utilizziamo RMSNorm ( , ) poiché è computazionalmente più efficiente di LayerNorm ( , ). Il modello 3B è addestrato con una lunghezza di contesto di 2048 token. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : Il modello 8B ha un'architettura simile al modello 3B, con l'eccezione dell'utilizzo di Grouped-Query Attention (GQA) ( , ). L'utilizzo di GQA offre un miglior compromesso tra prestazioni del modello ed efficienza di inferenza a questa scala. Addestriamo il modello 8B con una lunghezza di contesto di 4096 token. 8B Ainslie et al. 2023 : Il modello di codice 20B è addestrato con embedding di posizione assoluti appresi. Utilizziamo Multi-Query Attention ( , ) durante l'addestramento per un'inferenza downstream efficiente. Per il blocco MLP, utilizziamo la funzione di attivazione GELU ( , ). Per normalizzare le attivazioni, utilizziamo LayerNorm ( , ). Questo modello è addestrato con una lunghezza di contesto di 8192 token. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Per addestrare il modello 34B, seguiamo l'approccio di per l'upscaling in profondità del modello 20B. Specificamente, duplichiamo prima il modello di codice 20B con 52 layer e quindi rimuoviamo gli ultimi 8 layer dal modello originale e i primi 8 layer dalla sua copia per formare due modelli. 34B Kim et al. Infine, concateniamo entrambi i modelli per formare il modello Granite-34B-Code con 88 layer (vedi Figura per un'illustrazione). Dopo l'upscaling in profondità, osserviamo che la diminuzione delle prestazioni rispetto al modello 20B è molto piccola, contrariamente a quanto osservato da . Questa prestazione viene recuperata abbastanza rapidamente dopo aver continuato il pre-addestramento del modello 34B upscalato. Similmente al 20B, utilizziamo un contesto di 8192 token durante il pre-addestramento. 2 Kim et al. 4 Pre-addestramento In questa sezione, forniamo dettagli sull'addestramento in due fasi (Sez. ), sugli obiettivi di addestramento (Sez. ), sull'ottimizzazione (Sez. ) e sull'infrastruttura (Sez. ) utilizzati nel pre-addestramento dei modelli. 4.1 4.2 4.3 4.4 4.1 Addestramento in Due Fasi I modelli Granite Code sono addestrati su 3,5T-4,5T token di dati di codice e dataset di linguaggio naturale relativi al codice. I dati vengono tokenizzati tramite byte pair encoding (BPE, ( , )), impiegando lo stesso tokenizer di StarCoder ( , ). Seguendo ( , ; , ), utilizziamo dati di alta qualità con due fasi di addestramento come segue. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Durante la fase 1, sia i modelli 3B che 8B sono addestrati per 4 trilioni di token di dati di codice comprendenti 116 lingue. Il modello da 20 miliardi di parametri è addestrato su 3 trilioni di token di codice. Il modello 34B è addestrato su 1,4T di token dopo l'upscaling in profondità che viene eseguito sul checkpoint da 1,6T del modello 20B. Fase 1 (addestramento solo codice) • : Nella fase 2, includiamo dati aggiuntivi di alta qualità disponibili pubblicamente da vari domini, tra cui documenti tecnici, matematici e web, per migliorare ulteriormente le prestazioni del modello nel ragionamento e nelle capacità di risoluzione dei problemi, essenziali per la generazione di codice. Addestriamo tutti i nostri modelli per 500B token (80% codice e 20% dati linguistici) nella fase 2 di addestramento. Fase 2 (addestramento codice + linguaggio) 4.2 Obiettivo di Addestramento Per l'addestramento di tutti i nostri modelli, utilizziamo l'obiettivo di modellazione del linguaggio causale e l'obiettivo Fill-In-the-Middle (FIM) ( , ). L'obiettivo FIM ha il compito di prevedere i token inseriti con il contesto dato e il testo successivo. Addestriamo i nostri modelli a lavorare sia in modalità PSM (Prefix-Suffix-Middle) che SPM (Suffix-Prefix-Middle), con token di controllo di formattazione pertinenti, come StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a La perdita complessiva è calcolata come una combinazione ponderata dei 2 obiettivi: Impostiamo empiricamente = 0,5 durante l'addestramento e scopriamo che questo funziona bene in pratica, portando a prestazioni SOTA sia nelle attività di completamento del codice che di riempimento del codice. Va notato che l'obiettivo FIM viene utilizzato solo durante il pre-addestramento, tuttavia lo rimuoviamo durante l'ottimizzazione delle istruzioni, cioè impostiamo = 1. α α 4.3 Ottimizzazione Utilizziamo l'ottimizzatore AdamW ([Kingma & Ba](#_bookmark80), [2017](#_bookmark80)) con β1 = 0,9, β2 = 0,95 e decadimento del peso di 0,1 per l'addestramento di tutti i nostri modelli Granite Code. Per il pre-addestramento di fase 1, il tasso di apprendimento segue un programma coseno partendo da 3 10−4 che decresce a 3 10−5 con un passo iniziale di riscaldamento lineare di 2k iterazioni. Per il pre-addestramento di fase 2, partiamo da 3 10−4 (1,5 10−4 per i modelli 20B e 34B) e adottiamo un programma di decadimento esponenziale per ridurlo al 10% del tasso di apprendimento iniziale. Utilizziamo una dimensione del batch di 4M-5M di token a seconda della dimensione del modello durante entrambe le fasi di pre-addestramento. Per accelerare l'addestramento, utilizziamo FlashAttention 2 ( , ; , ), il kernel di layernorm persistente, il kernel Fused RMSNorm (a seconda del modello) e il kernel Fused Adam disponibili nella . Utilizziamo un fork personalizzato di Megatron-LM di NVIDIA ( , ; , ) per l'addestramento distribuito di tutti i nostri modelli. Addestriamo con un mix di parallelismo 3D: parallelo tensoriale, parallelo pipeline e parallelo dati Dao et al. 2022 Dao 2023 libreria Apex di NVIDIA Shoeybi et al. 2019 Narayanan et al. 2021
