Coisas secas! Explicação detalhada da tecnologia de ajuste fino multitarefa no papel MFTCoder

Os LLMs de código tornaram-se um campo especializado de pesquisa que melhora os recursos de codificação de modelos pré-treinados usando dados relacionados ao código para ajustar modelos pré-treinados. Os métodos de ajuste fino anteriores geralmente são personalizados para tarefas ou cenários posteriores específicos, o que significa que cada tarefa precisa ser ajustada separadamente, requer uma grande quantidade de recursos de treinamento e é difícil de manter e implantar devido à coexistência de vários modelos . Além disso, estes métodos não conseguem explorar as conexões intrínsecas entre diferentes tarefas de codificação.

Para superar essas limitações, propomos uma estrutura de ajuste fino multitarefa - MFTCoder, que pode realizar o ajuste fino em múltiplas tarefas simultaneamente e em paralelo. Ao combinar múltiplas funções de perda, resolvemos efetivamente os desafios comuns no aprendizado multitarefa, como volume de dados desequilibrado, dificuldade variável e velocidades de convergência inconsistentes entre tarefas.

Um grande número de resultados experimentais mostram que nosso método de ajuste fino multitarefa tem melhor desempenho do que o ajuste fino de uma única tarefa sozinho ou a mistura de várias tarefas em uma. Além disso, o MFTCoder possui recursos de treinamento eficientes, incluindo o fornecimento de modo eficiente de tokenização de dados e suporte ao ajuste fino do PEFT, o que pode efetivamente aumentar a velocidade do treinamento de ajuste fino e reduzir a demanda por recursos.

MFTCoder foi adaptado para suportar vários LLMs de código aberto convencionais, como LLama-1/2, CodeLLama, Qwen, CodeGeeX2, StarCoder, Baichuan2, ChatGLM2/3, GPT-Neox, etc. Usando CodeLLama como base e usando MFTCoder para ajustar CODEFUSE-CODELLAMA-34B, a pontuação pass@1 no teste HumaneEval chega a 74,4%, excedendo o desempenho do GPT-4 (67%, tiro zero, março 2023).

O artigo sobre os detalhes técnicos do MFTCoder foi lançado no Arxiv : https://arxiv.org/pdf/2311.02303.pdf ; o código correspondente também foi aberto no github : https://github.com/codefuse-ai /MFTCoder . Este artigo tem como objetivo fornecer uma interpretação técnica detalhada do artigo MFTCoder.

I. Introdução

O surgimento do ChatGPT e do GPT-4 levou a uma explosão na pesquisa e desenvolvimento de grandes modelos (LLMs), o que também desencadeou ainda mais o boom de pesquisa e desenvolvimento na aplicação de grandes modelos para geração e compreensão de código. Este ramo é chamado de código direção de modelos grandes (LLMs). Ou seja, Code LLMs). Ao pré-treinar em uma grande quantidade de dados de código (como dados públicos do GitHub) e dados de texto natural, o grande modelo de código pode concluir com eficácia várias tarefas relacionadas ao código, como preenchimento automático de código, geração de código com base em descrições e adição comentários ao código. Explicar funções de código, gerar casos de teste únicos, corrigir código, traduzir código, etc.

Embora a fase de pré-treinamento dos LLMs (de código) seja projetada para garantir sua capacidade de generalização para diferentes tarefas posteriores, a fase subsequente de ajuste fino geralmente é executada apenas para tarefas ou cenários específicos. Esta abordagem ignora dois desafios principais. Primeiro, envolve um ajuste fino individual que consome muitos recursos para cada tarefa, o que dificulta a implantação eficiente em ambientes de produção; segundo, a inter-relação das tarefas no domínio do código sugere que o ajuste fino conjunto pode melhorar o desempenho em comparação com o ajuste fino individual. Portanto, é crucial realizar o ajuste fino multitarefa para lidar com todas as tarefas simultaneamente e usar os pontos fortes das tarefas relacionadas para melhorar o desempenho de outras tarefas.

Para ilustrar melhor, imagine que temos duas tarefas relacionadas: conclusão de código e resumo de código. A conclusão do código prevê a próxima linha de código com base em trechos de código parciais, enquanto o resumo do código visa gerar um resumo conciso e legível de um determinado trecho de código. Tradicionalmente, cada tarefa era ajustada separadamente, resultando em uma duplicação que exigia muitos recursos. No entanto, existe uma conexão inerente entre a conclusão do código e o resumo do código. A conclusão de trechos de código depende da compreensão da funcionalidade e da finalidade geral, enquanto a geração de resumos precisos requer uma compreensão da estrutura, das dependências e da funcionalidade pretendida. Ao empregar a aprendizagem multitarefa, um único modelo pode ser treinado para aprender ambas as tarefas em conjunto, aproveitando conhecimentos e padrões partilhados para melhorar o desempenho em ambas as tarefas. O modelo entende as dependências contextuais entre os elementos do código, ajudando a prever o próximo trecho de código e a gerar resumos informativos. Além disso, a aprendizagem multitarefa oferece benefícios adicionais além do desempenho de tarefas individuais: representações compartilhadas entre tarefas ajudam a mitigar problemas de overfitting, promovem melhor generalização e aprimoram modelos para lidar com a escassez de dados específicos de tarefas. Se a conclusão do código tiver um conjunto de dados de treinamento maior do que o resumo do código, o modelo poderá aproveitar os ricos dados de conclusão para melhorar o desempenho da sumarização, enfrentando efetivamente o desafio da escassez de dados. O aprendizado multitarefa permite até que os modelos lidem com tarefas invisíveis, mas relacionadas, mesmo sem dados de treinamento específicos. No geral, a aprendizagem multitarefa permite que os modelos aprendam conjuntamente múltiplas tarefas relacionadas, beneficiem do conhecimento partilhado, melhorem o desempenho, melhorem as capacidades de generalização e lidem com a escassez de dados.

Apesar da importância da aprendizagem multitarefa, apenas alguns estudos existentes exploraram esta abordagem no campo do processamento de linguagem natural (Raffel et al., 2023; Aghajanyan et al., 2021; Aribandi et al., 2022). Esses estudos combinam dados multitarefa para aprendizagem de grandes modelos sem distinguir tarefas explicitamente. Ainda mais infelizmente, esses estudos tendem a priorizar tarefas com amostras maiores e ignorar tarefas com amostras menores. Além disso, não conseguem garantir velocidades de convergência iguais entre as tarefas, resultando na otimização excessiva de algumas tarefas e na subotimização de outras.

