Dense-Vector-Mapping und Indexierung optimieren: Dimension, Quantisierung, Speicher

1. Was ein einzelner Vektor tatsächlich an Speicher kostet

Ein Standard-Embedding-Modell mit 768 Dimensionen speichert jeden Wert typischerweise als 32-Bit-Gleitkommazahl, was pro Vektor rund drei Kilobyte reinen Rohdatenspeicher bedeutet, ohne den zusätzlichen HNSW-Graphen mitzurechnen. Bei einem Katalog mit fünf Millionen Produkten und nur einem Embedding-Feld pro Produkt summiert sich das bereits auf über vierzehn Gigabyte allein für die Rohvektoren, und mehrsprachige Kataloge mit einem separaten Embedding pro Sprache vervielfachen diesen Bedarf entsprechend.

Dieser Speicherbedarf betrifft nicht nur die Festplatte, sondern vor allem den Arbeitsspeicher, denn für performante kNN-Suche müssen sowohl die Vektoren als auch der HNSW-Graph möglichst vollständig im Speicher der Data Nodes gehalten werden. Wer die Dimension oder die Speicherstrategie nicht bewusst wählt, riskiert damit nicht nur unnötige Kosten, sondern auch spürbare Performance-Einbußen, sobald der verfügbare Speicher knapp wird und Teile der Daten auf langsamere Speichermedien ausweichen müssen.

2. Die Dimension: nicht jedes Modell mit mehr Dimensionen ist besser

Eine höhere Vektor-Dimension erfasst grundsätzlich mehr Nuancen der ursprünglichen Bedeutung, verlangt aber proportional mehr Speicher und mehr Rechenzeit für jede Distanzberechnung während der Suche. Ab einem gewissen Punkt liefert eine weitere Erhöhung der Dimension nur noch marginale Qualitätsgewinne, während Speicher- und Rechenkosten weiter linear steigen, ein klassisches Phänomen abnehmenden Grenznutzens.

Viele moderne Embedding-Modelle bieten deshalb explizit reduzierte Dimensionsvarianten an, etwa 384 statt 768 oder 1024 Dimensionen, die durch ein Trainingsverfahren namens Matryoshka Representation Learning erzeugt werden, bei dem die wichtigsten Informationen bewusst in den ersten Dimensionen konzentriert werden. Für viele Produktsuche-Anwendungsfälle liefert eine solche reduzierte Variante nahezu dieselbe Suchqualität bei deutlich geringerem Speicherbedarf, was vor der endgültigen Modellwahl unbedingt getestet werden sollte.

3. Quantisierung: von 32-Bit-Gleitkommazahlen zu kompakteren Formaten

Quantisierung reduziert die Präzision, mit der jeder einzelne Vektorwert gespeichert wird, ohne die Anzahl der Dimensionen selbst zu verändern. Statt einer 32-Bit-Gleitkommazahl pro Wert speichert int8-Quantisierung jeden Wert als 8-Bit-Ganzzahl, was den Speicherbedarf pro Vektor auf ein Viertel reduziert, während int4-Quantisierung mit 4 Bit pro Wert sogar auf ein Achtel des ursprünglichen Speicherbedarfs kommt.

Elasticsearch führt diese Quantisierung automatisch beim Indexieren durch, wenn der entsprechende index_options-Typ gesetzt ist, und behält intern zusätzlich eine kompaktere Repräsentation der Originalwerte für optionales Reranking vor, sodass ein Großteil der Suchgenauigkeit trotz der reduzierten Präzision erhalten bleibt.

PUT products
{
  "mappings": {
    "properties": {
      "description_embedding": {
        "type": "dense_vector",
        "dims": 768,
        "index": true,
        "similarity": "cosine",
        "index_options": {
          "type": "int8_hnsw",
          "m": 16,
          "ef_construction": 100
        }
      }
    }
  }
}

4. int8 gegen int4: Speichergewinn gegen Genauigkeitsverlust

int8-Quantisierung ist in der Praxis der solide Standardweg, weil der Genauigkeitsverlust gegenüber unquantisierten Vektoren für die allermeisten Produktsuche-Anwendungsfälle kaum messbar ist, während der Speicherbedarf bereits auf ein Viertel sinkt. int4-Quantisierung geht noch einen Schritt weiter und halbiert den Speicherbedarf gegenüber int8 erneut, verlangt dafür aber eine sorgfältigere Evaluierung, da der zusätzliche Präzisionsverlust je nach Embedding-Modell und Datensatz spürbarer ausfallen kann.

Eine praxistaugliche Vorgehensweise ist, mit int8 als Standard zu starten und int4 gezielt für besonders große Kataloge oder besonders speicherknappe Cluster in Betracht zu ziehen, wobei vor der Produktivnahme immer ein konkreter Recall-Vergleich zwischen unquantisierten, int8- und int4-Varianten auf einer repräsentativen Stichprobe der eigenen Produktdaten erfolgen sollte, statt sich auf allgemeine Herstellerangaben zu verlassen.

5. Auswirkung auf die Indexierungsgeschwindigkeit bei großen Katalogen

