Wissensbestand aktualisieren: RAG-Daten pflegen

Was dieser Artikel über Wissensbestand-Aktualisierung behandelt

• Warum ein RAG-Wissensbestand regelmäßig aktualisiert werden muss und was passiert, wenn Du es nicht tust.
• Die zwei wichtigsten Strategien: vollständiger Neuaufbau und inkrementelle Updates.
• Schritt-für-Schritt-Anleitung für neue, geänderte und veraltete Dokumente.
• Versionierung und Automatisierung, damit Dein Wissensbestand immer aktuell bleibt.
• Typische Stolpersteine und wie Du sie vermeidest.

Einleitung: Wissensbestand aktualisieren verständlich erklärt

Ein RAG-System lebt von seinen Daten. Du hast Dokumente gesammelt, sie in Chunks aufgeteilt, mit einem Embedding-Modell verarbeitet und in einer Vektordatenbank gespeichert. Soweit, so gut. Aber Dokumente ändern sich. Neue kommen hinzu, alte werden ungültig, manche werden überarbeitet.

Genau hier beginnt die Wartung Deines Wissensbestands. Dieser Artikel zeigt Dir, wie Du Deinen RAG-Wissensbestand aktuell hältst, ohne jedes Mal von vorne zu beginnen. Du lernst, welche Strategien es gibt, wann welche sinnvoll ist und wie Du den Prozess automatisierst.

Wenn Du die RAG Grundlagen noch nicht kennst, lies zuerst diesen Artikel. Er erklärt, wie die einzelnen Bausteine zusammenwirken.

Warum brauche ich Aktualisierung?

Stell Dir vor, Dein Unternehmen hat ein Handbuch für Mitarbeitende. Darin stehen Urlaubsregeln, Arbeitszeiten und Richtlinien. Du hast dieses Handbuch vor sechs Monaten in Dein RAG-System geladen. Jetzt fragt jemand: “Wie viele Urlaubstage habe ich pro Jahr?”

Das RAG-System sucht in der Vektordatenbank, findet den alten Eintrag und antwortet: “30 Tage.” Das Problem: Das Handbuch wurde vor zwei Monaten aktualisiert. Es sind jetzt 28 Tage. Dein RAG-System weiß das nicht, weil niemand die alte Version entfernt und die neue hinzugefügt hat.

Das ist kein theoretisches Szenario. Es passiert überall, wo Dokumente nicht statisch sind. Verträge ändern sich, Gesetzestexte werden angepasst, Produkthandbücher erhalten neue Versionen, interne Richtlinien werden überarbeitet. Ein RAG-System ohne Aktualisierung wird mit der Zeit unzuverlässig.

Weitere Beispiele für veraltete Daten:

• Ein Produktkatalog, aus dem Artikel entfernt wurden, die das System noch empfiehlt.
• Eine alte Datenschutzrichtlinie, die nicht mehr der aktuellen Rechtslage entspricht.
• Abgelaufene Angebote, die das System noch als gültig präsentiert.

Wissensbestand aktualisieren kurz erklärt

Stell Dir eine Bibliothek vor. Regelmäßig kommen neue Bücher hinzu. Manche Bücher werden durch neuere Auflagen ersetzt. Andere werden ausgesondert, weil sie veraltet sind. Der Bibliothekar führt Buch darüber, was neu ist, was ersetzt wurde und was aussortiert wurde. Ohne diese Pflege würde die Bibliothek unbrauchbar werden, weil die Besucher veraltete Informationen finden.

Dein RAG-Wissensbestand funktioniert genauso. Die Vektordatenbank ist die Bibliothek, die Dokumente sind die Bücher, und Du bist der Bibliothekar. Neue Dokumente müssen hinzugefügt, geänderte ersetzt und veraltete entfernt werden. Dieser Prozess heißt Aktualisierung oder Wartung des Wissensbestands.

Für wen ist dieser Artikel gedacht?

