LLM Primer III — Enterprise-KI mit RAG: Serieneinführung und Übersicht
"Ein Basismodell ist brillant und unbeweisbar. RAG ist die Architektur, die es zugleich aktuell und zitierbar macht." Willkommen zu Band III der LLM-Primer-Reihe — und zur Tour, die ihn begleitet. Über die nächsten elf Tage, einen Beitrag pro Kapitel, öffnen wir den Retrieval-Augmented-Generation-Stack und schauen uns die Entscheidungen an, die darüber bestimmen, ob ein Enterprise-RAG-System still funktioniert oder still scheitert.
Warum es Band III gibt
Die Bände I und II dieser Reihe haben dir das Modell gegeben. Band I erzählte in einfacher Sprache, was LLMs sind und wie Systeme darum herum gebaut werden. Band II öffnete die Mathematik darunter. Band III handelt davon, was ein Modell umgibt, sobald du versuchst, es auf Dokumente loszulassen, die sich ändern, auf Wissen, das zitiert werden muss, und auf Zugriffskontrollen, die nicht optional sind.
Von außen sieht RAG einfach aus. Drei Kästchen auf einer Folie: einbetten, abrufen, generieren. Jeder, der eines schon einmal in Produktion gebracht hat, weiß, dass jedes Kästchen eine eigene Disziplin ist und dass die Lücke zwischen einer funktionierenden Demo und einem System, dem eine Rechtsabteilung vertraut, in Monaten von Engineering-Arbeit gemessen wird — Arbeit an Problemen, die die Demo nie zu Gesicht bekam. Der Parser plättet Tabellen lautlos. Der Chunker schneidet eine Definition von ihrem Zusatz ab. Das Filter-Pushdown der Vektordatenbank ist schwächer, als der Benchmark suggerierte. Der Retriever liefert selbstbewusste Nachbarn eines bedeutungslosen Embeddings. Das Evaluations-Setup meldet grüne Dashboards über Halluzinationen.
Dieses Buch geht den Stack ehrlich durch, Schicht für Schicht. Jedes Kapitel ist die Disziplin hinter einem der Kästchen — die Fragen, die ein ernsthaftes Team beantworten muss, um die jeweilige Schicht in Produktion zu bringen. Das Versprechen ist nicht, dass es eine richtige Architektur gibt. Das Versprechen ist, dass du am Ende weißt, welche Architektur für deinen Korpus, dein Team und deinen regulatorischen Rahmen die richtige ist — und welchen Preis du auf jeder Achse zahlst.
Für wen das Buch geschrieben ist
Für Engineers, die RAG-Systeme bauen, technische PMs, die sie zuschneiden, und Architekten, die die Entscheidungen vor einem Security-Review verteidigen müssen. Das Buch setzt voraus, dass du mit dem Band-I-Bild davon vertraut bist, wie ein LLM sich verhält; die Mathematik aus Band II setzt es nicht voraus. Wo Mathematik auftaucht, dient sie der Intuition, nicht als Herleitung zum Durchackern. Der Schwerpunkt liegt auf dem Engineering: wo die Fehlerquellen sitzen, welche Entscheidungen reversibel sind und welche das Team über Jahre festlegen.
Wie du es lesen kannst
Drei Modi, die sich bei frühen Lesern bewährt haben. Von vorn nach hinten, wenn du gerade ein Enterprise-RAG-System aufbauen willst und den Stack in der Reihenfolge brauchst, in der die Entscheidungen tatsächlich anstehen. Als Referenz, wenn du ein laufendes System hast und eine bestimmte Schicht weh tut — die Parsing-, Chunking- und Evaluations-Kapitel funktionieren je für sich. Oder als Begleitlektüre zum Architecture-Review, wo die Kapitel zu Gesprächsanlässen werden, die ein Team braucht, bevor es sich auf einen Anbieter festlegt.
Die elf Kapitel im Überblick
18. März — Kapitel 1: Die Evolution der RAG-Architektur. Die vier architektonischen Haltungen — Naive, Advanced, Modular, Agentic — und wann Fine-Tuning die bessere Antwort ist als Retrieval.
19. März — Kapitel 2: Intelligentes Document-Parsing. Warum das Plätten einer PDF das Wichtige verliert, die layoutbewussten Parser, die die Signale zurückbringen, und der multimodale Pfad, auf dem das Modell die Seite direkt liest.
20. März — Kapitel 3: Fortgeschrittene Chunking-Frameworks. Das Chunking-Spektrum, der Overlap-Mythos, die Kontextklippe und die Frontier-Techniken — Contextual Retrieval und Late Chunking — die das Kalkül neu formen.
21. März — Kapitel 4: Die richtige Vektordatenbank wählen. Purpose-Built versus Extension, die Managed-Leader, das Open-Source-Feld und die drei Achsen — Residency, Betrieb, Kosten — die die echte Entscheidung treffen.
22. März — Kapitel 5: Die Retrieval-Pipeline architektonisch denken. Hybride Suche, Reciprocal Rank Fusion, Cross-Encoder-Reranking und die Query-Understanding-Schicht, die Nutzerfragen und Dokumentantworten verbindet.
23. März — Kapitel 6: Bedrohungsmodelle und Schwachstellen von RAG. Prompt Injection, indirekte Injection über abgerufene Inhalte, Pfade zur Datenexfiltration und das Bedrohungsmodell, gegen das du tatsächlich verteidigen musst.
24. März — Kapitel 7: Zugriffskontrolle umsetzen. Dokumentbezogene Berechtigungen, Row-Level-Security im Index, Identitätsdurchleitung durch den Retrieval-Aufruf und die Muster, die ein Audit überstehen.
25. März — Kapitel 8: Datenanonymisierung in der RAG-Pipeline. PII-Erkennung beim Ingest, der richtige Ort zum Redigieren, die Asymmetrien zwischen Trainingsdaten und Retrieval-Korpora und das Bild des Restrisikos.
26. März — Kapitel 9: Die RAG-Evaluations-Triade. Context Relevance, Groundedness, Answer Relevance — die drei Messungen, die lokalisieren, woher eine Regression kam.
27. März — Kapitel 10: Führende Evaluations-Frameworks. RAGAS, TruLens, DeepEval und die praktische Frage, wie man die Triade in der CI nutzbar macht.
28. März — Kapitel 11: Kontinuierliche Updates und Pipeline-Optimierung. Inkrementelle Indizierung, Drift-Erkennung, Reindex-Strategie und die Betriebs-Disziplin, die ein RAG-System davor bewahrt, nach dem Launch still abzugleiten.
Über dieses Buch und die Reihe
Die LLM-Primer-Reihe ist die lange Antwort auf eine Frage, die mir Engineers, Gründer und gelegentlich Regulatoren immer wieder gestellt haben: Wie funktionieren diese Systeme eigentlich, und was braucht es, um eines zu bauen, das unter Last bestehen kann? Band I gab die Form. Band II die Mathematik. Band III gibt die Produktionsarchitektur. Band IV, in Arbeit, wendet sich MCP und der Cognition-Schicht zu, die über dem Modell sitzt.
Bis morgen, mit Kapitel 1.