# Betrieb der Retrieval-Pipeline > Frische, Vollständigkeit, Replay, Löschungen, Neuaufbau und Indexmigration als messbaren Produktionsdienst führen. Track: [LLM Production Ops](https://physar.tech/learn/llm-production-ops) Kanonische Fassung: https://physar.tech/learn/llm-production-ops/data-pipeline-ops Stand: 2026-09-04 Interaktiver Teil: 8 Checks (nur im Browser) ## Betrieb der Retrieval-Pipeline ### Der stille Ausfall Wenn die Ingest-Pipeline stehen bleibt, fällt nichts aus. Der Dienst antwortet weiter, mit derselben Latenz und ohne Fehler — nur eben auf Basis eines Standes von gestern, letzter Woche oder vom letzten Monat. Für den Nutzer sieht das nicht wie ein Ausfall aus, sondern wie eine falsche Antwort. Das ist die zentrale Betriebseigenschaft dieses Moduls: Datenaktualität ist eine **Verfügbarkeitseigenschaft ohne Verfügbarkeitssignal**. Sie braucht eine eigene Zusage, eine eigene Messung und einen eigenen Alarm. > **Abgrenzung:** Berechtigungen im Index, Ingest-Qualität und Löschung entlang der Herkunftskette behandelt `llmops` im Modul zum RAG-Datenlebenszyklus. Hier geht es um den laufenden Betrieb: Frische, Neuaufbau, Migration, Rückstau. ### Frische als messbare Zusage Die brauchbare Kennzahl ist das **Alter des ältesten noch nicht verarbeiteten Elements** — nicht „der letzte Lauf war erfolgreich“. Ein Lauf kann erfolgreich sein und trotzdem nichts aufgeholt haben, und ein Zeitplan sagt nichts über den Rückstand aus. | | | | --- | --- | | Datenalter | Wie alt ist die älteste noch nicht indexierte Änderung? Direkt an der Nutzerwirkung. | | Rückstau | Wie viele Elemente warten? Zeigt, ob der Rückstand wächst oder schrumpft. | | Verarbeitungsrate gegen Zulaufrate | Sagt voraus, ob der Rückstand je aufgeholt wird. | | Anteil dauerhaft fehlgeschlagener Elemente | Zeigt Inhalte, die nie in den Index kommen — der leiseste Fehler von allen. | > **Merksatz:** Eine Frische-Zusage lautet „höchstens X alt“, nicht „läuft stündlich“. Nur die erste Form ist überprüfbar und alarmierbar. ### Neuaufbau ohne Ausfall Ein vollständiger Neuaufbau ist keine Ausnahme, sondern Routine: geänderte Segmentierung, korrigierte Metadaten, neues Schema. Ihn im laufenden Index vorzunehmen bedeutet, dass Nutzer während des Aufbaus einen halb aktualisierten Zustand sehen — mit doppelten oder fehlenden Treffern. Neuen Index parallel aufbauen → Vollständigkeit und Qualität gegen den alten prüfen → Auf einer Verkehrsstichprobe vergleichen → **Verweis umschalten** → Alten Index als Rückweg vorhalten Das Muster ist derselbe Gedanke wie beim Release: Der Index bekommt eine **Version**, die Anwendung zeigt über einen Verweis darauf, und der Wechsel ist ein Umschalten mit Rückweg. Der Preis ist doppelter Speicher während der Umstellung. > **Merksatz:** Ein Index ohne Version hat keinen Rückweg. Neuaufbau am lebenden Objekt ist ein Deploy ohne Rollback. ### Migration des Einbettungsmodells Ein Wechsel des Einbettungsmodells ist der härteste Fall: Vektoren aus zwei verschiedenen Modellen sind **nicht vergleichbar**. Eine teilweise migrierte Sammlung liefert deshalb keine leicht schlechteren Ergebnisse, sondern strukturell unsinnige — die Ähnlichkeiten zwischen den beiden Räumen bedeuten nichts. Daraus folgt: Anfrage- und Dokumentseite müssen immer dasselbe Modell verwenden, die Migration läuft über einen vollständig neu aufgebauten parallelen Index, und die Umschaltung erfolgt als Ganzes. Zusätzlich ist die Modellkennung Teil der Indexidentität — sonst kann später niemand feststellen, womit ein Vektor erzeugt wurde. > **Merksatz:** Einbettungsräume sind nicht mischbar. Eine schrittweise Migration innerhalb einer Sammlung ist keine vorsichtige Variante, sondern ein Defekt. ### Rückstau und Priorisierung Wenn der Zulauf die Verarbeitungsrate übersteigt, wächst der Rückstand unbegrenzt — und die Frische-Zusage bricht schleichend. Zusätzliche Verarbeitungskapazität ist eine Antwort; die andere ist **Priorisierung**: Nicht alle Inhalte sind gleich zeitkritisch. Häufig abgerufene oder als aktuell deklarierte Quellen dürfen vorgezogen werden. Wichtig ist außerdem der Umgang mit dauerhaft fehlschlagenden Elementen: Ohne separaten Fehlerpfad blockieren sie entweder die Verarbeitung oder verschwinden lautlos aus dem Index. Beides muss sichtbar und wiederaufnehmbar sein. > **Gleich im Check:** In den nächsten Entscheidungen wählst du für konkrete Ops-Szenarien selbst — und siehst pro Option, **warum** sie trägt oder nicht. ### Praxisachse: INDEX-FRESHNESS ### Betriebsprobe: INDEX-FRESHNESS Ein Wissensassistent beantwortet Fragen zu internen Richtlinien. Eine Richtlinie wurde vor elf Tagen geändert; der Assistent nennt weiterhin die alte Fassung. Die Überwachung der Ingest-Pipeline meldet seit Wochen ausschließlich erfolgreiche Läufe. Es stellte sich heraus, dass ein Konnektor Änderungen einer Quelle nicht mehr erkennt, der Lauf aber ohne Fehler endet. **Anforderungen** - Welchen Alarm baust du, damit dieser Fall künftig auffällt? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Auf das Alter des ältesten noch nicht indexierten Elements je Quelle alarmieren, gemessen gegen eine ausdrückliche Frische-Zusage. Richtig. Diese Kennzahl misst das Ergebnis statt der Ausführung: Sie schlägt an, sobald eine Quelle nicht mehr nachgeführt wird, unabhängig davon, ob die Läufe technisch erfolgreich enden. - Plausibler Fehlweg: Alarmieren, wenn ein Pipeline-Lauf fehlschlägt oder ausfällt. Genau das war vorhanden und hat nichts gemeldet. Ein Lauf, der nichts findet, ist technisch erfolgreich — der Alarm misst die Ausführung, nicht die Wirkung. - Plausibler Fehlweg: Alarmieren, wenn die Zahl der Dokumente im Index sinkt. Erkennt Löschunfälle, aber nicht den vorliegenden Fall: Die Dokumentzahl bleibt konstant, wenn Änderungen an bestehenden Dokumenten nicht ankommen. - Plausibler Fehlweg: Täglich eine Stichprobe von Antworten manuell prüfen. Eine sinnvolle Ergänzung, aber als primäre Erkennung zu langsam und zu lückenhaft — elf Tage Verzug wären so bestenfalls zufällig aufgefallen. **Merksatz:** Alarmiere auf das Ergebnis, das der Nutzer erlebt, nicht auf die Ausführung eines Ablaufs. Zwischen „der Job lief“ und „die Daten sind aktuell“ liegt genau die Fehlerklasse, die still bleibt. **+** Stille Datenausfälle werden zu lauten Alarmen mit klarer Zuordnung zur Quelle. **−** Die Kennzahl verlangt, dass die Pipeline Änderungszeitpunkte je Quelle kennt und vorhält; ohne diese Metadaten ist sie nicht berechenbar. ### Betriebsprobe: DELETE-PROPAGATION Ein Dokument wurde im Quellsystem gelöscht, erscheint aber weiterhin in Antworten. Der normale Upsert-Pfad funktioniert. **Anforderungen** - Wo geht die Löschinformation verloren? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Tombstones als eigene, wiederholbar verarbeitbare Operation bis zum Index propagieren und ihren Fortschritt messen. Eine Löschung ist eine Zustandsänderung und muss alle abgeleiteten Repräsentationen erreichen. Idempotente Verarbeitung erlaubt sichere Wiederholung. - Plausibler Fehlweg: Den Retrieval-Top-k-Wert reduzieren, damit der alte Chunk mit geringerer Wahrscheinlichkeit in einer Antwort auftaucht. Das versteckt den Fehler nur probabilistisch. Der unzulässige Datensatz bleibt vorhanden und kann weiterhin gefunden werden. - Plausibler Fehlweg: Nur neue Dokumente häufiger einbetten und den Löschstrom weiterhin vor der Chunking-Stufe verwerfen. Schnellere Upserts reparieren keinen fehlenden Delete-Pfad. Die Ableitung divergiert weiter von der Quelle. **Merksatz:** Ein Index ist abgeleiteter Zustand; Upserts und Löschungen benötigen einen nachvollziehbaren, wiederholbaren Propagationspfad. **+** Gelöschte Quellen verschwinden nachweisbar aus allen Chunks. **−** Tombstones, Revisionen und Reconciliation erhöhen die Zustands- und Aufbewahrungskomplexität. ### Praxisachse: INDEX-COMPLETENESS ### Betriebsprobe: INDEX-COMPLETENESS Das Frische-Dashboard ist grün, weil der jüngste verarbeitete Zeitstempel aktuell ist. Später zeigt sich, dass ein fehlerhafter Shard seit Stunden ein Drittel der Dokumente verwirft. **Anforderungen** - Welche zusätzliche Zusage hätte den Fehler sichtbar gemacht? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Plausibler Fehlweg: Ausschließlich den Zeitstempel des zuletzt erfolgreichen Dokuments noch häufiger abfragen — anschließend ohne Reconciliation als maßgebliche Indexversion veröffentlicht. Ein einzelner aktueller Datensatz kann trotz großer Lücken eintreffen. Frische allein misst keine Vollständigkeit. - Tragfähiger Ansatz: Erwartete und tatsächlich verarbeitete Einheiten je Partition abgleichen und Abweichungen alarmieren. Coverage beziehungsweise Completeness deckt verlorene Partitionen auf, auch wenn andere Daten weiterhin pünktlich eintreffen. - Plausibler Fehlweg: Die Antwortlatenz des Retrieval-Dienstes als alleinigen Indikator für fehlende Dokumente verwenden. Ein unvollständiger Index kann sehr schnell antworten. Serving-Latenz sagt nichts über die Menge korrekt übernommener Daten aus. - Plausibler Fehlweg: Jeden Indexzugriff protokollieren, ohne Sollmengen, Partitionen oder Erfolgsstatus zu erfassen. Zugriffslogs zeigen Nutzung, liefern aber keinen Nenner für die erwartete Datenabdeckung der Pipeline. **Merksatz:** Pipeline-Gesundheit braucht getrennte SLIs für Aktualität, Vollständigkeit und gegebenenfalls Korrektheit; ein grünes Signal kann die anderen Dimensionen nicht vertreten. **+** Teilverluste werden trotz aktueller Restdaten erkannt. **−** Erwartungsmengen und Partitionsstatus müssen verlässlich bereitgestellt und reconciliert werden. ### Betriebsprobe: INDEX-CUTOVER Ein vollständiger Neuaufbau liegt unter einer neuen Indexversion bereit. Die laufende Version muss bis zur bestandenen Prüfung unverändert bedienbar und als Rollbackziel erhalten bleiben. **Anforderungen** - Ordne den Cutover in eine sichere Reihenfolge. - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: 1. Neue Indexversion isoliert und vollständig aus einem festgehaltenen Quellstand bauen. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 2. Änderungen seit dem Quellstand nachführen und Frische sowie Vollständigkeit messen. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 3. Repräsentative Queries und Invarianten gegen alte und neue Version vergleichen. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 4. Lesepointer kontrolliert auf die neue Version umschalten. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 5. Qualitäts- und Betriebsmetriken beobachten und bei Gate-Verletzung zurückschalten. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. - Tragfähiger Ansatz: 6. Alte Version erst nach Ablauf des Rollbackfensters ausmustern. Dieser Schritt besitzt eine fachliche Vorbedingung und einen überprüfbaren Abschluss. **Merksatz:** Neuaufbau und Aktivierung sind getrennte Operationen; ein unveränderter Pointer macht Cutover und Rollback kontrollierbar. **+** Nutzer sehen erst einen geprüften und vollständigen Index. **−** Während Migration und Rollbackfenster werden doppelte Speicher- und Rechenressourcen benötigt. ### Praxisachse: PIPELINE-BACKLOG ### Betriebsprobe: PIPELINE-BACKLOG Nach der Anbindung einer großen neuen Quelle wächst der Ingest-Rückstand kontinuierlich: Die Zulaufrate liegt dauerhaft rund 30 % über der Verarbeitungsrate. Das Datenalter der wichtigsten Quelle ist von Minuten auf zwei Tage gestiegen und steigt weiter. Zusätzlich scheitern rund 2 % der Elemente reproduzierbar und werden endlos wiederholt. **Anforderungen** - Was ist die richtige Reihenfolge der Maßnahmen? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Zuerst die dauerhaft scheiternden Elemente in einen separaten Fehlerpfad ausleiten, dann zeitkritische Quellen im Rückstand priorisieren und parallel die Verarbeitungskapazität an die neue Zulaufrate anpassen. Richtig. Endlose Wiederholungen verbrauchen genau die Kapazität, die fehlt; ihre Ausleitung wirkt sofort. Priorisierung stellt die wichtigste Frische zuerst wieder her, und die Kapazitätsanpassung behebt die strukturelle Ursache. - Plausibler Fehlweg: Sofort die Verarbeitungskapazität verdoppeln, alles andere ergibt sich danach — anschließend ohne Reconciliation als maßgebliche Indexversion veröffentlicht und trotz fehlender Vollständigkeits- und Revisionsprüfung als erfolgreicher Cutover protokolliert. Wirkt gegen die Unterdeckung, lässt aber die Wiederholungsschleife bestehen — sie skaliert mit und frisst einen Teil der neuen Kapazität. Und ohne Priorisierung wird der Rückstand in beliebiger Reihenfolge abgebaut. - Plausibler Fehlweg: Die neue Quelle vorerst wieder abschalten, bis der Rückstand abgebaut ist. Stellt die alte Frische wieder her, verwirft aber die neue Funktion. Vertretbar nur als Notmaßnahme — als Plan gibt es das Ziel auf, statt die Kapazität an den erweiterten Umfang anzupassen. - Plausibler Fehlweg: Die Frische-Zusage auf zwei Tage anpassen, damit die Überwachung wieder grün ist. Das schaltet die Messung ab statt das Problem: Der Rückstand wächst weiter, und die angepasste Zusage ist morgen ebenfalls verletzt. **Merksatz:** Bei einem wachsenden Rückstand zuerst die Kapazität zurückgewinnen, die durch nutzlose Arbeit gebunden ist — dann die Reihenfolge nach Wichtigkeit steuern und erst danach die Kapazität dauerhaft nachziehen. Struktur vor Menge. **+** Die wichtigste Frische kehrt schnell zurück, und die Ursache wird behoben statt kaschiert. **−** Priorisierung heißt, dass nachrangige Quellen bewusst länger veraltet bleiben; das muss deklariert sein, sonst wirkt es wie ein Defekt. ### Betriebsprobe: EMBEDDING-MIGRATION Ihr wollt auf ein neues Einbettungsmodell wechseln. Der Neuaufbau aller Vektoren dauert Tage. Ein Vorschlag: neue und geänderte Dokumente ab sofort mit dem neuen Modell einbetten, den Bestand nach und nach nachziehen — beides in derselben Sammlung, damit der Dienst durchgehend alles findet. **Anforderungen** - Wie bewertest du diesen Migrationsplan? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Ablehnen: Vektoren zweier Modelle liegen in unvergleichbaren Räumen — in einer gemeinsamen Sammlung wären die Ähnlichkeitswerte bedeutungslos. Stattdessen eine zweite, vollständig neu eingebettete Sammlung aufbauen und als Ganzes umschalten. Richtig. Ähnlichkeit ist nur innerhalb eines Einbettungsraums definiert. Eine gemischte Sammlung liefert keine leicht schlechteren, sondern strukturell sinnlose Ranglisten — und zwar still, ohne Fehler. - Plausibler Fehlweg: Zustimmen, aber während der Übergangszeit die Trefferzahl erhöhen, um die Unschärfe auszugleichen — anschließend ohne Reconciliation als maßgebliche Indexversion veröffentlicht und trotz fehlender Vollständigkeits- und Revisionsprüfung als erfolgreicher Cutover protokolliert. Mehr Treffer aus einer unvergleichbaren Rangliste sind mehr Rauschen, keine Kompensation. Die Ordnung selbst ist unbrauchbar, nicht bloß zu kurz. - Plausibler Fehlweg: Zustimmen, wenn die Anfrage mit beiden Modellen eingebettet und gegen beide Teilmengen gesucht wird, mit anschließendem Zusammenführen der Ergebnisse. Technisch der ernsthafteste Einwand — und trotzdem der falsche Weg: Die Bewertungen zweier Modelle sind nicht auf einer gemeinsamen Skala, und ein Zusammenführen bräuchte eine eigene, kalibrierte Rangfusion. Dafür einen dauerhaften Doppelpfad zu bauen ist mehr Aufwand und mehr Risiko als der saubere parallele Aufbau. - Plausibler Fehlweg: Zustimmen, sofern das neue Modell dieselbe Vektordimension hat. Gleiche Dimension heißt nur, dass die Datenstruktur passt — nicht, dass die Räume dieselbe Bedeutung tragen. Genau diese Verwechslung macht den Fehler unsichtbar, weil nichts abstürzt. **Merksatz:** Ähnlichkeit ist nur innerhalb eines gemeinsamen Repräsentationsraums definiert. Wo eine Änderung den Raum wechselt, gibt es keinen gültigen Mischzustand — die Migration muss als Ganzes umgeschaltet werden. **+** Zu jedem Zeitpunkt liefert der Dienst Ergebnisse aus einem konsistenten Raum, und der alte Index bleibt als Rückweg verfügbar. **−** Der parallele Aufbau kostet tagelang doppelten Speicher sowie die volle Einbettungsrechnung, und alle Änderungen im Zeitraum müssen in beiden Sammlungen nachgeführt werden. ### Praxisachse: REPLAY-SAFETY ### Betriebsprobe: REPLAY-SAFETY Nach einem Parser-Fix sollen fehlgeschlagene Dokumente erneut verarbeitet werden. Das Job-Skript quittiert die Queue-Nachricht bereits vor dem Index-Commit. **Anforderungen** - Markiere die Zeile, die bei einem Prozessabsturz Datenverlust ermöglicht. - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Konfigurationsbefund. Das Ack geschieht vor der dauerhaften Wirkung. Stürzt der Worker danach ab, gilt die Nachricht als erledigt, obwohl der Index nicht aktualisiert wurde. Erst nach einem idempotenten Commit quittieren. **Merksatz:** Bei mindestens-einmal zugestellter Arbeit muss die Wirkung idempotent sein und die Quittierung hinter dem dauerhaften Commit liegen. **+** Abstürze führen zu wiederholbarer Arbeit statt zu stillen Lücken. **−** Deduplizierung und atomare Fortschrittsmarker benötigen zusätzlichen Zustand. ### Praxisachse: REINDEX-ROLLOUT ### Betriebsprobe: REINDEX-ROLLOUT Eine geänderte Segmentierung soll die Retrieval-Qualität verbessern. Der Index umfasst 4 Millionen Passagen; der vollständige Neuaufbau dauert etwa sechs Stunden. Der Assistent wird während dieser Zeit genutzt. Ein Vorschlag ist, die alten Passagen laufend durch neue zu ersetzen, „dann ist der Übergang fließend“. **Anforderungen** - Wie führst du den Neuaufbau durch? - Bewerte Ursache, wirksame Grenze und den Preis der tragfähigen Maßnahme getrennt. **Schritte** - Tragfähiger Ansatz: Einen zweiten, versionierten Index parallel aufbauen, ihn gegen den alten auf Vollständigkeit und Trefferqualität prüfen und dann den Verweis umschalten — mit dem alten Index als Rückweg. Richtig. Der laufende Betrieb sieht nur einen der beiden konsistenten Zustände, die Qualität ist vor der Umstellung vergleichbar, und ein misslungener Neuaufbau ist durch Zurückschalten in Sekunden behoben. - Plausibler Fehlweg: Passagen laufend im bestehenden Index ersetzen, das vermeidet doppelten Speicher. Damit läuft der Dienst sechs Stunden gegen einen gemischten Zustand aus alter und neuer Segmentierung — mit doppelten oder fehlenden Treffern und ohne Rückweg, wenn die neue Segmentierung schlechter ist. - Plausibler Fehlweg: Den Assistenten für die Dauer des Neuaufbaus abschalten. Ein ehrlicher, aber unnötig teurer Weg: Ein paralleler Aufbau erreicht dasselbe ohne sechs Stunden Ausfall — und liefert zusätzlich die Vergleichsmöglichkeit vor der Umstellung. - Plausibler Fehlweg: Den Neuaufbau nachts laufen lassen, dann stört der gemischte Zustand kaum jemanden. Das verkleinert die betroffene Nutzergruppe, ändert aber nichts an der fehlenden Konsistenz und am fehlenden Rückweg — und bei internationalen Nutzern gibt es die ruhige Zeit oft gar nicht. **Merksatz:** Abgeleitete Datenbestände werden wie Releases behandelt: neu aufbauen, vergleichen, umschalten, Rückweg behalten. Eine Änderung am lebenden Bestand hat weder einen konsistenten Zwischenzustand noch einen Rückweg. **+** Konsistente Sicht für Nutzer, prüfbare Qualität vor der Umstellung, Rückweg in Sekunden. **−** Während der Umstellung wird der Speicher doppelt belegt, und Änderungen, die während des Aufbaus eintreffen, müssen im neuen Index nachgeführt werden. ## Quellen - Google SRE Workbook, Data Processing Pipelines — https://sre.google/workbook/data-processing/ - Google SRE Book, Data Processing Pipelines — https://sre.google/sre-book/data-processing-pipelines/ - Google SRE Workbook, Configuration Design — https://sre.google/workbook/configuration-design/ - GDPR Article 17 — https://eur-lex.europa.eu/eli/reg/2016/679/oj