Ein eigenes LLM? Na klar!

Die Frage nach dem eigenen KI-Modell kommt regelmäßig, weil viele Unternehmen sich fragen, ob sie ihre Daten wirklich externen Anbietern anvertrauen wollen. Kann man ein eigenes Modell trainieren? Ja, technisch schon. Sollte man es tun? In den meisten Fällen: Eher nicht. Und dennoch möchte ich jede:n dazu anregen, es dennoch mal selbst zu machen.

Die drei Wege zum eigenen KI-Wissen

Wenn Du Dein Fachwissen in ein KI-System integrieren möchtest, stehen Dir grundsätzlich drei Wege offen. Jeder hat seine Berechtigung, aber sie unterscheiden sich erheblich in Aufwand, Kosten und Ergebnis. Um die Unterschiede greifbar zu machen, stell Dir vor, Du hast 1.000 Fachtexte zu einem Thema. Was passiert bei den drei Ansätzen?

• RAG (Retrieval-Augmented Generation): Die Texte werden indexiert und in einer Vektordatenbank gespeichert. Bei einer Frage findet das System die relevanten Passagen und gibt sie dem Modell als Kontext mit. Das Modell formuliert Antworten basierend auf dem gelieferten Kontext. Die Qualität hängt davon ab, ob das Retrieval die richtigen Dokumente findet.

• Fine-Tuning: Das Modell wird mit Deinen Texten weitertrainiert und lernt dabei Deinen Stil, Deine Terminologie und typische Antwortmuster. Es reproduziert diese Muster konsistent, ohne dass Beispiele im Prompt mitgeliefert werden müssen. Das verbessert primär Stil und Format, nicht automatisch faktische Korrektheit.

• Training from Scratch: Du baust ein Modell ausschließlich mit Deinen eigenen Daten, ohne Vorwissen aus dem Internet. Es lernt die Muster Deiner Fachtexte, hat aber kein robustes Allgemeinwissen. Es kann primär reproduzieren und rekombinieren, was in den Trainingsdaten vorkommt, und versucht jede Frage in diesen Rahmen zu pressen.

Warum macht Training from Scratch trotzdem Sinn?

Um zu verstehen, was in einem Sprachmodell wirklich passiert. Die meisten Menschen haben eine vage Vorstellung davon, wie ChatGPT oder Claude funktionieren, aber die Details bleiben oft im Nebel.

Und alles, was im Nebel ist, ist meist offen für wüste Spekulationen wie z.B. "Wann erlangt meine KI ein Bewusstsein?" Bro, gar nicht. Wenn Du das hier gelesen hast, möchtest Du jeden Menschen erschlagen, der solche Ideen in die Welt setzt. Versprochen. :-)

Wenn Du selbst ein Modell trainierst, werden die Mechanismen sichtbar: Du siehst, wie aus rohem Text Tokens werden, wie das Modell Muster erkennt, wie der Loss-Wert sinkt und was das für die Qualität der Ausgabe bedeutet.

In den folgenden Abschnitten gehen wir jeden dieser drei Wege im Detail durch. Du erfährst, wie RAG funktioniert und warum es für die meisten Anwendungsfälle die beste Wahl ist. Du lernst, wann Fine-Tuning sinnvoll wird und wie Du es praktisch umsetzt. Und schließlich schauen wir uns an, was beim Training from Scratch wirklich passiert, anhand eines echten Experiments, das ich auf meinem eigenen Server durchgeführt habe.

Du lernst hier nur eine Sache NICHT: Bestaunenswerte Magie und Esoterik. Wie langweilig, das ist einfach kein Engagement-Futter für Social Media.

Was Dich erwartet

In diesem Kapitel zeige ich Dir die drei Wege, wie Du Dein Fachwissen in ein KI-System integrieren kannst, und demonstriere anhand eines echten Experiments, was beim Training eines eigenen Modells wirklich passiert.

Teil 1: Die drei Wege

• RAG: Retrieval-Augmented Generation

• Fine-Tuning: Das Modell anpassen

• Training from Scratch

• Welcher Weg passt zu Dir?

Teil 2: Die Demo – Ein Mini-LLM von Grund auf

• Die Demo: Einführung

• Die Hardware

• Die Trainingsumgebung einrichten

• Die Trainingsdaten sammeln

• Was ist Tokenisierung?

• Den eigenen Tokenizer trainieren

• Wie ein Sprachmodell lernt

• Die Transformer-Architektur

• Das Modell konfigurieren

• Das Training durchführen

• Checkpoints und Monitoring

• Overfitting erkennen und vermeiden

• Das Ergebnis testen

• Die Grenzen verstehen

• Was wir daraus lernen

RAG: Retrieval-Augmented Generation

RAG ist der pragmatische Weg für die meisten Unternehmensanwendungen. Die Grundidee ist bestechend einfach: Statt das Modell selbst zu verändern, gibst Du ihm bei jeder Anfrage die relevanten Informationen als Kontext mit. Das Modell muss Dein Fachwissen nicht gelernt haben, es bekommt es in dem Moment serviert, in dem es gebraucht wird.

Der technische Ablauf sieht so aus: Zunächst werden Deine Dokumente in kleine Abschnitte zerlegt, sogenannte Chunks. Jeder Chunk wird durch ein Embedding-Modell in einen Vektor umgewandelt, also eine Liste von Zahlen, die den semantischen Inhalt repräsentiert. Diese Vektoren werden in einer Vektordatenbank gespeichert. Wenn jemand eine Frage stellt, wird auch diese Frage in einen Vektor umgewandelt. Dann sucht das System nach den Chunks, deren Vektoren der Frage am ähnlichsten sind. Diese relevanten Textpassagen werden zusammen mit der ursprünglichen Frage an das Sprachmodell geschickt, das daraus eine Antwort formuliert.

1. Indexierung (einmalig)
   Dokumente → Chunks → Embeddings → Vektordatenbank
 
2. Anfrage (bei jeder Frage)
   Frage → Embedding → Ähnlichkeitssuche → Top-K Chunks
 
3. Antwort
   [Relevante Chunks] + [Frage] → Lokales LLM → Antwort
                

Das Schöne an RAG ist die Flexibilität. Wenn sich Deine Dokumente ändern, indexierst Du einfach neu. Das Modell selbst bleibt unverändert, was bedeutet, dass Du jederzeit auf ein besseres Modell wechseln kannst, ohne die gesamte Infrastruktur neu aufzubauen. Die Daten bleiben vollständig unter Deiner Kontrolle, weil nur die relevanten Textpassagen an das Modell geschickt werden, nicht Dein gesamtes Wissen.

Ein lokales RAG-System lässt sich mit überschaubarem Aufwand aufsetzen. Du brauchst eine Vektordatenbank wie Qdrant, ChromaDB oder Milvus, ein Embedding-Modell für die Vektorisierung und ein lokales Sprachmodell wie Llama, Mistral oder Qwen. Alles läuft auf Deiner eigenen Hardware, keine Daten verlassen Dein Netzwerk.

Die Grenzen von RAG zeigen sich bei komplexen Zusammenhängen. Wenn die Antwort auf eine Frage Wissen aus mehreren Dokumenten erfordert, die nicht explizit aufeinander verweisen, kann das System Schwierigkeiten haben. Es findet vielleicht die einzelnen Puzzleteile, aber das Zusammensetzen hängt davon ab, ob das Retrieval die richtigen Chunks liefert und ob das Kontextbudget ausreicht. Die Qualität der Antwort ist direkt an die Qualität des Retrievals gekoppelt.

• Vorteile: Relativ schnell umgesetzt, Dokumente lassen sich jederzeit aktualisieren, läuft auch auf CPU, alle Daten bleiben im Unternehmen, einfacher Wechsel des Basismodells möglich.

• Nachteile: Die Antwortqualität hängt stark von Retrieval-Qualität, Chunking-Strategie und Kontextbudget ab. Bei komplexen Zusammenhängen, die über mehrere Dokumente verteilt sind und nicht im Kontext landen, stößt RAG an Grenzen.

