Was ist der Domainlifecycles Code Generator (DCG)?

Der Domainlifecycles Code Generator (DCG) ist ein generatives KI-Assistenzsystem zur Erstellung maßgeschneiderter Software mit dem von esentri entwickelten Domainlifecycles Framework für Domain-Driven Design (DDD). Der DCG entstand im Rahmen einer Masterarbeit und stellt den ersten Prototypen eines „Domainlifecycles-GPT“-ähnlichen Assistenzsystems dar. Er basiert auf einem fine-tuned CodeLlama-Modell, das in der Lage ist, syntaktisch korrekte JSON-Objekte in der Domainlifecycles Domain-Specific Language (DSL) zu generieren. Diese Fähigkeit ermöglicht den Einsatz des Prototyps in Pipelines und anderen komplexen Maschine-zu-Maschine-Systemen, wie einer Model Agency.

Was ist der Beitrag des DCG zur Nachhaltigkeit?

Der DCG zeigt eindrucksvoll, dass erfolgreiche Prototypen mit minimalem Ressourceneinsatz realisiert werden können. Für die Entwicklung des DCG wurde ein CodeLlama-Modell lokal auf einer Nvidia GTX 2080 mit 11 GB VRAM finetuned. Dies wurde durch 4-Bit-Quantisierung und den Einsatz von Low Rank Adaptation (LoRA) ermöglicht. Die Entwicklung solcher ressourcenschonenden Technologien und Prozesse ist entscheidend für die Nachhaltigkeit und trägt dazu bei, den CO₂-Ausstoß für zukünftige Projekte und Prototypen deutlich zu verringern.

💡 Was ist Low Rank Adaptation (LoRA)?

Low Rank Adaptation (LoRA) ist eine Technik zur Optimierung und Feinabstimmung von großen Sprachmodellen, die es ermöglicht, diese Modelle effizienter und ressourcenschonender zu trainieren. Anstatt das gesamte Modell anzupassen, konzentriert sich LoRA darauf, nur bestimmte Teile des Modells zu optimieren. Dadurch wird der Trainingsprozess beschleunigt und der Ressourcenverbrauch deutlich reduziert, ohne dass die Leistungsfähigkeit des Modells beeinträchtigt wird. Diese Methode ist besonders nützlich, um leistungsstarke KI-Anwendungen auf handelsüblicher Hardware zu entwickeln.

💡 Was ist 4-Bit Modell-Quantisierung?

Die 4-Bit Modell-Quantisierung ist eine Technik, die große KI-Modelle effizienter macht, indem sie die Präzision der Modellparameter reduziert. Normalerweise verwenden Modelle 16- oder 32-Bit-Werte, aber bei der 4-Bit-Quantisierung werden diese auf 4-Bit-Werte vereinfacht. Das bedeutet, dass weniger Speicherplatz und Rechenleistung benötigt werden, wodurch das Modell schneller und ressourcenschonender arbeitet. Diese Methode ermöglicht es, komplexe KI-Modelle auf kostengünstiger und weniger leistungsstarker Hardware auszuführen, ohne die Genauigkeit der Ergebnisse wesentlich zu beeinträchtigen.

Vorgehensweise bei der Entwicklung des DCG:

Datengrundlage und Zielsetzung

Für die Entwicklung des DCG wurden zwei große Datenquellen genutzt: Test-Daten des Domainlifecycles Frameworks (20% des gesamten Datensatzes) und Projektdaten aus einem Kundenprojekt (80% des gesamten Datensatzes). Das langfristige Ziel für ein „Domainlifecycles-GPT“ ist es, ein Assistenzsystem zu schaffen, das aus Business-Anforderungen und Fachwissen gemeinsam mit dem Ingenieur ein Metamodell in der DSL des Domainlifecycles Frameworks erstellt. Dieses Metamodell soll die Prozesse und Funktionen der Software abbilden. Da in den vorhandenen Daten das Know-how und die Business-Anforderungen fehlen, dient der DCG zunächst als Prototyp. Das Hauptziel ist es, die DSL des Domainlifecycles Frameworks zu erlernen und syntaktisch korrekte JSON-Objekte zu erstellen.

