Qdrant 1.20 bringt BM25 für Volltextindizes und neue TurboQuant-Datentypen

BM25-Scoring ohne Sparse Vectors

Qdrant unterstützt die Volltextsuche, die Treffer anhand der exakt enthaltenen Wörter findet. Wer diese Ergebnisse bislang mit BM25 ranken wollte, einer weit verbreiteten Ranking-Funktion für die Stichwortsuche, musste den Text in Sparse Vectors umwandeln. Laut Qdrant hat dieser Ansatz Nachteile: Für jedes Dokument und jede Anfrage ist ein Inferenzschritt nötig, und die durchschnittliche Dokumentlänge müssen Nutzer selbst nachhalten. Da dieser Wert in jedem gespeicherten Vektor festgeschrieben ist, passt er sich nicht an veränderte Daten an. Eine Aktualisierung bedeutet, alle Dokumente erneut umzuwandeln.

Version 1.20 führt BM25-Scoring direkt auf dem Volltextindex ein. Qdrant leitet sämtliche BM25-Statistiken, einschließlich der durchschnittlichen Dokumentlänge, aus den Daten ab. Text, der bereits im Payload liegt, ist durchsuchbar, sobald er indiziert ist.

Dazu legt man einen Volltextindex auf einem Feld mit dem Scoring-Typ bm25 an und sendet dann eine text-Anfrage, wobei das indizierte Feld über using angegeben wird. Die BM25-Parameter k und b lassen sich pro Anfrage setzen, sodass für das Tuning kein Neuaufbau des Index nötig ist. Eine Text-Anfrage funktioniert überall in der Query API, auch in der hybriden Suche mit dichten Vektoren oder als Rescoring-Schritt für Punkte, die eine andere Anfrage geliefert hat.

BM25 auf Sparse Vectors wird weiterhin unterstützt. Nutzer, deren Text bereits im Payload liegt, können ohne erneutes Hochladen der Daten wechseln: Sie legen einen Volltextindex mit aktiviertem Scoring an, konfigurieren dieselbe Textverarbeitung wie beim Sparse-BM25-Modell und ersetzen die Sparse-Vector-Anfragen durch Text-Anfragen.

Code-Tokenizer und schnellere verschachtelte Filter

Der Standard-Wort-Tokenizer trennt Text an Leerzeichen und Satzzeichen, was laut Qdrant bei Quellcode schlecht funktioniert. Er indiziert getUserName als ein einziges Token, sodass eine Suche nach user name oder get_user_name keinen Treffer liefert. Der neue Code-Tokenizer zerlegt Bezeichner an Unterstrichen und Groß-/Kleinschreibungswechseln, auch bei Akronymen, sodass getUserName, get_user_name und user name einander finden. Zusätzlich indiziert er den vollständigen Bezeichner, sodass hashmap weiterhin HashMap findet. In Kombination mit BM25-Scoring ermöglicht das eine gerankte Codesuche ohne Embeddings.

Auch verschachtelte Filter, die Punkte finden, bei denen ein einzelnes Array-Element alle Bedingungen erfüllt, wurden verbessert. Bisher konnten Indizes auf Feldern wie offers[].shop und offers[].price die Kandidaten nur eingrenzen. Anschließend las Qdrant den Payload jedes verbleibenden Kandidaten, meist von der Festplatte. Jeder Payload-Indextyp hat nun einen Parameter nested, der einen Index pro Element anlegt. Verwenden alle Bedingungen eines verschachtelten Filters Felder mit einem solchen Index auf demselben Array, beantwortet Qdrant den Filter allein aus den Indizes.

Die Such-API ändert sich nicht, bestehende verschachtelte Filter werden also schneller, sobald die Indizes erstellt sind. In einem Benchmark mit drei verschachtelten Filtern auf 100.000 Punkten waren die Indizes pro Element laut Qdrant 7- bis 38-mal schneller als reguläre Indizes mit Payload-Zugriffen, selbst wenn alle Payloads im Arbeitsspeicher lagen.

Die Datentypen turbo16 und turbo8

Das Release ergänzt zwei TurboQuant-Datentypen. Zuvor bot Qdrant turbo4 (4 Bit, eingeführt in Version 1.19, mit deutlich negativem Effekt auf den Recall bei einigen Datensätzen), float16 und uint8 an.

turbo16 nutzt wie float16 16 Bit pro Dimension, wendet aber zuerst die TurboQuant-Rotation an und speichert jeden Vektor dann auf einem einzigen 16-Bit-Ganzzahlraster. Laut Qdrant halbiert das den Speicherbedarf von float32-Vektoren ohne Genauigkeitsverlust. Über 13 Datensätze hinweg hatte turbo16 einen 7,5-mal geringeren Rekonstruktionsfehler als float16. In Suchbenchmarks auf 12 Datensätzen lag der Recall@10 bei exakter Suche auf jedem Datensatz innerhalb von 0,001 von float32, während float16 bei den Datensätzen ada-002 und CLIP auf 0,995 fiel. Bei der HNSW-Suche lag die mediane Latenz auf x86 beim 0,81-Fachen von float16, auf ARM beim 0,83-Fachen.

turbo8 belegt 1 Byte pro Dimension und quantisiert reguläre Float-Vektoren automatisch, anders als uint8. Laut Qdrant kommt der Recall bei halber Größe nahe an float16 heran. Über 11 Datensätze hinweg waren Suchen 1,1- bis 2,4-mal schneller als mit float16. Im Vergleich zu float32-Vektoren mit Skalarquantisierung und Rescoring erreichte turbo8 bei 10 von 11 Datensätzen einen höheren Recall und bei dem übrigen einen gleichen, bei ähnlicher Latenz und rund einem Fünftel der gespeicherten Bytes.

Die 8-Bit-Kodierung steht auch als TurboQuant-Quantisierung zur Verfügung, indem man bits auf bits8 setzt. Sie komprimiert Vektoren etwa um das Vierfache, gegenüber dem Achtfachen bei bits4, das weiterhin der Standard bleibt.

Was das für Nutzer bedeutet

Teams, die Stichwortsuche auf Payload-Text betreiben, können den Embedding-Schritt streichen und die BM25-Statistiken automatisch aktuell halten. Wer verschachtelte Payload-Filter nutzt, kann Indizes pro Element hinzufügen, ohne die Anfragen zu ändern. Nutzern der Skalarquantisierung rät Qdrant, bits8 als Alternative zu testen, da es die gleiche vierfache Kompression bietet und in den Tests des Unternehmens einen höheren Recall erreicht.