Autores: 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 Resumo Os modelos de linguaxe grandes (LLMs) adestrados en código están a revolucionar o proceso de desenvolvemento de software. Cada vez máis, os LLMs de código intégranse en contornos de desenvolvemento de software para mellorar a produtividade dos programadores humanos, e os axentes baseados en LLMs comezan a amosar promesas para xestionar tarefas complexas de forma autónoma. A realización do potencial total dos LLMs de código require unha ampla gama de capacidades, incluíndo a xeración de código, a corrección de erros, a explicación e documentación de código, o mantemento de repositorios e moito máis. Neste traballo, presentamos a serie Granite de modelos de código decoder-only para tarefas de xeración de código, adestrados con código escrito en 116 linguaxes de programación. A familia de modelos Granite Code consta de modelos que varían en tamaño desde 3 a 34 mil millóns de parámetros, adecuados para aplicacións que van desde tarefas complexas de modernización de aplicacións ata casos de uso con restricións de memoria no dispositivo. A avaliación nun conxunto completo de tarefas demostra que os modelos Granite Code alcanzan consistentemente un rendemento de vangarda entre os LLMs de código de código aberto dispoñibles. A familia de modelos Granite Code foi optimizada para fluxos de traballo de desenvolvemento de software empresarial e funciona ben en varias tarefas de codificación (por exemplo, xeración, corrección e explicación de código), converténdoa nun modelo de código versátil "todo en un". Publicamos todos os nosos modelos Granite Code baixo unha licenza Apache 2.0 para uso tanto de investigación como comercial. https://github.com/ibm-granite/granite-code-models 1 Introdución Durante as últimas décadas, o software teceuse no tecido de todos os aspectos da nosa sociedade. Mentres a demanda de desenvolvemento de software aumenta, é máis crítico ca nunca aumentar a produtividade do desenvolvemento de software, e os LLMs proporcionan un camiño prometedor para aumentar os programadores humanos. Os casos de uso empresariais prominentes para LLMs na produtividade do desenvolvemento de software inclúen a xeración de código, a explicación de código, a corrección de código, a xeración de probas unitarias e documentación, a modernización de aplicacións, a detección de vulnerabilidades, a tradución de código e moito máis. Os últimos anos viron un rápido progreso na capacidade dos LLMs para xerar e manipular código, e hoxe en día hai dispoñibles unha gama de modelos con impresionantes habilidades de codificación. Os modelos varían en tamaño desde miles de millóns de parámetros (por exemplo, Llama-7B (Touvron et al., 2023), Gemma-7B (Gemma-Team et al., 2024), etc.) ata centos de miles de millóns: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere), e varían na xeneralidade do uso previsto, con algúns modelos que buscan cubrir unha gama de usos fóra do código, mentres que outros se centran principalmente en tarefas relacionadas coa codificación (por exemplo, StarCoder (Li et al., 2023a; Lozhkov et al., 2024), CodeGen (Nijkamp et al., 2023), CodeLlama (Rozie`re et al., 2023), e CodeGemma (CodeGemma Team et al., 2024)). Non obstante, aínda hai importantes lagoas no campo actual dos LLMs para código, especialmente no contexto do desenvolvemento de software empresarial. En primeiro lugar, aínda que os LLMs xeneralistas moi grandes poden alcanzar un excelente rendemento de codificación, o seu tamaño fai que sexa caro implementalos. Os modelos máis pequenos centrados en código ( , ; , ; , ; , ; , ) poden alcanzar un excelente rendemento de xeración de código nun paquete máis pequeno e flexible, pero o rendemento en tarefas de codificación máis aló da xeración (por exemplo, corrección e explicación) pode quedar atrás do rendemento da xeración de código. Li et al. 2023a Lozhkov et al. 2024 Nijkamp et al. 2023 Rozie`re et al. 2023 CodeGemma Team et al. 2024 En moitos contextos empresariais, a adopción de LLMs de código pode complicarse aínda máis por factores máis aló do rendemento dos modelos. Por exemplo, mesmo os modelos abertos adoitan verse afectados pola falta de transparencia sobre as fontes de datos e os métodos de procesamento de datos que entraron no modelo, o que pode erosionar a confianza nos modelos en contextos críticos para a misión e regulados. Ademais, os termos de licenza nos LLMs abertos actuais poden dificultar e complicar a capacidade dunha empresa para usar un modelo. Aquí, presentamos os modelos Granite Code, unha serie de LLMs de código altamente capaces, deseñados para soportar o desenvolvemento de software empresarial nunha ampla gama de tarefas de codificación. Os modelos Granite Code teñen dúas variantes principais que lanzamos en catro tamaños diferentes (3B, 8B, 20B e 34B): modelos base fundamentais para tarefas relacionadas co código; Granite Code Base: modelos de seguimento de instrucións axustados utilizando unha combinación de commits de Git emparellados con instrucións humanas e conxuntos de datos de instrucións de código sintético de código aberto. Granite Code Instruct: Os modelos base da serie foron adestrados dende cero cunha estratexia de adestramento en dúas fases. Na fase 1, o noso modelo adéstrase en 3 a 4 billóns de tokens obtidos de 116 linguaxes de programación, garantindo unha comprensión completa das linguaxes de programación e da sintaxe. Na fase 2, o noso modelo adéstrase adicionalmente en 500 mil millóns de tokens cunha mestura coidadosamente deseñada de datos de alta calidade dos dominios de código e linguaxe natural para mellorar a capacidade de razoamento do modelo. Usamos o obxectivo de modelado de linguaxe non supervisado para adestrar os modelos base en ambas as fases de adestramento. Os modelos de instrución derívanse do axuste fino adicional dos modelos base adestrados anteriores nunha combinación dunha variante filtrada de CommitPack ( , ), conxuntos de datos de seguimento de instrucións en linguaxe natural (OASST ( , ), HelpSteer ( , )) e conxuntos de datos de matemáticas de código aberto (MathInstruct ( , ) e MetaMathQA ( , )), incluíndo conxuntos de datos de código xerados sinteticamente para mellorar o seguimento de instrucións e as capacidades de razoamento. Muennighoff et al. 2023 Ko¨ pf et al. 2023 Wang et al. 2023 Yue et al. 2023 Yu et al. 2023 Realizamos avaliacións extensas dos nosos LLMs de código nun conxunto completo de benchmarks, incluíndo HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ), e máis. Este conxunto de benchmarks inclúe moitos tipos diferentes de tarefas de codificación máis aló da síntese de código en Python, por exemplo, corrección de código, explicación de código, edición de código, tradución de código, etc., en case todas as linguaxes de programación principais (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 Os nosos achados revelan que entre os modelos de código aberto, os modelos Granite Code mostran un rendemento moi forte en xeral en todos os tamaños de modelos e benchmarks (a miúdo superando a outros modelos de código de código aberto que son o dobre de grandes en comparación con Granite). Como ilustración, a figura (arriba) mostra unha comparación de Granite-8B-Code-Base con outros LLMs de código base de código aberto, incluíndo LLMs base xerais de alto rendemento recentes como Mistral ( , ) e LLama-3 ( , ) en HumanEvalPack ( , ). Mentres CodeGemma e StarCoder2 funcionan razoablemente ben na xeración de código, funcionan significativamente peor nas variantes de corrección e explicación de código de HumanEvalPack. De media, Granite-8B-Code-Base supera ao modelo CodeGemma-8B máis competitivo en case 12 puntos en HumanEvalPack (33,2% fronte a 21,3%), a pesar de ser adestrado cun número significativamente menor de tokens (4,5T fronte a 7,5T tokens). Ademais dos modelos base, as variantes axustadas por instrucións dos nosos modelos Granite Code tamén mostran un forte rendemento en HumanEvalPack, superando a outros modelos de instrucións de código aberto, o que demostra os beneficios para un conxunto máis amplo de tarefas de codificación con instrucións en linguaxe natural (ver figura (abaixo)). 1 Jiang et al. 2023b AI@Meta 2024 Muennighoff et al. 2023 1 Ademais, dado que o razoamento é fundamental para resolver cuestións e tarefas complicadas, tamén probamos o noso modelo Granite-8B-Code-Base en seis benchmarks matemáticos, incluíndo MATH ( , ), GSM8K ( , ) e resolución de problemas co acceso a ferramentas computacionais, onde o noso modelo Granite 8B alcanza un mellor rendemento en comparación coa maioría dos LLMs de 7B ou 8B de vangarda. Por exemplo, Granite-8B-Code-Base supera a Llama-3-8B-Base en ~12 puntos en GSM8K e ~6 puntos en MATH (ver táboa ). Cobbe et al. 2021 Cobbe et al. 2021 1 As vantaxes clave dos modelos Granite Code inclúen: : Os modelos Granite Code logran un rendemento competitivo ou de vangarda en diferentes tipos de tarefas relacionadas co código, incluíndo xeración de código, explicación, corrección, edición, tradución, etc., demostrando a súa capacidade para resolver diversas tarefas de codificación; LLM de Código Todo-Terreno : Todos os nosos modelos son adestrados con datos permitidos por licenza recompilados seguindo os principios de ética de IA de IBM e guiados polo equipo legal corporativo de IBM para un uso empresarial confiable. Todos os modelos Granite Code publícanse baixo a licenza Apache 2.0. LLM de Nivel Empresarial Confiable 1 Describimos toda a nosa pipeline de recompilación, filtrado e preprocesamento de datos na sección . A sección describe os detalles da arquitectura do modelo, seguidos dos detalles de adestramento na Sección . A sección proporciona os detalles sobre o axuste de instrucións, e a sección describe os experimentos e resultados comparando os modelos Granite Code con outros LLMs de código aberto. 2 3 4 5 6 2 Recollida de Datos Nesta sección, describimos o proceso de rastrexo e filtrado (Secc. ), deduplicación (Secc. ), filtrado HAP/PII (Secc. ) utilizados para preparar os datos de código para o adestramento do modelo. Tamén proporcionamos unha visión xeral dos datos en linguaxe natural de alta calidade utilizados para mellorar a comprensión da linguaxe e as habilidades de razoamento matemático do modelo. 2.1 2.2 2.3 2.1 Rastrexo e Filtrado de Datos Os datos de código de pre-adestramento obtivéronse dunha combinación de conxuntos de datos dispoñibles publicamente como Github Code Clean , StarCoderdata , e repositorios e problemas públicos adicionais de GitHub. Filtramos os datos brutos para reter unha lista de 116 linguaxes de programación de máis de 300 linguaxes, como se indica no Apéndice . A asignación de datos a linguaxes de programación realízase unicamente en base á extensión do ficheiro, similar a StarCoder ( , ). Despois do filtrado de linguaxes, aplicamos catro regras de filtrado clave para eliminar código de menor calidade ( , ): (1) eliminar ficheiros con menos do 25% de caracteres alfabéticos, (2) excepto para a linguaxe XSLT, filtrar ficheiros onde a cadea “<?xml version=” aparece dentro dos primeiros 100 caracteres, (3) para ficheiros HTML, manter só os ficheiros onde o texto visible constitúe polo menos o 20% do código HTML e ten unha lonxitude mínima de 100 caracteres, (4) para ficheiros JSON e YAML, manter só os ficheiros que teñan un número de caracteres entre 50 e 5000 caracteres. Tamén filtramos os problemas de GitHub cun conxunto de métricas de calidade que inclúen a eliminación de texto xerado automaticamente, o filtrado de problemas que non sexan en inglés, a exclusión de comentarios de bots e o uso do número de usuarios involucrados na conversación como indicador de calidade. Tamén anotamos cada ficheiro de código con información de licenza asociada ao repositorio respectivo, atopada a través das APIs de Github e só mantemos ficheiros con licenzas permisivas para o adestramento do modelo. 2 3 A Li et al. 2023a Li et al. 2023a 2.2 Deduplicación Exacta e Difusa Adoptamos unha estratexia de deduplicación agresiva que inclúe tanto a deduplicación exacta como a difusa para eliminar documentos con contido de código (casi) idéntico no noso conxunto de adestramento. Para a deduplicación exacta, primeiro calculamos o hash SHA256 no contido do documento e eliminamos os rexistros con hashes idénticos. Despois da deduplicación exacta, aplicamos a deduplicación difusa co obxectivo de eliminar ficheiros de código que poidan ter variacións lixeiras e, polo tanto, desviar máis os datos. Aplicamos un método de dous pasos para isto: (1) calculamos MinHashes de todos os documentos e despois utilizamos LSH (Hashing Sensible á Localización) para agrupar documentos en base ás súas pegadas MinHash, (2) medimos a similaridade Jaccard entre cada par de documentos no mesmo grupo e anotamos os documentos, excepto un, como duplicados en base a un limiar de similaridade de 0,7. Aplicamos este proceso de case-deduplicación a todas as linguaxes de programación, incluídos os problemas de GitHub, para mellorar a riqueza e diversidade do conxunto de adestramento. 2.3 Filtrado HAP, PII, Malware Para reducir a probabilidade de xerar linguaxe odiosa, abusiva ou profana (HAP) a partir dos modelos, facemos esforzos dilixentes para filtrar o contido HAP do conxunto de adestramento. Primeiro creamos un dicionario de palabras clave HAP e despois anotamos cada documento de código co número de ocorrencias de tales palabras clave no contido, incluídos os comentarios. Filtramos os documentos que superan o limiar HAP, calculado en base a unha análise distributiva así como a unha inspección manual de ficheiros de código. Ademais, para protexer a privacidade, seguimos a StarCoder ( , ) e facemos esforzos dilixentes para redactar Información de Identificación Persoal (PII) do conxunto de adestramento. Específicamente, aproveitamos o modelo StarPII para detectar enderezos IP, claves, enderezos de correo electrónico, nomes, nomes de usuario e contrasinais atopados no contido. O paso de redacción de PII substitúe o texto PII polos tokens correspondentes NAME , EMAIL , KEY , PASSWORD e cambia o enderezo IP por un enderezo IP xerado sinteticamente, como en Li et al. (2023a). Tamén escaneamos os nosos conxuntos de datos usando para identificar e eliminar instancias de malware no código fonte. Li et al. 2023a 4 2.4 Conxuntos de Datos de Linguaxe Natural Ademais de recompilar datos de código para o adestramento do modelo, curamos varios conxuntos de datos de linguaxe natural de alta calidade dispoñibles publicamente para mellorar a competencia do modelo na comprensión da linguaxe e o razoamento matemático. Os conxuntos de datos representativos desta categoría inclúen documentos web (Stackexchange, CommonCrawl), texto web matemático (OpenWeb-Math; ( ), StackMathQA; ( )), texto académico (Arxiv, Wikipedia), e conxuntos de datos de axuste de instrucións (FLAN; ( ), HelpSteer ( , )). Non deduplicamos estes conxuntos de datos de linguaxe natural xa preprocesados. Paster et al. 2023 Zhang 2024 Longpre et al. 2023 Wang et al. 2023 3 Arquitectura do Modelo Adestramos unha serie de modelos de código de diferentes tamaños baseados na arquitectura do transformador decoder ( , ). Os hiperparámetros do modelo para estes modelos ofrécense na Táboa . Para todas as arquitecturas de modelos, usamos pre-normalización ( , ): normalización aplicada á entrada dos bloques de atención e MLP. Vaswani et al. 2017 1 Xiong et al. 2020 : O modelo máis pequeno da familia de modelos Granite-code adéstrase con incrustación RoPE ( , ) e Atención Multi-Cabeza ( , ). Este modelo utiliza a función de activación swish ( , ) con GLU ( , ) para o MLP, tamén coñecido comúnmente como swiglu. Para a normalización, usamos RMSNorm ( , ) xa que é computacionalmente máis eficiente que LayerNorm ( , ). O modelo 3B adéstrase cunha lonxitude de contexto de 2048 tokens. 3B Su et al. 2023 Vaswani et al. 2017 Ramachandran et al. 2017 Shazeer 2020 Zhang & Sennrich 2019 Ba et al. 2016 : O modelo 8B ten unha arquitectura similar á do modelo 3B coa excepción de usar Atención de Consulta Agrupada (GQA) ( , ). Usar GQA ofrece un mellor compromiso entre o rendemento do modelo e a eficiencia da inferencia a esta escala. Adestramos o modelo 8B cunha lonxitude de contexto de 4096 tokens. 8B Ainslie et al. 2023 : O modelo de código 20B adéstrase con incrustacións de posición absolutas aprendidas. Usamos Atención Multi-Consulta ( , ) durante o adestramento para unha inferencia posterior eficiente. Para o bloque MLP, usamos a función de activación GELU ( , ). Para normalizar as activacións, usamos LayerNorm ( , ). Este modelo adéstrase cunha lonxitude de contexto de 8192 tokens. 20B Shazeer 2019 Hendrycks & Gimpel 2023 Ba et al. 2016 : Para adestrar o modelo 34B, seguimos o enfoque de para a escalada en profundidade do modelo 20B. Especificamente, primeiro duplicamos o modelo de código 20B con 52 capas e despois eliminamos as últimas 8 capas do modelo orixinal e as primeiras 8 capas da súa duplicada para formar dous modelos. 34B Kim et al. Finalmente, concatenamos ambos os modelos para formar o modelo Granite-34B-Code con 88 capas (ver Figura para unha ilustración). Despois da escalada en profundidade, observamos que a caída no rendemento en comparación co modelo 20B é moi pequena ao contrario do que se observa en . Este rendemento recupérase bastante rápido despois de continuar o pre-adestramento do modelo 34B escalado. Similar ao 20B, usamos un contexto de 8192 tokens durante o pre-adestramento. 2 Kim et al. 4 Pre-adestramento Nesta sección, proporcionamos detalles sobre o adestramento en dúas fases (Secc. ), obxectivos de adestramento (Secc. ), optimización (Secc. ) e infraestrutura (Secc. ) utilizadas no pre-adestramento dos modelos. 4.1 4.2 4.3 4.4 4.1 Adestramento en Dúas Fases Os modelos Granite Code adéstranse en 3,5T a 4,5T tokens de datos de código e conxuntos de datos de linguaxe natural relacionados co código. Os datos tókenízanse mediante codificación de pares de bytes (BPE, ( , )), empregando o mesmo tokenizador que StarCoder ( , ). Seguindo ( , ; , ), utilizamos datos de alta calidade con dúas fases de adestramento do seguinte xeito. Sennrich et al. 2015 Li et al. 2023a Shen et al. 2024 Hu et al. 2024 • : Durante a fase 1, os modelos 3B e 8B adéstranse durante 4 billóns de tokens de datos de código que comprenden 116 linguaxes. O modelo de 20B parámetros adéstrase en 3 billóns de tokens de código. O modelo 34B adéstrase en 1,4T tokens despois da escalada en profundidade que se realiza no checkpoint de 1,6T do modelo 20B. Fase 1 (adestramento só de código) • : Na fase 2, incluímos datos adicionais de alta calidade dispoñibles publicamente de varios dominios, incluíndo documentos técnicos, matemáticos e web, para mellorar aínda máis o rendemento do modelo en habilidades de razoamento e resolución de problemas, que son esenciais para a xeración de código. Adestramos todos os nosos modelos durante 500B tokens (80% de código e 20% de datos de linguaxe) na fase 2 de adestramento. Fase 2 (adestramento de código + linguaxe) 4.2 Obxectivo de Adestramento Para o adestramento de todos os nosos modelos, usamos o obxectivo de modelado de linguaxe causal e o obxectivo Fill-In-the-Middle (FIM) ( , ). O obxectivo FIM encárgase de predicir tokens inseridos co contexto dado e o texto seguinte. Adestramos os nosos modelos para que funcionen con modos PSM (Prefix-Suffix-Middle) e SPM (Suffix-Prefix-Middle), con tokens de control de formato relevantes, igual que StarCoder ( , ). Bavarian et al. 2022 Li et al. 2023a A perda total calcúlase como unha combinación ponderada dos 2 obxectivos: Establecemos empíricamente α = 0,5 durante o adestramento e atopamos que isto funciona ben na práctica, levando a un rendemento SOTA tanto nas tarefas de completamento de código como de recheo de código. Cabe sinalar que o obxectivo FIM só se usa durante o pre-adestramento; non obstante, elimínase durante o axuste fino de instrucións, é dicir, establecemos α = 1. 4.3 Optimización Usamos o optimizador AdamW ([Kingma & Ba](#_bookmark80),(#_bookmark80)) con β1 = 0,9, β2 = 0,95 e unha decadencia de peso de 0,1 para adestrar todos os nosos modelos Granite code. Para o pre-adestramento da fase 1, a taxa de aprendizaxe segue un programa de coseno a partir de 3 10−4 que decae a 3 10−5 cun paso de quecemento lineal inicial de 2k iteracións. Para o pre-adestramento da fase 2, comezamos a partir de 3 10−4 (1,5 10−4 para os modelos 20B e 34B) e adoptamos un programa de decadencia exponencial para a súa atenuación ata o 10% da taxa de aprendizaxe inicial. Usamos un tamaño de lote de 4M-5M tokens dependendo do tamaño do modelo durante ambas as fases de pre-adestramento. Para acelerar o adestramento,
