So halten Sie einen RAG-Korpus aktuell und prüfen, ob alte Dokumente nicht mehr erscheinen

Die Pflege des Korpus ist nicht dasselbe wie die Bewertung von Antworten

Ein RAG-Korpus ist dann aktuell, wenn die für die Suche verfügbaren Inhalte weiterhin den Quellen entsprechen, die das Team als gültig betrachtet. Dazu gehört, Dokumente und Versionen zu identifizieren, Änderungen zu verarbeiten, indexierte Einheiten zu aktualisieren und das Ergebnis zu überprüfen. Diese Aufgabe unterscheidet sich von der Bewertung, ob das Modell eine richtige Antwort formuliert oder sie gut mit den abgerufenen Textstellen begründet. Beides kann zusammenhängen, ist aber nicht austauschbar: Ein Abruf-Test kann zeigen, dass ein zurückgezogenes Dokument weiterhin erscheint, selbst wenn die generierte Antwort plausibel klingt.

Die bereitgestellte Microsoft-Dokumentation beschreibt den Aufbau einer Pipeline für unstrukturierte Daten in KI-Anwendungen. Die Google-Cloud-Dokumentation behandelt die Verwaltung eines RAG-Korpus und umfasst den verfügbaren Informationen zufolge das Erstellen eines Korpus sowie das Importieren oder Hochladen von Dokumenten. Diese Quellen bieten Kontext zur Datenverarbeitung und zur Aufnahme von Inhalten. Die vorliegenden Informationen bestätigen jedoch kein allgemeingültiges Verfahren zum Aktualisieren oder Löschen von Dokumenten. Die folgenden Schritte sind daher ein anpassbares Betriebskonzept und keine Behauptung, dass jede Plattform eine bestimmte Funktion bereitstellt.

Praktisch sollte sich das Team jederzeit Fragen zum Zustand der Inhalte beantworten können: Aus welcher Quelle stammt ein Textabschnitt? Welche Version wurde verarbeitet? Ist ein Teilprozess fehlgeschlagen? Welcher Test belegt, dass ein Rückzug wirksam war? Kann das Team diese Fragen nicht beantworten, sollte es den Korpus nicht allein deshalb als aktuell betrachten, weil ein Verarbeitungslauf beendet wurde.

Quellen erfassen, bevor Sie Abläufe automatisieren

Listen Sie zunächst die Quellen auf, aus denen Inhalte in den Korpus gelangen können, und weisen Sie jeder Quelle eine verantwortliche Person oder Stelle zu. Eine Quelle kann ein internes Dokumentationssystem, ein Katalog, eine Sammlung von Vorschriften oder ein Dateibestand sein. Das Verzeichnis muss nicht an ein bestimmtes Produkt gebunden sein. Es muss aber jeden Ursprung unterscheidbar machen und erkennen lassen, wer darüber entscheidet, ob Inhalte aufgenommen, geändert oder zurückgezogen werden.

Speichern Sie für jedes Dokument eine stabile Kennung, sofern das Ursprungssystem eine solche bereitstellt. Halten Sie außerdem den Speicherort oder die Quellsammlung, die verantwortliche Stelle, ein überprüfbares Datum oder eine Version sowie den Dokumentstatus fest, zum Beispiel „aktiv“, „Verarbeitung ausstehend“ oder „zurückgezogen“. Gibt es keine formale Versionsnummer, können Sie ein verfügbares Änderungsmerkmal des Ursprungssystems erfassen. Das Team sollte jedoch dokumentieren, was dieses Merkmal aussagt und welche Grenzen es hat. Gehen Sie nicht davon aus, dass ein Änderungsdatum genügt, um identische Inhalte oder unterschiedliche Überarbeitungen zuverlässig voneinander zu unterscheiden.

Verknüpfen Sie diese Eigenschaften mit jeder abgeleiteten Einheit, die indexiert wird, etwa mit einem Textabschnitt oder Datensatz. So lassen sich alle Einheiten finden, die aus einer Quelle hervorgegangen sind, wenn diese geändert oder zurückgezogen wird. Kann der Indexierungsmechanismus keine Metadaten speichern oder ist nicht dokumentiert, wie sich Datensätze filtern und entfernen lassen, halten Sie das als zu prüfende Einschränkung fest. Nehmen Sie nicht an, dass das Löschen der Quelldatei automatisch auch ihre abgeleiteten Einheiten entfernt.

