Schnell vs. genau: Messung der Recall-Rate bei der quantisierten Vektorsuche

Wir alle wünschen uns eine sofortige Vektorsuche. Jedoch sind hochdimensionale Vektoren sehr umfangreich. Ein einzelner 1.024-dimensionaler Float-32-Vektor beansprucht viel Speicherplatz, wobei der Vergleich mit Millionen anderer Vektoren einen hohen Rechenaufwand erfordert.

Zur Lösung dieses Problems wenden Suchmaschinen wie Elasticsearch zwei wesentliche Optimierungsstrategien an:

1. Ungefähre Suche (Hierarchical Navigable Small World [HNSW]): Anstatt jedes Dokument zu durchsuchen, erstellen wir einen Navigationsgraphen, um schnell in die wahrscheinliche Nachbarschaft der Antwort zu gelangen.
2. Quantisierung: Wir komprimieren die Vektoren (beispielsweise von 32-Bit-Gleitkommazahlen auf 8-Bit-Ganzzahlen oder sogar auf 1-Bit-Binärwerte), um den Speicherbedarf zu verringern und die Berechnungen zu beschleunigen.

Doch Optimierung hat oft ihren Preis: Genauigkeit.

Die Befürchtung ist berechtigt: „Wenn ich meine Daten komprimiere und bei der Suche Abstriche mache, verpasse ich dann die besten Ergebnisse?“ „Beeinträchtigt diese Optimierung die Relevanz meiner Suchmaschine?“

Für den Nachweis, dass die Quantisierung von Elastic die Ergebnisse nicht beeinträchtigt, haben wir einen wiederholbaren Testrahmen unter Verwendung des DBPedia-14-Datensatzes entwickelt, um präzise zu berechnen, wie viel Genauigkeit (genauer gesagt Recall) wir bei der Verwendung der Standardoptimierungen in Elasticsearch zugunsten der Geschwindigkeit einbüßen.

Kurz gesagt: Viel weniger, als Sie denken. Sehen Sie sich das Notebook hier an und testen Sie es selbst

Die Definitionen (für die Nicht-Experten)

Klären wir zunächst einige Begriffe, bevor wir uns den Code ansehen.

• Relevanz vs. Recall: Relevanz ist subjektiv (habe ich etwas Gutes gefunden?). Recall ist mathematisch. Wenn sich in der Datenbank 10 Dokumente befinden, die perfekt zu Ihrer Abfrage passen, und die Suchmaschine neun davon findet, beträgt Ihr Recall 90 % (oder 0,9).
• Exakte Suche (flach): Wird auch als „Brute-Force“-Methode bezeichnet. Die Suchmaschine scannt jedes einzelne Dokument in einem Index und berechnet die Entfernung.
  • Vorteile: 100 % perfekter Recall.
  • Nachteile: Rechenintensiv und bei großem Umfang langsam.
• Näherungssuche (HNSW): Die „Abkürzungs“-Methode. Die Suchmaschine erstellt einen HNSW-Graphen. Sie durchläuft den Graphen, um die nächsten Nachbarn zu finden.
  • Vorteile: Extrem schnell und skalierbar.
  • Nachteile: Falls das Durchlaufen des Graphen zu früh beendet wird, könnte ein Nachbar übersehen werden.

Das Experiment: Exakt vs. ungefähr

Für den Recall-Test haben wir den DBPedia-14-Datensatz verwendet, einen umfangreichen Datensatz mit Titeln und Auszügen aus 14 Ontologieklassen, der häufig zum Trainieren und Bewerten von Modellen zur Textkategorisierung genutzt wird. Konkret konzentrieren wir uns auf die Kategorie „Film“. Wir wollten die optimierten Produktionseinstellungen mit einem mathematisch perfekten Referenzwert vergleichen.

Für dieses Experiment verwenden wir das Modell jina-embeddings-v5-text-small, ein fortschrittliches mehrsprachiges Modell, das bei den Branchen-Benchmarks für Textdarstellung führend ist. Wir haben uns für dieses Modell entschieden, da es den aktuellen Standard für leistungsstarke Einbettungen setzt. Durch die Kombination der herausragenden Genauigkeit von Jina v5 mit der nativen Quantisierung von Elasticsearch können wir eine Sucharchitektur präsentieren, die sowohl rechnerisch effizient ist als auch keine Kompromisse bei der Abrufqualität eingeht.