Fine-Tuning: Das Modell anpassen

Beim Fine-Tuning nimmst Du ein bereits trainiertes Modell und trainierst es mit Deinen eigenen Daten weiter. Das Modell hat bereits Sprache gelernt, es weiß, wie Sätze funktionieren, es kennt Grammatik und hat ein breites Allgemeinwissen. Durch das Fine-Tuning bringst Du ihm zusätzlich Deinen speziellen Stil, Deine Terminologie und Deine Denkmuster bei.

Der entscheidende Unterschied zu RAG: Das Modell speichert Muster in seinen Gewichten. Es muss nicht mehr nachschlagen, sondern reproduziert gelernte Strukturen direkt. Das führt zu schnelleren Antworten und konsistenterem Stil. Wichtig: Fine-Tuning verbessert primär Stil, Format und Terminologie. Es macht das Modell nicht automatisch faktisch korrekter, und ohne sorgfältige Evaluation kann es sogar selbstsicherer falsche Antworten geben.

Für das Fine-Tuning brauchst Du saubere Trainingsdaten im richtigen Format. Typischerweise sind das Paare aus Eingabe und erwarteter Ausgabe: eine Frage und die ideale Antwort, ein Textanfang und die gewünschte Fortsetzung, ein Problem und die Lösung. Je nach Anwendungsfall brauchst Du zwischen 500 und 5.000 solcher Beispiele. Die Qualität dieser Daten bestimmt maßgeblich die Qualität des Ergebnisses.

1. Basis-Modell wählen
   └── Llama 3, Mistral, Qwen, Phi, Gemma...
 
2. Trainingsdaten vorbereiten
   └── 500-5000 Beispiele im Format:
       {input: "Frage/Kontext", output: "Ideale Antwort"}
 
3. Training konfigurieren
   ├── Learning Rate: typisch 1e-5 bis 5e-5
   ├── Epochen: 1-5 (mehr kann zu Overfitting führen)
   └── LoRA/QLoRA für ressourcenschonendes Training
 
4. Training durchführen
   └── GPU dringend empfohlen, wenige Stunden bis Tage
 
5. Evaluieren und Deployen
   └── Testen mit Holdout-Daten, dann produktiv setzen
                

Ein wichtiges Konzept beim Fine-Tuning ist LoRA (Low-Rank Adaptation). Statt alle Milliarden Parameter des Modells anzupassen, trainierst Du nur kleine Adapter-Schichten. Das spart enorm Speicher und Rechenzeit. Mit LoRA kannst Du auch auf Consumer-GPUs mit 8-16 GB VRAM ein 7B-Modell fine-tunen. Die Ergebnisse sind oft erstaunlich gut, obwohl nur ein Bruchteil der Parameter angepasst wird.

Die Herausforderung beim Fine-Tuning ist das Gleichgewicht zwischen Spezialisierung und Allgemeinwissen. Wenn Du zu aggressiv trainierst, vergisst das Modell sein Vorwissen (Catastrophic Forgetting). Es kann dann Deine Fachfragen beantworten, versagt aber bei einfachen Alltagsfragen. Die Kunst liegt darin, genug zu trainieren, um Deinen Stil zu übernehmen, aber nicht so viel, dass das Basiswissen verloren geht.

• Vorteile: Das Modell reproduziert Deinen Stil konsistent, ohne dass Beispiele im Prompt mitgeliefert werden müssen. Die Inferenz ist schneller, weil kein RAG-Lookup nötig ist. Das Modell antwortet natürlicher im gewünschten Format.

• Nachteile: Du brauchst saubere Trainingsdaten im richtigen Format, was erheblichen Aufwand bedeutet. Das Modell veraltet, wenn sich Dein Wissen ändert. Technisch anspruchsvoller als RAG, GPU dringend empfohlen. Erhöht nicht automatisch faktische Korrektheit.

Training from Scratch: Von Null beginnen

Der dritte Weg ist der aufwändigste und gleichzeitig der lehrreichste: Du trainierst ein komplett neues Modell von Grund auf, ausschließlich mit Deinen eigenen Daten, ohne Vorwissen aus dem Internet. Das Modell startet als zufällige Zahlenmatrix und lernt alles, was es weiß, aus Deinen Texten.

Warum sollte jemand das tun? Aus praktischer Sicht fast nie. Die großen Sprachmodelle wurden mit riesigen Textmengen trainiert, Größenordnungen mehr als jedes Unternehmen an Dokumenten hat. Dein Firmenwissen umfasst vielleicht ein paar Millionen Wörter. Das reicht typischerweise, um Fachterminologie zu reproduzieren, aber nicht für robuste, generalisierbare sprachliche Kompetenz.

Aber es gibt einen guten Grund, es trotzdem zu tun: Du lernst dabei, was unter der Haube passiert. Die Blackbox wird deutlich verständlicher. Du verstehst, warum große Modelle so gut funktionieren und warum kleine Modelle an bestimmten Aufgaben scheitern. Dieses Verständnis hilft Dir, bessere Entscheidungen zu treffen, wenn Du KI in Deinem Unternehmen einsetzt.

⚠  Warnung: Das ist der harte Weg
 
Hardware:
   ├── GPU mit mindestens 16 GB VRAM
   ├── Viel RAM (32-64 GB empfohlen)
   └── Schneller Storage (NVMe SSD)
 
Daten:
   ├── Mindestens 100.000 Wörter (besser Millionen)
   ├── Saubere, konsistente Texte
   └── Thematisch fokussiert oder breit gestreut
 
Zeit:
   ├── Datenaufbereitung: Stunden bis Tage
   ├── Training: Stunden bis Wochen
   └── Evaluation und Iteration: fortlaufend
 
Ergebnis:
   └── Ein Modell mit Deinem Fachwissen,
       aber ohne jedes Allgemeinwissen
                

Das Ergebnis eines from-scratch trainierten Modells ist faszinierend und ernüchternd zugleich. Wenn Du es mit Fachtexten zu einem bestimmten Thema trainierst, wird es in diesem Thema erstaunlich kompetent. Es übernimmt Deinen Schreibstil, verwendet Deine Terminologie und reproduziert Deine Denkmuster. Aber frag es nach etwas außerhalb der Trainingsdaten, und es produziert oft unzuverlässige Antworten oder versucht, jede Frage in sein einziges Thema zu pressen.

Im folgenden Abschnitt zeige ich Dir anhand eines echten Experiments, was beim Training from Scratch wirklich passiert. Ich habe meine eigenen Texte zum Thema Systemisches Denken genommen und damit ein kleines GPT-2-Modell trainiert. Die Ergebnisse machen die Stärken und Schwächen dieses Ansatzes auf eine Weise sichtbar, die keine theoretische Erklärung erreichen kann.

• Vorteile: Volle Kontrolle über die Trainingsdaten, keine fremden Inhalte, keine Abhängigkeit von Anbietern, tiefes Verständnis der Mechanismen.

• Nachteile: Enorm aufwändig, das Modell kennt keine Allgemeinbildung, scheitert an einfachen Fragen außerhalb der Trainingsdaten, wirtschaftlich fast nie sinnvoll.

Welcher Weg passt zu Deinem Vorhaben?

Die Wahl zwischen RAG, Fine-Tuning und Training from Scratch hängt von Deinem konkreten Anwendungsfall ab. Hier sind einige typische Szenarien und die dazu passenden Empfehlungen.

Anwendungsfall                         → Empfehlung
 
Dokumente durchsuchbar machen           → RAG
Kundenservice mit Wissensbasis          → RAG
FAQ-Bot für interne Prozesse            → RAG
Technische Dokumentation abfragen       → RAG
 
Firmeneigener Schreibstil               → Fine-Tuning
Spezialisierte Fachsprache              → Fine-Tuning
Konsistente Markensprache               → Fine-Tuning
Domänenspezifische Aufgaben             → Fine-Tuning
 
