```html Forfattere: 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 Abstrakt Store sprogmodeller (LLMs) trænet på kode revolutionerer softwareudviklingsprocessen. Stadig oftere integreres kode-LLM'er i softwareudviklingsmiljøer for at forbedre produktiviteten for menneskelige programmører, og LLM-baserede agenter begynder at vise løfter for at håndtere komplekse opgaver autonomt. At realisere det fulde potentiale af kode-LLM'er kræver en bred vifte af kapaciteter, herunder kodegenerering, fejlretning, forklaring og dokumentation af kode, vedligeholdelse af repositories og meget mere. I dette arbejde introducerer vi Granite-serien af decoder-only kodemodeller til kodegenerative opgaver, trænet med kode skrevet på 116 programmeringssprog. Granite Code-familien af modeller består af modeller i størrelser fra 3 til 34 milliarder parametre, velegnet til applikationer lige fra komplekse opgaver til modernisering af applikationer til enhedsbegrænsede hukommelsessituationer. Evaluering på et omfattende sæt opgaver viser, at Granite Code-modeller konsekvent opnår state-of-the-art ydeevne blandt tilgængelige open source-kode LLM'er. Granite Code-model-familien blev optimeret til enterprise softwareudviklings-workflows og performer godt på tværs af en række kodningsopgaver (f.eks. kodegenerering, fejlretning og forklaring), hvilket gør den til en alsidig "all around" kodemodel. Vi frigiver alle vores Granite Code-modeller under en Apache 2.0-licens til både forsknings- og kommerciel brug. https://github.com/ibm-granite/granite-code-models 1 Introduktion I løbet af de sidste årtier er software blevet vævet ind i alle aspekter af vores samfund. Efterhånden som efterspørgslen efter softwareudvikling stiger, er det afgørende at øge produktiviteten i softwareudviklingen, og LLM'er giver en lovende vej til at supplere menneskelige programmører. Fremtrædende virksomhedsanvendelser for LLM'er i softwareudviklingsproduktivitet inkluderer kodegenerering, kodningsforklaring, kodningsfejlfinding, generering af enhedstest og dokumentation, modernisering af applikationer, sårbarhedsdetektion, kodningsoversættelse og mere. De seneste år har budt på hastige fremskridt i LLM'ers evne til at generere og manipulere kode, og en række modeller med imponerende kodningsevner er tilgængelige i dag. Modellerne varierer i størrelse fra enkeltcifrede milliarder parametre (f.eks. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024) osv.) til hundredvis af milliarder: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), og varierer i generel tilsigtet brug, hvor nogle modeller sigter mod at dække en række anvendelser uden for kode, mens andre primært fokuserer på kodningsrelaterede opgaver (f.eks. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), og CodeGemma (CodeGemma Team et al., 2024)). Der er dog fortsat vigtige huller i det nuværende felt af LLM'er til kode, især i forbindelse med enterprise softwareudvikling. For det første, mens meget store, generalistiske LLM'er kan opnå fremragende kodningsydelse, gør deres størrelse dem dyre at implementere. Mindre kodningsfokuserede modeller ( , ; , ; , ; , ; , ) kan opnå fremragende kodegenereringsydelse i en mindre og mere fleksibel pakke, men ydeevnen i kodningsopgaver ud over generering (f.eks. fejlretning og forklaring) kan halte bagefter kodegenereringsydelsen. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 I mange virksomhedskontekster kan LLM-adoption til kode kompliceres yderligere af faktorer ud over modellernes ydeevne. For eksempel er selv åbne modeller undertiden plaget af mangel på gennemsigtighed om datakilderne og databehandlingsmetoderne, der gik ind i modellen, hvilket kan underminere tilliden til modeller i kritiske og regulerede sammenhænge. Desuden kan licensbetingelser i nutidens åbne LLM'er begrænse og komplicere en virksomheds evne til at bruge en model. Her præsenterer vi Granite Code-modeller, en serie af yderst kapable kode-LLM'er, designet til at understøtte enterprise softwareudvikling på tværs af en bred vifte af kodningsopgaver. Granite Code-modeller har to hovedvarianter, som vi frigiver i fire forskellige størrelser (3B, 8B, 20B og 34B): grundlæggende fundamentmodeller til kode-relaterede opgaver; Granite Code Base: instruktionsfølgende modeller finjusteret ved hjælp af en kombination af Git-commits parret med menneskelige instruktioner og open source syntetisk genererede kodningsinstruktionsdatasæt. Granite Code Instruct: Basismodellerne i serien er trænet fra bunden med en to-faset træningsstrategi. I fase 1 er vores model trænet på 3 til 4 billioner tokens fra 116 programmeringssprog, hvilket sikrer en omfattende forståelse af programmeringssprog og syntaks. I fase 2 er vores model yderligere trænet på 500 milliarder tokens med en omhyggeligt designet blanding af data af høj kvalitet fra kode- og naturlige sprogdomæner for at forbedre modellens evne til at ræsonnere. Vi bruger det uovervågede sprogmodelleringsmål til at træne basismodellerne i begge faser af træningen. Instruktionsmodellerne er udledt ved yderligere finjustering af de ovennævnte trænede basismodeller på en kombination af en filtreret variant af CommitPack ( , ), datasæt til instruktionsfølgning i naturligt sprog (OASST ( , ), HelpSteer ( , )) og open source matematiske datasæt (MathInstruct ( , ) og MetaMathQA ( , )), inklusive syntetisk genererede kodningsdatasæt til forbedring af instruktionsfølgning og ræsonneringsevner. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Vi udfører omfattende evalueringer af vores kode-LLM'er på et komplet sæt benchmarks, inklusive HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ), og mere. Dette sæt af benchmarks omfatter mange forskellige typer kodningsopgaver ud over blot kodningssyntese i Python, f.eks. fejlretning af kode, forklaring af kode, redigering af kode, oversættelse af kode osv., på tværs af de fleste større programmeringssprog (Python, JavaScript, Java, Go, C++, Rust, osv.). Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 Vores resultater afslører, at blandt open source-modeller viser Granite Code-modellerne samlet set meget stærke resultater på tværs af alle modelstørrelser og benchmarks (ofte overgår andre open source-kodemodeller, der er dobbelt så store som Granite). Som illustration viser figur (top) en sammenligning af Granite-8B-Code-Base med andre open source-basis kod-LLM'er, inklusive nylige højtydende generelle basis LLM'er som Mistral ( , ) og LLama-3 ( , ) på HumanEvalPack ( , ). Mens CodeGemma og StarCoder2 performer rimeligt godt i kodegenerering, performer de betydeligt dårligere på fejlretnings- og forklaringsvarianterne af HumanEvalPack. I gennemsnit overgår Granite-8B-Code-Base den mest konkurrencedygtige CodeGemma-8B-model med næsten 12 point på HumanEvalPack (33,2% vs 21,3%), på trods af at den er trænet på et betydeligt mindre antal tokens (4,5T vs 7,5T tokens). Udover basismodellerne viser de instruktionsjusterede varianter af vores Granite Code-modeller også stærke resultater på HumanEvalPack, og overgår andre open source (kode) instruktionsmodeller, hvilket demonstrerer fordele for et bredere sæt kodningsopgaver med naturlige sproginstruktioner (se figur (bund)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Desuden, da ræsonnering er kritisk for at løse komplicerede spørgsmål og opgaver, tester vi også vores Granite-8B-Code-Base model på seks matematiske benchmarks, inklusive MATH ( , ), GSM8K ( , ) og problemløsning med adgang til beregningsværktøjer, hvor vores Granite 8B-model opnår bedre ydeevne sammenlignet med de fleste state-of-the-art 7B eller 8B LLM'er. For eksempel overgår Granite-8B-Code-Base Llama-3-8B-Base med cirka 12 point på GSM8K og cirka 6 point på MATH (se tabel ). Cobbe et al. 2021 Cobbe et al. 2021 15 De vigtigste fordele ved Granite Code-modeller inkluderer: : Granite Code-modeller opnår konkurrencedygtig eller state-of-the-art ydeevne på forskellige typer kode-relaterede opgaver, inklusive kodegenerering, forklaring, fejlretning, redigering, oversættelse osv., hvilket demonstrerer deres evne til at løse forskellige kodningsopgaver; All-rounder Kode LLM : Alle vores modeller er trænet på tilladte data indsamlet i overensstemmelse med IBM's AI Ethics-principper og vejledt af IBM's Corporate Legal team til troværdig virksomhedsbrug. Alle Granite Code-modeller frigives under Apache 2.0-licensen. Pålidelig Enterprise-Grade LLM 1 Vi beskriver vores komplette pipeline til dataindsamling, filtrering og forbehandling i afsnit . Afsnit beskriver detaljerne om modelarkitekturen, efterfulgt af træningsdetaljer i afsnit . Afsnit giver detaljerne om instruktionsjustering, og afsnit beskriver eksperimenterne og resultaterne, der sammenligner Granite Code-modeller med andre open source LLM'er. 2 3 4 5 6 2 Dataindsamling I dette afsnit beskriver vi processen med at crawle og filtrere (afsnit ), deduplikering (afsnit ), HAP/PII-filtrering (afsnit ), der bruges til at forberede kodningsdata til modeltræning. Vi giver også et overblik over naturlige sprogdata af høj kvalitet, der bruges til at forbedre modellens sprogforståelse og matematiske ræsonneringsevner. 2.1 2.2 2.3 2.1 Data-crawling og filtrering Forudgående træningskode-data blev hentet fra en kombination af offentligt tilgængelige datasæt som Github Code Clean , StarCoderdata , og yderligere offentlige koderepositorys og -udfordringer fra GitHub. Vi filtrerer rådata for at beholde en liste over 116 programmeringssprog ud af 300+ sprog, som angivet i tillæg . Tildelingen af data til programmeringssprog udføres udelukkende baseret på filtypenavn, ligesom StarCoder ( , ). Efter sprogfiltrering anvender vi fire nøglefiltreringsregler for at filtrere kode af lavere kvalitet fra ( , ): (1) fjern filer med færre end 25% alfabetiske tegn, (2) undtagen XSLT-sproget, filtrer filer fra, hvor strengen “<?xml version=” optræder inden for de første 100 tegn, (3) for HTML-filer, behold kun filer, hvor den synlige tekst udgør mindst 20% af koden og har en minimumslængde på 100 tegn, (4) for JSON og YAML-filer, behold kun filer, der har et tegntal mellem 50 og 5000 tegn. Vi filtrerer også GitHub-udfordringer ved hjælp af et sæt kvalitetsmålinger, der inkluderer fjernelse af automatisk genereret tekst, filtrering af ikke-engelske udfordringer, udelukkelse af kommentarer fra bots og brug af antallet af brugere, der deltager i samtalen, som en indikator for kvalitet. Vi annoterer også hver kodningsfil med licensinformation forbundet med det respektive repository, fundet via Github API'er og beholder kun filer med permissive licenser til modeltræning. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Eksakt og uklar deduplikering Vi anvender en aggressiv deduplikeringsstrategi, der inkluderer både eksakt og uklar deduplikering for at fjerne dokumenter med (næsten) identisk kodeindhold fra vores træningssæt. For eksakt deduplikering beregner vi først SHA256-hash på dokumentindholdet og fjerner poster med identiske hashes. Efter eksakt deduplikering anvender vi uklar deduplikering med det formål at fjerne kodningsfiler, der kan have små variationer og dermed yderligere ubalance i data. Vi anvender en to-trins metode til dette: (1) beregne MinHashes af alle dokumenter og derefter anvende Locally Sensitive Hashing (LSH) til at gruppere dokumenter baseret på deres MinHash-fingeraftryk, (2) måle Jaccard-lighed mellem hvert par af dokumenter i samme spand og annotere dokumenter undtagen et som dubletter baseret på en lighedstærskel på 0,7. Vi anvender denne næsten-deduplikeringsproces på alle programmeringssprog, inklusive GitHub-udfordringer, for at forbedre rigdommen og mangfoldigheden af træningsdatasættet. 2.3 HAP, PII, malware-filtrering For at reducere sandsynligheden for at generere hadefuldt, stødende eller profant sprog (HAP) fra modellerne, gør vi omhyggelige bestræbelser på at filtrere HAP-indhold fra træningssættet. Vi opretter først en ordbog med HAP-nøgleord og annoterer derefter hvert kodningsdokument med antallet af forekomster af sådanne nøgleord i indholdet, inklusive kommentarer. Vi filtrerer dokumenter fra, der overskrider HAP-tærsklen, beregnet baseret på en distributionsanalyse samt manuel inspektion af kodningsfiler. Desuden, for at beskytte privatlivets fred, følger vi StarCoder ( , ) og gør omhyggelige bestræbelser på at redigere personligt identificerbare oplysninger (PII) fra træningssættet. Specifikt udnytter vi StarPII -modellen til at detektere IP-adresser, nøgler, e-mailadresser, navne, brugernavne og adgangskoder fundet i indholdet. PII-redigeringstrinnet erstatter PII-teksten med de tilsvarende tokens NAME , EMAIL , KEY , PASSWORD og ændrer IP-adressen med en syntetisk genereret IP-adresse, som i Li et al. (2023a). Vi scanner også vores datasæt ved hjælp af for at identificere og fjerne forekomster af malware i kildekoden. Li et al. 2023a 4 2.4 Datasæt til naturligt sprog Ud over at indsamle kodningsdata til modeltræning samler vi flere offentligt tilgængelige datasæt af høj kvalitet til naturligt sprog for at forbedre modellens dygtighed i sprogforståelse og matematisk ræsonnering. Repræsentative datasæt i denne kategori inkluderer webdokumenter (Stackexchange, CommonCrawl), matematisk webtkst (OpenWeb-Math; ( ), StackMathQA; ( )), akademisk tekst (Arxiv, Wikipedia), og datasæt til instruktionsjustering (FLAN; ( ), HelpSteer ( , )). Vi deduplikerer ikke disse allerede forbehandlede datasæt til naturligt sprog. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Modelarkitektur Vi træner en serie af kodemodeller af varierende størrelser baseret på transformer decoder-arkitekturen ( , ). Modelhyperparametrene for disse modeller er givet i tabel . For alle modelarkitekturer bruger vi pre-normalisering ( , ): normalisering anvendt på input af opmærksomheds- og MLP-blokke. Vaswani et al. 2017 1 Xiong et al. 2020 : Den mindste model i Granite-code model-familien er trænet med RoPE-indlejring ( , ) og Multi-Head Attention ( , ). Denne model bruger swish-aktiveringsfunktionen ( , ) med GLU ( , ) til MLP'en, også almindeligt kendt som swiglu. Til normalisering bruger vi RMSNorm ( , ), da den er mere beregningsmæssigt effektiv end LayerNorm ( , ). 3B-modellen er trænet med en kontekstlængde på 2048 tokens. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : 8B-modellen har en lignende arkitektur som 3B-modellen, med undtagelse af brugen af Grouped-Query Attention (GQA) ( , ). Brugen af GQA giver en bedre balance mellem modelydelse og inferenseffektivitet i denne skala. Vi træner 8B-modellen med en kontekstlængde på 4096 tokens. 8B Ainslie et al. 2023 : 20B kodemodellen er trænet med lærte absolutte positionsindlejringer. Vi bruger Multi-Query Attention ( , ) under træning for effektiv inferens downstream. Til MLP-blokken bruger vi GELU-aktiveringsfunktionen ( , ). Til normalisering af aktiveringerne bruger vi LayerNorm ( , ). Denne model er trænet med en kontekstlængde på 8192 tokens. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Til træning af 34B-modellen følger vi tilgangen af til dybde-opskalering af 20B-modellen. Specifikt duplikerer vi først 20B-kodemodellen med 52 lag og fjerner derefter de sidste 8 lag fra den originale model og de første 8 lag fra dens duplikat for at danne to modeller. 34B Kim et al. Endelig samler vi begge modeller for at danne Granite-34B-Code-modellen med 88 lag (se figur for en illustration). Efter dybde-opskaleringen observerer vi, at faldet i ydeevne sammenlignet med 20B-modellen er meget lille i modsætning til, hvad observerede. Denne ydeevne genvindes ret hurtigt, efter vi fortsætter forudtræningen af den opskalerede 34B-model. Ligesom med 20B bruger vi en 8192 token kontekst under forudtræning. 2 Kim et al. 4 Forudtræning I dette afsnit giver vi detaljer om to-faset træning (afsnit ), træningsmål (afsnit ), optimering (afsnit ) og infrastruktur (afsnit ) brugt til forudtræning af modellerne. 4.1 4.2 4.3 4.4 4.1 To-faset træning Granite Code-modeller er trænet på 3,5T til 4,5T tokens af kodningsdata og naturlige sprogdata relateret til kode. Data tokeniseres via byte pair encoding (BPE, ( , )), idet den samme tokenizer som StarCoder ( , ) anvendes. Efter ( , ; , ) anvender vi data af høj kvalitet med to træningsfaser som følger. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Under fase 1 trænes både 3B og 8B modeller i 4 billioner tokens af kodningsdata omfattende 116 sprog. 20B parameter-modellen trænes på 3 billioner tokens kode. 34B-modellen trænes på 1,4T tokens efter dybde-opskaleringen, som udføres på 1,6T checkponten af 20B-modellen. Fase 1 (kun kodetræning) • : I fase 2 inkluderer vi yderligere offentligt tilgængelige data af høj kvalitet fra forskellige domæner, inklusive tekniske, matematiske og webdokumenter, for yderligere at forbedre modellens ydeevne i ræsonnering og problemløsningsevner, som er essentielle for kodegenerering. Vi træner alle vores modeller i 500B tokens (80% kode og 20% sprogdata) i fase 2-træningen. Fase 2 (kode + sprogtræning) 4.2 Træningsmål Til træning af alle vores modeller bruger vi det kausale sprogmodelleringsmål og Fill-In-the-Middle (FIM) ( , ) mål. FIM-målet har til opgave at forudsige indsatte tokens med den givne kontekst og efterfølgende tekst. Vi træner vores modeller til at arbejde med både PSM (Prefix-Suffix-Middle) og SPM (Suffix-Prefix-Middle) tilstande, med relevante formateringskontrol-tokens, ligesom StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a Det samlede tab beregnes som en vægtet kombination af de 2 mål: Vi sætter empirisk = 0,5 under træning og finder, at dette fungerer godt i praksis og fører til SOTA-ydelse på både kode-komplettering og kode-infilling-opgaver. Det skal bemærkes, at FIM-målet kun bruges under forudtræning, men vi dropper det under instruktionsfinjustering, dvs. vi sætter = 1. α α 4.3 Optimering
