Kapitel 11 — Kontinuierliche Updates und Pipeline-Optimierung

Elfter und letzter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Darin: Die Pipeline ist nie fertig — die Dokumente ändern sich, die Queries verschieben sich, die Modelle werden ausgetauscht — und das Team, das sie betreibt, lernt, in drei Zeitskalen gleichzeitig zu denken.

Warum dieses Kapitel existiert

Ein RAG-System ist nicht fertig, wenn es ausgespielt wird. Die Dokumente ändern sich, die Queries driften, das Modell selbst wird alle paar Monate ersetzt. Die Pipeline, auf die ein Team im März stolz ist, retrievet im September gegen veraltete Embeddings aus einem zwei Generationen alten Modell, bedient ein Basismodell, das still ausgetauscht wurde, und beantwortet eine Query-Verteilung, die sich auf Wegen verschoben hat, die niemand kartiert hat. Dieses Kapitel handelt vom Engineering des Aktuell-Bleibens — was sich im Korpus geändert hat erkennen, den Index frisch halten, ohne ihn neu zu bauen, die Latenz vom Klettern abhalten und die Schleife zwischen Produktions-Telemetrie und den Änderungen, die das Team tatsächlich macht, schließen.

11.1 Change Data Capture und inkrementelle Indizierung

Der erste Instinkt jedes Teams, das ein RAG-System ausspielt, ist, einen nächtlichen Index-Rebuild zu schedulen. Es funktioniert. Es ist langfristig auch falsch. Ein nächtlicher Rebuild verbrennt Embedding-API-Aufrufe auf Dokumenten, die sich nicht geändert haben, lässt den Index bis zu vierundzwanzig Stunden veralten und passt mit wachsendem Korpus irgendwann nicht mehr in das nächtliche Fenster. Das gereifte Muster ist inkrementelle Indizierung, getrieben von Change Data Capture — die Pipeline reagiert auf Events von upstream, statt zu pollen.

Drei Eventarten zählen. Insert: ein neues Dokument, geparst, gechunkt, eingebettet, indiziert. Update: ein bestehendes Dokument hat sich geändert; betroffene Chunks neu einbetten. Delete: ein Dokument entfernt; die entsprechenden Vektoren ausräumen, bevor sie in Ergebnissen wieder auftauchen können — eine harte Anforderung unter DSGVO, CCPA und dem Rest. Der Mechanismus, der das beherrschbar macht, ist der Content-Hash. Beim ersten Ingest SHA-256 über den normalisierten Chunk-Text neben dem Embedding speichern. Beim Update neu chunken, hashen, vergleichen: unveränderte Chunks bleiben, neue werden eingebettet, alte gehen. Aus einem Absatz-Edit wird ein Embedding-Call statt tausend. Die Embedding-Rechnung skaliert mit redaktioneller Aktivität statt mit der Korpusgröße.

Das härtere Problem sind Reihenfolge und Konsistenz. Events kommen außer der Reihe an; ein Delete kann einem Update vorauseilen, das ihm folgen sollte. Die Standard-Abhilfe sind monotone Versionen pro Dokument mit bedingten Writes: ein Event nur anwenden, wenn seine Version die Version auf der Platte übersteigt. Das macht die Pipeline idempotent — ein dupliziertes Event kann den Index nicht beschädigen —, was bei Skalierung keine Optimierung, sondern eine Korrektheitsforderung ist. Compliance-Kontexte ergänzen Tombstones: ein logischer Delete, der zur Query-Zeit greift, bevor die physische Entfernung asynchron abgeschlossen ist, sodass die Löschung sofort respektiert wird.

11.2 Latenz beherrschen: semantisches Caching und Model-Tiering

Ein retrieval-augmentierter Aufruf akkumuliert Latenz an jedem Hop. Die Verteidigung ist, weniger Arbeit zu tun, wenn die Arbeit beweisbar unnötig ist, und zwei Techniken tragen den meisten Anteil. Ein konventioneller Cache speichert Antworten, gekeyt am exakten Query-Text, und trifft einen verschwindenden Anteil des echten Traffics. Semantisches Caching keyt stattdessen an Bedeutung: jede eingehende Query einbetten, einen kleinen Cache der letzten Queries durchsuchen, die gecachte Antwort zurückgeben, wenn die Kosinus-Ähnlichkeit zum nächsten Eintrag einen Schwellwert übersteigt. "Wie ist unsere Rückerstattungspolicy?" und "wie funktionieren Erstattungen?" teilen keine String-Übereinstimmung und teilen die ganze Antwort.

Die drei wichtigen Wahlen sind der Ähnlichkeitsschwellwert (0,93–0,97 Kosinus für allgemeine Embeddings, gegen zurückgehaltenen Traffic getunt), die Lebensdauer (idealerweise an die beitragenden Chunks gebunden — invalidieren, wenn einer von ihnen neu eingebettet wird) und der Scope (partitioniert nach Mandant, nach Zugriffsrolle, nach allem, was eine Antwort eines Nutzers an einen anderen leaken könnte). Produktions-Deployments berichten Trefferraten von 30–60 % mit zweistelligen Millisekunden bei Treffern gegenüber mehrsekündigen ungecachten Antworten, mit proportionalen Kosteneinsparungen, da Cache-Treffer Embedding und Generierung beide überspringen.

