ki-buch/teil-01-grundlagen/kapitel-02-technische-funktionsweise-llms.md

Kapitel 2: Technische Funktionsweise von LLMs – Detaillierte Erklärung

Teil I · Grundlagen – Large Language Models und Kontext verstehen

---

Auffrischung – überspringbar. Wenn Context Window, Token-Budget und „Host kompiliert den Prompt“ für dich sitzen, weiter zu Kapitel 3.

Viele Agenten-Probleme sind keine Modell-Probleme: Das Modell „sieht“ nie dein Repo, deine CI oder dein Ticket – es sieht nur den Prompt, den der Host zusammengestellt hat. Wer Tokens, Context Window und Sampling als Magie behandelt, steuert Kosten, Latenz und Fehlerquellen blind. Wer sie als Betriebsphysik versteht, kann Working Sets, Tool-Results und RAG als knappe Ressourcen managen.

These: Das Context Window ist Arbeitsspeicher, keine Festplatte. Der Host ist der eigentliche Prompt-Compiler; RAG ist eine Beschaffungsstrategie unter anderen – und reicht allein nicht für Live-State und Aktionen.

Leitfrage: Was sieht das Modell wirklich – und was bedeutet das für Kosten, Latenz und Agenten-Design?

Dieses Kapitel liefert die technische Grundlage, ohne in Transformer-Forschung abzugleiten: Tokenisierung und Next-Token-Vorhersage, Attention-Intuition, autoregressive Generierung, Sampling und Structured Output, Window-Budget und Host-Assemblierung. Die Bridge zu späteren Kapiteln: Warum Window und RAG allein keine Coding Agents tragen – der MCP-Deep-Dive folgt bewusst erst in Kapitel 4.7. Kapitel 3 baut darauf die Grenzen und Context Engineering als Disziplin.

Lernziele

Nach diesem Kapitel kannst du:

• erklären, wie aus Text Tokens werden und warum Tokenisierung Kosten und Limits bestimmt,
• Self-Attention und autoregressive Generierung so weit nutzen, dass du Latenz und Kontextlänge grob ableiten kannst,
• das Context Window als knappes Budget managen statt als unendlichen Speicher missverstehen,
• Sampling-Parameter und Structured Output praxisnah einsetzen,
• beschreiben, wie Hosts aus Systemprompt, Historie und Tool-Results den finalen Modell-Kontext bauen,
• RAG-Grenzen für Software-Agenten benennen und begründen, warum Live-State und Aktionen eine Capability-Schicht brauchen (Vertiefung: Kap. 4).

---

2.1 Token, Embedding und die Vorhersage des nächsten Tokens

Was das Modell wirklich „sieht“

Large Language Models lesen keinen Text so wie Menschen. Der Host (bzw. das Serving-System) zerlegt Eingaben mit einem Tokenizer in Tokens – Untereinheiten, die Worte, Wortteile, Satzzeichen oder auch häufige Strings (z. B. </div>, ==) sein können.

Dasselbe Wort kann je nach Tokenizer und Kontext unterschiedlich zerlegt werden. Deshalb sind „Wörter“ eine schlechte Kosteneinheit; Tokens sind die Währung für Limits und Preise.

"""
Minimalbeispiel: Token-Zählung mit tiktoken (OpenAI-ähnliche Encoder).
Installation: pip install tiktoken
"""

import tiktoken

enc = tiktoken.get_encoding("cl100k_base")
text = "async def fetch_user(id: str) -> User:"
tokens = enc.encode(text)

print(len(tokens))          # Anzahl Tokens
print(tokens[:8])           # Token-IDs
print([enc.decode([t]) for t in tokens])

Analogie: Tokens sind wie Pakete in einem Netzwerkprotokoll. Das Modell denkt in Paket-IDs, nicht in Buchstaben. Wenn dein „kleines“ JSON durch Escaping und Wiederholung explodiert, explodiert dein Budget.

Vom Token zum Vektor

