Wie wirkt sich die Komprimierung von Vektorindizes auf Suchtrefferquote und RAM-Nutzung aus?

Die Komprimierung von Vektorindizes reduziert den RAM-Bedarf, indem Darstellungen mit geringerer Präzision gespeichert werden. Die daraus resultierende Verzerrung der Distanzen kann jedoch den Recall bei der Suche nach den nächsten Nachbarn verringern.

Ein lokaler RAG-Index kann bei einhunderttausend Chunks problemlos passen, nach Jahren mit Dokumenten, Fotos und Transkripten jedoch an die Speichergrenze stoßen. Quantisierung kann dafür sorgen, dass mehr Vektoren im Arbeitsspeicher verbleiben. Die Suchqualität hängt jedoch davon ab, ob komprimierte Distanzen dieselbe Reihenfolge der Kandidaten bewahren wie die Werte mit voller Präzision. Das Ergebnis variiert je nach Verteilung der Embeddings, Komprimierungsverhältnis, Indextyp, Anzahl der Kandidaten und der Frage, ob die ursprünglichen Vektoren für ein erneutes Scoring verfügbar bleiben.

Die Komprimierung verkleinert die Vektordaten, aber nicht alle Indexkosten

Ein Vektorindex benötigt Speicher für die Embedding-Werte, Graph- oder Partitionsstrukturen, Bezeichner, Metadaten, zusätzlichen Speicher des Allocators und temporäre Abfragepuffer. Die Komprimierung reduziert hauptsächlich die Darstellung der Embeddings. HNSW-Verknüpfungen und Metadaten können ähnlich groß bleiben, sodass die RAM-Ersparnis geringer ausfallen kann, als das Komprimierungsverhältnis der Vektoren vermuten lässt.

Hochdimensionale Vektoren sind kostenintensiv, weil jede als Wert mit voller Präzision gespeicherte Dimension zum Speicherbedarf und zu den Kosten der Distanzberechnung beiträgt. Werden diese Werte durch kompakte Codes ersetzt, verringert sich die im Speicher gehaltene Datenmenge, und die Cache-Effizienz kann steigen.

Die tatsächliche Einsparung hängt daher vom Aufbau des Index ab. Hochdimensionale Float-Vektoren bieten in der Regel ein großes Einsparpotenzial; bei kleinen Vektoren mit starker Graphverknüpfung fällt die proportionale Ersparnis möglicherweise geringer aus. Messen Sie den residenten Speicher des Prozesses und die Indexdateien vor und nach der Komprimierung, statt die rohen Vektorbytes einfach mit der Dokumentanzahl zu multiplizieren.

Quantisierung führt zu Verzerrungen der Distanzen

Bei der skalaren Quantisierung wird jede Dimension auf einen kleineren Zahlenbereich abgebildet, während die Produktquantisierung einen Vektor in Teilräume aufteilt und Codebuchauswahlen speichert. Beide Verfahren ersetzen exakte Koordinaten durch Näherungen. Die Abfragedistanz wird anschließend anhand rekonstruierter Werte oder Codebuchdistanzen statt anhand des ursprünglichen Float-Vektors berechnet.

Experimente mit der Produktquantisierung bewerten die Komprimierung, indem sie die Verzerrung rekonstruierter Distanzen und den Recall messen. Kompaktere Codes können Latenz und Speicherbedarf senken, erschweren jedoch die korrekte Reihenfolge nah beieinanderliegender Kandidaten, wenn deren tatsächliche Distanzen ähnlich sind.

Der Recall sinkt, wenn ein relevanter Nachbar unter die Kandidatengrenze fällt, nicht bloß deshalb, weil jede Distanz geringfügig falsch ist. Abfragen mit einem deutlichen Abstand zwischen relevanten und irrelevanten Chunks können auch eine starke Komprimierung verkraften. Dichte semantische Nachbarschaften mit vielen nahezu gleichwertigen Treffern reagieren dagegen empfindlicher.

Eine Erweiterung der Kandidatenmenge und ein erneutes Scoring können den Recall wiederherstellen

Bei einer zweistufigen Suche werden komprimierte Vektoren verwendet, um zunächst eine umfangreiche Auswahlliste zu erstellen. Anschließend werden die Distanzen für diese Kandidaten mit Vektoren höherer Präzision erneut berechnet. Durch Oversampling erhalten relevante Elemente mehr Möglichkeiten, die approximative erste Stufe zu überstehen. Das erneute Scoring stellt die Reihenfolge wieder her, wenn kompakte Codes kleine Distanzunterschiede verwischt haben.

Höhere Komprimierungsstufen verringern typischerweise den Recall, während Oversampling und erneutes Scoring die Genauigkeit verbessern können. Die Wiederherstellung benötigt zusätzliche Lesevorgänge, Speicher und Abfrageleistung. Die Komprimierung verlagert den Ressourcenaufwand also, anstatt die Qualitätskosten vollständig zu beseitigen.

Werden vollständige Vektoren auf der Festplatte gespeichert, bleibt der RAM-Bedarf zwar niedrig, beim erneuten Ranking kann jedoch zusätzliche Speicherlatenz entstehen. Die Speicherung im RAM verbessert die Latenz, verringert aber den Speichervorteil. Die passende Konfiguration hängt davon ab, ob der Heimserver durch Speicherkapazität, Storage-IOPS oder Zielvorgaben für die Antwortzeit begrenzt ist.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Der Recall muss für die lokale Retrieval-Aufgabe gemessen werden

Erstellen Sie einen Referenzdatensatz, indem Sie für repräsentative Abfragen eine exakte Suche oder eine Suche mit hoher Präzision ausführen. Vergleichen Sie anschließend, ob die komprimierte Suche innerhalb von top-k dieselben relevanten Nachbarn zurückgibt. Berücksichtigen Sie Paraphrasen, Eigennamen, nahezu identische Dokumente, seltene Begriffe und Abfragen, deren Antwort von einem kleinen Unterschied in den Belegen abhängt.

Dies ergänzt das Thema Vertrauen in die Retrieval-Grounding-Evidenz: Nachbarähnlichkeit und die Unterstützung einer Antwort hängen zusammen, sind aber nicht identisch. Messen Sie Recall@k anhand der Suchreferenz und prüfen Sie außerdem, ob verlorene oder neu angeordnete Chunks die für den Generator verfügbaren Belege verändern.

Es gibt keinen allgemeingültigen Sieger zwischen maximaler Komprimierung und maximaler Präzision. Erhöhen Sie die Komprimierung, bis RAM-Bedarf, Latenz und Aufgaben-Recall das gewünschte Gleichgewicht erreichen, und testen Sie nach Änderungen am Embedding-Modell oder Korpus erneut. Eine Konfiguration, die für die allgemeine Ähnlichkeitssuche bei Fotos funktioniert, kann für den Abruf technischer Dokumente mit vielen semantisch nah beieinanderliegenden Passagen zu verlustreich sein.