01 — Was ist ein LLM?

Ein Large Language Model (LLM) ist ein neuronales Netz, das auf riesigen Textmengen trainiert wurde, um die statistische Wahrscheinlichkeit des nächsten Tokens (Wort-Fragments) vorherzusagen. Aus dieser scheinbar simplen Aufgabe emergiert die Fähigkeit zu Reasoning, Codegenerierung, Zusammenfassung, Übersetzung und mehr.

Token ≠ Wort. Ein Token ist ein Wort-Fragment (~3–4 Zeichen im Schnitt). „Künstliche Intelligenz“ sind ca. 5 Tokens. Das Modell sieht immer nur Token-Sequenzen — kein semantisches Verständnis im menschlichen Sinne, aber hocheffektive Mustererkennung über statistische Verteilungen.
Parameter
Gewichte im neuronalen Netz. GPT-4 hat geschätzt ~1,8 Billion, Llama 3 70B hat 70 Milliarden. Mehr Parameter = mehr Kapazität, aber auch mehr Rechenaufwand.
Training
Vorgang, bei dem das Modell Milliarden von Text-Beispielen sieht und seine Gewichte anpasst, um Token-Vorhersagen zu verbessern. Dauert Wochen bis Monate auf tausenden GPUs.
Inferenz
Das Erzeugen von Ausgaben zur Laufzeit — also das, was passiert, wenn eine Anfrage gestellt wird. Deutlich günstiger als Training, aber trotzdem rechenintensiv bei großen Modellen.
Context Window
Maximale Anzahl Tokens, die das Modell in einer Anfrage „sehen“ kann. GPT-4o: 128k, Claude 3.5: 200k, Llama 3: 128k. Alles außerhalb des Fensters ist für das Modell unsichtbar.
Temperature
Steuerparameter für Kreativität vs. Determinismus. Wert 0 = immer die wahrscheinlichste Antwort. Wert 1+ = mehr Variation. Für strukturierte Aufgaben (Extraktion, Code) besser nahe 0.
02 — Modell-Typen

Nicht alle KI-Modelle sind LLMs. Für Automatisierungsprojekte gibt es spezialisierte Typen, die für bestimmte Aufgaben besser geeignet sind als ein Allzweck-LLM.

LLM — Large Language Model

Allzweck-Sprachmodell

Text verstehen, generieren, umstrukturieren. Basis aller modernen Chat-Systeme. Beispiele: GPT-4, Claude, Llama, Mistral.

NER — Named Entity Recognition

Entitäts-Erkennung

Erkennt strukturierte Objekte in Text: Personen, Orte, Datumsangaben, Firmennamen, Vertragsnummern. Oft kleines spezialisiertes Modell, sehr schnell.

Classifier

Klassifikationsmodell

Ordnet Text einer von N Kategorien zu. Z.B. Sentiment, Dokumenttyp, Priorität. Kann auch mit LLM-Prompting simuliert werden.

Embedding Model

Vektor-Einbettung

Wandelt Text in numerische Vektoren um, die semantische Ähnlichkeit repräsentieren. Grundlage für RAG und Semantic Search.

VLM — Vision Language Model

Bild + Text

Versteht sowohl Bilder als auch Text. Für OCR, Dokumentenanalyse, Screenshot-Verarbeitung. Beispiele: GPT-4o, Claude 3, LLaVA.

ASR / TTS

Sprache ↔ Text

Automatic Speech Recognition (Whisper) und Text-to-Speech. Relevant für Spracheingabe und Sprachausgabe in Automatisierungssystemen.

SLM — Small Language Model

Kompakte Modelle

Phi-3, Gemma 2B, Qwen 1.5B — laufen auf CPU oder Consumer-GPU. Für einfache Routing-Aufgaben oder On-Device-Szenarien.

Reranker

Ergebnis-Ranker

Bewertet Dokument-Relevanz nach initialem Retrieval neu. Cross-Encoder-Architektur. Verbessert RAG-Qualität erheblich.

03 — Capability Levels

LLMs lassen sich grob in Leistungsklassen einteilen — relevant für Kostenplanung, Aufgabenverteilung und Architekturentscheidungen.

Level Beispiele Stärken Typischer Einsatz
Frontier Top GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro Komplexes Reasoning, langer Kontext, multimodal, Coding, Analyse Kernlogik, komplexe Workflow-Entscheidungen, Drafting
Mid-Tier Balanced Claude 3 Haiku, GPT-4o mini, Gemini Flash, Mistral Large Gutes Verhältnis Preis/Leistung, schnell, gut für strukturierte Tasks Standard-Routing, häufige einfache Anfragen, Bulk-Verarbeitung
Small / Local On-Prem Llama 3 8B, Mistral 7B, Phi-3 Mini, Qwen2 7B Läuft on-premise, keine Datenweitergabe, günstig bei Skalierung Datensouveränität, DSGVO-konforme Szenarien
Spezialisiert Task-Specific CodeLlama, MedLlama, FinGPT, Legal-BERT Auf Domäne optimiert, oft kleiner und effizienter als Allzweck-Modelle Optionale Spezialisierung je Branche
Praxis-Tipp

