ChipNeMo : LLM adaptés au domaine pour la conception de puces : méthodes d'adaptation de domaine ChipNemo

Tableau des liens

• Résumé et introduction
• Base de données
• Méthodes d'adaptation de domaine ChipNemo
• Candidatures LLM
• Évaluations
• Discussion
• Travaux connexes
• Conclusions
• Remerciements, contributions et références
• annexe

III. MÉTHODES D'ADAPTATION DU DOMAINE CHIPNEMO

ChipNeMo implémente plusieurs techniques d'adaptation de domaine pour adapter les LLM au domaine de la conception de puces. Ces techniques incluent des tokeniseurs personnalisés pour les données de conception de puces, un pré-entraînement adaptatif de domaine avec un vaste corpus de données de domaine, un réglage fin supervisé avec des tâches spécifiques au domaine et une génération améliorée de récupération avec un modèle de récupération affiné. Nous illustrerons les détails de chaque technique dans cette section.

A. Tokeniseur

Lors de l'adaptation d'un tokeniseur pré-entraîné, les principaux objectifs sont d'améliorer l'efficacité de la tokenisation sur des données spécifiques à un domaine, de maintenir l'efficacité et les performances du modèle de langage sur des ensembles de données généraux et de minimiser les efforts de recyclage/de réglage fin. Pour y parvenir, nous avons développé une approche en quatre étapes :

• Étape 1 : formation d'un tokenizer à partir de zéro à l'aide de données spécifiques au domaine.

• Étape 2 : À partir du vocabulaire du nouveau tokenizer, identifier les tokens absents dans le tokenizer à usage général et rarement trouvés dans les ensembles de données à usage général.

• Étape 3 : Extension du tokenizer à usage général avec les jetons nouvellement identifiés à l'étape 2.

• Étape 4 : initialisation des intégrations des nouveaux jetons en utilisant le tokenizer à usage général.

Spécifiquement pour l'étape 4, lorsqu'un nouveau jeton est rencontré, il est tokenisé à l'aide du tokenizer à usage général pré-entraîné. L'intégration du nouveau jeton est déterminée en faisant la moyenne des intégrations des jetons générés par le tokenizer à usage général [24] et des poids de la couche de sortie initialisés à zéro.

L'étape 2 permet de maintenir les performances du LLM pré-entraîné sur des ensembles de données généraux en introduisant de manière sélective de nouveaux jetons rarement rencontrés dans les ensembles de données à usage général. Et l'étape 4 réduit l'effort requis pour recycler/affiner le LLM via l'initialisation des intégrations de nouveaux jetons guidées par le tokenizer à usage général.

B. Pré-formation adaptative au domaine

Dans notre étude, nous appliquons DAPT sur des modèles de base de fondation pré-entraînés LLaMA2 7B/13B. Chaque modèle DAPT est initialisé à l'aide des poids de leurs modèles de base fondamentaux pré-entraînés correspondants. Nous nommons nos modèles DAPT ChipNeMo . Nous utilisons l'augmentation du tokenizer comme décrit dans la section III-A et initialisons le poids d'intégration en conséquence [24]. Nous effectuons une pré-formation supplémentaire sur des données spécifiques à un domaine en utilisant l'objectif standard de modélisation de langage autorégressive. Toutes les procédures de formation de modèles sont effectuées à l'aide du framework NVIDIA NeMo [25], incorporant des techniques telles que le parallélisme tensoriel [26] et l'attention flash [27] pour une efficacité améliorée.

La figure 2 illustre la perte de formation de ChipNeMo sous les hyperparamètres spécifiés. Nous observons des pics de perte d’entraînement. Contrairement à l'hypothèse de [28], nous postulons que dans notre scénario, ces pics peuvent être attribués à des « mauvaises données » puisque ces irrégularités semblent se produire systématiquement lors d'étapes de formation similaires pour le même modèle, même pour des tailles de modèle différentes. Nous avons choisi de ne pas aborder ce problème, car ces anomalies ne semblent pas gêner de manière significative les étapes de formation ultérieures (sans dégradation notable de la perte de validation), probablement en raison de notre application d'un faible taux d'apprentissage.

