Kapitel 8 — LLMs in Anwendungen einsetzen
Dies ist Teil 8 einer Serie, die LLM Primer I: How Generative AI Works durchgeht. Gestern haben wir Embeddings, RAG und Multimodalität behandelt. Heute schauen wir, wie LLMs wirklich in ausgelieferten Produkten auftauchen — die Muster, die funktionieren, die, die es nicht tun, und die neue Welle agentischer Systeme, in denen das Modell der Fahrer ist.
Ein Chatbot ist nicht nur ein Modell
Der häufigste Fehler, den Leute bei Chatbots machen, ist zu denken, das Modell sei das Produkt. Ist es nicht. Das Modell ist eine Komponente. Das Produkt ist das System, das das Modell umschließt: Prompt-Templates, Verwaltung der Konversationshistorie, Sicherheitsfilter, Retrieval-Schichten, Tool-Integrationen, Fallback-Policies, Nutzerschnittstelle.
Der größte Teil des Engineering-Aufwands in einem produktiven Chatbot fließt in das umgebende System, nicht in das Modell. Ein gut entwickelter Chatbot mit einem Mid-Tier-Modell schlägt meist einen schlecht entwickelten Chatbot mit einem Frontier-Modell. Das Buch geht die architektonischen Muster durch, die tatsächlich funktionieren, einschließlich wie man Konversationszustand verwaltet, wann man alte Turns zusammenfasst gegenüber wörtlich behält, und wie man Sicherheitskontrollen schichtet.
Zusammenfassung und Suche
Zwei der wirkungsvollsten LLM-Anwendungsfälle drehen sich beide ums Verdichten von Information. Zusammenfassung verkleinert langen Text in eine kürzere Version unter Bewahrung der Bedeutung. Semantische Suche findet relevantes Material in einem großen Korpus durch Absicht statt durch Schlüsselwörter.
Das interessante moderne Muster ist, beides zu kombinieren. Ein Nutzer stellt eine Frage. Das System ruft relevante Dokumente ab. Das Modell fasst das abgerufene Material in einer fokussierten Antwort zusammen. Das ist, was die meisten "KI-Suche"-Produkte unter der Haube tatsächlich machen. Wenn es funktioniert, fühlt es sich magisch an. Wenn es scheitert, liegt es fast immer daran, dass der Retrieval-Schritt das relevante Material verpasst hat, nicht daran, dass das Modell es nicht zusammenfassen konnte.
Codegenerierung
Programmiersprachen sind formale Sprachen mit strikter Grammatik und klarem Feedback. Das macht sie besonders gut geeignet für LLMs. Ein Modell, das große Mengen Code gesehen hat, lernt Vervollständigungen vorherzusagen, die kompilieren, Funktionssignaturen, die zu Konventionen passen, und Idiome, die dem umgebenden Code ähneln.
Moderne Code-Assistenten sind eine besondere Art von RAG-System: Sie rufen relevanten Kontext aus dem bearbeiteten Codebase ab und füttern ihn dem Modell zusammen mit der Anfrage des Nutzers. Das Modell ist darin wirklich gut. Das Buch ist realistisch sowohl über den Vorteil (echte Produktivitätsgewinne bei gut abgegrenzten Aufgaben) als auch über den Nachteil (subtile Korrektheitsprobleme, die in flüssig aussehendem Code schwer zu erkennen sind).
Wissensextraktion
Das Gegenteil von Schreiben ist Lesen. Wissensextraktion ist das Muster, bei dem du dem Modell ein unstrukturiertes Dokument gibst und es bittest, strukturierte Daten zu produzieren — extrahiere Rechnungsnummer, Datum und Summe aus dieser PDF; extrahiere die Berufsgeschichte des Kandidaten aus diesem Lebenslauf; identifiziere die in dieser Arbeit erwähnten chemischen Verbindungen.
Das ist eine der unmittelbar nützlichsten geschäftlichen Anwendungen von LLMs, und sie ist relativ sicher, weil die Ausgabe gegen ein Schema validiert werden kann. Das Buch zeigt, wie man den Prompt und die Validierungsschicht zusammen entwirft, sodass fehlerhafte Modellausgaben gefangen und erneut versucht werden, statt nachgelagerte Systeme stillschweigend zu beschädigen.
Evaluation, in Produktion
Weil LLM-Ausgaben probabilistisch sind, kannst du sie nicht so testen, wie du deterministische Software testest. Es gibt selten eine einzige richtige Antwort zum Vergleich. Evaluation mischt mehrere Techniken: automatisierte Metriken wo möglich, Scoring durch ein stärkeres Modell, strukturierte menschliche Reviews, A/B-Tests in Produktion und kontinuierliches Monitoring auf Drift.
Dieser Abschnitt führt auch die benannten Benchmarks ein, die überall in der LLM-Forschung und in Produktankündigungen auftauchen: MMLU, GPQA-Diamond, HumanEval, SWE-bench, MMMU, LiveBench, GSM8K, MATH, ARC-AGI, BFCL, IFEval. Das Buch enthält eine Ein-Absatz-Referenz für jeden, damit du jeden Modellvergleich lesen kannst und weißt, was wirklich gemessen wird.
Das neue Muster: agentische Systeme
Dieser Abschnitt ist in der Ausgabe 2026 neu, denn das ist, wo sich das Feld am schnellsten bewegt hat. In einem agentischen System sitzt das Modell am Steuer. Statt nur Text zu produzieren, entscheidet es, wann ein Taschenrechner aufgerufen wird, wann eine Datenbank abgefragt wird, wann ein Suchwerkzeug aufgerufen wird, wann eine klärende Frage gestellt wird — und was mit den Ergebnissen zu tun ist.
Der Mechanismus ist strukturiertes Tool-Calling. Jedes verfügbare Tool wird dem Modell als Funktionssignatur beschrieben, mit Beschreibung und Schema für seine Argumente. Das Modell kann einen strukturierten Tool-Aufruf statt einfacher Prosa ausgeben. Das umgebende System parst den Aufruf, führt das Tool aus, liefert das Ergebnis zurück, und das Modell entscheidet, was als Nächstes zu tun ist. Die Schleife läuft, bis das Modell die Aufgabe für abgeschlossen erklärt.
Dieses Muster wirft neue Engineering-Bedenken auf, die das Buch ernst nimmt. Agentische Schleifen können Ressourcen unvorhersehbar verbrauchen. Tool-Fehler propagieren in das Modellverhalten. Sicherheitsbedenken sind verstärkt, weil das Modell jetzt auf die Welt einwirkt statt sie nur zu beschreiben. Das Buch zeigt, wie man Tool-Inventare entwirft, schrittweise Korrektheit evaluiert und ausufernde Schleifen eindämmt.
Was Kapitel 8 vorbereitet
Am Ende von Kapitel 8 hast du ein praktisches Playbook für die wichtigsten LLM-Anwendungsmuster. Du weißt, welche Art von System du für welche Art von Problem bauen solltest, wie Evaluation in jedem Fall aussieht und wie du die Benchmark-Zahlen liest, die Anbieter über ihre Modelle veröffentlichen. Das nächste Kapitel macht den naheliegenden nächsten Schritt: Was kostet es, das alles im großen Maßstab zu betreiben?
Als Nächstes — Kapitel 9: Leistung, Skalierung und Kosten. Morgen schauen wir auf die operativen Realitäten. Latenz, Throughput, Kosten pro Anfrage, Quantisierung, On-Device-Deployment und wie du über Modellgröße nachdenkst, wenn der größte Teil deines Geschäfts gar nicht vom größten verfügbaren Modell profitieren würde.