ChipNeMo: Domänenangepasste LLMs für Chipdesign: ChipNemo-Domänenanpassungsmethoden

Linktabelle

• Zusammenfassung und Einleitung
• Datensatz
• ChipNemo-Domänenanpassungsmethoden
• LLM-Bewerbungen
• Bewertungen
• Diskussion
• Verwandte Arbeiten
• Schlussfolgerungen
• Danksagungen, Beiträge und Referenzen
• Anhang

III. CHIPNEMO-DOMÄNENANPASSUNGSMETHODEN

ChipNeMo implementiert mehrere Domänenanpassungstechniken, um LLMs an die Chipdesigndomäne anzupassen. Diese Techniken umfassen benutzerdefinierte Tokenisierer für Chipdesigndaten, domänenadaptives Vortraining mit einem großen Korpus an Domänendaten, überwachtes Feintuning mit domänenspezifischen Aufgaben und abgefragte erweiterte Generierung mit einem fein abgestimmten Abrufmodell. Wir werden die Details jeder Technik in diesem Abschnitt erläutern.

Ein Tokenisierer

Bei der Anpassung eines vorab trainierten Tokenizers bestehen die Hauptziele darin, die Tokenisierungseffizienz bei domänenspezifischen Daten zu verbessern, die Effizienz und Leistung des Sprachmodells bei allgemeinen Datensätzen aufrechtzuerhalten und den Aufwand für erneutes Training/Feintuning zu minimieren. Um dies zu erreichen, haben wir einen vierstufigen Ansatz entwickelt:

• Schritt 1: Trainieren eines Tokenizers von Grund auf mit domänenspezifischen Daten.

• Schritt 2: Identifizieren Sie aus dem Vokabular des neuen Tokenizers Token, die im allgemeinen Tokenizer fehlen und in allgemeinen Datensätzen selten vorkommen.

• Schritt 3: Erweitern des Allzweck-Tokenizers mit den in Schritt 2 neu identifizierten Token.

• Schritt 4: Initialisieren der Einbettungen der neuen Token durch Verwendung des Allzweck-Tokenizers.

Konkret wird bei Schritt 4 ein neues Token mit dem vorab trainierten Allzweck-Tokenizer tokenisiert. Die Einbettung des neuen Tokens wird durch Mittelung der Einbettungen der vom Allzweck-Tokenizer generierten Token [24] bestimmt und die Gewichte der Ausgabeschicht werden auf Null initialisiert.

Schritt 2 hilft, die Leistung des vorab trainierten LLM bei allgemeinen Datensätzen aufrechtzuerhalten, indem selektiv neue Token eingeführt werden, die in allgemeinen Datensätzen selten vorkommen. Und Schritt 4 reduziert den Aufwand für das erneute Trainieren/Feintuning des LLM durch Initialisierung der Einbettungen neuer Token, die vom allgemeinen Tokenisierer gesteuert werden.

B. Domänenadaptives Vortraining

In unserer Studie wenden wir DAPT auf vorab trainierte Basismodelle LLaMA2 7B/13B an. Jedes DAPT-Modell wird mit den Gewichten der entsprechenden vorab trainierten Basismodelle initialisiert. Wir nennen unsere DAPT-Modelle ChipNeMo . Wir verwenden die Tokenizer-Augmentation wie in Abschnitt III-A dargestellt und initialisieren das Einbettungsgewicht entsprechend [24]. Wir führen weiteres Vortraining mit domänenspezifischen Daten durch, indem wir das Standardziel der autoregressiven Sprachmodellierung verwenden. Alle Modelltrainingsverfahren werden mit dem NVIDIA NeMo-Framework [25] durchgeführt und integrieren Techniken wie Tensorparallelität [26] und Flash Attention [27] zur Verbesserung der Effizienz.

Abbildung 2 veranschaulicht den Trainingsverlust von ChipNeMo unter den angegebenen Hyperparametern. Wir beobachten tatsächlich Spitzen im Trainingsverlust. Im Gegensatz zur Hypothese in [28] postulieren wir, dass diese Spitzen in unserem Szenario auf „schlechte Daten“ zurückzuführen sind, da diese Unregelmäßigkeiten in ähnlichen Trainingsschritten für dasselbe Modell, sogar über verschiedene Modellgrößen hinweg, immer wieder aufzutreten scheinen. Wir haben uns entschieden, dieses Problem nicht zu behandeln, da diese Anomalien nachfolgende Trainingsschritte nicht wesentlich zu beeinträchtigen schienen (ohne merkliche Verschlechterung des Validierungsverlusts), möglicherweise aufgrund unserer Anwendung einer niedrigen Lernrate.

C. Überwachte Feinabstimmung

