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 Rezumat Modelele lingvistice mari (LLM) antrenate pe cod revoluționează procesul de dezvoltare software. Din ce în ce mai mult, LLM-urile de cod sunt integrate în mediile de dezvoltare software pentru a îmbunătăți productivitatea programatorilor umani, iar agenții bazați pe LLM încep să arate promisiuni în gestionarea sarcinilor complexe în mod autonom. Realizarea potențialului complet al LLM-urilor de cod necesită o gamă largă de capabilități, inclusiv generarea de cod, remedierea erorilor, explicarea și documentarea codului, întreținerea depozitelor de cod și multe altele. În această lucrare, introducem seria Granite de modele de cod decoder-only pentru sarcini generative de cod, antrenate cu cod scris în 116 limbaje de programare. Familia de modele Granite Code constă în modele cu dimensiuni cuprinse între 3 și 34 de miliarde de parametri, potrivite pentru aplicații de la sarcini complexe de modernizare a aplicațiilor până la cazuri de utilizare cu memorie limitată pe dispozitiv. Evaluarea pe un set cuprinzător de sarcini demonstrează că modelele Granite Code ating în mod constant performanțe de ultimă generație printre LLM-urile de cod open-source disponibile. Familia de modele Granite Code a fost optimizată pentru fluxurile de lucru de dezvoltare software enterprise și performează bine pe o gamă largă de sarcini de codificare (de exemplu, generare, remediere și explicare de cod), făcându-l un model de cod versatil „all-around”. Publicăm toate modelele noastre Granite Code sub licența Apache 2.0 atât pentru cercetare, cât și pentru uz comercial. https://github.com/ibm-granite/granite-code-models 1 Introducere În ultimele decenii, software-ul a fost țesut în structura fiecărui aspect al societății noastre. Pe măsură ce cererea pentru dezvoltarea de software crește, este mai important ca niciodată să creștem productivitatea dezvoltării de software, iar LLM-urile oferă o cale promițătoare pentru augmentarea programatorilor umani. Cazurile de utilizare enterprise proeminente pentru LLM-uri în productivitatea dezvoltării software includ generarea de cod, explicarea codului, remedierea codului, generarea de teste unitare și documentație, modernizarea aplicațiilor, detectarea vulnerabilităților, traducerea codului și multe altele. Ultimii ani au înregistrat un progres rapid în capacitatea LLM-urilor de a genera și manipula cod, iar o gamă de modele cu abilități impresionante de codificare sunt disponibile astăzi. Modelele variază ca dimensiune de la câteva miliarde de parametri (de exemplu, Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), etc.) până la sute de miliarde: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere) și variază în generalitatea utilizării intenționate, unele modele vizând o gamă de utilizări dincolo de cod, în timp ce altele se concentrează în principal pe sarcini legate de codificare (de exemplu, StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), și CodeGemma (CodeGemma Team et al., 2024)). Cu toate acestea, există încă lacune importante în domeniul actual al LLM-urilor pentru cod, în special în contextul dezvoltării software enterprise. În primul rând, în timp ce LLM-urile generaliste foarte mari pot atinge performanțe excelente de codificare, dimensiunea lor le face scumpe de implementat. Modelele mai mici, axate pe cod ( , ; , ; , ; , ; , ) pot atinge performanțe excelente de generare de cod într-un pachet mai mic și mai flexibil, dar performanța în sarcini de codificare dincolo de generare (de exemplu, remediere și explicare) poate fi inferioară performanței de generare de cod. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 În multe contexte enterprise, adoptarea LLM-urilor de cod poate fi complicată și mai mult de factori dincolo de performanța modelelor. De exemplu, chiar și modelele deschise sunt uneori afectate de lipsa transparenței cu privire la sursele de date și metodele de procesare a datelor care au stat la baza modelului, ceea ce poate eroda încrederea în modele în contexte critice și reglementate. Mai mult, termenii de licență în LLM-urile deschise de astăzi pot îngrădi și complica capacitatea unei companii de a utiliza un model. Aici, prezentăm modelele Granite Code, o serie de LLM-uri de cod extrem de capabile, concepute pentru a sprijini dezvoltarea software enterprise într-o gamă largă de sarcini de codificare. Modelele Granite Code au două variante principale pe care le lansăm în patru dimensiuni diferite (3B, 8B, 20B și 34B): modele fundamentale de bază pentru sarcini legate de cod; Granite Code Base: modele de urmărire a instrucțiunilor finetunate folosind o combinație de commit-uri Git asociate cu instrucțiuni umane și seturi de date sintetice de instrucțiuni de cod open-source. Granite Code Instruct: Modelele de bază din serie au fost antrenate de la zero cu o strategie de antrenament în două faze. În faza 1, modelul nostru este antrenat pe 3 până la 4 trilioane de tokeni proveniți din 116 limbaje de programare, asigurând o înțelegere cuprinzătoare a limbajelor de programare și a sintaxei. În faza 2, modelul nostru este antrenat suplimentar pe 500 de miliarde de tokeni cu un amestec atent conceput de date de înaltă calitate din domenii de cod și limbaj natural pentru a îmbunătăți capacitatea modelului de a raționa. Folosim obiectivul de modelare lingvistică nesupervizată pentru a antrena modelele de bază în ambele faze de antrenament. Modelele instruct sunt derivate prin finetunarea suplimentară a modelelor de bază antrenate mai sus pe o combinație a unei variante filtrate a CommitPack ( , ), seturi de date de urmărire a instrucțiunilor în limbaj natural (OASST ( , ), HelpSteer ( , )) și seturi de date matematice open-source (MathInstruct ( , ) și MetaMathQA ( , )), inclusiv seturi de date sintetice de cod pentru îmbunătățirea capacității de urmărire a instrucțiunilor și de raționament. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Efectuăm evaluări extinse ale LLM-urilor noastre de cod pe un set cuprinzător de benchmark-uri, inclusiv HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) și altele. Acest set de benchmark-uri cuprinde multe tipuri diferite de sarcini de codificare dincolo de simpla sinteză de cod în Python, de exemplu, remedierea codului, explicarea codului, editarea codului, traducerea codului etc., în majoritatea limbajelor de programare majore (Python, JavaScript, Java, Go, C++, Rust, etc.). Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 Descoperirile noastre relevă că, printre modelele open-source, modelele Granite Code prezintă în general performanțe foarte puternice pe toate dimensiunile modelelor și benchmark-urile (depășind adesea alte modele de cod open-source care sunt de două ori mai mari decât Granite). Ca o ilustrare, figura (sus) arată o comparație a Granite-8B-Code-Base cu alte LLM-uri de bază de cod open-source, inclusiv LLM-uri de bază generaliste performante recente precum Mistral ( , ) și LLama-3 ( , ) pe HumanEvalPack ( , ). În timp ce CodeGemma și StarCoder2 performează rezonabil în generarea de cod, ele performează semnificativ mai prost pe variantele de remediere și explicare a codului din HumanEvalPack. În medie, Granite-8B-Code-Base depășește cel mai competitiv model CodeGemma-8B cu aproape 12 puncte pe HumanEvalPack (33,2% vs. 21,3%), deși a fost antrenat pe un număr semnificativ mai mic de tokeni (4,5T vs. 7,5T tokeni). Pe lângă modelele de bază, variantele de instrucțiuni finetunate ale modelelor noastre Granite Code prezintă, de asemenea, performanțe puternice pe HumanEvalPack, depășind alte modele de instrucțiuni open-source (de cod), demonstrând beneficii pentru un set mai larg de sarcini de codificare cu instrucțiuni în limbaj natural (vezi figura (jos)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 În plus, deoarece raționamentul este critic pentru rezolvarea întrebărilor și sarcinilor complicate, testăm și modelul nostru Granite-8B-Code-Base pe șase benchmark-uri matematice, inclusiv MATH ( , ), GSM8K ( , ) și rezolvarea de probleme cu acces la instrumente computaționale, unde modelul nostru Granite 8B obține performanțe mai bune comparativ cu majoritatea LLM-urilor state-of-the-art de 7B sau 8B. De exemplu, Granite-8B-Code-Base depășește Llama-3-8B-Base cu ~12 puncte pe GSM8K și ~6 puncte pe MATH (vezi tabelul ). Cobbe et al. 2021 Cobbe et al. 2021 15 Avantajele cheie ale modelelor Granite Code includ: : Modelele Granite Code obțin performanțe competitive sau state-of-the-art pe diferite tipuri de sarcini legate de cod, inclusiv generarea de cod, explicarea, remedierea, editarea, traducerea etc., demonstrând capacitatea lor de a rezolva sarcini diverse de codificare; LLM de cod „all-rounder” : Toate modelele noastre sunt antrenate pe date permise licențier, colectate conform principiilor de etică AI ale IBM și ghidate de echipa juridică corporativă a IBM pentru utilizare enterprise de încredere. Toate modelele Granite Code sunt lansate sub licența Apache 2.0. LLM de grad enterprise de încredere 1 Descriem întregul nostru pipeline de colectare, filtrare și preprocesare a datelor în secțiunea . Secțiunea descrie detaliile arhitecturii modelului, urmate de detaliile de antrenament în Secțiunea . Secțiunea oferă detalii despre instrucțiunile de finetuning, iar Secțiunea descrie experimentele și rezultatele comparând modelele Granite Code cu alte LLM-uri open-source. 2 3 4 5 6 2 Colectarea Datelor În această secțiune, descriem procesul de crawling și filtrare (Sec. ), deduplicare (Sec. ), filtrare HAP/PII (Sec. ) utilizate pentru pregătirea datelor de cod pentru antrenamentul modelului. Oferim, de asemenea, o prezentare generală a datelor de limbaj natural de înaltă calitate utilizate pentru a îmbunătăți înțelegerea limbajului și abilitățile de raționament matematic ale modelului. 2.1 2.2 2.3 2.1 Crawling și Filtrarea Datelor Datele de preantrenament de cod au fost obținute dintr-o combinație de seturi de date disponibile public, cum ar fi Github Code Clean , StarCoderdata , și depozite de cod publice suplimentare și probleme de pe GitHub. Filtrăm datele brute pentru a reține o listă de 116 limbaje de programare din peste 300 de limbaje, așa cum este listat în Anexa . Atribuirea datelor limbajelor de programare se face exclusiv pe baza extensiei fișierului, similar cu StarCoder ( , ). După filtrarea limbajelor, aplicăm patru reguli cheie de filtrare pentru a elimina codul de calitate inferioară ( , ): (1) eliminăm fișierele cu mai puțin de 25% caractere alfabetice, (2) cu excepția limbajului XSLT, filtrăm fișierele unde șirul „<?xml version=” apare în primele 100 de caractere, (3) pentru fișierele HTML, păstrăm doar fișierele unde textul vizibil constituie cel puțin 20% din codul HTML și are o lungime minimă de 100 de caractere, (4) pentru fișierele JSON și YAML, păstrăm doar fișierele care au un număr de caractere cuprins între 50 și 5000 de caractere. De asemenea, filtrăm problemele GitHub folosind un set de metrici de calitate care includ eliminarea textului generat automat, filtrarea problemelor non-engleze, excluderea comentariilor de la boți și utilizarea numărului de utilizatori implicați în conversație ca indicator al calității. De asemenea, adnotăm fiecare fișier de cod cu informații de licență asociate cu depozitul respectiv, găsite prin API-urile GitHub și păstrăm doar fișierele cu licențe permisive pentru antrenamentul modelului. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Deduplicare Exactă și Fuzzy Adoptăm o strategie agresivă de deduplicare, incluzând atât deduplicarea exactă, cât și cea fuzzy, pentru a elimina documentele care au conținut de cod (aproape) identic în setul nostru de antrenament. Pentru deduplicarea exactă, calculăm mai întâi un hash SHA256 pe conținutul documentului și eliminăm înregistrările cu hash-uri identice. După deduplicarea exactă, aplicăm deduplicarea fuzzy cu scopul de a elimina fișierele de cod care pot avea variații ușoare și, prin urmare, de a de-biasa și mai mult datele. Aplicăm o metodă în doi pași pentru aceasta: (1) calculăm MinHash-urile tuturor documentelor și apoi utilizăm Hashing-ul Sensibil la Localizare (LSH) pentru a grupa documentele pe baza amprentelor lor MinHash, (2) măsurăm similaritatea Jaccard între fiecare pereche de documente din același grup și adnotăm documentele, cu excepția unuia, ca duplicate, pe baza unui prag de similaritate de 0.7. Aplicăm acest proces de pseudo-deduplicare la toate limbajele de programare, inclusiv problemele GitHub, pentru a spori bogăția și diversitatea setului de date de antrenament. 2.3 Filtrare HAP, PII, Malware Pentru a reduce probabilitatea generării de limbaj hateful, abuziv sau profan (HAP) de către modele, depunem eforturi diligente pentru a filtra conținutul HAP din setul de antrenament. Mai întâi creăm un dicționar de cuvinte cheie HAP și apoi adnotăm fiecare document de cod cu numărul de apariții ale unor astfel de cuvinte cheie în conținut, inclusiv comentarii. Filtrăm documentele care depășesc pragul HAP, calculat pe baza unei analize distribuționale, precum și a inspecției manuale a fișierelor de cod. Mai mult, pentru a proteja confidențialitatea, urmăm StarCoder ( , ) și depunem eforturi diligente pentru a redacta informațiile de identificare personală (PII) din setul de antrenament. În mod specific, utilizăm modelul StarPII pentru a detecta adrese IP, chei, adrese de e-mail, nume, nume de utilizator și parole găsite în conținut. Pasul de redactare a PII înlocuiește textul PII cu tokenii corespunzători NAME , EMAIL , KEY , PASSWORD și modifică adresa IP cu o adresă IP generată sintetic, ca în Li et al. (2023a). De asemenea, scanăm seturile noastre de date folosind pentru a identifica și elimina instanțele de malware din codul sursă. Li et al. 2023a 4 2.4 Seturi de Date în Limbaj Natural Pe lângă colectarea datelor de cod pentru antrenamentul modelului, curatoriem mai multe seturi de date de limbaj natural disponibile public de înaltă calitate pentru a îmbunătăți competența modelului în înțelegerea limbajului și raționamentul matematic. Seturile de date reprezentative din această categorie includ documente web (Stackexchange, CommonCrawl), text web matematic (OpenWeb-Math; ( ), StackMathQA; ( )), text academic (Arxiv, Wikipedia) și seturi de date de instrucțiuni de finetuning (FLAN; ( ), HelpSteer ( , )). Nu deduplicăm aceste seturi de date în limbaj natural deja preprocesate. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Arhitectura Modelului Antrenăm o serie de modele de cod de diferite dimensiuni bazate pe arhitectura transformer decoder ( , ). Hiperparametrii modelului pentru aceste modele sunt prezentați în Tabelul . Pentru toate arhitecturile de model, folosim pre-normalizare ( , ): normalizare aplicată intrării blocurilor de atenție și MLP. Vaswani et al. 2017 1 Xiong et al. 2020 : Cel mai mic model din familia de modele Granite-code este antrenat cu embedding RoPE ( , ) și Multi-Head Attention ( , ). Acest model utilizează funcția de activare swish ( , ) cu GLU ( , ) pentru MLP, cunoscută, de asemenea, sub denumirea de swiglu. Pentru normalizare, folosim RMSNorm ( , ), deoarece este mai eficient din punct de vedere computațional decât LayerNorm ( , ). Modelul 3B este antrenat cu o lungime de context de 2048 de tokeni. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : Modelul 8B are o arhitectură similară cu modelul 3B, cu excepția utilizării Grouped-Query Attention (GQA) ( , ). Utilizarea GQA oferă un compromis mai bun între performanța modelului și eficiența inferenței la această scară. Antrenăm modelul 8B cu o lungime de context de 4096 de tokeni. 8B Ainslie et al. 2023 : Modelul de cod 20B este antrenat cu embedding-uri de poziție absolută învățate. Folosim Multi-Query Attention ( , ) în timpul antrenamentului pentru o inferență eficientă downstream. Pentru blocul MLP, folosim funcția de activare GELU ( , ). Pentru normalizarea activărilor, folosim LayerNorm ( , ). Acest model este antrenat cu o lungime de context de 8192 de tokeni. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Pentru a antrena modelul 34B, urmăm abordarea lui pentru scalarea în profunzime a modelului 20B. Mai exact, duplicăm mai întâi modelul 20B cu 52 de straturi, apoi eliminăm ultimele 8 straturi din modelul original și primele 8 straturi din duplicatul său pentru a forma două modele. 34B Kim et al. În final, concatenăm ambele modele pentru a forma modelul Granite-34B-Code cu 88 de straturi (vezi Figura pentru o ilustrare). După scalarea în profunzime, observăm că scăderea performanței comparativ cu modelul 20B este destul de mică, contrar celor observate de Această performanță este recuperată destul de repede după ce continuăm preantrenamentul modelului scalat 34B. Similar cu modelul 20B, folosim un context de 8192 de tokeni în timpul preantrenamentului. 2 Kim et al. 4 Prentrenament În această secțiune, oferim detalii despre antrenamentul în două faze (Sec. ), obiectivele de antrenament (Sec. ), optimizarea (Sec. ) și infrastructura (Sec. ) utilizate în preantrenamentul modelelor. 4.1 4.2 4.3 4.4 4.1 Antrenament în Două Faze Modelele Granite Code sunt antrenate pe 3.5T până la 4.5T de tokeni de date de cod și seturi de date de limbaj natural legate de cod. Datele sunt tokenizate prin byte pair encoding (BPE, ( , )), utilizând același tokenizer ca StarCoder ( , ). Urmând ( , ; , ), utilizăm date de înaltă calitate cu două faze de antrenament, după cum urmează. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : În timpul fazei 1, atât modelele 3B, cât și 8B sunt antrenate pentru 4 trilioane de tokeni de date de cod, cuprinzând 116 limbi. Modelul cu 20B parametri este antrenat pe 3 trilioane de tokeni de cod. Modelul 34B este antrenat pe 1.4T tokeni după scalarea în profunzime, care se realizează pe checkpoint-ul de 1.6T al modelului 20B. Faza 1 (antrenament doar pe cod) • : În faza 2, includem date suplimentare de înaltă calitate disponibile public din diverse domenii, inclusiv documente tehnice, matematice și web, pentru a îmbunătăți în continuare performanța modelului în abilitățile de raționament și rezolvare de probleme, care sunt esențiale pentru generarea de cod. Antrenăm toate modelele noastre pentru 500B tokeni (80% cod și 20% date lingvistice) în faza 2 de antrenament. Faza 2 (antrenament cod + limbaj) 4.2 Obiectivul de Antrenament Pentru antrenamentul tuturor modelelor noastre, folosim obiectivul de modelare lingvistică cauzală și obiectivul Fill-In-the-Middle (FIM) ( , ). Obiectivul FIM are sarcina de a prezice tokenii inserați cu contextul dat și textul ulterior. Antrenăm modelele noastre să lucreze atât cu modurile PSM (Prefix-Suffix-Middle), cât și SPM (Suffix-Prefix-Middle), cu tokeni de control de formatare relevanți, la fel ca StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a Pierderea totală este calculată ca o combinație ponderată a celor 2 obiective: Setăm empir