Die Grafik zeigt ein Diagramm über die Datengrundlage und Zielsetzung. Für die Entwicklung des DCG wurden zwei große Datenquellen genutzt: Test-Daten des Domainlifecycles Frameworks und Projektdaten aus einem Kundenprojekt.

Daten Vorverarbeitung

Die Datenvorverarbeitung ist ein entscheidender Schritt bei der Entwicklung generativer KI-Lösungen, da sie sicherstellt, dass die Daten in einer geeigneten Form vorliegen, um das Modell effektiv zu trainieren. Im Fall des DCG war es notwendig, aufgrund eines starken Daten-Bias (80 % der Daten stammen aus einem Kundenprojekt) und dem Schutz sensibler Kundendaten eine Daten-Abstraktion durchzuführen. Diese Abstraktion ermöglicht es, mit einem vergleichsweise kleinen Datensatz das Fine-Tuning erfolgreich umzusetzen. Die spezifische Pipeline für die Datenvorverarbeitung wurde für den DCG implementiert und trägt dazu bei, die Qualität und Relevanz der Daten für das Training zu optimieren.

In der Datenvorverarbeitung folgen wir mehreren wichtigen Schritten, um sicherzustellen, dass unsere Daten optimal für das Modelltraining vorbereitet sind.

1
2
3
4
5
6
Die Darstellung zeigt die Datenvorverarbeitung bei der Entwicklung generativer KI-Lösungen.
1

0. Data Import

Zunächst erfolgt der Data Import, bei dem die Daten in die Pipeline eingelesen werden.

2

1. Data Cleaning

Im Data Cleaning-Schritt reinigen wir die Daten, indem wir sensible Informationen anonymisieren und ausgewählte Keys durch Variablen ersetzen. Diese Variablen müssen später vom Anwender oder einem anderen Modell in der Model Agency interpretiert werden.

3

2. Data Chunking

Um die Hardware-Ressourcen optimal zu nutzen, teilen wir die JSON-Objekte im Data Chunking-Schritt in kleinere Segmente mit einer Länge von 2048 Tokens auf. Dabei fügen wir Start- und End-Tokens hinzu, um die Struktur der Daten nicht zu verlieren.

4

3. Chunk-Shuffling

Danach wird der Datensatz im Chunk-Shuffling-Schritt gemischt, um eine gleichmäßige Verteilung der Chunks in Trainings-, Evaluations- und Testdaten zu gewährleisten.

5

4. Data Splits

Im Data Splits-Schritt teilen wir den gesamten Datensatz auf, wobei 20% für den Test und 80% für das Training, wovon 20% für die Evaluation reserviert werden.

6

5. Model Training

Mit diesen vorbereiteten Datensätzen können wir dann mit dem Model Training beginnen.

Modelltraining des DCG

Das Ziel des Modelltrainings des Domainlifecycles Code Generators (DCG) ist es, dem Modell den spezifischen Dialekt der Domainlifecycles DSL beizubringen, sodass es in der Lage ist, syntaktisch korrekte JSON-Objekte durch Next-Token-Generierung zu erstellen. Hierfür wurde ein offenes Sprachmodell (LLM) ausgewählt, das bereits das JSON-Format in seinen Trainingsdaten enthalten hatte und lokal gehostet sowie kommerziell nutzbar ist. Das CodeLlama-Modell von Meta in der 7B-Variante erfüllt all diese Anforderungen. Um die Größe des Modells von 25 GB auf 4 GB zu reduzieren, wurde eine 4-Bit-Quantisierung angewendet, gefolgt von einer Feinabstimmung mit Low Rank Adaptation (LoRA). Dadurch wurde das Modell effizienter und konnte erfolgreich auf consumer Hardware eingesetzt werden.

Hyperparameter Tuning

Jedes Modelltraining umfasst sogenannte Hyperparameter, die entscheidend für die Ergebnisse sind, wie etwa die Lernrate. Für das Training des DCG wurden fünf Hyperparameter definiert, die eine Mischung aus LoRA-Parametern und allgemeinen Trainingsparametern darstellen. Das Ziel des Hyperparameter-Tunings ist es, durch intelligentes Ausprobieren verschiedener Kombinationen die besten Ergebnisse zu erzielen und die optimalen Hyperparameter für das Training zu finden. Dieser Prozess dauerte insgesamt 27 Tage, in denen 135 verschiedene Kombinationen getestet wurden. Die folgenden Abbildungen zeigen die Ergebnisse dieses Hyperparameter Tuning-Prozesses.

