LLMs verstehen: Wie große Sprachmodelle funktionieren

LLMs verstehen: Wie große Sprachmodelle funktionieren

Große Sprachmodelle (Large Language Models, LLMs) stecken hinter ChatGPT, lokalen Assistenten und immer mehr Unternehmenssoftware. Dieser Artikel erklärt ohne Formel-Ballast, was diese Modelle eigentlich tun, wo ihre Grenzen liegen und wie man sie im Alltag richtig einsetzt.

Die Kernidee: Das nächste Wort vorhersagen

Ein LLM ist im Grunde ein extrem großer „Text-Vervollständiger": Es berechnet für eine Eingabe (Prompt) die Wahrscheinlichkeit des nächsten Tokens – eines Wort- oder Zeichenbausteins – und wählt dann eines aus. Diesen Schritt wiederholt es, bis ein Stoppzeichen erreicht ist. Aus dieser simplen Mechanik entsteht erstaunlich kohärenter Text, weil das Modell während des Trainings Milliarden von Textbeispielen gesehen und statistische Muster gelernt hat.

Zwei Begriffe sind zentral:

• Token: Die Bausteine, in die Text zerlegt wird (ein Wort kann 1–4 Tokens sein).
• Kontextfenster: Die Menge an Text, die das Modell gleichzeitig „sehen" kann – aktuell typisch 8.000 bis 200.000+ Tokens („Tokens" ist hier die Einheit, nicht Wörter).

Wie entsteht ein LLM? Drei Phasen

1. Pre-Training: Das Modell lernt auf riesigen Textmengen (Bücher, Web, Code) das nächste Token vorherzusagen. Das kostet enorme Rechenleistung (Wochen auf tausenden GPUs) und liefert das „Grundwissen" inklusive Grammatik und Weltwissen.
2. Fine-Tuning (SFT): Mit kuratierten Frage-Antwort-Paaren wird das Modell auf Dialogverhalten trainiert – es lernt, hilfreich zu antworten statt nur weiterzuschreiben.
3. RLHF/DPO: Durch Feedback von Menschen (oder Modellen) wird das Verhalten weiter ausgerichtet: hilfreicher, ehrlicher, harmloser.

Für eigene Anwendungen ist wichtig: Das Pre-Training ist unbezahlbar teuer, das Fine-Tuning aber machbar – mit modernen Methoden wie LoRA lassen sich Modelle mit vergleichsweise wenig GPU-Stunden auf eigene Domänen anpassen (siehe KI & Automatisierung).

Stärken und Grenzen

Stärken:

• Zusammenfassen, Umformulieren, Übersetzen – sehr zuverlässig.
• Code generieren und erklären, Shell-Befehle vorschlagen.
• Strukturierte Ausgaben (JSON, Tabellen) aus unstrukturiertem Text.
• Brainstorming, erste Entwürfe, Recherche-Unterstützung.

Grenzen (wichtig für den Alltag!):

• Halluzinationen: Das Modell erfindet plausible, aber falsche Fakten – besonders bei konkreten Zahlen, Versionen und Personen. Antworten zu fachlichen Details immer verifizieren!
• Kein echtes Verständnis: Das Modell hat keine Intentionalität; es optimiert nur Textwahrscheinlichkeiten.
• Veraltetes Wissen: Der Trainingsstand liegt in der Vergangenheit; aktuelle Ereignisse fehlen ohne zusätzliche Werkzeuge.
• Kontextfenster-Grenze: Bei sehr langen Dokumenten wird der Anfang „vergessen" – Chunking und Retrieval helfen (siehe RAG unten).

Modellgrößen und ihre Bedeutung

Modelle gibt es in vielen Größen – von ~1 Mrd. bis 400+ Mrd. Parametern. Faustregeln:

• Kleine Modelle (1–8B): laufen auf Consumer-GPUs und sogar CPUs; gut für einfache Aufgaben, Zusammenfassen, Klassifikation.
• Mittlere Modelle (8–30B): guter Kompromiss aus Qualität und Hardware-Anspruch; benötigen 16–24 GB VRAM (quantisiert).
• Große Modelle (70B+): beste Qualität, brauchen 48+ GB VRAM oder mehrere GPUs – oder Cloud-APIs.

Wichtig: Die Parameterzahl ist nur ein Faktor. Ein gut trainiertes 8B-Modell kann ein älteres 70B-Modell schlagen. Entscheidend sind Benchmarks auf den eigenen Aufgaben – und die Hardware-Frage: siehe CPU vs. GPU und VRAM-Dimensionierung.