Dieser Artikel richtet sich an Anfängerinnen und Anfänger, die bereits ein funktionierendes RAG-System haben und nun lernen möchten, wie sie es langfristig pflegen. Du brauchst keine tiefen Programmierkenntnisse, solltest aber die Grundlagen aus Lokales RAG und Dokumente vorbereiten kennen.

Wenn Du Dich generell fragst, was lokale KI überhaupt ist, hilft Dir der Artikel Was ist lokale KI? weiter.

Wichtige Begriffe rund um die Aktualisierung

Begriff	Bedeutung
Wissensbestand	Gesamtheit aller Dokumente und Chunks in Deiner Vektordatenbank
Collection	Ein benannter Bereich in der Vektordatenbank, der zusammengehörige Daten enthält
Upsert	Eintrag aktualisieren, falls vorhanden, sonst neu anlegen (Update + Insert)
Delete	Eintrag oder Einträge aus der Vektordatenbank entfernen
Versionierung	Nachverfolgbarkeit, welche Version eines Dokuments gespeichert ist
Incremental Update	Nur geänderte oder neue Dokumente aktualisieren, nicht alles neu laden
Full Rebuild	Kompletter Neuaufbau der Vektordatenbank, alle Daten werden neu eingebettet
Stale	Veralteter Eintrag, der nicht mehr dem aktuellen Stand des Quelldokuments entspricht
Chunk ID	Eindeutiger Bezeichner für einen einzelnen Chunk in der Datenbank
Embedding	Zahlenvektor, der die Bedeutung eines Textabschnitts repräsentiert

Was passiert bei veralteten Daten?

Veraltete Daten sind nicht nur unschön, sie sind aktiv schädlich für Dein RAG-System. Hier sind die häufigsten Folgen:

Falsche Antworten: Das System antwortet auf Basis alter Informationen. Das kann im harmlosen Fall bedeuten, dass ein veraltetes Produktdatum genannt wird. Im schlimmeren Fall gibt das System falsche Sicherheits- oder Rechtsinformationen weiter.

Widersprüchliche Antworten: Wenn Du eine alte und eine neue Version desselben Dokuments in der Datenbank hast, kann das System je nach Frage einmal die alte und einmal die neue Antwort liefern. Das wirkt unzuverlässig und verwirrend.

Compliance-Probleme: In regulierten Bereichen wie Finanzen, Medizin oder Datenschutz ist es wichtig, dass nur aktuelle Dokumente verwendet werden. Veraltete Richtlinien können rechtliche Konsequenzen haben.

Sinkende Vertrauenswürdigkeit: Wenn Nutzer merken, dass Antworten veraltet sind, verlieren sie das Vertrauen in das System. Das ist schwer wieder aufzubauen.

Strategie 1: Vollständiger Neuaufbau

Der vollständige Neuaufbau, auch Full Rebuild genannt, ist die einfachste Strategie. Du löschst alle Daten aus der Vektordatenbank und lädst alle Dokumente neu ein. Jedes Dokument wird neu in Chunks aufgeteilt, jedes Chunk neu eingebettet und gespeichert.

Wann ist das sinnvoll?

• Beim ersten Aufbau des Systems.
• Wenn sich Dein Chunking-Verfahren oder Embedding-Modell geändert hat.
• Wenn die Datenbank fehlerhaft oder inkonsistent ist.
• Bei kleinen Wissensbeständen, die sich ohnehin schnell neu aufbauen lassen.
• Wenn Du keine Nachverfolgung hast und nicht weißt, was sich geändert hat.

Vorteile:

• Einfach umzusetzen, kein Tracking von Änderungen nötig.
• Garantiert konsistenter Zustand danach.
• Keine veralteten Einträge mehr.

Nachteile:

• Bei großen Wissensbeständen dauert es lange.
• Jedes Dokument muss neu eingebettet werden, was Rechenleistung kostet.
• Während des Neuaufbaus ist das System nicht nutzbar.

Ein Full Rebuild ist wie ein Frischluft-Kick für Deine Datenbank. Für kleine Projekte oder seltene Wartungsintervalle ist er völlig ausreichend.

