Wie beschleunigt die Produktquantisierung große private Vektorsammlungen?

Produktquantisierung beschleunigt große private Vektorsammlungen, indem sie Embeddings in Unterräume aufteilt und jeden Subvektor durch einen kompakten, erlernten Zentroid-Code ersetzt.

Dies ist ein spezifischer Mechanismus innerhalb der übergeordneten Familie der Vektorquantisierung. Statt jede Koordinate unabhängig zu reduzieren, lernt PQ mehrere kleinere Codebücher und stellt ein hochdimensionales Embedding als Folge von Code-IDs dar. Ein Suchserver zu Hause kann deutlich mehr dieser Codes im Arbeitsspeicher halten und Abfrageabstände anhand vorberechneter Tabellen schätzen. Dadurch werden sowohl die gespeicherte Anzahl an Vektor-Bytes als auch der für eine breit angelegte Kandidatensuche erforderliche Rechenaufwand mit voller Präzision reduziert.

PQ teilt ein hochdimensionales Embedding in mehrere Subvektoren auf

Angenommen, ein Embedding hat die Dimension `d`. PQ wählt `M` Subquantisierer und unterteilt die Koordinaten in `M` niedrigerdimensionale Blöcke, sodass jeder Block separat modelliert werden kann.

Die Anzahl der Subquantisierer bestimmt, in wie viele niedrigerdimensionale Blöcke das ursprüngliche Embedding aufgeteilt wird und wie viele Code-IDs somit eine PQ-Darstellung bilden.

Diese Faktorisierung verleiht der Produktquantisierung ihren Namen: Die vollständige Approximation wird aus unabhängig in mehreren Unterräumen getroffenen Entscheidungen zusammengesetzt und nicht aus einem einzigen riesigen Codebuch für den kompletten Vektor. Die Unterräume müssen die Vektordimensionen auf kompatible Weise aufteilen. Ihre Größe und Anzahl beeinflussen die Kompression, die Kosten für das Training des Codebuchs, die Genauigkeit der Abstände und die Frage, wie gut die Datenverteilung zur faktorisierten Darstellung passt.

Jeder Unterraum lernt ein Codebuch repräsentativer Zentroiden

PQ wird normalerweise anhand einer repräsentativen Stichprobe der Sammlung trainiert. Für jeden Unterraum werden durch Clustering Zentroidvektoren ermittelt, die Gruppen ähnlicher Subvektoren repräsentieren.

Ein typischer Produktquantisierer verwendet k-Means, um in jedem Unterraum Zentroiden zu erlernen und den Approximationsfehler zwischen Trainingssubvektoren und ihren zugewiesenen Repräsentanten zu minimieren.

Nach dem Training muss die Datenbank im kompakten Suchcode nicht mehr alle ursprünglichen Koordinaten speichern. Sie benötigt lediglich die Kennung des nächstgelegenen Zentroiden aus jedem Unterraum.

Wenn die Trainingsstichprobe zukünftige Dokumente aus dem Haushalt nur unzureichend repräsentiert, können die erlernten Zentroiden spätere Vektoren schlecht approximieren. Die Qualität des Codebuchs ist daher eine Implementierungsgrenze und kein einmaliges Detail, das ignoriert werden kann.

Der gespeicherte Vektor wird zu einer kurzen Folge von Code-IDs

Für jeden Subvektor findet der Encoder den nächstgelegenen Zentroiden und speichert den Index dieses Zentroiden. Durch das Aneinanderhängen der `M` Indizes entsteht der PQ-Code für das vollständige Embedding.

Das Speichern von m Subvektor-Codes mit konfigurierbarer Bitanzahl ersetzt ein langes Float-Array durch eine kurze Folge von Zentroid-IDs sowie gemeinsam genutzte Codebücher.

Mit beispielsweise acht Bits pro Subquantisierer lassen sich 256 Zentroidoptionen in diesem Unterraum darstellen. Der Gesamtcode des Vektors wächst dann mit der Anzahl der Subquantisierer und nicht mit der 32-Bit-Präzision jeder ursprünglichen Dimension. Codebücher und Index-Overhead benötigen weiterhin Speicher, daher ist die vollständige Sammlung größer als die Code-Bytes allein. Die Einsparungen werden besonders relevant, wenn die Anzahl der Vektoren groß genug ist, um die gemeinsam genutzten Codebücher auf viele Einträge umzulegen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Eine Abfrage erstellt Distanz-Nachschlagetabellen für jeden Unterraum

Wenn eine Abfrage eingeht, teilt das System sie in dieselben Unterräume auf und berechnet ihre Distanz zu jedem Zentroiden in jedem Codebuch. Diese Werte bilden kleine Nachschlagetabellen.

