Das Embedding-Modell zu wechseln ist eine Migration, keine Einstellung
Die Änderung war eine Zeile. Die Folge war, dass die Hälfte unseres Index den ganzen Arbeitstag über im alten Vektorraum antwortete und die andere Hälfte im neuen — und das Symptom sah nach einem Qualitätsproblem aus statt nach einem Deployment-Problem.
Eine Zeile, ein schlechter Nachmittag
Wir haben den Dienst auf ein neueres Embedding-Modell gezeigt, ausgerollt und den Neuindexierungslauf im Hintergrund laufen lassen, wie er entworfen war. Dokumente wurden stapelweise neu eingebettet, und der Suchindex nahm die neuen Vektoren an, sobald sie eintrafen — neben den alten.
Innerhalb einer Stunde wurden die Ergebnisse merkwürdig. Manche Anfragen lieferten offensichtlich richtige Passagen, andere Material ohne erkennbaren Bezug zur Frage, und welches Verhalten man bekam, hing davon ab, ob der Stapellauf das betreffende Dokument schon erreicht hatte.
Warum die Mischung Unsinn ist
Zwei Embedding-Modelle legen Text in zwei unverbundene Koordinatensysteme. Ein Abstand zwischen einem Vektor des einen und einem des anderen ist eine Zahl, die die Datenbank bereitwillig berechnet und die überhaupt nichts bedeutet — die schlimmste Art von Fehler: kein Abbruch, keine Warnung, nur Ergebnisse.
Wir wussten das im Abstrakten. Nicht zu Ende gedacht hatten wir, dass eine schrittweise Migration beide Vektorarten gleichzeitig in denselben Index legt, das System also die gesamte Migration über Größen vergleicht, die nicht vergleichbar sind.
Was wir heute tun
Das neue Modell baut einen zweiten Index, während der alte weiter ausliefert. Nichts wird umgestellt, bevor der neue Index vollständig ist und gegen das Referenzset gelaufen ist, und die Umstellung selbst ist eine einzelne Zeigeränderung, die in Sekunden rückgängig zu machen ist.
Der alte Index bleibt eine Woche stehen. Das ist keine Vorsicht gegenüber dem Modell, sondern gegenüber allem drumherum: Ein vollständiger und korrekter Index kann trotzdem im Chunking, in den Metadaten oder in den Filtern falsch sein — und den vorherigen intakt zu haben macht aus einer schlechten Entdeckung ein Zurückrollen statt eines Neuaufbaus.
| Was eine Neuindexierung kostet | Im Einzelnen |
|---|---|
| Modellaufrufe | Jeder Chunk, einmal, für den ganzen Bestand |
| Speicher | Beide Indizes gleichzeitig, für die Überlappung |
| Laufzeit | Stunden bis Tage, je nach Bestandsgröße |
| Risiko | Eine stille Qualitätsänderung, wenn nicht gemessen wird |
Die Forschung und was sie verändert hat
Lee und Kollegen veröffentlichten in jenem Monat Gecko: ein kompaktes Text-Embedding-Modell, destilliert mithilfe eines großen Sprachmodells zur Erzeugung und Verfeinerung der Trainingsdaten, mit konkurrenzfähiger Retrieval-Qualität bei kleineren Embedding-Dimensionen als vergleichbare Modelle.
Der Punkt mit der Dimension war für uns kaufmännisch der entscheidende. Ein kleinerer Vektor ist günstiger zu speichern und schneller zu durchsuchen bei gleicher Qualität, und bei unseren Bestandsgrößen ist das ein greifbarerer Vorteil als ein kleiner Gewinn auf einem öffentlichen Retrieval-Benchmark.
Wie wir entscheiden, ob es sich lohnt
Ein besserer Benchmark-Wert ist kein Grund. Die Frage ist, ob die Anfragen, die heute auf unserem Referenzset scheitern, dann gelängen — und das lässt sich nur beantworten, indem man den zweiten Index baut und laufen lässt, was ohnehin den größten Teil der Migrationskosten ausmacht.
Also stichproben wir. Zweitausend Chunks statt des ganzen Bestands, mit dem Kandidatenmodell in einen Wegwerf-Index eingebettet, und die markierten Anfragen laufen dagegen. Das ist nicht abschließend, hat aber schon zweimal gereicht, um zu zeigen, dass ein Kandidat nicht geholfen hätte — und den vollen Lauf gespart.
Der Teil, der nicht das Modell ist
In beiden Migrationen, die wir gemacht haben, kam mehr Verbesserung aus Dingen, die wir gleichzeitig geändert haben, als aus dem Embedding-Modell selbst. Neuindexierung zwingt zum Neu-Chunken, und neu zu chunken mit allem, was man seither über den Bestand gelernt hat, ist der Ort, an dem sich die Qualität tatsächlich bewegte.
Das gehört getrennt statt gefeiert. Hat der Chunker die Arbeit getan, war der Modellwechsel der Anlass und nicht die Ursache — und das Gegenteil zu glauben führt zu einer Faustregel, die sagt: Embeddings erneuern für Qualität. Die ehrliche Regel lautet: Chunking überdenken für Qualität.
Was wir während der Umstellung beobachten
Drei Dinge, alle billig. Die Zahl indexierter Chunks gegen die Zahl der Quell-Chunks, denn eine Migration, die still Dokumente verliert, übersieht man leicht. Das Referenzset, gelaufen gegen den neuen Index, bevor der Zeiger umgelegt wird. Und den Anteil der Anfragen, die nichts oberhalb der Relevanzschwelle liefern — das schnellste Signal, dass etwas strukturell falsch ist.
Letzteres hat bei unserer zweiten Migration einen Filterbruch gefangen: Die Namen der Metadatenfelder hatten sich geändert, der Filter traf nichts, und der Recall-Einbruch zeigte sich in Minuten statt in einem Support-Ticket der Folgewoche.
Was wir nicht behaupten
Wir behaupten nicht, neuere Embedding-Modelle lohnten sich nicht. Sie tun es, und die Verbesserungen waren real. Unser Punkt betrifft die Gestalt der Änderung: Sie ist eine Datenmigration mit Rückfallplan, kein Konfigurationswert — und sie als Letzteres zu behandeln hat uns einen Nachmittag gekostet.
Wir behaupten auch nicht, eine Stichprobe von zweitausend Chunks sei ein verlässlicher Vorhersagewert. Sie ist ein billiger Negativtest. Sie kann zeigen, dass ein Kandidat nicht besser ist; sie kann nicht versprechen, dass er es ist, und wir haben nicht versucht, ihr mehr abzuverlangen.