Qdrant: die Vektordatenbank eines RAG lokal

#Wozu eine Vektordatenbank dient

Ein Embedding-Modell wandelt einen Text in eine Liste von Zahlen – einen Vektor – um, sodass zwei Texte mit ähnlicher Bedeutung zwei nahe beieinanderliegende Vektoren ergeben. Relevante Passagen zu einer Frage zu finden, bedeutet dann, die Vektoren zu suchen, die dem Vektor der Frage am nächsten liegen. Bei tausend Passagen genügt eine einfache Berechnung über die gesamte Menge. Bei einer Million braucht man eine Indexstruktur, und genau das ist die Aufgabe einer Vektordatenbank: diese Struktur aufzubauen und zu pflegen, innerhalb weniger Millisekunden zu antworten, statt jeden Vektor einzeln zu vergleichen, und weiterhin korrekt zu arbeiten, während dem Korpus laufend neue Dokumente hinzugefügt werden.

Von diesem Schritt hängt alles Weitere ab: Ein hervorragendes Modell, das die falschen Passagen erhält, antwortet schlecht, und keine Prompt-Anweisung kann eine fehlerhafte Informationssuche ausgleichen. Deshalb verdient die Wahl der Vektordatenbank, die lange als austauschbares Infrastrukturdetail behandelt wurde, dieselbe Sorgfalt wie die Wahl des Sprachmodells selbst.

#Was Qdrant bietet

Das Projekt beschreibt sich selbst als „leistungsstarke Suchmaschine und Vektordatenbank für große Datenmengen“, ausgelegt auf umfangreiche Filterung – das unterscheidet es von Bibliotheken, die lediglich ohne weitere Bedingungen nach dem nächsten Nachbarn suchen. Es ist in Rust geschrieben, was seine Autoren als Grund für seine Geschwindigkeit und Zuverlässigkeit unter hoher Last anführen. Zur betrieblichen Robustheit dokumentiert das Projekt außerdem eine vorauseilende Protokollierung (Write-Ahead Logging), die sicherstellt, dass Daten nach Bestätigung einer Aktualisierung dauerhaft gespeichert bleiben, selbst bei einem Stromausfall. Hinzu kommen Metriken, Telemetrie und Auditprotokolle, um eine Bereitstellung im Produktionsbetrieb zu überwachen und Fehler zu beheben.

Ein eigenständiger Server

Ein Container, eine HTTP- und gRPC-API sowie offizielle Clients für Python, Go, Rust, JavaScript/TypeScript, .NET und Java. Der Server läuft unabhängig von Ihrer Anwendung, die neu gestartet werden kann, ohne jemals den aufgebauten Index zu verlieren.

Filterung nach Payload

Jeder Vektor enthält Metadaten – Autor, Datum, Abteilung, Dokumenttyp –, anhand derer bereits während der Suche mit den Klauseln should, must und must_not gefiltert wird, nicht erst danach. Das ist der Unterschied zwischen einer im Unternehmen nutzbaren Suche und einer Demonstration.

Quantisierung der Vektoren

Die Vektoren komprimieren, um den Speicherbedarf deutlich zu reduzieren (um den Faktor 4 bei skalarer, bis zu 32 bei binärer Quantisierung), auf Kosten eines kontrollierten Genauigkeitsverlusts, der sich ausgleichen lässt.

Dünn besetzte Vektoren und Multivektoren

Neben klassischen dichten Vektoren unterstützt Qdrant auch dünn besetzte Vektoren für die Volltextsuche sowie Objekte mit mehreren Embeddings, die für Modelle mit später Interaktion wie ColBERT nützlich sind.

Hybride Suche

Mehrere Vektoren in derselben Abfrage kombinieren, um sowohl vom semantischen Verständnis als auch von der Genauigkeit der Stichwortsuche zu profitieren. Die Ergebnisse werden dabei mit konfigurierbaren Strategien wie Reciprocal Rank Fusion (RRF) oder Distribution-Based Score Fusion (DBSF) zusammengeführt.