Wir haben einen Index mit doppeltem Mapping eingerichtet. Wir haben denselben Text gleichzeitig in zwei verschiedene Felder aufgenommen:

1. content.raw mit Typ: flat. Dadurch wird Elasticsearch gezwungen, einen Brute-Force-Scan der gesamten Float32-Vektoren durchzuführen. Hierdurch werden exakte Übereinstimmungen geliefert, die als Ausgangsbasis dienen.
2. content mit Typ semantic_text. Standardmäßig werden HNSW und „Better Binary Quantization“ (BBQ) verwendet. Hierbei handelt es sich um die standardmäßige, optimierte Produktionseinstellung für die ungefähre Übereinstimmung.

Der Recall @10-Test

Als Metrik verwendeten wir Recall@10.

Wir haben 50 zufällige Filme ausgewählt und dieselbe Abfrage für beide Felder durchgeführt.

• Wenn die exakte (flache) Suche ergibt, dass die ersten 10 Nachbarn IDs [1, 2, 3 ... 10] sind.
• Und die ungefähre (HNSW) Suche liefert die IDs [1, 2, 3 ... 9, 99].
• Wir haben neun der Top 10 korrekt gefunden. Der Score liegt bei 0,9.

Hier ist das von uns verwendete Mapping:

Das Ergebnis: Die „flache Kurve“ des Erfolgs

Wir haben einen Skalierungstest durchgeführt, bei dem wir den gesamten Datensatz neu geladen und mit Indexgrößen von 1.000 bis 40.000 Dokumenten getestet haben.

So hat sich der Recall-Score entwickelt:

Die Ergebnisse waren erstaunlich stabil. Selbst als wir die Skalierung erhöhten, stimmte die ungefähre Suche in >99 % der Fälle mit der exakten Brute-Force-Suche überein.

Warum hat es so gut funktioniert?

Sie könnten erwarten, dass die Komprimierung von Vektoren zu Binärwerten die Genauigkeit stärker beeinträchtigen würde. Der Grund dafür liegt in der Art und Weise, wie Elasticsearch den Abruf handhabt.

Die meisten Einbettungsmodelle liefern heutzutage Float32-Vektoren als Ausgabe, die sehr groß sind. Für eine effiziente Suche nutzt Elasticsearch die Quantisierung für hochdimensionale Vektoren. Genauer gesagt wird seit Version 9.2 standardmäßig BBQ verwendet.

BBQ verwendet einen Rescoring-Mechanismus:

1. Durchlaufen: Die Suchmaschine verwendet die komprimierten (quantisierten) Vektoren, um den HNSW-Graphen schnell zu durchlaufen. Da die Vektoren klein sind, kann das System effizient überabtasten und so eine größere Liste von Kandidaten (zum Beispiel die 100 am ehesten passenden Dokumente) ohne Leistungseinbußen zusammenstellen.
2. Rescore: Sobald diese Kandidaten vorliegen, ruft das System die Werte in voller Genauigkeit nur für diese wenigen Dokumente ab, um das endgültige, genaue Ranking zu berechnen.

So erhalten Sie das Beste aus beiden Welten: die Geschwindigkeit der Quantisierung für die rechenintensiven Aufgaben und die Präzision von Gleitkommazahlen für die abschließende Sortierung.

Können wir das besser machen?

An dieser Stelle ist anzumerken, dass die hier gezeigten Ergebnisse auf den Standardeinstellungen und einer zufälligen Stichprobe von Daten basieren. Betrachten Sie das als einen leistungsstarken Ausgangspunkt. Auch wenn Jina v5 ein wahres Kraftpaket ist, sind diese Recall-Werte keine allgemeingültige Garantie für jeden Datensatz. Jede Datenerhebung hat ihre Eigenheiten, und obwohl es durchaus möglich ist, die Leistung durch weitere Optimierungen weiter zu steigern, sollten Sie stets einen Vergleichstest mit Ihren eigenen spezifischen Daten durchführen, um Ihre Leistungsgrenze zu ermitteln.

Fazit

Es handelt sich hierbei um einen sehr kleinen Test. Der Zweck dieser Übung besteht jedoch nicht speziell in der Messung des Einbettungsmodells oder von BBQ, sondern vielmehr in der Veranschaulichung, wie Sie mit minimalem Aufwand den Recall Ihres Datensatzes messen können.

Wenn Sie diesen Test mit Ihren eigenen Daten durchführen möchten, können Sie sich das Notebook hier ansehen und es selbst testen.