Embeddings versionieren und ohne Downtime neu indizieren

Das Embedding-Modell zu wechseln entwertet jeden Vektor, den Sie gespeichert haben, denn Distanzen zwischen Vektoren aus zwei verschiedenen Modellen bedeuten nichts. Eine mit dem neuen Modell embeddete Query ordnet alte Vektoren nach reinem Rauschen. Also embedden Sie den gesamten Korpus in einen versionierten Index neu, lassen den alten weiter den Live-Traffic bedienen und schalten erst dann um, wenn ein Eval-Set bestätigt, dass der neue mindestens genauso gut abruft.

Die Falle besteht darin, Embeddings als dauerhafte Daten zu behandeln. Sie sind ein abgeleitetes Artefakt, wie ein kompiliertes Binary. Die Source of Truth sind Ihre Chunks und deren Metadaten; die Vektoren sind eine Funktion dieser Chunks und eines bestimmten Modells in einer bestimmten Version. Ändert sich die Funktion, ist das Ergebnis veraltet, und zwar alles auf einmal. Teams, die Embeddings speichern, ohne festzuhalten, welches Modell sie erzeugt hat, lernen das auf die harte Tour beim ersten Upgrade, meist dann, wenn die Retrieval-Qualität abstürzt und nichts in den Logs erklärt, warum.

Warum ein Upgrade ein vollständiges Neu-Embedding ist, kein Patch

Sie können nichts nachträglich auffüllen. Es gibt keine clevere Migration, die nur die geänderten Dokumente neu embeddet und den Rest in Ruhe lässt. Ein Vektor aus text-embedding-3-large und ein Vektor aus einem neueren Modell leben nicht im selben Raum, haben häufig nicht einmal dieselbe Dimensionalität, und ihre Cosine-Distanzen liegen auf Skalen, die Sie nicht vergleichen können. Sie in einem Index zu mischen bedeutet, dass eine Query Passagen selbstbewusst nach einem Artefakt ordnet, nämlich danach, welches Modell sie zufällig embeddet hat. Das ist das Retrieval-Äquivalent dazu, Preise in zwei Währungen ohne Wechselkurs zu vergleichen.

Jeder Modellwechsel erzwingt also eine Entscheidung, die Sie bewusst treffen sollten, statt in sie hineinzustolpern:

• Das Embedding-Modell selbst ändert sich. Ein Anbieter setzt eine Version außer Betrieb, oder Sie wechseln von einem gehosteten Modell zu einem selbst betriebenen, um die Abhängigkeit von Dritten zu reduzieren, genau jene Art von ICT-Konzentrationsrisiko, dessen Steuerung DORA von einem Finanzunternehmen erwartet. Vollständiges Neu-Embedding.
• Die Chunking-Strategie ändert sich. Andere Grenzen oder Fenstergrößen bedeuten anderen Eingabetext, also andere Vektoren. Vollständiges Neu-Embedding und in der Regel eine erneute Evaluierung der Retrieval-Qualität, denn Chunking bewegt die Qualität stärker als das Modell.
• Das Preprocessing ändert sich. Sie beginnen, Boilerplate zu entfernen, Tabellen zu normalisieren oder Entitätsnamen aufzulösen, bevor Sie embedden. Der Eingabetext hat sich geändert, also sind die Vektoren veraltet.

Beachten Sie, dass zwei dieser drei Punkte nichts mit dem Modell zu tun haben. Alles, was den an den Embedder übergebenen Text verändert, entwertet das Ergebnis. Deshalb behandeln Sie den Embedding-Schritt als reine, versionierte Funktion und halten seine vollständige Signatur fest, nicht nur den Modellnamen.

Versionieren Sie das Artefakt, nicht nur den Modellnamen

Jeder gespeicherte Vektor muss genug Lineage tragen, um eine Frage zu beantworten: Was genau hat dich erzeugt? In der Praxis ist das ein kompakter Versionsschlüssel, der an jeden Vektor und an den Index als Ganzes gehängt wird. Wir halten vier Dinge fest:

• Das Embedding-Modell und seinen exakten Versions-String, niemals einen fließenden Alias, den ein Anbieter stillschweigend umbiegen kann.
• Die Chunking-Strategie und ihre Parameter: Grenzregeln, Ziel-Tokenlänge, Overlap.
• Die Version der Preprocessing-Pipeline, als Hash oder Tag des Normalisierungs- und Entitätsauflösungs-Codes.
• Die Dimensionalität und die Distanzmetrik, damit eine Diskrepanz zur Query-Zeit laut fehlschlägt, statt Müll zurückzugeben.

