Vektordatenbanken erklärt

Hinter fast jeder „KI-gestützten Suche" und jedem RAG-Feature steckt dasselbe unscheinbare Werkzeug: Ähnlichkeitssuche über Vektoren. Wenn Sie etwas bauen, das relevante Inhalte nach Bedeutung statt nach exakten Schlüsselwörtern findet, müssen Sie Vektoren verstehen – und vor allem wissen, wann Sie dafür eine dedizierte Datenbank brauchen und wann nicht.

Von Text zu Vektoren

Ein Embedding ist eine Liste von Zahlen – ein Vektor –, der die Bedeutung eines Textstücks (oder eines Bilds oder Audios) erfasst. Ein Embedding-Modell wandelt „Abo kündigen" und „Wie höre ich auf zu zahlen?" in Vektoren um, die nah beieinanderliegen, obwohl sie kaum gemeinsame Wörter teilen.

Diese Nähe ist der entscheidende Trick. Bedeutung wird zur Geometrie: Ähnliche Konzepte landen in einem hochdimensionalen Raum nebeneinander, und „verwandte Inhalte finden" wird zu „benachbarte Vektoren finden".

Wie Ähnlichkeitssuche funktioniert

Sobald Ihre Inhalte als Vektoren gespeichert sind, ist der Abruf im Prinzip straightforward:

1. Betten Sie die Suchanfrage des Nutzers in einen Vektor ein.
2. Finden Sie die gespeicherten Vektoren, die ihm am nächsten liegen – typischerweise per Cosinus-Ähnlichkeit.
3. Geben Sie die Inhalte zurück, zu denen diese nächsten Vektoren gehören.

Die Herausforderung liegt in Schritt 2: Wenn Sie Millionen von Vektoren haben, ist der Vergleich mit jedem einzelnen zu langsam. Vektorindizes verwenden daher Approximate-Nearest-Neighbor-Algorithmen (ANN), die minimale Genauigkeitsverluste gegen enormen Geschwindigkeitsgewinn eintauschen.

Brauchen Sie wirklich eine Vektordatenbank?

Das ist die entscheidende Frage – und die ehrliche Antwort lautet: Meistens nicht, zumindest nicht am Anfang.

Wenn Sie bereits PostgreSQL betreiben – und mit Supabase tun Sie das –, fügt die pgvector-Erweiterung Vektorspalten und ANN-Indizierung direkt in Ihre bestehende Datenbank ein. Das bedeutet:

• Ein einziges System, das Sie betreiben, sichern und absichern müssen – kein zweites.
• Joins zwischen Ihren Vektoren und Ihren relationalen Daten in einer einzigen Abfrage: nach Mandant, Datum oder Kategorie filtern und gleichzeitig nach Ähnlichkeit suchen.
• Kein zusätzlicher Dienst, den Sie synchronisieren, bezahlen oder konsistent halten müssen.

Für die meisten Produkte bis in den Millionenbereich an Vektoren ist pgvector kein Kompromiss – es ist die pragmatisch richtige Wahl.

Wann eine dedizierte Vektordatenbank sinnvoll wird

Wechseln Sie zu einem spezialisierten Vektorspeicher, wenn Sie an echte Grenzen stoßen:

• Sehr großer Maßstab – Dutzende oder Hunderte Millionen Vektoren, bei denen zweckgebundene Indizierung und Sharding entscheidend sind.
• Hoher Query-Durchsatz, der mit Ihrer transaktionalen Arbeitslast konkurrieren würde.
• Erweiterte Retrieval-Funktionen wie ausgefeilte Hybrid-Suche oder Filterung, die eine dedizierte Engine besser beherrscht.

Selbst dann gilt: Halten Sie die Metadaten, auf die Ihre Anwendung angewiesen ist, in Postgres – und lassen Sie den Vektorspeicher nur das tun, worin er wirklich überlegen ist.

Retrieval-Qualität richtig hinbekommen

Die Datenbank ist selten das eigentliche Problem – die Retrieval-Qualität ist es. Ein paar Stellschrauben bewegen mehr als die Wahl der Engine:

• Passen Sie das Embedding-Modell an Ihre Domäne an und verwenden Sie dasselbe Modell für Indizierung und Abfragen.
• Kombinieren Sie Vektorsuche mit Schlüsselwortsuche (Hybrid), damit exakte Begriffe wie Produktnamen zuverlässig treffen.
• Filtern Sie vor oder parallel zur Ähnlichkeitssuche, damit Ergebnisse Mandantentrennung und Berechtigungen respektieren.
• Re-ranken Sie die Top-Kandidaten, um den besten Kontext nach vorne zu bringen.

Starten Sie einfach mit pgvector, messen Sie die Retrieval-Qualität anhand echter Anfragen, und skalieren Sie die Infrastruktur erst dann, wenn die Zahlen es verlangen. Wenn Sie KI-Suche oder RAG schnell und präzise aufbauen wollen, ohne den Stack zu übertechnisieren, sprechen Sie uns an.