Ein intelligentes Automatisierungssystem kann als Model-Router fungieren: einfache Anfragen gehen an ein kleines lokales Modell (schnell, günstig), komplexe Anfragen werden an ein größeres Modell eskaliert. Das ist die Grundlage für ein kosteneffizientes, DSGVO-konformes Tier-System.

04 — RAG vs. Fine-Tuning

Eine der wichtigsten Architekturentscheidungen: Wann reicht es, dem Modell zur Laufzeit mehr Wissen mitzugeben — und wann muss das Modell neu trainiert werden?

Kontext erweitern (kein Training)

Das Basis-Modell bleibt unverändert. Wissen wird zur Laufzeit in den Prompt eingespeist — entweder direkt oder per Retrieval (RAG). Schnell, flexibel, kein GPU-Aufwand.

Modell trainieren / Fine-Tunen

Das Modell wird mit eigenen Daten weitertrainiert, sodass das Wissen in den Gewichten verankert ist. Aufwändig, kostspielig, aber für bestimmte Aufgaben notwendig.

Es gibt verschiedene Abstufungen — von „gar kein Training“ bis zu „Modell von Grund auf neu trainieren“:

PromptingSystem-Prompt + Beispiele
→
RAGRetrieval aus Wissensbasis
→
Fine-TuningLoRA / PEFT
→
Continued Pre-TrainingDomain-Adaption
→
From ScratchEigenes Basismodell
Methode Was wird verändert? Wann sinnvoll? Aufwand
System-Prompt Nichts — nur Kontext Immer als Erstes versuchen. Rolle, Regeln, Format vorgeben. Minimal
Few-Shot Prompting Nichts — nur Kontext Wenn Format/Stil konsistent sein muss. 3–10 Beispiele im Prompt. Minimal
RAG Nichts am Modell — externe Wissensbasis Wenn aktuelle/proprietäre Daten benötigt werden. Standard-Lösung für Enterprise. Mittel
Fine-Tuning (LoRA) Kleine Teilmenge der Gewichte Wenn Stil/Ton/Format konsistent sein muss, Prompting nicht reicht. Hoch
Full Fine-Tuning Alle Gewichte Selten notwendig. Wenn LoRA nicht ausreicht. Sehr Hoch
Pre-Training (Domain) Basiswissen des Modells Für stark spezialisierte Domänen (Medizin, Recht, Code) mit riesigen Textkorpora. Extrem
Wichtige Faustregel: Fine-Tuning ist kein Ersatz für RAG. Fine-Tuning lehrt das Modell wie es antworten soll — nicht was die aktuelle Antwort sein soll. Aktuelle Daten (Preislisten, Dokumente, Kundeninfos) gehören immer in RAG, nicht ins Training.
Empfehlung

Für den typischen Automatisierungs-Usecase (Dokumente verarbeiten, Formulare ausfüllen, internes Unternehmenswissen nutzen) ist RAG + System-Prompt der richtige Einstieg — kein Training notwendig. Fine-Tuning wird erst interessant, wenn konsistenter Ausgabe-Stil (z.B. Behördensprache, Branchenformat) erzwungen werden soll.

05 — RAG — Retrieval-Augmented Generation

RAG ist die Standardarchitektur für Enterprise-LLM-Systeme. Statt Wissen ins Modell zu trainieren, wird es zur Laufzeit aus einer Wissensbasis abgerufen und in den Kontext eingespeist.

Nutzeranfrage
→
Query EmbeddingText → Vektor
→
Vector SearchÄhnlichste Chunks
→
Prompt AssemblyFrage + Kontext
→
LLMAntwort generieren
→
Ausgabe
Chunking
Dokumente werden in kleine Textabschnitte (Chunks) aufgeteilt — typisch 200–800 Tokens. Chunk-Größe ist ein kritischer Parameter: zu groß = zu viel Rauschen, zu klein = fehlender Kontext.
Embedding
Jeder Chunk wird durch ein Embedding-Modell in einen hochdimensionalen Vektor umgewandelt. Semantisch ähnliche Texte liegen im Vektorraum nah beieinander.
Vector DB
Datenbank, die Vektoren speichert und effiziente Nearest-Neighbor-Suche erlaubt. Beispiele: Chroma, Qdrant, Weaviate, pgvector (PostgreSQL-Extension).
Reranking
Optionaler zweiter Schritt: Ein Cross-Encoder bewertet die N besten Retrieval-Ergebnisse nochmals auf Relevanz. Verbessert Qualität, erhöht aber Latenz.
Halluzination
LLMs „erfinden“ Fakten, wenn sie keine verlässliche Quelle im Kontext haben. RAG reduziert Halluzinationen erheblich, eliminiert sie aber nicht vollständig.
06 — Structured Output & Tool Use