Strategie 2: Inkrementelle Updates

Inkrementelle Updates sind die effizientere Strategie für größere Wissensbestände. Statt alles neu zu laden, aktualisierst Du nur das, was sich geändert hat. Neue Dokumente werden hinzugefügt, geänderte werden ersetzt, entfernte werden gelöscht.

Wann ist das sinnvoll?

• Bei großen Wissensbeständen, die ein Full Rebuild zu lange dauern würde.
• Wenn sich Dokumente häufig ändern, aber nur in kleinen Teilen.
• Wenn Du ein System zur Änderungserkennung hast.
• Wenn das System während der Aktualisierung verfügbar bleiben muss.

Vorteile:

• Viel schneller als ein Full Rebuild.
• Geringerer Rechenaufwand, da nur geänderte Dokumente neu eingebettet werden.
• System bleibt nutzbar.

Nachteile:

• Komplexer zu implementieren.
• Erfordert Nachverfolgung, welches Dokument in welcher Version vorliegt.
• Fehler in der Erkennung führen zu veralteten Einträgen.

Inkrementelle Updates sind die Strategie der Wahl für produktive Systeme, die kontinuierlich gepflegt werden müssen.

Schritt 1: Neue Dokumente hinzufügen

Das Hinzufügen neuer Dokumente funktioniert im Prinzip wie der erste Aufbau. Du durchläufst die bekannten Schritte aus Dokumente vorbereiten:

1. Vorbereiten: Dokument laden, bereinigen und prüfen. Entferne unnötige Formatierungen, stelle sicher, dass der Text lesbar ist.
2. Chunking: Teile das Dokument in Abschnitte auf, wie in Chunking beschrieben.
3. Embedding: Wandle jeden Chunk mit Deinem Embedding-Modell in einen Vektor um.
4. Speichern: Füge die Vektoren zusammen mit Metadaten in die Vektordatenbank ein.

Wichtig ist, dass Du Metadaten mitgibst. Mindestens diese Felder solltest Du speichern:

• source: Pfad oder URL des Originaldokuments.
• version: Version oder Datum des Dokuments.
• chunk_id: Eindeutige ID für den Chunk.
• created_at: Zeitpunkt des Hinzufügens.

Mit diesen Metadaten kannst Du später gezielt aktualisieren oder löschen.

Ein einfaches Beispiel mit Chroma:

import chromadb

client = chromadb.PersistentClient(path="./vectordb")
collection = client.get_or_create_collection("wissen")

collection.add(
    documents=["Urlaubsregelung 2026: 28 Tage pro Jahr"],
    metadatas=[{"source": "handbuch.pdf", "version": "2026-08", "chunk_id": "handbuch_001"}],
    ids=["handbuch_001"]
)

Schritt 2: Geänderte Dokumente aktualisieren

Wenn sich ein Dokument ändert, reicht es nicht, einfach die neue Version hinzuzufügen. Sonst hast Du alte und neue Chunks gleichzeitig in der Datenbank, was zu widersprüchlichen Antworten führt.

Der richtige Ablauf:

1. Änderung erkennen: Vergleiche die aktuelle Version des Dokuments mit der gespeicherten. Dafür eignen sich Hash-Werte oder Versionsnummern.
2. Alte Chunks löschen: Entferne alle Chunks, die zur alten Version gehören. Du kannst sie über die Metadaten finden, zum Beispiel über source und version.
3. Neue Chunks hinzufügen: Teile das aktualisierte Dokument auf, bette es ein und speichere es mit der neuen Versionsnummer.

Viele Vektordatenbanken unterstützen Upsert, also das gleichzeitige Aktualisieren und Einfügen. Bei Chroma sieht das so aus:

# Alte Chunks für dieses Dokument löschen
collection.delete(
    where={"source": "handbuch.pdf"}
)

