Auteurs:
(1) Mingjie Liu, NVIDIA {Contribution égale} ;
(2) Teodor-Dumitru Ene, NVIDIA {Contribution égale} ;
(3) Robert Kirby, NVIDIA {Contribution égale} ;
(4) Chris Cheng, NVIDIA {Contribution égale} ;
(5) Nathaniel Pinckney, NVIDIA {Contribution égale} ;
(6) Rongjian Liang, NVIDIA {Contribution égale} ;
(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.
La collection a été implémentée avec un ensemble de scripts Shell et Python, conçus pour identifier les données de conception et la documentation pertinentes, les convertir en texte brut le cas échéant, les filtrer à l'aide de mesures de qualité de base, calculer une somme de contrôle pour une déduplication précise des fichiers et les compresser pour le stockage. Le flux de collecte n'a pas utilisé de scripts de scraping et de collecte spécifiques au LLM, car nous visions à minimiser les besoins en espace grâce à la collecte de données in situ de sources de données internes (à la fois les systèmes de fichiers en réseau et les applications Web internes). Pour la collecte basée sur le système de fichiers, les données étaient conservées en place tout en étant filtrées pour en vérifier la qualité, au lieu de stocker des ensembles supplémentaires de données brutes localement.
La collecte de données de conception et de vérification comprenait une variété de fichiers sources, notamment Verilog et VHDL (RTL et netlists), C++, Spice, Tcl, divers langages de script et des fichiers de configuration liés à la construction. Les données des services Web internes ont été collectées via des appels d'API REST et une exploration conventionnelle, le formatage HTML étant supprimé à l'aide de la bibliothèque Python open source BeautifulSoup [52] dans les deux cas afin de minimiser la suppression par inadvertance d'exemples de codage, au prix de l'introduction de davantage de chaudières. barres de navigation de plaque et autres éléments de page HTML. Notre flux de collecte de données prenait en charge les formats de documentation conventionnels, notamment .docx, .pptx et .pdf, à l'aide de bibliothèques de conversion Python et d'outils open source facilement disponibles.
Comme la plupart des données internes sont considérées comme étant de haute qualité, un filtrage minimal a été appliqué : un filtrage par nombre de lignes a été utilisé pour garantir que les fichiers extrêmement grands ou petits étaient exclus, et les fichiers ont été triés en grandes catégories (écrites manuellement ou générées par un outil).
Dans cette section, nous présentons des résultats détaillés sur nos modèles pré-entraînés adaptatifs de domaine. Nous détaillons également nos expériences d'ablation sur le pré-entraînement adaptatif de domaine.
Hyperparamètres DAPT : détails présentés dans le tableau VI.
Résultats de l'évaluation automatique : Nous présentons les résultats détaillés des critères d'évaluation automatique dans les tableaux VII et VIII. Par souci de simplicité, dans le reste de la section, nous présentons les résultats de référence agrégés pour les études d'ablation :
• Puce : nous rapportons les résultats moyens sur les tests de conception, de script, de bogues et de circuits dans le domaine à partir du tableau III (5 plans).
• MMLU : Nous rapportons les résultats globaux sur MMLU (5-shot) [22], une référence agrégée populaire sur une grande variété de sujets.
• Raisonnement : Nous rapportons des résultats moyens sur des benchmarks publics populaires sur le raisonnement de bon sens (0-shot), notamment Winogrande [53], hellaswag [54], ARC-easy [55] et RACE-High [56].
• Code : Nous rapportons le taux de réussite moyen des tests de codage avec décodage gourmand, notamment HumanEval [23], VerilogEval-Machine [12] et VerilogEval-Human [12].
Augmentation du tokenizer : nous avons expérimenté DAPT en utilisant le tokenizer LLaMA2 original et le tokenizer augmenté comme décrit dans la section III-A. La figure 11 représente la perte de formation lissée pour ChipNeMo avec le tokenizer d'origine non modifié. Par rapport à la figure 2, nous observons qu'un tokeniseur augmenté présente une perte de formation plus importante lors de l'initialisation, en raison du fait que les jetons ajoutés n'ont jamais été observés lors du pré-entraînement du modèle de base. Une perte de formation similaire est obtenue pour DAPT avec 1 époque.
Le tableau IX présente les résultats agrégés des références d’évaluation automatique. Nous notons qu'une augmentation minutieuse du tokenizer et une initialisation du poids n'ont que légèrement d'impact sur les performances du modèle sur les références académiques générales. DAPT a considérablement amélioré les références de domaine avec n'importe quel tokenizer, y compris le codage Verilog (pas de différence majeure dans HumanEval). Nous concluons que l'augmentation du tokenizer présente l'avantage d'une amélioration de l'efficacité du tokenizer et de la formation sans dégradation des capacités générales du langage et du domaine du modèle.
Mélange d'ensembles de données publics : comme introduit dans la section II-A, nous avons inclus des données publiques dans DAPT, échantillonnées à partir d'ensembles de données publics couramment utilisés pour la pré-formation du modèle de base. Nous espérions principalement que le mélange de données publiques telles que Wikipédia dans DAPT pourrait aider à « corriger » les perturbations provoquées par l'augmentation du tokenizer et améliorer les capacités générales du langage naturel.
de modèles. Nous avons effectué une autre série de DAPT avec augmentation du tokenizer en utilisant uniquement les données du domaine, entraînant le même nombre d'étapes équivalant à environ 1,1 époque des données. Nous avons constaté que la combinaison de données publiques améliore légèrement les résultats. Nous présentons les résultats détaillés dans le tableau X.
La figure 12 montre la perte de formation pour ChipNeMo-7B avec des tokenizers augmentés, y compris le mix-in d'ensembles de données publics. Nous avons observé d'importants pics de perte d'entraînement lors des étapes d'entraînement initiales, la perte d'entraînement finale pour les modèles 7B étant même meilleure que celle des hyperparamètres DAPT d'origine 13B. Cependant, nous notons une dégradation substantielle dans les tests de référence en langage naturel, comme le montre le tableau XII, y compris la conception des puces dans le domaine. Les capacités de codage se sont améliorées conformément aux résultats de [32].
Nous soulignons que notre cas diffère de celui de [32]. Bien que nous effectuions également un « pré-entraînement continu » à partir de points de contrôle pré-entraînés, nous souhaitons de préférence que le modèle maintienne des degrés élevés de performance sur les capacités générales, tout en
distiller les informations et les connaissances des ensembles de données de domaine (invisibles lors de la pré-formation du modèle) en poids du modèle. En revanche, [32] utilisent des données de code accessibles au public qui manquent principalement d'éléments de langage naturel, mettant l'accent sur leur objectif principal sur les tâches liées au codage. Nous émettons l'hypothèse qu'un taux d'apprentissage plus faible a joué un double rôle pour l'adaptation du domaine, facilitant la distillation des connaissances du domaine via DAPT tout en maintenant un équilibre qui ne s'éloigne pas trop du modèle de base, préservant ainsi les capacités générales du langage naturel tout en améliorant considérablement les performances dans -tâches de domaine
Réglage fin efficace des paramètres (PEFT) : le réglage fin efficace des paramètres gèle les poids du modèle pré-entraîné et injecte des paramètres pouvant être entraînés dans des modèles d'adaptateur plus petits pour un réglage fin efficace des tâches en aval. Nous explorons l'utilisation du PEFT dans le DAPT en utilisant l'adaptation de bas rang (LoRA) [16]. Étant donné que notre implémentation de couche de transformateur fusionne KQV en une seule projection, nous ajoutons des adaptateurs LoRA pour une seule projection de bas rang pour chaque couche d'auto-attention de manière combinée. Nous expérimentons sur les modèles LLaMA2-13B avec le tokenizer LLaMA2 d'origine, en utilisant les mêmes configurations de formation DAPT dans le tableau VI. Nous avons mené deux expériences, introduisant des paramètres supplémentaires entraînables de 26,4 millions (petits) et 211,2 millions (grands) respectivement.
La figure 13 montre les courbes de perte d'entraînement des modèles LoRA et les compare à l'entraînement complet des paramètres. Pour les deux modèles LoRA, la perte converge rapidement et cesse de diminuer au-delà d’un certain point. Le tableau XIII présente les résultats de l'évaluation des modèles LoRA. Les deux modèles LoRA sont nettement sous-performants en matière de formation complète des paramètres sur les tâches de conception de puces dans le domaine. Les modèles LoRA s'améliorent dans les tâches de conception de puces par rapport à leurs homologues non DAPT, le modèle plus grand présentant des résultats légèrement meilleurs (mais non significatifs).
La génération manuelle d'échantillons de formation demande beaucoup d'efforts, nous avons donc choisi de mettre en œuvre un processus pour les générer automatiquement. Puisque nous utilisons l'apprentissage contrastif pour affiner notre modèle, chaque échantillon nécessite un ensemble de passages positifs et de passages négatifs, en particulier des négatifs durs, pour maximiser la précision.
1) Procédure d'échantillonnage de l'ensemble de données : La figure 14 décrit les étapes suivies pour générer un échantillon :
• Étape 1 : Sélectionner aléatoirement un passage du corpus documentaire
• Étape 2 : Utiliser un modèle de langage (Vicuna) pour générer une requête valide à partir du passage.
• Étape 3 : Utiliser un modèle de récupération préexistant (transformateur de phrase) pour récupérer les N premiers passages du corpus de documents pour la requête, où chaque passage est un potentiel dur-négatif.
• Étape 4 : Il est possible que certains des passages récupérés soient en réalité positifs. Utilisez donc le même modèle de langage pour filtrer les passages positifs.
• Étape 5 : S'il n'y a pas suffisamment de passages négatifs après ce processus de filtrage, complétez avec des passages aléatoires du corpus.
Pour notre recherche initiale, nous avons utilisé Vicuna [4] et Sentence Transformer [33] ; cependant, ils peuvent facilement être remplacés respectivement par LLaMA2 [5] et BM25 [42] pour produire un modèle de récupération commercialement viable.
2) Comparaison de la qualité des hits : tous les hits ne sont pas créés égaux. Le passage de l'exemple Spec ci-dessous répond clairement et complètement à sa requête. Le passage de l'exemple Build contient la réponse ; cependant, plus de contexte est nécessaire pour répondre à la requête.
Exemple de spécification : le passage frappé répond clairement à la requête.
Exemple de construction : des informations supplémentaires sont requises pour répondre pleinement à la requête. Par exemple : Qu’est-ce qu’un DL ? Comment savons-nous qu'Arch-Build-Hotseat-XXX est un DL ?
D. Données d'évaluation supplémentaires
Le tableau XIV présente les données d'évaluation pour tous les modèles sur l'application chatbot d'assistant d'ingénierie.
Le tableau XV montre nos résultats d'évaluation pour tous les modèles sur la tâche de génération de script EDA.
Le tableau XVI montre nos résultats d'évaluation pour tous les modèles sur la tâche de résumé et d'analyse des bogues.
1) Chatbot assistant d'ingénierie :
2) Génération de script EDA : certains noms de fonctions et commandes sont obscurcis.
3) Résumé et analyse des bogues : les noms d'utilisateur, les noms de puces et les chemins sont obscurcis.
Cet article est disponible sur arxiv sous licence CC 4.0.