Von Wörtern zu Bedeutung
Text kann mithilfe eines Embedding-Modells in einen Vektor umgewandelt werden – eine numerische Darstellung seiner semantischen Eigenschaften. Texte mit ähnlicher Bedeutung sollten im Vektorraum näher beieinander liegen.
Vereinfacht:
„vergessenes Passwort“ → [0.12, -0.43, 0.87, …]
und
„Problem bei der Anmeldung“ → [0.15, -0.39, 0.82, …]
Diese Zahlen sagen einem Menschen zunächst nicht viel. Für ein System bestimmen sie jedoch die Position des Textes im Vektorraum. Eine Vector-Datenbank kann anschließend nach Vektoren suchen, die der Anfrage am ähnlichsten sind.
Das Ergebnis ist also nicht einfach:
„Finde ein Dokument, das diese Wörter enthält.“
Sondern eher:
„Finde Inhalte, die dieser Frage semantisch am ähnlichsten sind.“
Was macht eine Vector-Datenbank?
Eine Vector-Datenbank ist ein System zum Speichern, Indexieren und Durchsuchen von Vektorrepräsentationen.
Nehmen wir an, Sie haben 500.000 Dokumente. Jeder relevante Textabschnitt kann mithilfe eines Embedding-Modells in einen Vektor umgewandelt und zusammen mit dem ursprünglichen Inhalt und relevanten Metadaten gespeichert werden.
Wenn ein Nutzer eine Frage stellt, wird auch für diese Frage ein Embedding erstellt.
Frage → Embedding-Modell → Query-Vektor → Vektorsuche → relevante Ergebnisse
Die Datenbank sucht anschließend nach den nächstgelegenen Vektoren.
Dieses Prinzip ist besonders wichtig für RAG (Retrieval-Augmented Generation).
Eine Vector-Datenbank als Gedächtnis für KI
Ein LLM kennt nicht automatisch Ihre internen Unternehmensdokumente. Stattdessen kann eine Anwendung bei jeder Frage zunächst nach relevanten Teilen Ihrer Dokumentation suchen.
Ein Nutzer könnte beispielsweise fragen:
„Wie viele Urlaubstage bekommen wir nach drei Jahren im Unternehmen?“
Die Vektorsuche kann den relevanten Abschnitt in der HR-Dokumentation finden, auch wenn die Frage nicht exakt dieselben Wörter verwendet wie das Dokument.
Dieser Abschnitt wird anschließend als Kontext in den Prompt eingefügt und vom LLM für die Antwort verwendet.
Vereinfacht:
Nutzer → Frage → Embedding → Vektorsuche → relevante Dokumente → LLM → Antwort
Eine Vector-Datenbank ist also nicht die KI selbst. Sie ist Teil eines Systems, das es der KI ermöglicht, mit externen Daten zu arbeiten.
Warum werden Dokumente in kleinere Teile aufgeteilt?
RAG-Systeme teilen Dokumente häufig in kleinere Abschnitte, sogenannte Chunks.
Wenn beispielsweise ein 100-seitiges Dokument mit nur einem einzigen Embedding dargestellt wird, erhält die Suche lediglich eine sehr allgemeine Repräsentation seines Inhalts.
Stattdessen kann das System beispielsweise Folgendes erstellen:
Dokument → Chunk 1 → Embedding
Dokument → Chunk 2 → Embedding
Dokument → Chunk 3 → Embedding
So kann die Suche einen konkreten Teil des Dokuments finden, der die relevante Information enthält.
Die Größe der Chunks muss jedoch sinnvoll gewählt werden. Zu kleine Abschnitte können wichtigen Kontext verlieren, während zu große Abschnitte zu viele irrelevante Informationen enthalten können.
Wie kann man Millionen von Vektoren durchsuchen?
Wenn wir eine große Anzahl von Vektoren haben, könnten wir theoretisch jeden neuen Query-Vektor mit allen vorhandenen Vektoren vergleichen.
Das wäre jedoch langsam und teuer.
Deshalb verwendet die Vektorsuche Indizes und Algorithmen für Approximate Nearest Neighbor (ANN) Search. Damit lässt sich effizient eine kleinere Gruppe von Kandidaten finden, unter denen sich wahrscheinlich die relevantesten Ergebnisse befinden.
Ein verbreiteter Ansatz ist HNSW (Hierarchical Navigable Small World). Dabei wird ein mehrschichtiger Graph verwendet, mit dem sich schnell in den relevanten Bereich des Vektorraums navigieren lässt.
Das Ergebnis ist ein Kompromiss zwischen Suchgeschwindigkeit, Speicherverbrauch und Genauigkeit.
Eine Vector-Datenbank muss kein separates System sein
Vektorsuche bedeutet nicht automatisch, dass eine komplett neue Datenbank eingeführt werden muss.
Zum Beispiel ermöglicht pgvector, Vektoren direkt in PostgreSQL zu speichern und unterstützt sowohl Approximate-Nearest-Neighbor-Suche als auch Indizes wie HNSW und IVFFlat.
Das kann besonders praktisch für Anwendungen sein, die bereits PostgreSQL verwenden.
Für größere oder spezialisierte Projekte gibt es auch Lösungen wie Weaviate oder Milvus. FAISS wiederum ist eine Bibliothek für effiziente Ähnlichkeitssuche und das Clustering dichter Vektoren.
Und wie sieht es mit der Genauigkeit aus?
Vektorsuche bedeutet nicht, dass das System immer die richtige Antwort findet.
Sie findet die ähnlichsten Ergebnisse – diese können aber trotzdem irrelevant sein.
Produktionssysteme verwenden deshalb beispielsweise Similarity Thresholds, Metadatenfilter oder zusätzliche Ranking- und Reranking-Schritte.
Auch die Qualität der zugrunde liegenden Daten, des Chunkings und des Embedding-Modells spielt eine wichtige Rolle.
Wenn beim Retrieval der falsche Kontext gefunden wird, kann selbst ein gutes LLM daraus eine falsche Antwort erzeugen.
Keyword Search vs. Vector Search
Vektorsuche ersetzt die klassische Suche außerdem nicht unbedingt.
Wenn ein Nutzer nach einer konkreten Kennung sucht:
„OBJ-2026-10482“
kann eine exakte Übereinstimmung wesentlich hilfreicher sein als semantische Ähnlichkeit.
Deshalb kombinieren moderne Systeme häufig beide Ansätze in einer hybriden Suche.
Die Keyword-Suche kümmert sich um exakte Begriffe, während die Vektorsuche semantische Ähnlichkeiten berücksichtigt. Die Kombination kann besonders bei technischen oder geschäftlichen Datenbanken hilfreich sein, in denen Nutzer natürliche Sprache mit konkreten Namen und Identifikatoren verbinden.
Wo werden Vector-Datenbanken eingesetzt?
Vektorsuche kann in vielen KI-Anwendungen eingesetzt werden:
Intelligente Suche – Nutzer müssen den genauen Namen eines Dokuments oder Produkts nicht kennen.
RAG-Anwendungen – relevante Informationen werden aus Unternehmensdaten abgerufen und als Kontext für ein LLM verwendet.
Empfehlungssysteme – das System kann Produkte, Artikel oder andere Inhalte finden, die dem Interesse eines Nutzers ähnlich sind.
Bild- und Multimediasuche – Embeddings müssen nicht ausschließlich Text darstellen. Vektorsuche kann auch mit Bildern, Audio und anderen Datentypen eingesetzt werden.
Eine Vector-Datenbank ist keine magische KI-Schicht
Die Qualität des gesamten Systems hängt von der kompletten Pipeline ab:
Daten → Chunking → Embedding-Modell → Index → Retrieval → Reranking → LLM
Sind die Daten schlecht, kann eine Vector-Datenbank das nicht beheben.
Sind die Chunks zu groß oder zu klein, kann die Qualität des Retrievals leiden.
Versteht das Embedding-Modell eine bestimmte Domäne oder Sprache nicht gut genug, können die Ergebnisse schlechter ausfallen.
Und wenn das System den falschen Kontext abruft, kann ein LLM eine überzeugend klingende Antwort auf Basis falscher Informationen erzeugen.
Deshalb sollte man bei KI-Anwendungen nicht nur die Datenbank selbst bewerten. Entscheidend ist die gesamte Retrieval-Pipeline.
Nicht nur das Wort, sondern die Bedeutung
Die wichtigste Veränderung durch Vektorsuche lässt sich einfach zusammenfassen.
Bei einer klassischen Suche fragen wir:
„Enthält dieses Dokument meine Wörter?“
Bei einer Vektorsuche:
„Ist dieses Dokument semantisch ähnlich zu dem, wonach ich suche?“
Nutzer müssen deshalb weder den exakten Namen eines Dokuments noch die in der Datenbank verwendete Terminologie kennen. Sie können ihr Problem einfach beschreiben.
Eine Vector-Datenbank „versteht“ Bedeutung dabei nicht von selbst. Das Embedding-Modell erstellt eine numerische Repräsentation des Inhalts, und die Vector-Datenbank sucht anschließend effizient nach ähnlichen Repräsentationen.
Zusammen ermöglichen diese Technologien KI-Anwendungen, Informationen auf eine Weise zu durchsuchen, die viel näher daran liegt, wie Menschen tatsächlich nach Informationen suchen.
Nicht danach, welches exakte Wort sie eingegeben haben.
Sondern danach, wonach sie wahrscheinlich gesucht haben.