Einführung
Im Oktober 2024 begann ich mein Bachelor-Studium in Data Science und Künstlicher Intelligenz. Als Teil unserer anfänglichen Kursarbeit wurden wir Studenten beauftragt, ein Machine Learning- oder KI-Projekt zu entwickeln, um praktische Erfahrung in diesem Bereich zu sammeln.
Da ich zuvor viel über die Architektur und Funktionsweise von Transformern und Large Language Models (LLMs) gelesen hatte, entwickelte ich ein starkes Interesse an diesem Bereich. Dies führte mich dazu, mein Projekt auf das Fine-Tuning eines solchen LLMs zu fokussieren. Spezifisch kam mir die Idee zur Entwicklung eines Übersetzungssystems zwischen Standarddeutsch und schwäbischem Dialekt.
Bei der Auswahl einer Modellarchitektur erwog ich spezialisierte Übersetzungsmodelle wie T5. Angesichts meines Interesses, LLM-Fine-Tuning-Techniken zu erkunden, entschied ich mich jedoch für das LLAMA 3.1 8B Modell, trotz seiner potenziellen Limitierungen für Übersetzungsaufgaben. Diese Entscheidung stimmte mit meinen Lernzielen überein, auch wenn spezialisierte Übersetzungsmodelle möglicherweise eine überlegene Leistung erzielen könnten.
Datenaufbereitung
Bevor ich mit dem eigentlichen Fine-Tuning-Prozess beginnen konnte, musste ich einen geeigneten Datensatz finden. Glücklicherweise entdeckte ich schwaebisch-schwaetza.de, eine Website, die ein umfassendes Wörterbuch mit über 12.000 Übersetzungen von Standarddeutsch zum schwäbischen Dialekt hostet. Auf Nachfrage erklärte sich der Administrator dieser Website glücklicherweise bereit, mir diese Daten für das Projekt bereitzustellen. Der Datensatz präsentierte jedoch zwei Hauptherausforderungen: Er war unstrukturiert und es fehlte an kontextuellen Informationen um die Wortpaare herum. Kontext ist jedoch entscheidend, damit das LLM dialektale Muster effektiv lernen kann.
Entwicklung des Datensatzes (Beispiel)
- Ursprünglicher Datensatz:
- Schwäbisch: A blaus Mol
- Standarddeutsch: Bluterguss
Um Kontext hinzuzufügen, kam ich schließlich auf die Idee, ein State-of-the-Art LLM zu nutzen, um synthetischen Kontext um die ursprünglichen Wörter zu erstellen. Also nutzte ich die Claude-API und XAIs Grok-API, die ich per Prompt dazu brachte, natürliche Sätze um jedes Wortpaar zu generieren:
- Nach der Kontexterweiterung:
- Schwäbisch: Du hosch ja a blaus Mol am Arm! Wa isch denn do bassiert?
- Standarddeutsch: Du hast ja einen schlimmen Bluterguss am Arm! Was ist denn da passiert?
Dies verbesserte die Datenqualität signifikant, obwohl einige Übersetzungen nicht perfekt waren. Anschließend lud ich diesen erweiterten Datensatz auf Hugging Face hoch, kann ihn aber leider aufgrund meiner Vereinbarung mit dem Website-Besitzer nicht öffentlich teilen.
SFT-Fine-Tuning
Nun war ich endlich bereit, um mit dem eigentlichen Finetuning zu starten. Dazu beschloss ich zuerst, den Fine-Tuning-Prozess in zwei Phasen aufzuteilen: SFT (Supervised Fine-Tuning) und DPO (Direct Preference Optimization). Bevor ich jedoch näher in diese Methoden eintauche, lass mich das Kernkonzept von QLoRA erklären, welches effizientes Fine-Tuning erst möglich macht.
Kernkonzepte: LoRA & QLoRA
- LoRA (Low-Rank Adaptation): Traditionell erfordert das Fine-Tuning eines LLMs die Aktualisierung aller Parameter im Modell basierend auf den neuen Daten, was signifikante Rechenressourcen verlangt. Die LoRA-Technik verfolgt einen etwas anderen Ansatz: Anstatt alle Parameter zu aktualisieren, friert sie diese ein und fügt eine kleine Anzahl trainierbarer Parameter zusätzlich zu den bestehenden hinzu. Diese innovative Methode macht Fine-Tuning hocheffizient und ermöglicht das Training auf einer einzelnen Grafikkarte.
- Das „Q“ (Quantisierung): Dies bezieht sich auf die Reduzierung der Präzision von Modellgewichten. Standard-Modellgewichte werden typischerweise als 32-Bit-Gleitkommazahlen gespeichert, aber wir können diese Präzision auf verschiedene Level reduzieren: 16-Bit, 8-Bit, 4-Bit oder sogar experimentelle 1-Bit-Darstellungen. Während die Reduzierung der Präzision die Modelleffektivität leicht beeinträchtigen kann, verringert sie dramatisch die benötigten Rechenressourcen sowohl für das Training als auch für die Inferenz.
SFT-Implementierung
Für die SFT-Phase erweiterte ich den zuvor erstellten Datensatz, indem ich spezifische Prompts zu jedem Datenpunkt hinzufügte. Diese Prompts beinhalteten Anweisungen wie:
„übersetze den folgenden Satz ins Standarddeutsche: {Schwäbischer Satz}“ (oder umgekehrt für die entgegengesetzte Richtung).
Ich implementierte das Training mit UnslothAIs Notebook für LLAMA 3.1 8B. UnslothAI ist ein Framework, das diese Fine-Tuning-Techniken effizient implementiert und den Trainingsprozess deutlich vereinfacht. Es ist einfach zu verwenden und integriert sich perfekt mit Hugging Face. Das Training wurde auf Google Colab für 2 Epochen durchgeführt, was zu einem zufriedenstellenden Loss-Wert von ungefähr 0,8 führte, was für diese Übersetzungsaufgabe angemessen ist.
DPO-Fine-Tuning
Vielleicht bist du auch schon einmal auf ChatGPTs Feedback-Interface gestoßen, was sich auf die zweite Stufe des Fine-Tunings bezieht. Traditionell nutzte diese Stufe RLHF (Reinforcement Learning from Human Feedback), wo Modelle lernen, indem sie Paare von Ausgaben vergleichen, um zu bestimmen, welche besser ist. DPO (Direct Preference Optimization) folgt einem ähnlichen Prinzip des Lernens aus menschlichen Präferenzen.
DPO-Fine-Tuning erfordert einen Präferenz-Datensatz, der drei Schlüsselspalten enthält: Prompt, Chosen (ausgewählt) und Rejected (abgelehnt). Um diesen Datensatz effizient zu erstellen, wählte ich 300 Beispiele aus meinem initialen Datensatz aus und generierte zwei Modellantworten für jeden Prompt, die ich in einer CSV-Datei speicherte.
Ich evaluierte dann manuell die Paare von Ausgaben, wählte die bessere Antwort für die „Chosen"-Spalte aus und platzierte die Alternative in der „Rejected"-Spalte. Während dieser manuelle Evaluierungsprozess mühsam war, war er notwendig, um Qualität sicherzustellen. Alternative Ansätze wie Community-Voting könnten funktionieren, wären aber ebenfalls zeitaufwendig.
DPO-Datensatz-Beispiel
- Prompt: „Übersetze ins Hochdeutsche: A blaus Mol“
- Chosen: „Bluterguss“
- Rejected: „Ein blauer Fleck“
Anschließend lud ich den kuratierten Präferenz-Datensatz erneut auf Hugging Face hoch. Glücklicherweise bietet UnslothAI ebenfalls ein Colab-Notebook an, welches speziell für DPO-Fine-Tuning entwickelt wurde, was es mir erlaubte, Konsistenz in meinem Entwicklungs-Framework zu bewahren. Ich führte das Training für 3 Epochen durch und veröffentlichte das resultierende Modell auf Hugging Face.
Evaluierung und Fazit
Anstatt wie üblich formale Benchmarks zu implementieren, evaluierte ich das Modell ausschließlich durch praktisches Testen, dazu führte ich verschiedene Übersetzungsversuche durch. Während das Modell meist die korrekten Übersetzungen produzierte, war es nicht konsistent mit der Präzision der Übersetzung. Einige Übersetzungsfehler können auf Qualitätsprobleme des Datensatzes zurückgeführt werden, insbesondere bei den von Claude und Grok generierten Beispielen, die gelegentlich ungenaue oder irreführende Übersetzungen enthielten.
Praxis-Beispiel (Schwäbisches Lied)
"Oinr isch immer der Arsch, und er woiß id mol warum."
- Übersetzung 1: „Einer ist immer der Arsch, und er weiß nicht mal warum.“ 👉 Fazit: Dies ist eine exzellente Übersetzung, die die Bedeutung perfekt einfängt.
- Übersetzung 2: „Ein Mann ist immer der Arsch, und er weiß nicht mal warum.“
👉 Fazit: Diese Übersetzung ist weniger akkurat, da sie "Oinr" spezifisch als „Ein Mann“ interpretiert statt des allgemeineren „Einer“ (jemand).
Eine tiefergreifende, fundamentale Herausforderung liegt in der Natur des schwäbischen Dialekts selbst. Als eine primär gesprochene Sprache ohne standardisierte Rechtschreibung oder Verwendung variiert Schwäbisch signifikant über verschiedene Regionen hinweg. Selbst als lebenslanger Bewohner eines schwäbischsprachigen Gebiets in Deutschland begegnete ich unbekannten Ausdrücken beim Durchsehen des Datensatzes. Diese regionale Variation macht die Erstellung eines umfassenden, "optimalen" Datensatzes besonders herausfordernd.
Potenzielle zukünftige Verbesserungen:
- Spezialisiertes Basismodell: Die Verwendung eines spezialisierten Übersetzungsmodells als Basismodell könnte bessere Ergebnisse liefern.
- Audio-Fähigkeiten: Einbindung von Audio-Fähigkeiten könnte die Leistung signifikant verbessern, obwohl die Beschaffung geeigneter Audio-Datensätze ihre eigenen Herausforderungen präsentiert.
- RAG-Pipeline: Implementierung einer RAG (Retrieval-Augmented Generation) Pipeline, bei der Übersetzungen aus dem Datensatz in einer Vektordatenbank gespeichert würden. Das System könnte dann relevante Übersetzungen abrufen und sie in den Prompt einbauen, bevor es Antworten generiert.
- Agenten-Systeme: Entwicklung eines Agenten-Systems, das zur Selbstüberprüfung und -verbesserung fähig ist. Ein solches System könnte autonom Webressourcen oder Datenbanken nach korrekten Übersetzungen durchsuchen, wenn es auf unbekannte Begriffe stößt.
Dieser Ansatz repräsentiert einen aufregenden Bereich für zukünftige Erkundung und Entwicklung.
Ressourcen & Code
Der Code für dieses Projekt, einschließlich der Fine-Tuning-Notebooks und Modellkonfigurationen, ist in meinem GitHub-Repository verfügbar: SwabianGPT.
Hinweis: Während du den Code als Referenz oder Inspiration für ähnliche Projekte nutzen kannst, beachte bitte, dass die exakte Reproduktion der Ergebnisse nicht möglich sein wird, da der Trainingsdatensatz aufgrund von Lizenzvereinbarungen nicht geteilt werden kann.
Das Repository beinhaltet:
- Datenaufbereitungsskripte
- Fine-Tuning-Notebooks für sowohl SFT als auch DPO
- Modellkonfigurationen und Hyperparameter
- Beispiel-Inferenz-Code
Abschließende Worte
Ich hoffe, dir hat der Artikel gefallen.
Wenn du Fragen oder Anmerkungen hast, kontaktiere mich gerne.
Mario 💚