Qdrant

Klassische Datenbanken suchen nach exakten Treffern: Du fragst nach "Vorsorge" und bekommst genau die Zeilen zurück, in denen das Wort steht. Doch was, wenn jemand "Pensionierung" oder "AHV-Lücke" tippt und trotzdem dieselben Dokumente finden soll? Genau hier setzt eine Vektordatenbank an. Statt Zeichenketten zu vergleichen, arbeitet sie mit der *Bedeutung* von Texten - und liefert ähnliche Inhalte, auch wenn kein einziges Wort übereinstimmt. Qdrant ist eine solche Vektordatenbank: in Rust geschrieben, produktionsreif und darauf optimiert, Millionen von Vektoren mit minimaler Latenz zu durchsuchen. In dieser Anleitung lernst du, was Qdrant ausmacht, wann sich der Einsatz lohnt und wie du es per Docker mit persistentem Storage aufsetzt. Den roten Faden bildet ein Anwendungsfall aus der Praxis: die semantische Suche hinter einem RAG-Chatbot, der seine Antworten aus deinen eigenen Dokumenten zieht.

Was ist Qdrant?

Geschrieben in Rust, läuft Qdrant ressourcenschonend und stabil unter Last. Es bringt ein eigenes Web-Dashboard mit, über das du Collections inspizieren, Suchen testen und den Zustand des Clusters überwachen kannst - praktisch für die Entwicklung und das Debugging.

Vektordatenbank statt Volltextsuche. Qdrant speichert keine Texte, sondern deren mathematische Repräsentation. Ein Embedding-Modell verwandelt jeden Textabschnitt in einen Vektor - eine Liste von Zahlen (oft mehrere hundert bis tausend Dimensionen), die die Bedeutung des Textes als Punkt in einem hochdimensionalen Raum codiert. Ähnliche Inhalte liegen in diesem Raum nahe beieinander.

Punkt = Vektor + Payload. Die Grundeinheit in Qdrant ist der Point. Er besteht aus dem Vektor selbst und einer optionalen Payload - frei strukturierte Metadaten wie Quelle, Tenant-ID, Sprache oder Zeitstempel. So kannst du eine Ähnlichkeitssuche mit klassischen Filtern kombinieren, etwa: finde die semantisch passendsten Dokumente, aber nur jene eines bestimmten Mandanten.

Approximate Nearest Neighbor per HNSW. Eine exakte Suche über Millionen von Vektoren wäre zu langsam. Qdrant nutzt deshalb den HNSW-Index (Hierarchical Navigable Small World), der die nächsten Nachbarn approximativ, aber sehr schnell findet. Du opferst minimal an Trefferpräzision und gewinnst dafür Latenzen im Millisekundenbereich - auch bei grossen Datenmengen.

Collections, Embeddings und Distance-Metrik

Genau dieser Ablauf bildet das Herzstück eines RAG-Systems (Retrieval-Augmented Generation). Statt ein Sprachmodell raten zu lassen, holst du dir aus Qdrant die thematisch passendsten Dokumentabschnitte und reichst sie als Kontext an das LLM weiter. Das Modell antwortet dann belegbar auf Basis deiner Daten - etwa in einem Bot, der Fragen zu internen Richtlinien oder Vorsorge-Dokumenten beantwortet, ohne zu halluzinieren.

Collections gruppieren deine Vektoren. Eine Collection ist vergleichbar mit einer Tabelle: Sie fasst Points zusammen, die dieselbe Vektor-Dimension und dieselbe Distance-Metrik teilen. Pro Anwendungsfall - etwa eine Wissensbasis pro Mandant oder pro Sprache - legst du in der Regel eine eigene Collection an.

Die Distance-Metrik entscheidet über Ähnlichkeit. Beim Anlegen der Collection wählst du, wie Nähe gemessen wird: Cosine (Winkel zwischen Vektoren, der häufigste Fall bei Text-Embeddings), Dot (Skalarprodukt) oder Euclid (euklidischer Abstand). Wichtig ist, dass die Metrik zum verwendeten Embedding-Modell passt - die meisten Text-Modelle erwarten Cosine.

Embeddings kommen von aussen. Qdrant erzeugt die Vektoren nicht selbst. Du berechnest Embeddings vorab mit einem Modell - lokal oder über eine API - und schreibst sie zusammen mit der Payload in die Collection. Bei der Suche embeddest du die Nutzerfrage mit demselben Modell und übergibst den resultierenden Vektor an Qdrant.

Wann und wofür setzt du Qdrant ein?