Bündeln Sie das in einen einzigen embedding_version-Identifier und stempeln Sie ihn auf den Index. Jetzt kann der Query-Pfad sicherstellen, dass der für die Query erzeugte Vektor und der durchsuchte Index dieselbe Version teilen. Stimmen sie nicht überein, wirft die Query einen Fehler, statt plausiblen Unsinn zurückzugeben. Diese Prüfung verdient sich ihren Platz im Finanzbereich. Eine falsche Passage, die abgerufen wird, weil Query- und Index-Version auseinandergedriftet sind, ist der Fehlertyp “selbstsicherer Satz mit falscher Zahl”: in einer Demo unsichtbar, in einem Audit teuer.

Diese Lineage direkt neben den Chunk-Metadaten zu halten, statt in einer separaten Registry, die Sie abgleichen müssen, bedeutet, dass die Antwort auf “Welches Modell hat die Passage hinter dieser Antwort embeddet?” ein Lookup ist, keine Untersuchung. Wenn Sie jemand bittet, in sechs Monaten zu rekonstruieren, warum eine RAG-gestützte Antwort so ausgefallen ist, wie sie ausgefallen ist, ist diese Lineage Ihr Audit-Trail.

Der Cutover: daneben aufbauen, beweisen, dann umschalten

Neu zu indizieren ohne Downtime ist ein Blue-Green-Deployment, angewandt auf Vektoren. Sie mutieren den Live-Index niemals an Ort und Stelle. Sie bauen einen neuen daneben auf und leiten den Traffic erst um, wenn er sich den Wechsel verdient hat.

Die Sequenz, die wir fahren:

1. Den neuen Index kalt aufbauen. Embedden Sie den gesamten Korpus neu in einen frischen Index oder Namespace, getaggt mit der neuen embedding_version. Das läuft im Hintergrund gegen einen Snapshot der Chunks und rührt den Index, der die Produktion bedient, nie an. Es kann Stunden dauern, was in Ordnung ist, weil niemand darauf wartet.
2. Das Delta einfrieren und abgleichen. Dokumente, die während des Backfills ingested wurden, müssen ebenfalls embeddet werden. Verfolgen Sie Ingestion-Zeitstempel und embedden Sie dieses Delta vor dem Cutover in den neuen Index, damit ihm nicht die letzten Stunden an Einreichungen fehlen.
3. Evaluieren, bevor irgendjemand ihm vertraut. Lassen Sie ein festes Eval-Set aus echten Queries mit bekannt korrekten Passagen gegen den alten und den neuen Index laufen. Vergleichen Sie Recall bei Ihrem Produktions-Scoping und reranked Precision. Gewinnt oder gleicht das neue Modell nicht, halten Sie hier an und haben nichts verloren, weil der alte Index nie aufgehört hat zu bedienen. Schalten Sie niemals auf Basis eines Anbieter-Benchmarks um; messen Sie auf Ihrem Korpus.
4. Den Pointer atomar umlegen. Der Cutover ist eine einzige Änderung daran, aus welchem Index der Query-Pfad liest, ein Config-Flag oder ein Alias-Swap. Ein Request liest den alten Index; der nächste liest den neuen. Es existiert kein Fenster, in dem eine Query eine Mischung sieht.
5. Den alten Index für den Rollback warm halten. Behalten Sie ihn für einen definierten Zeitraum. Driftet die reranked Precision oder regressiert die Latenz in der Produktion, legen Sie den Pointer in Sekunden zurück. Erst nachdem der neue Index sich bewährt hat, geben Sie den Speicher des alten frei, was bei HNSW die teure Ressource ist.

Bei einem großen Korpus können Sie vor dem Umschalten Shadow-Reads durchführen. Schicken Sie eine Stichprobe der Live-Queries an beide Indizes, loggen Sie beide Result-Sets und diffen Sie sie offline. Das fängt Regressionen ab, die das Eval-Set verpasst hat, weil echter Query-Traffic immer seltsamer ist als Ihr Eval-Set. Achten Sie besonders auf die Exact-Token-Identifier-Queries, die CUSIPs, LEIs und Abschnittsverweise, bei denen eine Änderung des Dense-Modells das Verhalten unauffällig verschieben kann.

Machen Sie das oft genug, und Neuindizierung ist nicht länger das Ereignis, vor dem Sie sich zum Quartalsende fürchten, sondern wird zur Routinewartung. Was es zur Routine macht, ist dasselbe, was es sicher macht. Die Vektoren sind wegwerfbar; die Chunks und ihre Lineage sind es nicht; und keine Query berührt je einen Index, dessen Version sie nicht verifizieren kann.