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 están a integrarse en contornas de desenvolvemento de software para mellorar a produtividade dos programadores humanos, e os axentes baseados en LLMs comezan a mostrar promesas para xestionar tarefas complexas de forma autónoma. Realizar todo o potencial 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 de tipo "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 consiste en modelos que varían en tamaño dende 3 a 34 mil millóns de parámetros, axeitados para aplicacións que van dende tarefas complexas de modernización de aplicacións ata casos de uso con limitacións de memoria no dispositivo. A avaliación nun conxunto completo de tarefas demostra que os modelos Granite Code acadan 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 nunha gama de tarefas de codificación (por exemplo, xeración, corrección e explicación de código), converténdoos nun modelo de código versátil "todo en un". Liberamos 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 Nas últimas décadas, o software teceuse no tecido de todos os aspectos da nosa sociedade. A medida que a demanda de desenvolvemento de software aumenta, é máis crucial que 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 os 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 están dispoñibles unha gama de modelos con impresionantes habilidades de codificación. Os modelos varían en tamaño dende poucos 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 co código (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, seguen existindo importantes lagoas no campo actual dos LLMs para código, especialmente no contexto do desenvolvemento de software empresarial. En primeiro lugar, mentres que os LLMs xeralistas moi grandes poden acadar un excelente rendemento de codificación, o seu tamaño fai que sexa caro de implementar. Os modelos máis pequenos centrados no código ( , ; , ; , ; , ; , ) poden acadar un excelente rendemento na 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 por detrá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 ás veces sofren unha 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 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 apoiar o desenvolvemento de software empresarial nunha ampla gama de tarefas de codificación. Os modelos Granite Code teñen dúas variantes principais que liberamos en catro tamaños diferentes (3B, 8B, 20B e 34B): modelos fundacionais base para tarefas relacionadas co código; Granite Code Base: modelos de seguimento de instrucións axustados usando 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 procedentes de 116 linguaxes de programación, garantindo unha comprensión completa das linguaxes de programación e a sintaxe. Na fase 2, o noso modelo adéstrase adicionalmente en 500 mil millóns de tokens cunha mestura deseñada coidadosamente 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 instruct 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 matemáticos de código aberto (MathInstruct ( , ) e MetaMathQA ( , )), incluíndo conxuntos de datos de código xerado sinteticamente para mellorar as capacidades de seguimento de instrucións e 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 abarca 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., na maioría das 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 de propósito xeral de alto rendemento recentes como Mistral ( , ) e LLama-3 ( , ) en HumanEvalPack ( , ). Mentres que CodeGemma e StarCoder2 teñen un rendemento razoable na xeración de código, teñen un rendemento significativamente peor nas variantes de corrección e explicación de código de HumanEvalPack. En 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 nun 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ón de código aberto, o que demostra 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 é crítico para resolver preguntas 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 acadou 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 15 As vantaxes clave dos modelos Granite Code inclúen: Os modelos Granite Code acadan 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 en un": Todos os nosos modelos son adestrados con datos permitidos por licenza recollidos seguindo os principios de ética da IA de IBM e guiados polo equipo legal corporativo de IBM para un uso empresarial confiable. Todos os modelos Granite Code son liberados baixo a licenza Apache 2.0. LLM de Grao Empresarial Confiable: 1 Describimos a nosa pipeline completa de recollida, 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 (Sec. ), deduplicación (Sec. ), filtrado HAP/PII (Sec. ) utilizado para preparar os datos de código para o adestramento do modelo. Tamén proporcionamos unha visión xeral dos datos de 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 clave de filtrado para eliminar código de menor calidade ( , ): (1) eliminar ficheiros con menos do 25% de caracteres alfabéticos, (2) agás a linguaxe XSLT, filtrar ficheiros onde a cadea “<?xml version=” aparece dentro dos primeiros 100 caracteres, (3) para ficheiros HTML, manter só ficheiros onde o texto visible constitúa polo menos o 20% do código HTML e teña unha lonxitude mínima de 100 caracteres, (4) para ficheiros JSON e YAML, manter só ficheiros que teñan unha conta 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 non ingleses, a exclusión de comentarios de bots e o uso do número de usuarios involucrados na conversa 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 mantemos só os 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 deduplicación exacta e difusa para eliminar documentos que teñan contido de código (case) idéntico no noso conxunto de adestramento. Para a deduplicación exacta, primeiro calculamos o hash SHA256 no contido do documento e eliminamos rexistros con hashes idénticos. Despois da deduplicación exacta, aplicamos deduplicación difusa co obxectivo de eliminar ficheiros de código que poidan ter lixeiras variacións e, polo tanto, desbalancear aínda máis os datos. Aplicamos un método de dous pasos para isto: (1) calcular MinHashes de todos os documentos e despois utilizar Hashing Sensible Local (LSH) para agrupar documentos segundo as súas pegadas de MinHash, (2) medir a similitude de Jaccard entre cada par de documentos no mesmo grupo e anotar documentos agás un como duplicados baseándose nun limiar de similitude de 0,7. Aplicamos este proceso de case-deduplicación a todas as linguaxes de programación, incluíndo os problemas de GitHub, para mellorar a riqueza e diversidade do conxunto de datos 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 aparicións de tales palabras clave no contido, incluíndo comentarios. Filtramos os documentos que superan o limiar HAP, calculado en base a unha análise distributiva así como a inspección manual dos 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. Especificamente, 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 cun 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, recompilamos 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 baixo esta 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 decodificador ( , ). Os hiperparámetros do modelo para estes modelos están 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 Granite-code está adestrado con incrustación RoPE ( , ) e Atención Multi-Cabeza ( , ). Este modelo usa 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 é máis eficiente computacionalmente que LayerNorm ( , ). O modelo 3B está adestrado 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) ( , ). O uso de GQA ofrece unha mellor relación entre o rendemento do modelo e a eficiencia da inferencia nesta escala. Adestramos o modelo 8B cunha lonxitude de contexto de 4096 tokens. 8B Ainslie et al. 2023 : O modelo de código 20B está adestrado con incrustacións de posición absolutas aprendidas. Usamos Atención Multi-Consulta ( , ) durante o adestramento para unha inferencia eficiente posterior. Para o bloque MLP, usamos a función de activación GELU ( , ). Para normalizar as activacións, usamos LayerNorm ( , ). Este modelo está adestrado 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 8 capas finais do modelo orixinal e as 8 capas iniciais da súa duplicado 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 é bastante pequena, ao contrario do que observaron . 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 (Sec. ), obxectivos de adestramento (Sec. ), optimización (Sec. ) e infraestrutura (Sec. ) utilizados 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 tokenización de par de bytes (BPE, ( , )), empregando o mesmo tokenizador que StarCoder ( , ). Seguindo ( , ; , ), utilizamos datos de alta calidade con dúas fases de adestramento como segue. 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ó en 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 500 mil millóns de tokens (80% código e 20% 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 subsiguiente. Adestramos os nosos modelos para traballar con ambos os 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 empiricamente α = 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 inserción de código. Debe notarse que o obxectivo FIM só se usa durante o pre-adestramento, sen embargo, 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 decaimento 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 horario de coseno comezando dende 3 10−4 que decae a 3 10−5 cun paso inicial de quentamento lineal de 2k iteracións. Para o pre-adestramento da fase 2, comezamos dende 3 10−4 (1,5 10−4 para os modelos 20B e 34B) e adoptamos un horario de decaimento exponencial para anularlo ao 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