Die ROUGE-Werte lagen jedoch nicht innerhalb des erwarteten Bereichs. Dies kann darauf zurückzuführen sein, dass die Metrik nicht korrekt berechnet wurde oder nicht für den gegebenen Ansatz geeignet ist.

Darstellung der Wichtigkeit der Hyperparameter ermittelt mit einem Random Forrest Regressor. Die Grafik zeigt, dass – bezogen auf die Zielgröße Loss – die Hyperparameter num_train_epochs und learning_rate besonders wichtig sind.

Die Grafik zeigt ein Diagramm, das Parameter Importance für Multiple Objectives darstellt.

Erreichte Evaluationswerte für den Loss und den BLEU über die 135 verschiedenen Hyperparameter Kombinationen aus dem Hyperparameter Tuning. Nach den ersten 100 Versuchen wurde eine Anpassung der Suchräume für die möglichen Parameter vorgenommen, was die Verbesserungen der Werte nach dem 100. Versuch erklärt.

Das Bild zeigt eine Grafik, die Inverse Loss and BLEU per Optuna Trail darstellt.

Modell Assessment

Um zu beurteilen, wie gut das letzte Training mit den optimierten Hyperparametern war, reichen Evaluationsmetriken allein nicht aus. Es ist auch wichtig, die syntaktische Korrektheit der erzeugten JSON-Objekte zu überprüfen und diese im Detail zu betrachten, um die Eignung des Modells für den Einsatz in einer Pipeline sicherzustellen. Daher wurde ein dreistufiges Modell-Assessment durchgeführt. In diesem Prozess wurden die Evaluationsmetriken analysiert, die syntaktische Korrektheit der JSON-Objekte geprüft und eine qualitative Analyse der erstellten JSON-Objekte durchgeführt. Dies ermöglicht eine umfassende Bewertung der Modellleistung.

1. Stufe: Evaluationsmetriken

In der ersten Stufe des Modell-Assessments wurden die Evaluationsmetriken des Modells ausgewertet, insbesondere der Loss und der BLEU-Score auf den Evaluations- und Test-Datensätzen. Der Loss misst, wie gut das Modell die Trainingsdaten nachbildet, wobei ein niedrigerer Wert besser ist. Der BLEU-Score bewertet die Genauigkeit der vom Modell erzeugten Texte, wobei ein höherer Wert besser ist. Für das DCG-Training ergaben sich folgende Werte: Der Loss betrug 0.0393 auf den Evaluationsdaten und 0.0309 auf den Testdaten. Der BLEU-Score erreichte 0.9924 auf den Evaluationsdaten und 0.9918 auf den Testdaten. Diese Metriken zeigten, dass das Modell sehr präzise und effizient arbeitete und dass kein Overfitting vorliegt.

  • Loss ↓ (Evaluation Data)
  • 0.0393
  • Loss ↓ (Test Data)
  • 0.0309
  • BLEU ↑ (Evaluation Data)
  • 0.9924
  • BLEU ↑ (Test Data)
  • 0.9918

2. Stufe: Parsibility

Um die syntaktische Korrektheit der generierten Samples zu prüfen, wurden 100 JSON-Objekte aus 20 verschiedenen Prompts erzeugt. Diese Prompts teilten sich in 10 „klare“ und 10 „experimentelle“ Prompts auf. Jedes Sample wurde exakt 4000 Tokens lang generiert und anschließend mit einem Skript geschlossen, da 4000 Tokens die maximale Länge sind, die auf der GTX 2080 generiert werden können. Da die meisten JSON-Objekte nach 4000 Tokens noch nicht abgeschlossen waren, mussten sie manuell geschlossen werden. Nach diesem Prozess konnten 81 von 100 der generierten Samples fehlerfrei geparst werden und waren somit syntaktisch korrekt. Bei den „klaren“ Prompts waren sogar alle 50 generierten Samples korrekt, was die hohe Zuverlässigkeit des DCG unter diesen Bedingungen zeigt.

3. Stufe: Qualitative Analyse