Verstehen wie LLMs funktionieren        → Training (Lernprojekt)
Maximale Datensouveränität              → Training (selten sinnvoll)
Forschung und Experimente               → Training (akademisch)
                

In der Praxis kombinieren viele Unternehmen die Ansätze. Ein fine-getuntes Modell, das den Firmenstil gelernt hat, wird mit RAG erweitert, um aktuelle Dokumente zu berücksichtigen. So bekommst Du das Beste aus beiden Welten: ein Modell, das sich wie ein Mitarbeiter anhört, aber trotzdem auf aktuelle Informationen zugreifen kann.

Die letzte Zeile in der Tabelle ist der eigentliche Grund für dieses Kapitel. Manchmal muss man etwas selbst bauen, um es wirklich zu verstehen, auch wenn das Ergebnis praktisch nutzlos ist. Im folgenden Teil zeige ich Dir, was beim Training eines eigenen Modells wirklich passiert.

Die Demo: Ein Mini-LLM von Grund auf

Theorie ist gut, aber manchmal muss man Dinge selbst ausprobieren, um sie wirklich zu verstehen. Die Frage nach dem eigenen KI-Modell kam in Gesprächen so regelmäßig, dass ich beschlossen habe, es einfach durchzuspielen. Nicht um etwas Nützliches zu bauen, sondern um zu zeigen, was dabei wirklich passiert.

Das Experiment war bewusst klein gehalten. Kein Supercomputer, keine Milliardenbudgets, sondern ein einzelner Server mit einer Consumer-GPU und meine eigenen Texte als Trainingsdaten. Die Frage war: Was passiert, wenn man ein Sprachmodell ausschließlich mit Fachtexten zu einem bestimmten Thema trainiert?

Die Antwort ist faszinierend und lehrreich zugleich. Das Modell lernt erstaunlich gut, was in den Trainingsdaten steht. Es übernimmt Schreibstil, Terminologie und Denkmuster. Aber außerhalb dieser Trainingsdaten hat es keine belastbare Wissensbasis. Frag es nach der Hauptstadt von Frankreich, und es versucht, die Frage mit systemischem Denken zu beantworten, weil das der einzige Kontext ist, den es kennt.

In den folgenden Abschnitten gehe ich jeden Schritt des Experiments durch: die Hardware, die Daten, die Architektur, das Training und die Ergebnisse. Wenn Du danach verstehst, warum große Modelle so gut funktionieren und warum ein kleines Modell mit begrenzten Daten an seine Grenzen stößt, hat dieses Kapitel seinen Zweck erfüllt.

Die Hardware

Für dieses Experiment habe ich einen dedizierten Server bei Hetzner verwendet. Die Wahl fiel auf eine Konfiguration, die auch für andere lokale KI-Aufgaben geeignet ist: stark genug für ernsthaftes Training, aber nicht so teuer, dass es den Rahmen eines Experiments sprengt.

Das Herzstück ist eine NVIDIA RTX 4000 SFF Ada Generation mit 20 GB VRAM. Das klingt nach viel, ist aber im Vergleich zu dem, was große Forschungslabore verwenden, bescheiden. Die großen Modelle werden auf Clustern mit Hunderten von GPUs trainiert, jede mit 80 GB VRAM oder mehr. Aber für ein kleines Experiment mit begrenzten Daten reicht diese Konfiguration völlig aus.

GPU:     NVIDIA RTX 4000 SFF Ada Generation
         └── 20 GB VRAM
         └── Ada Lovelace Architektur
         └── Tensor Cores für ML-Beschleunigung
 
RAM:     64 GB DDR5
         └── Wichtig für große Batch-Sizes
         └── Preprocessing der Daten
 
CPU:     Intel Core i5-13500
         └── 14 Kerne (6P + 8E)
         └── Gut für Datenaufbereitung
 
Storage: NVMe SSD
         └── Schnelles Laden der Trainingsdaten
         └── Checkpoints speichern
                

Der VRAM ist der limitierende Faktor beim Training. Je mehr VRAM, desto größere Modelle und Batch-Sizes sind möglich. Mit 20 GB lässt sich ein GPT-2-Modell mit 110 Millionen Parametern komfortabel trainieren. Für größere Modelle wie Llama 7B hängt der VRAM-Bedarf stark von Precision (FP16, INT8, INT4), Training vs. Inferenz, Optimizer-Wahl und Batch-Size ab. Mit LoRA und 4-Bit-Quantisierung ist Fine-Tuning auch auf 16 GB möglich, Full-Fine-Tuning in FP16 braucht deutlich mehr.

Der RAM ist wichtiger, als man zunächst denkt. Während des Trainings werden die Daten im Speicher gehalten, Gradients berechnet und Optimizer-States verwaltet. 64 GB geben genug Spielraum, um auch bei größeren Datasets nicht in Speicherprobleme zu laufen.

Die Kosten für diese Konfiguration liegen bei etwa 200-300 Euro pro Monat. Das ist nicht billig, aber für ein Lernprojekt überschaubar. Die großen Frontier-Modelle werden mit Budgets trainiert, die mehrere Größenordnungen darüber liegen.

Die Trainingsumgebung einrichten

Bevor das Training beginnen kann, muss die Software-Umgebung stehen. Das klingt trivial, ist aber oft der Punkt, an dem viele Projekte scheitern. Inkompatible Versionen, fehlende Treiber, Speicherprobleme. Die gute Nachricht: Wenn Du weißt, worauf Du achten musst, ist die Einrichtung in einer Stunde erledigt.

Die Basis ist Python. Für Machine Learning hat sich Python als Standard durchgesetzt, nicht weil die Sprache besonders schnell wäre, sondern weil die Libraries hervorragend sind. PyTorch, das Framework, das wir für das Training verwenden, ist in Python geschrieben und bietet eine intuitive API, die sich fast wie Pseudocode liest.

# 1. Python-Version prüfen (3.10+ empfohlen)
$ python3 --version
Python 3.11.4
 
# 2. Virtuelle Umgebung erstellen
$ python3 -m venv llm-training
$ source llm-training/bin/activate
 
# 3. PyTorch mit CUDA-Unterstützung installieren
$ pip install torch torchvision torchaudio \
    --index-url https://download.pytorch.org/whl/cu121
 
# 4. Zusätzliche Libraries
$ pip install transformers datasets tokenizers
$ pip install wandb tensorboard  # Monitoring
$ pip install numpy pandas tqdm
 
# 5. CUDA-Verfügbarkeit testen
$ python3 -c "import torch; print(torch.cuda.is_available())"
True
 
$ python3 -c "import torch; print(torch.cuda.get_device_name(0))"
NVIDIA RTX 4000 SFF Ada Generation
                

Der kritische Punkt ist die CUDA-Kompatibilität. PyTorch-Wheels bringen oft ihre eigene CUDA-Runtime mit, aber der NVIDIA-Treiber muss zur verwendeten CUDA-Version passen. Im Zweifelsfall: Treiber aktuell halten und das PyTorch-Wheel verwenden, das zur Treiberversion passt. Bei Inkompatibilität funktioniert die GPU-Beschleunigung nicht, und das Training läuft auf der CPU, was bei einem Modell dieser Größe Tage statt Stunden dauern würde.

Die virtuelle Umgebung ist keine Spielerei, sondern Notwendigkeit. Machine-Learning-Projekte haben oft komplexe Abhängigkeiten, die miteinander in Konflikt geraten können. Eine isolierte Umgebung stellt sicher, dass alles zusammenpasst und andere Projekte auf dem Server nicht beeinträchtigt werden.

# Verfügbaren VRAM anzeigen
$ nvidia-smi
 
+-------------------------------------------------------------------------+
| NVIDIA-SMI 545.23       Driver Version: 545.23       CUDA Version: 12.3 |
|-------------------------------+----------------------+------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile GPU-Util|
|===============================+======================|==================|
|   0  RTX 4000 SFF Ada    Off  | 00000000:01:00.0 Off |                N/A|
| N/A   42C    P8    10W / 70W  |      0MiB / 20480MiB |      0%          |
+-------------------------------+----------------------+------------------+
 