Prompting: Die wichtigste Fähigkeit

Die Qualität der Antwort hängt stark vom Prompt ab. Vier Bausteine für bessere Ergebnisse:

1. Rolle und Kontext: „Du bist ein erfahrener Linux-Administrator…" – gibt dem Modell die Perspektive.
2. Klare Aufgabe: „Erkläre in 5 Bulletpoints, was systemd ist." – präzise statt vage.
3. Einschränkungen: „Nenne nur Befehle, die mit apt verfügbar sind." – verhindert Halluzinationen.
4. Gewünschtes Format: „Antworte als JSON mit den Feldern id und name." – erzwingt strukturierte Ausgabe.

Beispiel eines schlechten vs. guten Prompts:

Schlecht:  "Wie richte ich einen Server ein?"
Gut:       "Ich betreibe Debian 12. Gib mir eine Schritt-für-Schritt-Anleitung
            zur Ersteinrichtung: SSH-Härtung, Fail2ban, UFW-Firewall, Updates.
            Nur apt-Befehle, kurz und praxisnah."

RAG: Eigene Dokumente nutzbar machen

RAG (Retrieval-Augmented Generation) ist die Standard-Methode, um LLMs mit eigenem Wissen zu füttern, ohne das Modell zu trainieren: Dokumente werden in Chunks zerlegt, eingebettet (embeddings) und in einer Vektor-Datenbank gespeichert. Bei einer Frage sucht das System die passenden Chunks und reicht sie dem LLM als Kontext mit. Ergebnis: Das Modell antwortet auf Basis der eigenen Dokumente – und kann sogar die Quelle nennen. Detaillierte Anleitung: RAG-Wissensassistent aufbauen.

Lokale Modelle vs. Cloud-APIs

Viele Teams nutzen beides: Cloud für schwere Aufgaben, lokal für vertrauliche Daten und für Experimente. Die Abwägung Cloud vs. eigene Server vertieft der bestehende Artikel Cloud vs. eigene Server.

Quantisierung: Kleiner, schneller, fast so gut

Quantisierung reduziert die Präzision der Gewichte – von 16 Bit (FP16/BF16) auf 8, 4 oder sogar 2 Bit. Vorteile: Der Speicherbedarf sinkt drastisch (4-Bit = ~25 % von 16-Bit), die Inference wird schneller. Nachteil: ein leichter Qualitätsverlust, der bei guten Modellen oft kaum messbar ist. Praktische Größenordnung für ein 7B-Modell:

Tools: llama.cpp nutzt GGUF-Dateien (mit llama-quantize erzeugbar), GPTQ und AWQ sind Formate für GPU-Beschleunigung (vLLM, ExLlama). Faustregel: Für lokale Modelle Q4/Q5 wählen – bester Kompromiss aus Qualität und Hardware-Anspruch.

Embeddings und Vektor-Datenbanken

Neben generativen LLMs gibt es Embedding-Modelle: Sie wandeln Text in Zahlenvektoren um, sodass ähnliche Texte ähnliche Vektoren bekommen. Darauf bauen Vektor-Datenbanken (z.B. Chroma, Qdrant, pgvector):

# Konzept: Text → Vektor → Suche
"Der Server ist ausgefallen"  → [0.12, 0.87, -0.34, ...]
"Der Server läuft wieder"     → [0.11, 0.85, -0.31, ...]  (sehr ähnlich)

# Suche: Vektor der Frage berechnen,
# dann die n ähnlichsten Chunks per Kosinus-Ähnlichkeit finden

Diese Technik ist das Herzstück von RAG (Retrieval-Augmented Generation): Dokumente werden eingebettet, bei einer Frage sucht das System die passenden Textstellen und gibt sie dem LLM als Kontext. So entstehen Wissensassistenten, die auf eigenen Unterlagen basieren und sogar Quellen nennen – praktisch aufgebaut im Artikel RAG-Wissensassistent aufbauen.

Fazit

LLMs sind leistungsfähige Textwerkzeuge – keine allwissenden Systeme. Wer versteht, dass sie Wahrscheinlichkeiten statt Fakten produzieren, sie mit klaren Prompts steuert und kritische Aussagen verifiziert, bekommt enormen Nutzen. Die praktische Anwendung in Agenten und Automatisierungen zeigt der Artikel KI-Agenten in der Praxis.

Verwandte Artikel: KI & Automatisierung · CPU vs. GPU · Python für Einsteiger