```html 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 Összefoglalás A kódon 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ési 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 komplex feladatok önálló 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 hibajavítást, a kód magyarázatát és dokumentálását, a tárolók karbantartását és még sok mást. Ebben a munkában bemutatjuk a dekóder-alapú kódmodellek Granite sorozatát kódgenerálási feladatokra, 116 programozási nyelven írt kódra képezve. A Granite Code modellek családja 3 és 34 milliárd paraméter közötti méretű modelleket foglal magában, amelyek alkalmasak olyan alkalmazásokhoz, mint a komplex alkalmazásmodernizálási feladatok vagy az eszközön belüli, memóriakorlátos felhasználási esetek. A feladatok átfogó készletén végzett értékelés azt mutatja, 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 munkafolyamatokhoz optimalizáltuk, és jól teljesít a kódolási feladatok széles skáláján (pl. kódgenerálás, javítás és magyarázat), így sokoldalú "minden az egyben" kódmodell. Minden Granite Code modellünket Apache 2.0 licenc alatt adjuk ki kutatási és 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 aspektusunk szövetévé vált. Ahogy a szoftverfejlesztés iránti kereslet megugrik, létfontosságúvá vált 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 területei a szoftverfejlesztési termelékenységben magukban foglalják a kódgenerálást, kódmagyarázatot, kódjavítást, egységteszt- és dokumentációgenerálást, alkalmazásmodernizálást, sérülékenységészlelést, kódfordítást és még sok mást. Az elmúlt években gyors előrelépés történt az LLM-ek kódgenerálási és -manipulálási 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 tervezett felhasználás általánosságában, egyes modellek a kódoláson kívüli feladatok széles körét célozzák meg, míg mások elsősorban kódolással kapcsolatos 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 célú LLM-ek kiváló kódolási teljesítményt érhetnek el, méretük miatt drágák a bevetéshez. A kisebb, kódra fókuszáló modellek ( , ; , ; , ; , ; , ) kisebb és rugalmasabb csomagban is kiváló kódgenerálási teljesítményt érhetnek el, de a generáláson túli 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 elfogadása tovább bonyolódhat a modellek teljesítményét meghaladó tényezők miatt. Például, még a nyílt modellek is néha átláthatóság hiányával küszködnek az adrásforrásokat és adatfeldolgozási módszereket illetően, ami alááshatja a bizalmat a kritikus és szabályozott kontextusokban. Továbbá, a mai nyílt LLM-ek licencfeltételei megterhelhetik és bonyolíthatják a vállalkozások számára a modellek használatát. Itt bemutatjuk a Granite Code modelleket, egy sor rendkívül képzett kód LLM-et, amelyeket a vállalati szoftverfejlesztés támogatására terveztek a kódolási feladatok széles skáláján. A Granite Code modellek két fő változattal rendelkeznek, 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ód utasításkészletek kombinációjával finomhangoltak. Granite Code Instruct: A sorozat alapmodelljeit a nulláról képezték, kétfázisú képzési stratégiával. Az 1. fázisban modellünket 116 programozási nyelven írt 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, kiváló minőségű kód- és természetes nyelvi adatok keverékével, hogy javítsuk a modell érvelési képességét. A képzési mindkét fázisában az alapmodelleket felügyelet nélküli nyelvi modellezési célkitűzéssel képezzük. Az utasításmodellek a fent kiképzett alapmodellek további finomhangolásával származnak egy szűrt CommitPack ( , ) változata, természetes nyelvi utasításkövető adatkészletek (OASST ( , ), HelpSteer ( , )) és nyílt forráskódú matematikai adatkészletek (MathInstruct ( , ) és MetaMathQA ( , )) kombinációján, beleértve a szintetikusan generált kód adatkészleteket az utasításkövetés és é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-jeinken egy átfogó benchmarkkészleten, beleértve a HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) és egyebeket. Ez a benchmarkkészlet számos különböző típusú kódolási feladatot foglal magában a Pythonban történő kódösszeállításon túl, 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 szerint a nyílt forráskódú modellek között a Granite Code modellek összességében nagyon erős teljesítményt mutatnak minden modellméretben és benchmarkon (gyakran felülmúlják a kétszer akkora nyílt forráskódú kódmodelleket, mint a Granite). Illusztrációként az 1. ábra (felső rész) összehasonlítja a Granite-8B-Code-Base modellt más nyílt forráskódú alap kód LLM-ekkel, beleértve a legutóbbi, nagy teljesítményű általános célú alap LLM-eket, mint a Mistral ( , ) és az LLama-3 ( , ) modelleket a HumanEvalPack (Muennighoff et al., 2023) esetében. Míg a CodeGemma és a StarCoder2 elfogadhatóan teljesítenek a kódgenerálásban, jelentősen rosszabbul teljesítenek a HumanEvalPack kódjavítási és magyarázati változataiban. Átlagosan a Granite-8B-Code-Base majdnem 12 ponttal múlja felül a legversenyképesebb CodeGemma-8B modellt a HumanEvalPackon (33,2% vs. 21,3%), annak ellenére, hogy jelentősen kevesebb tokenen képzették (4,5T vs. 7,5T token). Az alap modellek mellett az utasításokkal finomhangolt Granite Code modelljeink is erős teljesítményt mutatnak a HumanEvalPackon, felülmúlva más nyílt forráskódú (kód) utasításmodelleket, ami a természetes nyelvi utasításokkal végzett kódolási feladatok szélesebb körére gyakorolt előnyöket mutatja (lásd az 1. ábra (alsó rész)). Jiang et al. 2023b AI@Meta 2024 Továbbá, mivel az érvelés kritikus a bonyolult kérdések és feladatok megoldásához, Granite-8B-Code-Base modellünket hat matematikai benchmarkon is teszteljük, beleértve a MATH ( , ), GSM8K ( , ) és számítási eszközökkel való problémamegoldást, ahol Granite 8B modellünk jobb teljesítményt ér el, mint a legtöbb állapota szerinti 7B vagy 8B LLM. 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 kulcsfontosságú előnyei közé tartoznak: : A Granite Code modellek versenyképes vagy legmagasabb teljesítményt érnek el a kódolással kapcsolatos feladatok különböző típusain, 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ára való képességüket; Minden az egyben kód LLM : Minden modellünket licencileg megengedett adatokon képeztük, amelyeket az IBM AI Etikai elvei alapján gyűjtöttek, és az IBM Vállalati Jogi Csapatának iránymutatása mellett a megbízható vállalati használat érdekében. Minden Granite Code modellt Apache 2.0 licenc alatt adunk ki. Megbízható, vállalati szintű LLM 1 Az adatszerzés, szűrés és előfeldolgozás teljes folyamatát a 2. szakaszban írjuk le. A 3. szakasz a modellarchitektúra részleteit írja le, amelyet a 4. szakaszban tárgyalt képzési részletek követnek. Az 5. szakasz az utasításfinomhangolás részleteit ismerteti, a 6. szakasz pedig a kísérleteket és eredményeket, összehasonlítva a Granite Code modelleket más nyílt forráskódú LLM-ekkel. 2 Adatgyűjtés Ebben a részben leírjuk a kódadatok modellek képzésére való előkészítéséhez használt mászás és szűrés (2.1. szakasz), deduplikáció (2.2. szakasz), HAP/PII szűrés (2.3. szakasz) folyamatát. 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ódadatok nyilvánosan elérhető adatkészletek, mint a Github Code Clean , StarCoderdata , valamint további nyilvános kód-repozitóriumok és GitHub-ügyek kombinációjából származtak. A nyersadatokat 300+ nyelv közül 116 programozási nyelvre szűrjük, az A. mellékletben felsoroltak szerint. Az adatok programozási nyelvekhez való hozzárendelése kizárólag a fájlkiterjesztés alapján történik, hasonlóan a StarCoderhez ( , ). A nyelvszűrés után négy kulcsfontosságú 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=”" karakterlánc az első 100 karakteren belül található, (3) HTML fájlok esetében csak azokat a fájlokat tartsuk meg, ahol 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 az 50 és 5000 karakter közötti karaktercounttal rendelkező fájlokat tartsuk meg. A GitHub-ügyeket is szűrjük minőségi mutatók készletével, amelyek magukban foglalják az automatikusan generált szövegek eltávolítását, a nem angol nyelvű ügyek kiszűrését, a botok megjegyzéseinek kizárását, és a minőségi mutatóként a beszélgetésben részt vevő felhasználók számának felhasználását. Minden kódfájlt licencinformációkkal is ellátunk, amelyek a megfelelő repozitóriumhoz kapcsolódnak, a GitHub API-n keresztül, és csak a licencelt, engedélyezett licencekkel rendelkező fájlokat tartjuk meg a modellek képzéséhez. 2 3 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 a képzési készletünkben (közel) azonos kód tartalmú dokumentumokat. A pontos deduplikációhoz először SHA256 hash-t számítunk a dokumentum tartalmán, é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 kis eltéréseket tartalmazó kódfájlok eltávolítása, ezáltal az adatok további torzításának csökkentése. Ehhez egy kétrészes módszert alkalmazunk: (1) MinHash-eket számítunk az összes dokumentumról, majd a Lokálisan Érzékeny Hashelést (LSH) használjuk a dokumentumok MinHash ujjlenyomataik alapján történő csoportosítására, (2) az azonos bucketen belüli dokumentumpárok Jaccard-hasonlóságát mérjük, és az egyik dokumentum kivételével az összes többit kettős másolatként jelöljük meg a 0,7-es hasonlósági küszöb alapján. Ezt a közelítő deduplikációs eljárást minden programozási nyelvre, beleértve a GitHub-ügyeket is, alkalmazzuk a képzési adatkészlet gazdagságának és sokféleségének növelése érdekében. 2.3 HAP, PII, Malware Szűrés Annak érdekében, hogy csökkentsük a gyűlöletkeltő, bántalmazó vagy profán (HAP) nyelv generálásának valószínűségét a modellekből, gondos erőfeszítéseket teszünk a HAP tartalom szűrésére a képzési készletből. Először létrehozunk egy szótárat HAP kulcsszavakból, majd minden kód dokumentumot ellátunk az ilyen kulcsszavak előfordulási számával a tartalommal, beleértve a megjegyzéseket is. Kiszelektáljuk azokat a dokumentumokat, amelyek meghaladják a HAP küszöböt, amelyet eloszlási elemzés, valamint a kódfájlok manuális ellenőrzése alapján számítunk ki. Ezenkívül, az adatvédelem érdekében, követjük a StarCoder ( , ) módszerét, és gondos erőfeszítéseket teszünk a személyazonosító adatok (PII) vörösre festésére a képzési készletben. 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 helyettesíti: NAME , EMAIL , KEY , PASSWORD , és az IP-címet szintetikusan generált IP-címmel helyettesítjük, mint Li et al. (2023a) esetében. Emellett a forráskódban található malware példányok azonosítására és eltávolítására is átvizsgáljuk az adatokat. Li et al. 2023a 4 2.4 Természetes Nyelvi Adatkészletek A modellek képzéséhez szükséges kódadatok gyűjtése mellett, több nyilvánosan elérhető, kiváló minőségű természetes nyelvi adatkészletet kurálunk a modell nyelvi megértésében és matematikai érvelésében való jártasságának javítása érdekében. Az ebbe a kategóriába tartozó reprezentatív adatkészletek közé tartoznak webes dokumentumok (Stackexchange, CommonCrawl), matematikai webes szövegek (OpenWeb-Math; ( ), StackMathQA; ( )), tudományos szövegek (Arxiv, Wikipedia) és utasításfinomhangoló adatkészletek (FLAN; ( ), HelpSteer ( , )). Ezeket az előre feldolgozott természetes nyelvi adatkészleteket nem deduplikáljuk. 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. A modellek hiperparaméterei az 1. táblázatban találhatók. Minden modellarchitektúrához elő-normalizálást ( , ) használunk: az attenciós és MLP blokkok bemenetére alkalmazott normalizálást. Vaswani et al. 2017 Xiong et al. 2020 : A Granite-code modellcsalád legkisebb modelljét RoPE embeddinggel ( , ) és Multi-Head Attention-nel ( , ) képezzük. Ez a modell a swish aktiválási funkciót ( , ) használja GLU-val ( , ) az MLP-hez, amelyet gyakran swiglu-nak is neveznek. A normalizáláshoz RMSNorm-ot ( , ) használunk, mivel számítási szempontból hatékonyabb, mint a LayerNorm ( , ). A 3B modellt 2048 tokenes kontextushosszúsággal 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, azzal a kivétellel, hogy Grouped-Query Attention-t (GQA) ( , ) használ. A GQA használata jobb kompromisszumot kínál a modell teljesítménye és az inferencia hatékonysága között ezen a skálán. A 8B modellt 4096 tokenes kontextushosszúsággal képezzük. 8B Ainslie et al. 2023 : A 20B kódmodellt tanult abszolút pozíció embeddingekkel képezzük. A Multi-Query Attention-t ( , ) használjuk képzés közben a hatékony lefelé irányuló következtetés érdekében. Az MLP blokkhoz a GELU aktiválási funkciót ( , ) használjuk. Az aktiválások normalizálásához LayerNorm-ot ( , ) használunk. Ezt a modellt 8192 tokenes kontextushosszúsággal képezzük. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : A 34B modell képzéséhez a 20B modell mélységi skálázására 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 annak másolatának első 8 rétegét, hogy két modellt hozzunk létre. 34B Kim et al. Végül mindkét modellt összefűzzük, hogy létrehozzuk a Granite-34B-Code modellt 88 réteggel (lásd a 2. ábrát az illusztrációhoz). A mélységi skálázás után azt tapasztaljuk, hogy a 20B modellhez képesti teljesítménycsökkenés meglehetősen kicsi, ellentétben azzal, amit megfigyeltek. Ez a teljesítmény meglehetősen gyorsan helyreáll, miután folytatjuk a skálázott 34B modell előképzését. Hasonlóan a 20B modellhez, előképzés során 8192 tokenes kontextust használunk. Kim et al. 4 Előképzés Ebben a részben a modellek előképzéséhez használt kétfázisú képzés (4.1. szakasz), képzési célkitűzések (4.2. szakasz), optimalizálás (4.3. szakasz) és infrastruktúra (4.4. szakasz) részleteit ismertetjük. 4.1 Kétfázisú Képzés A Granite Code modelleket 3,5T-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 tokenizálót használva, mint a StarCoder ( , ). A ( , ; , ) alapján, kiváló minőségű adatokat használunk két képzési fázisban az alábbiak 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, amelyek 116 nyelvet foglalnak magukban. A 20B paraméteres 1. fázis (csak kód képzés)