Für Automatisierung entscheidend: LLMs können nicht nur Freitext ausgeben, sondern zuverlässig strukturierte Daten und Aktionen erzeugen.

JSON Mode
Das Modell gibt garantiert valides JSON aus. Basis für alle Integrationen, die strukturierte Daten erwarten (Formulare, API-Calls, Datenbank-Inserts).
Function Calling
Das Modell entscheidet, welche Tool-Funktion mit welchen Parametern aufgerufen werden soll. Kernmechanismus für LLM-Agents. Von allen großen Modellen unterstützt.
Chain-of-Thought
Modelle denken besser, wenn sie Zwischenschritte ausformulieren dürfen („Scratchpad“). Relevant für komplexe Routing-Entscheidungen.
Agentic Loop
Das Modell führt mehrere Tool-Calls in Sequenz aus, bis die Aufgabe erledigt ist. Basis für mehrstufige Automatisierungs-Workflows: Eingabe → Entscheidung → Aktion → Ergebnis → nächster Schritt.
07 — On-Premise LLMs

Für Unternehmen mit hohen Anforderungen an Datenschutz und Datensouveränität sind lokale Modelle zentral. Das bringt eigene Anforderungen mit sich.

Vorteile

Keine Datenweitergabe an Cloud-Anbieter. Vorhersagbare Latenz. Keine API-Kosten bei Skalierung. Betrieb ohne Internet möglich. Volle Kontrolle über Modellversion.

Herausforderungen

GPU-Hardware notwendig (oder CPU mit Abstrichen). Kleinere lokale Modelle haben Qualitätslücken zu Frontier-Modellen. Modell-Updates müssen manuell gehandhabt werden.

Ollama
Runtime/Server zum lokalen Betrieb von LLM-Modelldateien — kein eigenes Modell, sondern die Laufzeitumgebung, die Modelle wie Llama 3, Mistral oder Qwen über eine OpenAI-kompatible API bereitstellt.
llama.cpp / GGUF
CPU-optimierte Inferenz-Engine. GGUF ist das Standard-Format für quantisierte Modelle. Läuft ohne GPU, mit quantisierten Modellen (Q4_K_M) auf normaler Server-Hardware.
vLLM
Production-Grade GPU-Inferenz mit Paged Attention. Deutlich höherer Durchsatz als naive Inferenz. Sinnvoll wenn mehrere parallele Anfragen erwartet werden.
Hardwareanforderung
Faustregel: Modellgröße in GB ≈ Parameter × 2 (Float16) oder × 0.5 (Q4). Llama 3 8B Q4 ≈ 4,5 GB VRAM. Llama 3 70B Q4 ≈ 40 GB — braucht 2× A100 oder vergleichbar.
08 — Entscheidungsbaum: Welcher Ansatz?

Schnelle Orientierung für häufige Architekturentscheidungen:

Situation Empfehlung
Modell soll interne Dokumente kennen → RAG
Modell soll immer in bestimmtem Format antworten → System-Prompt + Few-Shot; wenn nicht ausreichend: Fine-Tuning
Datenschutz ist kritisch (DSGVO, Behörde) → On-Premise lokales Modell (Llama, Mistral)
Höchste Qualität, keine On-Prem-Pflicht → Frontier API (GPT-4o, Claude 3.5)
Viele strukturierte Felder aus Text extrahieren → LLM mit JSON Mode oder NER-Modell
Sehr einfache Klassifikation (Ja/Nein, Typ A/B) → Kleines Classifier-Modell oder GPT-4o mini
Komplexer mehrstufiger Workflow → Agentic Loop mit Tool Use
Latenz < 500ms notwendig → Kleine Modelle (Haiku, Flash, Phi-3) + Caching
09 — Bekannte Probleme bei LLMs

LLMs haben systematische Schwächen, die nicht durch bessere Prompts verschwinden. Wer mit Modellen produktiv arbeitet, muss diese kennen — und Architekturen bauen, die damit umgehen.