Jede Token-ID wird auf einen Embedding-Vektor abgebildet – eine Liste von Zahlen, die Position und (erlerntes) „Ähnlichkeitsnachbarschaft“ im Raum kodiert. Zusätzlich fließen Positionsinformationen ein, damit „der Test schlägt fehl“ und „fehl schlägt der Test“ nicht identisch wirken.

Autoregression: ein Token nach dem anderen

Generierung ist typischerweise autoregressiv:

1. Kontext-Tokens gehen ins Modell.
2. Das Modell erzeugt eine Wahrscheinlichkeitsverteilung über das nächste Token.
3. Ein Token wird gewählt (Sampling, siehe 2.4).
4. Dieses Token wird an den Kontext angehängt.
5. Wiederhole bis Stopp-Kriterium (End-Token, max length, structured stop).

{ width=100% }

Konsequenzen für Agenten:

• Lange Antworten = viele sequenzielle Schritte = Latenz.
• Jedes Tool-Result, das du zurückschreibst, wird Teil des Kontexts der nächsten Vorhersagen.
• Fehler im frühen Token können den Rest „auf die schiefe Bahn“ ziehen (Compounding).

---

2.2 Attention und der Transformer-Block – Intuition für Praktiker

Self-Attention in einem Satz

Self-Attention erlaubt jedem Token, eine gewichtete Summe von Informationen aus anderen Token der Sequenz zu bilden. Das Modell lernt (über Query/Key/Value-Projektionen), worauf es achten soll: z. B. auf den Funktionsnamen, wenn es Parameter füllt, oder auf die Fehlermeldung, wenn es einen Fix vorschlägt.

Du musst die Matrizen nicht herleiten können, um Architekturentscheidungen zu treffen. Merke dir:

• Attention ist kontextabhängig und inhaltsadressierbar – ideal für „finde die relevante Stelle im Prompt“.
• Der Aufwand wächst mit der Sequenzlänge spürbar (klassisch grob quadratisch in der Attention; Implementations und Architekturen mildern das, eliminieren Kosten aber nicht).
• Längerer Kontext ≠ linear bessere Qualität. Aufmerksamkeit und „Lost in the Middle“-Effekte sind reale Praxisphänomene: Wichtiges in der Mitte riesiger Windows geht unter.

Stacks, Schichten, Residual Paths

Ein Transformer-Block kombiniert Attention mit Feed-Forward-Netzen, Normalisierung und Residuen. Viele Blöcke hintereinander bilden das Modell. Tiefe und Breite bestimmen Kapazität – und Serving-Kosten.

KV-Cache: warum Prefill und Decode unterschiedlich teuer sind

Beim Generieren speichern Serving-Stacks oft Key/Value-Zustände bereits gesehener Token (KV-Cache). Dadurch muss nicht bei jedem neuen Token die gesamte Historie naiv neu „von null“ teuer berechnet werden – aber der Cache verbraucht GPU-Memory proportional zur Kontextlänge und Batch-Größe.

Praxis:

• Ein stabiler, wiederverwendbarer Systemprompt kann je nach Stack cache-freundlich sein.
• Permanent wechselnde, riesige RAG-Dumps zerstören Cache-Effizienz und Geld.
• Agent-Loops mit wachsender Trace-Historie werden teurer – Summarization und Truncation sind Engineering, kein Nice-to-have.

---

2.3 Das Context Window: Arbeitsspeicher, nicht Festplatte

Hard Limits und Soft Realität

Das Context Window ist die maximale Menge an Tokens, die Modell + Serving in einem Forward-Pass-Kontext berücksichtigen (Input + bislang generierte Output-Tokens, je nach API-Zählung). Marketing-Zahlen („200k“, „1M“) sind Kapazitäten, keine Empfehlungen, sie vollzumüllen.

Zusätzliche Constraints:

Faktor	Effekt
Preis	Input- und Output-Tokens kosten
Latenz	lange Prefills, großer KV-Cache
Qualität	Signal-to-Noise sinkt
Stabilität	mehr Platz für Prompt-Injection und irrelevante Pfade
Privacy	mehr Daten im Prompt = größere Expositionsfläche

