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 ser integrados en contornos de desenvolvemento de software para mellorar a produtividade dos programadores humanos, e os axentes baseados en LLM comezan a mostrar promesas para xestionar tarefas complexas de forma autónoma. A consecución do pleno 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 máis. Neste traballo, presentamos a serie Granite de modelos de código só-decodificadores para tarefas xerativas de código, adestrados con código escrito en 116 linguaxes de programación. A familia de modelos Granite Code consta de modelos cuxo tamaño varía de 3 a 34 mil millóns de parámetros, axeitados para aplicacións que van desde tarefas complexas de modernización de aplicacións ata casos de uso con restricións de memoria en dispositivo. A avaliación nun conxunto completo de tarefas demostra que os modelos Granite Code ac-tualmente alcanzan 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 os fluxos de traballo de desenvolvemento de software empresarial e funciona ben en varias tarefas de codificación (por exemplo, xeración de código, corrección e explicación), converténdoa nun modelo de código "todo terreo" versátil. Publicamos todos os nosos modelos Granite Code baixo unha licenza Apache 2.0 para uso tanto na 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. A medida que a demanda de desenvolvemento de software aumenta, é máis crítico 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. Nos últimos anos, houbo un rápido progreso na capacidade dos LLMs para xerar e manipular código, e hoxe están dispoñibles unha variedade de modelos con impresionantes habilidades de codificación. Os modelos varían en tamaño desde miles de millóns de parámetros dun só díxito (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 apuntan a 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 existen 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 xeralistas moi grandes poden acadar un rendemento de codificación excelente, o seu tamaño fai que sexan caros de despregar. Modelos de código máis pequenos ( , ; , ; , ; , ; , ) poden acadar un rendemento excelente 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 ser inferior ao 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, incluso os modelos abertos a veces están plagados de falta de transparencia sobre as fontes de datos e os métodos de procesamento de datos que foron utilizados 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 de alta capacidade, 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 publicamos en catro tamaños diferentes (3B, 8B, 20B e 34B): modelos fundamentais base para tarefas relacionadas co código; Base de Código Granite: modelos que seguen instrucións finetuneados mediante unha combinación de confirmacións de Git emparelladas con instrucións humanas e conxuntos de datos de instrucións de código sintético de código aberto. Instrución de Código Granite: Os modelos base da serie foron adestrados desde 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 da sintaxe. Na fase 2, o noso modelo adéstrase ademais 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 de instrucións derivanse do finetuning adicional dos modelos base adestrados anteriores nunha combinación dunha variante filtrada de CommitPack ( , ), conxuntos de datos de seguimento de instrucións de 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 sintético 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 abrangue 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 moitas das principais linguaxes de programación (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 en xeral un rendemento moi forte en todos os tamaños de modelos e benchmarks (superando a miúdo 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 base de código de código aberto, incluíndo LLMs base xeralistas recentes de alto rendemento como Mistral ( , ) e LLama-3 ( , ) en HumanEvalPack ( , ). Mentres que 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% vs 21,3%), a pesar de ser adestrado cun número significativamente menor de tokens (4,5T vs 7,5T tokens). Ademais dos modelos base, as variantes de instrucións afinadas dos nosos modelos Granite Code tamén mostran un forte rendemento en HumanEvalPack, superando a outros modelos de instrucións (código) de código aberto, o que demostra os beneficios para un conxunto máis amplo de tarefas de codificación con instrucións de 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 acada un mellor rendemento en comparación coa maioría dos LLMs de vangarda de 7B ou 8B. 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 acadan un rendemento competitivo ou de vangarda en diferentes tipos de tarefas relacionadas co código, incluíndo a xeración de código, a explicación, a corrección, a edición, a tradución, etc., demostrando a súa capacidade para resolver diversas tarefas de codificación; LLM de Código Todo-Redondo : Todos os nosos modelos son adestrados con datos con licenza permisible recollidos 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 Grao Empresarial Confiable 1 Describimos a nosa canalización completa de recollida, filtrado e preprocesamento de datos na sección . A sección describe os detalles da arquitectura do modelo, seguida 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 os resultados que comparan 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 baixa 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, só manter 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, só manter ficheiros cun recuento de caracteres que oscile entre 50 e 5000 caracteres. Tamén filtramos os problemas de GitHub usando un 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 implicados na conversa como indicador de calidade. Tamén anotamos cada ficheiro de código coa información de licenza asociada ao repositorio respectivo, atopada a través das APIs de Github e só mantemos ficheiros con licenzas permisibles 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 deduplicación exacta como difusa para eliminar documentos que teñen contido de código (near) idéntico no noso conxunto de adestramento. Para a deduplicación exacta, primeiro calculamos o hash SHA256 sobre o contido do documento e eliminamos os rexistros con hashes idénticos. Despois da deduplicación exacta, aplicamos deduplicación difusa co obxectivo de eliminar ficheiros de código que poden ter lixeiras variacións 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 Localmente Sensitive Hashing (LSH) para agrupar documentos en base ás súas pegadas MinHash, (2) medimos a similaridade de Jaccard entre cada par de documentos no mesmo grupo e anotamos documentos agás un como duplicados en base a un limiar de similaridade de 0,7. Aplicamos este proceso de cuasi-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 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 ocorrrencias de tales palabras clave no contido, incluídos os comentarios. Filtramos os documentos que exceden 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 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 NOME , EMAIL , CHAVE , CONTRASINAL 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 recoller 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 no razoamento matemático. Os conxuntos de datos representativos nesta 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 varios tamaños baseados na arquitectura do decodificador transformer ( , ). Os hiperparámetros do modelo para estes modelos móstranse na Tabela . 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 ao modelo 3B coa excepción de usar Atención de Consulta Agrupada (GQA) ( , ). Usar GQA ofrece un mellor equilibrio 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 de profundidade do modelo 20B. Especificamente, primeiro duplicamos o modelo 20B con 52 capas e despois eliminamos as 8 capas finais do modelo orixinal e as 8 capas iniciais do seu 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 de profundidade, observamos que a caída no rendemento en comparación co modelo 20B é moi pequena, ao contrario do observado por . 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 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 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 en 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 de 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 nas habilidades de razoamento e resolución de problemas, que son esenciais para a xeración de código. Adestramos todos os nosos modelos en 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 está encargado de predicir tokens inseridos co contexto e o texto posterior dados. 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 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 completado de código como de recheo de código. Débese notar que o obxectivo FIM úsase só durante o pre-adestramento, sen embargo, elimínase durante o axuste 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 de código Granite. Para o pre-adestramento de fase 1, a taxa de aprendizaxe segue un calendario de coseno comezando desde 3 10−4 que decae a 3 10−5 cun paso inicial de quentamento lineal de 2k iteracións. Para o pre-adestramento de fase 2, comezamos desde 3 10−4 (1,5 10−4 para os modelos 20B e 34B) e adoptamos un calendario de decaimento exponencial para anular o a 10% da taxa de aprendizaxe inicial. Usamos un tamaño de lote de 4M-5M tokens depend