Este artigo se concentra no ajuste fino multitarefa (MFT) para modelos grandes, com o objetivo de permitir que tarefas com diferentes tamanhos de amostra recebam igual atenção e obtenham otimização semelhante. Embora nosso método não se limite ao campo de modelos grandes de código, neste artigo nos concentramos no modelo grande de código, considerando que as tarefas downstream no campo de código são frequentemente mais relevantes, o que também dá origem ao nome MFTCoder. Enfatizamos que o MFTCoder pode ser facilmente estendido a qualquer conjunto de tarefas de PNL relacionadas. Para melhorar a eficiência do MFTCoder, adotamos técnicas de ajuste fino com parâmetros eficientes, incluindo LoRA (Hu et al., 2021) e QLoRA (Dettmers et al., 2023). Os resultados experimentais mostram que os modelos multitarefa treinados usando o método MFT superam os modelos que são ajustados para cada tarefa individualmente ou ajustados pela fusão de dados de múltiplas tarefas. Adaptamos e verificamos ainda a eficácia do MFTCoder em vários LLMs pré-treinados atualmente populares, como Qwen, Baichuan2, Llama, Llama 2, StarCoder, CodeLLama, CodeGeex2, etc. Vale ressaltar que ao usar CodeLlama-34B-Python como modelo base, o modelo CodeFuse-CodeLLama-34B ajustado pelo MFTCoder alcançou uma pontuação pass@1 de 74,4% no conjunto de avaliação HmanEval, superando GPT-4 (67 %, tiro zero, março de 2023).

As principais contribuições do artigo são resumidas a seguir: 

  • É proposto o MFTCoder, que aplica o aprendizado multitarefa ao ajuste fino de grandes modelos de código, com foco na solução dos problemas comuns de desequilíbrio de dados e velocidade de convergência inconsistente nos métodos anteriores de ajuste fino multitarefa.
  • Extensos experimentos mostram que o método MFT supera os métodos de ajuste fino individual e de ajuste fino híbrido multitarefa em desempenho. Com base na base CodeLlama-34B-Python, o modelo CodeFuse-CodeLLama-34B ajustado pelo MFTCoder alcançou uma pontuação pass@1 de 74,4% no conjunto de avaliação HumanEval, excedendo GPT-4 (67%, amostra zero), e o modelo era de código aberto e um conjunto de dados de instruções de alta qualidade.
  • Adaptamos e verificamos o desempenho do MFTCoder em vários LLMs populares, incluindo Qwen, Baichuan2, Llama, Llama 2, StarCoder, CodeLLama, CodeFuse e CodeGeex2, etc., comprovando sua compatibilidade e escalabilidade com diferentes modelos básicos.

 

2. Método

Figura 1: Diagrama da arquitetura MFT

 

2.1 Estrutura

A estrutura geral do MFTCoder é mostrada na Figura 1, incluindo suporte multitarefa, adaptação multimodelo, construção de conjunto de dados de alta qualidade, uso eficiente de dados, métodos de treinamento eficientes e design balanceado multitarefa .

  • ( Multitarefa ) O MFTCoder foi projetado para adaptar LLMs perfeitamente a diferentes cenários e maximizar seu desempenho em cenários específicos. Ao aplicar o MFTCoder a um novo cenário, o primeiro passo é dividir o cenário em tarefas menores que correspondam às capacidades alvo. Por exemplo, no campo de LLMs de código, o objetivo geral de aprimorar as capacidades de código do modelo pode ser dividido em tarefas mais refinadas, como conclusão de código, geração de texto para código, geração de casos de teste de unidade, código reparo, depuração de código e até tradução entre idiomas. Nossa ampla experiência prática mostra que o MFTCoder pode lidar com escalas multitarefa de maneira eficaz, desde uma única tarefa até dezenas ou mesmo centenas de tarefas.
  • ( Construção de conjuntos de dados e treinamento eficiente ) Após a divisão, a próxima etapa é coletar e organizar conjuntos de dados ajustados para cada tarefa. No entanto, a coleta de dados para algumas tarefas pode apresentar desafios. Para superar esse problema, o MFTCoder utiliza a tecnologia Self-Instruct (Wang et al., 2022) e Agentes para gerar conjuntos de dados de instruções. O ajuste fino multitarefa geralmente significa que uma quantidade maior de dados de treinamento será usada para um ajuste fino. Para garantir um processo de treinamento eficiente, o MFTCoder adota dois modos eficientes de tokenização de dados e suporta PEFT (Ajuste fino com eficiência de parâmetros). ) tecnologia para melhorar a eficiência do treinamento  .
  • ( Design de balanceamento de tarefas ) Em resposta aos desafios comuns no campo da aprendizagem multitarefa: volume de dados desequilibrado, dificuldade variável e velocidades de convergência inconsistentes entre tarefas, o MFTCoder introduz ou ajusta diferentes funções de perda para alcançar o equilíbrio de tarefas.
  • ( Adaptação de vários modelos ) Tendo em vista as diferentes vantagens e capacidades de diferentes modelos de grande escala, a fim de apoiar a seleção de bases de modelos adequadas sob demanda para ajuste fino para alcançar o melhor desempenho, o MFTCoder se adaptou a vários modelos abertos convencionais LLMs de origem, incluindo LLama, LLama 2, CodeLLama, Qwen, Baichuan 1/2, ChatGLM 2, CodeGeeX 2, GPT-NEOX, CodeFuse-13B, StarCoder, AntLLM, etc. Ao mesmo tempo, estamos em constante atualização e adaptação a novos modelos.

 

2.2 Construção do conjunto de dados de instruções

Para tarefas desafiadoras de coleta de dados, adotamos a tecnologia Self-Instruct para gerar dados de ajuste fino para tarefas downstream relacionadas ao código no MFTCoder. Isso envolve fornecer dicas personalizadas para GPT-3.5 ou GPT-4 que descrevam claramente nossas necessidades de geração de instruções e, assim, gerem dados de instrução. Além disso, somos inspirados pelo trabalho PHI-1/1.5 (Gunasekar et al., 2023) e aplicamos ainda mais a técnica Self-Instruct para gerar conjuntos de dados de prática de código de alta qualidade para tarefas downstream relacionadas ao código.