Analogie: Das Context Window ist RAM. MCP-Server, Vektordatenbanken und Git sind Festplatten bzw. Services. Gute Systeme laden Seiten bei Bedarf, statt die ganze Festplatte in den RAM zu mappen.

{ width=100% }

Anti-Pattern: Context Stuffing

„Wir geben dem Agenten einfach das ganze Repo“ scheitert an Größe, Geheimnissen, Rauschen und Kosten. Selbst wenn es technisch passt, sinkt die Treffsicherheit.

Besser: gezielte Ausschnitte (betroffene Dateien, Interfaces, Fehlerkontext), plus die Fähigkeit, nachzuladen.

---

2.4 Sampling und Steuerbarkeit

Temperature, Top-p und Co.

Nach den Logits entscheidet die Decoding-Strategie, welches Token als Nächstes kommt:

• Greedy / niedrige Temperature: deterministischer, oft besser für Code und Faktenformate; kann in Wiederholungen stecken.
• Höhere Temperature / Top-p (Nucleus): diverser, kreativer – riskanter für Syntax und APIs.
• Seed (wo unterstützt): Reproduzierbarkeit annähernd, selten absolut über alle Stacks.

Für Coding Agents gilt grob:

Aufgabe	Tendenz
Refactor nach Spec, JSON, Patches	niedrige Temperature, strict schema
Ideation, Namensfindung, Architekturoptionen	moderate Temperature
Sicherheitssensitive Ops	ohnehin Tool-Policy + Human-in-the-loop, nicht nur Sampling

Bridge zu Agenten: In einer Tool-Schleife multipliziert sich Sampling-Rauschen über Steps. Deshalb steuerst du Stabilität vor allem über Schemas, Verify-Orakel und max_steps – Sampling ist Feintuning, kein Ersatz für Harness und Context Policy (Kap. 3–4).

Structured Output

Viele APIs erzwingen JSON-Schemas oder Grammatiken (z. B. über response_format / structured outputs). Das reduziert Parse-Fehler dramatisch – ersetzt aber keine semantische Korrektheit. Ein schema-valides { "path": "../.env", "action": "delete" } ist trotzdem eine Katastrophe, wenn die Policy es zulässt.

Pitfall: Determinismus-Mythos. Selbst Temperature 0 ist über Provider, Batching und Implementationen hinweg nicht immer bitidentisch. Tests gegen Agenten brauchen tolerante Orakel (Verhalten, nicht exakten String).

---

2.5 System Prompt, Messages und Tool Results als Kontext

Der Host ist der eigentliche Prompt-Compiler

Das LLM sieht am Ende eine vom Host zusammengesetzte Sicht der Welt. Typische Schichten:

1. System-/Developer-Instructions – Rolle, Policies, Ausgabeformate
2. Stabile Projekt-Konventionen – Style, Architekturgrenzen
3. Dynamischer Task-Kontext – Issue, User-Query, Akzeptanzkriterien
4. Arbeitsartefakte – Dateien, Diffs, Suchtreffer
5. Tool-Definitionen – was darf aufgerufen werden
6. Tool-Results / Observations – was die Welt zurückgab
7. Assistenten-Zwischenschritte – Pläne, CoT (je nach Produkt sichtbar oder nicht)

{ width=100% }

Message-Rollen sind Architektur

Wenn Tool-Results als normale User-Messages „geschmuggelt“ werden, verwischt die Grenze zwischen Mensch und Maschine – und Prompt-Injection wird leichter. Saubere Hosts markieren Tool-Ausgaben klar und wenden Trust-Level an: Tool-Output ist Daten, keine Anweisungen (soweit erzwingbar).

# Konzeptuelle Message-Liste eines Tool-Turns
messages = [
    {"role": "system", "content": "Du bist ein Coding-Agent. Folge den Repo-Regeln."},
    {"role": "user", "content": "Fixe den roten Test in tests/test_billing.py"},
    {
        "role": "assistant",
        "content": None,
        "tool_calls": [
            {"id": "1", "function": {"name": "read_file", "arguments": '{"path": "tests/test_billing.py"}'}}
        ],
    },
    {
        "role": "tool",
        "tool_call_id": "1",
        "content": "def test_invoice():\n    assert total == 42\n",
    },
]