Legen Sie außerdem Regeln für Aufnahme und Rückzug fest. Bestimmen Sie beispielsweise, wer genehmigt, dass ein Dokument den Status „aktiv“ erhält, was als Ersatz gilt und wie widersprüchliche Quellen behandelt werden. Das sind Governance-Entscheidungen des Teams und keine Eigenschaften von RAG an sich. Werden sie schriftlich festgehalten, verhindert das, dass ein technischer Aktualisierungsvorgang unbeabsichtigt darüber entscheidet, welche Version als gültig gilt.

Festlegen, welche Änderungen eine erneute Verarbeitung erfordern

Nicht jede Änderung muss denselben Arbeitsumfang auslösen. Für eine lokale Korrektur kann es genügen, ein einzelnes Dokument erneut zu verarbeiten. Eine Änderung an den Regeln für die Inhaltsextraktion oder die Aufteilung in Textabschnitte kann dagegen eine ganze Sammlung betreffen. Wird eine Konfiguration geändert, die die gespeicherte Repräsentation beeinflusst, kann eine umfassendere Neuerstellung sinnvoll sein. Dies sind Kategorien für Entscheidungen. Bevor Sie danach handeln, müssen Sie prüfen, welche Komponenten Ihr konkreter Stack verwendet und welche Vorgänge er unterstützt.

Formulieren Sie eine Richtlinie, die Änderungssignale mit dem Umfang der erneuten Verarbeitung verknüpft. So könnte eine neue, im Ursprungssystem ausgewiesene Version die erneute Verarbeitung des betreffenden Dokuments auslösen. Eine allgemeine Änderung an der Extraktion könnte eine Überprüfung der betroffenen Sammlung erfordern. Zweifel an der Konsistenz des Gesamtkorpus könnten Anlass für einen Testaufbau geben. Machen Sie aus solchen Beispielen keine automatischen Regeln, bevor Sie die Identität der Dokumente, die Möglichkeit zum Entfernen und das Verhalten des jeweiligen Werkzeugs geprüft haben.

Die von Microsoft beschriebene Pipeline kann als allgemeine Referenz dienen, wenn Sie die Verarbeitung unstrukturierter Daten planen. Die verfügbaren Informationen sagen jedoch nicht, welche Funktionen für inkrementelle Aktualisierung, Synchronisierung oder Löschung sie implementiert. Ebenso bestätigt die Google-Cloud-Referenz zur Korpusverwaltung das Thema Erstellen und Importieren, erlaubt aber keine Schlussfolgerung darüber, unter welchen Bedingungen Datensätze geändert oder gelöscht werden können. Das tatsächliche Verhalten muss anhand der Dokumentation des gewählten Stacks und durch kontrollierte Tests geprüft werden.

Ablauf für neue und geänderte Dokumente gestalten

Ein Aktualisierungsablauf lässt sich in klar benannte Schritte gliedern. Zuerst wird eine neue Quelle oder eine Änderung anhand eines verfügbaren Signals im Ursprungssystem erkannt. Anschließend wird die beobachtete Version festgehalten und geprüft, ob das Dokument nach den Regeln des Teams aufgenommen werden darf. Danach wird der Inhalt extrahiert, mit der vereinbarten Konfiguration verarbeitet und mit Metadaten versehen, die eine Rückverfolgung zur Quelle ermöglichen.

Legen Sie vor der Veröffentlichung des Ergebnisses fest, wie der Übergang zwischen Versionen erfolgen soll. Eine mögliche Strategie besteht darin, die neue Version zunächst vorzubereiten und zu prüfen, bevor sie verfügbar gemacht wird, sofern die Plattform eine getrennte Bereitstellung unterstützt. Eine andere Möglichkeit ist, die Inhalte direkt zu ersetzen und die Änderung danach zu überprüfen. Keine dieser Strategien ist grundsätzlich immer überlegen. Welche geeignet ist, hängt von den dokumentierten Funktionen, der Toleranz des Systems gegenüber Unterbrechungen und dem Umgang mit Zwischenzuständen ab.

