Was ist eine Vektordatenbank? Embeddings, Ähnlichkeitssuche und Indexe einfach erklärt
Eine Vektordatenbank speichert Inhalte nicht als Zeichenketten, sondern als Zahlenvektoren (Embeddings) und findet bei einer Anfrage die inhaltlich ähnlichsten Einträge, auch wenn kein einziges Wort übereinstimmt. Das macht sie zu einem zentralen Baustein vieler RAG-Systeme (Retrieval-Augmented Generation). Nötig ist sie aber nicht immer: Häufig genügt eine klassische Volltextsuche oder eine Kombination aus beidem.
Was ist eine Vektordatenbank?
Eine klassische Datenbank sucht nach exakten oder teilweisen Übereinstimmungen: Ein Suchwort muss im Text vorkommen, ein Wert muss in einer Spalte stehen. Eine Vektordatenbank arbeitet anders. Sie speichert für jeden Text, jedes Bild oder jeden Dokumentabschnitt eine mathematische Repräsentation: einen Vektor mit mehreren hundert bis tausend Zahlen, genannt Embedding. Bei einer Anfrage wird diese ebenfalls in einen Vektor umgewandelt, und die Datenbank sucht die Einträge, deren Vektoren am nächsten liegen.
Bekannte Produkte in diesem Bereich sind unter anderem Pinecone, Weaviate, Qdrant, Milvus oder pgvector als Erweiterung für PostgreSQL. Alle verfolgen dasselbe Grundprinzip, unterscheiden sich aber in Indexverfahren, Skalierbarkeit und Betriebsaufwand.
Embeddings: Wie aus Text Zahlen werden
Ein Embedding-Modell übersetzt Text in einen Vektor, der die Bedeutung des Inhalts kodiert. Zwei Sätze mit ähnlichem Sinn (etwa 'Kündigungsfrist für den Mietvertrag' und 'Wie lange im Voraus muss ich die Wohnung kündigen?') landen im Vektorraum nah beieinander, obwohl kaum ein Wort übereinstimmt. Das unterscheidet Embeddings fundamental von Stichwortsuche, die auf exakten Begriffen beruht.
Die Dimension der Vektoren hängt vom Modell ab, typischerweise zwischen 384 und 1536 Zahlen pro Vektor. Wichtig für die Praxis: Embeddings aus unterschiedlichen Modellen sind in der Regel nicht kompatibel. Wechselt man das Modell, müssen alle gespeicherten Inhalte neu eingebettet werden.
Ähnlichkeitssuche: Wie eine Vektordatenbank Treffer findet
Die Ähnlichkeit zweier Vektoren wird meist über Kosinus-Ähnlichkeit, Skalarprodukt oder euklidische Distanz berechnet. Je kleiner der Abstand beziehungsweise je größer die Ähnlichkeit, desto relevanter der Treffer für die gestellte Frage. Bei wenigen hundert Dokumenten lässt sich das per Brute-Force lösen: Jeder Vektor wird mit jedem verglichen. Bei Millionen von Einträgen wird das jedoch zu langsam. Hier kommen approximative Suchverfahren (Approximate Nearest Neighbor, kurz ANN) ins Spiel, die nicht garantiert den exakt besten, aber mit sehr hoher Wahrscheinlichkeit einen sehr guten Treffer liefern, dafür um Größenordnungen schneller.
Indexverfahren im Überblick: HNSW, IVF und Co.
Die Wahl des Indexverfahrens entscheidet über Suchgeschwindigkeit, Genauigkeit und Speicherbedarf. Die gängigsten Ansätze im Überblick:
Vergleich gängiger Indexverfahren für Vektorsuche
| Verfahren | Funktionsweise | Stärken | Grenzen |
|---|---|---|---|
| Flat / Brute-Force | Vergleicht die Anfrage mit jedem gespeicherten Vektor | Exakte Ergebnisse, einfach zu verstehen | Skaliert nicht über einige Hunderttausend Vektoren hinaus |
| HNSW (Hierarchical Navigable Small World) | Baut ein mehrschichtiges Graphennetz zur schnellen Navigation zu nahen Nachbarn | Sehr gute Balance aus Geschwindigkeit und Trefferqualität, Industriestandard | Höherer Speicherbedarf, Index-Aufbau dauert länger |
| IVF (Inverted File Index) | Teilt den Vektorraum in Cluster auf und durchsucht nur die relevantesten Cluster | Speichereffizient, gut parallelisierbar | Genauigkeit hängt stark von der Clusteranzahl ab |
| IVF-PQ (mit Produktquantisierung) | Komprimiert Vektoren zusätzlich, um Speicher zu sparen | Sehr speichersparend bei riesigen Datenmengen | Leichter Genauigkeitsverlust durch Kompression |
Muss ich das Indexverfahren selbst auswählen?
Bei einer selbst betriebenen Vektordatenbank ja, inklusive Tuning von Parametern wie Graphentiefe oder Clusteranzahl. Bei einem gemanagten RAG-Dienst übernimmt der Anbieter diese Entscheidung, sodass Sie sich auf Inhalte statt Infrastruktur konzentrieren können.
Wann brauchen Sie wirklich eine Vektordatenbank für RAG?
Nicht jedes Projekt mit Dokumenten braucht zwingend eine eigene Vektordatenbank. Die folgenden Signale sprechen dafür, dass semantische Suche einen echten Unterschied macht:
- Nutzer formulieren Fragen anders, als die Dokumente formuliert sind (Paraphrasen, Umgangssprache, Synonyme)
- Der Dokumentenbestand ist groß und wächst kontinuierlich (Hunderte bis Zehntausende Seiten)
- Inhalte liegen in mehreren Sprachen vor, sollen aber sprachübergreifend durchsuchbar sein
- Fragen sind eher konzeptionell als nach exakten Begriffen oder Produktnummern gestellt
Wann Volltextsuche reicht
Bei kleinen, gut strukturierten Beständen mit präzisem Fachvokabular (etwa Gesetzestexten, Artikelnummern, internen Richtliniennummern) liefert eine klassische Volltextsuche (zum Beispiel BM25) oft bessere und nachvollziehbarere Ergebnisse als reine Vektorsuche. Exakte Begriffe wie Aktenzeichen oder Paragraphen werden von Embedding-Modellen nicht zwangsläufig bevorzugt gefunden.
Wann Hybrid-Suche die bessere Wahl ist
In der Praxis liefert die Kombination aus Volltextsuche und semantischer Suche (Hybrid-Suche) meist die robustesten Ergebnisse: exakte Treffer bei bekannten Begriffen, semantische Treffer bei umformulierten Fragen. Genau diesen Ansatz nutzt Kopik standardmäßig für hochgeladene Wissensdatenbanken, inklusive semantischer Schlagwort-Erweiterung, ohne dass Sie Indexverfahren selbst konfigurieren müssen.
Vektordatenbank selbst betreiben oder RAG as a Service nutzen?
Eine eigene Vektordatenbank bedeutet laufenden Betrieb: Embedding-Modell auswählen und bei Bedarf wechseln, Indizes pflegen, Skalierung bei wachsendem Dokumentenbestand sicherstellen, Zugriffsrechte verwalten und (gerade für Unternehmen in Deutschland relevant) Fragen zu Datenresidenz und DSGVO-Konformität klären. Wer diese Infrastruktur nicht selbst aufbauen möchte, kann auf einen RAG-as-a-Service-Ansatz setzen, bei dem Upload, Indexierung, Suche und Antwortgenerierung bereits integriert sind. Mehr zu diesem Modell und wann es sich lohnt, lesen Sie im Artikel RAG as a Service: Was es ist und wann es sich lohnt.
Bei Kopik laden Sie PDF-, Word-, Text- oder Markdown-Dateien hoch, die Plattform übernimmt Extraktion, Chunking und Indexierung für die hybride Suche automatisch. Eine Wissensbasis kann privat bleiben (nur für Sie und Ihre API-Schlüssel zugänglich) oder öffentlich im Katalog gelistet werden, wobei Sie den Preis pro Frage festlegen und 70 % der Einnahmen behalten. Abfragen funktionieren über die Website, per REST API oder über einen MCP-Server, der direkt aus Cursor, Claude oder ChatGPT heraus genutzt werden kann.
Eigene Wissensbasis in Minuten statt Monaten
Laden Sie Ihre Dokumente hoch und testen Sie hybride Suche ohne eigene Vektordatenbank-Infrastruktur.
Kurz zusammengefasst
Eine Vektordatenbank macht semantische Suche möglich, indem sie Inhalte als Embeddings speichert und über Indexverfahren wie HNSW oder IVF schnell ähnliche Vektoren findet. Sie lohnt sich vor allem bei großen, uneinheitlich formulierten Dokumentbeständen. Für präzises Fachvokabular reicht oft Volltextsuche, und für die meisten realen Anwendungsfälle liefert eine Hybrid-Suche aus beidem die verlässlichsten Ergebnisse. Wer das nicht selbst aufbauen möchte, findet im Katalog bereits fertige Wissensbasen oder kann in wenigen Minuten eine eigene anlegen.
Häufige Fragen
Was ist der Unterschied zwischen einer Vektordatenbank und einer relationalen Datenbank?
Eine relationale Datenbank sucht nach exakten Übereinstimmungen in Tabellen und Spalten. Eine Vektordatenbank speichert Inhalte als Zahlenvektoren und sucht nach semantischer Ähnlichkeit, auch wenn keine Wörter übereinstimmen.
Brauche ich für jedes RAG-Projekt eine Vektordatenbank?
Nein. Bei kleinen Dokumentenmengen mit präzisem Fachvokabular reicht oft eine Volltextsuche. Vektor- oder Hybrid-Suche lohnt sich vor allem bei großen, uneinheitlich formulierten Beständen.
Was bedeutet HNSW?
HNSW steht für Hierarchical Navigable Small World und ist ein weit verbreitetes Indexverfahren, das einen mehrschichtigen Graphen aufbaut, um sehr schnell nahe Nachbarn eines Vektors zu finden, ohne jeden Eintrag einzeln zu prüfen.
Ist pgvector eine vollwertige Vektordatenbank?
pgvector ist eine Erweiterung für PostgreSQL, die Vektorspeicherung und Ähnlichkeitssuche innerhalb einer bestehenden relationalen Datenbank ermöglicht. Für viele mittelgroße Projekte reicht das aus, bei sehr großen Datenmengen stoßen dedizierte Vektordatenbanken oft schneller an Grenzen.
Wie wirkt sich die DSGVO auf Vektordatenbanken aus?
Embeddings gelten als personenbezogene Daten, wenn sie aus personenbezogenen Texten erzeugt wurden, da sich daraus teilweise wieder Rückschlüsse ziehen lassen. Speicherort, Zugriffsrechte und Löschkonzepte müssen daher wie bei den Originaldokumenten DSGVO-konform geregelt sein.
Was kostet der Betrieb einer eigenen Vektordatenbank?
Neben Lizenz- oder Hosting-Kosten fallen vor allem Aufwände für Embedding-Erstellung, Indexpflege, Skalierung und Betrieb an. Gemanagte RAG-Dienste rechnen stattdessen meist nutzungsbasiert ab, etwa über Credits pro Frage oder ein monatliches Abonnement.
Den Kopik-Newsletter abonnieren
Neue Wissensdatenbanken, RAG-Leitfäden und Produktneuheiten. Eine E-Mail alle ein bis zwei Wochen, Abmeldung mit einem Klick.
Mit dem Abonnement stimmen Sie dem Erhalt unseres Newsletters zu. Ihre Adresse wird nie weitergegeben.