# Neue Version hinzufügen
collection.add(
    documents=["Neue Urlaubsregelung 2026: 28 Tage pro Jahr"],
    metadatas=[{"source": "handbuch.pdf", "version": "2026-09", "chunk_id": "handbuch_001"}],
    ids=["handbuch_001"]
)

Alternativ kannst Du upsert verwenden, wenn Deine Datenbank es unterstützt. Upsert überschreibt bestehende IDs und fügt neue hinzu.

Schritt 3: Veraltete Dokumente entfernen

Manchmal werden Dokumente komplett ungültig. Ein Produkt wird eingestellt, eine Richtlinie wird zurückgezogen, ein Vertrag läuft aus. In diesen Fällen musst Du die entsprechenden Chunks aus der Datenbank entfernen.

Du kannst auf verschiedene Arten löschen:

Nach Quelle: Lösche alle Chunks, die zu einem bestimmten Dokument gehören.

collection.delete(where={"source": "altes_handbuch.pdf"})

Nach Datum: Lösche alle Chunks, die vor einem bestimmten Datum hinzugefügt wurden.

collection.delete(where={"created_at": {"$lt": "2026-01-01"}})

Nach Metadaten: Lösche alle Chunks, die eine bestimmte Eigenschaft haben, zum Beispiel eine alte Version.

collection.delete(where={"version": "2025-12"})

Wichtig: Lösche nicht blind alles, was alt ist. Manche Dokumente sind auch nach Jahren noch gültig. Prüfe vor dem Löschen, ob das Dokument wirklich veraltet ist.

Versionierung und Nachverfolgbarkeit

Versionierung ist der Schlüssel zu einer sauberen Aktualisierung. Ohne sie weißt Du nicht, welche Version eines Dokuments in der Datenbank liegt, und Du kannst nicht gezielt aktualisieren.

Eine einfache Versionierung speichert zu jedem Chunk folgende Metadaten:

• source: Woher kommt das Dokument?
• version: Welche Version ist es? Das kann eine Nummer, ein Datum oder ein Hash-Wert sein.
• updated_at: Wann wurde es zuletzt aktualisiert?

So kannst Du jederzeit abfragen, welche Versionen in der Datenbank sind:

results = collection.get(
    where={"source": "handbuch.pdf"},
    include=["metadatas"]
)

for item in results["metadatas"]:
    print(item["version"], item["updated_at"])

Eine fortgeschrittene Versionierung arbeitet mit Hash-Werten. Du berechnst einen Hash über den Inhalt des Dokuments und speicherst ihn. Wenn sich der Inhalt ändert, ändert sich auch der Hash. So erkennst Du Änderungen zuverlässig, ohne manuell vergleichen zu müssen.

Automatisierung

Manuelle Aktualisierung funktioniert für kleine Wissensbestände. Sobald Du aber dutzende oder hunderte Dokumente hast, wird es mühsam. Automatisierung hilft hier.

Cron-Jobs: Richte einen regelmäßigen Job ein, der Deinen Dokumentenordner prüft. Der Job vergleicht die aktuellen Dateien mit den gespeicherten Versionen und aktualisiert die Datenbank bei Bedarf.

Watch-Folder: Ein Skript überwacht einen Ordner auf Änderungen. Sobald eine Datei hinzugefügt, geändert oder gelöscht wird, wird die Datenbank automatisch aktualisiert.

Ein einfaches Beispiel für einen Cron-Job mit Python:

import os
import hashlib
import chromadb

def datei_hash(pfad):
    with open(pfad, "rb") as f:
        return hashlib.md5(f.read()).hexdigest()

def aktualisiere_wissensbestand(ordner, collection):
    for dateiname in os.listdir(ordner):
        pfad = os.path.join(ordner, dateiname)
        if not os.path.isfile(pfad):
            continue

        hash_wert = datei_hash(pfad)

        # Pruefen, ob sich etwas geaendert hat
        bestehend = collection.get(
            where={"source": dateiname},
            include=["metadatas"]
        )

        if bestehend["metadatas"]:
            aktueller_hash = bestehend["metadatas"][0].get("hash")
            if aktueller_hash == hash_wert:
                continue  # Keine Aenderung

            # Alte Version loeschen
            collection.delete(where={"source": dateiname})

        # Neue Version hinzufuegen
        with open(pfad, "r", encoding="utf-8") as f:
            text = f.read()

        collection.add(
            documents=[text],
            metadatas=[{"source": dateiname, "hash": hash_wert, "version": hash_wert[:8]}],
            ids=[dateiname]
        )

