```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 nella gestione autonoma di compiti complessi. La realizzazione del pieno potenziale degli LLM di codice richiede una vasta 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 decoder-only per attività generative di codice, addestrati con codice scritto in 116 lingue di programmazione. La famiglia di modelli Granite Code è composta da modelli che vanno 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 all'avanguardia 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 offre buone prestazioni in una serie di attività di codifica (ad esempio, generazione, correzione e spiegazione del codice), rendendola un modello di codice versatile "tuttofare". Rilasciamo tutti i nostri modelli Granite Code sotto 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 intessuto nel tessuto di ogni aspetto della nostra società. Poiché la domanda di sviluppo del software è in aumento, è più critico che mai aumentare la produttività dello sviluppo del software, e gli LLM offrono un percorso promettente per aumentare i programmatori umani. I casi d'uso aziendali di spicco per gli LLM nella produttività dello sviluppo del 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. Gli ultimi anni hanno visto 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 singoli miliardi di parametri (ad esempio, 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 esempio, 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, rimangono importanti lacune nel campo attuale degli LLM per il codice, specialmente nel contesto dello sviluppo del software aziendale. In primo luogo, sebbene gli LLM generalisti molto grandi possano ottenere eccellenti prestazioni di codifica, le loro dimensioni li rendono costosi da implementare. Modelli più piccoli focalizzati sul codice ( , ; , ; , ; , ; , ) possono ottenere eccellenti prestazioni di generazione di codice in un pacchetto più piccolo e flessibile, ma le prestazioni nelle attività di codifica oltre la generazione (ad esempio, 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 di 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 sulle fonti dei dati e sui metodi di elaborazione dei dati che sono entrati nel modello, il che può erodere la fiducia nei modelli in contesti mission-critical e regolamentati. Inoltre, i termini di licenza degli LLM aperti odierni possono gravare 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 una vasta 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 base fondamentali per attività relative al codice; Granite Code Base: modelli che seguono istruzioni, affinati utilizzando una combinazione di commit Git accoppiati con istruzioni umane e dataset di istruzioni di codice sintetizzate open-source. Granite Code Instruct: I modelli base della serie sono stati addestrati da zero con una strategia di addestramento in due fasi. Nella fase 1, il nostro modello viene addestrato su 3-4 trilioni di token provenienti da 116 lingue di programmazione, garantendo una comprensione completa dei linguaggi di programmazione e della sintassi. Nella fase 2, il nostro modello viene ulteriormente addestrato su 500 miliardi di token con un mix attentamente progettato di dati di alta qualità dai domini del codice e del linguaggio naturale per migliorare la capacità di ragionamento del modello. Utilizziamo l'obiettivo di modellazione del linguaggio non supervisionato per addestrare i modelli base in entrambe le fasi di addestramento. I modelli instruct derivano dall'ulteriore affinamento dei modelli base addestrati sopra menzionati su una combinazione di una variante filtrata di CommitPack ( , ), dataset di istruzioni in linguaggio naturale (OASST ( , ), HelpSteer ( , )) e dataset matematici open-source (MathInstruct ( , ) e MetaMathQA ( , )), inclusi dataset di codice sintetizzati per migliorare le capacità di seguire istruzioni e di ragionamento. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu 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 tipi diversi di attività di codifica oltre alla semplice sintesi di codice in Python, ad esempio, correzione di codice, spiegazione di codice, modifica di codice, traduzione di codice, ecc., nella maggior parte delle principali lingue 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 Le nostre scoperte rivelano che tra i modelli open-source, i modelli Granite Code mostrano nel complesso prestazioni molto elevate su tutti i modelli e benchmark (spesso superando 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 base open-source, inclusi recenti LLM di uso generale ad alte prestazioni come Mistral ( , ) e LLama-3 ( , ) su HumanEvalPack ( , ). Mentre CodeGemma e StarCoder2 offrono prestazioni ragionevoli nella generazione di codice, offrono prestazioni significativamente inferiori nelle varianti di correzione e spiegazione del codice di HumanEvalPack. In media, Granite-8B-Code-Base supera il più competitivo modello CodeGemma-8B di quasi 12 punti su HumanEvalPack (33,2% contro 21,3%), nonostante sia stato addestrato su un numero significativamente inferiore di token (4,5T contro 7,5T token). Oltre ai modelli base, le varianti affinate con istruzioni dei nostri modelli Granite Code mostrano anche prestazioni elevate su HumanEvalPack, superando altri modelli di istruzione open-source (di codice), dimostrando i benefici per un set più ampio di attività di codifica con istruzioni in linguaggio naturale (vedere la figura (in basso)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Inoltre, poiché il ragionamento è fondamentale per risolvere domande 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 (vedere la 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 all'avanguardia su diversi tipi di attività relative al codice, tra cui generazione, 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 seguendo 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 sotto licenza Apache 2.0. LLM affidabile di livello aziendale 1 Descriviamo l'intera pipeline di raccolta, filtraggio ed elaborazione preliminare 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'affinamento 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 (Sezione ), deduplicazione (Sezione ), filtraggio HAP/PII (Sezione ) utilizzati per preparare i dati del codice per l'addestramento del modello. Forniamo anche 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 del codice di pre-addestramento sono stati raccolti da una combinazione di dataset pubblicamente disponibili come Github Code Clean , StarCoderdata , e repository di codice pubblici aggiuntivi e issue da GitHub. Filtriamo i dati grezzi per mantenere un elenco di 116 lingue di programmazione su oltre 300 lingue, come elencato nell'Appendice . L'assegnazione dei dati alle lingue 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 della lingua XSLT, filtrare file in cui la stringa “<?xml version=” appare entro i primi 100 caratteri, (3) per i file HTML, conservare solo 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, conservare solo file che hanno un conteggio di caratteri compreso tra 50 e 5000 caratteri. Annotiamo 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 inglesi, l'esclusione di commenti dai bot e l'uso del numero di utenti coinvolti nella conversazione come indicatore di qualità. Annotiamo inoltre ogni file di codice con informazioni sulla licenza associate al rispettivo repository, trovate tramite le API di Github e conserviamo 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 aggressiva di deduplicazione che include sia la deduplicazione esatta che quella 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 avere lievi variazioni e quindi rendere i dati ulteriormente imparziali. Applichiamo un metodo in due fasi per questo: (1) calcolare 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 tutte le lingue di programmazione, comprese le issue di GitHub, per migliorare la ricchezza e la diversità del set di dati di addestramento. 2.3 Filtraggio HAP, PII, Malware Per ridurre la probabilità di generare linguaggio odioso, offensivo o volgare (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 distributiva 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 NOME , EMAIL , CHIAVE , PASSWORD e cambia 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 linguaggio naturale Oltre alla raccolta di dati di codice per l'addestramento del modello, curiamo diversi dataset di linguaggio naturale di alta qualità disponibili pubblicamente per migliorare la competenza del modello nella comprensione del linguaggio e nel ragionamento matematico. I dataset rappresentativi in questa categoria includono documenti web (Stackexchange, CommonCrawl), testo web matematico (OpenWeb-Math; ( ), StackMathQA; ( )), testo accademico (Arxiv, Wikipedia) e dataset di affinamento delle istruzioni (FLAN; ( ), HelpSteer ( , )). Non deduplichiamo questi dataset di linguaggio 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 del decoder transformer ( , ). Gli iperparametri del modello per questi modelli sono riportati nella Tabella . Per tutte le architetture di 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'uso della Grouped-Query Attention (GQA) ( , ). L'uso di GQA offre un migliore 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 assoluta 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. Nello specifico, prima duplichiamo il modello 20B con 52 layer e poi 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 (vedere la Figura per un'illustrazione). Dopo l'upscaling in profondità, osserviamo che la diminuzione delle prestazioni rispetto al modello 20B è molto ridotta, contrariamente a quanto osservato da . Questa prestazione viene recuperata abbastanza rapidamente dopo aver continuato il pre-addestramento del modello 34B scalato. 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 (Sezione ), obiettivi di addestramento (Sezione ), ottimizzazione (Sezione ) e infrastruttura (Sezione ) utilizzate 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, ( , )), utilizzando 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, entrambi i modelli 3B e 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 da 34B è addestrato su 1,4T token dopo l'upscaling in profondità che viene eseguito sul checkpoint da 1,6T del modello da 20B. Fase 1 (addestramento solo codice) • : Nella fase 2, includiamo dati aggiuntivi di alta qualità disponibili pubblicamente da vari domini, inclusi documenti tecnici, matematici e web, per migliorare ulteriormente le prestazioni del modello nelle capacità di ragionamento e problem solving, 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 causale del linguaggio 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 (Prefisso-Suffisso-Mezzo) che SPM (Suffisso-Prefisso-Mezzo), 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 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 eliminiamo durante l'affinamento 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 addestrare tutti i nostri modelli Granite code. Per il pre-addestramento di fase 1, il tasso di apprendimento segue una pianificazione coseno che parte da 3 10−4 e decade a 3 10−5 con una fase 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 una pianificazione di decadimento esponenziale per ridurla al 10% del tasso di apprendimento iniziale. Utilizziamo una dimensione del batch di 4M-5M token a seconda della dimensione del modello durante entrambe le fasi di pre-addestramento. Per accelerare l'addestramento, utilizziamo FlashAttention 2 ( , ; , ), il kernel layernorm persistente, il kernel Fused RMSNorm (a seconda del modello) e il kernel Fused Adam disponibili nella libreria . Utilizziamo un fork personalizzato di Megatron-LM di NVIDIA ( , ; , ) per l'add Dao et al. 2022 Dao 2023 NVIDIA's Apex Shoeybi et al. 2019 Narayanan et al. 2021