Das Ausführungsprotokoll sollte mindestens die Zielquelle und Zielversion, den Erkennungszeitpunkt, den geplanten Umfang, den Status jeder Phase und das Ergebnis der Überprüfungen enthalten. Wird der Ablauf unterbrochen, hilft diese Information dabei, eine nicht erkannte Quelle von einer fehlgeschlagenen Extraktion oder einer nur teilweise angewandten Aktualisierung zu unterscheiden. Markieren Sie eine Version nicht allein deshalb als aktuell, weil ihre Verarbeitung begonnen hat.

Definieren Sie ein beobachtbares Abschlusskriterium. Beispielsweise gilt der Vorgang erst dann als abgeschlossen, wenn überprüft wurde, dass die erwarteten Einheiten abrufbar sind und die frühere Version nicht mehr erscheint, sofern sie ersetzt werden sollte. Das Kriterium muss mit dem konkreten Werkzeug umsetzbar sein. Bietet es keine Möglichkeit zur Überprüfung, dokumentieren Sie diese Einschränkung und entwerfen Sie einen externen Abruf-Test.

Rückzüge und Ersetzungen verwalten, ohne Reste zu hinterlassen

Eine Datei aus dem Ursprungssystem zu entfernen und ihre Repräsentationen aus dem Index zu entfernen, sind unterschiedliche Vorgänge – es sei denn, die konkrete Integration dokumentiert und belegt das Gegenteil. Bei einem Rückzug können Textabschnitte, abgeleitete Kopien oder doppelte Datensätze zurückbleiben, wenn nicht alle Inhalte identifiziert werden, die aus der Quelle stammen. Deshalb sollte die Zuordnung zwischen Quell-ID und indexierten Einheiten bereits entworfen sein, bevor der erste Rückzug stattfindet.

Halten Sie bei einer Ersetzung fest, welche Version nicht mehr gültig ist und welche an ihre Stelle treten soll. Prüfen Sie, ob die neue Version korrekt verarbeitet wird und ob die alte bei Suchanfragen, für die sie zuvor relevant war, nicht mehr erscheint. Müssen beide Versionen aus einem legitimen Grund nebeneinander bestehen, legen Sie fest, wie sie unterschieden werden und welchen Status jede hat. Präsentieren Sie sie nicht als gleichwertig, wenn die Quellenrichtlinie sie als unvereinbar behandelt.

Ein Rückzug sollte einen Nachweis hinterlassen: die zurückgezogene Quelle, den Zeitpunkt der Anfrage, die verantwortliche Stelle, die betroffenen Einheiten oder den Umfang des Vorgangs, das Ergebnis und die ausgeführten Testabfragen. Schlägt der Vorgang fehl, behalten Sie den Status „ausstehend“ oder „fehlgeschlagen“ bei und stellen Sie den Korpus nicht als vollständig aktuell dar. Zur Fehlerbehebung kann ein erneuter Versuch, eine teilweise Neuerstellung oder eine Eskalation gehören. Welche Möglichkeit geeignet ist, hängt von den verfügbaren Funktionen ab und sollte dokumentiert werden.

Die bereitgestellten Quellen bestätigen nicht ausreichend, dass eine bestimmte Plattform beim Löschen eines Dokuments automatisch alle daraus abgeleiteten Textabschnitte entfernt. Die als Quelle angeführte Reddit-Diskussion ist anekdotisch und belegt kein garantiertes Verhalten. Prüfen Sie die Löschfunktionen in der offiziellen Dokumentation des konkreten Produkts und kontrollieren Sie das Ergebnis vor allem mit einem reproduzierbaren Test.

Teilweise Aktualisierungen und Fehler kontrollieren

Ein Aktualisierungsvorgang kann abbrechen, nachdem eine Änderung erkannt wurde, während der Extraktion oder nachdem nur ein Teil des Index geändert wurde. Das Betriebskonzept muss diese Unterschiede sichtbar machen. Legen Sie einfache Statuswerte fest, etwa „ausstehend“, „in Bearbeitung“, „abgeschlossen“ und „fehlgeschlagen“, und beschreiben Sie, was jeder Wert bedeutet. Benötigt das Team genauere Phasen, kann es weitere Status ergänzen, sofern für die Bedienenden klar ist, wie diese zusammenhängen.

