Vektordatenbanken
Wie man in Millionen Vektoren den nächsten Nachbarn findet, ohne alle zu vergleichen: HNSW, IVF und der Zielkonflikt zwischen Trefferquote und Latenz.
Die Idee
Ein Embedding verwandelt Text in einen Punkt im Raum. Ähnliche Texte liegen nahe beieinander. Eine Vektordatenbank ist der Kartenschrank dafür: Sie beantwortet die Frage „welche zehn Punkte liegen diesem hier am nächsten?" in Millisekunden statt in Minuten.
Wozu es gut ist
- Eigene Dokumente durchsuchbar machen, ohne exakte Stichwörter.
- Ähnliche Fälle, Artikel oder Bilder finden.
- Grundlage für RAG, also Antworten auf Basis eigener Quellen.
- Doppelte Einträge erkennen.
Die Verfahren
| Verfahren | Aufbau | Suche | Speicher | Wofür |
|---|---|---|---|---|
| Exakt (Flat) | keiner | O(n·d) | Vektoren | bis ~100.000 |
| IVF | Clustering | O(n/k · d) | Vektoren plus Zentren | Millionen, Aufbau schnell |
| HNSW | Graph | O(log n) | Vektoren plus Kanten, hoch | Beste Latenz |
| IVF-PQ | Clustering plus Kompression | schnell | stark reduziert | Sehr große Bestände |
# Ohne eigene Datenbank: pgvector in Postgres
# CREATE EXTENSION vector;
# CREATE TABLE dok (id bigserial, text text, e vector(768));
# CREATE INDEX ON dok USING hnsw (e vector_cosine_ops)
# WITH (m = 16, ef_construction = 64);
#
# SELECT id, text, 1 - (e <=> $1) AS aehnlichkeit
# FROM dok ORDER BY e <=> $1 LIMIT 10;
#
# <=> ist der Kosinusabstand. Der Index greift nur, wenn im ORDER BY
# derselbe Operator steht wie in der Indexdefinition.- Vektoren vor dem Einfügen normalisieren, wenn mit Kosinus gesucht wird.
- Den Suchparameter
ef_searchals Regler zwischen Recall und Latenz behandeln. - Recall gegen eine exakte Suche auf einer Stichprobe messen, nicht schätzen.
- Metadaten mitfiltern lassen, statt nachträglich zu filtern; sonst kommen zu wenige Treffer zurück.
Der Zielkonflikt
Typische Messwerte für HNSW bei einer Million Vektoren mit 768 Dimensionen:
ef_search | Recall@10 | Latenz je Abfrage |
|---|---|---|
| 16 | 0,84 | 0,4 ms |
| 64 | 0,96 | 1,1 ms |
| 128 | 0,985 | 2,0 ms |
| 512 | 0,999 | 7,5 ms |
| exakt | 1,000 | ~380 ms |
Die letzte Zeile zeigt den Gewinn: Faktor 190 bei 1,5 Prozent verlorenen Treffern.
Speicher, durchgerechnet
Für n = 10⁷, d = 768, b = 4, M = 16: Vektoren 30,7 GB, Graph
2,6 GB, zusammen rund 33 GB. In float16 wären es 18 GB, mit
Produktquantisierung auf 96 Byte je Vektor nur noch 3,6 GB, bei einem Recall
um 0,9.
Hybride Suche
Reine Vektorsuche versagt bei Eigennamen, Aktenzeichen und Zahlen. Die übliche Lösung ist eine Kombination mit BM25 und anschließender Zusammenführung:
Der Vorteil gegenüber einer gewichteten Summe der Punktwerte: Ränge sind zwischen den beiden Verfahren vergleichbar, Punktwerte nicht. In Auswertungen verbessert die Kombination Recall@10 gegenüber reiner Vektorsuche regelmäßig um 5 bis 15 Punkte. Siehe RAG, technisch.
Löschen und Betroffenenrechte
Ein Löschbegehren nach Art. 17 DSGVO betrifft auch den Index. Zwei Punkte sind in der Praxis heikel:
- Ein als gelöscht markierter Vektor bleibt im Graphen, bis der Index neu aufgebaut wird. Ein Neuaufbauzyklus gehört deshalb in das Verzeichnis der Verarbeitungstätigkeiten.
- Aus einem Embedding lässt sich der Ausgangstext teilweise rekonstruieren. Ein Embedding ist damit kein anonymisiertes Datum, sondern ein pseudonymisiertes.
Passende Kurse und Quellen
Efficient Estimation of Word Representations
Die Arbeit, die Wörter erstmals als Vektoren mit rechenbarer Bedeutung etablierte. Der Ursprung aller Einbettungen.
Der Ursprung aller Einbettungen; kurz und bis heute erhellend.
LangChain-Dokumentation
Bausteine für Abruf, Werkzeugaufrufe und Agenten. Nützlich als Katalog der Muster, auch wenn man am Ende ohne das Rahmenwerk baut.
Als Musterkatalog nützlich, auch wenn man am Ende ohne das Rahmenwerk baut.