Aktualisierung und Versionierung von Wissen in RAG

Die Produktabteilung ändert am Freitagnachmittag die Preisliste. Der RAG-Assistent bearbeitet Kundenanfragen über das Wochenende und antwortet auf Basis von Vektoren, die am Dienstag generiert wurden. Der Kunde erhält einen falschen Preis, legt eine Reklamation ein, und die Supportabteilung verbringt eine Stunde mit Erklärungen. Das ist kein hypothetisches Szenario. Das ist ein Muster, das in jeder RAG-Implementierung auftritt, die keine durchdachte Schicht zur Aktualisierung des Wissens hat.

Das Problem liegt nicht im Sprachmodell selbst oder in der Vektorsuche. Es liegt in der Annahme, dass die Wissensbasis ein Zustand und kein Strom ist. Unternehmen, die das verstehen, bauen die Aktualisierungspipeline zusammen mit der Indizierungspipeline – nicht als separates Projekt für „später“.

Erste RAG-Implementierungen sehen oft gleich aus: einmalige Indizierung einiger hundert Dokumente, das Ergebnis begeistert, das Projekt geht in Produktion. Nach einem Monat gibt es erste Beschwerden über veraltete Antworten. Nach einem Quartal ist die Pflege der Wissensbasis eine Vollzeitaufgabe für jemanden im Team.

Der Grund ist einfach. Unternehmensdokumente sind nicht statisch. Verfahren ändern sich, Preislisten werden aktualisiert, Produkte werden eingestellt. Jede Änderung, die nicht in den Index gelangt, schafft eine Diskrepanz zwischen dem, was die Organisation weiß, und dem, was der Assistent antwortet. Diese Diskrepanz ist ein Risiko: falsche Informationen an den Kunden, falsche Schlussfolgerungen eines Mitarbeiters, Eskalation an einen Berater, die nicht hätte stattfinden müssen.

Drei Mechanismen verschärfen das Problem, je größer die Wissensbasis wird:

Der alte Vektor verschwindet nicht automatisch. Wenn ein Dokument aktualisiert wird, bleibt seine vorherige Version weiterhin in der Vektordatenbank als separater Datensatz erhalten. Bei einer semantischen Abfrage können beide Vektoren relevant sein – das Modell erhält widersprüchliche Fragmente und wählt entweder zufällig aus oder kombiniert sie zu einer inkohärenten Antwort.

Vollständige Reindizierung ist kostspielig. Bei 10.000 Dokumenten und einem lokal laufenden Embedding-Modell dauert eine vollständige Reindizierung mehrere Minuten. Bei einem Cloud-Modell entstehen Kosten proportional zur Anzahl der Token. Wenn man dies jede Nacht durchführt, hat man nach einer Woche sieben vollständige Reindizierungen, von denen sechseinhalb Vektoren betreffen, die sich nicht geändert haben.

Wissensdrift ist ohne Monitoring unsichtbar. Das System funktioniert, Antworten kommen an, operative Metriken sind grün. Doch die Qualität der Antworten verschlechtert sich langsam, weil immer mehr Abfragen auf veraltete Fragmente treffen. Ohne aktive Messung der Treffergenauigkeit bleibt dieser Drift unsichtbar, bis ihn ein Nutzer meldet.

Die richtige Lösung ist eine ereignisgesteuerte Reindizierung: Jede Änderung eines Dokuments löst die Reindizierung nur dieses Dokuments aus, nicht des gesamten Korpus.

Dafür werden vier Elemente benötigt:

Änderungsdetektor. Jedes Dokument hat einen Inhalts-Hash (SHA-256 reicht aus), der zusammen mit den Vektormetadaten gespeichert wird. Vor der Indizierung vergleicht die Pipeline den Hash der aktuellen Version mit dem gespeicherten Hash. Eine Reindizierung erfolgt nur bei einer Abweichung. Bei der Integration mit einem CMS, SharePoint oder einem Git-Repository kann stattdessen auf Webhooks oder API-Ereignisse gehört werden – eine Dokumentenänderung löst direkt eine Indizierungsaufgabe aus.

Aufgabenwarteschlange. Indizierungsereignisse gelangen in eine Warteschlange (Redis, Celery oder ein dedizierter Message Broker). Die Warteschlange stellt sicher, dass ein plötzlicher Batch von Aktualisierungen (z. B. eine Preisaktualisierung vor der Saison) das System nicht blockiert – Aufgaben werden schrittweise mit Priorisierung von Dokumenten mit hoher Abfragehäufigkeit verarbeitet.

Atomares Ersetzen von Vektoren. Bei der Aktualisierung eines Dokuments werden die alten Vektoren als zurückgezogen markiert (Soft Delete mit Zeitstempel), neue werden indiziert, anschließend werden die alten gelöscht. Niemals umgekehrt. Das Zeitfenster, in dem beide Versionen in der Datenbank existieren, beträgt einige Sekunden und wird durch Versionsmetadaten verwaltet.