✓ 20 GB VRAM verfügbar
✓ Temperatur normal (42°C)
✓ Keine anderen Prozesse aktiv
                

Hugging Face Transformers ist die Library, die das Training erheblich vereinfacht. Sie stellt vorgefertigte Modellarchitekturen bereit, kümmert sich um das Laden und Speichern von Checkpoints und bietet Utilities für Tokenisierung und Datenverarbeitung. Statt alles von Grund auf zu implementieren, können wir auf bewährte Komponenten zurückgreifen.

Für das Monitoring habe ich Weights & Biases (wandb) und TensorBoard installiert. Beide Tools visualisieren den Trainingsverlauf in Echtzeit: Loss-Kurven, Learning Rate, GPU-Auslastung. Das ist kein Luxus, sondern essenziell, um zu erkennen, ob das Training in die richtige Richtung geht oder ob etwas schief läuft.

Die Trainingsdaten

Die Qualität eines Sprachmodells hängt direkt von der Qualität der Trainingsdaten ab. Garbage in, garbage out gilt hier besonders. Für dieses Experiment habe ich meine eigenen Texte zum Thema Systemisches Denken verwendet, weil dieses Themenfeld einen klaren Wortschatz und erkennbare Denkmuster hat.

Die Datensammlung umfasste Blogbeiträge, Artikel, Newsletter und Dokumentationen, die ich über die Jahre geschrieben habe. Insgesamt etwa 1.036 Dokumente mit rund 1,2 Millionen Wörtern. Das klingt nach viel, ist aber im Vergleich zu den Trainingsdaten großer Modelle winzig. Die großen Modelle werden mit Größenordnungen von hunderten Milliarden Tokens trainiert.

Scanning directories...
 
Gefunden:   1.036 Dokumente
Wörter:     ~1.2 Millionen
Zeichen:    ~7.8 Millionen
Themen:     Systemisches Denken, Kybernetik,
            Feedback-Loops, Komplexität, Marketing
 
Preprocessing...
├── HTML-Tags entfernt
├── Encoding normalisiert (UTF-8)
├── Duplikate entfernt
└── Texte bereinigt
 
✓ Dataset ready: 847 unique documents
✓ Total tokens: ~1.4 Millionen
                

Die Datenaufbereitung ist aufwändiger, als man denkt. HTML-Tags müssen entfernt werden, Sonderzeichen normalisiert, Duplikate gefiltert. Inkonsistenzen in der Formatierung können das Training stören. Ein sauberes Dataset ist die halbe Miete.

Thematisch sind die Daten fokussiert: Systemisches Denken, Kybernetik, Feedback-Loops, Komplexitätstheorie und deren Anwendung auf Marketing und Unternehmensführung. Diese thematische Eingrenzung hat einen wichtigen Effekt: Das Modell wird in diesem Bereich relativ kompetent, weiß aber nichts über andere Themen.

Die Tokenisierung verdient besondere Aufmerksamkeit. Was genau passiert dabei, und warum ist sie so wichtig? Das erkläre ich im nächsten Abschnitt.

Was ist Tokenisierung?

Bevor ein Sprachmodell Text verarbeiten kann, muss dieser Text in eine Form gebracht werden, die das Modell versteht. Computer arbeiten mit Zahlen, nicht mit Buchstaben. Die Tokenisierung ist der Prozess, der Text in eine Folge von Zahlen umwandelt, die das Modell verarbeiten kann.

Die naive Lösung wäre, jedes Wort als eine Zahl zu codieren. Das hat zwei Probleme. Erstens: Die deutsche Sprache hat Hunderttausende Wörter, Komposita und Fachbegriffe. Das Vokabular würde explodieren. Zweitens: Seltene Wörter kämen im Training kaum vor, das Modell könnte sie nicht vernünftig verarbeiten.

Die elegante Lösung heißt Byte-Pair Encoding (BPE). Statt ganze Wörter zu speichern, lernt der Tokenizer häufige Zeichenfolgen. Häufige Wörter wie der, und, ist werden als einzelne Tokens gespeichert. Seltene Wörter werden in kleinere Teile zerlegt, die das Modell kennt.

Eingabe: "Systemisches Denken ermöglicht neue Perspektiven"
 
Tokens:
  "System"    → Token 4821
  "isches"    → Token 1293
  " Denken"   → Token 7744
  " ermöglicht" → Token 15822
  " neue"     → Token 892
  " Perspektiven" → Token 23419
 
Ergebnis: [4821, 1293, 7744, 15822, 892, 23419]
 
─────────────────────────────────────────────
 
Häufiges Wort: "und" → Ein Token (912)
Seltenes Wort: "Kybernetik" → Drei Tokens
   "Ky" (8421) + "ber" (293) + "netik" (19283)
 
Beobachtung:
Je häufiger ein Wort in den Trainingsdaten,
desto wahrscheinlicher wird es als EIN Token gelernt (bei BPE).
                

Die Vokabulargröße ist ein Kompromiss. Ein kleines Vokabular (z.B. 8.000 Tokens) bedeutet, dass jedes Wort in viele kleine Teile zerlegt wird, was die Sequenzen länger macht und das Kontextfenster schneller füllt. Ein großes Vokabular (z.B. 100.000 Tokens) braucht mehr Speicher für die Embedding-Tabelle und enthält viele Tokens, die selten vorkommen und daher schlecht gelernt werden.

Für dieses Experiment habe ich 32.000 Tokens gewählt. Das ist ein gängiger Wert, der gut mit der Größe meines Datasets harmoniert. Deutsche Fachbegriffe aus dem Bereich systemisches Denken werden meist als 1-3 Tokens codiert, was eine vernünftige Balance darstellt.

Ein wichtiger Aspekt: Der Tokenizer bestimmt, wie das Modell Text repräsentiert. Wenn ein Begriff in mehrere Tokens zerlegt wird, muss das Modell erst lernen, dass diese Tokens zusammengehören. Ein Tokenizer, der auf englische Texte trainiert wurde, wird deutsche Umlaute möglicherweise als einzelne Zeichen tokenisieren, was ineffizient ist. Deshalb trainieren wir einen eigenen Tokenizer.

Den eigenen Tokenizer trainieren

Vorgefertigte Tokenizer wie die von OpenAI oder Hugging Face sind auf englische Texte optimiert. Für deutsche Fachtexte zu systemischem Denken funktionieren sie, aber nicht optimal. Deshalb trainieren wir einen eigenen Tokenizer, der die Besonderheiten unserer Texte berücksichtigt.

Das Training eines Tokenizers ist überraschend schnell. Der Algorithmus analysiert die Häufigkeiten von Zeichenfolgen und baut iterativ ein Vokabular auf. Der Hugging Face Tokenizers-Library macht das in wenigen Zeilen Code.

from tokenizers import Tokenizer
from tokenizers.models import BPE
from tokenizers.trainers import BpeTrainer
from tokenizers.pre_tokenizers import Whitespace
 
# Tokenizer initialisieren
tokenizer = Tokenizer(BPE(unk_token="[UNK]"))
tokenizer.pre_tokenizer = Whitespace()
 
# Trainer konfigurieren
trainer = BpeTrainer(
    vocab_size=32000,
    special_tokens=["[PAD]", "[UNK]", "[EOS]"]
)
 
# Training mit unseren Texten
tokenizer.train(files=["training_data.txt"], trainer=trainer)
tokenizer.save("tokenizer.json")
                

Loading training data...
Files: 847 documents
Total characters: 7,823,419
 
Training BPE tokenizer...
├── Building character vocabulary
├── Computing pair frequencies
├── Merging pairs iteratively
└── Finalizing vocabulary
 
✓ Vocabulary size: 32,000 tokens
✓ Training time: 47 seconds
 
