```html Författare: 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 Sammanfattning Stora språkmodeller (LLM) som tränats på kod revolutionerar mjukvaruutvecklingsprocessen. Allt oftare integreras kod-LLM i miljöer för mjukvaruutveckling för att förbättra produktiviteten hos mänskliga programmerare, och LLM-baserade agenter börjar visa löften för att hantera komplexa uppgifter autonomt. Att realisera den fulla potentialen hos kod-LLM kräver ett brett spektrum av förmågor, inklusive kodgenerering, buggfixning, förklaring och dokumentation av kod, underhåll av kodarkiv och mycket mer. I detta arbete introducerar vi Granite-serien av endast avkodande kodmodeller för kodgenereringsuppgifter, tränade med kod skriven på 116 programmeringsspråk. Granite Code-modellfamiljen består av modeller som varierar i storlek från 3 till 34 miljarder parametrar, lämpliga för applikationer från komplexa uppgifter för modernisering av applikationer till användningsfall med minnesbegränsningar på enheten. Utvärdering på en omfattande uppsättning uppgifter visar att Granite Code-modeller konsekvent når toppmodern prestanda bland tillgängliga open source-kod-LLM. Granite Code-modellfamiljen optimerades för arbetsflöden för företags mjukvaruutveckling och presterar bra över en rad kodningsuppgifter (t.ex. kodgenerering, fixning och förklaring), vilket gör den till en mångsidig "allround"-kodmodell. Vi släpper alla våra Granite Code-modeller under en Apache 2.0-licens för både forskning och kommersiellt bruk. https://github.com/ibm-granite/granite-code-models 1 Introduktion Under de senaste decennierna har mjukvara vävts in i själva grunden för alla aspekter av vårt samhälle. I takt med att efterfrågan på mjukvaruutveckling ökar, är det viktigare än någonsin att öka produktiviteten för mjukvaruutveckling, och LLM:er erbjuder en lovande väg för att förstärka mänskliga programmerare. Framstående företagsanvändningsfall för LLM:er inom produktivitet för mjukvaruutveckling inkluderar kodgenerering, kodförklaring, kodfixning, generering av enhetstester och dokumentation, modernisering av applikationer, sårbarhetsdetektering, kodöversättning med mera. Under de senaste åren har det skett snabba framsteg i LLM:ers förmåga att generera och manipulera kod, och en rad modeller med imponerande kodningsförmågor finns tillgängliga idag. Modellerna varierar i storlek från modeller med ett fåtal miljarder parametrar (t.ex. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), etc.) till hundratals miljarder: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), och varierar i den avsedda användningens generalitet, där vissa modeller syftar till att täcka en rad användningsområden utanför kod, medan andra fokuserar främst på kodrelaterade uppgifter (t.ex. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), och CodeGemma (CodeGemma Team et al., 2024)). Det finns dock fortfarande viktiga luckor inom det nuvarande fältet av LLM:er för kod, särskilt i samband med företags mjukvaruutveckling. För det första, även om mycket stora, generalistiska LLM:er kan uppnå utmärkt kodningsprestanda, gör deras storlek dem dyra att driftsätta. Mindre kodfokuserade modeller ( , ; , ; , ; , ; , ) kan uppnå utmärkt kodgenereringsprestanda i ett mindre och mer flexibelt paket, men prestandan i kodningsuppgifter utöver generering (t.ex. fixning och förklaring) kan släpa efter kodgenereringsprestandan. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 I många företagskontexter kompliceras adoptionen av kod-LLM ytterligare av faktorer utöver modellernas prestanda. Till exempel, även öppna modeller plågas ibland av bristande transparens om datakällor och databehandlingsmetoder som användes för att skapa modellen, vilket kan underminera förtroendet för modeller i kritiska och reglerade sammanhang. Dessutom kan licensvillkoren i dagens öppna LLM:er begränsa och komplicera ett företags förmåga att använda en modell. Här presenterar vi Granite Code-modeller, en serie mycket kapabla kod-LLM:er, designade för att stödja företags mjukvaruutveckling över ett brett spektrum av kodningsuppgifter. Granite Code-modeller har två huvudvarianter som vi släpper i fyra olika storlekar (3B, 8B, 20B och 34B): grundläggande basmodeller för kodrelaterade uppgifter; Granite Code Base: instruktionsföljande modeller finjusterade med en kombination av Git-commits parat med mänskliga instruktioner och syntetiskt genererade kodinstruktionsdataset med öppen källkod. Granite Code Instruct: Basmodellerna i serien har tränats från grunden med en tvåfasig träningsstrategi. I fas 1 tränas vår modell på 3 till 4 biljoner tokens från 116 programmeringsspråk, vilket säkerställer en omfattande förståelse av programmeringsspråk och syntax. I fas 2 tränas vår modell ytterligare på 500 miljarder tokens med en noggrant utformad blandning av högkvalitativ data från kod- och naturliga språkdomäner för att förbättra modellens förmåga att resonera. Vi använder det oövervakade språkmodelleringsmålet för att träna basmodellerna i båda faserna av träningen. Instruktörsmodellerna härleds genom att ytterligare finjustera de ovan tränade basmodellerna på en kombination av en filtrerad variant av CommitPack ( , ), dataset för instruktionsföljning i naturligt språk (OASST ( , ), HelpSteer ( , )) och matematiska dataset med öppen källkod (MathInstruct ( , ) och MetaMathQA ( , )), inklusive syntetiskt genererade koddataset för att förbättra instruktionsföljning och resonemangsförmåga. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Vi genomför omfattande utvärderingar av våra kod-LLM:er på en komplett uppsättning riktmärken, inklusive HumanEvalPack ( , ), MBPP+ ( , ; , ), RepoBench ( , ), ReCode ( , ), och mer. Denna uppsättning riktmärken omfattar många olika typer av kodningsuppgifter utöver enbart kodsyntes i Python, t.ex. kodfixning, kodförklaring, kodredigering, kodöversättning, etc., över de flesta stora programmeringsspråk (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 Våra resultat visar att bland open source-modeller, visar Granite Code-modellerna övergripande mycket stark prestanda över alla modellstorlekar och riktmärken (ofta överträffande andra open source-kodmodeller som är dubbelt så stora jämfört med Granite). Som illustration visar figur (överst) en jämförelse av Granite-8B-Code-Base med andra open source-baserade kod-LLM:er, inklusive nyligen högpresterande generella bas-LLM:er som Mistral ( , ) och LLama-3 ( , ) på HumanEvalPack ( , ). Medan CodeGemma och StarCoder2 presterar rimligt bra i kodgenerering, presterar de betydligt sämre på kodfixnings- och förklaringsvarianterna av HumanEvalPack. I genomsnitt överträffar Granite-8B-Code-Base den mest konkurrenskraftiga CodeGemma-8B-modellen med nästan 12 poäng på HumanEvalPack (33,2% vs 21,3%), trots att den tränats på betydligt färre antal tokens (4,5T vs 7,5T tokens). Utöver basmodellerna visar även de instruktionsjusterade varianterna av våra Granite Code-modeller stark prestanda på HumanEvalPack, överträffande andra open source (kod) instruktionsmodeller, vilket visar fördelarna för en bredare uppsättning kodningsuppgifter med instruktioner i naturligt språk (se figur (nederst)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Dessutom, eftersom resonemang är kritiskt för att lösa komplicerade frågor och uppgifter, testar vi även vår Granite-8B-Code-Base-modell på sex matematiska riktmärken, inklusive MATH ( , ), GSM8K ( , ) och problemlösning med tillgång till beräkningsverktyg, där vår Granite 8B-modell uppnår bättre prestanda jämfört med de flesta state-of-the-art 7B- eller 8B-LLM:er. Till exempel, Granite-8B-Code-Base överträffar Llama-3-8B-Base med cirka 12 poäng på GSM8K och cirka 6 poäng på MATH (se tabell ). Cobbe et al. 2021 Cobbe et al. 2021 15 De viktigaste fördelarna med Granite Code-modeller inkluderar: : Granite Code-modeller uppnår konkurrenskraftig eller state-of-the-art prestanda på olika typer av kodrelaterade uppgifter, inklusive kodgenerering, förklaring, fixning, redigering, översättning, etc., vilket visar deras förmåga att lösa olika kodningsuppgifter; Allround-kod-LLM : Alla våra modeller tränas på licenskompatibla data som samlats in enligt IBM:s AI Ethics-principer och vägleds av IBM:s Corporate Legal team för pålitlig företagsanvändning. Alla Granite Code-modeller släpps under Apache 2.0-licensen. Pålitlig företagsanpassad LLM 1 Vi beskriver vår hela pipeline för datainsamling, filtrering och förbehandling i avsnitt . Avsnitt beskriver detaljerna om modellarkitekturen, följt av träningsdetaljer i avsnitt . Avsnitt ger detaljer om instruktionsjustering, och avsnitt beskriver experimenten och resultaten som jämför Granite Code-modeller med andra open source-LLM:er. 2 3 4 5 6 2 Datainsamling I detta avsnitt beskriver vi processen för att krypa och filtrera (avsnitt ), deduplicering (avsnitt ), HAP/PII-filtrering (avsnitt ) som används för att förbereda koddata för modellträning. Vi ger också en översikt över högkvalitativ naturlig språkdata som används för att förbättra modellens språkförståelse och matematiska resonemangsförmåga. 2.1 2.2 2.3 2.1 Datakrypning och filtrering Predrivningskoddata hämtades från en kombination av offentligt tillgängliga dataset som Github Code Clean , StarCoderdata , och ytterligare offentliga kodarkiv och problem från GitHub. Vi filtrerar rådata för att behålla en lista över 116 programmeringsspråk av över 300 språk, som anges i Appendix . Tilldelningen av data till programmeringsspråk sker enbart baserat på filändelse, liknande StarCoder ( , ). Efter språkfiltrering tillämpar vi fyra viktiga filtreringsregler för att filtrera bort kod av lägre kvalitet ( , ): (1) ta bort filer med färre än 25% alfabetiska tecken, (2) med undantag för XSLT-språket, filtrera bort filer där strängen " 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Exakt och suddig deduplicering Vi använder en aggressiv dedupliceringsstrategi som inkluderar både exakt och suddig deduplicering för att ta bort dokument med (nästan) identiskt kodinnehåll i vårt träningsset. För exakt deduplicering beräknar vi först SHA256-hash på dokumentinnehållet och tar bort poster med identiska hashar. Efter exakt deduplicering tillämpar vi suddig deduplicering med målet att ta bort kodfiler som kan ha små variationer och därmed ytterligare avjämna datan. Vi använder en tvåstegsmetod för detta: (1) beräkna MinHash för alla dokument och sedan använda Locally Sensitive Hashing (LSH) för att gruppera dokument baserat på deras MinHash-fingeravtryck, (2) mäta Jaccard-likhet mellan varje par av dokument i samma grupp och annotera dokument utom ett som duplicerade baserat på en likhetströskel på 0,7. Vi tillämpar denna nästan-dedupliceringsprocess på alla programmeringsspråk, inklusive GitHub-problem, för att öka rikheten och mångfalden i träningsdatasetet. 2.3 HAP, PII, Malwarefiltrering För att minska sannolikheten för att generera hatiskt, kränkande eller profant (HAP) språk från modellerna, gör vi noggranna ansträngningar för att filtrera HAP-innehåll från träningssetet. Vi skapar först en ordbok med HAP-nyckelord och annoterar sedan varje koddokument med antalet förekomster av sådana nyckelord i innehållet, inklusive kommentarer. Vi filtrerar bort dokument som överskrider HAP-tröskeln, beräknad baserat på en distributionsanalys samt manuell granskning av kodfiler. Dessutom, för att skydda integriteten, följer vi StarCoder ( , ) och gör noggranna ansträngningar för att redigera personligt identifierbar information (PII) från träningssetet. Specifikt använder vi StarPII -modellen för att upptäcka IP-adresser, nycklar, e-postadresser, namn, användarnamn och lösenord som hittas i innehållet. PII-redigeringssteget ersätter PII-texten med motsvarande tokens NAME, EMAIL, KEY, PASSWORD och ändrar IP-adressen till en syntetiskt genererad IP-adress, som i Li et al. (2023a). Vi skannar också våra dataset med för att identifiera och ta bort instanser av skadlig kod i källkoden. Li et al. 2023a 4 2.4 Dataset för naturligt språk Utöver att samla in koddata för modellträning, kuraterar vi flera offentligt tillgängliga högkvalitativa dataset för naturligt språk för att förbättra modellens färdigheter i språkförståelse och matematiskt resonemang. Representativa dataset under denna kategori inkluderar webbdokument (Stackexchange, CommonCrawl), matematiska webbtexter (OpenWeb-Math; ( ), StackMathQA; ( )), akademiska texter (Arxiv, Wikipedia), och dataset för instruktionsjustering (FLAN; ( ), HelpSteer ( , )). Vi deduplicerar inte dessa redan förbehandlade dataset för naturligt språk. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Modellarkitektur Vi tränar en serie kodmodeller av varierande storlek baserade på transformer-avkodararkitekturen ( , ). Modellhyperparametrarna för dessa modeller ges i tabell . För alla modellarkitekturer använder vi förnormalisering ( , ): normalisering tillämpad på indata till uppmärksamhets- och MLP-block. Vaswani et al. 2017 1 Xiong et al. 2020 : Den minsta modellen i Granite-code-modellfamiljen tränas med RoPE-inbäddning ( , ) och Multi-Head Attention ( , ). Denna modell använder swish aktiveringsfunktionen ( , ) med GLU ( , ) för MLP:n, även allmänt kallad swiglu. För normalisering använder vi RMSNorm ( , ) eftersom den är beräkningsmässigt effektivare än LayerNorm ( , ). 3B-modellen tränas med en kontextlängd 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 liknande arkitektur som 3B-modellen med undantag för användningen av Grouped-Query Attention (GQA) ( , ). Att använda GQA ger en bättre avvägning mellan modellprestanda och inferenseffektivitet i denna skala. Vi tränar 8B-modellen med en kontextlängd på 4096 tokens. 8B Ainslie et al. 2023 : 20B-kodmodellen tränas med inlärda absoluta positionsinbäddningar. Vi använder Multi-Query Attention ( , ) under träningen för effektiv nedströmsinferens. För MLP-blocket använder vi GELU-aktiveringsfunktionen ( , ). För att normalisera aktiveringarna använder vi LayerNorm ( , ). Denna modell tränas med en kontextlängd på 8192 tokens. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : För att träna 34B-modellen följer vi metoden av för djupuppskalning av 20B-modellen. Specifikt duplicerar vi först 20B-kodmodellen med 52 lager och tar sedan bort de sista 8 lagren från den ursprungliga modellen och de första 8 lagren från dess dubblett för att bilda två modeller. 34B Kim et al. Slutligen sammanfogar vi båda modellerna för att bilda Granite-34B-Code-modellen med 88 lager (se figur för en illustration). Efter djupuppskalningen observerar vi att prestandafallet jämfört med 20B-modellen är mycket litet, i motsats till vad som observerades av . Denna prestanda återhämtas ganska snabbt efter att vi fortsätter predrivningen av den uppskalade 34B-modellen. Liksom för 20B använder vi en kontext på 8192 tokens under predrivningen. 2 Kim et al. 4 Predrivning I detta avsnitt ger vi detaljer om tvåfasig träning (avsnitt ), träningsmål (avsnitt ), optimering (avsnitt ) och infrastruktur (avsnitt ) som används vid predrivning av modellerna. 4.1 4.2 4.3 4.4 4.1 Tvåfasig träning Granite Code-modeller tränas på 3,5T till 4,5T tokens av koddata och dataset i naturligt språk relaterade till kod. Data tokeniseras via byte pair encoding (BPE, ( , )), med samma tokenizer som StarCoder ( , ). Efter ( , ; , ), använder vi högkvalitativ data med två faser av träning enligt följande. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Under fas 1 tränas både 3B- och 8B-modellerna för 4 biljoner tokens koddata som omfattar 116 språk. 20B-parameter modellen tränas på 3 biljoner tokens kod. 34B-modellen tränas på 1,4T tokens efter djupuppskalningen som görs på 1,6T-kontrollpunkten av 20B-modellen. Fas 1 (endast kodträning) • : I fas 2 inkluderar vi ytterligare högkvalitativt offentligt tillgängligt data från olika domäner, inklusive tekniska, matematiska och webbdokument, för att ytterligare förbättra modellens prestanda i resonemang och problemlösningsförmåga, vilket är avgörande för kodgenerering. Vi tränar alla våra modeller för 500B tokens (80% kod och 20% språkdata) i fas 2-träningen. Fas 2 (kod + språkträning) 4.2 Träningsmål För träning av alla våra modeller använder vi det kausala språkmodelleringsmålet och Fill-In-the-Middle (FIM) ( , ) målet. FIM-målet har uppgiften att förutsäga insatta tokens med den givna kontexten och efterföljande text. Vi tränar våra modeller att arbeta med både PSM (Prefix-Suffix-Middle) och SPM (Suffix-Prefix-Middle) lägen, med relevanta formateringskontrolltokens, samma som StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a Den totala förlusten beräknas som en viktad kombination av de 2 målen: Vi sätter empiriskt = 0,5 under träningen och finner att detta fungerar bra i praktiken, vilket leder till SOTA-prestanda på både kodkomplettering och kodinfillning. Det bör noteras att FIM-målet endast används under predrivning, men vi släpper det under instruktionsfinjustering, dvs. vi sätter = 1. α α 4.3 Optimering Vi använder AdamW-optimeraren ([Kingma & Ba](#_bookmark80), [2017](#_bookmark80)) med β1 = 0,9, β2 = 0,95 och viktnedbrytning på 0,1 för träning av alla våra Granite-kodmodeller. För fas-1-predrivningen följer inlärningshastigheten en cosinusplan från 3 10−4 som avtar till 3
