Kapitel 1 — Die Disziplin des KI-Engineerings
Erster Beitrag der kapitelweisen Tour durch LLM Primer V: Building Real-World LLM Applications. Das Kapitel argumentiert, dass der Grund, warum dein Demo funktioniert und dein Produktivsystem nicht, kein Modellproblem ist — es ist ein Ingenieurproblem, und das Engineering hat einen Namen.
Warum dieses Kapitel existiert
Jedes Team, das ein LLM-Feature ausliefert, entdeckt dieselbe Lücke. Das Demo läuft sauber auf den zwanzig Inputs, die das Team ausgewählt hat; das Produktivsystem läuft schlecht auf den zwanzigtausend Inputs, die es nie sieht. Das Modell ist nicht schlechter geworden. Das Team hat die Region verlassen, in der ein plausibler Single-Shot-Output als Erfolg zählt, und die Region von Last, Drift, adversarialen Eingaben und zahlenden Kundinnen betreten, deren Beschwerde-Metrik unerbittlich ist. Kapitel 1 benennt diese Region und gibt ihr eine Disziplin. KI-Engineering ist nicht die Wissenschaft vom Training des Modells und nicht die Kunst, einen cleveren Prompt zu schreiben. Es ist das Engineering deterministischen Systemverhaltens um einen probabilistischen Kern. Der Rest des Buchs schreitet die Flächen ab, an denen diese Disziplin lebt; dieses Kapitel ist der Rahmen.
1.1 Die Zuverlässigkeitslücke zwischen Demo und Produktion
Ein Demo und ein Produktivsystem sehen im Architekturdiagramm identisch aus. Sie unterscheiden sich in Last, in der Tail-Verteilung der Inputs, im Latenzbudget, im Kostendruck und im Fehlermodus. Der dominierende Unterschied ist statistisch: Ein Demo läuft handverlesene Dutzende Inputs, während ein Produktivsystem Millionen gegen den Long Tail läuft — Anfragen, die seltsam formuliert sind, teilweise in einer anderen Sprache stehen, Kontext vermissen lassen oder absichtlich adversarial sind. Zuverlässigkeit ist eine Frage der Tails, nicht der Mittelwerte. Darauf gestapelt ist das Modell selbst nichtdeterministisch — Sampling, providerseitiges Load-Balancing und stille Modell-Updates überlagern sich alle —, und die Fehler sind leise. Eine falsche Antwort parst sauber, erfüllt jede Typprüfung, die das Team geschrieben hat, und erreicht den Nutzer ohne Alarm. Klassische Observability, die HTTP-200er zählt, kann diesen Fehlermodus nicht sehen. Der erste Schritt des Teams ist zu erkennen, dass Wiederholbarkeit, Korrektheit und Kosten Ingenieureigenschaften sind, die konstruiert werden müssen, keine Annahmen, die vom klassischen Stack geerbt werden können.
1.2 Die deterministische Hülle um den probabilistischen Kern
Die architektonische Antwort lautet, das Modell probabilistisch zu lassen und es in klassischer Software zu umhüllen. Die Hülle besitzt Input-Form, Output-Form, Validierung, Retries, Fallbacks, Caching, Observability und Kostenbuchhaltung. Von außen präsentiert sie sich als deterministische Funktion — eine Anfrage kommt herein, eine validierte Antwort geht hinaus. Innen enthält sie eine probabilistische Komponente, die mit Timeout, Schema und einem Wiederherstellungsplan für den Fall aufgerufen wird, dass das Modell Unsinn zurückgibt. Die Hülle hat vier Bänder: Input-Validierung, Prompt-Vorbereitung, Ausführung unter Vertrag und Recovery-und-Emission. Erst nachdem alle vier bestanden sind, wird die Antwort zum offiziellen Output der Hülle. Die wiederkehrende Versuchung besteht darin, Logik zurück in das Modell zu schieben — „lass das Modell seine eigene Antwort prüfen“ —, und jeder Schritt in diese Richtung ist ein Schritt weg von Testbarkeit. Die Disziplin lautet, den probabilistischen Kern klein, wohldefiniert und eingegrenzt zu halten und so viel Systemverhalten wie möglich in deterministischem Code zu behalten, den das Team versionieren und durchdenken kann.
1.3 Die fünf Säulen: Zuverlässigkeit, Qualität, Performance, Kosten, Evolution
Kapitel 1 schreitet fünf Ingenieurhaltungen ab, die in jedem Produktivsystem wiederkehren. Zuverlässigkeit entsteht durch Redundanz: Retries mit exponentiellem Backoff, Fallback-Ketten, die von einem günstigen Primärmodell zu einem stärkeren Sekundärmodell zu einem regelbasierten Default gehen, Multi-Provider-Abstraktion und Circuit Breaker, die einen strauchelnden Provider davon abhalten, die Kaskade auszulösen. Qualität entsteht durch Validierung auf zwei Ebenen: Schema-Validierung fängt Formfehler, und Inhaltsvalidierung — Groundedness-Checks, Konfidenzschwellen, Guardrail-Prüfungen — fängt semantische Fehler, die das Schema passieren. Performance entsteht durch Caching in drei Schichten: exakter Match, semantisch und Prompt-Präfix. Kostenkontrolle entsteht durch Messung und Attribution, durch das Routing von Traffic zum kleinsten hinreichenden Modell, durch Budgets pro Nutzer und pro Anfrage, die eine Agentenschleife daran hindern, tausend Dollar leise zu verbrennen, und durch Prompt-Ökonomie. Evolution entsteht aus den fünf Rückkopplungsschleifen — Logging, Evaluation, Tracing, menschliches Feedback und Canary-Rollout —, die zu einem Kreislauf verschaltet sind, in dem ein Produktions-Trace zu einem Eval-Fall wird, eine Eval-Regression ein Deploy blockiert und das System Monat für Monat besser wird.
Was Kapitel 1 vorbereitet
Der Rest des Buchs ist die Hülle, eine Schicht nach der anderen. Kapitel 2 geht in den Modellaufruf selbst hinein — Modell-Tiering, Sampling-Parameter, defensive Prompts und strukturierte Outputs. Kapitel 3 erweitert nach außen um Retrieval, damit das Modell den richtigen Kontext zum Nachdenken hat. Kapitel 4 verwandelt die Hülle in einen Agenten, der Werkzeuge aufrufen kann. Kapitel 5 und 6 fügen die Evaluations- und Observability-Schienen hinzu. Kapitel 7 und 8 schließen mit Sicherheit und der Ökonomie des Servings. Der Rahmen von Kapitel 1 macht jedes spätere Kapitel lesbar: Jede Technik ist entweder ein Weg, die Hülle enger zu ziehen, oder ein Weg, den probabilistischen Kern darin leichter umhüllbar zu machen.
Als Nächstes — Kapitel 2: Foundation Models und Prompt-Engineering. Die Schicht innerhalb der Hülle — Modellwahl, Sampling, Prompts und strukturierte Outputs — behandelt als Ingenieurflächen statt als Kunst.