Indizierungsprotokolle. Jede Operation (neu, aktualisiert, gelöscht) wird mit Zeitstempel, Dokumenten-ID und Version protokolliert. Das Protokoll ist unabhängig von der Vektordatenbank selbst und ermöglicht ein Audit: wann ein bestimmtes Dokument zuletzt reindiziert wurde, wie oft es geändert wurde und ob die Indizierung erfolgreich war.

Versionierung in einem RAG-System funktioniert auf zwei Ebenen, die konzeptionell getrennt werden sollten.

Dokumentenversionierung beantwortet die Frage: Welche Version eines Dokuments ist aktuell aktiv? Die minimale Implementierung besteht aus einem Feld version oder valid_from / valid_to in den Metadaten jedes Fragments. Bei einer Abfrage schließt ein Metadatenfilter Fragmente mit valid_to in der Vergangenheit aus. Dadurch ist es möglich, Aktualisierungen zurückzunehmen: Das Zurücksetzen von valid_to stellt die vorherige Version ohne Reindizierung wieder her.

Vektorenversionierung beantwortet die Frage: Stammt dieser Vektor aus dem aktuell verwendeten Embedding-Modell? Embedding-Modelle ändern sich. Die Migration von einem Modell zu einem anderen (z. B. Upgrade auf eine neuere Version von BGE-M3 oder Änderung der Vektordimension) bedeutet, dass alte und neue Vektoren nicht vergleichbar sind. Die Metadaten jedes Vektors sollten die Modell-ID und die Dimension enthalten. Bei einer Modellmigration werden alte Vektoren schrittweise durch neue ersetzt – Dual-Index während der Übergangsphase, dann Löschung der alten.

Eine vollständige Reindizierung sollte eine Ausnahmeoperation sein, keine Routine. Wenn sie regelmäßig durchgeführt werden muss, ist das ein Signal, dass die Architektur zur Erkennung von Änderungen nicht funktioniert.

Wissensdrift ist die wachsende Diskrepanz zwischen dem, wonach Nutzer fragen, und dem, was in der Wissensbasis enthalten ist. Zwei Typen sind am häufigsten.

Inhaltlicher Drift: Die Dokumente in der Wissensbasis sind aktuell, aber die Nutzerfragen betreffen Themen, die noch nicht indiziert sind. Sichtbar in Metriken als steigender Anteil von Antworten mit der Meldung „Ich habe diese Information nicht“ oder steigende Anzahl von Eskalationen an Berater.

Qualitativer Drift: Die Dokumente in der Wissensbasis enthalten veraltete Informationen, aber die Vektoren sind semantisch weiterhin relevant, sodass das System selbstsicher auf Basis falscher Daten antwortet. Dies ist der schwierigere Fall, da operative Metriken das Problem nicht signalisieren. Sichtbar nur durch aktives Messen der Treffergenauigkeit oder durch Nutzerfeedback.

Praktische Erkennung von Wissensdrift erfordert drei Elemente:

Regelmäßige Tests der Treffergenauigkeit mit einem Satz goldener Fragen und erwarteter Antworten. Der Satz sollte Fragen aus verschiedenen Wissensdomänen umfassen und zusammen mit der Wissensbasis aktualisiert werden. Einmal pro Woche reicht für die meisten Systeme aus.

Alarm bei steigendem Anteil von „Weiß ich nicht“-Antworten. Ein plötzlicher Anstieg ist ein Signal, dass neue Themen ohne Abdeckung in der Wissensbasis aufgetaucht sind – oder dass Dokumente aus dieser Domäne geändert und nicht reindiziert wurden.

Versionsverfolgung in jeder Antwort. Die Protokollierung, aus welcher Version welchen Dokuments das für die Antwort verwendete Fragment stammt, ermöglicht im Nachhinein zu prüfen, ob die Antwort auf aktuellen oder zurückgezogenen Inhalten basierte. Ohne dies ist ein Audit unmöglich. Dieses Muster ist auch eine Anforderung des AI Act in Systemen, die als hochriskant eingestuft werden – der Entscheidungsweg muss nachvollziehbar sein.

Bei begrenzten Indizierungsressourcen lohnt es sich, zu priorisieren. Nicht jedes Dokument hat die gleiche Bedeutung für die Qualität der Antworten.

Hohe Priorität haben Dokumente, auf deren Basis das System am häufigsten Antworten gibt. Die Protokollierung der Dokumenten-ID bei jeder Nutzung (sofern RODO und Anonymisierung von PII respektiert werden) ermöglicht die Erstellung eines Rankings der Dokumentenpopularität. Dokumente im oberen Bereich des Rankings sollten bei jeder Änderung der Domäne auf Aktualität überprüft werden.

Hohe Priorität haben auch Dokumente mit kurzem Lebenszyklus: Preislisten, SLAs, AGBs, Zeitpläne. Ihre Metadaten sollten ein Feld valid_to mit einem definierten Ablaufdatum enthalten. Das System sollte sie nach diesem Datum automatisch als veraltet markieren und eine Bestätigung des Dokumenteneigentümers vor weiterer Nutzung erzwingen.