Der Aufbau des HNSW-Graphen ist der rechenintensivste Teil der Indexierung, da für jeden neuen Vektor die nächsten Nachbarn im bereits bestehenden Graphen gesucht und Verbindungen entsprechend dem ef_construction-Parameter angelegt werden müssen. Bei einem initialen Voll-Indexierungslauf über mehrere Millionen Produkte macht sich das deutlich in der Gesamtlaufzeit bemerkbar, während eine Quantisierung diesen Effekt teilweise abmildert, weil weniger Daten pro Vektor bewegt und verglichen werden müssen.

Bei inkrementellen Updates einzelner Produkte, wie sie im laufenden Magento-Betrieb bei jeder Preisänderung oder Beschreibungsanpassung anfallen, ist die Auswirkung auf einzelne Dokumente gering, kumuliert sich aber bei sehr häufigen Bulk-Updates über große Teile des Katalogs. Eine bewährte Praxis ist, Embedding-Updates nicht bei jeder kleinen Änderung, sondern gebündelt und mit einer sinnvollen Batch-Größe über die Bulk-API einzuspielen, statt einzelne Dokumente nacheinander zu aktualisieren.

6. Oversampling und Reranking zur Kompensation von Quantisierungsverlusten

Um den durch Quantisierung entstehenden Genauigkeitsverlust auszugleichen, unterstützt Elasticsearch ein zweistufiges Vorgehen: Die initiale kNN-Suche läuft auf den quantisierten Vektoren und liefert eine größere Kandidatenmenge als eigentlich benötigt, das sogenannte Oversampling, und ein anschließender Reranking-Schritt bewertet diese Kandidaten anhand der präziseren, nicht quantisierten Werte neu, bevor die endgültige Top-Auswahl zurückgegeben wird.

Dieses Vorgehen kombiniert die Geschwindigkeits- und Speichervorteile der Quantisierung für die breite erste Suche mit der Genauigkeit unquantisierter Werte für die finale Sortierung der wenigen tatsächlich zurückgegebenen Ergebnisse, und ist in der Praxis oft der beste Kompromiss zwischen Ressourceneffizienz und Suchqualität, besonders bei int4-Quantisierung, wo der reine Genauigkeitsverlust ohne Reranking spürbarer ausfällt.

7. Mehrere Vektorfelder pro Dokument: Kosten realistisch einplanen

In einem mehrsprachigen Magento-Shop ist es naheliegend, für jede unterstützte Sprache ein eigenes Embedding-Feld anzulegen, etwa description_embedding_de und description_embedding_en, was den Gesamtspeicherbedarf pro Dokument entsprechend der Anzahl der Sprachen vervielfacht. Vor einer solchen Entscheidung lohnt es sich zu prüfen, ob ein einzelnes, sprachübergreifend trainiertes Multilingual-Embedding-Modell nicht denselben fachlichen Nutzen mit nur einem Vektorfeld liefern kann.

Falls separate Sprachfelder tatsächlich nötig sind, etwa weil sprachspezifische Modelle nachweislich bessere Ergebnisse liefern, sollte die Kapazitätsplanung des Clusters diesen multiplizierten Speicherbedarf von Anfang an berücksichtigen, statt ihn erst bei einem produktiven Speicherengpass zu entdecken.

8. Messung: Speicher- und Latenzunterschiede konkret nachvollziehen

Vor jeder Entscheidung für eine bestimmte Dimension oder Quantisierungsstufe lohnt sich ein einfacher, aber aussagekräftiger Vergleichstest auf einem repräsentativen Ausschnitt des eigenen Produktkatalogs, bei dem derselbe Datensatz einmal unquantisiert, einmal mit int8 und gegebenenfalls einmal mit int4 indiziert wird, jeweils mit Messung von Indexgröße auf der Festplatte, Speicherverbrauch der Data Nodes und tatsächlicher Suchlatenz unter realistischer Anfragelast.

Diese konkreten Zahlen aus der eigenen Umgebung sind deutlich verlässlicher als generische Benchmark-Werte aus der Elastic-Dokumentation, da Indexgröße, Vektordimension, Katalogstruktur und Hardwareausstattung von Shop zu Shop erheblich variieren und der tatsächliche Effekt einer Optimierung sich nur am eigenen Datensatz zuverlässig zeigt.

9. Praktische Empfehlung: ein pragmatischer Startpunkt

Für die meisten Magento-Shops mit einem mittleren bis großen Produktkatalog ist ein pragmatischer Startpunkt eine reduzierte Embedding-Dimension zwischen 384 und 768, kombiniert mit int8-Quantisierung und Standard-HNSW-Parametern, was bereits einen Großteil der möglichen Speicherersparnis realisiert, ohne die Suchqualität spürbar zu beeinträchtigen.

Weitergehende Optimierungen wie int4-Quantisierung oder aggressivere Dimensionsreduktion lohnen sich erst, wenn konkrete Kapazitätsgrenzen des Clusters erreicht werden oder wenn die Kostenrechnung für den Betrieb der Infrastruktur eine weitere Reduktion ausdrücklich verlangt, und sollten dann immer anhand der eigenen, gemessenen Daten getroffen werden, nicht anhand allgemeiner Empfehlungen allein.

10. Zusammenfassung

11. FAQ: Dense-Vector-Mapping optimieren: Das Wichtigste auf einen Blick