Top 10 häufigste Tokens (illustrativ):
   1. " der"     (54,821x)
   2. " und"     (48,293x)
   3. " die"     (45,108x)
   4. " in"      (38,421x)
   5. " System"  (12,847x)
   6. " Denken"  (8,293x)
   7. " Feedback" (4,821x)
   8. " Muster"  (4,293x)
   9. " Komplex" (3,847x)
  10. " Loop"    (3,219x)
 
✓ Tokenizer saved: tokenizer.json (2.1 MB)
                

Der trainierte Tokenizer spiegelt die Häufigkeiten in unseren Daten wider. System und Denken sind unter den häufigsten Tokens, weil sie im Corpus ständig vorkommen. Das bedeutet, dass diese Begriffe effizient als einzelne Tokens codiert werden, während sie bei einem Standard-Tokenizer möglicherweise in mehrere Teile zerlegt würden.

Die Special Tokens haben besondere Funktionen: [PAD] füllt Sequenzen auf eine einheitliche Länge auf, [UNK] repräsentiert unbekannte Zeichen, und [EOS] markiert das Ende eines Textes. Diese Tokens sind wichtig für das Training und die Inferenz.

Ein kurzer Test zeigt, wie unser Tokenizer im Vergleich zu einem Standard-Tokenizer abschneidet. Bei domänenspezifischen Texten braucht unser Tokenizer weniger Tokens für denselben Inhalt, was bedeutet, dass mehr Text in das Kontextfenster passt.

Text: "Systemisches Denken betrachtet Wechselwirkungen
       in komplexen Systemen als Feedback-Loops."
 
GPT-2 Standard-Tokenizer (illustrativ):
   ~15-20 Tokens (variiert je nach Tokenizer-Version)
   Seltene Wörter werden in Subwörter zerlegt:
   "Systemisches" → "System" + "isches"
   "Wechselwirkungen" → "Wechsel" + "wirk" + "ungen"
 
Unser Tokenizer:
   ~10 Tokens
   Domänenspezifische Begriffe als einzelne Tokens:
   "Systemisches", "Wechselwirkungen", "Feedback-Loops"
 
→ Deutlich weniger Tokens für domänenspezifische Texte
                

Wie ein Sprachmodell lernt

Jetzt kommen wir zum Kern der Sache: Wie lernt ein Sprachmodell eigentlich? Die Grundidee ist verblüffend einfach: Das Modell versucht, das nächste Wort vorherzusagen. Immer wieder, milliardenfach. Dabei justiert es seine internen Parameter so, dass die Vorhersagen besser werden.

Stell Dir vor, Du liest den Satzanfang Die Katze sitzt auf dem. Dein Gehirn hat sofort Erwartungen: Dach, Sofa, Tisch, Baum. Das Wort Relativitätstheorie erwartest Du nicht. Ein Sprachmodell lernt genau diese Erwartungen aus den Trainingsdaten.

Eingabe: "Systemisches Denken betrachtet"
 
Modell berechnet Wahrscheinlichkeiten:
   "Zusammenhänge"  → 0.23 (23%)
   "Wechselwirkungen" → 0.18 (18%)
   "Systeme"        → 0.15 (15%)
   "Probleme"       → 0.09 (9%)
   "die"            → 0.07 (7%)
   ...
   "Bananen"        → 0.00001 (0.001%)
 
Tatsächliches nächstes Token: "Wechselwirkungen"
 
Loss = -log(0.18) = 1.71
 
Je höher die Wahrscheinlichkeit für das richtige Token,
desto niedriger der Loss. Das Modell passt seine
Parameter an, um den Loss zu minimieren.
                

Der Loss ist das Maß dafür, wie falsch das Modell liegt. Wenn das Modell das richtige Token mit 100% Wahrscheinlichkeit vorhersagt, ist der Loss 0. Wenn die Vorhersage komplett daneben liegt, ist der Loss hoch. Das Ziel des Trainings: den Loss minimieren.

Die Magie passiert im Backpropagation-Schritt. Nach jeder Vorhersage berechnet das System, welche Parameter in welche Richtung angepasst werden müssen, damit die Vorhersage beim nächsten Mal besser wird. Diese Anpassungen sind winzig, aber über Milliarden von Beispielen summieren sie sich zu einem Modell, das sprachliche Muster reproduzieren kann.

1. Forward Pass
   Text → Tokens → Embeddings → Transformer → Vorhersage
 
2. Loss berechnen
   Vergleiche Vorhersage mit tatsächlichem Token
   Loss = wie falsch war die Vorhersage?
 
3. Backward Pass (Backpropagation)
   Berechne Gradienten: Welcher Parameter hat wie viel
   zum Fehler beigetragen?
 
4. Parameter Update
   Passe jeden Parameter ein kleines bisschen an
   in die Richtung, die den Loss reduziert
 
5. Wiederholen
   Nächstes Token, nächster Satz, nächste Epoche...
   Milliardenfach.
 
→ Emergentes Verhalten:
  Nach genug Wiederholungen kann das Modell
  Sprache, Grammatik, Fakten und sogar logische
  Zusammenhänge reproduzieren.
                

Was dabei emergiert, ist faszinierend. Das Modell wurde nie explizit mit Grammatikregeln gefüttert, aber es lernt sie aus den Mustern. Es wurde nie über Fakten unterrichtet, aber es kodiert sie als statistische Muster in seinen Parametern. Es kennt keine Definition von logischem Denken, aber es reproduziert logische Muster, wenn es genug davon in den Trainingsdaten gesehen hat.

Die Grenzen dieses Ansatzes sind ebenso wichtig: Das Modell generiert Kombinationen aus gelernten Mustern. Es kann neue Formulierungen erzeugen, aber es ist stark an seine Trainingsdaten gebunden. Wenn ein Muster nicht in den Trainingsdaten vorkommt, kann das Modell es nicht zuverlässig reproduzieren. Deshalb sind große, diverse Trainingsdaten so wichtig für die Fähigkeiten eines Modells.

Die Transformer-Architektur

Der Transformer ist die Architektur, die alle modernen Sprachmodelle antreibt. Entwickelt 2017 bei Google, hat er ältere Architekturen wie RNNs und LSTMs fast vollständig abgelöst. Der Grund: Transformer können paralleler rechnen und erfassen Zusammenhänge über längere Distanzen.

Das Herzstück des Transformers ist der Attention-Mechanismus. Die Idee: Wenn das Modell ein Token verarbeitet, schaut es auf alle anderen Tokens im Kontext und entscheidet, welche davon relevant sind. Das erlaubt es, Zusammenhänge über weite Distanzen zu erfassen.

Satz: "Das System reguliert sich selbst durch Feedback"
 
Attention für "sich":
 
     Das    System  reguliert  sich  selbst  durch  Feedback
      │       │        │        │      │       │       │
     0.02    0.45     0.15     1.0   0.31   0.04    0.03
 
"sich" achtet stark auf "System" (0.45) und "selbst" (0.31)
→ Das Modell lernt, dass "sich selbst" zusammengehört
→ und dass "System" das Subjekt ist, auf das sich "sich" bezieht
 
Attention für "Feedback":
 
     Das    System  reguliert  sich  selbst  durch  Feedback
      │       │        │        │      │       │       │
     0.01    0.38    0.29     0.05   0.04   0.12    1.0
 
"Feedback" achtet auf "System" und "reguliert"
→ Das Modell lernt den Zusammenhang zwischen
   Regulation und Feedback in Systemen
                

Der Transformer besteht aus mehreren Schichten, die aufeinander aufbauen. Jede Schicht hat zwei Hauptkomponenten: den Multi-Head Attention Block und ein Feed-Forward Network. Die Attention erfasst Beziehungen zwischen Tokens, das Feed-Forward Network transformiert die Repräsentationen.

Multi-Head Attention bedeutet, dass das Modell mehrere Attention-Mechanismen parallel laufen lässt. Jeder Head kann sich auf andere Aspekte konzentrieren: einer auf Grammatik, einer auf semantische Ähnlichkeit, einer auf Positionen im Satz. Die Ergebnisse werden kombiniert.

Eingabe: Token-Embeddings (Sequenz × 768 Dimensionen)
          ↓
