Mga May-akda: 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 Buod Ang Malalaking Modelo ng Wika (LLMs) na sinanay sa code ay nagbabago sa proseso ng pagbuo ng software. Papalubog na, ang mga code LLM ay isinasama sa mga kapaligiran sa pagbuo ng software upang mapabuti ang pagiging produktibo ng mga human programmer, at ang mga ahente na batay sa LLM ay nagsisimulang magpakita ng pangako para sa paghawak ng mga kumplikadong gawain nang awtonomiya. Ang pag-realize ng buong potensyal ng mga code LLM ay nangangailangan ng malawak na hanay ng mga kakayahan, kabilang ang pagbuo ng code, pag-aayos ng mga bug, pagpapaliwanag at pagdodokumento ng code, pagpapanatili ng mga repositoryo, at higit pa. Sa gawaing ito, ipinakilala namin ang serye ng Granite ng mga decoder-only code model para sa mga code generative task, na sinanay gamit ang code na nakasulat sa 116 na programming language. Ang pamilya ng Granite Code model ay binubuo ng mga modelong nag-iiba-iba sa laki mula 3 hanggang 34 bilyong parameter, angkop para sa mga application na mula sa kumplikadong mga gawain sa pag-modernize ng aplikasyon hanggang sa mga kaso ng paggamit na limitado sa memorya sa on-device. Ang pagsusuri sa isang komprehensibong hanay ng mga gawain ay nagpapakita na ang Granite Code model ay patuloy na umaabot sa state-of-the-art na pagganap sa mga available na open-source code LLMs. Ang pamilya ng Granite Code model ay na-optimize para sa mga workflow ng enterprise software development at mahusay na gumaganap sa iba't ibang mga coding task (hal. code generation, fixing at explanation), na ginagawa itong isang versatile "all around" code model. Inilalabas namin ang lahat ng aming Granite Code model sa ilalim ng isang Apache 2.0 license para sa parehong pananaliksik at komersyal na paggamit. https://github.com/ibm-granite/granite-code-models 1 Introduksyon Sa mga nakalipas na dekada, ang software ay naihabi sa hibla ng bawat aspeto ng ating lipunan. Habang tumataas ang demand para sa pagbuo ng software, mas kritikal kaysa dati na pataasin ang pagiging produktibo ng pagbuo ng software, at ang mga LLM ay nagbibigay ng magandang landas para sa pagdaragdag sa mga human programmer. Ang mga kilalang enterprise use case para sa mga LLM sa pagiging produktibo ng pagbuo ng software ay kinabibilangan ng code generation, code explanation, code fixing, unit test at documentation generation, application modernization, vulnerability detection, code translation, at higit pa. Ang mga nakaraang taon ay nakakita ng mabilis na pag-unlad sa kakayahan ng LLM na bumuo at manipulahin ang code, at isang hanay ng mga modelo na may kahanga-hangang kakayahan sa coding ang magagamit ngayon. Ang mga modelo ay nag-iiba-iba sa laki mula sa single-digit billions ng parameters (hal. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), atbp.) hanggang sa daan-daang bilyon: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), at nag-iiba sa pangkalahatang layunin ng paggamit, kung saan ang ilang mga modelo ay naglalayong sakupin ang isang hanay ng mga gamit sa labas ng code, habang ang iba ay pangunahing nakatuon sa mga gawain na may kaugnayan sa coding (hal. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), at CodeGemma (CodeGemma Team et al., 2024)). Gayunpaman, mayroon pa ring mahahalagang puwang sa kasalukuyang larangan ng mga code LLM, lalo na sa konteksto ng enterprise software development. Una, habang ang napakalaki, pangkalahatang LLM ay maaaring makamit ang mahusay na pagganap sa coding, ang kanilang laki ay ginagawa silang mahal upang i-deploy. Ang mas maliliit na modelong nakatuon sa code ( , ; , ; , ; , ; , ) ay maaaring makamit ang mahusay na pagganap sa pagbuo ng code sa isang mas maliit at mas flexible na pakete, ngunit ang pagganap sa mga coding task na lampas sa henerasyon (hal. pag-aayos at pagpapaliwanag) ay maaaring mahuli sa pagganap ng code generation. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 Sa maraming konteksto ng enterprise, ang pag-ampon ng code LLM ay maaaring lalong kumplikado ng mga salik na lampas sa pagganap ng mga modelo. Halimbawa, kahit ang mga bukas na modelo ay kung minsan ay may kakulangan sa transparency tungkol sa mga pinagmulan ng data at mga pamamaraan sa pagproseso ng data na napunta sa modelo, na maaaring makabawas sa tiwala sa mga modelo sa mga kritikal na misyon at mga regulated na konteksto. Higit pa rito, ang mga tuntunin sa lisensya sa mga kasalukuyang bukas na LLM ay maaaring makahadlang at makapagpalubha sa kakayahan ng isang enterprise na gumamit ng isang modelo. Dito, ipinakikilala namin ang mga Granite Code model, isang serye ng mga code LLM na may mataas na kakayahan, na idinisenyo upang suportahan ang enterprise software development sa malawak na hanay ng mga coding task. Ang mga Granite Code model ay may dalawang pangunahing variant na inilalabas namin sa apat na magkakaibang laki (3B, 8B, 20B, at 34B): mga pangunahing foundation model para sa mga gawaing may kaugnayan sa code; Granite Code Base: mga modelong sumusunod sa mga tagubilin na finetuned gamit ang kumbinasyon ng mga Git commit na ipinares sa mga tagubilin ng tao at mga open-source na synthetically generated code instruction dataset. Granite Code Instruct: Ang mga base model sa serye ay sinanay mula sa simula na may two-phase training strategy. Sa phase 1, ang aming modelo ay sinanay sa 3 hanggang 4 trilyong token na nakuha mula sa 116 programming language, tinitiyak ang isang komprehensibong pag-unawa sa mga programming language at syntax. Sa phase 2, ang aming modelo ay karagdagang sinanay sa 500 bilyong token na may maingat na dinisenyong pinaghalong mataas na kalidad na data mula sa mga domain ng code at natural na wika upang mapabuti ang kakayahan ng modelo na mangatwiran. Ginagamit namin ang unsupervised language modeling objective upang sanayin ang mga base model sa parehong mga yugto ng pagsasanay. Ang mga instruct model ay nagmula sa karagdagang finetuning ng mga nabanggit na sinanay na base model sa isang kumbinasyon ng isang na-filter na variant ng CommitPack ( , ), mga natural language instruction following dataset (OASST ( , ), HelpSteer ( , )) at mga open-source math dataset (MathInstruct ( , ) at MetaMathQA ( , )), kabilang ang mga synthetically generated code dataset para sa pagpapabuti ng instruction following at reasoning capabilities. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Nagsasagawa kami ng malawak na pagsusuri ng aming mga code LLM sa isang komprehensibong hanay ng mga benchmark, kabilang ang HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ), at higit pa. Ang hanay ng mga benchmark na ito ay sumasaklaw sa maraming iba't ibang uri ng coding task na lampas sa code synthesis sa Python, hal., code fixing, code explanation, code editing, code translation, atbp., sa karamihan ng mga pangunahing programming language (Python, JavaScript, Java, Go, C++, Rust, atbp.). Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 Ang aming mga natuklasan ay nagpapakita na sa mga open-source model, ang mga Granite Code model sa kabuuan ay nagpapakita ng napakalakas na pagganap sa lahat ng model size at benchmark (madalas na nalalampasan ang iba pang open-source code model na dalawang beses na mas malaki kumpara sa Granite). Bilang isang ilustrasyon, ipinapakita ng pigura (itaas) ang isang paghahambing ng Granite-8B-Code-Base sa iba pang open-source base code LLMs, kabilang ang mga kamakailang high-performing general purpose base LLMs tulad ng Mistral ( , ) at LLama-3 ( , ) sa HumanEvalPack ( , ). Habang ang CodeGemma at StarCoder2 ay mahusay na gumaganap sa pagbuo ng code, sila ay makabuluhang mas mababa ang pagganap sa mga code fixing at explanation variant ng HumanEvalPack. Sa average, ang Granite-8B-Code-Base ay nalalampasan ang pinaka-kompetitibong CodeGemma-8B model ng halos 12 puntos sa HumanEvalPack (33.2% vs 21.3%), sa kabila ng pagkakaroon ng mas kaunting bilang ng token na sinanay (4.5T vs 7.5T token). Bukod sa mga base model, ang mga instruction tuned variant ng aming Granite Code model ay nagpapakita rin ng malakas na pagganap sa HumanEvalPack, na nalalampasan ang iba pang open-source (code) instruction model, na nagpapakita ng mga benepisyo sa mas malawak na hanay ng mga coding task na may natural language instructions (tingnan ang pigura (ibaba)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Higit pa rito, dahil kritikal ang pangangatwiran sa paglutas ng mga kumplikadong tanong at gawain, sinusubukan din namin ang aming Granite-8B-Code-Base model sa anim na mathematical benchmark, kabilang ang MATH ( , ), GSM8K ( , ) at problem solving na may access sa computational tools, kung saan ang aming Granite 8B model ay nakakakuha ng mas mahusay na pagganap kumpara sa karamihan ng state-of-the-art na 7B o 8B LLMs. Halimbawa, ang Granite-8B-Code-Base ay nalalampasan ang Llama-3-8B-Base ng ∼12 puntos sa GSM8K at ∼6 puntos sa MATH (tingnan ang talahanayan ). Cobbe et al. 2021 Cobbe et al. 2021 15 Ang mga pangunahing bentahe ng Granite Code model ay kinabibilangan ng: : Nakakamit ng mga Granite Code model ang kompetitibo o state-of-the-art na pagganap sa iba't ibang uri ng mga gawaing may kaugnayan sa code, kabilang ang code generation, explanation, fixing, editing, translation, atbp., na nagpapakita ng kanilang kakayahan na lumutas ng iba't ibang coding task; All-rounder Code LLM : Lahat ng aming modelo ay sinanay sa mga license-permissible na data na nakolekta kasunod ng mga prinsipyo ng AI Ethics ng IBM at ginagabayan ng Corporate Legal team ng IBM para sa mapagkakatiwalaang paggamit sa enterprise. Ang lahat ng Granite Code model ay inilalabas sa ilalim ng Apache 2.0 license. Trustworthy Enterprise-Grade LLM 1 Inilalarawan namin ang aming buong data collection, filtering, at preprocessing pipeline sa seksyon . Inilalarawan ng Seksyon ang mga detalye ng model architecture, na sinusundan ng mga detalye ng training sa Seksyon . Ang Seksyon ay nagbibigay ng mga detalye tungkol sa instruction tuning, at ang Seksyon ay naglalarawan ng mga eksperimento at resulta na naghahambing ng mga Granite Code model sa iba pang open-source LLMs. 2 3 4 5 6 2 Pagkolekta ng Data Sa seksyong ito, inilalarawan namin ang proseso ng pag-crawl at pag-filter (Sec. ), deduplication (Sec. ), HAP/PII filtering (Sec. ) na ginamit upang ihanda ang data ng code para sa model training. Nagbibigay din kami ng pangkalahatang-ideya ng mataas na kalidad na natural language data na ginamit upang mapabuti ang mga kasanayan sa pag-unawa sa wika at mathematical reasoning ng modelo. 2.1 2.2 2.3 2.1 Pag-crawl at Pag-filter ng Data Ang pretraining code data ay nakuha mula sa isang kumbinasyon ng mga available na pampublikong dataset tulad ng Github Code Clean , StarCoderdata , at karagdagang mga pampublikong code repository at mga isyu mula sa GitHub. Sinusubukan namin ang raw data upang mapanatili ang isang listahan ng 116 na programming language mula sa 300+ na wika, gaya ng nakalista sa Appendix . Ang pagtatalaga ng data sa mga programming language ay ginagawa batay lamang sa file extension, katulad ng StarCoder ( , ). Pagkatapos ng language filtering, naglalapat kami ng apat na pangunahing filtering rule upang alisin ang mas mababang kalidad na code ( , ): (1) alisin ang mga file na may mas kaunti sa 25% na alphabetic character, (2) maliban sa XSLT language, alisin ang mga file kung saan ang string na "<?xml version=” ay lumilitaw sa loob ng unang 100 character, (3) para sa mga HTML file, panatilihin lamang ang mga file kung saan ang nakikitang teksto ay bumubuo ng hindi bababa sa 20% ng HTML code at may minimum na haba na 100 character, (4) para sa mga JSON at YAML file, panatilihin lamang ang mga file na may character count na mula 50 hanggang 5000 character. Sinusubukan din namin ang mga GitHub issue gamit ang isang hanay ng mga kalidad na sukatan na kinabibilangan ng pag-alis ng auto-generated text, pag-filter ng mga isyung hindi Ingles, pagbubukod ng mga komento mula sa mga bot, at paggamit ng bilang ng mga user na kasali sa pag-uusap bilang isang tagapagpahiwatig ng kalidad. Nag-a-annotate din kami ng bawat code file na may impormasyon ng lisensya na nauugnay sa kaukulang repositoryo, na natagpuan sa pamamagitan ng Github API at pinapanatili lamang ang mga file na may permissive na lisensya para sa model training. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Exact at Fuzzy Deduplication Nag-a-adopt kami ng isang agresibong deduplication strategy kabilang ang parehong exact at fuzzy deduplication upang alisin ang mga dokumento na may (halos) magkaparehong nilalaman ng code sa aming training set. Para sa exact deduplication, unang kinakalkula namin ang SHA256 hash sa nilalaman ng dokumento at inaalis ang mga record na may magkaparehong hash. Pagkatapos ng exact deduplication, naglalapat kami ng fuzzy deduplication na may layuning alisin ang mga code file na maaaring may bahagyang pagkakaiba at sa gayon ay mas ma-unbias ang data. Naglalapat kami ng two-step na paraan para dito: (1) kalkulahin ang MinHashes ng lahat ng dokumento at pagkatapos ay gamitin ang Locally Sensitive Hashing (LSH) upang pangkatin ang mga dokumento batay sa kanilang MinHash fingerprint, (2) sukatin ang Jaccard similarity sa pagitan ng bawat pares ng dokumento sa parehong bucket at i-annotate ang mga dokumento maliban sa isa bilang mga duplicate batay sa isang similarity threshold na 0.7. Inilalapat namin ang near-deduplication process na ito sa lahat ng programming language kabilang ang GitHub issues upang mapahusay ang kayamanan at pagkakaiba-iba ng training dataset. 2.3 HAP, PII, Malware Filtering Upang mabawasan ang posibilidad ng pagbuo ng mapoot, mapang-abusong, o malaswang (HAP) na wika mula sa mga modelo, nagsusumikap kaming alisin ang HAP na nilalaman mula sa training set. Una, lumilikha kami ng isang dictionary ng mga HAP keyword at pagkatapos ay i-annotate ang bawat code document na may bilang ng mga paglitaw ng ganitong mga keyword sa nilalaman kasama ang mga komento. Inaalis namin ang mga dokumento na lumampas sa HAP threshold, na kinakalkula batay sa isang distributional analysis pati na rin ang manual inspection ng mga code file. Bukod dito, upang maprotektahan ang privacy, sinusunod namin ang StarCoder ( , ) at nagsusumikap na i-redact ang Personally Identifiable Information (PII) mula sa training set. Sa partikular, ginagamit namin ang StarPII model upang matukoy ang mga IP address, key, email address, pangalan, username, at password na matatagpuan sa nilalaman. Ang PII redaction step ay nagpapalit ng PII text ng mga kaukulang token na NAME , EMAIL , KEY , PASSWORD at binabago ang IP address ng isang synthetically generated IP address, gaya sa Li et al. (2023a). Sinusubukan din namin ang aming mga dataset gamit ang upang matukoy at alisin ang mga pagkakataon ng malware sa source code. Li et al. 2023a 4 2.4 Mga Dataset ng Natural na Wika Bukod sa pagkolekta ng data ng code para sa model training, nag-curate kami ng ilang available na pampublikong mataas na kalidad na natural language dataset para sa pagpapabuti ng kasanayan ng modelo sa pag-unawa sa wika at mathematical reasoning. Ang mga representatibong dataset sa ilalim ng kategoryang ito ay kinabibilangan ng mga web document (Stackexchange, CommonCrawl), mathematical web text (OpenWeb-Math; ( ), StackMathQA; ( )), akademikong teksto (Arxiv, Wikipedia), at instruction tuning dataset (FLAN; ( ), HelpSteer ( , )). Hindi namin dine-deduplicate ang mga na-preprocess na natural language dataset na ito. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Arkitektura ng Modelo Nagsanay kami ng isang serye ng mga code model ng iba't ibang laki batay sa transformer decoder architecture ( , ). Ang mga hyperparameter ng modelo para sa mga modelong ito ay ibinigay sa Talahanayan . Para sa lahat ng model architecture, ginagamit namin ang pre-normalization ( , ): normalization na inilapat sa input ng attention at MLP blocks. Vaswani et al. 2017 1 Xiong et al. 2020 : Ang pinakamaliit na modelo sa Granite-code model family ay sinanay gamit ang RoPE embedding ( , ) at Multi-Head Attention ( , ). Ginagamit ng modelong ito ang swish activation function ( , ) na may GLU ( , ) para sa MLP, na karaniwang tinutukoy din bilang swiglu. Para sa normalization, ginagamit namin ang RMSNorm ( , ) dahil ito ay mas mahusay sa computational kaysa sa LayerNorm ( , ). Ang 3B model ay sinanay na may context length na 2048 token. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : Ang 8B model ay may katulad na arkitektura sa 3B model maliban sa paggamit ng Grouped-Query Attention (GQA) ( , ). Ang paggamit ng GQA ay nagbibigay ng mas mahusay na tradeoff sa pagitan ng model performance at inference efficiency sa scale na ito. Nagsasanay kami ng 8B model na may context length na 4096 token. 8B Ainslie et al. 2023 : Ang 20B code model ay sinanay gamit ang learned absolute position embeddings. Gumagamit kami ng Multi-Query Attention ( , ) sa panahon ng pagsasanay para sa mahusay na downstream inference. Para sa MLP block, ginagamit namin ang GELU activation function ( , ). Para sa pag-normalize ng mga activation, ginagamit namin ang LayerNorm ( , ). Ang modelong ito ay sinanay na may context length na 8192 token. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Upang sanayin ang 34B model, sinusunod namin ang approach ni para sa depth upscaling ng 20B model. Sa partikular, unang dinodoble namin ang 20B code model na may 52 layers at pagkatapos ay inaalis ang huling 8 layers mula sa orihinal na modelo at ang unang 8 layers mula sa duplicate nito upang bumuo ng dalawang modelo. 34B Kim et al. Sa wakas, pinagsasama namin ang parehong modelo upang bumuo ng Granite-34B-Code model na may 88 layers (tingnan ang Figure para sa isang ilustrasyon). Pagkatapos ng depth upscaling, napapansin namin na ang pagbaba sa pagganap kumpara sa 20B model ay napakaliit taliwas sa naobserbahan ni . Ang pagganap na ito ay mabilis na nababawi pagkatapos naming ipagpatuloy ang pretraining ng na-upscale na 34B model. Katulad ng 20B, gumagamit kami ng 8192 token context habang nagpe-pretrain. 2 Kim et al. 4 Pretraining Sa seksyong ito, nagbibigay kami ng mga detalye sa dalawang phase training (Sec. ), training objectives (Sec. ), optimization (Sec. ) at imprastraktura (Sec. ) na ginamit sa pretraining ng mga modelo. 4.1 4.2 4.3 4.4 4.1 Two Phase Training Ang mga Granite Code model ay sinanay sa 3.5T hanggang 4.5T token ng code data at natural language dataset na nauugnay sa code. Ang data ay na-tokenize sa pamamagitan ng byte pair encoding (BPE, ( , )), gamit ang parehong tokenizer tulad ng StarCoder ( , ). Kasunod ng ( , ; , ), ginagamit namin ang mataas na kalidad na data na may dalawang yugto ng pagsasanay tulad ng sumusunod. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Sa panahon ng phase 1, ang parehong 3B at 8B model ay sinanay para sa 4 trilyong token ng code data na binubuo ng 116 na wika. Ang 20B parameter model ay sinanay sa 3 trilyong token ng code. Ang 34B model ay sinanay sa 1.4T token pagkatapos ng depth upscaling na ginawa sa 1.6T checkpoint ng 20B model. Phase 1 (code only training) • : Sa phase 2, nagsasama kami ng karagdagang available na mataas na kalidad na data mula sa iba't ibang domain, kabilang ang mga teknikal, matematika, at web document, upang higit pang mapabuti ang pagganap ng modelo sa pangangatwiran at problem solving skills, na mahalaga para sa code generation. Nagsasanay kami ng lahat ng aming modelo para sa 500B token (80% code at 20% language data) sa phase 2 training. Phase 2 (code + language training) 4.2 Layunin ng Pagsasanay Para sa pagsasanay ng lahat ng aming modelo, ginagamit namin ang causal language modeling objective at Fill-In
