Kapitel 12 — Dein eigenes LLM-System bauen
Dies ist Teil 12 — der letzte Beitrag dieser Serie, die LLM Primer I: How Generative AI Works durchgeht. Gestern haben wir die Forschungsfront abgedeckt. Heute schließen wir mit dem ab, was es braucht, um tatsächlich mit diesen Systemen zu bauen — von "ich verstehe, was ein LLM ist" zu "ich liefere eines in Produktion".
Der Blick von oben
Wenn du dieses Kapitel erreichst, hast du elf Kapitel damit verbracht, die konzeptionelle Maschinerie aufzubauen. Du verstehst Wahrscheinlichkeit über Tokens. Du verstehst die Transformer-Architektur. Du verstehst Training, Adaption, Retrieval, Anwendungen, Kosten, Sicherheit und die Spitzenforschung. Kapitel 12 ist, wo all das zu einem Stack wird — das integrierte Bild eines LLM-Systems, wie es in der echten Welt ausgeliefert wird.
Das ist das Kapitel, in dem das Buch aufhört, ein Lehrbuch zu sein, und zu einer Referenz für Builder wird. Wenn du den Rest gelesen hast, wirst du dafür bereit sein.
Datensätze, und die rechtliche Schicht
Die meisten Einführungen zur LLM-Entwicklung nehmen an, dass die Daten bereits existieren. In der Praxis ist die Datensatzwahl, wo viele ernsthafte Projekte beginnen und enden. Worauf du trainierst, formt, was das Modell tun kann. Worauf du trainieren darfst, formt, ob du überhaupt ausliefern kannst.
Die rechtliche und ethische Landschaft rund um Trainingsdaten hat sich in den letzten Jahren verschärft. Provenienz, Lizenzierung, Opt-out-Compliance, Datenschutzregulierungen und Urheberrecht interagieren auf Weisen, die nicht viel bedeuteten, als das Feld klein und akademisch war. Jetzt bedeuten sie enorm viel. Das Buch geht durch, worüber man nachdenken sollte — nicht als Rechtsberatung, sondern als die Engineering-Realität, mit der jeder, der Modelltraining ernst nimmt, navigieren muss.
Trainings-Pipelines
Wenn du trainierst statt zu kaufen, ist die Trainings-Pipeline der Großteil der Arbeit. Das Buch geht sie als Fließband durch: Sammlung, Bereinigung, Deduplikation, Tokenisierung, der eigentliche Trainingslauf, Checkpointing, Evaluation und Deployment. Jede Station hat ihre eigenen Werkzeuge, ihre eigenen Fehlermodi und ihre eigenen Optimierungsentscheidungen.
Die meisten Teams stecken dramatisch mehr Engineering-Aufwand in die Pipeline als in die Modellarchitektur selbst. Das ist kein Bug; es ist das richtige Verhältnis. Moderne Modelldesigns sind über Labore hinweg bemerkenswert ähnlich. Was die Labore unterscheidet, ist die Qualität und Disziplin ihrer Pipelines.
Evaluations-Frameworks
Hier scheitern viele Projekte. Evaluation in LLM-Systemen ist wirklich schwer, weil es selten eine einzige richtige Antwort gibt, gegen die man vergleichen kann. Du brauchst einen Rahmen, der automatisierte Metriken (wo sie zutreffen), Scoring durch starke Modelle (für Aufgaben, wo es mit menschlichem Urteil korreliert), strukturierte menschliche Reviews (für hochriskante Fälle) und kontinuierliches Monitoring des Produktionsverhaltens (um Drift zu fangen) kombiniert.
Das Buch hat Meinungen zur Evaluation, weil die Muster wichtig sind. Ohne einen Evaluations-Rahmen hast du keine Möglichkeit zu sagen, ob deine Änderungen Verbesserungen oder Regressionen sind. Mit einem wird jede Entscheidung empirisch.
Der integrierte Anwendungs-Stack
Eine funktionierende LLM-Anwendung hat viele bewegliche Teile. Das Modell selbst. Ein Retrieval-System, wenn du RAG nutzt. Eine Vektordatenbank. Eine Prompt-Template-Schicht. Tool-Integrationen, wenn du agentisch gehst. Eine Sicherheitsschicht. Logging und Analytics. Die Nutzerschnittstelle. Authentifizierung und Autorisierung. Rate Limiting. Caching. Monitoring-Dashboards.
Jedes Teil ist ein ziemlich normales Engineering-Problem. Die Kombination ist der neue Teil. Das Buch zeigt, wie man über den Stack als Ganzes denkt — was hart von was abhängt, wo die Fehlermodi sind und wie man für inkrementelle Verbesserung gestaltet.
Wie erfolgreiche Deployments aussehen
Das Buch schließt mit Mustern aus erfolgreichen Deployments in der echten Welt. Sie sind überraschend konsistent. Fang klein an mit einem eng abgegrenzten Use Case. Bau den Evaluations-Rahmen vor dem Skalieren. Füge Retrieval hinzu, bevor du nach einem größeren Modell greifst. Beobachte, was Nutzer tatsächlich tun, nicht, was du angenommen hast, dass sie tun würden. Investiere früh in Sicherheitskontrollen. Behandle das Modell als Komponente und engineere alles drumherum sorgfältig.
Die gescheiterten Deployments teilen dagegen ein anderes Muster. Sie beginnen mit dem Modell, nehmen an, dass das Engineering geradlinig ist, überspringen die Evaluation und entdecken zu spät, dass das, was wie ein KI-Feature aussah, größtenteils ein Systems-Feature mit einer KI darin ist.
Was das Buch — und diese Serie — vorbereiten
Du hast das Ende sowohl des Buches als auch der Serie erreicht. Wenn du mitgelesen hast, hast du jetzt ein funktionierendes mentales Modell der generativen KI, das weit tiefer geht als die Schlagzeilen. Du kannst eine Forschungsarbeit, eine Produktankündigung oder die Preisseite eines Anbieters lesen und sie präzise einordnen. Du kannst darüber argumentieren, was ein Modell in einer Situation tun wird, die weder du noch jemand anderes je gesehen hat. Du kannst LLM-Systeme mit Selbstvertrauen bauen, evaluieren, deployen und über sie nachdenken.
Das ist es, was das Buch erreichen will. Wenn es bei dir Erfolg hatte, wirst du die gleiche Tiefe der Behandlung im Rest der LLM Primer Serie fortgesetzt finden — jeder Band fokussiert auf einen anderen Aspekt davon, diese Systeme verantwortungsvoll in Produktion zu bringen.
Damit endet die Serie. Danke fürs Lesen. Wenn auch nur einer dieser zwölf Beiträge verändert hat, wie du über LLMs denkst, wird es das Buch — das viel tiefer geht, als diese Vorschauen vermuten lassen — vielfach tun.
