Dokumente aktualisieren und entfernen, ohne veraltete Antworten zu hinterlassen

Warum gelöschte Dokumente weiter antworten

Eine Änderung zu erkennen ist einfach, denn die geänderte Datei ist noch da. Eine Löschung zu erkennen verlangt, dass der Sync-Prozess bemerkt, dass etwas fehlt. Microsoft sagt das für Azure AI Search deutlich: Indexer für Azure Storage erkennen neue und geänderte Blobs an ihren Zeitstempeln, verfolgen aber keine Löschungen. Ohne Soft-Delete-Richtlinie bleiben Suchdokumente entfernter Dateien als Waisen im Index.

Auch der Zeitpunkt zählt. Laut derselben Dokumentation muss die Löschrichtlinie ab dem ersten Indexer-Lauf aktiv sein; vorher gelöschte Dokumente bleiben erhalten, auch wenn Sie die Richtlinie später ergänzen und den Indexer zurücksetzen, und als Abhilfe wird ein neuer Index empfohlen. Bei Azure-SQL-Quellen erkennt die High-Water-Mark-Richtlinie gelöschte Zeilen überhaupt nicht, und per TRUNCATE geleerte Zeilen verschwinden durch Zurücksetzen und erneutes Ausführen nicht aus dem Index. Andere Plattformen haben andere Regeln, und genau darum geht es: Lesen Sie vor dem ersten Laden nach, wie Ihre mit Löschungen umgeht.

Jede Änderung enthält eine kleine Löschung

Angenommen, eine Richtlinie schrumpft nach einer Änderung von zwölf auf zehn Chunks. Aktualisiert die Ingestion Chunks nach ihrer Position, bleiben Chunk elf und zwölf der alten Fassung im Index und können weiter abgerufen werden. Das sicherere Muster ersetzt alle Chunks mit der Dokument-ID als Einheit. Wo der Speicher es erlaubt, schreiben Sie die neue Fassung unter einer Versionskennung und schalten in einem Schritt um. Andernfalls löschen und einfügen Sie, behandeln das Dokument währenddessen als nicht verfügbar und testen, was passiert, wenn die Ingestion auf halbem Weg scheitert.

Frameworks unterstützen Teile davon. In LlamaIndex speichert eine Ingestion-Pipeline mit Document Store einen Hash pro Dokument-ID; mit angebundenem Vektorspeicher wird ein Dokument mit geändertem Hash neu verarbeitet und per Upsert aktualisiert, ein unverändertes übersprungen. Das erledigt Änderungen effizient. Über Dokumente, die aus der Quelle verschwunden sind, sagt es für sich genommen nichts, Löschungen brauchen also einen eigenen Weg.

Kennungen müssen auch Verschiebungen überstehen. Azure weist darauf hin, dass geänderte Dokumentschlüssel oder Pfade die Nachverfolgung der Indexer brechen und dass das Umbenennen eines Verzeichnisses in ADLS Gen2 die Zeitstempel der Blobs nicht aktualisiert, sodass sie nicht neu indexiert werden. Verwenden Sie, wo vorhanden, eine ID aus dem Quellsystem statt eines Dateipfads.

Fünf Ereignisse, die jede Quelle abdecken muss

Halten Sie für jede Quelle im Umfang fest, wie jedes dieser Ereignisse in den Index gelangt und wie lange das dauert:

• Angelegt: ein neues Dokument erscheint
• Bearbeitet: der Inhalt ändert sich, die Chunk-Anzahl womöglich auch
• Gelöscht oder zurückgezogen: das Dokument darf nicht mehr antworten
• Verschoben oder umbenannt: die Identität muss gleich bleiben
• Berechtigungen geändert: Zugriffslisten im Index müssen folgen

Abgeleitete Daten brauchen dieselbe Behandlung. Kontextzusammenfassungen an Chunks, Antwort-Caches und Evaluierungssets aus altem Text halten veraltete Inhalte am Leben, nachdem sich die Quelle geändert hat.

Aktualität mit Canary-Dokumenten testen

Ein Canary ist ein harmloses Testdokument mit einem eindeutigen Fakt, den kein echtes Dokument enthält. Legen Sie in jeder Quelle eines an und führen Sie es nach jedem geplanten Sync durch die genannten Ereignisse. Prüfen Sie, welche Chunks abgerufen wurden, nicht nur den Antworttext, denn ein Modell kann eine richtige Antwort formulieren, während ein alter Chunk noch im Kontext steckt.

# Freshness canary run (hypothetical; run after each scheduled sync)
1. create  canary-7f3a.md  "The canary parking code is BLUE-41."
   ask     "What is the canary parking code?"   expect BLUE-41, cites canary-7f3a
2. update  canary-7f3a.md  "The canary parking code is GREEN-12."
   ask     same question                        expect GREEN-12, no chunk says BLUE-41
3. delete  canary-7f3a.md
   ask     same question                        expect decline, zero chunks from canary-7f3a
4. restore canary-7f3a.md from recycle bin / soft delete
   ask     same question                        expect GREEN-12 again
record: time from each source change to the first correct answer

Der Wiederherstellungsschritt hat einen Grund. Azure dokumentiert, dass ein wiederhergestellter Blob nicht immer neu indexiert wird, weil die Wiederherstellung seinen LastModified-Zeitstempel nicht ändert; erneutes Speichern der Metadaten erzwingt die Aktualisierung.

Wenn eine alte Fassung auffindbar bleiben soll

Nicht jedes überholte Dokument sollte verschwinden. Eine Vertragsvorlage aus dem Vorjahr kann für Bestandskunden weiter gelten. Dann behalten Sie beide Fassungen, speichern Gültigkeitsdaten und Status als Metadaten und filtern danach, sodass die normale Frage die aktuelle Fassung liefert und eine Frage zu einem älteren Vertrag trotzdem die alte erreicht.

Was Sie im Betrieb beobachten sollten

• Dokumente pro Quelle im Index im Vergleich zum Quellsystem
• Indexeinträge, deren IDs im Quellsystem nicht mehr existieren
• Zeitpunkt des letzten erfolgreichen Syncs und fehlgeschlagene Elemente pro Quelle
• Canary-Ergebnisse und die gemessene Verzögerung von Änderung bis zur richtigen Antwort

Ist die gemessene Verzögerung länger, als das Geschäft akzeptiert, ist der Zeitplan nicht der einzige Hebel. Azure etwa lässt SQL-Indexer höchstens alle fünf Minuten laufen und empfiehlt, Änderungen direkt per Push zu übertragen, wenn sie schneller sichtbar sein müssen.