Eine Distanz-Nachschlagetabelle zwischen Abfrage und Zentroiden berechnet vorab die Distanz der Abfrage zu jedem Zentroiden in jedem Unterraum, sodass Kandidatendistanzen aus kleinen Nachschlagevorgängen statt aus Berechnungen mit vollständigen Vektoren zusammengesetzt werden können.

Um die Distanz zu einem gespeicherten Datenbankvektor zu schätzen, muss die Suche nicht mehr jede vollständige Koordinate rekonstruieren. Sie liest jede Code-ID aus, schlägt die entsprechende Distanz des Unterraums nach und addiert diese Werte.

Dieser tabellengesteuerte Ablauf wird häufig als asymmetrische Distanzberechnung bezeichnet, weil die Abfrage eine hohe Präzision behalten kann, während die Datenbankvektoren durch quantisierte Codes dargestellt werden.

Kompakte Codes verbessern die Cache-Lokalität bei wachsenden Sammlungen

Bei großen Vektorsuchen wird die Leistung häufig stärker dadurch begrenzt, dass Kandidatendaten durch den Speicher bewegt werden müssen, als durch die mathematische Komplexität einer einzelnen Distanzberechnung.

Kurze Codes ermöglichen es, mehr Kandidaten in CPU-Caches unterzubringen, und reduzieren die benötigte Bandbreite pro Vergleich.

Der komprimierte Distanzberechnungspfad kann durch SIMD-freundliche Tabellennachschlagevorgänge beschleunigt werden, da die produktquantisierte Suche wiederholt kompakte Codes liest und Distanzen der Unterräume aufsummiert.

Bei einer privaten Sammlung zu Hause kann dies den Unterschied zwischen einem Index ausmachen, dessen aktive Suchdarstellung im Arbeitsspeicher bleibt, und einem Index, der ständig mit dem lokalen LLM, der Datenbank und dem Dateisystem-Cache konkurriert.

Der Vorteil fällt geringer aus, wenn die Sammlung sehr klein ist, wenn Metadatenfilter jede Abfrage auf eine Handvoll Vektoren reduzieren oder wenn eine andere Indexebene die Latenz dominiert.

PQ tauscht in der Regel etwas Recall gegen Kompression und Geschwindigkeit

Zentroid-Codes approximieren die ursprünglichen Subvektoren. Daher kann sich die Reihenfolge zweier Kandidaten ändern, wenn ihre tatsächlichen Distanzen nahe beieinanderliegen. Eine aggressivere Kompression lässt im Allgemeinen weniger Informationen übrig, um zwischen ihnen zu unterscheiden.

Die Produktquantisierung als verlustbehaftete Kompression zu betrachten macht die Grenze deutlich: Kleinere Codes reduzieren den Vektorspeicher, doch Quantisierungsfehler können die Reihenfolge ähnlicher Nachbarn verändern.

Eine höhere Anzahl an Subquantisierern oder Bits kann mehr Details bewahren, vergrößert jedoch jeden Code und die Nachschlagstrukturen. Kleinere Codes sparen mehr Speicher, erhöhen aber die Wahrscheinlichkeit von Quantisierungsfehlern. Die geeignete Konfiguration hängt vom Korpus ab. Eng verwandte Handbücher, duplizierte Dokumentversionen und die Suche in fein strukturiertem Code können mehr Präzision erfordern als eine breit angelegte semantische Suche über vielfältige Notizen aus dem Haushalt.

Auf einen kompakten ersten Durchlauf kann ein Rescoring mit voller Präzision folgen

PQ zwingt nicht dazu, für die endgültige Antwort der komprimierten Distanzreihenfolge blind zu vertrauen. Ein System kann mit PQ eine größere Kandidatenmenge abrufen und anschließend nur diese Kandidaten anhand der an anderer Stelle gespeicherten Originalvektoren erneut bewerten.

Bei der semantischen Vektorsuche verändert PQ die für den Kandidatenvergleich verwendete Darstellung; Herkunft, Metadatenfilterung, Neugewichtung und RAG finden weiterhin rund um diese Vektorstufe statt.

Dieser zweistufige Ansatz verteilt Speicher und Rechenleistung asymmetrisch: Komprimierte Codes bearbeiten den großen Kandidatenraum, während auf exakte Vektoren nur für eine kleine Auswahlliste zugegriffen wird.

Produktquantisierung beschleunigt eine private Sammlung, wenn kompakte Codes die Arbeitssatzgröße und den Distanzdatenverkehr deutlich reduzieren, ohne den gemessenen Recall unter die für das lokale RAG-System erforderliche Qualität der Belege zu senken.