client = chromadb.PersistentClient(path="./vectordb")
collection = client.get_or_create_collection("wissen")
aktualisiere_wissensbestand("./dokumente", collection)

Dieses Skript ist ein Ausgangspunkt. Für produktive Nutzung solltest Du es um Fehlerbehandlung, Logging und ein geeignetes Chunking erweitern.

Typische Stolpersteine bei der Aktualisierung

1. Keine Metadaten gespeichert: Ohne Metadaten kannst Du gezielt weder aktualisieren noch löschen. Du musst dann einen Full Rebuild machen. Speichere immer mindestens source und version.

2. Alte Versionen nicht gelöscht: Wenn Du eine neue Version hinzufügst, ohne die alte zu entfernen, hast Du Duplikate mit unterschiedlichen Inhalten. Das führt zu widersprüchlichen Antworten.

3. Änderungen nicht erkannt: Wenn Du kein System zur Änderungserkennung hast, aktualisierst Du entweder zu oft (unnötiger Aufwand) oder zu selten (veraltete Daten). Hash-Werte oder Versionsnummern lösen dieses Problem.

4. Embedding-Modell gewechselt, Daten nicht neu aufgebaut: Wenn Du ein anderes Embedding-Modell verwendest, sind die alten Vektoren nicht mehr kompatibel. Du musst einen Full Rebuild machen, sonst sind die Suchergebnisse unbrauchbar.

5. Chunking geändert, IDs nicht angepasst: Wenn Du Dein Chunking-Verfahren änderst, ändern sich auch die Chunk-Grenzen. Alte Chunk-IDs passen nicht mehr zu den neuen Chunks. Lösche die alten Chunks und füge die neuen hinzu.

6. Kein Backup vor der Aktualisierung: Wenn bei der Aktualisierung etwas schiefgeht, sind Deine Daten möglicherweise verloren. Mach vorher ein Backup der Vektordatenbank.

7. Gleichzeitige Schreibzugriffe: Wenn mehrere Prozesse gleichzeitig in die Datenbank schreiben, kann es zu Konflikten kommen. Sperre die Datenbank während der Aktualisierung oder nutze eine Queue.

8. Vergessene Dokumente in Unterordnern: Wenn Dein Skript nur den Hauptordner durchsucht, bleiben Dokumente in Unterordnern unberücksichtigt. Achte darauf, rekursiv zu suchen.

Hardware, Kosten und Sicherheit bei der Aktualisierung

Hardware: Die Aktualisierung benötigt vor allem Rechenleistung für das Embedding. Wenn Du viele Dokumente auf einmal aktualisierst, kann das Deine CPU oder GPU auslasten. Bei inkrementellen Updates ist der Aufwand gering, da nur wenige Dokumente neu eingebettet werden. Ein Full Rebuild bei großen Beständen kann mehrere Stunden dauern.

Kosten: Bei lokaler Ausführung entstehen keine direkten Kosten, außer Strom und Verschleiß. Wenn Du Cloud-Embeddings nutzt, kostet jeder Aufruf Geld. Inkrementelle Updates sind hier deutlich günstiger als ein Full Rebuild.

Sicherheit: Alle Daten bleiben auf Deinem Rechner, solange Du Embedding-Modell und Vektordatenbank lokal betreibst. Das ist einer der großen Vorteile von lokaler KI. Achte darauf, dass Backups verschlüsselt sind, besonders wenn sie sensible Dokumente enthalten.

Weiterführende Links und Infos zur Aktualisierung