┌─────────────────────────────────────────────┐
│  Multi-Head Self-Attention                  │
│  ├── 12 parallele Attention-Heads           │
│  ├── Jeder Head: Query, Key, Value Matrizen │
│  └── Outputs werden konkateniert            │
├─────────────────────────────────────────────┤
│  Add & Normalize                            │
│  └── Residual Connection + Layer Norm       │
├─────────────────────────────────────────────┤
│  Feed-Forward Network                       │
│  ├── Linear: 768 → 3072                     │
│  ├── GELU Activation                        │
│  └── Linear: 3072 → 768                     │
├─────────────────────────────────────────────┤
│  Add & Normalize                            │
└─────────────────────────────────────────────┘
          ↓
Ausgabe: Transformierte Embeddings (Sequenz × 768)
 
Dieser Block wird 12x gestapelt.
Jede Schicht verfeinert die Repräsentation.
                

Die Positionscodierung ist ein wichtiges Detail. Da Attention keine inherente Vorstellung von Reihenfolge hat, muss die Position jedes Tokens explizit codiert werden. GPT-2 verwendet gelernte Positionsembeddings, modernere Modelle wie Llama verwenden RoPE (Rotary Position Embedding), das besser mit langen Kontexten umgeht.

Warum funktioniert das so gut? Der Transformer kann jedes Token mit jedem anderen verbinden, unabhängig von der Distanz. Bei einem RNN müsste Information von Token zu Token weitergegeben werden, wobei sie mit jeder Station schwächer wird. Der Transformer umgeht dieses Problem, indem er direkte Verbindungen erlaubt.

Die Skalierbarkeit ist der zweite Grund für den Erfolg. Transformer lassen sich gut parallelisieren, weil die Attention-Berechnungen für verschiedene Positionen gleichzeitig erfolgen können. Das macht Training auf vielen GPUs effizient, und genau das hat die Explosion der Modellgrößen ermöglicht.

Das Modell konfigurieren

Für das Experiment habe ich die GPT-2 Architektur gewählt. Nicht weil sie die modernste wäre, sondern weil sie gut dokumentiert ist, auf meiner Hardware in akzeptabler Zeit trainierbar war und die grundlegenden Prinzipien aller modernen Sprachmodelle verkörpert.

GPT-2 ist ein Transformer-Modell in der Decoder-only Variante. Das bedeutet, es liest Text von links nach rechts und versucht, das jeweils nächste Wort vorherzusagen. Diese simple Aufgabe, Next Token Prediction genannt, ist der Kern aller großen Sprachmodelle. Die Idee dahinter: Wenn ein Modell gut darin ist, das nächste Wort vorherzusagen, muss es statistisch robuste Muster der Sprache gelernt haben.

Architektur:    GPT-2 (Transformer, Decoder-only)
 
Parameter:      110.434.816 (110.4M)
                └── Zum Vergleich: GPT-3 hat 175B
                └── Llama 3 hat 8B-70B
 
Vokabular:      32.000 Tokens
                └── Eigener Tokenizer
                └── Optimiert für deutsche Fachtexte
 
Kontext:        1.024 Tokens
                └── ~750 Wörter Kontextfenster
                └── Moderne Modelle: 32K-200K+
 
Schichten:      12 Transformer-Layer
                └── Je 12 Attention-Heads
                └── Feed-Forward Networks
 
Embedding:      768 Dimensionen
                └── Jedes Token als 768-D Vektor
                

Die 110 Millionen Parameter verteilen sich auf verschiedene Komponenten: das Embedding-Layer, das Tokens in Vektoren umwandelt; die Attention-Mechanismen, die Beziehungen zwischen Tokens lernen; und die Feed-Forward-Networks, die die eigentliche Transformation durchführen. Jeder dieser Parameter ist eine Zahl, die während des Trainings angepasst wird.

Das Kontextfenster von 1.024 Tokens ist ein wichtiger Limitierungsfaktor. Das Modell kann immer nur die letzten rund 750 Wörter sehen, wenn es das nächste Wort vorhersagt. Moderne Modelle bieten Kontextfenster von 32.000 bis über 200.000 Tokens, je nach Anbieter und Modellvariante. Das macht einen enormen Unterschied bei längeren Dokumenten oder komplexen Aufgaben.

Die Architektur selbst ist heute nicht mehr State of the Art, aber für das Verständnis der Grundprinzipien völlig ausreichend. Die neueren Modelle wie Llama oder Mistral verwenden optimierte Varianten mit verbessertem Attention-Mechanismus (Grouped Query Attention, Flash Attention), effizienteren Aktivierungsfunktionen und besserer Positionscodierung. Aber das Grundprinzip bleibt dasselbe: ein Transformer, der das nächste Token vorhersagt.

Das Training

Das Training eines Sprachmodells ist ein iterativer Prozess. Das Modell sieht die Trainingsdaten immer wieder, passt seine Parameter an und wird dabei schrittweise besser. Ein Durchlauf durch alle Daten nennt sich Epoche. Für dieses Experiment habe ich 100 Epochen trainiert, das Modell hat also jeden Text 100 Mal gesehen.

Der zentrale Indikator beim Training ist der Loss-Wert. Er misst, wie gut das Modell das nächste Token vorhersagt. Ein hoher Loss bedeutet, das Modell liegt oft daneben. Ein niedriger Loss bedeutet, es trifft die richtigen Vorhersagen. Das Ziel ist, den Loss zu minimieren, ohne dabei die Trainingsdaten auswendig zu lernen (Overfitting).

GPU: NVIDIA RTX 4000 SFF Ada Generation
VRAM: 18.2 GB / 20 GB allocated
Loaded: 1036 documents, 1.4M tokens
 
Training tokenizer...
✓ Vocabulary: 32,000 tokens
✓ Special tokens: [PAD], [EOS], [UNK]
 
Initializing model...
✓ Parameters: 110,434,816 (110.4M)
✓ Optimizer: AdamW, lr=5e-5
✓ Scheduler: Cosine with warmup
 
Starting 100 epoch training...
 
Epoch   1/100  ████████████████████  loss: 8.28
Epoch  10/100  ████████████████████  loss: 2.41
Epoch  25/100  ████████████████████  loss: 0.89
Epoch  50/100  ████████████████████  loss: 0.34
Epoch  75/100  ████████████████████  loss: 0.08
Epoch 100/100  ████████████████████  loss: 0.016
 
✓ Training complete
✓ Final loss: 0.016
✓ Model saved: 422 MB
✓ Duration: ~3 hours
                

Der Loss-Verlauf erzählt eine interessante Geschichte. Am Anfang liegt der Loss bei 8.28, das Modell rät praktisch zufällig. Nach 10 Epochen ist der Loss auf 2.41 gefallen, das Modell hat die grundlegende Struktur der Sprache erfasst. Nach 50 Epochen erreichen wir 0.34, das Modell reproduziert die Trainingsdaten schon recht gut. Am Ende, nach 100 Epochen, liegt der Loss bei 0.016, was bedeutet, dass das Modell die Trainingsdaten nahezu perfekt vorhersagen kann.

Der Optimizer AdamW ist Standard für das Training von Transformern. Die Learning Rate von 5e-5 ist konservativ gewählt, um stabiles Training zu gewährleisten. Der Cosine-Scheduler reduziert die Learning Rate gegen Ende des Trainings, was hilft, ein gutes Minimum zu finden.

Die Trainingsdauer von etwa 3 Stunden ist für diese Modellgröße und Datenmenge typisch. Größere Modelle oder mehr Daten würden entsprechend länger dauern. Das Training von Llama 2 70B hat zum Beispiel 1,7 Millionen GPU-Stunden gedauert.

Checkpoints und Monitoring

Ein Training, das Stunden oder Tage dauert, willst Du nicht blind laufen lassen. Checkpoints und Monitoring sind essenziell, um den Fortschritt zu verfolgen, Probleme früh zu erkennen und im Notfall auf einen früheren Stand zurückzukehren.