C. Mise au point supervisée

Après DAPT, nous effectuons l'alignement du modèle avec un réglage fin supervisé (SFT). Nous adoptons la configuration de formation d'hyperparamètres identique à celle de DAPT pour tous les modèles, à l'exception de l'utilisation d'une taille de lot globale réduite à 128. Toutes les données SFT sont structurées selon le modèle de discussion ci-dessous :

<extra_id_0>système\n{système}

<extra_id_1>Utilisateur\n{user_utterance}

<extra_id_1>Assistant\n{chipnemo_response}

…

Nous utilisons un objectif d'optimisation autorégressif, mettant en œuvre une stratégie dans laquelle les pertes associées aux jetons provenant du système et aux invites de l'utilisateur sont masquées [5]. Cette approche garantit que lors de la rétropropagation, notre concentration est exclusivement dirigée vers l'optimisation des jetons de réponse.

Nous combinons notre ensemble de données SFT de domaine, comprenant environ 1,1 000 échantillons, avec l'ensemble de données SFT de chat général plus complet de 128 000 échantillons. Nous avons ensuite procédé à un réglage fin pour une seule époque après avoir appliqué un mélange aléatoire aux données. Nous avons mené des expériences impliquant l'augmentation de l'ensemble de données SFT spécifique au domaine pendant plus d'une époque. Cependant, il est devenu évident que le modèle présentait rapidement des signes de surajustement lorsqu'il était présenté avec des questions dans le domaine, répétant souvent des réponses non pertinentes de l'ensemble de données SFT du domaine.

De plus, nous avons effectué une SFT supplémentaire en utilisant uniquement l'ensemble de données de chat général, à l'exclusion de toute donnée SFT spécifique à un domaine. Pour plus de clarté, nous désignons tous nos modèles ChipNeMo comme suit :

1. ChipNeMo-Chat : modèles affinés avec les données de domaine et de chat générales ;

   
   

2. ChipNeMo-Chat (noDSFT) : modèles affinés exclusivement avec des données de chat générales.

Nous avons également expérimenté DAPT directement sur un modèle aligné sur le chat, tel que le modèle LLaMA2-Chat. Nous avons constaté que DAPT dégradait considérablement l'alignement du modèle, rendant le modèle résultant inutile pour les tâches en aval.

D. Génération augmentée par récupération

Il est bien connu que les LLM peuvent générer des textes inexacts, ce qu'on appelle des hallucinations [29]. Bien que le phénomène ne soit pas complètement compris, il faut néanmoins atténuer les hallucinations car elles sont particulièrement problématiques dans un contexte de chatbot d’assistant d’ingénierie, où la précision est essentielle. Notre proposition est d’exploiter la méthode de génération augmentée de récupération (RAG). RAG essaie de récupérer les passages pertinents d'une base de données pour les inclure dans l'invite avec la question, ce qui incite le LLM à produire des réponses plus précises. Nous constatons que l'utilisation d'un modèle linguistique adapté au domaine pour RAG améliore considérablement la qualité des réponses aux questions spécifiques à notre domaine. En outre, nous constatons que le réglage fin d'un modèle de récupération dense pré-entraîné non supervisé prêt à l'emploi avec une quantité modeste de données de formation spécifiques à un domaine améliore considérablement la précision de la récupération. Notre diagramme d’implémentation RAG adapté au domaine est illustré sur la figure 3.

Nous avons créé notre modèle de récupération adapté au domaine en affinant le modèle e5_small_unsupervised [30] avec 3000 échantillons générés automatiquement spécifiques au domaine à l'aide du framework Tevatron [31]. Le processus de génération d’échantillons et de formation est couvert à l’annexe C.

Même avec les gains significatifs liés à l'affinement d'un modèle de récupération, il n'en reste pas moins que la récupération se heurte toujours à des requêtes qui ne correspondent pas directement aux passages du corpus de documents ou qui nécessitent davantage de contexte non présent dans le passage. Malheureusement, ces requêtes sont également plus représentatives des requêtes qui seront posées par les ingénieurs en situation réelle. Combiner la récupération avec un modèle de langage adapté au domaine est une façon de résoudre ce problème.