Em termos de implementação específica, temos duas opções. Um é um método de diálogo autônomo de múltiplas rodadas com a ajuda de Agentes (como Camel (Li et al., 2023c)), e o outro é um método de diálogo de rodada única implementado chamando diretamente a API ChatGPT. No método de diálogo multiturno, usamos Camel para iniciar dois Agentes, cada Agente recebe uma função específica e um objetivo de tarefa, e conduzimos o diálogo entre eles para gerar dados de instrução consistentes com o tema determinado. Por exemplo, ao gerar dados de exercícios Python, especificamos dois Agentes como "professor" (simulando a função de usuário do ChatGPT) e "aluno" (simulando a função de assistente do ChatGPT). Entre eles, a responsabilidade do professor é fornecer os dados gerados para alunos. instruções para problemas práticos, e a tarefa do aluno é fornecer soluções para as instruções correspondentes. Este processo iterativo continuará a gerar múltiplas questões práticas até que os requisitos da tarefa sejam atendidos ou o comprimento máximo de entrada do ChatGPT seja atingido. Vale ressaltar que para nos adaptarmos ao limite de comprimento de entrada do ChatGPT, não podemos utilizar diretamente tópicos mais amplos como tópicos de tarefas. Por exemplo, ao criar exercícios para avaliar o domínio dos alunos na linguagem Python, precisamos dividir o tópico em pontos de conhecimento Python menores e específicos (como árvores de pesquisa binária) e iniciar uma sessão Camel separada para cada ponto de conhecimento. O exemplo específico é mostrado na Figura 2 abaixo (extraído do Apêndice A do artigo  https://arxiv.org/pdf/2311.02303.pdf  ).

Figura 2: Exemplo de sistema de geração de perguntas práticas de código e configuração de prompt do usuário por meio de Camel Agents

 

A solução de diálogo multi-ronda oferece maiores capacidades de automação, mas o custo é maior porque dois agentes precisam ser mantidos, e cada agente precisa fazer múltiplas chamadas de conversação para a API ChatGPT. Para aliviar este problema, propomos um método de geração de diálogo de rodada única mais econômico, cujo processo geral é mostrado na Figura 3. Primeiro criamos um conjunto inicial que consiste em centenas de pontos de conhecimento básicos do Python. Essas sementes são então combinadas com os modelos de prompt fixos preparados para gerar um conjunto de prompts de tarefas padronizados. A fim de resolver o problema de redução da diversidade causada por modelos fixos e garantir uma descrição precisa dos prompts, utilizamos a função de refinamento dos prompts de tarefas do Camel para obter prompts de tarefas precisos e diversos. Cada prompt de tarefa é usado para gerar um conjunto de instruções relacionadas à semente correspondente (como um problema de exercício relacionado a uma árvore de pesquisa binária). Usando ChatGPT, geramos soluções diretivas correspondentes. Por fim, montamos e desduplicamos as instruções e suas soluções correspondentes para obter um conjunto de dados de treinamento. Abrimos o código-fonte do conjunto de dados de exercícios de código Python criado usando essa abordagem ( https://huggingface.co/datasets/codefuse-ai/CodeExercise-Python-27k ).

 

Figura 3: Conjunto de dados de instruções de exercícios de código Processo de solução de geração de rodada única

 

2.3 Modo de tokenização eficiente

Figura 4: Diagrama esquemático comparando as formas de existência de dados de três modos de tokenização em um lote

 

No processo de pré-treinamento e ajuste fino dos LLMs, a tokenização é uma etapa fundamental, na qual o texto de entrada e saída são divididos em unidades menores para uso posterior. A tokenização, juntamente com a função de perda utilizada no processo de treinamento, define como os dados são utilizados durante o processo de treinamento e, portanto, desempenha um papel fundamental na eficácia do modelo e na eficiência do treinamento. Em um esquema típico de tokenização SFT (ajuste fino supervisionado), as amostras no mesmo lote são alinhadas uniformemente ao comprimento máximo de entrada (comprimento seq) do modelo, e tokens de preenchimento adicionais são usados ​​para preenchimento se o comprimento for insuficiente, como mostrado na Figura 4 (a) é mostrado. Entretanto, na prática, descobrimos que essa abordagem resultou em um grande número de tokens de preenchimento. Por exemplo, ao usar o Tokenizer do CodeFuse-13B (Di et al., 2023) para processar 35 dados de tarefas downstream, a proporção média de tokens preenchidos é de 92,22% (comprimento seq é 4.096). Isso significa que há um grande número de Tokens utilizados apenas para alinhamento sem qualquer valor para o processo de treinamento, o que resulta na redução da eficiência do treinamento e no desperdício de espaço de armazenamento usado para armazenar resultados de Tokenização offline. Para resolver este problema, adotamos dois modos de Tokenização, nomeadamente o modo Dynamic Padding e o modo Packing, e os otimizamos.

No modo de preenchimento dinâmico, o tamanho da janela do microlote para cada GPU é determinado pelo comprimento máximo da amostra dentro dela. Amostras mais curtas são preenchidas com tokens de preenchimento adicionais para alinhar a esse tamanho, conforme mostrado na Figura 4 (b). Embora o preenchimento de tokens não afete o efeito de treinamento do modelo, eles aumentarão a sobrecarga computacional durante o processo de treinamento, afetando assim a velocidade de treinamento, e o modo de preenchimento dinâmico reduz efetivamente a proporção de tokens de preenchimento usados, acelerando assim o treinamento. De acordo com a nossa experiência, esta abordagem pode atingir aproximadamente o dobro da velocidade em comparação com o modo tradicional de tokenização SFT (o aumento real depende do conjunto de dados). Deve-se observar que este modo só é aplicável a cenários de Tokenização online.

Ao contrário do modo de enchimento dinâmico, que melhora a eficiência ao reduzir o tamanho da janela do microlote, o modo de embalagem começa na perspectiva de maximizar a utilização do comprimento máximo da janela de entrada (comprimento seq) permitido pelo modelo. Este modo é consistente com o SFT do Llama 2. O modelo de Tokenização (Touvron et al., 2023b) é semelhante. No modo de empacotamento, múltiplas amostras de ajuste fino são empacotadas em uma janela de comprimento seq em sequência, e duas amostras adjacentes são separadas por um token EOS, conforme . Na figura, as amostras 1-4 da Figura 4(a) são combinadas e colocadas sequencialmente em uma janela. Se uma amostra não puder caber completamente na janela atual,ela será colocada na próxima janela e preencherá o espaço restante com tokens de preenchimento.Por exemplo,na Figura 4(c),a amostra 5 é colocada na segunda janela e preenchida com preenchimento tokens. O espaço final é preenchido e a amostra 6 é colocada na terceira janela. Comparado com o modo de preenchimento dinâmico, o modo de empacotamento reduz ainda mais a proporção de preenchimento de Tokens, o que pode melhorar ainda mais a velocidade de treinamento. Nossa experiência prática mostra que nas 35 tarefas mencionadas anteriormente, este método reduz a proporção média de Tokens preenchidos para menos de 10%, aumentando significativamente a velocidade de treinamento enquanto mantém o efeito do treinamento. Deve-se enfatizar que o MFTCoder oferece suporte a cenários de tokenização de embalagens on-line e off-line, atendendo não apenas à fase SFT, mas também adequado à fase de pré-treinamento.

 

2.4 Ajuste fino eficiente do PEFT

Os LLMs de código aberto atualmente populares geralmente contêm bilhões ou até dezenas de bilhões de parâmetros, e os cenários de aprendizagem multitarefa geralmente envolvem um grande número de tarefas, o que significa que um grande número de amostras de ajuste fino estará envolvido no treinamento. Se optarmos por utilizar uma grande quantidade de dados para ajustar totalmente estes grandes modelos, enfrentaremos dois desafios: primeiro, será necessária uma grande quantidade de recursos de armazenamento e de computação; segundo, poderemos enfrentar o risco de um esquecimento catastrófico durante o processo de treinamento. Para resolver esses problemas, o MFTCoder adota a tecnologia PEFT (ajuste fino com eficiência de parâmetros) (Houlsby et al., 2019), que permite que um ajuste fino eficiente seja alcançado em um curto espaço de tempo com requisitos mínimos de recursos.

Figura 5: Esquema das ideias centrais de Lora

 

Especificamente, MFTCoder suporta dois métodos PEFT: Lora (adaptação de baixo nível de modelo de linguagem em grande escala) (Hu et al., 2021) e QLora (adaptação de baixo nível de modelo de linguagem em grande escala quantizada) (Dettmers et al., 2023) . O conceito básico de Lora é muito simples, conforme mostra a Figura 5. Ele adicionará um ramo de desvio ao modelo original. Durante o processo de treinamento, os parâmetros W ∈ R (forma dxd) do modelo de treinamento original permanecem inalterados, e apenas a matriz de redução de dimensionalidade A ∈ R (forma d × r) e o os parâmetros da matriz de dimensão ascendente B ∈ R (forma rxd) são treináveis. Após a conclusão do treinamento, o produto da matriz BA será adicionado aos parâmetros do modelo original W para obter o modelo recém-treinado. Como o tamanho de r é significativamente reduzido em relação a d, o número de parâmetros treináveis ​​é bastante reduzido. Baseado em Lora, QLora adota uma nova tecnologia de quantização de alta precisão chamada NF4 e introduz quantização dupla para quantizar o modelo pré-treinado em 4 bits. Além disso, ele introduz um conjunto de pesos adaptadores de baixa classificação que podem ser aprendidos e ajustados otimizando os gradientes dos pesos quantizados. Como resultado, o QLoRA pode ajustar modelos maiores usando menos recursos de GPU. Por exemplo, o MFTCoder pode ajustar um modelo 70B em uma única placa Nvidia A100 (memória de vídeo de 80 GB).

 

2.5 Função de perda balanceada multitarefa

Como uma estrutura de aprendizagem multitarefa, o MFTCoder enfrenta grandes desafios, como volume de dados desequilibrado, dificuldade variável e diferentes velocidades de convergência entre tarefas. Para enfrentar esses desafios, o MFTCoder emprega um conjunto de funções de perda projetadas especificamente para mitigar esses problemas de desequilíbrio.

Primeiro, para resolver o problema de desequilíbrio de dados, o MFTCoder garantirá que cada amostra de todas as tarefas dentro de uma única época seja usada e apenas uma vez. Para evitar que o modelo seja tendencioso para tarefas com mais dados, introduzimos uma estratégia de alocação de peso durante o processo de cálculo de perdas. Especificamente, oferecemos suporte a dois esquemas de cálculo de peso: um baseado no número de amostras de tarefas e outro baseado no número de Tokens efetivos incluídos no cálculo de perda. O primeiro é mais direto, mas pode não funcionar bem ao lidar com tarefas com diferenças extremas no número de amostras e no número de tokens válidos (como tarefas de classificação binária com respostas "sim" ou "não" ou tarefas de exame de escolha única ). Por outro lado, um esquema de atribuição de peso baseado no número de Tokens efetivos incorporados no cálculo de perda pode aliviar este problema. A função de perda ponderada é mostrada especificamente na fórmula (1) . Na Fórmula 1, N representa o número total de tarefas, M_i representa o número de amostras da i-ésima tarefa, T_ij representa o número de Tokens válidos (ou seja, Tokens envolvidos no cálculo de perda) na j-ésima amostra do i-ésima tarefa, e t_ijk representa o k-ésimo token válido da j-ésima amostra da tarefa i.

Para resolver o problema de dificuldade variada das tarefas, pegamos emprestada a ideia de Focal Loss e a incorporamos no MFTCoder. Implementamos dois níveis diferentes de funções de perda focal para nos adaptarmos a diferentes níveis refinados. Um opera no nível amostral, conforme mostrado na Equação (2) , e o outro opera no nível da tarefa, conforme mostrado na Equação (3) .

Para resolver o problema da velocidade de convergência inconsistente, pegamos emprestada a ideia do método FAMO (Fast Adaptation via Meta-Optimization) (Liu et al., 2023) e a aplicamos de forma inovadora para calcular a perda de validação. Primeiro, assumimos que cada tarefa (denotada pelo índice i) possui sua própria função de perda original Li(θ). Na t-ésima iteração, atualizamos o peso de cada tarefa de acordo com o gradiente da perda de validação da tarefa correspondente. O objetivo é maximizar o peso w_i da tarefa com a menor velocidade de convergência, conforme mostrado na fórmula (4 ) . Entre eles, g_t representa o gradiente da perda de verificação ponderada de todas as tarefas, ci(α, g_t) representa a inclinação (gradiente) da i-ésima perda de verificação da tarefa, θ_t representa os parâmetros da rede na t-ésima iteração , α é a taxa de aprendizagem e ε é uma constante pequena usada para evitar a divisão por zero. Além disso, gostaríamos de obter mais explicações sobre como o equilíbrio convergente é alcançado. Para garantir que as tarefas convirjam em velocidades semelhantes, introduzimos um mecanismo de balanceamento dinâmico. Em cada iteração, atualizamos os pesos específicos da tarefa com base no gradiente da perda de validação da tarefa. Este método visa dar mais atenção às tarefas que convergem mais lentamente, permitindo-lhes ter um maior impacto no processo global de otimização. Ao ajustar dinamicamente os pesos das tarefas, criamos um cenário de convergência equilibrado onde todas as tarefas progridem em direção à sua solução ideal a uma taxa semelhante. Este mecanismo resolve efetivamente o problema de diferentes velocidades de convergência e melhora a estabilidade geral e o desempenho da estrutura MFTCoder.

Ao combinar essas diferentes funções de perda, o MFTCoder pode resolver efetivamente as diferentes necessidades de vários cenários multitarefa e aliviar o desequilíbrio dos dados da tarefa, a dificuldade desigual e a velocidade de convergência inconsistente comumente encontradas na pesquisa de aprendizagem multitarefa em grande escala existente. Como uma estrutura flexível, o MFTCoder fornece soluções eficazes para esses problemas e apoia o desenvolvimento de modelos multitarefa mais eficientes e precisos.

 

3. Experimente

Nesta seção, usaremos o MFTCoder para conduzir vários conjuntos de experimentos para verificar a eficácia e superioridade do método MFT. Especificamente, pretendemos responder às seguintes três questões de pesquisa:

  • RQ1: O modelo MFT obtido pelo ajuste fino de múltiplas tarefas usando o método MFT é melhor do que o modelo SFT-S (tarefa única) obtido pelo ajuste fino de cada tarefa individualmente?
  • RQ2: O modelo MFT é melhor que o modelo SFT-Mixed (tarefa mista), que é obtido pelo ajuste fino de múltiplas tarefas como uma única tarefa? 
  • RQ3: O modelo MFT é melhor que o modelo SFT-Misto em termos de capacidade de generalização para tarefas invisíveis?

A seguir, primeiro apresentamos a configuração experimental. Em seguida, apresentamos e nos aprofundamos nos resultados experimentais. Por fim, resumiremos e responderemos às questões de pesquisa colocadas nesta seção.

3.1 Configuração experimental

Para responder a essas três questões de pesquisa, selecionamos 5 tarefas downstream relacionadas ao código e preparamos os dados de ajuste fino correspondentes, conforme mostrado na Tabela 1 . A Tabela 1 mostra as habilidades alvo (coluna III) e o tamanho da amostra (coluna IV) para cada tarefa. Por exemplo, CODECOMPLETION-TASK visa melhorar os recursos de conclusão de código do modelo e inclui 192.547 amostras de ajuste fino. CODETRANS-TASK foi projetado para aprimorar os recursos de tradução de código do modelo e contém 307.585 amostras ajustadas. Portanto, treinamos um total de 7 modelos (coluna I), incluindo o modelo SFT-S-* treinado separadamente para cada tarefa downstream, o modelo SFT-MIXED com os 5 dados da tarefa misturados em um, e o método MFT treinado MFT- Modelo 5TASKS.

 

Nos experimentos, todos os modelos foram configurados de forma idêntica, exceto os dados de treinamento. O modelo base para todos os modelos é o Code Llama-13B-Python (Rozière et al., 2023). Cada modelo usa 16 GPUs A100 (memória de vídeo de 80 GB), o tamanho do microlote é 8 e o tamanho global do lote é 128 para treinamento. Usando o otimizador Adam (Kingma e Ba, 2017), a taxa de aprendizagem inicial é 2e-4 e a taxa de aprendizagem mínima é 1e-5. Usamos o modo QLora-INT4 do MFTCoder para ajuste fino, a proporção do parâmetro de ajuste fino é de 2,52%, e a posição e o valor inicial dos parâmetros treináveis ​​também são os mesmos. Todos os modelos adotam a função de perda de equalização de dados (ou seja, fórmula (1) ) e usam o modo de tokenização empacotado. É importante notar que quando há apenas uma tarefa, esta função de perda é consistente com a função de perda tradicional usada no pré-treinamento do modelo GPT padrão. Para fazer com que cada modelo convirja o mais completamente possível, encerraremos o treinamento do modelo quando a perda de validação de duas épocas consecutivas do modelo for maior do que a perda de validação da época imediatamente anterior e selecionaremos o ponto de verificação do modelo correspondente ao terceiro para última época como objeto de avaliação.

3.2 Conjunto de avaliação

Neste artigo, usamos conjuntos de revisão de código representativos e disponíveis publicamente para avaliação comparativa, incluindo:

  • HumanEval (Chen et al., 2021) é um conjunto de dados de avaliação de conclusão de código Python amplamente utilizado, cuidadosamente projetado por pesquisadores da OpenAI. 
  • HumanEval-X (Zheng et al., 2023) estende HumanEval em múltiplas linguagens de programação por meio de tradução, realizando avaliação de conclusão de código multilíngue. 
  • DS-1000 (Lai et al., 2022) concentra-se na avaliação da capacidade do modelo de realizar análises de ciência de dados usando código Python, abrangendo bibliotecas importantes como Numpy, Pandas, TensorFlow, Pytorch, Scipy, Sklearn e Matplotlib. 
  • MBPP (Austin et al., 2021) contém 1.000 questões de programação Python, construídas por meio de crowdsourcing, e avalia principalmente a capacidade do modelo de dominar Python básico. Neste estudo, selecionamos 500 questões com IDs 11-510 do MBPP para avaliar a capacidade do modelo de gerar códigos baseados em descrições textuais.
  • CodeFuseEval ( https://github.com/codefuse-ai/codefuse-evaluation ), baseado em HumanEval e HumanEval-X, expande ainda mais o escopo de avaliação e adiciona preenchimento de código chinês (docstring está em chinês), tradução de código e caso de teste único avaliação da capacidade de geração, os subconjuntos correspondentes são chamados CodeFuseEval-CN, CodeFuseEval-CodeTrans e CodeFuseEval-UnitTest respectivamente.

No conjunto de avaliação acima, todos usamos " pass @1 " como índice de avaliação neste artigo.

3.3 Resultados experimentais

A seguir, mostramos os resultados da avaliação dos 7 modelos treinados. Para cada modelo SFT-S-* de tarefa única, nos concentramos em testar seus recursos de destino específicos. Por exemplo, para o modelo SFT-S-CODECOMPLETION treinado apenas com o conjunto de dados de conclusão de código, testamos apenas sua capacidade na conclusão de código. Desempenho . Por outro lado, para o modelo SFT-MIXED e o modelo MFT-5TASKS, avaliaremos seu desempenho em cada tarefa e compararemos com o modelo SFT-S-* correspondente. Especificamente, avaliamos o desempenho de sete modelos em dimensões de capacidade, como conclusão de código, Text2Code, geração de anotação de código, tradução de código e geração de caso de teste único.

3.3.1 Conclusão de código

Para a tarefa de conclusão de código, usamos os conjuntos de dados de avaliação HumanEval e HumanEval-X para avaliar o desempenho do modelo, usando pass@1 como índice de avaliação. Foram avaliados 3 modelos: SFT-S-CODECOMPLETION, SFT-MIXED e MFT-5TASKS. Um resumo do desempenho desses modelos no conjunto de dados HumanEval é mostrado na Tabela 2 (coluna III). Os resultados mostram que o modelo MFT-5TASKS treinado pelo método MFT supera os outros dois modelos. Comparado com o modelo SFT-MIXED ajustado usando dados de tarefas mistas, seu desempenho foi melhorado em 2,44%. Vale a pena notar que o desempenho do modelo SFT-MIXED não é tão bom quanto o modelo SFT-S-CODECOMPLETION, que é treinado separadamente para tarefas de conclusão de código.

Além disso, também avaliamos os recursos de conclusão de código multilíngue dos três modelos no conjunto de dados HumanEval-X, conforme mostrado na Tabela 3 . O modelo MFT-5TASKS apresenta excelente desempenho em Java e Golang, enquanto o modelo SFT-MIXED apresenta bom desempenho em C++ e JavaScript. No geral, o modelo MFT-5TASKS tem um desempenho melhor que os outros dois modelos, com uma melhoria média de 1,22% em comparação com o modelo SFT-MIXED.

No geral, em termos de tarefas de conclusão de código, os modelos treinados usando o método MFT superaram os modelos ajustados sozinhos e os modelos ajustados pela mistura de múltiplas tarefas.

3.3.2 Texto2Código

Para avaliar a capacidade do modelo de gerar código com base em descrições, selecionamos o conjunto de avaliação MBPP e usamos pass@1 como métrica de avaliação. Testamos e comparamos 3 modelos no conjunto de dados MBPP: SFT-S-TEXT2CODE, SFT-MIXED e MFT-5TASKS, conforme mostrado na Tabela 2 (Coluna IV). Dentre esses modelos, o MFT-5TASKS apresenta o maior desempenho, 2,4% superior ao modelo SFT-MIXED. Da mesma forma, na tarefa de geração de texto para código, um modelo obtido pelo ajuste fino de uma mistura de múltiplas tarefas apresentou desempenho inferior do que um modelo ajustado apenas para esta tarefa.

No geral, em termos de tarefas de geração de texto para código, os modelos treinados usando o método MFT superaram os modelos ajustados sozinhos e os modelos ajustados pela mistura de múltiplas tarefas.

3.3.3 Geração de comentários de código

O objetivo da tarefa de geração de comentários de código é permitir que o modelo adicione os comentários necessários ao código, incluindo comentários de linha e comentários de interface, sem modificar o próprio código de entrada, tornando o código mais legível e fácil de usar. Para avaliar esta capacidade, construímos um conjunto de avaliação baseado em 500 conjuntos de testes MBPP (id 11-510). Para cada questão do conjunto de avaliação, permitimos que os modelos SFT-S-CODECOMMENT, SFT-MIXED e MFT-5TASKS gerem anotações. Em seguida, usamos o GPT-4, que aprendeu bons padrões de anotação de código, como árbitro para determinar qual modelo tem melhor desempenho e, se não puder ser julgado, produzimos UNKNOWN. Por fim, contamos o número de problemas para os quais cada modelo foi identificado como de melhor desempenho e calculamos as proporções correspondentes, conforme mostrado na Tabela 4 . Pode-se observar que 38,8% dos problemas foram determinados como sendo do modelo MFT-5TASKS, que teve melhor desempenho, superando o modelo SFT-MIXED do segundo colocado em 7,4% e o modelo SFT-S-CODECOMMENT do terceiro colocado em 10,8 %. Além disso, 1,8% das questões foram marcadas como indecidíveis pelo GPT-4.

No geral, o modelo treinado pelo método MFT apresenta o melhor desempenho na tarefa de geração de anotações de código.

3.3.4 Tradução de Código

O objetivo da tarefa de tradução de código é traduzir com precisão um determinado fragmento de código-fonte em um fragmento de código equivalente no idioma de destino, ou seja, garantir que ambas as implementações tenham a mesma funcionalidade. Aqui, aproveitamos o subconjunto de tradução de código do conjunto de avaliação CODEFUSEEVAL, que oferece suporte à avaliação de tradução bidirecional entre Java, Python e C++. Para avaliar a precisão e equivalência funcional dos resultados da tradução, utilizamos casos de teste semanticamente equivalentes ao programa fonte para verificar se o código resultante pode ser executado e aprovado com sucesso, ou seja, atende ao padrão pass@1. Os resultados dos testes dos três modelos são mostrados na Tabela 5 : O modelo MFT-5TASKS teve melhor desempenho na tradução de Python para Java, Python para C++ e C++ para Java; o modelo SFT-MIXED teve melhor desempenho na tradução de C++ para Python , enquanto o modelo SFT-S-CODETRANS tem melhor desempenho em traduções de Java para Python e de Java para C++. No geral, o modelo MFT-5TASKS apresenta desempenho superior, com média 0,93% superior ao modelo SFT-MIXED e 10,9% superior ao modelo SFT-S-CODETRANS.

Em resumo, na tarefa de tradução de código, o modelo treinado pelo método MFT é melhor que os modelos obtidos pelos outros dois métodos de treinamento.

3.3.5 Geração de caso de teste único

A tarefa de geração de caso de teste único é gerar um conjunto de casos de teste de unidade para um determinado fragmento de código (como um método ou classe) treinando o modelo para verificar se a implementação do código fornecido está correta. Optamos por usar o subconjunto UNITTEST do conjunto de avaliação CODEFUSEEVAL como nosso conjunto de dados de teste. Da mesma forma, a métrica pass@1 é usada como métrica de avaliação, o que significa que se o modelo gerar casos de teste para a amostra de entrada (snippet de código) e a amostra de entrada passar em todos os casos de teste, o número de amostras geradas corretamente será aumentado em 1. A estratégia de decodificação gananciosa também é utilizada durante o processo de avaliação.

Comparamos os recursos de geração de casos de teste únicos dos três modelos em Python, Java e JavaScript, conforme mostrado na Tabela 6 . Os resultados mostram que o modelo MFT-5TASKS é superior a outros modelos na geração de casos de teste únicos em Python, 5,73% superior ao modelo SFT-MIXED do segundo colocado e 10,19% à frente do modelo SFT-S-UNITTEST do terceiro colocado . Em JavaScript, o modelo MFT-5TASKS também teve um bom desempenho, liderando os demais modelos em 7,93%. Porém, em Java, o desempenho do modelo MFT-5TASKS é 5,37% superior ao SFT-S-UNITTEST, mas 5,44% inferior ao SFT-MIXED. No geral, o modelo MFT-5TASKS ainda apresenta o desempenho mais elevado, com uma melhoria média de 2,74% em comparação com o modelo SFT-MIXED e uma melhoria média de 7,83% em comparação com o modelo SFT-S-UNITTEST.

Em resumo, os modelos treinados usando o método MFT apresentam melhor desempenho do que os modelos de tarefa única e os modelos de tarefa mista.

3.3.6 Desempenho de generalização em tarefas invisíveis

Além de avaliar o desempenho do modelo em tarefas com dados de treinamento para responder RQ1 e RQ2, este artigo também testa e responde se o modelo MFT apresenta melhor capacidade de generalização do que o modelo de tarefas mistas em tarefas não vistas (ou seja, RQ3). Para responder a esta questão, o artigo selecionou a tarefa de geração de Texto para SQL como alvo de teste. Os dados para esta tarefa não estão incluídos no treinamento dos 7 modelos existentes. Além disso, esta tarefa tem dependências de código óbvias, mas é diferente das 5 tarefas downstream existentes.

O artigo selecionou dois indicadores de avaliação, a pontuação BLEU e a precisão lógica da instrução SQL. O BLEU avalia a semelhança textual entre a saída gerada e a resposta de referência. Por outro lado, a métrica de precisão lógica é usada para lidar com a situação em que o significado está correto, mas a instrução SQL é expressa de forma diferente. Especificamente, a precisão lógica mede a proporção de amostras de teste para as quais as instruções SQL geradas no conjunto de dados são sintaticamente corretas e semanticamente equivalentes à resposta de referência.

 

O artigo selecionou 5 conjuntos de dados Text2SQL representativos, incluindo WikiSQL (Zhong et al., 2017), Spider (Yu et al., 2019b), CSpider (Min et al., 2019), CoSQL (Yu et al., 2019a) e BirdSQL (Li et al., 2023d) e 200 exemplos foram selecionados aleatoriamente de cada conjunto de dados para avaliação. O exemplo do caso de teste é mostrado na Tabela 7 , onde a primeira linha mostra o formato de dados de ajuste fino semelhante ao formato OpenAI ChatML. Para cada conjunto de dados amostrado, o artigo testou a precisão lógica e a pontuação BLEU dos modelos SFT-MIXED e MFT-5TASKS, conforme mostrado na Tabela 8 . De acordo com a Tabela 8, a pontuação BLEU do modelo MFT-5TASKS é superior à do modelo SFT-MIXED em cada conjunto de dados, com média 2,78 vezes superior. Isso indica que os resultados gerados pelo MFT-5TASKS são mais parecidos com o texto das respostas de referência. Essa semelhança também pode ser observada na Tabela 7 , onde o modelo MFT-5TASKS gera resultados mais limpos, enquanto o modelo SFT-MIXED fornece mais explicações (que podem ser preferidas em alguns casos). Além disso, o MFT-5TASKS tem melhor desempenho em termos de precisão lógica, com precisão geral 2,18 vezes maior que o modelo SFT-MIXED e 4,67 vezes maior no conjunto de dados WikiSQL.

 

Numericamente, o MFT-5TASKS apresenta melhor desempenho que o SFT-MIXED, indicando que o modelo treinado pelo MFT possui maior capacidade de generalização em tarefas invisíveis, que não são vistas durante o processo de treinamento.

 

3.4 Resumo da experiência

Este artigo selecionou 5 tarefas downstream relacionadas ao código e treinou um total de 7 modelos, incluindo o modelo SFT-S-* que foi ajustado separadamente para cada tarefa, o modelo SFT-MIXED que foi ajustado usando uma mistura de todos os dados da tarefa e o modelo SFT-MIXED que foi ajustado usando uma mistura de todos os dados da tarefa.Modelo MFT-5TASKS treinado pelo método MFT. O artigo compara e testa o desempenho de cada modelo em termos de suas capacidades alvo. Além disso, o artigo também avalia comparativamente o desempenho de generalização do método MFT e do método SFT híbrido em tarefas invisíveis. A conclusão é resumida da seguinte forma: 

  • Os modelos treinados pelo método MFT superaram os modelos ajustados individualmente para cada tarefa, respondendo afirmativamente ao RQ1. 
  • Os modelos treinados usando o método MFT superaram os modelos ajustados usando uma mistura de múltiplas tarefas, respondendo afirmativamente ao RQ2. 
  • O modelo treinado usando o método MFT mostra maior capacidade de generalização em novas tarefas invisíveis do que o modelo SFT ajustado usando uma mistura de múltiplas tarefas.

4. Aplicativo MFTCoder

Tendo em vista o excelente desempenho do método de treinamento MFT, usamos o MFTCoder para nos adaptar aos atuais LLMs de código aberto convencionais, incluindo QWen, Baichuan 1/2, CodeGeex2, Llama 1/2, CodeLLama, StarCoder, etc.

MFTCoder oferece suporte a Lora e QLora, o que reduz significativamente o número de parâmetros de treinamento de modelo que precisam ser treinados. No processo de adaptação e ajuste desses modelos, definimos os parâmetros treináveis ​​na faixa de 0,1% a 5% dos parâmetros totais. Uma grande quantidade de prática mostrou que à medida que a proporção de parâmetros treináveis ​​aumenta, o desempenho do modelo não continuará a melhorar, mas logo ficará saturado.Na prática, observou-se que a proporção de parâmetros treináveis ​​não excede 5%, o que geralmente pode atingir um nível de desempenho próximo ao ajuste fino completo. Além disso, durante esses processos de ajuste fino, configuraremos e usaremos de 3 a 7 tarefas relacionadas ao código. Geralmente usamos o modo Lora para modelos abaixo de 20B e o modo QLora para modelos acima de 20B. Após a conclusão do ajuste fino, avaliamos o desempenho desses modelos nas tarefas de conclusão de código e Text2Code, conforme mostrado nas colunas III e IV da Tabela 9 . O artigo calcula a melhoria média do índice de ajuste fino do MFT em comparação com o modelo de linha de base nos conjuntos de avaliação HumanEval e MBPP.Conforme mostrado na coluna 5, a melhoria varia de 6,26% a 12,75%, e a melhoria no HumanEval excede a do MBPP .a magnitude acima.

 

 

Além disso, o artigo também avalia o desempenho de conclusão de código do modelo ajustado pelo MFTCoder no benchmark multilíngue HumanEval-X, conforme mostrado na Tabela 10 . É importante notar que o CodeFuse-CodeLLama-Python-MFT (34B) ajustado atinge uma aprovação média de 56,88% em quatro linguagens (Java, C++, JavaScript e Golang).

 

Em particular, a Tabela 9 também mostra o desempenho de alguns modelos representativos de código aberto ajustados (como OctoPack e WizardCoder-Python) e modelos de código fechado (como Claude2 e GPT-4) em HumanEval e MBPP. É importante notar que nosso modelo CodeFuse-CodeLLama-34B ajustado alcançou pass@1 74,4% no HumanEval, superando todos os modelos listados na tabela, incluindo GPT-4 (67,00%, tiro zero, março de 2023) . Para este modelo, o artigo também avaliou seu desempenho em outros testes de benchmark, incluindo HUMANEVAL-X multilíngue, MBPP, DS-1000 e CODEFUSEEVAL, e comparou-o com GPT-3.5 e GPT-4, conforme . CodeFuse-CodeLLama-34B supera GPT-4 em CODEFUSEEVAL-UNITTEST e HUMANEVAL e é equivalente a ele em recursos de tradução de código, mas tem baixo desempenho em preenchimento de código chinês (CODEFUSEEVAL-CN), preenchimento multilíngue e análise de ciência de dados ( DS-1000). ) e os recursos de geração de texto para código (MBPP) são ligeiramente inferiores ao GPT-4. No entanto, ele não tem desempenho pior que o GPT-3.5 em todos os conjuntos de dados de avaliação.

Figura 6: Gráfico de radar comparando o desempenho do CodeFuse-CodeLLama-34B com GPT-3.5/GPT-4 em vários conjuntos de avaliação de código

 

Além disso, conduzimos uma avaliação adicional para avaliar o impacto no desempenho do ajuste fino do modelo em tarefas de PNL usando MFTCoder e dados relacionados ao código. Tomando CODEFUSE-QWEN-14B como exemplo, comparamos seu desempenho de PNL com o modelo básico QWEN-14B e o QWEN-14B-CHAT oficial ajustado do Alibaba Cloud, conforme . Obviamente, a capacidade do CODEFUSE-QWEN-14B em tarefas de PNL não diminuiu, pelo contrário, em comparação com os outros dois modelos, apresenta melhor desempenho em linguagem (AFQMC, CHID, Wic, WSC), raciocínio (COPA, CMNLI, OCNLI, AX-b, AX-g, RTE) e compreensão (CSL, C3, EPRSTMT) . No entanto, em comparação com o modelo de referência QWEN-14B, suas capacidades de assunto abrangentes (MMLU, C-Eval, ARC-c) diminuíram ligeiramente. Um fenômeno de declínio semelhante também aparece no modelo QWEN-14B-CHAT. Os dados detalhados são mostrados na Tabela 11 mostrada. Em média, em várias tarefas (incluindo codificação), CodeFuse-QWen-14B melhorou 2,56% e 4,82%, respectivamente, em comparação com Qwen-14B e QWen-14B-chat, enquanto QWen-14B-chat diminuiu 2,26% em comparação com QWen-14B .

Figura 7: Gráfico de radar comparando o desempenho do CodeFuse-QWen-14B com Qwen-14B e QWen-14B-chat em tarefas de avaliação de PNL e codificação

 

Tabela 11: Comparação de CodeFuse-QWen-14B, QWen-14B e QWen-14B-chat em tarefas de PNL.

5. Resumo

Este artigo apresenta o MFTCoder, que introduz o aprendizado multitarefa no estágio de ajuste fino (código) de grandes modelos e alivia efetivamente os desafios de volume desigual de dados, dificuldade variável e velocidades de convergência inconsistentes no aprendizado multitarefa, projetando ou aplicando múltiplas funções de perda balanceadas.Um grande número de resultados experimentais mostram que os modelos ajustados multitarefa têm melhor desempenho do que os modelos ajustados individualmente para cada tarefa downstream e os modelos ajustados após a mistura de dados multitarefa em um. MFTCoder fornece soluções de treinamento eficientes, incluindo modo eficiente de tokenização de dados e suporte PEFT, e fornece soluções de construção de conjuntos de dados de instruções de alta qualidade. Além disso, o MFTCoder foi adaptado para muitos modelos grandes de código aberto atualmente populares, entre eles o modelo CodeFuse-CodeLLama-34B, que é baseado em CodeLLama-34B-Python e ajustado usando MFTCoder, alcançou uma pontuação pass@1 de 74,4% no conjunto de dados HumanEval, superando GPT-4 (67%, disparo zero, março de 2023).

Referência

Artigo de referência específico: https://arxiv.org/pdf/2311.02303.pdf . A seguir estão os artigos citados neste artigo.

  • Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li e Peter J. Liu. 2023. Explorando os limites da aprendizagem por transferência com um transformador unificado de texto para texto. arXiv:cs.LG/1910.10683 
  • Armen Aghajanyan, Anchit Gupta, Akshat Shrivastava, Xilun Chen, Luke Zettlemoyer e Sonal Gupta. 2021. Muppet: representações multitarefa massivas com pré-ajuste. arXiv:cs.CL/2101.11038 
  • Vamsi Aribandi, Yi Tay, Tal Schuster, Jinfeng Rao, Huaixiu Steven Zheng, Sanket Vaibhav Mehta, Honglei Zhuang, Vinh Q. Tran, Dara Bahri, Jianmo Ni, Jai Gupta, Kai Hui, Sebastian Ruder e Donald Metzler. 2022. ExT5. : Rumo ao escalonamento multitarefa extremo para aprendizagem por transferência. arXiv:cs.CL/2111.10952
  • Edward J. Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang e Weizhu Chen. 2021. LoRA: Adaptação de baixo nível de modelos de linguagem grande. arXiv:cs.CL/2106.09685 
  • Tim Dettmers, Artidoro Pagnoni, Ari Holtzman e Luke Zettlemoyer. 2023. QLoRA: Ajuste fino eficiente de LLMs quantizados. arXiv:cs.LG/2305.14314 
  • Yizhong Wang, Yeganeh Kordi, Swaroop Mishra, Alisa Liu, Noah A Smith, Daniel Khashabi e Hannaneh Hajishirzi. 2022. Autoinstruir: Alinhando o modelo de linguagem com instruções autogeradas.  Pré-impressão arXiv arXiv:2212.10560  (2022). 
  • Suriya Gunasekar, Yi Zhang, Jyoti Aneja, Caio César Teodoro Mendes, Allie Del Giorno, Sivakanth Gopi, Mojan Javaheripi, Piero Kauffmann, Gustavo de Rosa, Olli Saarikivi, et al. 2023. Os livros didáticos são tudo que você precisa.  Pré-impressão do arXiv arXiv:2306.11644  (2023). 
  • Guohao Li, Hassan Abed Al Kader Hammoud, Hani Itani, Dmitry Khizbullin e Bernard Ghanem. 2023c. CAMEL: Agentes Comunicativos para Exploração da "Mente" da Sociedade Modelo de Linguagem em Grande Escala. arXiv: cs.AI/2303 
  • Peng Di, Jianguo Li, Hang Yu, Wei Jiang, Wenting Cai, Yang Cao, Chaoyu Chen, Dajun Chen, Hongwei Chen, Liang Chen, Gang Fan, Jie Gong, Zi Gong, Wen Hu, Tingting Guo, Zhichao Lei, Ting Li , Zheng Li, Ming Liang, Cong Liao, Bingchang Liu, Jiachen Liu, Zhiwei Liu, Shaojun Lu, Min Shen, Guangpei Wang, Huan Wang, Zhi Wang, Zhaogui Xu, Jiawei Yang, Qing Ye, Gehao Zhang, Yu Zhang, Zelin Zhao, Xunjin Zheng, Hailian Zhou, Lifu Zhu e Xianying Zhu. 2023. CodeFuse-13B: um modelo de linguagem grande com código multilíngue pré-treinado. arXiv:cs.SE/2310.06266 
  • Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yasmine Babaei, Nikolay Bashlykov, Soumya Batra, Prajjwal Bhargava, Shruti Bhosale, e outros. 2023b. Llama 2: Base aberta e modelos de chat ajustados.  Pré-impressão do arXiv arXiv:2307.09288  (2023). 
  • Neil Houlsby, Andrei Giurgiu, Stanislaw Jastrzebski, Bruna Morrone, Quentin de Laroussilhe, Andrea Gesmundo, Mona Attarian e Sylvain Gelly. 2019. Aprendizagem por transferência com eficiência de parâmetros para PNL. arXiv:cs.LG/1902.00751 
  • Bo Liu, Yihao Feng, Peter Stone e Qiang Liu. 2023. FAMO: Otimização multitarefa adaptativa rápida. arXiv:cs.LG/2306.03792 
  • Baptist Rozier, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jeremy Rapin, e outros. 2023. Código flamejante: modelos básicos abertos para código.  Pré-impressão arXiv arXiv:2308.12950  (2023). 
  • Diederik P. Kingma e Jimmy Ba. 2017. Adam: Um Método para Otimização Estocástica. arXiv:cs.LG/1412.6980 
  • Qinkai Zheng, Xiao Xia, Xu Zou, Yuxiao Dong, Shan Wang, Yufei Xue, Zihan Wang, Lei Shen, Andi Wang, Yang Li, Teng Su, Zhilin Yang e Jie Tang. 2023. CodeGeeX: um modelo pré-treinado para Geração de código com avaliações multilíngues em HumanEval-X. Em  KDD . 
  • Yuhang Lai, Chengxi Li, Yiming Wang, Tianyi Zhang, Ruiqi Zhong, Luke Zettlemoyer, Scott Wen tau Yih, Daniel Fried, Sida Wang e Tao Yu. 2022. DS-1000: uma referência natural e confiável para geração de código de ciência de dados.  ArXivabs  /2211.11501 (2022). 
  • Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al. 2021. Síntese de Programas com Grandes Modelos de Linguagem.  Pré-impressão arXiv arXiv:2108.07732  (2021). 
  • Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri e outros. no Código. (2021). arXiv:cs.LG/2107.03374 

Contate-nos

O MFTCoder é de código aberto, e os modelos e conjuntos de dados mencionados neste artigo também são de código aberto. Se você gosta do nosso trabalho, fique à vontade para experimentá-lo, corrigir erros e contribuir com código. Se puder, adicione Star ao nosso projeto para nos apoiar.

 

 

O Alibaba Cloud sofreu uma falha grave, afetando todos os produtos (foi restaurado). O sistema operacional russo Aurora OS 5.0, uma nova UI, foi revelado no Tumblr. Muitas empresas de Internet recrutaram urgentemente programadores Hongmeng . .NET 8 é oficialmente GA, o mais recente Versão LTS Tempo UNIX Está prestes a entrar na era de 1,7 bilhão (já entrou). A Xiaomi anunciou oficialmente que o Xiaomi Vela é totalmente de código aberto. O kernel subjacente é .NET 8 no NuttX Linux. O tamanho independente é reduzido em 50%. FFmpeg 6.1 "Heaviside" é lançado. Microsoft lança um novo "Windows App"
{{o.nome}}
{{m.nome}}

Acho que você gosta

Origin my.oschina.net/u/6942768/blog/10143310
Recomendado
Clasificación