Embedding-Quantisierung: Binär-, int8- und Matryoshka-Vektoren ohne Qualitätsverlust beim Retrieval

Vektorindizes werden schneller teuer, als man denkt. Zehn Millionen Chunks mit 1.024-dimensionalen float32-Embeddings sind rund 41 GB reine Vektoren, vor jedem Index-Overhead, und HNSW-Indizes wollen im Arbeitsspeicher liegen. Lange bevor Embedding-Modell oder Datenbank zum Problem werden, wird es der RAM. Quantisierung verkleinert diese Vektoren um den Faktor 2 bis 32 und kostet mit einem zusätzlichen Schritt überraschend wenig Retrieval-Qualität.

Dieser Artikel vergleicht halbe Genauigkeit, int8, binäre Quantisierung und Matryoshka-Kürzung mit gemessenen Erhaltungswerten, zeigt die Umsetzung in pgvector und endet mit einem Testplan für den eigenen Korpus. Die Wahl des Speichers selbst behandelt pgvector oder eine Vektordatenbank.

Was macht Embedding-Quantisierung eigentlich?

Es ist ein Nachbearbeitungsschritt an den Vektoren, nicht am Modell. Wie der Beitrag von Hugging Face erklärt, wandelt binäre Quantisierung jeden float32-Wert per Schwelle bei null in ein Bit um, was Speicher um den Faktor 32 senkt; skalare int8-Quantisierung bildet jeden Wert auf einen von 256 Bereichen ab, Faktor 4. Binäre Vektoren vergleicht man per Hamming-Distanz, die sehr billig zu berechnen ist.

Die Zahlen sind reine Vektorgrößen; Indizes kommen grob proportional obendrauf. Entscheidend ist die Größenordnung: Binär macht aus einem Problem für einen eigenen Server etwas, das neben die Anwendung passt.

Wie viel Retrieval-Qualität verliert man?

Hugging Face hat das mit mxbai-embed-large-v1 auf MTEB Retrieval gemessen. Binäre Embeddings allein behielten rund 92,5 % der float32-Leistung. Ein Rescoring-Schritt, Kandidaten mit der binären Anfrage holen und dann mit dem float32-Anfrage-Embedding bewerten, hob das auf rund 96 %, bei 32-facher Speicherersparnis für den Index. int8 liegt dazwischen und ist die sicherere Wahl, wenn kein Rescoring-Durchgang möglich ist.

Was bringen Matryoshka-Embeddings?

Quantisierung reduziert die Bits pro Dimension. Matryoshka Representation Learning reduziert die Zahl der Dimensionen: Modelle werden so trainiert, dass die ersten Dimensionen die meiste Information tragen und ein Präfix des Vektors allein ein brauchbares Embedding ist. Das Originalpaper berichtet bis zu 14-mal kleinere Embeddings bei gleicher Genauigkeit in der ImageNet-Klassifikation. Für Text zitiert der Hugging-Face-Beitrag OpenAIs text-embedding-3-large mit 93,1 % Leistung bei 12-facher Kompression und nomic-embed-text-v1.5 mit 95,8 % bei 3-facher und 90 % bei 6-facher.

Kürzen funktioniert nur bei so trainierten Modellen. Bei einem gewöhnlichen Modell Dimensionen abzuschneiden verschlechtert es stark, und klassische Dimensionsreduktion wie PCA schneidet bei Embeddings meist schlecht ab, wie derselbe Beitrag festhält. Vor dem Schneiden die Model Card prüfen.

Wie setzt man das in pgvector um?

Die pgvector-README nennt die Grenzen für HNSW-Indizes: vector bis 2.000 Dimensionen, halfvec bis 4.000 und bit bis 64.000. Binäre Quantisierung geht über einen Ausdrucksindex auf binary_quantize(embedding) mit Hamming-Distanz, und dieselbe Abfrage kann die Kandidaten mit den Originalvektoren neu ordnen. Subvektor-Ausdrucksindizes liefern Matryoshka-Kürzung ohne zweite Spalte.

-- Binary index for candidate search, full vectors for rescoring
CREATE INDEX chunks_bq ON chunks
  USING hnsw ((binary_quantize(embedding)::bit(1024)) bit_hamming_ops);

SELECT id, text FROM (
  SELECT id, text, embedding FROM chunks
  ORDER BY binary_quantize(embedding)::bit(1024) <~> binary_quantize($1::vector)
  LIMIT 200                                   -- 4–10x the final k
) candidates
ORDER BY embedding <=> $1::vector             -- rescore with the float query
LIMIT 20;

-- Matryoshka: index only the first 512 dimensions of a model trained for it
CREATE INDEX chunks_mrl ON chunks
  USING hnsw ((subvector(embedding, 1, 512)::vector(512)) vector_cosine_ops);

-- Half precision: half the memory, nearly no loss
CREATE INDEX chunks_half ON chunks
  USING hnsw ((embedding::halfvec(1024)) halfvec_cosine_ops);

Die Abfrage muss denselben Ausdruck wie der Index verwenden, sonst fällt Postgres auf einen sequenziellen Scan zurück. Einmal pro Abfrageform mit EXPLAIN prüfen. Spezialisierte Vektordatenbanken wie Qdrant bieten skalare und binäre Quantisierung als Collection-Einstellung mit eingebautem Rescoring; die Abwägungen sind dieselben.

Welche Technik sollte man wählen?

Wie testet man Quantisierung an eigenen Daten?

1. Das eigene Retrieval-Eval-Set nehmen, Fragen mit bekannten relevanten Chunks, wie in RAG evaluieren beschrieben.
2. Recall@10 und Recall@50 mit float32 als Basislinie messen.
3. Für halfvec, int8, binär ohne Rescoring und binär mit Rescoring beim 4- und 10-Fachen des finalen k wiederholen.
4. Indexgröße, Abfragelatenz im p95 und Recall in einer Tabelle festhalten und die günstigste Option innerhalb des Recall-Budgets wählen.

Danach die ganze Pipeline laufen lassen, inklusive hybrider Suche und Reranker aus Eine produktive RAG-Pipeline. Ein Reranker verdeckt oft kleine Recall-Verluste der ersten Stufe, ein weiterer Grund, warum quantisiertes Retrieval in der ersten Stufe in der Praxis gut funktioniert.

Quellen

1. Hugging Face: Binary and Scalar Embedding Quantization for Significantly Faster and Cheaper Retrieval (Mar 2024)
2. Kusupati et al.: Matryoshka Representation Learning (2022)
3. pgvector README: halfvec, bit, binary quantization and subvector indexing