Diese Struktur ist die Brücke zu Agenten: Observe → Reason → Act wird zur Message-Historie.

---

2.6 Moderne Kontext-Provisionierung jenseits des reinen Context Windows

Reines Window-Management skaliert nicht mit Unternehmensrealität. In der Praxis greifen Teams zu Retrieval (RAG und Verwandte) und – sobald Live-State, Aktionen und mehrere Hosts dazukommen – zu einer standardisierten Capability-Schicht. Beide lösen überlappende, aber nicht identische Probleme; die Protokoll-Details folgen in Kapitel 4.

---

2.6.1 Retrieval-Augmented Generation (RAG) – Grenzen und Weiterentwicklung

Grundidee

Statt alles zu speichern oder zu hoffen, dass das Modell es „weiß“, holst du zur Query passende Dokumentstücke und legst sie in den Prompt.

Klassische Pipeline:

{ width=100% }

Was RAG gut kann

• Unternehmensdokumentation, Wikis, ADRs
• semi-statisches Wissen mit klarer Textform
• Reduktion von Halluzinationen über vorhandene Quellen (wenn Zitation erzwungen wird)

Grenzen, die in Agenten schmerzhaft werden

Grenze	Bedeutung für Software-Agenten
Chunking-Artefakte	Interfaces und Aufrufer liegen in verschiedenen Chunks
Ranking-Fehler	falsche Datei, richtiger Stil → überzeugender Unsinn
Aktualität	Index hinkt Git hinterher
Keine Aktionen	RAG liest, es ändert keinen CI-Stand
Live-State	„Ist der Job grün?“ ist kein Embedding-Problem allein
Schreibpfade	Fixes brauchen Tools, nicht nur Textfunduren
Context Bloat	k=20 große Chunks = Rauschen

Weiterentwicklungen (2024–2026)

• Agentic RAG: das Modell reformuliert Queries, holt mehrstufig nach
• GraphRAG / Code Graphs: Struktur (Calls, Module, Dependencies) statt reiner Vektor-Ähnlichkeit
• Hybrid Search: BM25 + Vectors + Metadata-Filter (lang:ts, service:billing)
• Re-Ranking: Cross-Encoder oder LLM-seitig „brauch ich diesen Chunk?“
• Citations & Grounding Checks: Antwort muss Spans referenzieren

All das verbessert Lesekontext. Es ersetzt nicht die standardisierte Handlungs- und Live-Kontext-Schicht.

Best Practice: Nutze RAG/Graph-Retrieval als eine Resource-Quelle hinter einem MCP-Server – nicht als paralleles Universum mit eigener Host-Logik pro IDE.

---

2.6.2 Bridge: Warum Window + RAG für Agenten nicht reichen

Function Calling standardisiert, wie ein Modell einen Aufruf äußert – meist innerhalb einer Vendor-API. Es standardisiert nicht, wie eine beliebige AI-Anwendung Unternehmensfähigkeiten entdeckt, autorisiert, versioniert und über mehrere Hosts wiederverwendet.

Für Coding Agents fehlen Window und RAG allein an drei Stellen:

Lücke	Warum es weh tut	Was Architektur braucht
Live-State	CI, Branch, Issue-Status sind kein Embedding-Problem	lesbare, aktuelle Quellen on-demand
Aktionen	Fixes, PRs, Testläufe sind Mutationen	Tools mit Policy und Verify
Portabilität	N Hosts × M Adapter	gemeinsame Capability-Schicht

MCP (Model Context Protocol) ist 2025/26 der prominenteste offene Ansatz für genau diese Integrationsachse: Hosts sprechen mit Fähigkeits-Servern über standardisierte Tools, Resources und Prompts. Die USB-C-Analogie und der vollständige Architektur-Deep-Dive (Host–Client–Server, Lifecycle, Transports, wann MCP nicht) stehen in Kapitel 4.7 – einmal kanonisch, ohne Doppelung hier.

Hybrid-Faustregeln (Details und Bau: Kap. 4, 10):