In der dritten Stufe des Modell-Assessments wurde eine qualitative Analyse der generierten JSON-Objekte durchgeführt. Dabei wurden verschiedene Fehler und Beispielsamples detailliert untersucht. Einige Fehler führten zu Problemen beim Parsen der JSON-Objekte, wie das Auftreten von breitenlosen Leerzeichen (Unicode U+200B Zeichen). Bei experimentellen Prompts starteten die Samples manchmal mitten in JSON-Objekten oder sogar in der Mitte von Keys und Values. Dennoch waren die von den „klaren“ Prompts erstellten Samples überwiegend überzeugend in ihrer Qualität und Sinnhaftigkeit. Diese Analyse half, die Stärken und Schwächen des Modells besser zu verstehen und gezielte Verbesserungen vorzunehmen.

DCG Demo App – ein kleines Erklärvideo:

Um den DCG zu testen und seinen potenziellen Einsatz zu demonstrieren, wurde eine Server-Client-App entwickelt, die die Funktionalitäten des DCG darstellt und nutzbar macht. Der Code zur App ist öffentlich auf GitHub verfügbar: DCG-DemoApp. Mit der App können Benutzer dem Modell verschiedene Prompts geben und die generierten Antworten erhalten. Zudem lässt sich ein Post-Processing deaktivieren, wodurch die Rohdaten des Modells sichtbar werden und die generierten JSON-Objekte nachbearbeitet werden, um deren Verarbeitbarkeit zu verbessern.

Ressources und weitere Informationen:

Weitere Informationen:

DomainlifecyclesCodeGenerator Projekt

DCG-DemoApp: Dieses Repository enthält eine einfache PyQT-Anwendung mit einem Server, um das fein abgestimmte Donainlifecycles Code Generator (DCG)-Modell auszuführen und die Codegenerierung zu demonstrieren.

Literatur:

[DDD]: Eric Evans 2004: “Domain-Driven Design: Tackling Complexity in the Heart of Software”

[DSL]: Martin Fowler 2010: “Domain-specific languages”

[CodeLLama]: Rozière et al. 2023: “Code Llama: Open Foundation Models for Code“ ( )

[MODEL-AGENCY]: Wang et al. 2024: “Mixture-of-Agents Enhances Large Language Model Capabilities” ( )

[LORA]: Hu et al. 2021: “LoRA: Low-Rank Adaptation of Large Language Models“ ( )

[QUANTISIERUNG]: Belkada et al. 2023: “Making LLMs even more accessible with bitsandbytes, 4-bit quantization and QLoRA“ ( )

[BLEU]: Papineni et al. 2002: “Bleu: a Method for Automatic Evaluation of Machine Translation“ ( )

[WikipediaBL]:

Diese Themen könnten Dich auch interessieren

Schmuckbild zum Thema Chatbot Assistenten durch Nutzung von LLMs und Retrieval Augmented Generation

Chatbot Assistenten durch Nutzung von LLMs und Retrieval Augmented Generation

Wir erläutern die Architektur eines Chatbots, der durch die Nutzung von LLMs und Retrieval Augmented Generation schnell und effizient auf Fragen antwortet.
Eine Person analysiert eine Datenauswertung auf dem Bildschirm eines MacBooks.

Revolution in Real-time Analytics: Wie Tiered Storage Dateneffizienz transformiert

Wir zeigen Dir, welche Auswirkungen Speicherstrategien in Bezug auf Real-time Analytics haben.
Das Bild zeigt eine Person, die auf einem Bildschirm auf eine Datenauswertung zeigt. An einem Tisch sitzen fünf Personen, die der Auswertung zuhören.

CoffAI – Welche Architektur bietet wie viel Echtzeit?

Wir erläutern, wie Vibrationsdaten mittels Sensoren, Machine Learning und einer Cloud-Infrastruktur verarbeitet, klassifiziert und visualisiert werden.

Nimm gerne Kontakt zu uns auf!

Hast Du Fragen zu unseren Ideen, Konzepten oder Abschlussarbeiten? Dann freue ich mich immer über den Austausch mit Dir!

Sende mir gerne eine Mail, vernetze Dich mit mir oder hinterlasse Deine Kontaktdaten.

Filip Stępniak
Senior Data Consultant