Schnappschüsse und Wiederherstellung

Eine Sammlung sichern und an anderer Stelle wiederherstellen – das ist wichtig, wenn eine erneute Indexierung Stunden an GPU-Rechenzeit kosten würde.

Verteilte Bereitstellung

Eine Sammlung durch Sharding und Replikation auf mehrere Knoten verteilen und ihre Größe ohne Betriebsunterbrechung anpassen – relevant über eine rein lokale Nutzung hinaus, aber gut zu wissen, wenn das Projekt wächst, damit nicht alles von Grund auf neu aufgebaut werden muss, sobald ein einzelner Rechner nicht mehr ausreicht.

#Lokal starten

Der kürzeste Weg führt über den offiziellen Container mit einem Volume, damit die Daten einen Neustart überstehen. Eine integrierte Weboberfläche, vom Projekt als „eine visuelle Möglichkeit, mit Ihren Daten zu interagieren und den Zustand Ihrer Bereitstellung zu überwachen“ beschrieben, ermöglicht anschließend das Erkunden der Collections, die Verwaltung der Daten und das Abfragen der REST-API, ohne eine einzige Zeile Code zu schreiben — sie ist das beste Diagnosewerkzeug, wenn eine Antwort schlecht ist: Man sieht nach, was tatsächlich gefunden wurde, statt beim erneuten Lesen des Retrieval-Codes Vermutungen anzustellen.

docker run -p 6333:6333 -p 6334:6334 \
  -v "$(pwd)/qdrant_storage:/qdrant/storage" \
  qdrant/qdrant

Der Python-Client kann auch ganz ohne Server arbeiten: QdrantClient(":memory:") für einen kurzlebigen Test oder QdrantClient(path="chemin/vers/db") für eine persistente lokale Speicherung. Das ist wertvoll für einen Prototyp oder automatisierte Tests, da derselbe Code anschließend durch die Änderung einer einzigen Zeile für die Verbindung mit einem Server verwendet werden kann. Seit 2026 dokumentiert das Projekt einen zweiten Integrationsweg, Qdrant Edge: eine abgespeckte Version für Geräte mit begrenzten Ressourcen, die direkt im Prozess der Anwendung läuft statt in einer Client-Server-Architektur und sich mit einem vollständigen Qdrant-Server synchronisieren lässt.

#Minimaler Python-Code

1. 01
   Verbinden

   Auf from qdrant_client import QdrantClient folgt client = QdrantClient(url="http://localhost:6333"); damit wird der weiter oben gestartete Container angesprochen.
2. 02
   Eine Sammlung erstellen

   client.create_collection(collection_name="docs", vectors_config=VectorParams(size=1024, distance=Distance.COSINE)) — die Größe muss exakt der Dimension Ihres Embedding-Modells entsprechen.
3. 03
   Einfügen von Punkten

   client.upsert(collection_name="docs", points=[PointStruct(id=1, vector=[...], payload={"service": "support"})]) weist jedem Vektor eine ID und filterbare Metadaten zu.
4. 04
   Abfragen

   client.query_points(collection_name="docs", query=vecteur_question, limit=5).points gibt die fünf nächstgelegenen Abschnitte mit ihrem Score und ihrem Payload zurück.

#Metadatenfilterung: die Funktion, bei der man bereut, sie vernachlässigt zu haben

In der Praxis bezieht sich eine Frage fast nie auf den gesamten Korpus. Gesucht wird in Dokumenten einer Abteilung, in Dokumenten nach einem bestimmten Datum, in Dokumenten eines bestimmten Typs oder in solchen, auf die der fragende Benutzer zugreifen darf. Qdrant wendet diese Bedingungen während der Vektorsuche an und bietet vielfältige Filtermöglichkeiten – Schlüsselwortabgleich, Volltextsuche, numerische Bereiche und Geolokalisierung –, die durch die logischen Klauseln should, must und must_not kombiniert werden. So erhalten Sie stets die richtige Anzahl relevanter Ergebnisse, während eine nachträgliche Filterung unter Umständen keine Ergebnisse übrig lässt.