• Lokales RAG - Übersicht aller RAG-Artikel.
• RAG Grundlagen - Wie die Bausteine zusammenwirken.
• Dokumente vorbereiten - Bevor Du aktualisieren kannst, müssen Dokumente sauber vorliegen.
• Chunking - Die Aufteilung beeinflusst, wie Du aktualisierst.
• Embedding-Modelle - Beim Modellwechsel musst Du neu aufbauen.
• Vektordatenbanken - Die Datenbank ist Dein Speicherort.
• RAG-Qualität testen - Nach der Aktualisierung solltest Du die Qualität prüfen.

FAQ: Wissensbestand aktualisieren - Typische Fragen

Wie oft sollte ich meinen Wissensbestand aktualisieren?

Das hängt davon ab, wie oft sich Deine Dokumente ändern. Bei täglich wechselnden Inhalten ist eine tägliche Aktualisierung sinnvoll. Bei stabilen Dokumenten reicht eine wöchentliche oder monatliche Aktualisierung.

Full Rebuild oder inkrementelle Updates, was ist besser?

Für kleine Wissensbestände oder beim Wechsel von Embedding-Modell oder Chunking-Strategie ist ein Full Rebuild einfacher. Für große, kontinuierlich gepflegte Bestände sind inkrementelle Updates effizienter.

Was passiert, wenn ich alte Chunks nicht lösche?

Die Datenbank enthält dann alte und neue Versionen gleichzeitig. Das RAG-System kann widersprüchliche Antworten liefern, weil es nicht weiß, welche Version aktuell ist.

Wie erkenne ich, ob sich ein Dokument geändert hat?

Die einfachste Methode ist ein Hash-Wert über den Dateiinhalt. Ändert sich der Inhalt, ändert sich auch der Hash. Alternativ kannst Du Versionsnummern oder Änderungsdaten der Datei nutzen.

Muss ich die Vektordatenbank nach jedem Update neu starten?

Nein, die meisten Vektordatenbanken unterstützen Aktualisierungen im laufenden Betrieb. Bei großen Full Rebuilds kann es sinnvoll sein, die Datenbank kurz zu sperren, um Konflikte zu vermeiden.

Kann ich die Aktualisierung automatisieren?

Ja, mit Cron-Jobs oder Skripten, die einen Ordner überwachen. Bei Änderungen wird die Datenbank automatisch aktualisiert. Das ist für produktive Systeme empfehlenswert.

Was mache ich, wenn ich das Embedding-Modell wechsle?

Du musst einen Full Rebuild durchführen. Die alten Vektoren sind mit dem neuen Modell nicht kompatibel, da jedes Modell Vektoren mit unterschiedlicher Bedeutung und Dimension erzeugt.

Wie gehe ich mit gelöschten Dokumenten um?

Lösche alle Chunks, die zur Quelle des gelöschten Dokuments gehören. Nutze dafür die Metadaten, typischerweise das Feld source, um die entsprechenden Einträge zu finden und zu entfernen.

Brauche ich ein Backup vor der Aktualisierung?

Ja, unbedingt. Wenn bei der Aktualisierung etwas schiefgeht, kannst Du so den vorherigen Zustand wiederherstellen. Besonders bei Full Rebuilds ist ein Backup unerlässlich.

Wie teste ich, ob die Aktualisierung erfolgreich war?

Stelle Testfragen, deren Antworten Du kennst, und prüfe, ob das System die aktuellen Informationen liefert. Mehr dazu im Artikel RAG-Qualität testen.

Was sind Metadaten und warum sind sie wichtig?

Metadaten sind zusätzliche Informationen zu jedem Chunk, wie Quelle, Version oder Datum. Sie ermöglichen es Dir, gezielt zu aktualisieren und zu löschen, ohne die gesamte Datenbank neu aufzubauen.

Quellen und weiterführende Literatur

• Chroma Documentation: Collections und Metadata
• Qdrant Documentation: Points und Filtering
• LangChain Documentation: Document Loaders und Vector Stores
• LlamaIndex Documentation: Index Management