```html Outeurs: 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 Opsomming Groot Taalmodelle (LLMs) wat op kode opgelei is, is besig om die sagtewareontwikkelingsproses te verander. Al hoe meer word kodemodelle geïntegreer in omgewings vir sagtewareontwikkeling om die produktiwiteit van menslike programmeerders te verbeter, en LLM-gebaseerde agente begin belowend wees vir die hantering van komplekse take outonoom. Om die volle potensiaal van kodemodelle te verwesenlik, is 'n wye reeks vermoëns nodig, insluitend kodegenerering, foutiewe kode regstel, kode verduidelik en dokumenteer, repositories onderhou, en meer. In hierdie werk stel ons die Granite-reeks van dekoder-alleen kodemodelle bekend vir kodegenererende take, opgelei met kode geskryf in 116 programmeertale. Die Granite Kode-modellefamilie bestaan uit modelle wat wissel in grootte van 3 tot 34 miljard parameters, geskik vir toepassings wat wissel van komplekse toepassingmoderniseringstake tot geheuebeperkte gebruiksgevalle op toestelle. Evaluering op 'n omvattende stel take toon aan dat Granite Kode-modelle konsekwent die nuutste prestasie onder beskikbare oopbron-kodemodelle bereik. Die Granite Kode-model familie is geoptimaliseer vir ondernemingsagteware-ontwikkelingswerkvloeie en presteer goed oor 'n reeks kodetake (bv. kodegenerering, regstelling en verduideliking), wat dit 'n veelsydige "rondom" kodemodel maak. Ons stel al ons Granite Kode-modelle vry onder 'n Apache 2.0-lisensie vir beide navorsings- en kommersiële gebruik. https://github.com/ibm-granite/granite-code-models 1 Inleiding Oor die laaste paar dekades is sagteware in die weefsel van elke aspek van ons samelewing ingeweef. Soos die vraag na sagtewareontwikkeling toeneem, is dit van kritieke belang om sagtewareontwikkelingsproduktiwiteit te verhoog, en LLM's bied 'n belowende pad vir die aanvulling van menslike programmeerders. Prominente ondernemingsgebruiksgevalle vir LLM's in die produktiwiteit van sagtewareontwikkeling sluit in kodegenerering, kodeverklaring, kodeherstel, eenheidstoets- en dokumentasiegenerering, toepassingmodernisering, kwesbaarheidsdetectie, kodetranslasie, en meer. Die afgelope paar jaar was daar vinnige vooruitgang in LLM se vermoë om kode te genereer en te manipuleer, en 'n reeks modelle met indrukwekkende kodervaardighede is vandag beskikbaar. Modelle wissel in grootte van enkelsyfer miljarde parameters (bv. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), ens.) tot honderde miljarde: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), en verskil in die algemeenheid van beoogde gebruik, met sommige modelle wat daarop gemik is om 'n reeks gebruike buite kode te dek, terwyl ander hoofsaaklik op kodegerelateerde take fokus (bv. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), en CodeGemma (CodeGemma Team et al., 2024)). Daar is egter belangrike leemtes in die huidige veld van LLM's vir kode, veral in die konteks van ondernemingsagtewareontwikkeling. Eerstens, hoewel baie groot, algemene LLM's uitstekende kodeprestasie kan behaal, maak hul grootte dit duur om te ontplooi. Kleiner kode-gefokusde modelle ( , ; , ; , ; , ; , ) kan uitstekende kodegenerasieprestasie in 'n kleiner en meer buigsame pakket behaal, maar prestasie in kodetake behalwe generering (bv. regstelling en verduideliking) kan agter kodegenerasieprestasie bly. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 In baie ondernemingskontekste kan die aanvaarding van kodemodelle verder bemoeilik word deur faktore buite die prestasie van die modelle. Byvoorbeeld, selfs oop modelle word soms geteister deur 'n gebrek aan deursigtigheid oor die databronne en dataprosesseringsmetodes wat in die model gegaan het, wat vertroue in modelle in missiekritieke en gereguleerde kontekste kan ondermyn. Verder kan lisensieterme in vandag se oop LLM's 'n onderneming se vermoë om 'n model te gebruik, belemmer en bemoeilik. Hier bied ons Granite Kode-modelle aan, 'n reeks hoogs bekwame kodemodelle, ontwerp om ondernemingsagtewareontwikkeling oor 'n wye reeks kodetake te ondersteun. Granite Kode-modelle het twee hoofvariante wat ons in vier verskillende groottes vrystel (3B, 8B, 20B en 34B): basis modelle vir kodegerelateerde take; Granite Kode Basis: instruksievolgende modelle wat gefyn-tune is met 'n kombinasie van Git-omskrywings gepaard met menslike instruksies en oopbron sinteties gegenereerde kodestruksie-datastelle. Granite Kode Instruksie: Die basismodelle in die reeks is van voor af opgelei met 'n tweefase-opleidingsstrategie. In fase 1 word ons model op 3 tot 4 biljoen tokens uit 116 programmeertale opgelei, wat 'n omvattende begrip van programmeertale en sintaksis verseker. In fase 2 word ons model verder opgelei op 500 miljard tokens met 'n sorgvuldig ontwerpte mengsel van hoë-gehalte data uit kode- en natuurlike taal-domeine om die model se vermoë om te redeneer te verbeter. Ons gebruik die onbewaakte taalmodelleer-objektief om die basismodelle in beide fases van opleiding te oefen. Die instruksiemodelle word afgelei deur die bogenoemde opgeleide basismodelle verder op 'n kombinasie van 'n gefilterde variant van CommitPack ( , ), natuurlike taal-instruksievolgende datastelle (OASST ( , ), HelpSteer ( , )) en oopbron-wiskunde datastelle (MathInstruct ( , ) en MetaMathQA ( , )), insluitend sinteties gegenereerde kodestruksie-datastelle vir die verbetering van instruksievolging en redeneervermoëns, te fyn-tune. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Ons voer uitgebreide evaluasies van ons kodemodelle uit op 'n omvattende stel maatstawwe, insluitend HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ), en meer. Hierdie stel maatstawwe omvat baie verskillende soorte kodetake benewens net kod sintese in Python, bv. kode herstel, kode verduideliking, kode wysiging, kodetranslasie, ens., oor die meeste groot programmeertale (Python, JavaScript, Java, Go, C++, Rust, ens.). Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 Ons bevindinge toon aan dat, onder oopbronmodelle, die Granite Kode-modelle oor die algemeen baie sterk prestasie toon oor alle modelgroottes en maatstawwe (dikwels beter as ander oopbron-kodemodelle wat twee keer so groot is as Granite). As 'n illustrasie, figuur (bo) toon 'n vergelyking van Granite-8B-Code-Base met ander oopbron-basis kodemodelle, insluitend onlangse hoë-presterende algemene basis LLM's soos Mistral ( , ) en LLama-3 ( , ) op HumanEvalPack ( , ). Terwyl CodeGemma en StarCoder2 redelik goed presteer in die generering van kode, presteer hulle aansienlik swakker op die kodeherstel- en verduidelikingsvariante van HumanEvalPack. Gemiddeld presteer Granite-8B-Code-Base byna 12 punte beter as die mees mededingende CodeGemma-8B-model op HumanEvalPack (33.2% vs 21.3%), ondanks die feit dat dit opgelei is op aansienlik minder tokens (4.5T vs 7.5T tokens). Benewens basismodelle, toon die instruksie-tuned variante van ons Granite Kode-modelle ook sterk prestasie op HumanEvalPack, en presteer beter as ander oopbron (kode) instruksiemodelle, wat voordele vir 'n breër stel kodetake met natuurlike taal instruksies toon (sien figuur (onder)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Verder, aangesien redenering krities is vir die oplossing van ingewikkelde vrae en take, toets ons ook ons Granite-8B-Code-Base model op ses wiskunde-maatstawwe, insluitend MATH ( , ), GSM8K ( , ) en probleemoplossing met toegang tot rekenkundige gereedskap, waar ons Granite 8B-model beter prestasie behaal vergeleke met die meeste nuutste 7B of 8B LLM's. Byvoorbeeld, Granite-8B-Code-Base presteer ∼12 punte beter as Llama-3-8B-Base op GSM8K en ∼6 punte beter op MATH (sien tabel ). Cobbe et al. 2021 Cobbe et al. 2021 15 Die sleutelvoordele van Granite Kode-modelle sluit in: : Granite Kode-modelle behaal mededingende of nuutste prestasie op verskillende soorte kodegerelateerde take, insluitend kodegenerering, verduideliking, regstelling, wysiging, translasie, ens., wat hul vermoë demonstreer om diverse kodetake op te los; All-rounder Kode LLM : Al ons modelle is opgelei op lisensie-toelaatbare data wat versamel is volgens IBM se AI-etiekbeginsels en gelei deur IBM se Korporatiewe Regspan vir betroubare ondernemingsgebruik. Al die Granite Kode-modelle word vrygestel onder die Apache 2.0-lisensie. Betroubare Ondernemingsgraad LLM 1 Ons beskryf ons volledige datainsameling, filtering en voorverwerkingspyplyn in afdeling . Afdeling beskryf die besonderhede van die modelargitektuur, gevolg deur opleidingsdetails in Afdeling . Afdeling verskaf die besonderhede oor instruksie-tuning, en Afdeling beskryf die eksperimente en resultate wat Granite Kode-modelle met ander oopbron LLM's vergelyk. 2 3 4 5 6 2 Data-insameling In hierdie afdeling beskryf ons die proses van kruip en filter (Sec. ), deduplikasie (Sec. ), HAP/PII-filtering (Sec. ) wat gebruik is om die kodedata vir modelopleiding voor te berei. Ons verskaf ook 'n oorsig van hoë-gehalte natuurlike taaldata wat gebruik is om die model se taalbegrip en wiskundige redeneervaardighede te verbeter. 2.1 2.2 2.3 2.1 Data Kruip en Filtrering Die voorgeskrewe kodedata is verkry uit 'n kombinasie van publiek beskikbare datastelle soos Github Code Clean , StarCoderdata , en bykomende publieke koderepositories en uitgawes van GitHub. Ons filter rou data om 'n lys van 116 programmeertale uit meer as 300 tale te behou, soos uiteengesit in Bylae . Die toekenning van data aan programmeertale word slegs gedoen op grond van lêeruitbreiding, soortgelyk aan StarCoder ( , ). Na taalfiltrering, pas ons vier sleutelfiltreringsreëls toe om kode van laer gehalte uit te filter ( , ): (1) verwyder lêers met minder as 25% alfabetiese karakters, (2) behalwe vir die XSLT-taal, filter lêers uit waar die string “<?xml version=” binne die eerste 100 karakters verskyn, (3) vir HTML-lêers, hou slegs lêers waar die sigbare teks minstens 20% van die HTML-kode uitmaak en 'n minimum lengte van 100 karakters het, (4) vir JSON- en YAML-lêers, hou slegs lêers met 'n karaktertelling tussen 50 en 5000 karakters. Ons filter ook GitHub-uitgawes met behulp van 'n stel kwaliteitsmetrieke wat die verwydering van outomaties gegenereerde teks insluit, die filtering van nie-Engelse uitgawes, die uitsluiting van opmerkings van bots, en die gebruik van die aantal gebruikers wat betrokke is by die gesprek as 'n aanduiding van kwaliteit. Ons annoteer ook elke kodelêer met lisensie-inligting wat verband hou met die onderskeie repository, gevind via GitHub API's en hou slegs lêers met permitte lisensies vir modelopleiding. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Eksakte en Foutiewe Deduplikasie Ons gebruik 'n aggressiewe deduplikasie strategie, insluitend beide eksakte en foutiewe deduplikasie, om dokumente met (naby) identiese kodeginhoud in ons opleidingsstel te verwyder. Vir eksakte deduplikasie bereken ons eers SHA256-hashes op die dokumentinhoud en verwyder rekords met identiese hashes. Na eksakte deduplikasie, pas ons foutiewe deduplikasie toe met die doel om kodlêers te verwyder wat effense variasies mag hê en sodoende die data verder onbevooroordeeld maak. Ons gebruik 'n tweestap-metode hiervoor: (1) bereken MinHashes van al die dokumente en gebruik dan Locally Sensitive Hashing (LSH) om dokumente te groepeer op grond van hul MinHash-vingerafdrukke, (2) meet Jaccard-soortgelykheid tussen elke paar dokumente in dieselfde bucket en annoteer dokumente behalwe een as duplikate gebaseer op 'n soortgelykheid-drempel van 0.7. Ons pas hierdie naby-deduplikasieproses toe op alle programmeertale, insluitend GitHub-uitgawes, om die rykheid en diversiteit van die opleidingsdatastel te verbeter. 2.3 HAP, PII, Malware Filtrering Om die waarskynlikheid van die generering van haatlike, beledigende of beledigende (HAP) taal uit die modelle te verminder, doen ons noukeurige pogings om HAP-inhoud uit die opleidingsstel te filter. Ons skep eers 'n woordeboek van HAP-sleutelwoorde en annoteer dan elke kod dokument met die aantal voorkomste van sulke sleutelwoorde in die inhoud, insluitend opmerkings. Ons filter dokumente wat die HAP-drempel oorskry, bereken op grond van 'n distributiewe analise asook handmatige inspeksie van kodlêers. Verder, om privaatheid te beskerm, volg ons StarCoder ( , ) en doen noukeurige pogings om Persoonlik Identifiseerbare Inligting (PII) uit die opleidingsstel te redigeer. Spesifiek, ons gebruik die StarPII -model om IP-adresse, sleutels, e-posadresse, name, gebruikersname en wagwoorde wat in die inhoud gevind word, op te spoor. Die PII-redigeringsstap vervang die PII-teks met die ooreenstemmende tokens NAME, EMAIL, KEY, PASSWORD en verander die IP-adres met 'n sinteties gegenereerde IP-adres, soos in Li et al. (2023a). Ons skandeer ook ons datastelle met om gevalle van malware in die bronkode te identifiseer en te verwyder. Li et al. 2023a 4 2.4 Natuurlike Taal Datastelle Benewens die versameling van koddata vir modelopleiding, kurateer ons verskeie publiek beskikbare hoë-gehalte natuurlike taal datastelle vir die verbetering van die model se vaardigheid in taalbegrip en wiskundige redenering. Verteenwoordigende datastelle onder hierdie kategorie sluit in webdokumente (Stackexchange, CommonCrawl), wiskundige webteks (OpenWeb-Math; ( ), StackMathQA; ( )), akademiese teks (Arxiv, Wikipedia), en instruksie-tuning datastelle (FLAN; ( ), HelpSteer ( , )). Ons dedupliseer hierdie reeds voorverwerkte natuurlike taal datastelle nie. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Model Argitektuur Ons oefen 'n reeks kodemodelle van verskillende groottes gebaseer op die transformer-dekoderargitektuur ( , ). Die modelhiperparameters vir hierdie modelle word in Tabel gegee. Vir alle modelargitekture gebruik ons pre-normalisering ( , ): normalisering toegepas op die inset van aandag- en MLP-blokke. Vaswani et al. 2017 1 Xiong et al. 2020 : Die kleinste model in die Granite-kode-model familie word opgelei met RoPE-inbedding ( , ) en Multi-Head Attention ( , ). Hierdie model gebruik die swish aktiveringsfunksie ( , ) met GLU ( , ) vir die MLP, ook algemeen verwys as swiglu. Vir normalisering gebruik ons RMSNorm ( , ) aangesien dit berekeningsmatig doeltreffender is as LayerNorm ( , ). Die 3B-model word opgelei met 'n kontekslengte van 2048 tokens. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : Die 8B-model het 'n soortgelyke argitektuur as die 3B-model, met die uitsondering dat Groep-Gekykde Aandag (GQA) gebruik word ( , ). Die gebruik van GQA bied 'n beter afweging tussen modelprestasie en inferensiedoeltreffendheid op hierdie skaal. Ons oefen die 8B-model met 'n kontekslengte van 4096 tokens. 8B Ainslie et al. 2023 : Die 20B-kodemodel word opgelei met geleerde absolute posisie-inbeddings. Ons gebruik Multi-Query Attention ( , ) tydens opleiding vir doeltreffende afwaartse inferensie. Vir die MLP-blok gebruik ons die GELU-aktiveringsfunksie ( , ). Vir die normalisering van die aktiverings gebruik ons LayerNorm ( , ). Hierdie model word opgelei met 'n kontekslengte van 8192 tokens. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Om die 34B-model op te lei, volg ons die benadering deur vir diepte-opskaal van die 20B-model. Spesifiek, ons verdubbel eers die 20B-kodemodel met 52 lae en verwyder dan die laaste 8 lae van die oorspronklike model en die eerste 8 lae van sy duplikaat om twee modelle te vorm. 34B Kim et al. Uiteindelik voeg ons albei modelle saam om die Granite-34B-Code-model met 88 lae te vorm (sien Figuur vir 'n illustrasie). Na die diepte-opskaal, neem ons waar dat die prestasieverlies vergeleke met die 20B-model baie klein is, anders as wat waargeneem word deur Hierdie prestasie word redelik vinnig herstel nadat ons die voorgeskrewe opleiding van die opgeskaalde 34B-model voortgesit het. Soortgelyk aan die 20B, gebruik ons 'n 8192-token konteks tydens voorgeskrewe opleiding. 2 Kim et al. 4 Voorgeskrewe Opleiding In hierdie afdeling verskaf ons besonderhede oor tweefase-opleiding (Sec. ), opleidingsdoelstellings (Sec. ), optimering (Sec. ) en infrastruktuur (Sec. ) wat gebruik is in die voorgeskrewe opleiding van die modelle. 4.1 4.2 4.3 4.4 4.1 Twee Fase Opleiding Granite Kode-modelle word opgelei op 3.5T tot 4.5T tokens van koddata en natuurlike taal datastelle wat verband hou met kode. Data word getokeniseer via byte pair encoding (BPE, ( , )), wat dieselfde tokenizer as StarCoder ( , ) gebruik. Volgens ( , ; , ), gebruik ons hoë-gehalte data met twee fases van opleiding soos volg. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Tydens fase 1 word beide 3B- en 8B-modelle vir 4 biljoen tokens koddata wat 116 tale insluit, opgelei. Die 20B-parameter model word op 3 biljoen tokens kode opgelei. Die 34B-model word op 1.4T tokens opgelei na die diepte-opskaal wat gedoen word op die 1.6T-kontrolepunt van die 20B-model. Fase 1 (slegs kod opleiding) • : In fase 2 sluit ons bykomende publiek beskikbare hoë-gehalte data uit verskeie domeine in, insluitend tegniese, wiskunde, en webdokumente, om die model se prestasie in redenering en probleemoplossing te verbeter, wat noodsaaklik is vir kodegenerering. Ons oefen al ons modelle vir 500B tokens (80% kode en 20% taal data) in fase 2 opleiding. Fase 2 (kode + taal opleiding) 4.2 Opleidingsdoelstelling Vir die opleiding van al ons modelle gebruik ons die kausale taalmodelleer-objektief en Fill-In-the-Middle (FIM) ( , ) objektief. Die FIM-objektief het die taak om ingevoegde tokens te voorspel met die gegewe konteks en daaropvolgende teks. Ons oefen ons modelle om met beide PSM (Prefix-Suffix-Middle) en SPM (Suffix-Prefix-Middle) modusse te werk, met relevante formateringbeheer tokens, dieselfde as StarCoder ( , < Bavarian et al. 2022 Li et al.