Nach DAPT führen wir eine Modellausrichtung mit überwachter Feinabstimmung (SFT) durch. Wir übernehmen für alle Modelle die gleiche Hyperparameter-Trainingskonfiguration wie DAPT, mit Ausnahme der Verwendung einer reduzierten globalen Batchgröße von 128. Alle SFT-Daten sind gemäß der folgenden Chat-Vorlage strukturiert:

<extra_id_0>System\n{System}

<extra_id_1>Benutzer\n{user_utterance}

<extra_id_1>Assistent\n{chipnemo_response}

…

Wir verfolgen ein autoregressives Optimierungsziel und implementieren eine Strategie, bei der Verluste, die mit Token verbunden sind, die vom System und von Benutzeraufforderungen stammen, maskiert werden [5]. Dieser Ansatz stellt sicher, dass unser Fokus bei der Backpropagation ausschließlich auf der Optimierung von Antwort-Tokens liegt.

Wir kombinieren unseren Domänen-SFT-Datensatz, der aus ungefähr 1,1.000 Beispielen besteht, mit dem umfangreicheren allgemeinen Chat-SFT-Datensatz mit 128.000 Beispielen. Anschließend haben wir uns mit der Feinabstimmung für eine einzelne Epoche befasst, nachdem wir eine zufällige Mischung auf die Daten angewendet hatten. Wir haben Experimente durchgeführt, bei denen der domänenspezifische SFT-Datensatz für mehr als eine Epoche erweitert wurde. Es wurde jedoch deutlich, dass das Modell bei domäneninternen Fragen schnell Anzeichen von Überanpassung zeigte und häufig irrelevante Antworten aus dem Domänen-SFT-Datensatz wiederholte.

Zusätzlich haben wir eine zusätzliche SFT durchgeführt, bei der wir ausschließlich den allgemeinen Chat-Datensatz verwendet und alle domänenspezifischen SFT-Daten ausgeschlossen haben. Der Übersichtlichkeit halber benennen wir alle unsere ChipNeMo-Modelle wie folgt:

1. ChipNeMo-Chat: Modelle, die sowohl mit Domänen- als auch mit allgemeinen Chat-Daten optimiert sind;

   
   

2. ChipNeMo-Chat (noDSFT): Modelle, die ausschließlich mit allgemeinen Chat-Daten feinabgestimmt sind.

Wir haben DAPT auch direkt an einem Chat-orientierten Modell wie dem LLaMA2-Chat-Modell ausprobiert. Wir haben festgestellt, dass DAPT die Ausrichtung des Modells erheblich verschlechterte, wodurch das resultierende Modell für nachgelagerte Aufgaben unbrauchbar wurde.

D. Retrieval-erweiterte Generierung

Es ist bekannt, dass LLMs ungenaue Texte generieren können, sogenannte Halluzinationen [29]. Obwohl das Phänomen noch nicht vollständig verstanden ist, müssen wir Halluzinationen dennoch eindämmen, da sie im Kontext eines Chatbots für technische Assistenten, wo Genauigkeit von entscheidender Bedeutung ist, besonders problematisch sind. Unser Vorschlag ist, die Methode der Retrieval Augmented Generation (RAG) zu nutzen. RAG versucht, relevante Passagen aus einer Datenbank abzurufen, die zusammen mit der Frage in die Eingabeaufforderung aufgenommen werden, was das LLM dazu veranlasst, genauere Antworten zu geben. Wir stellen fest, dass die Verwendung eines domänenangepassten Sprachmodells für RAG die Antwortqualität auf unsere domänenspezifischen Fragen erheblich verbessert. Außerdem stellen wir fest, dass die Feinabstimmung eines handelsüblichen, unbeaufsichtigten, vorab trainierten dichten Retrievalmodells mit einer bescheidenen Menge domänenspezifischer Trainingsdaten die Abrufgenauigkeit erheblich verbessert. Unser domänenangepasstes RAG-Implementierungsdiagramm ist in Abbildung 3 dargestellt.

Wir haben unser domänenangepasstes Retrievalmodell erstellt, indem wir das e5_small_unsupervised -Modell [30] mit 3000 domänenspezifischen, automatisch generierten Beispielen unter Verwendung des Tevatron-Frameworks [31] feinabgestimmt haben. Die Beispielgenerierung und der Trainingsprozess werden in Anhang C behandelt.

Trotz der erheblichen Vorteile, die sich durch die Feinabstimmung eines Abfragemodells ergeben, hat die Abfrage immer noch Probleme mit Abfragen, die nicht direkt auf Passagen im Dokumentkorpus verweisen oder mehr Kontext erfordern, der in der Passage nicht vorhanden ist. Leider sind diese Abfragen auch repräsentativer für Abfragen, die von Ingenieuren in realen Situationen gestellt werden. Die Kombination der Abfrage mit einem domänenangepassten Sprachmodell ist eine Möglichkeit, dieses Problem zu lösen.