Ein Checkpoint ist ein Snapshot des Modells zu einem bestimmten Zeitpunkt. Er enthält alle Parameter, den Optimizer-State und Metadaten wie die aktuelle Epoche. Wenn das Training abstürzt oder Du feststellt, dass etwas schiefgelaufen ist, kannst Du vom letzten Checkpoint aus weitermachen, statt von vorne zu beginnen.

checkpoint_config = {
    "save_every_n_epochs": 10,
    "save_best_only": True,
    "metric": "val_loss",
    "keep_last_n": 3
}
 
Gespeicherte Checkpoints:
checkpoints/
├── epoch_010_loss_2.41.pt    (42 MB)
├── epoch_020_loss_1.23.pt    (42 MB)
├── epoch_030_loss_0.67.pt    (42 MB)
├── epoch_040_loss_0.45.pt    (42 MB)
├── epoch_050_loss_0.34.pt    (42 MB)
├── ...
└── best_model.pt             (42 MB)
 
Jeder Checkpoint enthält:
├── model_state_dict     # Alle 110M Parameter
├── optimizer_state_dict # AdamW Momentums
├── scheduler_state_dict # Learning Rate State
├── epoch               # Aktuelle Epoche
├── global_step         # Trainingsschritt
└── config              # Hyperparameter
                

Das Monitoring zeigt in Echtzeit, was während des Trainings passiert. Die wichtigsten Metriken sind der Training-Loss und, wenn vorhanden, der Validation-Loss. Der Training-Loss zeigt, wie gut das Modell die Trainingsdaten lernt. Der Validation-Loss zeigt, wie gut es auf ungesehenen Daten generalisiert.

$ tensorboard --logdir=./runs
TensorBoard 2.15.1 at http://localhost:6006
 
Überwachte Metriken:
 
Loss-Kurven
   ├── train/loss      ↘ fällt kontinuierlich
   └── val/loss        ↘ fällt, dann stagniert
 
Learning Rate
   └── lr/scheduler    ↘ Cosine Decay von 5e-5 zu 0
 
Hardware
   ├── gpu/memory      █████████████░░░  18.2 GB / 20 GB
   ├── gpu/utilization █████████████████ 98%
   └── gpu/temperature 72°C
 
Training Speed
   ├── steps/sec       12.4
   └── tokens/sec      12,697
 
⚠ Alerts konfiguriert:
   └── Warnung wenn val_loss > train_loss * 1.5 (Overfitting)
                

Die GPU-Auslastung verrät, ob das Training effizient läuft. Eine Auslastung unter 80% deutet oft auf einen Flaschenhals hin: langsames Datenladen, zu kleine Batch-Size oder ineffiziente Preprocessing-Pipeline. Bei 98% Auslastung nutzen wir die Hardware optimal aus.

Die Temperatur der GPU ist ebenfalls wichtig. Bei Dauerbelastung können GPUs auf 80-85°C kommen. Alles darüber ist kritisch und kann zu Throttling oder Hardwareschäden führen. Bei unserem Setup bleibt die Temperatur bei 72°C, was im sicheren Bereich liegt.

Weights & Biases (wandb) bietet zusätzlich Cloud-basiertes Logging mit schönen Dashboards, Experiment-Vergleichen und Team-Sharing. Für ein Solo-Projekt reicht TensorBoard, aber bei komplexeren Setups oder Teamarbeit ist wandb die bessere Wahl.

Overfitting erkennen und vermeiden

Overfitting ist das größte Risiko beim Training von Machine-Learning-Modellen. Das Modell lernt die Trainingsdaten auswendig, statt generalisierbare Muster zu erkennen. Es kann die Trainingsdaten perfekt reproduzieren, versagt aber bei neuen, ungesehenen Daten.

Bei einem kleinen Dataset wie unserem ist Overfitting fast unvermeidlich. 1,4 Millionen Tokens sind für ein Modell mit 110 Millionen Parametern nicht viel. Das Modell hat genug Kapazität, um jeden einzelnen Text zu memorieren, statt abstrakte Muster zu lernen.

Gesundes Training:
Epoch  Train-Loss  Val-Loss   Status
  10      2.41       2.58     ✓ Beide fallen
  20      1.23       1.45     ✓ Gap klein
  30      0.67       0.89     ✓ Val folgt Train
 
Overfitting:
Epoch  Train-Loss  Val-Loss   Status
  40      0.45       0.91     ⚠ Gap wächst
  50      0.34       0.98     ⚠ Val steigt!
  60      0.21       1.12     ✗ Overfitting
 
───────────────────────────────────────────
 
Das klassische Muster:
 
Loss
  │
  │  ╲
  │   ╲  train_loss
  │    ╲___________
  │     ╲
  │      ╲______
  │             ╲_val_loss
  │              ╱
  │           __╱  ← Wendepunkt
  │          ╱
  └────────────────────────── Epoch
        ↑
    Hier stoppen!
    (Early Stopping)
                

Das klassische Anzeichen für Overfitting: Der Training-Loss fällt weiter, aber der Validation-Loss beginnt zu steigen. Das Modell wird besser darin, die Trainingsdaten vorherzusagen, aber schlechter darin, neue Daten zu verarbeiten. Der Wendepunkt, an dem der Validation-Loss zu steigen beginnt, ist der optimale Zeitpunkt zum Stoppen.

Early Stopping ist die einfachste Gegenmaßnahme. Du beobachtest den Validation-Loss und stoppst das Training, wenn er über mehrere Epochen nicht mehr sinkt. Das verhindert, dass das Modell in die Overfitting-Phase rutscht.

1. Early Stopping
   patience = 5  # Stoppe nach 5 Epochen ohne Verbesserung
   → Verhindert tiefes Overfitting
 
2. Dropout
   dropout_rate = 0.1  # 10% der Neuronen zufällig deaktiviert
   → Zwingt das Modell zu robusteren Features
 
3. Weight Decay
   weight_decay = 0.01  # L2 Regularisierung
   → Verhindert zu große Gewichte
 
4. Data Augmentation
   # Bei Text schwieriger als bei Bildern
   → Synonyme, Umformulierungen, Back-Translation
 
5. Mehr Daten
   → Die beste Lösung, wenn verfügbar
 
6. Kleineres Modell
   → Weniger Parameter = weniger Kapazität zum Memorieren
                

Bei unserem Experiment haben wir bewusst auf diese Maßnahmen verzichtet, um zu zeigen, was passiert. Das Modell hat die Trainingsdaten tatsächlich weitgehend memoriert. Es kann Passagen fast wörtlich reproduzieren, generalisiert aber schlecht auf neue Formulierungen.

Für ein produktives Modell wäre das ein Problem. Für unser Lernprojekt ist es lehrreich: Es zeigt, dass ein niedriger Training-Loss nicht automatisch ein gutes Modell bedeutet. Die Fähigkeit zur Generalisierung ist das, was ein Modell wirklich nützlich macht.

Die praktische Konsequenz: Wenn Du ein eigenes Modell trainierst, achte auf den Validation-Loss mindestens so sehr wie auf den Training-Loss. Und wenn Du nicht genug Daten hast, verwende ein kleineres Modell oder wechsle zu Fine-Tuning, wo das Basismodell bereits generalisierbare Muster gelernt hat.

Das Ergebnis testen

Nach dem Training kommt der spannende Teil: Was kann das Modell tatsächlich? Die Antwort überrascht in beide Richtungen. Innerhalb seines Trainingsbereichs ist das Modell erstaunlich kompetent. Außerhalb davon scheitert es auf faszinierende Weise.

Bei Fragen zum systemischen Denken liefert das Modell kohärente, stilistisch konsistente Antworten. Die Wortwahl, die Satzstruktur und die Gedankenführung entsprechen meinem Schreibstil, weil das Modell genau diese Muster aus den Trainingsdaten gelernt hat. Es ist wie ein Echo meiner eigenen Texte, neu arrangiert und rekombiniert.

Prompt: Systemisches Denken
 