Niedrige Priorität haben konzeptionelle und historische Dokumente, die sich selten ändern. Sie können einmal pro Quartal oder nur bei expliziter Aktualisierung reindiziert werden.

Die RAG-Wissensbasis kann personenbezogene Daten enthalten: Transkriptionen von Kundengesprächen, E-Mails, Projektnotizen. Das Recht auf Vergessenwerden (Art. 17 RODO) gilt nicht nur für die Dokumentendatenbank, sondern auch für die Vektoren.

Das Löschen eines Dokuments aus dem Repository entfernt nicht automatisch die daraus generierten Vektoren. Ein explizites Löschen aus der Vektordatenbank mit Bestätigung im Protokoll ist erforderlich. Das Verfahren sollte dokumentiert und testbar sein: Nach dem Löschen sollte keine Abfrage Fragmente aus dem gelöschten Dokument zurückgeben.

Bei sensiblen Daten (z. B. Transkriptionen mit Kundendaten) ist der Standardweg die Maskierung von PII vor der Indizierung. Das indizierte Fragment enthält dann keine personenbezogenen Daten, und das Löschen auf Anfrage betrifft nur die Originaldokumente, nicht die Vektoren. Ein detailliertes Muster beschreiben wir im Artikel über Anonymisierung von PII vor KI.

Bei sensiblen Daten und regulatorischen Anforderungen sollte der gesamte Stack (Embeddings + Vektordatenbank + Modell) lokal betrieben werden. Self-Hosting eliminiert die Frage nach Datenübertragung in die Cloud und vereinfacht die DPIA.

Beschreibe die Struktur deiner Wissensbasis und die Häufigkeit von Dokumentenänderungen, und das Modell schlägt eine auf die Skalierung abgestimmte Architektur für die Aktualisierungspipeline vor – als Ausgangspunkt für die Diskussion mit dem technischen Team (Playground: PII maskiert, keine Speicherung):

Die Antwort hängt vom Tempo der Dokumentenänderungen ab, nicht von einem willkürlichen Zeitplan. Für Dokumente, die wöchentlich oder häufiger geändert werden, ist das richtige Muster eine ereignisgesteuerte Reindizierung: Ein Webhook oder Hash-Diff löst die Reindizierung sofort nach einer Änderung aus. Für statische oder selten geänderte Dokumente reicht ein wöchentlicher oder monatlicher Zeitplan. Eine vollständige Reindizierung des gesamten Korpus sollte die Ausnahme sein, nicht die Regel – sie wird bei der Migration des Embedding-Modells oder bei einer größeren Reorganisation der Wissensbasis durchgeführt.

Das System gibt beide als Kandidaten für die Antwort zurück. Das Sprachmodell erhält widersprüchliche Fragmente und verhält sich unvorhersehbar: Es kann zufällig auswählen, widersprüchliche Informationen kombinieren oder die Diskrepanz eingestehen. Das richtige Muster ist das atomare Ersetzen: Neue Vektoren werden indiziert, alte als zurückgezogen markiert und in einer Transaktion gelöscht. Das Zeitfenster der Inkonsistenz sollte Sekunden betragen, nicht Minuten.

Drei Signale sind es wert, überwacht zu werden. Erstens: Ein steigender Anteil von „Ich habe diese Information nicht“-Antworten im Vergleich zur Baseline. Zweitens: Ein Anstieg der Eskalationen an Berater bei Fragen, die zuvor automatisch beantwortet wurden. Drittens: Regelmäßige Tests der Treffergenauigkeit mit einem Satz goldener Fragen und erwarteter Antworten. Die Kombination dieser drei liefert eine frühzeitige Warnung, bevor das Problem für Kunden sichtbar wird. Das Muster der Messung beschreiben wir detailliert im Artikel über Monitoring der Qualität eines KI-Agenten.

Ja. Ein Vektor, der aus einem Dokument mit personenbezogenen Daten generiert wurde, ist eine Ableitung dieser Daten und unterliegt denselben Pflichten wie das Original. Das Löschen des Dokuments aus dem Quell-Repository reicht nicht aus – ein explizites Löschen der Vektoren aus der Vektordatenbank mit Bestätigung im Protokoll ist erforderlich. Eine empfohlene Alternative ist die Maskierung von PII vor der Indizierung: Das indizierte Fragment enthält dann keine personenbezogenen Daten, und das Recht auf Löschung betrifft nur die Originaldokumente.

Alte und neue Vektoren sind geometrisch nicht vergleichbar – man kann Vektoren aus verschiedenen Modellen nicht in einer Sammlung mischen. Das sichere Migrationsverfahren ist Dual-Index: Parallele Pflege der alten Sammlung (aus der die Produktion antwortet) und der neuen (in die die inkrementelle Reindizierung erfolgt). Nach der Reindizierung des gesamten Korpus wird der Traffic auf die neue Sammlung umgeschaltet, die alte wird gelöscht. Die Migrationsdauer hängt von der Größe des Korpus und den verfügbaren Rechenressourcen ab – bei Self-Hosting mit lokalem Modell meist einige bis zu