Wann lohnt sich Qdrant nicht? Wenn deine Suche rein auf exakten Werten, Bereichen oder Volltext beruht, reicht eine relationale Datenbank oder eine klassische Suchmaschine völlig aus. Vektordatenbanken spielen ihre Stärke erst aus, sobald Bedeutung und Ähnlichkeit ins Spiel kommen - oft auch ergänzend (hybrid) zur bestehenden Datenhaltung, nicht als deren Ersatz.

Semantische Suche und RAG. Der klassische Fall: Du willst, dass ein Chatbot oder eine Suchfunktion nach Bedeutung statt nach Stichworten findet. Qdrant liefert die relevantesten Textabschnitte als Kontext für ein LLM - die Grundlage jedes RAG-Chatbots, der auf eigenen Dokumenten arbeitet.

Empfehlungen und Duplikat-Erkennung. Weil ähnliche Inhalte nahe beieinander liegen, eignet sich Qdrant auch für Recommendation-Systeme (ähnliche Produkte, Artikel, Profile) oder um nahezu identische Dokumente und Bilder aufzuspüren.

Mandantenfähigkeit über Payload-Filter. In Multi-Tenant-Szenarien speicherst du eine Tenant-ID in der Payload und filterst jede Suche strikt darauf. So bleibt die Ähnlichkeitssuche schnell, ohne dass Daten verschiedener Mandanten vermischt werden - entscheidend für SaaS-Plattformen mit Datenschutzanforderungen.

Installation mit Docker

Qdrant läuft am einfachsten als offizieller Container. Das Image qdrant/qdrant stellt die REST/HTTP-API samt Web-Dashboard auf Port 6333 und die gRPC-Schnittstelle auf Port 6334 bereit. Damit deine Vektoren einen Neustart überleben, persistierst du das Storage-Verzeichnis /qdrant/storage über ein benanntes Volume - so bleiben die Daten getrennt vom Container-Lebenszyklus erhalten.

1# Image holen
2docker pull qdrant/qdrant
3
4# Container starten: REST/Dashboard (6333) + gRPC (6334),
5# Storage als benanntes Volume persistieren
6docker run -d \
7  --name qdrant \
8  -p 6333:6333 \
9  -p 6334:6334 \
10  -e QDRANT__SERVICE__API_KEY=dein-geheimer-api-key \
11  -v qdrant_storage:/qdrant/storage \
12  qdrant/qdrant

Oder als wiederverwendbare docker-compose.yml:

1services:
2  qdrant:
3    image: qdrant/qdrant
4    container_name: qdrant
5    restart: unless-stopped
6    ports:
7      - "6333:6333"   # REST/HTTP + Web-Dashboard
8      - "6334:6334"   # gRPC
9    environment:
10      # Optionaler API-Key zum Schutz der API
11      QDRANT__SERVICE__API_KEY: dein-geheimer-api-key
12    volumes:
13      - qdrant_storage:/qdrant/storage
14      # Optional: eigene Konfiguration einhängen
15      # - ./config/custom_config.yaml:/qdrant/config/production.yaml
16
17volumes:
18  qdrant_storage:

Prüfe nach dem Start, ob Qdrant erreichbar und bereit ist. Die Kubernetes-Probes /livez und /readyz antworten auch ohne API-Key; /healthz hingegen verlangt den Key, sobald einer gesetzt ist. Das Dashboard erreichst du im Browser.

1# Lebt der Dienst? (Probe ohne API-Key)
2curl http://localhost:6333/livez
3
4# Ist Qdrant bereit, Anfragen zu beantworten? (ohne API-Key)
5curl http://localhost:6333/readyz
6
7# Health-Endpoint mit gesetztem API-Key
8curl -H "api-key: dein-geheimer-api-key" \
9  http://localhost:6333/healthz
10
11# Collections auflisten (mit gesetztem API-Key)
12curl -H "api-key: dein-geheimer-api-key" \
13  http://localhost:6333/collections
14
15# Web-Dashboard im Browser:
16# http://localhost:6333/dashboard

Fazit

Qdrant ist ein robustes, in Rust gebautes Fundament für alles, was mit semantischer Ähnlichkeit zu tun hat. Du speicherst Embeddings als Points mit Payload, wählst pro Collection die passende Distance-Metrik und lässt den HNSW-Index die relevantesten Treffer in Millisekunden finden. In Kombination mit einem LLM wird daraus ein RAG-System, das belegbar auf deinen eigenen Dokumenten antwortet - mit Payload-Filtern bleibt das auch in mandantenfähigen Szenarien sauber getrennt. Mit dem offiziellen Docker-Image, Port 6333 für API und Dashboard, Port 6334 für gRPC und einem benannten Volume für /qdrant/storage hast du in wenigen Minuten eine produktionsnahe Basis stehen. Denk in Produktion an den API-Key und schütze die Ports - dann steht der semantischen Suche nichts mehr im Weg.