Autores:
(1) Mingjie Liu, NVIDIA {Contribuição igual};
(2) Teodor-Dumitru Ene, NVIDIA {Contribuição igual};
(3) Robert Kirby, NVIDIA {Contribuição igual};
(4) Chris Cheng, NVIDIA {Contribuição igual};
(5) Nathaniel Pinckney, NVIDIA {Contribuição igual};
(6) Rongjian Liang, NVIDIA {Contribuição igual};
(7) Jonah Alben, NVIDIA;
(8) Himyanshu Anand, NVIDIA;
(9) Sanmitra Banerjee, NVIDIA;
(10) Ismet Bayraktaroglu, NVIDIA;
(11) Bonita Bhaskaran, NVIDIA;
(12) Bryan Catanzaro, NVIDIA;
(13) Arjun Chaudhuri, NVIDIA;
(14) Sharon Clay, NVIDIA;
(15) Bill Dally, NVIDIA;
(16) Laura Dang, NVIDIA;
(17) Parikshit Deshpande, NVIDIA;
(18) Siddhanth Dhodhi, NVIDIA;
(19) Sameer Halepete, NVIDIA;
(20) Eric Hill, NVIDIA;
(21) Jiashang Hu, NVIDIA;
(22) Sumit Jain, NVIDIA;
(23) Brucek Khailany, NVIDIA;
(24) George Kokai, NVIDIA;
(25) Kishor Kunal, NVIDIA;
(26) Xiaowei Li, NVIDIA;
(27) Charley Lind, NVIDIA;
(28) Hao Liu, NVIDIA;
(29) Stuart Oberman, NVIDIA;
(30) Sujeet Omar, NVIDIA;
(31) Sreedhar Pratty, NVIDIA;
(23) Jonathan Raiman, NVIDIA;
(33) Ambar Sarkar, NVIDIA;
(34) Zhengjiang Shao, NVIDIA;
(35) Hanfei Sun, NVIDIA;
(36) Pratik P Suthar, NVIDIA;
(37) Varun Tej, NVIDIA;
(38) Walker Turner, NVIDIA;
(39) Kaizhe Xu, NVIDIA;
(40) Haoxing Ren, NVIDIA.
ChipNeMo implementa múltiplas técnicas de adaptação de domínio para adaptar LLMs ao domínio de design de chip. Essas técnicas incluem tokenizadores personalizados para dados de design de chip, pré-treinamento adaptativo de domínio com grande corpus de dados de domínio, ajuste fino supervisionado com tarefas específicas de domínio e geração aumentada de recuperação com um modelo de recuperação ajustado. Ilustraremos os detalhes de cada técnica nesta seção.
A. Tokenizador
Ao adaptar um tokenizer pré-treinado, os principais objetivos são melhorar a eficiência da tokenização em dados específicos de domínio, manter a eficiência e o desempenho do modelo de linguagem em conjuntos de dados gerais e minimizar o esforço de retreinamento/ajuste fino. Para conseguir isso, desenvolvemos uma abordagem em quatro etapas:
• Etapa 1: treinar um tokenizer do zero usando dados específicos do domínio.
• Etapa 2: A partir do vocabulário do novo tokenizer, identificar tokens que estão ausentes no tokenizer de uso geral e raramente são encontrados em conjuntos de dados de uso geral.
• Etapa 3: Expandir o tokenizer de uso geral com os tokens recém-identificados na Etapa 2.
• Etapa 4: Inicializar os embeddings dos novos tokens utilizando o tokenizer de uso geral.
Especificamente para a Etapa 4, quando um novo token é encontrado, ele é tokenizado usando o tokenizer de uso geral pré-treinado. A incorporação do novo token é determinada pela média das incorporações dos tokens gerados pelo tokenizer de uso geral [24] e pelos pesos da camada de saída inicializados em zero.
A Etapa 2 ajuda a manter o desempenho do LLM pré-treinado em conjuntos de dados gerais, introduzindo seletivamente novos tokens que são raramente encontrados em conjuntos de dados de uso geral. E a Etapa 4 reduz o esforço necessário para retreinar/ajustar o LLM por meio da inicialização dos embeddings de novos tokens guiados pelo tokenizer de uso geral.
B. Pré-treinamento adaptativo de domínio
Em nosso estudo, aplicamos DAPT em modelos de base de fundação pré-treinados LLaMA2 7B/13B. Cada modelo DAPT é inicializado usando os pesos de seus modelos básicos pré-treinados correspondentes. Chamamos nossos modelos DAPT de ChipNeMo . Empregamos o aumento do tokenizer conforme descrito na Seção III-A e inicializamos o peso de incorporação de acordo [24]. Conduzimos pré-treinamento adicional em dados específicos de domínio, empregando o objetivo de modelagem de linguagem autorregressiva padrão. Todos os procedimentos de treinamento do modelo são conduzidos usando a estrutura NVIDIA NeMo [25], incorporando técnicas como paralelismo de tensor [26] e atenção flash [27] para maior eficiência.
A Figura 2 ilustra a perda de treinamento do ChipNeMo sob os hiperparâmetros especificados. Observamos picos na perda de treinamento. Em contraste com a hipótese em [28], postulamos que, em nosso cenário, esses picos podem ser atribuídos a “dados ruins”, uma vez que essas irregularidades parecem ocorrer consistentemente em etapas de treinamento semelhantes para o mesmo modelo, mesmo em modelos de tamanhos diferentes. Optamos por não abordar esta questão, pois estas anomalias não pareciam impedir significativamente as etapas de treinamento subsequentes (sem degradação perceptível na perda de validação), possivelmente devido à nossa aplicação de uma baixa taxa de aprendizagem.
C. Ajuste fino supervisionado
Após o DAPT, realizamos o alinhamento do modelo com ajuste fino supervisionado (SFT). Adotamos a configuração de treinamento de hiperparâmetros idêntica ao DAPT para todos os modelos, com exceção do uso de um tamanho de lote global reduzido de 128. Todos os dados SFT são estruturados de acordo com o modelo de chat abaixo:
<extra_id_0>sistema\n{sistema}
<extra_id_1>Usuário\n{user_utterance}
<extra_id_1>Assistente\n{chipnemo_response}
…
Empregamos um objetivo de otimização autorregressiva, implementando uma estratégia onde as perdas associadas aos tokens originados do sistema e aos prompts do usuário são mascaradas [5]. Essa abordagem garante que durante a retropropagação nosso foco seja direcionado exclusivamente para a otimização de tokens de resposta.
Combinamos nosso conjunto de dados SFT de domínio, compreendendo aproximadamente 1,1 mil amostras, com o conjunto de dados SFT de bate-papo geral mais extenso de 128 mil amostras. Em seguida, realizamos o ajuste fino para uma única época após aplicar um embaralhamento aleatório aos dados. Conduzimos experimentos envolvendo o aumento do conjunto de dados SFT específico do domínio por mais de uma época. No entanto, tornou-se evidente que o modelo exibiu rapidamente sinais de sobreajuste quando apresentado a questões no domínio, muitas vezes repetindo respostas irrelevantes do conjunto de dados SFT do domínio.
Além disso, realizamos uma OFVM adicional usando apenas o conjunto de dados de chat geral, excluindo quaisquer dados de OFVM específicos do domínio. Para maior clareza, designamos todos os nossos modelos ChipNeMo da seguinte forma:
ChipNeMo-Chat: Modelos ajustados com dados de domínio e de chat geral;
ChipNeMo-Chat (noDSFT): Modelos ajustados exclusivamente com dados gerais de chat.
Também experimentamos o DAPT diretamente em um modelo alinhado ao chat, como o modelo LLaMA2-Chat. Descobrimos que o DAPT degradou significativamente o alinhamento do modelo, tornando o modelo resultante inútil para tarefas posteriores.
D. Geração Aumentada por Recuperação
É bem sabido que os LLMs podem gerar texto impreciso, a chamada alucinação [29]. Embora o fenómeno não seja completamente compreendido, ainda devemos mitigar as alucinações, uma vez que são particularmente problemáticas num contexto de chatbot de assistente de engenharia, onde a precisão é crítica. Nossa proposta é aproveitar o método de geração aumentada de recuperação (RAG). O RAG tenta recuperar passagens relevantes de um banco de dados para serem incluídas no prompt junto com a pergunta, o que fundamenta o LLM para produzir respostas mais precisas. Descobrimos que o uso de um modelo de linguagem adaptado ao domínio para RAG melhora significativamente a qualidade das respostas em nossas perguntas específicas do domínio. Além disso, descobrimos que o ajuste fino de um modelo de recuperação denso pré-treinado não supervisionado e pronto para uso com uma quantidade modesta de dados de treinamento específicos de domínio melhora significativamente a precisão da recuperação. Nosso diagrama de implementação RAG adaptado ao domínio é ilustrado na Figura 3.
Criamos nosso modelo de recuperação adaptado ao domínio ajustando o modelo e5_small_unsupervised [30] com 3.000 amostras geradas automaticamente específicas do domínio usando a estrutura Tevatron [31]. A geração de amostras e o processo de treinamento são abordados no Apêndice C.
Mesmo com os ganhos significativos decorrentes do ajuste fino de um modelo de recuperação, permanece o fato de que a recuperação ainda enfrenta dificuldades com consultas que não são mapeadas diretamente para passagens no corpus do documento ou que exigem mais contexto não presente na passagem. Infelizmente, essas perguntas também são mais representativas das perguntas que serão feitas pelos engenheiros em situações reais. Combinar a recuperação com um modelo de linguagem adaptado ao domínio é uma forma de resolver esse problema.
Este artigo está disponível no arxiv sob licença CC 4.0.