Die Zugriffskontrolle verdient eine gesonderte Erwähnung: Wenn mehrere Personen denselben Index abfragen, verhindert der Berechtigungsfilter, dass ein Modell einer Person ein Dokument zitiert, das sie nicht lesen darf. Keine Prompt-Anweisung ersetzt diesen Filter. Ihn auf Datenbankebene statt im Anwendungscode zu implementieren, verhindert, dass bei einem neuen Zugangspunkt zur selben Sammlung vergessen wird, ihn erneut anzuwenden.

#In den Speicher passen: Vektorquantisierung

Die dokumentierte Vorgehensweise besteht darin, die komprimierten Vektoren zu durchsuchen und anschließend die besten Kandidaten anhand der ursprünglichen Vektoren neu zu bewerten und zu sortieren (Rescoring). Qdrant stellt einen Oversampling-Parameter bereit, um diesen Kompromiss anzupassen: Bei einem Wert von 2,4 und einem Limit von 100 Ergebnissen werden im quantisierten Index 240 Kandidaten vorausgewählt, bevor die endgültige Neusortierung erfolgt. So bleibt die Genauigkeit weitgehend erhalten, während der Speicherbedarf auf ein Viertel oder weniger sinkt – auf einem Rechner, auf dem auch ein Modell läuft, ist das kein Luxus. Die offizielle Dokumentation nennt außerdem eine bis zu 40-fache Beschleunigung durch binäre Quantisierung gegenüber den ursprünglichen Vektoren. Diese Zahl sollten Sie anhand Ihres eigenen Datensatzes überprüfen, statt sie als gegeben hinzunehmen. Das Projekt fasst all diese Kompressionsoptionen in Kombination mit der Speicherung auf Datenträgern zusammen und kündigt eine Verringerung des Speicherbedarfs um bis zu 97 % an. Diese Größenordnung erklärt, warum Quantisierung als zentrale Funktion und nicht als nebensächliche Einstellung dargestellt wird.

#Qdrant oder eine andere Datenbank

Die Frage, die Sie sich stellen sollten, lautet nicht „Welche Vektordatenbank ist die beste?“, sondern „Was braucht mein Projekt heute?“. Ein Testskript benötigt nichts weiter als eine Bibliothek, die im Arbeitsspeicher arbeitet. Eine Geschäftsanwendung, die bereits PostgreSQL abfragt, profitiert davon, dort eine Vektorerweiterung hinzuzufügen, statt einen weiteren Dienst einzuführen. Qdrant wird genau dann zur richtigen Wahl, wenn mehrere dieser Anforderungen gleichzeitig zusammenkommen: ein von mehreren Anwendungen gemeinsam genutzter Dienst, eine feingranulare Filterung nach Metadaten, ein weiter wachsender Korpus und der Wunsch, Persistenz oder Snapshots nicht selbst neu implementieren zu müssen. Diese Entscheidung regelmäßig zu überprüfen, statt sie schon beim ersten Prototyp festzuschreiben, verhindert sowohl eine unnötig komplexe Architektur für ein kleines Projekt als auch eine zu knapp bemessene Architektur für ein inzwischen gewachsenes Projekt.

• Ein vollständiges lokales RAG-System, von der Datenaufnahme bis zur Antwort
• Ein Modell für französische Embeddings auswählen
• Einen Reranker hinzufügen, um die Relevanz zu verbessern
• pgvector: Wenn PostgreSQL ausreicht
• Das lokale RAG-Kit QuelLLM
• Quelle: offizielles Qdrant-Repository auf GitHub
• Quelle: offizielle Dokumentation zur Quantisierung
• Quelle: Qdrant-Schnellstart mit Python

#FAQ