Entscheiden Sie, welche Inhalte verfügbar bleiben sollen, solange eine Aktualisierung unvollständig ist. In manchen Systemen lässt sich die frühere Version möglicherweise beibehalten, bis die neue geprüft wurde. In anderen kann die Aktualisierung ein Zeitfenster mit eingeschränkter Verfügbarkeit oder gemischte Suchergebnisse verursachen. Versprechen Sie keine atomare Umschaltung oder unterbrechungsfreie Ersetzung, solange die Plattformdokumentation dies nicht bestätigt und ein Test das Verhalten nicht überprüft hat.

Legen Sie eine Wiederholungsstrategie fest, die keine Duplikate erzeugt. Prüfen Sie vor einem erneuten Lauf, ob der vorige Vorgang teilweise Einheiten hinterlassen hat und wie diese zu erkennen sind. Lässt sich das nicht feststellen, behandeln Sie das Ergebnis als ungewiss und vermeiden Sie einen blinden zweiten Schreibvorgang. Dokumentieren Sie den Umfang, die getroffene Entscheidung und den anschließenden Test, damit eine andere Person rekonstruieren kann, welche Version verfügbar war.

Inkrementelle Aktualisierung oder Neuerstellung wählen

Eine inkrementelle Aktualisierung beschränkt die Arbeit auf betroffene Dokumente oder Sammlungen. Sie kann geeignet sein, wenn das System jede Quelle genau identifizieren und ihre abgeleiteten Inhalte entfernen oder ersetzen kann. Bei einer Neuerstellung wird ein größerer Bestand erneut verarbeitet. Das kann eine umfassendere Überprüfung erleichtern, aber auch mehr Zeit und Ressourcen beanspruchen. Dies sind allgemeine betriebliche Überlegungen und weder Leistungsgarantien noch Beschreibungen eines bestimmten Werkzeugs.

Vergleichen Sie beide Möglichkeiten anhand von Daten aus Ihrer Umgebung: Umfang der Quellen, Häufigkeit von Änderungen, beobachtete Laufzeit, Verarbeitungskosten, Leichtigkeit der Identifizierung betroffener Einheiten und Folgen einer unvollständigen Aktualisierung. Berücksichtigen Sie außerdem, ob der Stack dokumentierte Funktionen zum Aktualisieren, Löschen, Abfragen von Status und Wiederherstellen einer früheren Version bietet. Ist eine wesentliche Funktion nicht bestätigt, halten Sie sie als offene Frage fest, die vor einer Automatisierung geklärt werden muss.

Wählen Sie nicht allein deshalb die inkrementelle Aktualisierung, weil sie günstiger klingt, und lösen Sie nicht bei jeder Änderung automatisch eine Neuerstellung aus. Entscheidend ist, ob sich die Auswirkungen begrenzen und die Konsistenz des Ergebnisses nachweisen lassen. Ein Test einer Neuerstellung in einer kontrollierten Umgebung kann helfen, die Dauer abzuschätzen und Abweichungen zu erkennen. Für sich genommen belegt er jedoch nicht, dass eine Neuerstellung in der Produktion sicher ist.

Prüfen, ob der Korpus den erwarteten Zustand widerspiegelt

Abnahmetests sollten das Verhalten des Korpus prüfen und nicht nur bestätigen, dass ein technischer Auftrag ohne Fehlermeldung beendet wurde. Die bereitgestellten Informationen zur Erstellung von RAG-Korpora und deren Verwendung für Evaluationen unterstreichen, dass Prüfungen für RAG-Systeme relevant sind. Sie geben hier jedoch weder eine konkrete Testsuite noch einen allgemeingültigen Grenzwert vor. Abfragen und Akzeptanzkriterien müssen aus den Quellen und den Risiken der jeweiligen Anwendung abgeleitet werden.

