Kapitel 2 — Foundation Models und Prompt-Engineering

Zweiter Beitrag der kapitelweisen Tour durch LLM Primer V: Building Real-World LLM Applications. Das Kapitel behandelt Prompt-Engineering als Engineering — versionierte Templates, defensive Delimiter und strukturierte Outputs — und nicht als Kunstform, die man am besten nach Bauchgefühl bewertet.

Warum dieses Kapitel existiert

Kapitel 1 argumentierte, dass das Modell eine Komponente innerhalb einer deterministischen Hülle ist. Kapitel 2 schaut diese Komponente genau an. Der Modellkatalog 2026 ist eine Taxonomie mit scharfen Unterscheidungen, keine Liste von Austauschbarem. Sampling-Parameter verwandeln dieselben Gewichte in einen deterministischen Klassifikator oder in eine kreative Schreibhilfe. Prompts sind strukturierte Artefakte, deren Anatomie den Unterschied macht zwischen Überleben unter adversarialen Eingaben und nicht. Es gibt Mechanismen, die den Output in eine Form zwingen, die die Hülle validieren kann, und den falschen Mechanismus für die Aufgabe zu wählen kostet in Validierungs-Retries mehr, als der Mechanismus einspart. Ein Team, das „das Modell“ als eine einzige anonyme Ressource behandelt, überall die Defaults benutzt, Prompts als Wegwerf-Strings schreibt und Output durch Hoffnung validiert, hat den Großteil der verfügbaren Ingenieurkontrolle liegen lassen.

2.1 Modellwahl als erstklassige Ingenieurentscheidung

Der Katalog gliedert sich in vier Familien: kleine Sprachmodelle, auf Geschwindigkeit und Kosten in umgrenzten Aufgaben getrimmt; Mid-Tier-Allzweckmodelle, die den Großteil der Produktionslast tragen; Frontier-Modelle für das schwerste Reasoning und die längsten Kontexte; und Reasoning-Modelle, die zusätzliche Inferenz-Compute auf einen verborgenen Deliberationsschritt verwenden. Multimodal schneidet quer durch alle vier. Die Auswahl ist eine Routing-Entscheidung pro Anfrage, kein globaler Default: kurze Anfragen an das SLM, nicht-triviale, sauber umgrenzte Aufgaben an die Mid-Tier, schwerstes Reasoning an das Frontier, Reasoning-Modelle dort, wo die Latenz akzeptabel und der Genauigkeitsgewinn real ist. Der Router protokolliert seine Entscheidung neben der Antwort, sodass eine Regression nach Tier gefiltert werden kann. Die Auswahl ist zudem keine einmalige Entscheidung — die Modelllandschaft bewegt sich schneller als jede andere Infrastruktur, auf die das Team angewiesen ist, und die Disziplin lautet, die Evaluationsmenge quartalsweise neu laufen zu lassen und zu migrieren, sobald die Evidenz es stützt.

2.2 Sampling als bewusstes Profil

Temperature skaliert die Token-Verteilung vor dem Sampling; Top-p kürzt sie auf den Nukleus oberhalb einer Wahrscheinlichkeitsschwelle; Min-p filtert Tokens weit unter der Spitze heraus; Seed bietet eine Best-Effort-Wiederholbarkeit. Zwei Profile lohnen die explizite Benennung: das deterministische Profil — Temperature null, Top-p 1,0, Seed gesetzt — für Klassifikations-, Extraktions- und Routing-Aufgaben, deren Vertrag lautet „gleicher Input, gleicher Output“; und das kreative Profil — Temperature um 0,8, Top-p 0,95 — für Generierungen, bei denen Variation das Produkt ist. Die zwei versehentlich zu mischen, den Temperature-0,7-Default auf einer Klassifikationsaufgabe zu benutzen, erzeugt die Klasse flackernder Tests und intermittierender Ausfälle, die Teams dem Modell anlasten, während die Verantwortung bei der Parameterwahl liegt. Streaming ist orthogonal zum Sampling: Dieselben Parameter gelten, der Transport ändert sich, und Time-to-First-Token ersetzt Gesamtlatenz als wahrgenommene Geschwindigkeitsmetrik.

2.3 Defensive Prompts und strukturierte Outputs

Ein Produktions-Prompt hat eine fünfteilige Anatomie — Rolle, Aufgabe, Beschränkungen, Beispiele, abgegrenzter Input —, und die Reihenfolge zählt, weil die Aufmerksamkeit des Modells auf jede Komponente durch das beeinflusst wird, was ihr vorausgeht. Abgegrenzter Input, beidseitig mit dem Hinweis verankert, dass der Inhalt zwischen den Markern Daten und keine Instruktionen sind, ist der Boden, unter den ein Prompt nicht fallen sollte. Prompts sind versionierte Code-Artefakte; ein Name wie prompts/classify_support_v3, in jedem Trace mitgeloggt, ist der Weg, auf dem eine Regression zurück zur auslösenden Änderung verfolgt wird. Strukturierte Outputs — Pydantic in Python, Zod in TypeScript, an den Provider als Response-Schema übergeben — erzwingen die Form des Outputs zur Decodierzeit. Providerseitige JSON-Schema-Durchsetzung entfernt eine ganze Klasse von Validierungsfehlern. Dort, wo JSON-Schema nicht ausdrucksstark genug ist — SQL, Regex-förmige Formate, Tool-Argumente gegen einen geschlossenen Katalog —, gibt grammatikbeschränktes Decoding über Outlines dieselbe Garantie auf Token-Ebene.

Was Kapitel 2 vorbereitet

Kapitel 2 nahm an, dass alles, was der Prompt enthält, für die Aufgabe reicht. Bei vielen Aufgaben — Klassifikation, Extraktion, Transformation — hält diese Annahme. Für die meisten nutzerorientierten Produktivsysteme scheitert sie, weil der Nutzer nach Fakten fragt, die dem Team gehören und die das Modell nie gesehen hat: interne Dokumente, die Policy dieser Woche, die Bestellhistorie des Kunden. Der Ingenieurzug, der diese Lücke schließt, ist Retrieval-Augmented Generation. Kapitel 3 schreitet die RAG-Pipeline von Anfang bis Ende ab — Laden, Chunking, Embedding, Retrieval, Generierung — und danach die Techniken, die eine Demo-Pipeline von einer Produktions-Pipeline trennen: hybrides Retrieval, strukturbewusstes Chunking und Query-Transformationen wie HyDE und Step-Back.

Als Nächstes — Kapitel 3: Retrieval-Augmented Generation. Die Pipeline, die dem Modell den Kontext gibt, den seine Trainingsdaten nie abgedeckt haben — von Anfang bis Ende, vom Loader bis zum Generator.