Wechsel des RAG-Embedding-Modells? Planen Sie die Vektormigration vor dem Umstieg
Ein Wechsel des Embedding-Modells betrifft sowohl gespeicherte Dokumentvektoren als auch eingehende Anfragevektoren. Mit diesem gestuften Plan erfassen Sie Ihre Konfiguration, erstellen und prüfen einen Index neu und wechseln kontrolliert – mit Rückfalloption.
Behandeln Sie einen Embedding-Wechsel wie eine Datenmigration
Ein RAG-System erzeugt typischerweise Embeddings aus Quellinhalten, um diese zu speichern, und aus Nutzeranfragen, um passende Inhalte abzurufen. Ein Wechsel des Embedding-Modells verändert einen wichtigen Teil dieses Ablaufs. Gehen Sie nicht davon aus, dass bereits in einem Index gespeicherte Vektoren mit Anfragen, die durch ein anderes Modell oder eine andere Konfiguration eingebettet wurden, korrekt funktionieren.
Die sichere betriebliche Grundregel lautet, das Verhalten beim Einbetten von Dokumenten und Anfragen aufeinander abzustimmen und behauptete Kompatibilität zu überprüfen, bevor Sie sich darauf verlassen. Ähnlichkeitswerte aus zwei unterschiedlichen Modellkonfigurationen sollten nicht als direkt vergleichbar betrachtet werden, es sei denn, Sie haben diesen Vergleich für Ihr System getestet.
Deshalb reicht eine Änderung der Modelleinstellung allein nicht als Migrationsplan aus. Die RAG-Leitlinien von NVIDIA besagen, dass Dokumente nach der Aufnahme erneut eingelesen werden müssen, wenn das Embedding-Modell oder die Dimensionen geändert werden, damit der Abruf korrekt funktioniert. Qdrant dokumentiert einen Migrationsansatz, bei dem Daten in eine neue Collection kopiert und Vektoren erneut eingebettet werden, während die Suche weiterläuft.
- Ermitteln Sie genau, welches Modell und welche Konfiguration für die aktuellen Dokumentvektoren verwendet wurden.
- Planen Sie, wie sowohl gespeicherte Dokumente als auch eingehende Anfragen das neue Embedding-Setup verwenden werden.
- Halten Sie den bestehenden, funktionierenden Index verfügbar, bis der Ersatz alle Prüfungen bestanden hat.
Erfassen Sie vor dem Neuaufbau den gesamten Retrieval-Pfad
Halten Sie zunächst fest, wie Daten vom Quellinhalt bis zu den abgerufenen Textpassagen fließen. Ein Index-Neuaufbau kann unvollständig sein, auch wenn der Embedding-Aufruf erfolgreich ist: Der Quellbestand kann sich geändert haben, Metadaten können fehlen oder der Anfragepfad kann noch die vorherige Konfiguration verwenden.
Dokumentieren Sie die aktuellen und geplanten Einstellungen an einem zentralen Ort. Halten Sie Modellkennungen und alle Konfigurationen fest, die sich auf die Embedding-Ausgabe auswirken, außerdem die erwarteten Vektordimensionen, Textextraktions- und Chunking-Schritte, Metadatenfelder und Retrieval-Einstellungen. Notieren Sie, wie Dokumente identifiziert und aktualisiert werden, damit Sie den neu erstellten Index mit dem vorgesehenen Korpus vergleichen können.
Behandeln Sie die Vorverarbeitung als Teil des Embedding-Setups. Wenn Dokumenttext während der Migration anders aufgeteilt oder normalisiert wird, können Änderungen beim Retrieval sowohl auf diese Unterschiede als auch auf den Modellwechsel zurückzuführen sein. Machen Sie solche Änderungen ausdrücklich kenntlich, anstatt sie in einem nicht nachvollziehbaren Wechsel zu bündeln.
- Korpus: Quellorte, Dokumentkennungen, erwartete Anzahl an Elementen oder Chunks sowie ausgeschlossene Inhalte.
- Embedding: aktuelles und vorgesehenes Modell, Konfiguration, Dimensionen und Pfad für Anfrage-Embeddings.
- Verarbeitung: Textextraktion, Chunking, Texttransformationen sowie der Umgang mit Aktualisierungen und Löschungen.
- Index und Retrieval: Name der Collection oder des Index, Metadaten- und Filterfelder sowie Sucheinstellungen.
- Betrieb: Neuaufbau-Auftrag, Zugriffsberechtigungen, verfügbarer Speicherplatz und eine Möglichkeit, Fehler zu untersuchen.
Wählen Sie eine Migrationsform, bei der ein funktionierender Zustand erhalten bleibt
Der passende Migrationsansatz hängt davon ab, ob Ihr System mehrere Indizes parallel vorhalten kann, wie groß der Korpus ist und wie häufig er aktualisiert wird sowie wie viel Unterbrechung Ihre Anwendung verkraftet. Die bereitgestellten Anbieterhinweise unterstützen ein Migrationsmuster mit einer neuen Collection, legen aber keine Strategie als die beste für jede Bereitstellung fest.
Ein vollständiger Neuaufbau kann unkompliziert sein, wenn Sie ein Wartungsfenster einplanen und den alten Index behalten können, bis der neue geprüft wurde. Ein paralleler Index ist sinnvoll, wenn Sie das Retrieval-Verhalten vergleichen oder während des Neuaufbaus weiterhin den bestehenden Index verwenden müssen. Eine Migration mit begrenztem Umfang kann helfen, die Pipeline anhand einer repräsentativen Teilmenge zu testen. Sie beweist jedoch nicht, dass der gesamte Korpus neu aufgebaut oder validiert wurde.
Entscheiden Sie bewusst, dokumentieren Sie die Abwägungen und löschen oder überschreiben Sie nicht als ersten Schritt den einzigen funktionierenden Index. Wenn die Plattform den gewünschten Ansatz nicht unterstützt, berücksichtigen Sie diese Einschränkung, bevor Sie beginnen.
- Verwenden Sie einen vollständigen Neuaufbau, wenn eine kontrollierte Unterbrechung akzeptabel ist und Sie den vorherigen Index erhalten können.
- Verwenden Sie parallele Indizes, wenn der bestehende Retrieval-Pfad während des Neuaufbaus und der Validierung verfügbar bleiben muss.
- Nutzen Sie einen begrenzten Pilotversuch, um den Prozess zu testen, und planen und prüfen Sie anschließend separat die vollständige Migration.
- Klären Sie Kapazität, Schreibverhalten während des Neuaufbaus und die Methode, mit der Anfragen an den vorgesehenen Index geleitet werden.
Betten Sie konsistent erneut ein und verfolgen Sie die Abdeckung
Erstellen Sie den neuen Index mit der vorgesehenen Konfiguration für Dokument-Embeddings und richten Sie das Anfrage-Embedding passend dazu ein, bevor Sie das Retrieval für diesen Index testen. Prüfen Sie, ob die erzeugten Dimensionen den Erwartungen des Index entsprechen. Eine Dimensionsabweichung ist eine konkrete Inkompatibilität, die erkannt werden sollte, bevor Live-Anfragen weitergeleitet werden.
Protokollieren Sie, was verarbeitet wurde und was fehlgeschlagen ist. Vergleichen Sie die neu erstellten Inhalte anhand stabiler Dokument- oder Chunk-Kennungen, sofern verfügbar, mit dem vorgesehenen Korpus. Klären Sie fehlende Elemente, Duplikate, übersprungene Datensätze und während des Auftrags geänderte Dokumente, statt einen abgeschlossenen Prozess als Beweis für eine vollständige Abdeckung zu betrachten.
Wenn sich Quellinhalte während des Neuaufbaus ändern können, legen Sie fest, wie diese Änderungen in den neuen Index gelangen. Je nach System kann es sinnvoll sein, Schreibvorgänge zu pausieren, Änderungen zur späteren Anwendung zu protokollieren oder Aktualisierungen als Teil der Migration in das Ziel zu übernehmen. Testen Sie das gewählte Verfahren, statt anzunehmen, dass das Ziel stets aktuell bleibt.
- Verwenden Sie für alle Dokumentvektoren im neuen Index dieselbe vorgesehene Embedding-Konfiguration.
- Verwenden Sie beim Abfragen dieses Index die entsprechende Konfiguration für Anfrage-Embeddings.
- Prüfen Sie die Dimensionen und bestätigen Sie, dass der Index das erwartete Vektorformat akzeptiert.
- Verfolgen Sie verarbeitete, fehlgeschlagene, übersprungene, geänderte und doppelte Datensätze.
- Gleichen Sie während des Neuaufbaus vorgenommene Aktualisierungen an den Quellen vor dem Wechsel ab.
Validieren Sie das Retrieval, bevor Sie Nutzer auf den neuen Index umstellen
Bei der Validierung sollte nicht nur geprüft werden, ob der neue Index Anfragen akzeptiert. Erstellen Sie vor dem Neuaufbau eine Reihe repräsentativer Fragen und erwarteter Quelldokumente oder Textpassagen. Berücksichtigen Sie häufige Anfragen, Anfragen, die von wichtigen Metadatenfiltern abhängen, sowie Fälle, in denen die richtige Quelle weniger offensichtlich ist.
Führen Sie diese Prüfungen über denselben Anfrage-Embedding- und Retrieval-Pfad aus, den Ihre Anwendung verwenden wird. Untersuchen Sie die abgerufenen Textpassagen und ihre Metadaten, nicht nur eine abschließende Antwort: Eine plausibel klingende Antwort kann eine fehlende, irrelevante oder falsch gefilterte Quelle verbergen. Vergleichen Sie den alten und den neuen Pfad als getrennte Systeme und legen Sie fest, was für Ihren Anwendungsfall als akzeptables Ergebnis gilt. Vergleichen Sie nicht einfach rohe Ähnlichkeitswerte, als hätten sie eine gemeinsame Skala.
Prüfen Sie neben der Retrieval-Qualität auch die Abdeckung des Korpus. Ein gutes Ergebnis bei einer kleinen Testmenge belegt nicht, dass jedes vorgesehene Dokument indexiert wurde. Halten Sie Testfälle, Ergebnisse und ungeklärte Unterschiede fest, damit die Entscheidung über den Wechsel nachvollziehbar ist.
- Bestätigen Sie, dass repräsentative Dokumente im neuen Index vorhanden sind.
- Prüfen Sie das erwartete Retrieval für repräsentative Anfragen und untersuchen Sie die tatsächlich zurückgegebenen Textpassagen.
- Überprüfen Sie Metadatenfilter und alle wichtigen Zugriffs- oder Bereichsbeschränkungen, die beim Retrieval verwendet werden.
- Prüfen Sie für Ihre Anwendung relevante leere, mehrdeutige und fehlerhafte Fälle.
- Vereinbaren Sie vor den Tests Akzeptanzkriterien und halten Sie alle Ausnahmen fest.
Wechseln Sie kontrolliert und behalten Sie eine Rückfalloption
Behandeln Sie den Wechsel des Index als bewusst geplanten betrieblichen Schritt. Halten Sie fest, welchen Index und welche Embedding-Konfiguration die Anwendung verwendet, und ändern Sie den Anfragepfad als abgestimmtes Paar. Wenn Anfragen an den neuen Index geleitet werden, das Anfrage-Embedding aber auf der alten Konfiguration bleibt, kann die bisherige Arbeit zunichtegemacht werden.
Bewahren Sie den vorherigen Index samt seiner Konfiguration während des vereinbarten Beobachtungszeitraums unverändert auf. Legen Sie fest, wer einen Rollback einleiten darf, welche Erkenntnisse ihn auslösen und wie die Anwendung auf den vorherigen funktionierenden Pfad zurückgestellt wird. Wenn während oder nach dem Wechsel weiterhin Daten geändert werden, berücksichtigen Sie diese Änderungen im Rollback-Plan, damit beim Zurückschalten zum alten Index nicht unbemerkt neuere Inhalte verloren gehen.
Räumen Sie den vorherigen Index erst auf, wenn der neue Pfad akzeptiert wurde, ein Rollback nicht mehr erforderlich ist und Aufbewahrungs- oder Governance-Anforderungen berücksichtigt wurden. Ein Backup ist für die Wiederherstellungsplanung hilfreich, ersetzt aber weder einen getesteten Indexwechsel noch ein klares Rollback-Verfahren.
- Ändern Sie die Konfiguration für Anfrage-Embeddings und den Zielindex gemeinsam als kontrollierte Änderung.
- Überprüfen Sie den Live-Pfad unmittelbar nach dem Wechsel anhand einiger bekannter Anfragen.
- Halten Sie den vorherigen Index verfügbar, bis der neue Pfad die vereinbarten Akzeptanzkriterien erfüllt hat.
- Dokumentieren Sie die Rollback-Berechtigung, Auslöser, Schritte und den Umgang mit zwischenzeitlichen Datenänderungen.
- Legen Sie den Zeitpunkt für die Bereinigung erst nach der Abnahme und der Prüfung der Aufbewahrungsanforderungen fest.
Weisen Sie Verantwortlichkeiten zu und bewahren Sie die Migrationsdokumentation auf
Eine Embedding-Migration ist nicht abgeschlossen, sobald der Index umgeschaltet wurde. Benennen Sie eine verantwortliche Person für das Modell und die Vorverarbeitungskonfiguration, bei Bedarf zusätzlich eine zuständige Rolle für den Indexbetrieb, und legen Sie ein Verfahren fest, mit dem entschieden wird, wann zukünftige Änderungen am Modell oder an den Dimensionen einen Neuaufbau erfordern.
Bewahren Sie den Migrationsnachweis zusammen mit der Indexkonfiguration auf: Umfang des Quellkorpus, Modell und Dimensionen, Entscheidungen zur Vorverarbeitung, Abschluss- und Fehlerzahlen, Validierungsergebnisse, Zeitpunkt des Wechsels, Rollback-Anweisungen und Entscheidung zur Bereinigung. So hängt die spätere Fehlersuche weniger vom Erinnerungsvermögen ab, und eine Änderung am Embedding lässt sich besser von einer Änderung am Korpus oder Retrieval unterscheiden.
Hosting und Infrastrukturverwaltung können den Betriebsaufwand verringern. Sie entscheiden jedoch nicht, welche Dokumente in den Index gehören, welche Nutzer sie abrufen dürfen oder ob die Retrieval-Qualität akzeptabel ist. Airbip verwaltet beispielsweise die Bereitstellung von Kataloganwendungen als Docker-Workloads und stellt konfigurierbare Backups bereit. Teams müssen die RAG-Datenmigration, Zugriffsentscheidungen, Validierung und den Rollback für ihre eigene Konfiguration weiterhin selbst planen.
- Benennen Sie eine verantwortliche Person für die Embedding-Konfiguration und eine für den Indexbetrieb.
- Versionieren oder bewahren Sie anderweitig die Modell-, Vorverarbeitungs- und Retrieval-Einstellungen für jeden Index auf.
- Bewahren Sie ein Migrationsprotokoll und einen repräsentativen Validierungssatz für zukünftige Änderungen auf.
- Prüfen Sie Datenzugriff, Aufbewahrung und Backup-Entscheidungen unabhängig von der Modellkonfiguration.
Häufige Fragen
Muss ich Dokumente erneut einbetten, wenn ich das Embedding-Modell wechsle?
Planen Sie, die Dokumente für das neue Setup erneut einzubetten oder einzulesen, sofern die Kompatibilität nicht ausdrücklich unterstützt und für Ihr System validiert wurde. Laut der RAG-Dokumentation von NVIDIA müssen Dokumente nach der Aufnahme erneut eingelesen werden, wenn das Embedding-Modell oder die Dimensionen geändert werden, damit der Abruf korrekt funktioniert.
Kann der alte Index verfügbar bleiben, während ein neuer erstellt wird?
Das hängt von der Vektordatenbank und dem Bereitstellungsdesign ab. Qdrant dokumentiert einen Migrationsprozess, bei dem Daten in eine neue Collection kopiert, Vektoren erneut eingebettet und Suchanfragen während der Migration weiterhin ausgeführt werden können. Prüfen Sie das Verhalten und die betrieblichen Anforderungen Ihrer eigenen Konfiguration, bevor Sie sich auf einen ähnlichen Ansatz verlassen.
Kann ich Ähnlichkeitswerte der alten und der neuen Embedding-Modelle vergleichen?
Gehen Sie nicht davon aus, dass die Werte auf einer direkt vergleichbaren Skala liegen. Vergleichen Sie abgerufene Textpassagen anhand repräsentativer Anfragen und vereinbarter Akzeptanzkriterien. Behandeln Sie jedes Modell und jede Indexkonfiguration als eigenen Retrieval-Pfad, sofern Sie die Vergleichbarkeit der Werte nicht validiert haben.
Reicht ein erfolgreicher Neuaufbau aus, um den Wechsel freizugeben?
Nein. Prüfen Sie die Abdeckung, Fehler, Metadaten und Filter sowie die Retrieval-Ergebnisse für repräsentative Anfragen. Wechseln Sie anschließend die Konfiguration für Anfrage-Embeddings und den Index gemeinsam, überprüfen Sie den Live-Pfad und behalten Sie eine Rückfalloption, bis das neue Setup akzeptiert ist.