• statisches/semantisches Wissen → Retrieval/Graph (gern als Resource hinter einem Server),
• Live-State und Mutationen → Tools,
• wiederkehrende Workflows → kuratierte Prompts/Skills,
• portable Schicht, wenn mehr als ein Host oder Team andocken soll.

{ width=100% }

Abbildung: Context-Zyklus mit Capability-Schicht – Vertiefung in Kap. 4.7.

---

Best Practices

1. Budgetiere Tokens wie Performance-Budgets: harte Obergrenzen pro Kategorie (Historie, Diff, Docs, Tools).
2. Lade on-demand: erst Fehlerkontext und Signaturen, dann bei Bedarf Dateien nachziehen.
3. Halte Tool-Oberflächen klein und scharf – lieber 8 klare Tools als 80 unklare.
4. Trenne Read und Write konzeptionell; schreibende Tools strenger absichern (Kap. 4, 11).
5. Logge Context Decisions (was wurde warum geladen) – unverzichtbar für Debugging.
6. Behandle RAG als eine Beschaffungsstrategie, nicht als Religion – Live-State braucht andere Pfade (Kap. 4).

---

Pitfalls

Pitfall	Folge	Gegenmaßnahme	Kapitel-Querverweis
1M-Window als Strategie	Kosten, Rauschen, Injection-Fläche	Selektion + on-demand Loading	Kap. 2.3, 3
Alle Docs in jeden Turn	Cache-Miss, Latenz	Metadata-Filter, Re-Rank, Summaries	Kap. 2.6
Tools ohne Sandbox	Datenverlust, Security Incidents	Least Privilege, Human Approval	Kap. 11
Tool-Results als vertrauenswürdige Instructions	Indirect Prompt Injection	Hardening, Delimiter, Policy	Kap. 11
Host-spezifische Einmal-Plugins	N×M, Lock-in	portable Capability-Schicht	Kap. 4.7
RAG-Index ≠ Git-HEAD	Fixes für toten Code	commit-aware Indexing / live read	Kap. 2.6
Zu viele Tool-Schemas im Prompt	Bloat, falsche Auswahl	dynamische Teilmengen, Routing	Kap. 4–5

---

Key Takeaways

• LLMs generieren autoregressiv Token für Token; Tokenizer und Window bestimmen Kosten und Grenzen.
• Attention macht langen Kontext nutzbar – aber nicht beliebig effizient oder zuverlässig.
• Das Context Window ist RAM, keine Wissensdatenbank; Hosts kompilieren den Prompt aus vielen Quellen. (Kanonische Stelle dieser Metapher.)
• Sampling steuert Diversität; Structured Output steuert Format, nicht Wahrheit.
• RAG löst Retrieval von Wissen; für Live-State, Aktionen und Portabilität braucht es eine Capability-Schicht (kanonisch: Kap. 4.7).
• Für Coding Agents zählen Budgetierung, on-demand Loading und klare Trust Boundaries – bevor man das nächste Frontier-Modell jagt.

---

Was als Nächstes kommt

Kapitel 3 vertieft Fähigkeiten und Grenzen von LLMs und führt Context Engineering als eigene Disziplin aus. Kapitel 4 definiert Agent und Harness und liefert den MCP-Deep-Dive inklusive wann nicht.

---

Übungsanregungen

1. Aufgabe: Miss die Token-Zahl eures typischen „Bugfix-Prompts“ (Stacktrace + Datei + Guidelines).
   DoD: ☐ on-demand-Variante skizziert · Zeit: ~15 Min

2. Aufgabe: Protokolliere einen Agent-Lauf und markiere jede Message als System / User / Tool / Excerpt.
   DoD: ☐ eine Bloat-Stelle benannt · Zeit: ~20 Min

3. Aufgabe: Nimm einen internen Adapter (Jira/Git) und skizziere 3 Tools + 3 lesbare Quellen (noch ohne SDK).
   DoD: ☐ Portabilitätsnutzen in einem Satz · Zeit: ~20 Min
   (Server-Bau und FastMCP: Kap. 10.)