Model-Tiering behandelt die Queries, die das Modell benutzen müssen und nicht das größte verfügbare benutzen sollten. Zwei oder drei Stufen: ein kleines schnelles günstiges Modell für die Masse, ein größeres für Queries, bei denen das kleine unsicher ist, optional ein drittes für den Long Tail. Der Router ist der Punkt, an dem Produktions-Deployments das beim ersten Anlauf falsch machen. Die einfachste Version nutzt query-seitige Signale (kurze Faktenabfrage vs analytisch). Eine bessere nutzt retrieval-seitige Signale (hohe konsistente Ähnlichkeit heißt, das kleine Modell reicht). Die ausgefeilteste fährt das kleine Modell zuerst und eskaliert auf kalibriertem Konfidenz-Signal — präzise am Rand, zahlt mit einer zusätzlichen Inferenz bei Eskalationen. Die Zahlen, auf die zu schauen ist, sind Eskalationsrate und Bedauer-Rate gemeinsam; eine allein irreführt.

11.3 Die kontinuierliche Feedback-Schleife

Eine RAG-Pipeline emittiert konstant Telemetrie. Die meisten Teams sammeln sie; sehr wenige schließen die Schleife auf ihr. Die Schleife hat vier Stufen. Sammeln: jede Query, jedes Retrieval, jede Generierung, jede Zitation und jede Nutzerinteraktion mit stabilem Schema und einem stabilen Query-Identifier geloggt, der sich durch jede Stufe zieht — ohne diesen Identifier wird das Diagnostizieren einer Regression zur Rätselei. Evaluieren: die Triade aus den Kapiteln 9 und 10 in zwei Modi gefahren — gesampelt offline gegen ein Referenzset für Genauigkeit, und online verhaltensbasierte Proxies (Regenerate, Copy, Follow-up, Abbruch) für Abdeckung. Keiner allein reicht. Zusammen triangulieren sie.

Entscheiden ist die härteste Stufe, weil dasselbe Signal mehrere verschiedene Korrekturen impliziert. Ein Rückgang bei Context Relevance kann heißen, dass der Korpus Themen fehlen, oder dass der Reranker degradiert ist, oder dass das Embedding-Modell nicht mehr zum neuen Wortschatz passt. Das auseinanderzuhalten verlangt, die Metriken zu zerlegen — nach Thema, nach Dokumentalter, nach Embedding-Version, nach Mandant —, und das Team, das nur das Aggregat beobachtet, entdeckt ein Quartal zu spät, dass eine einzelne Scheibe den Durchschnitt die ganze Zeit nach unten zog.

Anwenden kommt in drei Gewichten. Konfigurations-Änderungen — top-k, Reranker-Gewichte, Hybrid-Alpha, Cache-Schwelle, Eskalationsregel — in Stunden A/B-getestet, in Minuten zurückgerollt, mehrere parallel laufend. Reindex-Aktionen — ein veraltetes Thema neu einbetten, eine neue Quelle ingesten, obsolete Dokumente ausräumen — wöchentlich bis on-demand, auf einem Nicht-Produktions-Replica vor der Promotion. Modell-Änderungen — das Embedding-Modell tauschen, das Basismodell tauschen, einen Custom-Reranker neu trainieren — quartalsweise, mit Shadow-Deployment, paralleler Evaluation, gradueller Traffic-Verschiebung und Rollback-Option. Die Disziplin liegt in der Kadenz, nicht in irgendeiner einzelnen Änderung. Ein kleiner Human-Label-Kanal — vielleicht hundert Beispiele pro Woche aus der mehrdeutigen-Proxy-Warteschlange — hält die LLM-Judges kalibriert und verhindert, dass die Schleife gegen ihre eigenen Proxies optimiert.

Was Band III vorbereitet

Wir haben mit der Behandlung von Retrieval-Augmented Generation als der Engineering-Antwort auf zwei Probleme begonnen, die reine Sprachmodelle nicht lösen können: aktuelles Wissen und verifizierbare Provenienz. Wir haben die Architektur von dem frühen Einbetten-Abrufen-Stopfen-Muster über die modularen und agentischen Systeme nachgezeichnet, die heute in Produktion sind, und auf dem Weg die sorgfältige Arbeit an jeder Komponente getan — die Parser, die Struktur aus PDFs zurückholen, die Chunker, die entscheiden, was eine Bedeutungseinheit ist, die Vektordatenbanken, die das Ergebnis speichern, die hybriden Retriever und Reranker, die finden, was zählt, die Zugriffskontrollen und Anonymisierungs-Schichten, die das System ehrlich halten, die Evaluations-Frameworks, die uns sagen, ob das alles funktioniert, und nun die Continuous-Update-Mechanismen, die es am Leben halten.

RAG ist keine Produktkategorie. Es ist eine Engineering-Disziplin, zusammengesetzt aus vielleicht einem Dutzend Unter-Disziplinen, von denen jede den Unterschied zwischen einem System, das funktioniert, und einem, das still halluziniert, ausmachen kann. Ein Team, das jede Unter-Disziplin ernst nimmt, wird etwas produzieren, das unter echtem Traffic hält. Ein Team, das irgendeine als Blackbox behandelt, wird etwas produzieren, das es nicht tut.

Die Reihe geht weiter in LLM Primer IV — Designing AI Cognition with MCP. Wo Band III davon handelte, dem Modell das richtige Wissen zu bringen, handelt Band IV davon, ihm die richtigen Hände zu geben — das Model Context Protocol, die Agenten, die es führen, die Werkzeuge, die sie aufrufen, und das Gedächtnis, das sie ansammeln. Dieselbe architektonische Sensibilität, eine andere Oberfläche desselben Problems. Die Arbeit geht weiter.