Szerzők: 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 Részletek A kóddal képzett nagy nyelvi modellek (LLM-ek) forradalmasítják a szoftverfejlesztési folyamatot. Egyre inkább a kód LLM-eket integrálják a szoftverfejlesztői környezetekbe az emberi programozók termelékenységének javítása érdekében, és az LLM-alapú ügynökök ígéretesnek mutatkoznak összetett feladatok autonóm kezelésében. A kód LLM-ek teljes potenciáljának megvalósítása széles körű képességeket igényel, beleértve a kódgenerálást, a hibák javítását, a kód magyarázatát és dokumentálását, a adattárak karbantartását és még sok mást. Ebben a munkában bemutatjuk a dekóder-only kódmodellek Granite sorozatát kódgenerálási feladatokhoz, 116 programozási nyelven írt kóddal képezve. A Granite Code modellek családja 3 és 34 milliárd paraméter közötti méretű modelleket tartalmaz, amelyek alkalmasak olyan alkalmazásokhoz, mint az összetett alkalmazásmodernizálási feladatoktól a memóriakorlátozott, eszközön belüli használati esetekig. A feladatok átfogó készletén végzett értékelés kimutatja, hogy a Granite Code modellek következetesen elérik az elérhető nyílt forráskódú kód LLM-ek között a legmodernebb teljesítményt. A Granite Code modellcsaládot vállalati szoftverfejlesztési munkafolyamatokra optimalizálták, és jól teljesít különféle kódolási feladatokban (pl. kódgenerálás, javítás és magyarázat), így sokoldalú "mindenre alkalmas" kódmodell. Minden Granite Code modellünket Apache 2.0 licenc alatt tesszük közzé mind kutatási, mind kereskedelmi célú felhasználásra. https://github.com/ibm-granite/granite-code-models 1 Bevezetés Az elmúlt évtizedekben a szoftver minden társadalmi aspektus szövetévé vált. Ahogy a szoftverfejlesztés iránti igény növekszik, kritikusabbá válik a szoftverfejlesztési termelékenység növelése, és az LLM-ek ígéretes utat kínálnak az emberi programozók kiegészítésére. Az LLM-ek kiemelkedő vállalati felhasználási esetei a szoftverfejlesztési termelékenységben a kódgenerálás, kódmagyarázat, kódjavítás, egységteszt és dokumentációgenerálás, alkalmazásmodernizálás, sebezhetőségészlelés, kódfordítás és még sok más. Az elmúlt években gyors fejlődés tapasztalható az LLM-ek kódgenerálási és manipulációs képességeiben, és ma már számos lenyűgöző kódolási képességekkel rendelkező modell áll rendelkezésre. A modellek mérete az egymilliárdos paraméterektől (pl. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024) stb.) a több száz milliárdig terjed: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), és eltérnek a szándékolt felhasználás általános jellegében, mivel egyes modellek a kódoláson kívüli felhasználási területeket céloznak meg, míg mások elsősorban kódolási feladatokra összpontosítanak (pl. StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), és CodeGemma (CodeGemma Team et al., 2024)). Azonban továbbra is fontos hiányosságok vannak a kód LLM-ek jelenlegi területén, különösen a vállalati szoftverfejlesztés kontextusában. Először is, bár a nagyon nagy, általános LLM-ek kiváló kódolási teljesítményt érhetnek el, méretük miatt drágák a telepítésük. A kisebb, kódra fókuszáló modellek ( , ; , ; , ; , ; , ) kiváló kódgenerálási teljesítményt érhetnek el kisebb és rugalmasabb csomagban, de a kódolási feladatok (pl. javítás és magyarázat) teljesítménye elmaradhat a kódgenerálási teljesítménytől. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 Számos vállalati kontextusban a kód LLM-ek adaptációját tovább bonyolíthatják a modellek teljesítményét meghaladó tényezők. Például még a nyílt modellek is szenvednek az adatok forrásairól és az adatfeldolgozási módszerekről való átláthatóság hiányától, ami csökkentheti a bizalmat a kritikus fontosságú és szabályozott kontextusokban lévő modellekben. Továbbá, a mai nyílt LLM-ek licencfeltételei akadályozhatják és bonyolíthatják egy vállalkozás egy modell használati képességét. Itt bemutatjuk a Granite Code modelleket, egy sor rendkívül képes kód LLM-et, amelyeket a vállalati szoftverfejlesztés támogatására terveztek különféle kódolási feladatokban. A Granite Code modelleknek két fő változata van, amelyeket négy különböző méretben (3B, 8B, 20B és 34B) adunk ki: alap alapmodellek kódolással kapcsolatos feladatokhoz; Granite Code Base: utasításkövető modellek, amelyeket Git commitok és emberi utasítások, valamint nyílt forráskódú, szintetikusan generált kódutasítási adatkészletek kombinációjával finomhangoltunk. Granite Code Instruct: A sorozat alapmodelljeit a nulláról, kétfázisú képzési stratégiával képeztük. Az 1. fázisban modellünket 116 programozási nyelvből származó 3-4 trillió tokenen képezzük, biztosítva a programozási nyelvek és szintaxis átfogó megértését. A 2. fázisban modellünket további 500 milliárd tokenen képezzük, gondosan megtervezett keverékkel, kiváló minőségű kód- és természetes nyelvi adatokból, hogy javítsuk a modell érvelési képességét. Mindkét képzési fázisban az önfelügyelt nyelvi modellezési célkitűzést használjuk az alapmodellek képzéséhez. Az utasításmodellek a fent képzett alapmodellek tovább finomhangolásával származnak, a CommitPack ( , ) szűrt változatának, természetes nyelvi utasításkövető adatkészleteknek (OASST ( , ), HelpSteer ( , )) és nyílt forráskódú matematikai adatkészleteknek (MathInstruct ( , ) és MetaMathQA ( , )), beleértve a szintetikusan generált kódadatokat az utasításkövetés és az érvelési képességek javítása érdekében. Muennighoff et al. 2023 Ko¨pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Kiterjedt értékeléseket végzünk kód LLM-jeinkről egy átfogó benchmark készleten, beleértve a HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) és másokat. Ez a benchmark készlet sokféle kódolási feladatot foglal magában, túl a Python kód generálásán, pl. kódjavítás, kódmagyarázat, kód szerkesztés, kódfordítás stb. a legtöbb fő programozási nyelven (Python, JavaScript, Java, Go, C++, Rust stb.). Muennighoff et al. 2023 Austin et al. 2021 Liu et al. 2023a Liu et al. 2023b Wang et al. 2022 Megállapításaink feltárják, hogy a nyílt forráskódú modellek között a Granite Code modellek általában nagyon erős teljesítményt mutatnak minden modellméretben és benchmarkon (gyakran felülmúlva más, kétszer nagyobb nyílt forráskódú kódmodelleket is, mint a Granite). Illusztrációként az 1. ábra (felső rész) bemutatja a Granite-8B-Code-Base és más nyílt forráskódú alap kód LLM-ek összehasonlítását, beleértve a nemrégiben nagy teljesítményű általános célú alap LLM-eket, mint a Mistral ( , ) és az LLama-3 ( , ) a HumanEvalPack-en ( , ). Míg a CodeGemma és a StarCoder2 elfogadhatóan teljesít a kódgenerálásban, jelentősen rosszabbul teljesítenek a HumanEvalPack kódjavítási és magyarázati változaton. Átlagosan a Granite-8B-Code-Base közel 12 ponttal (33,2% vs 21,3%) múlja felül a legversenyképesebb CodeGemma-8B modellt a HumanEvalPack-en, annak ellenére, hogy jelentősen kevesebb tokenen (< 4,5T vs 7,5T token) képezték. Az alapmodelleken túl, a Granite Code modellek utasításokkal finomhangolt változatai is erős teljesítményt mutatnak a HumanEvalPack-en, felülmúlva más nyílt forráskódú (kód) utasításmodelleket, bemutatva az előnyöket a kódolási feladatok szélesebb körénél természetes nyelvi utasításokkal (lásd az 1. ábra (alsó rész)). Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 Továbbá, mivel az érvelés kritikus a bonyolult kérdések és feladatok megoldásához, teszteljük a Granite-8B-Code-Base modellünket hat matematikai benchmarkon, beleértve a MATH ( , ), GSM8K ( , ) és problémamegoldás számítási eszközökkel, ahol a Granite 8B modellünk jobb teljesítményt ér el a legtöbb state-of-the-art 7B vagy 8B LLM-hez képest. Például a Granite-8B-Code-Base ∼12 ponttal múlja felül a Llama-3-8B-Base modellt a GSM8K-n és ∼6 ponttal a MATH-on (lásd a 15. táblázatot). Cobbe et al. 2021 Cobbe et al. 2021 A Granite Code modellek fő előnyei közé tartoznak: : A Granite Code modellek versenyképes vagy state-of-the-art teljesítményt érnek el különféle kódolással kapcsolatos feladatokban, beleértve a kódgenerálást, magyarázatot, javítást, szerkesztést, fordítást stb., bizonyítva sokoldalú kódolási feladatok megoldásának képességét; Mindenre alkalmas kód LLM : Minden modellünket engedélyezett adatokon képeztük, amelyeket az IBM AI etikai elvei szerint gyűjtöttek, és az IBM Vállalati Jogi Csapata irányította a megbízható vállalati felhasználás érdekében. Minden Granite Code modellt Apache 2.0 licenc alatt adunk ki. Megbízható vállalati minőségű LLM 1 Az adatgyűjtési, szűrési és előfeldolgozási folyamatot a 2. szakaszban írjuk le. . A 3. szakasz a modellarchitektúra részleteit írja le, amelyet a 4. szakaszban a képzési részletek követnek. Az 5. szakasz az utasításfinomhangolás részleteit tartalmazza, a 6. szakasz pedig a kísérleteket és az eredményeket ismerteti, amelyek összehasonlítják a Granite Code modelleket más nyílt forráskódú LLM-ekkel. 2 2 Adatgyűjtés Ebben a szakaszban leírjuk a kódadatok modellezéshez való előkészítéséhez használt másolási és szűrési (2.1. szakasz), deduplikációs (2.2. szakasz), HAP/PII szűrési (2.3. szakasz) folyamatot. Emellett áttekintést adunk a modell nyelvi megértésének és matematikai érvelési készségeinek javítására használt kiváló minőségű természetes nyelvi adatokról is. 2.1 Adatmásolás és Szűrés Az előképzési kódadatokat nyilvánosan elérhető adatkészletek kombinációjából szereztük be, mint például a Github Code Clean , StarCoderdata , valamint további nyilvános kód adattárakból és GitHub problémákból. A nyers adatokat szűrjük, hogy 300+ programozási nyelv közül 116 nyelvet tartsunk meg, ahogy az A. melléklet felsorolja. Az adatok programnyelvekhez való hozzárendelése kizárólag a fájlkiterjesztés alapján történik, hasonlóan a StarCoderhez ( , ). A nyelvi szűrés után négy fő szűrési szabályt alkalmazunk az alacsonyabb minőségű kód kiszűrésére ( , ): (1) távolítsuk el a 25%-nál kevesebb alfanumerikus karaktert tartalmazó fájlokat, (2) az XSLT nyelv kivételével, szűrjük ki azokat a fájlokat, ahol az "<?xml version=”" sztring az első 100 karakteren belül található, (3) HTML fájlok esetében csak azokat a fájlokat tartsuk meg, amelyeknél a látható szöveg az HTML kód legalább 20%-át teszi ki, és legalább 100 karakter hosszú, (4) JSON és YAML fájlok esetében csak azokat a fájlokat tartsuk meg, amelyek karakter száma 50 és 5000 karakter között van. Szűrjük a GitHub problémákat is minőségi metrikák egy készletével, amely magában foglalja az automatikusan generált szövegek eltávolítását, a nem angol nyelvű problémák szűrését, a botok kommentjeinek kizárását, és a beszélgetésben részt vevő felhasználók számának minőségi mutatóként való használatát. Minden kód fájlt licencinformációkkal is ellátunk, amelyek az adott adattárral kapcsolatosak, a Github API-n keresztül, és csak engedélyezett licencekkel rendelkező fájlokat tartunk meg a modell képzéséhez. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Pontos és Fuzzy Deduplikáció Aggresszív deduplikációs stratégiát alkalmazunk, beleértve a pontos és fuzzy deduplikációt is, hogy eltávolítsuk az (közel) azonos kód tartalmú dokumentumokat a képzési készletünkből. A pontos deduplikációhoz először kiszámítjuk a dokumentumtartalom SHA256 hash-ét, és eltávolítjuk az azonos hash-ekkel rendelkező rekordokat. A pontos deduplikáció után fuzzy deduplikációt alkalmazunk, amelynek célja a kismértékben eltérő kód fájlok eltávolítása, és ezáltal az adatok további torzításmentesítése. Ehhez egy kétlépéses módszert alkalmazunk: (1) kiszámítjuk az összes dokumentum MinHash-ét, majd a Helyileg Érzékeny Hashelést (LSH) használjuk a dokumentumok MinHash ujjlenyomatuk alapján történő csoportosítására, (2) kiszámítjuk a Jaccard hasonlóságot minden dokumentumpár között ugyanabban a bucketben, és az egyik kivételével az összes dokumentumot másolatként jelöljük meg egy 0,7-es hasonlósági küszöbérték alapján. Ezt a közel-deduplikációs folyamatot minden programnyelvre alkalmazzuk, beleértve a GitHub problémákat is, hogy növeljük a képzési adatkészlet gazdagságát és sokféleségét. 2.3 HAP, PII, Kártevő Szűrés Annak érdekében, hogy csökkentsük a gyűlöletkeltő, bántó vagy obszcén (HAP) nyelv modellekből való generálásának valószínűségét, lelkiismeretesen törekszünk a HAP tartalom szűrésére a képzési készletből. Először létrehozunk egy HAP kulcsszótárat, majd minden kód dokumentumot ellátunk a tartalom, beleértve a megjegyzéseket is, ilyen kulcsszavak előfordulásainak számával. Szűrjük azokat a dokumentumokat, amelyek meghaladják a HAP küszöböt, amelyet eloszlási elemzés, valamint kód fájlok kézi ellenőrzése alapján számítunk ki. Ezenkívül a magánélet védelme érdekében követjük a StarCoder ( , ) módszerét, és lelkiismeretesen törekszünk a személyazonosításra alkalmas információk (PII) vörösre festésére a képzési készletből. Pontosabban, a StarPII modellt használjuk IP-címek, kulcsok, e-mail címek, nevek, felhasználónevek és jelszavak észlelésére a tartalom. A PII vörösre festési lépés a PII szöveget a megfelelő tokenekkel (NAME, EMAIL, KEY, PASSWORD) helyettesíti, és az IP-címet egy szintetikusan generált IP-címmel cseréli le, mint Li et al. (2023a) esetében. Azt is átvizsgáljuk az adatkészleteinket, hogy azonosítsuk és eltávolítsuk a kártevők forráskódjában található példányokat. Li et al. 2023a 4 2.4 Természetes Nyelvi Adatkészletek A modellképzéshez kódadatok gyűjtése mellett számos nyilvánosan elérhető, kiváló minőségű természetes nyelvi adatkészletet kurálunk a modell nyelvi megértésének és matematikai érvelésének javítása érdekében. Az ebbe a kategóriába tartozó tipikus adatkészletek közé tartoznak webdokumentumok (Stackexchange, CommonCrawl), matematikai weben (OpenWeb-Math; ( ), StackMathQA; ( )), tudományos szövegek (Arxiv, Wikipedia) és utasításfinomhangolási adatkészletek (FLAN; ( ), HelpSteer ( , )). Nem deduplikáljuk ezeket az előre feldolgozott természetes nyelvi adatkészleteket. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Modell Architektúra Különböző méretű kódmodellek sorozatát képezzük a transzformer dekóder architektúrára ( , ) alapozva. Ezeknek a modelleknek a hiperparaméterei az 1. táblázatban találhatók. Minden modellarchitektúrához pre-normalizálást ( , ) használunk: normalizálás az figyelem és az MLP blokkok bemenetén. Vaswani et al. 2017 Xiong et al. 2020 : A Granite-code modellcsalád legkisebb modelljét RoPE beágyazással ( , ) és Multi-Head Attention-nel ( , ) képezzük. Ez a modell a swish aktiválási funkciót ( , ) GLU-val ( , ) használja az MLP-hez, amelyet gyakran swiglu-nak is neveznek. Normalizáláshoz RMSNormot ( , ) használunk, mivel ez számításilag hatékonyabb, mint a LayerNorm ( , ). A 3B modellt 2048 tokenes kontextushosszal képezzük. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : A 8B modell hasonló architektúrával rendelkezik, mint a 3B modell, kivéve a Grouped-Query Attention (GQA) ( , ) használatát. A GQA használata jobb kompromisszumot kínál a modell teljesítménye és az inference hatékonysága között ezen a skálán. A 8B modellt 4096 tokenes kontextushosszal képezzük. 8B Ainslie et al. 2023 : A 20B kódmodellt tanult abszolút pozíciós beágyazásokkal képezzük. A Multi-Query Attentiont ( , ) használjuk képzés közben a hatékony utólagos inference érdekében. Az MLP blokkhoz a GELU aktiválási funkciót ( , ) használjuk. Az aktiválások normalizálásához LayerNormot ( , ) használunk. Ez a modell 8192 tokenes kontextushosszal kerül képzésre. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : A 34B modell képzéséhez a 20B modell mélységének növelésére vonatkozó megközelítést követjük. Konkrétan először megduplázzuk a 52 rétegű 20B kódmodellt, majd eltávolítjuk az eredeti modell utolsó 8 rétegét és a duplikált modell első 8 rétegét, hogy két modellt hozzunk létre. 34B Kim et al. Végül mindkét modellt összekapcsoljuk a Granite-34B-Code modellel, amely 88 réteget tartalmaz (lásd a 12. ábra illusztrációját). A mélységnövelés után azt tapasztaljuk, hogy a teljesítménycsökkenés a 20B modellhez képest igen csekély, ellentétben azzal, amit megfigyeltek. Ez a teljesítmény meglehetősen gyorsan helyreáll, miután folytatjuk a megnövelt 34B modell előképzését. Hasonlóan a 20B-hoz, 8192 tokenes kontextust használunk az előképzés során. 2 Kim et al. 4 Előképzés Ebben a szakaszban részletezzük a kétfázisú képzést (4.1. szakasz), a képzési célokat (4.2. szakasz), az optimalizálást (4.3. szakasz) és az infrastruktúrát (4.4. szakasz), amelyeket a modellek előképzéséhez használtunk. 4.1 Kétfázisú Képzés A Granite Code modelleket 3,5–4,5T token kódadatokon és kódhoz kapcsolódó természetes nyelvi adatkészleteken képezzük. Az adatokat byte pair encoding (BPE, ( , )) segítségével tokenizáljuk, ugyanazt a tokenizert használva, mint a StarCoder ( , ). A ( , ; , ) nyomán kiváló minőségű adatokat használunk két képzési fázisban a következők szerint. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Az 1. fázisban mind a 3B, mind a 8B modelleket 4 trillió token kódadatokon képezzük, 116 nyelvet foglalva magában. A 20B paraméteres modellt 3 trillió token kódon képezzük. 1. Fázis (csak kód képzés)
