```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 (LLM'er), der er trænet på kode, revolutionerer softwareudviklingsprocessen. I stigende grad bliver kodnings-LLM'er integreret i softwareudviklingsmiljøer for at forbedre produktiviteten hos menneskelige programmører, og LLM-baserede agenter begynder at vise lovende resultater for autonom håndtering af komplekse opgaver. For at realisere det fulde potentiale af kodnings-LLM'er kræves der et bredt spektrum af kapaciteter, herunder kodegenerering, fejlretning, forklaring og dokumentering af kode, vedligeholdelse af repositories og meget mere. I dette arbejde introducerer vi Granite-serien af decoder-only kodemodeller til kodegenereringsopgaver, trænet med kode skrevet på 116 programmeringssprog. Granite Code-modellernefamilien består af modeller, der spænder i størrelse fra 3 til 34 milliarder parametre, velegnet til applikationer lige fra komplekse opgaver til modernisering af applikationer til hukommelsesbegrænsede anvendelser på enheden. Evaluering på et omfattende sæt af opgaver viser, at Granite Code-modeller konsekvent opnår state-of-the-art ydeevne blandt tilgængelige open source kodnings-LLM'er. Granite Code-model familialeen er optimeret til virksomheders softwareudviklingsworkflows og yder godt på tværs af en række kodningsopgaver (f.eks. kodegenerering, fejlretning og forklaring), hvilket gør den til en alsidig "all-round" 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 seneste årtier er software blevet vævet ind i stoffet i alle aspekter af vores samfund. Efterhånden som efterspørgslen efter softwareudvikling stiger, er det mere kritisk end nogensinde at øge produktiviteten inden for softwareudvikling, og LLM'er giver en lovende vej til at supplere menneskelige programmører. Fremtrædende virksomhedsanvendelser for LLM'er inden for softwareudviklingsproduktivitet inkluderer kodegenerering, kodeforklaring, kodefejlretning, generering af enhedstests og dokumentation, applikationsmodernisering, sårbarhedsopdagelse, kodetranslation og mere. De seneste år har set hurtige fremskridt i LLM'ers evne til at generere og manipulere kode, og en række modeller med imponerende kodningskompetencer er tilgængelige i dag. Modellerne spænder i størrelse fra enkeltcifrede milliarder af parametre (f.eks. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024) osv.) til hundreder af milliarder: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), og varierer i generel anvendelse, 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 virksomheders softwareudvikling. For det første, mens meget store, generalist 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 virksomhedssammenhænge kan adoptionen af kodnings-LLM'er kompliceres yderligere af faktorer ud over modellernes ydeevne. For eksempel er selv åbne modeller undertiden plaget af manglende gennemsigtighed om datakilder og databehandlingsmetoder, der indgik i modellen, hvilket kan underminere tilliden til modeller i missionskritiske og regulerede sammenhænge. Desuden kan licensvilkår i dagens åbne LLM'er begrænse og komplicere en virksomheds mulighed for at bruge en model. Her præsenterer vi Granite Code-modellerne, en serie af yderst kapable kodnings-LLM'er, designet til at understøtte virksomheders softwareudvikling på tværs af et bredt spektrum af kodningsopgaver. Granite Code-modellerne har to hovedvarianter, som vi frigiver i fire forskellige størrelser (3B, 8B, 20B og 34B): grundlæggende fundamentmodeller til kodningsrelaterede 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 kodestruktionsdatasæ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 den usuperviserede sprogmodelleringsmål til at træne basismodellerne i begge faser af træningen. Instruktionsmodellerne er udledt ved yderligere finjustering af ovenstående trænede basismodeller på en kombination af en filtreret variant af CommitPack ( , ), datasæt til instruktionsfølgning på 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 kodnings-LLM'er på et komplet sæt benchmarks, inklusive HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) og mere. Dette benchmarksæt omfatter mange forskellige typer af kodningsopgaver ud over blot kodensyntese i Python, f.eks. kodefejlretning, kodeforklaring, koderedigering, kodetranslation osv., på tværs af de fleste store 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 fund afslører, at blandt open source-modellerne viser Granite Code-modellerne generelt meget stærk ydeevne på tværs af alle modelstørrelser og benchmarks (ofte udkonkurrerer andre open source kodemodeller, der er dobbelt så store som Granite). Som en illustration viser figur (øverst) en sammenligning af Granite-8B-Code-Base med andre open source basis kodnings-LLM'er, inklusive nyligt højtydende generelle basis LLM'er som Mistral ( , ) og LLama-3 ( , ) på HumanEvalPack ( , ). Mens CodeGemma og StarCoder2 yder rimeligt godt i kodegenerering, yder de signifikant dårligere på kodefejlretnings- og forklarende varianter af HumanEvalPack. I gennemsnit udkonkurrerer 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 signifikant mindre antal tokens (4,5T vs. 7,5T tokens). Udover basismodellerne viser de instruktionsjusterede varianter af vores Granite Code-modeller også stærk ydeevne på HumanEvalPack og udkonkurrerer andre open source (kode) instruktionsmodeller, hvilket viser fordele for et bredere sæt af kodningsopgaver med instruktioner på naturligt sprog (se figur (nederst)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Desuden, da ræsonnement 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 udkonkurrerer Granite-8B-Code-Base Llama-3-8B-Base med ∼12 point på GSM8K og ∼6 point på MATH (se tabel ). Cobbe et al. 2021 Cobbe et al. 2021 15 De vigtigste fordele ved Granite Code-modellerne inkluderer: : Granite Code-modeller opnår konkurrencedygtig eller state-of-the-art ydeevne på forskellige typer kodningsrelaterede opgaver, inklusive kodegenerering, forklaring, fejlretning, redigering, translation osv., hvilket viser deres evne til at løse diverse kodningsopgaver; All-rounder Kodnings-LLM : Alle vores modeller er trænet på licens-permissible data indsamlet i overensstemmelse med IBM's AI Ethics principper og styret af IBM's Corporate Legal team til pålidelig virksomhedsanvendelse. Alle Granite Code-modellerne frigives under Apache 2.0-licensen. Pålidelig Enterprise-Grade LLM 1 Vi beskriver vores hele dataindsamlings-, filtrerings- og forbehandlingspipeline i afsnit . Afsnit beskriver detaljerne i modelarkitekturen, efterfulgt af træningsdetaljer i afsnit . Afsnit giver detaljer 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 ) brugt 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 Datacrawling og filtrering Prætræningskodningsdataene blev hentet fra en kombination af offentligt tilgængelige datasæt som Github Code Clean , StarCoderdata , og yderligere offentlige koderepositorys og issues fra GitHub. Vi filtrerer rådata for at bevare en liste over 116 programmeringssprog ud af over 300 sprog, som angivet i appendiks . Tildelingen af data til programmeringssprog udføres udelukkende baseret på filtypenavn, ligesom StarCoder ( , ). Efter sprogfiltrering anvender vi fire nøglefiltreringsregler til 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=” vises inden for de første 100 tegn, (3) for HTML-filer, behold kun filer, hvor den synlige tekst udgør mindst 20% af HTML-koden og har en minimumslængde på 100 tegn, (4) for JSON- og YAML-filer, behold kun filer, der har et tegntal på mellem 50 og 5000 tegn. Vi filtrerer også GitHub-issues ved hjælp af et sæt kvalitetsmetrikker, der inkluderer fjernelse af auto-genereret tekst, filtrering af ikke-engelske issues, udelukkelse af kommentarer fra bots og brug af antallet af brugere, der er engageret i samtalen, som en indikator for kvalitet. Vi annoterer også hver kodfil med licensinformation tilknyttet det respektive repository, fundet via Github APIs, 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 Fuzzy deduplikering Vi anvender en aggressiv deduplikeringsstrategi, herunder både eksakt og fuzzy deduplikering, for at fjerne dokumenter med (næsten) identisk kodeindhold i vores træningssæt. Til eksakt deduplikering beregner vi først SHA256 hash på dokumentindholdet og fjerner poster med identiske hashes. Efter eksakt deduplikering anvender vi fuzzy deduplikering med det formål at fjerne kodfiler, der kan have små variationer og dermed yderligere afbalancere dataene. Vi anvender en to-trins metode til dette: (1) beregn MinHashes af alle dokumenter og brug derefter Locally Sensitive Hashing (LSH) til at gruppere dokumenter baseret på deres MinHash fingeraftryk, (2) mål Jaccard-ligheden mellem hvert par af dokumenter i samme gruppe og annoter dokumenter undtagen ét som duplikater baseret på en lighedstærskel på 0,7. Vi anvender denne nær-deduplikeringsproces på alle programmeringssprog, inklusive GitHub-issues, for at forbedre rigdommen og mangfoldigheden af træningsdatasættet. 2.3 HAP, PII, Malware filtrering For at reducere sandsynligheden for at generere hadefuldt, krænkende eller profant (HAP) sprog fra modellerne, gør vi flittige bestræbelser på at filtrere HAP-indhold fra træningssættet. Vi opretter først en ordbog over HAP-nøgleord og annoterer derefter hvert kod dokument 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 kodfiler. Desuden, for at beskytte privatlivets fred, følger vi StarCoder ( , ) og gør flittige bestræbelser på at redigere personligt identificerbare oplysninger (PII) fra træningssættet. Specifikt udnytter vi StarPII -modellen til at opdage 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 til en syntetisk genereret IP-adresse, som i Li et al. (2023a). Vi scanner også vores datasæt for at identificere og fjerne forekomster af malware i kildekoden. Li et al. 2023a 4 2.4 Datasæt med naturligt sprog Ud over at indsamle kodningsdata til modeltræning, kuraterer vi flere offentligt tilgængelige datasæt af høj kvalitet med naturligt sprog til at forbedre modellens færdigheder i sprogforståelse og matematisk ræsonnement. Repræsentative datasæt i denne kategori inkluderer webdokumenter (Stackexchange, CommonCrawl), matematisk weblinkst (OpenWeb-Math; ( ), StackMathQA; ( )), akademisk tekst (Arxiv, Wikipedia) og datasæt til instruktionsjustering (FLAN; ( ), HelpSteer ( , )). Vi deduplikerer ikke disse allerede forbehandlede datasæt med 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-decoderarkitekturen ( , ). Modelhyperparametrene for disse modeller er angivet i tabel . For alle modelarkitekturer bruger vi pre-normalisering ( , ): normalisering anvendt på input til 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 embedding ( , ) 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 modelydeevne og inferens-effektivitet 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æningen for effektiv downstream-inferens. 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 for dybdeskaleringsforøgelse af 20B-modellen. Specifikt duplikerer vi først 20B-kodemodellen med 52 lag og fjerner derefter de sidste 8 lag fra den oprindelige model og de første 8 lag fra dens duplikat for at danne to modeller. 34B Kim et al. Endelig sammensætter vi begge modeller for at danne Granite-34B-Code-modellen med 88 lag (se figur for en illustration). Efter dybdeskaleringsforøgelsen observerer vi, at faldet i ydeevne sammenlignet med 20B-modellen er ret lille, i modsætning til hvad observerede. Denne ydeevne genvindes ret hurtigt, efter at vi fortsætter prætræningen af den opskalerede 34B-model. Ligesom med 20B bruger vi en 8192 token-kontekst under prætræning. 2 Kim et al. 4 Prætræning I dette afsnit giver vi detaljer om to-faset træning (afsnit ), træningsmål (afsnit ), optimering (afsnit ) og infrastruktur (afsnit ) brugt til prætræning af modellerne. 4.1 4.2 4.3 4.4 4.1 To-faset træning Granite Code-modellerne er trænet på 3,5T til 4,5T tokens af kodningsdata og naturlige sprogdatasæt relateret til kode. Data tokeniseres via byte pair encoding (BPE, ( , )), ved brug af den samme tokenizer som StarCoder ( , ). I overensstemmelse med ( , ; , ) udnytter vi data af høj kvalitet med to faser af træning 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 modellerne for 4 billioner tokens af kodningsdata, der omfatter 116 sprog. 20B parameter-modellen trænes på 3 billioner tokens kode. 34B modellen trænes på 1,4T tokens efter dybdeskaleringsforøgelsen, som udføres på 1,6T checkpoint 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, herunder tekniske, matematiske og webdokumenter, for yderligere at forbedre modellens ydeevne i ræsonnement og problemløsningsevner, som er essentielle for kodegenerering. Vi træner alle vores modeller i 500 mia. tokens (80% kode og 20% sproglige data) i fase 2 træning. Fase 2 (kode + sproglig træning) 4.2 Træningsmål Til træning af alle vores modeller bruger vi den kausale sprogmodelleringsmål og Fill-In-the-Middle (FIM) ( , ) mål. FIM-målet er 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 formateringskontroltokens, 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æningen og finder, at dette fungerer godt i praksis og fører til SOTA-ydeevne på både kodefuldførelse og kodensindføjningsopgaver. Det skal bemærkes, at FIM-målet kun bruges under prætræning, men vi dropper det under instruktions finjustering, dvs. vi sætter = 1. α α