Erstellen Sie einen kleinen, stabilen Satz von Abfragen. Nehmen Sie Abfragen auf, die eine aktuelle Version abrufen sollten, solche, die für eine zurückgezogene Quelle charakteristisch sind, und solche zu nicht betroffenen Dokumenten, die weiterhin verfügbar sein müssen. Dokumentieren Sie die erwartete Quelle und Version, das beobachtete Ergebnis und den Zeitpunkt des Tests. Hängt der Abruf von Rangfolge, Schwellenwerten oder anderen Einstellungen ab, halten Sie auch die relevante Konfiguration fest, damit Änderungen zwischen Testläufen eingeordnet werden können.

Ergänzen Sie Tests auf Duplikate und Konflikte. Eine Suche kann die alte und die neue Version, zwei Kopien desselben Dokuments oder Textabschnitte zurückgeben, deren Herkunft sich nicht mehr ausreichend unterscheiden lässt. Legen Sie fest, welche Ergebnisse akzeptabel sind: etwa genau eine aktive Version, wenn die Richtlinie Exklusivität verlangt, oder zwei klar gekennzeichnete Versionen, wenn ihre gleichzeitige Verfügbarkeit zulässig ist.

Ein negativer Test – also eine zurückgezogene Quelle nicht abzurufen – erfordert besondere Sorgfalt. Dass sie bei einer einzelnen Abfrage nicht erscheint, beweist nicht, dass sie aus dem gesamten Index verschwunden ist. Verwenden Sie mehrere repräsentative Abfragen und prüfen Sie, sofern das Werkzeug es ermöglicht, Datensätze anhand der Quell-ID. Beschreiben Sie den tatsächlichen Umfang der Prüfung und stellen Sie eine Stichprobe nicht als absolute Garantie dar.

Die Bewertung des Abrufs entscheidet auch nicht für sich allein, ob das Modell eine richtige Antwort formuliert. Muss das Team zusätzlich die endgültige Antwort bewerten, sollte es dafür einen getrennten Testsatz mit passenden Kriterien führen. So lässt sich ein Aktualitätsproblem des Korpus von einem Problem bei der Generierung oder der Nutzung des Kontexts unterscheiden.

Regelmäßige Routine und Grenzen der verfügbaren Belege

Eine regelmäßige Routine sollte ausstehende Änderungen, fehlgeschlagene Vorgänge, Quellen ohne verantwortliche Stelle, nicht bestätigte Versionen und noch nicht ausgeführte Abnahmetests berücksichtigen. Wie häufig die Prüfung stattfindet, hängt von der Änderungsrate und dem Risiko ab: Für eine Sammlung mit Vorschriften können häufigere Kontrollen erforderlich sein als für ein gelegentlich konsultiertes Archiv. Die bereitgestellten Quellen nennen keine allgemeingültige Prüffrequenz. Jedes Team sollte daher begründen, warum es seinen Rhythmus gewählt hat.

Prüfen Sie außerdem, ob sich die Regeln für Extraktion oder Verarbeitung seit der letzten Aktualisierung geändert haben und ob diese Änderung eine erneute Verarbeitung älterer Dokumente erforderlich macht. Kontrollieren Sie, ob Kennungen und Metadaten weiterhin bis zu den abgerufenen Einheiten erhalten bleiben. Kann das Team nicht nachvollziehen, welche Quelle und Version zu einem Testergebnis beigetragen haben, sollte es zuerst diese Lücke in der Rückverfolgbarkeit schließen, bevor es die Automatisierung ausweitet.

Die verfügbaren Quellen haben einen begrenzten Umfang. Die Microsoft-Dokumentation bestätigt das Thema Datenpipelines für unstrukturierte KI-Daten. Die Google-Cloud-Dokumentation behandelt die Verwaltung und den Import von Dokumenten in einen RAG-Korpus. Der Beitrag des Instituts für Wissensingenieurwesen behandelt die Erstellung von RAG-Korpora und ihren Einsatz für Evaluationen. Keiner der bereitgestellten Auszüge bestätigt das genaue Verhalten einer Plattform bei Rückzügen, Ersetzungen, Transaktionen, Neuerstellungen oder inkrementellen Aktualisierungen. Diese Funktionen müssen anhand der aktuellen Produktdokumentation und mit Tests in der tatsächlichen Umgebung überprüft werden.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.