Qdrant 1.20 bringt die Datentypen turbo8 und turbo16 sowie Indexierung pro Element für verschachtelte Felder

Kleinere Vektoren auf Basis von TurboQuant

Das Speichern von Vektoren ist laut Qdrant der größte Kostenfaktor bei der semantischen Suche: Kalt kosten sie Festplattenplatz, warm Arbeitsspeicher. Die neuen Datentypen verringern die pro Dimension gespeicherten Bits. turbo8 nutzt 8 Bit, turbo16 nutzt 16 Bit, sodass eine Collection nur ein Viertel (turbo8) beziehungsweise die Hälfte (turbo16) des Platzes von float32 benötigt. Für Teams, denen RAM oder Speicherplatz ausgeht, bedeutet das laut Qdrant weniger Knoten oder mehr Platz für Daten auf den vorhandenen.

Das Unternehmen grenzt den Ansatz von den bestehenden Typen float16 und uint8 ab. Die Umwandlung von float32 in diese Formate verliert Präzision und auch Information, weil die Kompression auf einfachen Transformationen beruht. Die neuen Datentypen setzen auf TurboQuant, einen rotationsbasierten Kompressionsalgorithmus, der laut Qdrant auf den meisten Datensätzen gut funktioniert, unterstützt von einigen eigenen Ergänzungen. Er bewahrt die relevanten Informationen, während die Präzision sinkt.

Der 4-Bit-Datentyp turbo4 aus Version 1.19 spart mit 8-fach geringerem Speicherbedarf noch mehr, büßt auf manchen Datensätzen aber einige Prozentpunkte beim Recall ein. Qdrant empfiehlt ihn für Fälle, in denen Ressourcenlimits wichtiger sind als die Suchqualität.

Um die neuen Typen zu nutzen, wählt man beim Anlegen einer Collection für datatype den Wert turbo8 oder turbo16. Normale float32-Vektoren lassen sich weiterhin hochladen; Qdrant rotiert sie mit TurboQuant und legt sie auf einem 8-Bit- oder 16-Bit-Ganzzahlraster ab.

Latenz im Bereich von 10 % gegenüber float32

Quantisierung kann die Latenz erhöhen, räumt Qdrant ein, gibt aber an, dass turbo8 und turbo16 serverseitig innerhalb von 10 % der Latenz von float32-Vektoren bleiben. Die Abfrage durchläuft nicht die vollständige TurboQuant-Pipeline. Sie wird lediglich rotiert und in float32-Präzision belassen. Dieses Vorgehen heißt asymmetrisches Scoring und hält den Mehraufwand minimal.

Skalare und binäre Quantisierung funktionieren anders. Sie behalten neben den verkleinerten Vektoren Kopien in voller Präzision und können die besten Kandidaten gegen die Originale neu bewerten, um den Recall zurückzugewinnen. Liegen diese Originale auf der Festplatte, wartet jede Abfrage auf Lesezugriffe. Ohne Rescoring entfällt das Warten, dafür sinkt der Recall. Die TurboQuant-Datentypen kommen ohne Rescoring aus, da die kompakten Vektoren die gespeicherten Vektoren sind und die float32-Originale verworfen werden. Laut Qdrant bleibt der Recall nah an float32.

Das Unternehmen gibt an, jeden Datentyp auf 14 Embedding-Datensätzen mit 512 bis 3.072 Dimensionen getestet zu haben, mit HNSW als Index und exakter Suche als Referenz. Die veröffentlichten Zahlen stammen von drei Datensätzen mit 1.536 Dimensionen, einem Limit von 100 Ergebnissen und 2-fachem Oversampling bei skalarer und binärer Quantisierung. Der Code liegt im Repository modern-quantization-bench.

Indexierung pro Element für verschachtelte Filter

Die zweite Neuerung zielt auf Metadaten-Payloads, die Arrays von Objekten enthalten, etwa die Autoren einer Publikation. Ein verschachtelter Filter sucht nach einem einzelnen Element, das alle Bedingungen erfüllt, zum Beispiel einem Autor mit dem Vornamen Ada und dem Nachnamen Hopper.

Bisher erledigte Qdrant das in zwei Schritten. Ein Index-Lookup fand Kandidatenpunkte, die alle Bedingungen erfüllen, wenn auch nicht zwingend im selben Element. Anschließend las Qdrant die Payloads dieser Kandidaten von der Festplatte oder aus dem Speicher, um nur Punkte zu behalten, bei denen ein Element alle Bedingungen erfüllte. Mit 1.20 kann Qdrant dank der Indexierung pro Element den zweiten Schritt überspringen und den gesamten Filter allein über Index-Lookups auswerten.

Auf 1 Million arXiv-Publikationen bediente der Index pro Element laut Qdrant bis zu viermal so viele Abfragen pro Sekunde wie reguläre Indizes, bei identisch korrekten Ergebnissen. Der Code liegt im Repository nested-filters-bench.

Qdrant vergleicht das auch mit flachen Filtern, die jede Bedingung unabhängig und nur per Index-Lookup prüfen. Sie sind meist am schnellsten, liefern bei Arrays von Objekten aber viele falsch positive Treffer, weil die Bedingungen auf unterschiedliche Elemente eines Arrays zutreffen können. Im Benchmark lag ein flacher Filter geschwindigkeitsmäßig nah dran, verfehlte aber zwischen einem Fünftel und einem Drittel der richtigen Publikationen.

So aktiviert man die Funktionen

Einen Index pro Element legt man an, indem man beim Erstellen eines Payload-Index für ein Feld innerhalb der Elemente nested auf den Array-Schlüssel setzt. In Qdrants Beispiel wird das Feld authors[].first als Keyword indexiert, mit nested auf authors. Derselbe Index muss für jedes im Filter verwendete Feld angelegt werden.

Laut Qdrant werden bestehende verschachtelte Filter schneller, ohne dass sich die Suchanfrage ändern muss. Beide Funktionen sind in Qdrant 1.20 verfügbar, und das Unternehmen bittet auf seinem Discord um Feedback.

Für Teams, die Qdrant betreiben, bietet das Release zwei getrennte Stellschrauben: geringere Speicherkosten mit turbo8 oder turbo16 und schnelleres Filtern verschachtelter Felder durch eine Indexänderung. Alle Leistungsangaben stammen aus Qdrants eigenen Benchmarks.