Lost-in-the-Middle
Das Modell gewichtet Informationen am Anfang und Ende des Kontexts stärker als in der Mitte. Bei sehr langen Dokumenten werden mittlere Abschnitte effektiv übersehen.
Attention: O(n²)
Standard-Transformer-Attention kostet O(n²) in Rechenzeit und Speicher relativ zur Kontextlänge. Ein 128k-Kontext ist nicht 4× so teuer wie 32k — sondern 16×.
Halluzinationen
Je mehr Text, desto mehr Möglichkeiten für das Modell, sich in widersprüchlichen Informationen zu verirren oder Details zu erfinden, die nicht im Kontext stehen.
Prompt Injection
Mehr Kontext = mehr Angriffsfläche. In langen Dokumenten können versteckte Instruktionen das Modellverhalten unbemerkt beeinflussen — besonders relevant für RAG mit externen Quellen.
Kein Gedächtnis
Das Modell liest den Kontext bei jeder Inferenz neu — es gibt kein persistentes Gedächtnis zwischen Turns. Was aus dem Fenster fällt, ist vollständig vergessen.
Garbage In
Ein langer Kontext mit irrelevanten Informationen schadet aktiv. Das Modell versucht, alles zu berücksichtigen — mehr Rauschen führt zu schlechteren Antworten als ein präziser kurzer Kontext.
10 — Glossar

Alphabetische Kurzreferenz aller zentralen Begriffe.

Agentic Loop
Wiederholter Zyklus aus LLM-Entscheidung → Tool-Aufruf → Ergebnis → nächste Entscheidung.
Chain-of-Thought
Technik, bei der das Modell Zwischenschritte explizit ausformuliert. Verbessert Reasoning-Qualität.
Chunking
Aufteilung von Dokumenten in kleinere Textabschnitte für RAG-Pipelines (typisch 200–800 Tokens).
Context Window
Maximale Anzahl Tokens, die ein Modell in einer Anfrage verarbeiten kann.
Embedding
Numerische Vektordarstellung von Text, die semantische Ähnlichkeit messbar macht.
Fine-Tuning
Weiteres Training eines Basis-Modells auf eigenen Daten.
Function Calling
Fähigkeit eines LLMs, strukturierte Aufrufe an externe Funktionen/Tools zu generieren.
GGUF
Dateiformat für quantisierte Modelle. Standard für CPU-Inferenz via llama.cpp und Ollama.
Halluzination
Phänomen, bei dem ein LLM plausibel klingende, aber faktisch falsche Informationen generiert.
JSON Mode
Betriebsmodus, in dem das Modell garantiert valides JSON ausgibt.
LLM
Large Language Model — großes neuronales Netz, trainiert auf Textvorhersage.
LoRA
Low-Rank Adaptation — parameter-effiziente Fine-Tuning-Methode.
NER
Named Entity Recognition — Erkennung von Entitäten (Personen, Orte, Daten) in Text.
Ollama
Runtime/Server zum lokalen Betrieb von LLMs über eine OpenAI-kompatible API.
Quantisierung
Komprimierung von Modellgewichten (z.B. Float32 → Int4) um Speicherbedarf zu reduzieren.
RAG
Retrieval-Augmented Generation — relevante Dokumente werden zur Laufzeit abgerufen und in den Prompt eingespeist.
Temperature
Steuerparameter für Ausgabe-Zufälligkeit. 0 = deterministisch, >1 = kreativ.
Token
Kleinste Verarbeitungseinheit eines LLMs — meist ein Wort-Fragment (~3–4 Zeichen).
Vector DB
Datenbank für Embedding-Vektoren mit effizienter Nearest-Neighbor-Suche.
VLM
Vision Language Model — verarbeitet sowohl Text als auch Bilder.
Häufige Fragen

Braucht mein Unternehmen Fine-Tuning?

In den meisten Fällen nicht. Für die große Mehrheit der Business-Anwendungen — Dokumentenverarbeitung, E-Mail-Analyse, Formularautomatisierung — reicht RAG + System-Prompt vollständig aus. Fine-Tuning wird erst relevant, wenn Sie einen sehr spezifischen Ausgabestil benötigen oder die Prompt-Länge zum Latenz-Problem wird.

Können LLMs on-premise DSGVO-konform betrieben werden?

Ja. Modelle wie Llama 3, Mistral und Qwen können vollständig lokal über Ollama oder vLLM betrieben werden. Es verlassen keine Daten das Unternehmensnetzwerk. Die Qualität lokaler Modelle liegt unter der von Frontier-Modellen, ist aber für viele strukturierte Aufgaben ausreichend — besonders in Kombination mit einem Model-Router, der komplexe Anfragen bei Bedarf eskaliert.

Was kostet der Betrieb eines LLM?

Das hängt vom Ansatz ab. Cloud-APIs berechnen pro Token (GPT-4o: ~5–15 USD pro Million Tokens). On-premise fallen einmalig Hardware-Kosten an (GPU-Server ab ca. 3.000 EUR für kleine Modelle), dafür keine laufenden API-Kosten. Für Unternehmen mit hohem Volumen wird On-Premise schnell kosteneffizient.