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 du eine Anfrage stellst. 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 Alfred-relevante Workflows 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 (positiv/negativ), 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. Beispiel: text-embedding-3.
👁️
VLM — Vision Language Model
Bild + Text
Versteht sowohl Bilder als auch Text. Für OCR, Dokumentenanalyse mit Bildern, Screenshot-Verarbeitung. Beispiele: GPT-4o, Claude 3, LLaVA.
🔊
ASR / TTS
Sprache ↔ Text
Automatic Speech Recognition (Whisper) und Text-to-Speech. Für Alfred: Receptor-Modul für Spracheingabe oder Actuator-Modul für Sprachausgabe.
⚡
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 relevant.
🔍
Reranker
Ergebnis-Ranker
Bewertet Dokument-Relevanz nach initialem Retrieval neu. Cross-Encoder-Architektur. Verbessert RAG-Qualität erheblich, aber mit Latenz-Kosten.
03 — Capability Levels
LLMs lassen sich grob in Leistungsklassen einteilen — relevant für Kostenplanung, Aufgabenverteilung und Architekturentscheidungen in Alfred.
| Level |
Beispiele |
Stärken |
Einsatz in Alfred |
| Frontier Top |
GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro |
Komplexes Reasoning, langer Kontext, multimodal, Coding, Analyse |
Cortex-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 |
Primär für Alfred DMZ-Deployment — Datensouveränität |
| Spezialisiert Task-Specific |
CodeLlama, MedLlama, FinGPT, Legal-BERT |
Auf Domäne optimiert, oft kleiner und effizienter als Allzweck-Modelle |
Optionale Spezialisierung je Branche/Usecase |
Alfred — Architektur-Implikation
Alfred's Cortex 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 — Kontext erweitern vs. Modell trainieren
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":
Prompting
System-Prompt + paar Beispiele
→
RAG
Retrieval aus Wissensbasis
→
Fine-Tuning
LoRA / PEFT auf eigenen Daten
→
Continued Pre-Training
Domain-Adaption (viel Text)
→
From Scratch
Eigenes 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, viele gelabelte Beispiele vorhanden. |
Hoch |
| Full Fine-Tuning |
Alle Gewichte |
Selten notwendig. Wenn LoRA nicht ausreicht und spezifisches Verhalten tief eingebettet sein muss. |
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.
Alfred — Empfehlung
Für den typischen Alfred-Usecase (Dokumente verarbeiten, Formulare ausfüllen, intern wissen was im Unternehmen gilt) 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 oder Latenz durch lange Prompts ein Problem wird.
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.
Frage des Users
Receptor
→
Query Embedding
Text → Vektor
→
Vector Search
Ähnlichste Chunks
→
Prompt Assembly
Frage + Kontext
→
LLM (Cortex)
Antwort generieren
→
Actuator
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 — Warum ist Modell A besser als Modell B?
„Besser" ist immer aufgabenrelativ. Die Zahl im Modellnamen bezeichnet die Parametergröße in Milliarden (B = Billion/Milliarden):
ein 7B-Modell hat 7 Milliarden trainierbare Gewichte, ein 70B-Modell hat 70 Milliarden. Mehr Parameter bedeutet mehr Kapazität — aber nicht automatisch bessere
Ergebnisse
für jeden Anwendungsfall. Ein spezialisiertes 7B-Modell kann bei spezifischen Coding-Tasks ein 70B-Modell schlagen. Diese Faktoren bestimmen die Eignung:
Trainings-Datenmix
Was das Modell „gelesen" hat, bestimmt seine Stärken. Code-lastige Pre-Training-Daten → besseres Coding. Viel multilingualer Text → bessere nicht-englische
Sprachen.
Instruction Tuning / RLHF
Nach dem Pre-Training werden Modelle auf Instruktionen optimiert (SFT) und durch menschliches Feedback verfeinert (RLHF/DPO). Das bestimmt, wie „hilfreich" und
sicher das Modell auf Anfragen reagiert.
Modellgröße & Architektur
Mehr Parameter = mehr Kapazität für komplexes Reasoning. Aber: Architekturen wie Mixture-of-Experts (MoE) erlauben große Kapazität bei geringerer Inferenz-Last.
Context Window
Langer Kontext ist nicht gratis: Modelle mit 128k-Kontext verlieren oft Qualität bei sehr langen Eingaben (Lost-in-the-Middle-Problem). Die tatsächlich nutzbare
Länge ist oft kürzer.
Quantisierung
Für On-Premise: Modell-Gewichte werden von Float32 auf Int4/Int8 komprimiert. Spart 4–8× Speicher, geringe Qualitätseinbuße. Llama in GGUF-Format ist der Standard
für CPU-Inferenz.
Benchmark-Vorsicht
MMLU, HumanEval, GSM8K usw. messen spezifische Fähigkeiten. Hohe Benchmark-Scores ≠ gut für deinen Usecase. Immer mit eigenen, repräsentativen Beispielen
evaluieren.
07 — Structured Output & Tool Use
Für Alfred entscheidend: LLMs können nicht nur Freitext ausgeben, sondern zuverlässig strukturierte Daten und Aktionen.
JSON Mode
Das Modell gibt garantiert valides JSON aus. Basis für alle Actuator-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. OpenAI-Standard,
mittlerweile von allen großen Modellen unterstützt.
Tool Use
Anthropics Bezeichnung für dasselbe Konzept. Das Modell kann aus einem Set von Tools wählen und strukturierte Aufrufe generieren — Grundlage für
Alfred's Actuator-Layer.
Chain-of-Thought
Modelle denken besser, wenn sie Zwischenschritte ausformulieren dürfen („Scratchpad"). Relevant für komplexe Routing-Entscheidungen im Cortex.
Agentic Loop
Das Modell führt mehrere Tool-Calls in Sequenz aus, bis die Aufgabe erledigt ist. Basis für Alfred-Workflows: Receptor → Cortex entscheidet → Actuator
handelt → Ergebnis zurück → ggf. nächster Schritt.
Alfred — Cortex als Orchestrator
Alfred's Cortex ist ein Agentic Loop: Er empfängt den Intent (aus Receptor), wählt via Function Calling die richtigen Actuatoren, führt
sie in der richtigen Reihenfolge aus und gibt das Ergebnis zurück. Die Stärke liegt darin, dass der Cortex diese Entscheidung dynamisch trifft — kein starres Flowchart,
sondern LLM-gesteuertes Routing.
08 — On-Premise LLMs — Besonderheiten
Für Alfred's Kernversprechen (DSGVO, DMZ, Datensouveränität) sind lokale Modelle zentral. Das bringt eigene Anforderungen:
Vorteile
Keine Datenweitergabe an Cloud-Anbieter. Predictable 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. Läuft auf Mac/Linux/Windows. Alfred nutzt Ollama als Default-Backend für lokale Modelle.
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
normalem 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 (für Float16) oder × 0.5 (für Q4). Llama 3 8B Q4 ≈ 4,5 GB VRAM. Llama 3 70B Q4 ≈ 40 GB — braucht 2× A100
oder vergleichbar.
09 — Entscheidungsbaum: Welcher Ansatz?
Schnelle Orientierung für häufige Architekturentscheidungen:
| Situation |
Empfehlung |
| Modell soll interne Dokumente kennen |
→ RAG aufbauen, kein Fine-Tuning |
| 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 im Cortex |
| Latenz < 500ms notwendig |
→ Kleine Modelle (Haiku, Flash, Phi-3) + Caching |
10 — 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, statt sie zu ignorieren.
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×.
Latenz × Kontext
Auch mit modernen Optimierungen (Flash Attention, KV-Cache): je mehr Tokens im Kontext,
desto länger die Time-to-First-Token. Kritisch für interaktive Anwendungen.
KV-Cache-Speicher
Jeder Token im Kontext braucht einen Eintrag im Key-Value-Cache. Bei langen Kontexten
wird der GPU-VRAM-Bedarf schnell zum Flaschenhals — on-premise besonders relevant.
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.
Die Wahrscheinlichkeit steigt mit der Kontextlänge.
Präzisionsverlust
Wenn dasselbe Konzept mehrfach im Kontext auftaucht (z.B. in verschiedenen Dokumenten),
verliert das Modell den Überblick darüber, welche Quelle maßgeblich ist.
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.
Kontext ≠ Arbeitsgedächtnis.
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.
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.
11 — Überforderung bei komplexen Aufgaben
Kann man ein Modell, das einen größeren Plan verfolgen soll, mit vielen
Zwischenaufgaben genauso überwirren wie einen Menschen?
Ja — und es ist strukturell ähnlicher als man denkt.
Das Kernproblem heißt Context Pollution: je mehr Zwischenschritte,
Teilergebnisse und Zwischenfehler sich im Kontext ansammeln, desto mehr Lärm muss das
Modell bei jedem neuen Schritt durchfiltern. Es gibt kein echtes Arbeitsgedächtnis,
das selektiv vergisst — alles bleibt gleichwertig im Fenster liegen.
Fehlerfortpflanzung
Macht das Modell in Schritt 3 einen Fehler und baut Schritt 7 darauf auf, verstärkt
sich der Fehler. Ein Mensch merkt irgendwann „warte mal, da war was falsch" —
das Modell nicht ohne expliziten Check.
Zieldrift
Bei sehr langen Ketten verliert das Modell das ursprüngliche Ziel aus den
Augen und optimiert lokal für den letzten Schritt. Der Gesamtplan wird zur Nebensache.
Instruktionskonflikte
Wenn frühere Teilaufgaben-Ergebnisse mit dem ursprünglichen System-Prompt in Konflikt
geraten, ist unklar was gewinnt. Oft gewinnt das Nächste, nicht das Wichtigere.
Tool-Call-Lawinen
In Agentic Loops kann das Modell anfangen, Tools unnötig oft aufzurufen um „sicher zu gehen",
was den Kontext weiter aufbläht — ein Teufelskreis.
Der Unterschied zum Menschen: Ein Mensch wird müde, frustriert,
verliert Motivation — aber er kann aktiv priorisieren, zusammenfassen und Irrelevantes
wegschieben. Das Modell macht das nicht automatisch — es sei denn, man baut genau
diese Mechanismen explizit ein.
Was dagegen hilft: Regelmäßige Zwischenzusammenfassungen die den
Kontext komprimieren. Explizite „Was ist noch das Ziel?"-Checks nach N Schritten.
Aufteilen in kleinere unabhängige Sub-Agents statt einem langen Loop. Klare
Abbruchbedingungen.
Für Alfred ist das direkt relevant: der Cortex braucht bei komplexen Workflows entweder
ein State-Management das den Kontext bewusst schlank hält — oder große
Aufgaben werden in diskrete, abgeschlossene Teilaufträge mit sauberen Übergaben aufgeteilt.
12 — Dokumentenanalyse: Vom Bild zur Struktur
OCR allein liefert flachen Text — eine Wortsuppe ohne Struktur. Um aus einem
gescannten Formular zuverlässig Daten zu extrahieren, braucht es Techniken, die
das visuelle Layout verstehen, bevor der Text interpretiert wird.
Diese Disziplinen sind etabliert und gut erforscht.
Document Layout Analysis (DLA)
Erkennt und klassifiziert Regionen eines Dokuments: Überschriften,
Absätze, Tabellen, Formularfelder, Kopf-/Fußzeilen. Ausgabe: Bounding Boxes mit
Typbezeichnung. DLA ist der erste Schritt jeder strukturierten Dokumentenverarbeitung —
bevor man Daten extrahiert, muss man wissen, wo Felder, Tabellen und Text sind.
Moderne Ansätze nutzen YOLO-basierte Detektoren oder multimodale Transformer.
Tools: Surya (Layout-Modell mit 15 Kategorien), DocLayout-YOLO, Docling (IBM).
Key-Value Pair Extraction (KVP)
Identifiziert Beschriftung-Wert-Paare auf Formularen — z.B. „Name: Maria Schneider"
oder ein Feldlabel neben/über seinem handschriftlichen Wert. Die Herausforderung:
Labels und Werte können nebeneinander, übereinander oder durch Linien getrennt stehen.
Moderne Ansätze nutzen Layout-aware Transformer (LayoutLM-Familie), die Text-Tokens
mit ihren 2D-Koordinaten verknüpfen und so räumliche Zuordnung lernen.
Tools: LayoutLMv3 (Microsoft, nicht kommerziell nutzbar), LiLT (sprachunabhängig).
Table Structure Recognition (TSR)
Versteht die interne Struktur einer erkannten Tabelle: Zeilen, Spalten,
Zellgrenzen, überspannende Zellen, Kopfzeilen. Ohne TSR ist OCR-Text aus einer Tabelle
eine ungeordnete Textsequenz ohne Zeilen-/Spalten-Zuordnung. Besonders schwierig:
Tabellen ohne sichtbare Linien.
Tools: Surya (Table Recognition), Table Transformer (Microsoft).
Vision Language Models (VLMs)
Verarbeiten das Dokumentbild direkt statt über den Umweg OCR-Text.
Pionier: Donut (ECCV 2022) — ein Swin-Transformer-Encoder liest das Bild,
ein BART-Decoder gibt strukturierten Text aus, komplett OCR-frei. Vorteil: keine
OCR-Fehlerkette. Für Prototyping und kleine Mengen kann ein großes VLM (Qwen2.5-VL,
InternVL3) Felder ohne Training extrahieren. Für Produktion bieten feingetuntete
Modelle wie LayoutLMv3 oder Donut mehr Kontrolle.
Tools: Donut, DocTR (Mindee), Qwen2.5-VL.
Document Segmentation
Verwandt mit DLA, aber auf Pixelebene — jeder Pixel bekommt ein
Klassen-Label (Text, Tabelle, Bild, Hintergrund). Präziser als Bounding Boxes für
unregelmäßige Layouts. Für Standard-Geschäftsformulare reicht DLA mit Bounding Boxes
in der Regel aus.
NER im Dokumentenkontext
Named Entity Recognition arbeitet downstream von OCR: erst wird Text
extrahiert, dann werden Entitäten klassifiziert (Personenname, Datum, Adresse, Betrag).
NER ergänzt KVP: KVP sagt wo ein Wert steht, NER sagt was der Wert
semantisch ist. Zusammen ermöglichen sie Validierung — ein „Geburtsdatum"-Feld sollte
ein Datum enthalten, keinen Geldbetrag.
Die typische Pipeline: Dokumentbild → DLA (Regionen finden) →
OCR pro Region (Text lesen) → KVP (Labels und Werte zuordnen) → NER (Entitäten
klassifizieren) → strukturierte Ausgabe (JSON). VLMs können mehrere dieser Schritte
in einem Modellaufruf zusammenfassen — auf Kosten von Kontrolle und Debugbarkeit.
13 — Glossar
Alphabetische Kurzreferenz aller zentralen Begriffe dieser Seite.
Agentic Loop
Wiederholter Zyklus aus LLM-Entscheidung → Tool-Aufruf → Ergebnis → nächste Entscheidung, bis eine Aufgabe abgeschlossen ist.
ASR
Automatic Speech Recognition — Sprache zu Text. Beispiel: OpenAI Whisper.
Chain-of-Thought
Technik, bei der das Modell Zwischenschritte explizit ausformuliert, bevor es eine Antwort gibt. Verbessert Reasoning-Qualität deutlich.
Chunking
Aufteilung von Dokumenten in kleinere Textabschnitte für die Vektorisierung in RAG-Pipelines (typisch 200–800 Tokens).
Classifier
Modell, das Text einer vordefinierten Kategorie zuordnet (z.B. Dokumenttyp, Sentiment, Priorität).
Context Pollution
Akkumulation von Zwischenergebnissen, Fehlern und irrelevantem Text im Kontext, die die Modellqualität bei mehrstufigen Aufgaben systematisch
verschlechtert.
Context Window
Maximale Anzahl Tokens, die ein Modell in einer einzigen Anfrage verarbeiten kann. Alles darüber hinaus ist unsichtbar.
DLA
Document Layout Analysis — Erkennung und Klassifikation von Dokumentregionen (Überschriften, Tabellen, Formularfelder) mittels Bounding Boxes. Erster
Schritt der strukturierten Dokumentenverarbeitung.
Donut
OCR-freies Vision-Language-Modell (ECCV 2022). Liest Dokumentbilder direkt und gibt strukturierten Text aus, ohne separaten OCR-Schritt.
DPO
Direct Preference Optimization — Alternative zu RLHF für Alignment-Training, ohne separates Reward-Modell.
Embedding
Numerische Vektordarstellung von Text, die semantische Ähnlichkeit messbar macht. Basis für RAG und Semantic Search.
Few-Shot Prompting
Mitgabe von 3–10 Beispielen im Prompt, um das gewünschte Ausgabeformat oder -stil zu demonstrieren — ohne Training.
Fine-Tuning
Weiteres Training eines Basis-Modells auf eigenen Daten, um Stil, Format oder domänenspezifisches Verhalten anzupassen.
Frontier Model
Modelle an der Leistungsgrenze des aktuell Möglichen: GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro.
Function Calling
Fähigkeit eines LLMs, strukturierte Aufrufe an externe Funktionen/Tools zu generieren — Kernmechanismus für Agents.
Flash Attention
Optimierter Attention-Algorithmus, der die O(n²)-Speicherkosten durch geschicktes Tiling auf GPU-SRAM reduziert. Standard in modernen
Inferenz-Engines.
GGUF
Dateiformat für quantisierte Modelle (Nachfolger von GGML). Standard für CPU-Inferenz via llama.cpp und Ollama.
Halluzination
Phänomen, bei dem ein LLM plausibel klingende, aber faktisch falsche Informationen generiert, weil es keine verlässliche Quelle im Kontext hat.
Inferenz
Das Erzeugen einer Ausgabe durch das Modell zur Laufzeit (im Gegensatz zum Training). Jede Anfrage ist ein Inferenz-Vorgang.
Garbage In, Garbage Out
Irrelevante oder verrauschte Informationen im Kontext verschlechtern die Ausgabequalität aktiv — ein kürzerer, präziser Kontext ist besser als ein
langer, ungefilteter.
DocTR
Open-Source OCR-Engine von Mindee. Texterkennung + Textlokalisation. Häufig als OCR-Frontend für LayoutLM-basierte Pipelines verwendet.
JSON Mode
Betriebsmodus, in dem das Modell garantiert valides JSON ausgibt — Basis für strukturierte Actuator-Integrationen.
KV-Cache
Key-Value-Cache — speichert bereits berechnete Attention-Daten für vorherige Tokens, damit sie bei jedem neuen Token nicht neu berechnet werden
müssen. VRAM-intensiv bei langen Kontexten.
llama.cpp
CPU-optimierte Open-Source-Inferenz-Engine für quantisierte LLMs. Ermöglicht Betrieb ohne GPU auf Standard-Hardware.
LLM
Large Language Model — großes neuronales Netz, trainiert auf Textvorhersage, aus dem Sprach- und Reasoning-Fähigkeiten emergieren.
LayoutLMv3
Multimodaler Transformer von Microsoft für Document AI. Fusioniert Text-Tokens mit 2D-Layoutpositionen und Bildinformationen. Kann für Key-Value Pair
Extraction feingetunt werden. Nicht kommerziell nutzbar (CC BY-NC-SA 4.0).
LoRA
Low-Rank Adaptation — Parameter-effiziente Fine-Tuning-Methode, die nur kleine Adapter-Matrizen trainiert statt aller Gewichte.
Lost-in-the-Middle
Beobachtung, dass Modelle Informationen in der Mitte eines langen Kontexts schlechter verarbeiten als am Anfang oder Ende.
MoE
Mixture of Experts — Architektur, bei der verschiedene Teilnetzwerke (Experten) für verschiedene Eingaben aktiviert werden. Ermöglicht große
Kapazität bei geringerer Rechenkosten pro Token.
NER
Named Entity Recognition — Erkennung von Entitäten (Personen, Orte, Daten, Firmennamen) in Text. Oft spezialisiertes, kleines Modell.
Ollama
Runtime/Server zum lokalen Betrieb von LLM-Modelldateien (kein eigenes Modell). Stellt Modelle wie Llama, Mistral, Qwen über eine OpenAI-kompatible
API bereit. Alfred-Standard-Backend.
Parameter
Gewichte im neuronalen Netz. Anzahl der Parameter bestimmt Kapazität und Rechenaufwand des Modells (z.B. 7B, 70B, 405B).
PEFT
Parameter-Efficient Fine-Tuning — Oberbegriff für Methoden wie LoRA, die nur einen Bruchteil der Gewichte trainieren.
Pre-Training
Erstes Training eines Modells auf riesigen Textkorpora zur Grundlagenwissens-Vermittlung. Dauert Wochen bis Monate auf tausenden GPUs.
Prompt Injection
Angriffstechnik, bei der versteckte Instruktionen in Nutzereingaben oder externen Dokumenten das Modellverhalten manipulieren. Risiko steigt mit der
Kontextlänge.
KVP Extraction
Key-Value Pair Extraction — Erkennung von Beschriftung-Wert-Paaren auf Formularen. Nutzt räumliche Zuordnung (welcher Wert gehört zu welchem Label?)
mittels Layout-aware Modellen.
Quantisierung
Komprimierung von Modellgewichten (z.B. Float32 → Int4), um Speicherbedarf zu reduzieren. Q4_K_M ist ein gängiger Kompromiss.
RAG
Retrieval-Augmented Generation — Architekturmuster, bei dem relevante Dokumente zur Laufzeit abgerufen und in den Prompt eingespeist werden.
Reranker
Modell, das nach einem initialen Retrieval-Schritt die Ergebnisse nach Relevanz neu bewertet (Cross-Encoder-Architektur).
RLHF
Reinforcement Learning from Human Feedback — Training-Methode, bei der menschliche Präferenz-Signale das Modellverhalten formen.
SFT
Supervised Fine-Tuning — Erster Schritt des Instruction-Tunings, bei dem das Modell auf gelabelte Instruktions-Antwort-Paare trainiert wird.
SLM
Small Language Model — kompakte Modelle (1–7B Parameter), die auf CPU oder Consumer-GPU laufen. Für einfache Aufgaben on-premise.
System-Prompt
Instruktionen, die vor der eigentlichen Nutzeranfrage eingespeist werden, um Rolle, Regeln und Format des Modells zu definieren.
Temperature
Steuerparameter für Ausgabe-Zufälligkeit. Wert 0 = deterministisch/vorhersagbar. Wert >1 = kreativ/variabel.
TSR
Table Structure Recognition — Erkennung der internen Tabellenstruktur (Zeilen, Spalten, Zellgrenzen). Notwendig, damit OCR-Text aus Tabellen den
richtigen Zellen zugeordnet wird.
Token
Kleinste Verarbeitungseinheit eines LLMs — meist ein Wort-Fragment (~3–4 Zeichen). LLMs sehen und erzeugen ausschließlich Token-Sequenzen.
Tool Use
Anthropics Bezeichnung für Function Calling — das Modell wählt aus einem Set von Tools und generiert strukturierte Aufrufe.
Vector DB
Datenbank für Embedding-Vektoren mit effizienter Nearest-Neighbor-Suche. Beispiele: Qdrant, Chroma, Weaviate, pgvector.
VLM
Vision Language Model — verarbeitet sowohl Text als auch Bilder. Für OCR, Dokumentenanalyse mit Bildinhalten relevant.
vLLM
Production-Grade GPU-Inferenz-Framework mit Paged Attention für hohen Durchsatz bei parallelen Anfragen.