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 gyakrabban integrálják a kódbázisú LLM-eket 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 összetett feladatok önálló kezelésében. A kódbázisú LLM-ek teljes potenciáljának megvalósítása számos képességet 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árhelyek karbantartását és még sok mást. Ebben a munkában bemutatjuk a kódgenerálási feladatokhoz készült, dekóder-alapú kódmodellek Granite sorozatát, amelyet 116 programozási nyelven írt kódra képeztek. A Granite Code modellek családja 3 és 34 milliárd paraméter közötti méretű modelleket tartalmaz, amelyek alkalmasak az összetett alkalmazásmodernizációs feladatoktól a fedélzeti, memóriakorlátozott használati esetekig terjedő alkalmazásokhoz. A feladatok átfogó készletén végzett értékelés kimutatja, hogy a Granite Code modellek következetesen az elérhető nyílt forráskódú kód LLM-ek között csúcsteljesítményt érnek el. A Granite Code modellek családját vállalati szoftverfejlesztési munkafolyamatokhoz optimalizálták, és jól teljesít a kódolási feladatok széles körében (pl. kódgenerálás, javítás és magyarázat), így sokoldalú „mindenes” kódmodell. Minden Granite Code modellünket Apache 2.0 licenc alatt tesszük közzé kutatási és kereskedelmi célokra egyaránt. https://github.com/ibm-granite/granite-code-models 1 Bevezetés Az elmúlt évtizedekben a szoftver szinte minden aspektusát áthatotta társadalmunknak. Mivel a szoftverfejlesztés iránti igény rohamosan növekszik, kritikusabbá 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 kiemelt vállalati használati 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égdetektálá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á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ó paraméteres modellektől (pl. Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), stb.) a több százmillióig terjed: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), és eltérnek a tervezett használat általánosságában, egyes modellek a kódokon kívüli felhasználási területeket célozzák meg, míg mások elsősorban a 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 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ódorientált modellek ( , ; , ; , ; , ; , ) kiváló kódgenerálási teljesítményt érhetnek el kisebb és rugalmasabb csomagban, 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ását tovább bonyolíthatják a modellek teljesítményén túli tényezők. Például még a nyílt modelleket is gyakran átláthatóság hiánya jellemzi az adathordozókról és az adatfeldolgozási módszerekről, amelyek a modellbe kerültek, ami ronthatja a bizalmat a kritikus és szabályozott kontextusokban. Ezenkívül a mai nyílt LLM-ek licencfeltételei megterhelhetik és bonyolíthatják a vállalati modellhasználati képességet. Itt mutatjuk be a Granite Code modelleket, a nagy teljesítményű kód LLM-ek sorozatát, amelyeket a vállalati szoftverfejlesztés támogatására terveztek a kódolási feladatok széles körében. 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: alapvető modellek kódolási 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ási adatkészletek kombinációjával finomhangoltunk. 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 a modellt 116 programozási nyelvből származó 3–4 trillió tokenen képezzük, biztosítva a programozási nyelvek és a szintaxis átfogó megértését. A 2. fázisban a modellt további 500 milliárd tokenen képezzük, gondosan megtervezett, kiváló minőségű adatok keverékével a kód és a természetes nyelv területeiről, hogy javítsuk a modell érvelési képességeit. Felügyelt nyelvmodell-objektumot használunk az alapmodellek képzésére mindkét fázisban. Az utasításmodellek a fent képzett alapmodellek finomhangolásával jönnek létre 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ód adatkészleteket 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 a benchmarkok átfogó készletén, beleértve a HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) és még sok mást. Ez a benchmark készlet számos különböző típusú kódolási feladatot tartalmaz, nem csak Python kód szintézist, 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 összességében nagyon erős teljesítményt mutatnak az összes modellméretben és benchmarkban (gyakran felülmúlva más nyílt forráskódú kódmodelleket, amelyek kétszer nagyobbak, mint a Granite). Illusztrációként az 1. ábra (fent) összehasonlítja a Granite-8B-Code-Base-t más nyílt forráskódú alap kód LLM-ekkel, beleértve a nemrégiben megjelent, 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ítenek a kódgenerálásban, lényegesen rosszabbul teljesítenek a HumanEvalPack kódjavítási és magyarázati változataiban. Átlagosan a Granite-8B-Code-Base közel 12 ponttal múlja felül a legversenyképesebb CodeGemma-8B modellt a HumanEvalPack-en (33,2% vs 21,3%), annak ellenére, hogy lényegesen kevesebb tokenen képzett (4,5T vs 7,5T token). Az alapmodellek mellett az utasításokkal finomhangolt Granite Code modellek 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, ami a természetes nyelvi utasításokkal végzett kódolási feladatok szélesebb körének előnyeit mutatja (lásd az 1. ábra (lent) részleteit). Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 Ezenkívül, mivel az érvelés kritikus fontosságú az összetett kérdések és feladatok megoldásában, 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 a Granite 8B modellünk jobb teljesítményt ér el, mint a legtöbb state-of-the-art 7B vagy 8B LLM. Például a Granite-8B-Code-Base ~12 ponttal múlja felül a Llama-3-8B-Base-t 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 csúcsteljesítményt érnek el a kódolási 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 képességüket a különböző kódolási feladatok megoldására; Mindenes kód LLM : Minden modellünket engedélyezett adatokon képezzük, amelyeket az IBM AI Etikai elvei szerint gyűjtöttek be, és az IBM vállalati jogi csapata irányítja a megbízható vállalati használat érdekében. Minden Granite Code modell Apache 2.0 licenc alatt kerül kiadásra. Megbízható vállalati minőségű LLM 1 Az adatgyűjtési, szűrési és előfeldolgozási folyamatunkat a 2. szakaszban írjuk le. A 3. szakasz a modellarchitektúra részleteit ismerteti, a 4. szakaszban pedig a képzési részleteket. Az 5. szakasz az utasításfinomítás részleteit tartalmazza, a 6. szakasz pedig a kísérletek és eredmények leírását mutatja be, összehasonlítva a Granite Code modelleket más nyílt forráskódú LLM-ekkel. 2 Adatgyűjtés Ebben a szakaszban leírjuk a kódadatok másolásának és szűrésének (2.1. szakasz), az ismétlődések eltávolításának (2.2. szakasz), valamint a HAP/PII szűrésének (2.3. szakasz) folyamatát, amelyeket a kódadatok modellképzéshez való elkészítéséhez használtunk. Emellett áttekintést nyújtunk a kiváló minőségű természetes nyelvi adatokról, amelyeket a modell nyelvi megértésének és matematikai érvelési képességeinek javítására használtunk. 2.1 Adatmásolás és szűrés Az előképzési kódadatok nyilvánosan elérhető adatkészletekből, mint a Github Code Clean , StarCoderdata , valamint további nyilvános kód adattárakból és a GitHub issue-kból származtak. A nyersadatokat szűrjük, hogy 300+ nyelv közül 116 programozási nyelvet tartsunk meg, 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 nyelvi szű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) eltávolítjuk a kevesebb mint 25%-ban alfabetikus karaktereket tartalmazó fájlokat, (2) az XSLT nyelv kivételével kiszűrjük azokat a fájlokat, ahol az „<?xml version=” karakterlánc az első 100 karakteren belül található, (3) HTML fájlok esetén csak azokat a fájlokat tartjuk meg, ahol a látható szöveg az HTML kód legalább 20%-át teszi ki, és minimális hossza 100 karakter, (4) JSON és YAML fájlok esetén csak azokat a fájlokat tartjuk meg, amelyek karakter száma 50 és 5000 karakter között van. A GitHub issue-kat is szűrjük minőségi mutatók egy készletével, amelyek magukban foglalják az automatikusan generált szöveg eltávolítását, a nem angol issue-k kiszűrését, a botok megjegyzéseinek kizárását, és a beszélgetésben részt vevő felhasználók számának a minőség mutatójaként való használatát. Ezenkívül minden kód fájlt az adott adattár licencinformációival látunk el, amelyeket GitHub API-kon keresztül találtunk, és csak engedélyezett licencekkel rendelkező fájlokat tartunk meg a modellképzéshez. 2 3 Li et al. 2023a Li et al. 2023a 2.2 Pontos és fuzzy ismétlődések eltávolítása Aggresszív ismétlődés-eltávolítási stratégiát alkalmazunk, beleértve a pontos és fuzzy ismétlődések eltávolítását is, hogy eltávolítsuk a képzési készletünkben a (közel) azonos kód tartalmú dokumentumokat. A pontos ismétlődések eltávolításához először SHA256 hash-t számolunk a dokumentum tartalmára, és eltávolítjuk az azonos hash-ekkel rendelkező rekordokat. A pontos ismétlődések eltávolítása után fuzzy ismétlődések eltávolítását alkalmazzuk, amelynek célja a kódfájlok eltávolítása, amelyek enyhe eltéréseket mutathatnak, ezáltal tovább torzítva az adatokat. Ehhez kétlépcsős módszert alkalmazunk: (1) MinHash-eket számolunk az összes dokumentumra, majd helyi érzékeny hashing-et (LSH) használunk a dokumentumok MinHash ujjlenyomataik alapján történő csoportosításához, (2) Jaccard hasonlóságot mérünk az azonos bucketban lévő dokumentumpárok között, és az egyik kivételével az összes dokumentumot kettősnek jelöljük a 0,7 hasonlósági küszöb alapján. Ezt a közel-ismétlődés-eltávolítási folyamatot minden programozási nyelvre alkalmazzuk, beleértve a GitHub issue-kat is, hogy javítsuk 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á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 HAP kulcsszavak szótárát, majd minden kód dokumentumot annotálunk a tartalom, beleértve a megjegyzéseket is, ilyen kulcsszavak előfordulási számával. Kisűrnénk azokat a dokumentumokat, amelyek meghaladják a HAP küszöböt, amelyet eloszlásbeli elemzés, valamint a kód fájlok kézi ellenőrzése alapján számítunk ki. Továbbá, a magánélet védelme érdekében követjük a StarCoder ( , ) megközelítését, és gondos erőfeszítéseket teszünk a személyazonosításra alkalmas információk (PII) elvonására a képzési készletből. Pontosabban, a StarPII modellt használjuk az IP-címek, kulcsok, e-mail címek, nevek, felhasználónevek és jelszavak felismerésére a tartalom. A PII elvonási lépés helyettesíti a PII szöveget a megfelelő tokenekkel: NAME, EMAIL, KEY, PASSWORD, és megváltoztatja az IP-címet egy szintetikusan generált IP-címmel, mint Li et al. (2023a). Ezenkívül átvizsgáljuk az adatkészleteinket is, hogy azonosítsuk és eltávolítsuk a kártevők előfordulásait a forráskódban. Li et al. 2023a 4 2.4 Természetes nyelvi adatkészletek A modellképzéshez 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 is összeállítunk a modell nyelvi megértésében és matematikai érvelési képességeiben való jártasságának javítása érdekében. Az ebben a kategóriában található reprezentatív adatkészletek közé tartoznak webdokumentumok (Stackexchange, CommonCrawl), matematikai webes szövegek (OpenWeb-Math; ( ), StackMathQA; ( )), tudományos szövegek (Arxiv, Wikipedia), és utasításfinomítási adatkészletek (FLAN; ( ), HelpSteer ( , )). Ezeket az előre feldolgozott természetes nyelvi adatkészleteket nem távolítjuk el az ismétlődések miatt. 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 a 10. táblázatban találhatók. Minden modellarchitektúrához előzetes normalizálást ( , ) használunk: normalizálás az figyelem és az MLP blokkok bemeneténél. Vaswani et al. 2017 Xiong et al. 2020 : A legkisebb modell a Granite-code modell családban RoPE embeddinget ( , ) és Multi-Head Attention-t ( , ) használ. Ez a modell swish aktivációs funkciót ( , ) használ GLU-val ( , ) az MLP-hez, amit gyakran swiglu-nak is neveznek. A normalizáláshoz RMSNorm-ot ( , ) használunk, mivel számításilag hatékonyabb, mint a LayerNorm ( , ). A 3B modellt 2048 tokenes kontextus hosszal 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 inferencia hatékonysága között ezen a skálán. A 8B modellt 4096 tokenes kontextus hosszal 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 Attention ( , ) használunk a képzés során a hatékony utólagos inferencia érdekében. Az MLP blokkhoz a GELU aktivációs függvényt ( , ) használjuk. Az aktivációk normalizálásához LayerNorm-ot ( , ) használunk. Ezt a modellt 8192 tokenes kontextus hosszal képezzük. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : A 34B modell képzéséhez a megközelítését követjük a 20B modell mélységbeli skálázásához. Konkrétan, először megkettőzzük a 20B kódmodellt 52 réteggel, majd eltávolítjuk az eredeti modell utolsó 8 rétegét és a kettőzött modell első 8 rétegét, hogy két modellt hozzunk létre. 34B Kim et al. Végül mindkét modellt összeillesztjük, hogy létrehozzuk a 88 rétegű Granite-34B-Code modellt (lásd a 2. ábrát az illusztrációhoz). A mélységbeli skálázás után megfigyeljük, hogy a 20B modellhez képest a teljesítménycsökkenés meglehetősen kicsi, ellentétben azzal, amit a 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-hez, 8192 tokenes kontextust használunk az előképzés során. Kim et al. 4 Előképzés Ebben a szakaszban a modellek előképzéséhez használt kétfázisú képzési (4.1. szakasz), képzési objektív (4.2. szakasz), optimalizálási (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 és 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 ( , ; , ) követve, a következő két fázisban használjuk a kiváló minőségű adatokat: Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Az 1. fázisban mind a 1. fázis (csak kód képzés)
