Qdrant-FineWeb-10B: Vektorsuche realistisch benchmarken

Viele Vektordatenbanken wirken im Test schnell, weil der Benchmark klein, sauber und statisch ist. In produktiven RAG- und Suchsystemen treffen dagegen Milliarden Einträge, Filter, parallele Abfragen, laufende Aktualisierungen und unterschiedliche Vektortypen aufeinander. Qdrant-FineWeb-10B soll diese Lücke mit einem offenen Datensatz im Milliardenmaßstab verkleinern. Zusammen mit dem Open-Source-Framework Supernova entsteht ein reproduzierbarer Werkzeugkasten für Ground Truth, Beladung und Lasttests. Für Unternehmen ist das kein automatischer Siegervergleich, sondern eine Chance, Beschaffungs- und Skalierungsentscheidungen näher am eigenen Betrieb zu prüfen.

Was Qdrant tatsächlich veröffentlicht hat

Der Datensatz umfasst laut Primärquelle 10,07 Milliarden dichte und ebenso viele sparse Vektoren. Hinzu kommen 24,47 Terabyte Vektordaten sowie 28,66 Terabyte Quelltext und Metadaten. Für 100.000 Suchanfragen wurden über den vollständigen Raum exakte Top-1000-Nachbarn per Brute Force berechnet. Qdrant beziffert den Aufwand auf mehr als eine Billiarde Distanzberechnungen. Diese Ground Truth ermöglicht, nicht nur Geschwindigkeit, sondern auch Recall gegen bekannte korrekte Nachbarn zu prüfen.

Mit Supernova wird zusätzlich ein offenes Benchmark-Framework bereitgestellt. Es automatisiert vier Phasen: Embeddings erzeugen, exakte Ground Truth berechnen, Datenbanken beladen und Suchsysteme unter Last bewerten. Die Supernova-Komponente nova-storm erfasst unter anderem Abfragen pro Sekunde, p50-, p95- und p99-Latenzen, Aufbauzeiten und Recall. Als Zielsysteme nennt die Quelle unter anderem Qdrant, Milvus und Elasticsearch.

Wichtig ist die Einordnung: Die Veröffentlichung stammt von Qdrant. Sie liefert Datensatz und Infrastruktur, aber in der herangezogenen Quelle keine unabhängige Rangliste der genannten Datenbanken. Aussagen darüber, welches Produkt allgemein schneller oder günstiger ist, wären daraus nicht ableitbar. Ebenso wenig beweist Internetmaßstab automatisch die Eignung für einen konkreten Unternehmensbestand.

Was das für RAG- und Sucharchitekturen bedeutet

Ein belastbarer Test muss Zielkonflikte sichtbar machen. Niedrige Medianlatenz nützt wenig, wenn die langsamsten fünf Prozent der Abfragen Serviceziele reißen. Hoher Durchsatz ist ebenfalls unzureichend, wenn der Recall bei strengen Filtern einbricht. Supernovas getrennte Messung von Latenzverteilungen, QPS, Aufbauzeit und Recall bietet dafür eine sinnvolle Struktur. Die Auswahl und Gewichtung der Kennzahlen bleibt jedoch eine Unternehmensentscheidung.

Auch die Kostenfrage verschiebt sich. Ein Benchmark in dieser Größenordnung braucht erhebliche Speicher-, Netzwerk- und Rechenressourcen. Daraus folgt nicht, dass jedes Team den vollständigen Datensatz replizieren sollte. Häufig ist ein gestufter Ansatz sinnvoller: zunächst ein repräsentativer Ausschnitt, anschließend ein Lastniveau nahe der geplanten Produktion und erst bei nachgewiesenem Skalierungsrisiko ein größerer Test. Diese Ableitung reduziert Testkosten, ohne die kritischen Engpässe aus dem Blick zu verlieren.

Entscheidungsrahmen vor dem Benchmark