Output:
Systemisches Denken bedeutet, die Zusammenhänge zu sehen.
Nicht die einzelnen Teile, sondern wie sie miteinander
verbunden sind. Ein System ist mehr als die Summe seiner
Teile. Die Beziehungen zwischen den Elementen definieren
das Verhalten des Ganzen.
 
Wenn wir ein Problem verstehen wollen, reicht es nicht,
die einzelnen Komponenten zu analysieren. Wir müssen die
Wechselwirkungen betrachten, die Feedback-Loops, die
emergenten Eigenschaften, die aus dem Zusammenspiel
entstehen...
                

Die Qualität dieser Ausgabe ist beeindruckend, wenn man bedenkt, dass das Modell nur 110 Millionen Parameter hat und ausschließlich mit meinen Texten trainiert wurde. Es hat nicht nur Wörter gelernt, sondern auch die Art, wie ich Gedanken strukturiere. Die Sätze fließen, die Argumentation baut aufeinander auf, der Stil ist konsistent.

Aber der eigentliche Test kommt, wenn wir das Modell mit Fragen konfrontieren, die außerhalb seiner Trainingsdaten liegen. Was passiert, wenn wir nach etwas fragen, das in keinem meiner Texte vorkam?

Die Grenzen

Was passiert, wenn wir das Modell nach etwas fragen, das außerhalb seiner Trainingsdaten liegt? Hier zeigt sich die fundamentale Einschränkung eines von Grund auf trainierten Modells mit begrenzten Daten.

Prompt: Die Hauptstadt von Frankreich
 
Output:
Die Hauptstadt von Frankreich ist ein interessantes
Beispiel für systemisches Denken. Die Wechselwirkungen
zwischen den verschiedenen Elementen erzeugen emergente
Eigenschaften, die wir erst verstehen, wenn wir das
Zusammenspiel der Teile betrachten.
 
In einem komplexen System wie einer Stadt entstehen
Muster, die nicht durch die einzelnen Komponenten
erklärt werden können. Die Feedback-Loops zwischen
Infrastruktur, Menschen und Institutionen...
                

Das Modell hat keine Ahnung, dass Paris die Antwort ist. Es hat den Namen Paris nie in einem relevanten Kontext gesehen. Also tut es das Einzige, was es kann: Es versucht, die Frage mit dem einzigen Wissen zu beantworten, das es hat. Systemisches Denken. Das Ergebnis ist absurd, aber aus der Perspektive des Modells völlig logisch.

Dieses Verhalten illustriert ein fundamentales Prinzip: Ein Sprachmodell generiert Text basierend auf gelernten Mustern. Es kann neue Kombinationen erzeugen, aber es ist stark an die Verteilung seiner Trainingsdaten gebunden. Wenn diese Daten nur ein Thema abdecken, wird jede Frage zu diesem Thema umgebogen.

Deshalb funktionieren große Modelle so viel besser: Sie wurden mit riesigen, diversen Textmengen aus allen erdenklichen Bereichen trainiert. Sie haben Geographie, Geschichte, Wissenschaft, Literatur, Programmierung und tausend andere Themen gesehen. Wenn Du sie nach Paris fragst, können sie auf diese Muster zurückgreifen. Mein kleines Modell hat solche Daten nie gesehen und kann sie daher auch nicht reproduzieren.

Was wir daraus lernen

Dieses Experiment war kein Versuch, ein nützliches Produkt zu bauen. Es war ein Lernprojekt, das die Mechanismen sichtbar macht, die in allen Sprachmodellen arbeiten. Die Erkenntnisse lassen sich auf vier Punkte zusammenfassen.

✓ Training funktioniert
  Ein LLM von Grund auf zu trainieren ist machbar,
  auch auf Consumer-Hardware. Die Mechanismen sind
  keine Magie, sondern nachvollziehbare Mathematik.
 
✓ Stil wird gelernt
  Das Modell übernimmt Schreibweise und Terminologie
  der Trainingsdaten erstaunlich gut. Nach 100 Epochen
  klingt es wie der Autor der Trainingsdaten.
 
✗ Wissen ist begrenzt
  Ohne breites Training fehlt Allgemeinwissen.
  Jede Frage wird zum Hammer, jedes Problem zum Nagel.
  Das Modell kann nicht über seine Daten hinauswachsen.
 
→ Praktische Konsequenz
  Für echte Anwendungen: RAG oder Fine-Tuning.
  Training from Scratch nur zum Lernen sinnvoll.
  Die großen Anbieter haben die Grundlagenarbeit
  bereits erledigt.
                

Die erste Erkenntnis: Training funktioniert. Es ist keine Raketenwissenschaft. Mit den richtigen Tools, ausreichend Daten und etwas Geduld kann jeder ein Sprachmodell trainieren. Die Mechanismen sind transparent, der Code ist verfügbar, die Hardware ist erschwinglich. Das Mysterium um KI-Training löst sich auf, wenn man es selbst durchführt.

Die zweite Erkenntnis: Stil wird gelernt. Das Modell hat nicht nur Fakten aus meinen Texten extrahiert, sondern auch die Art, wie ich schreibe. Die Satzlänge, die Wortwahl, die Gedankenführung. Das erklärt, warum Fine-Tuning so effektiv sein kann: Du kannst einem allgemeinen Modell Deinen spezifischen Stil beibringen, ohne das gesamte Weltwissen neu trainieren zu müssen.

Die dritte Erkenntnis: Wissen ist begrenzt. Ein Modell kann primär reproduzieren und rekombinieren, was es in den Trainingsdaten gesehen hat. Ohne breite Trainingsdaten fehlt das robuste Allgemeinwissen, das wir von einem guten Assistenten erwarten. Deshalb macht Training from Scratch für praktische Anwendungen selten Sinn. Die Grundlagenarbeit, das breite Weltwissen, haben andere bereits erledigt.

Die vierte Erkenntnis: Für echte Anwendungen gibt es bessere Wege. RAG gibt Dir Zugriff auf aktuelle Dokumente, ohne das Modell zu verändern. Fine-Tuning bringt dem Modell Deinen Stil bei, ohne das Weltwissen zu verlieren. Training from Scratch ist ein Lernprojekt, aber keine Produktionsstrategie.

Meine Lerneffekte aus diesem kleinen Experiment

Nach dem 100ten Linked-Beitrag, in dem erwachsene Menschen etwas von "Bewusstsein" halluziniert haben, ist mir einfach der Kragen geplatzt:

Spiritualität, Glaube, Esoterik, Trance - das sind alles wundervolle Domänen, die auch in meinem Leben große Rollen spielen. Aber ganz ehrlich: Ein LLM innerhalb eines KI-Systems ist einfach nur blanke Mathematik. Das ist soweit von Bewusstsein weg wie ClawdBot von einer verantwortungsvollen Software = Lichtjahre. :-)

Ein bisschen möchte ich Dich auch dazu ermutigen, mit dem Wissen zu experimentieren: Es hilft zu verstehen, warum große Modelle so gut funktionieren und warum es meistens sinnvoller ist, sie zu nutzen, statt das Rad neu zu erfinden.

Technisch ist ein eigenes LLM machbar, aber praktisch lohnt es sich fast nie, weil der Aufwand in keinem Verhältnis zum Nutzen steht. Die großen Anbieter haben bereits Milliarden investiert (und verbrennen sie gerade fröhlich in Hoffnung auf mehr Abos), um Modelle zu trainieren, die Sprache, Wissen und Reasoning auf einem Niveau beherrschen, das mit begrenzten Ressourcen nicht erreichbar ist.

Nimm ein gutes lokales Modell wie Llama, Mistral oder Qwen. Verbinde es mit Deinen Daten via RAG. Wenn nötig, passe es per Fine-Tuning an Deinen Stil an. Die Grundlagenarbeit ist erledigt, jetzt geht es darum, sie für Deine Zwecke zu nutzen. :-)

Danke für Deine wertvolle Zeit und dass Du das hier alles gelesen hast.

Ich freue mich natürlich sehr über Feedback,

Dein Karl