1. Arbeitslast beschreiben: Dokumentzahl, Vektordimensionen, dense-, sparse- und hybride Suche, Filterkomplexität, Aktualisierungsrate und parallele Nutzer festhalten.
2. Qualitätsziel festlegen: eine geprüfte Query-Sammlung mit relevanten Treffern aufbauen und Mindestwerte für Recall sowie fachliche Antwortqualität definieren.
3. Serviceziele trennen: p50 für den Normalfall, p95 und p99 für Ausreißer, QPS für Spitzenlast sowie Belade- und Indexaufbauzeiten separat bewerten.
4. Vergleich fair machen: identische Daten, Queries, Filter, Hardwareklassen, Replikation, Aufwärmphase und Messdauer für alle Kandidaten verwenden.
5. Vollkosten erfassen: Compute, Speicher, Netzwerk, Betrieb, Backups, Neuindizierung und Personalaufwand in die Rechnung aufnehmen.
6. Abbruchkriterien setzen: Tests stoppen, wenn Recall, Wiederherstellbarkeit, Budget oder Sicherheitsanforderungen unter die vorab definierten Grenzen fallen.

Dieser Rahmen verhindert zwei typische Fehler: einen Hersteller-Benchmark unverändert als Beschaffungsentscheidung zu übernehmen oder nur den schnellsten Einzelwert zu optimieren. Das Ergebnis sollte eine belastbare Betriebskurve sein. Sie zeigt, wie Qualität, Latenz und Kosten reagieren, wenn Datenmenge, Gleichzeitigkeit und Filterlast steigen.

Ein kontrollierter Pilot in vier Stufen

• Stufe 1 – Baseline: heutige Suchlösung mit realen Queries, Filtern und Aktualisierungen messen.
• Stufe 2 – Reproduzierbarer Vergleich: dieselbe Arbeitslast über versionierte Konfigurationen in Supernova oder einem gleichwertigen Harness ausführen.
• Stufe 3 – Störfälle: Knotenverlust, verzögerte Replikation, Teilindizes, Reindexierung und Lastspitzen testen; Wiederanlauf und Ergebnisqualität dokumentieren.
• Stufe 4 – Schattenbetrieb: ausgewählte Produktionsanfragen spiegeln, Antworten nicht ausliefern und Abweichungen gegen die bestehende Lösung prüfen.

Freigegeben wird erst, wenn die Zielwerte über mehrere Läufe stabil bleiben. Ein einmaliger Bestwert reicht nicht. Besonders für DACH-Unternehmen gehören Datenstandort, Löschanforderungen, Mandantentrennung und Protokollierung in denselben Testplan wie Recall und Latenz. Testdaten müssen entweder freigegeben oder ausreichend anonymisiert sein.

Risiken, die ein großer Datensatz nicht löst

FineWeb-basierte Inhalte sind nicht automatisch repräsentativ für Verträge, Produktkataloge, technische Akten oder deutschsprachige Fachtexte. Ein System kann auf dem offenen Benchmark stark sein und bei domänenspezifischen Filtern oder seltenen Begriffen schwächeln. Deshalb braucht jeder Vergleich zusätzlich einen eigenen, geprüften Datensatz. Der offene Benchmark beantwortet Skalierungsfragen; die fachliche Eignung belegt er nicht allein.

Zudem können Konfigurationen Ergebnisse stärker beeinflussen als der Produktname. Indexparameter, Quantisierung, Replikation, Cache, Batchgrößen und Hintergrundindizierung müssen offengelegt und versioniert werden. Ohne diese Transparenz entsteht Benchmark-Theater: Zahlen sehen vergleichbar aus, beruhen aber auf unterschiedlichen Betriebsannahmen.

Go/No-Go für die Auswahl

• Go, wenn Recall und fachliche Trefferqualität die Mindestwerte erreichen und p95/p99 unter realistischer Spitzenlast stabil bleiben.
• Go, wenn Neuindizierung, Wiederherstellung und Löschung innerhalb definierter Zeit- und Kostenbudgets funktionieren.
• No-Go, wenn Vorteile nur auf dem offenen Datensatz auftreten, nicht aber auf der eigenen Query- und Filterverteilung.
• No-Go, wenn der Business Case nur mit unrealistischer Hardware, deaktivierten Sicherheitsfunktionen oder nicht vergleichbaren Einstellungen trägt.
• No-Go, wenn Messlauf, Konfiguration und Ground Truth nicht reproduzierbar dokumentiert sind.

Qdrant-FineWeb-10B und Supernova schaffen eine nützliche offene Grundlage für Vektorsuche im Milliardenmaßstab. Der geschäftliche Wert entsteht jedoch erst durch einen Test, der die eigene Arbeitslast, Qualitätsgrenzen und Vollkosten abbildet. Wer Datensatz, Harness und interne Queries kombiniert, erhält eine belastbarere Entscheidungsbasis als aus Produktdemos oder einzelnen QPS-Zahlen.