Vector Databases Embeddings Semantic Search RAG HNSW

Wie eine Vektordatenbank funktioniert: Embeddings, Vektorsuche und menschliches Gedächtnis

Ein auf dem Speichern basierendes mentales Modell für die Vektorsuche: Wie Embeddings, Ähnlichkeitsbetrachtungen, Nachbarschaftsindexe und Metadatenfilter in einer Vektordatenbank für RAG funktionieren.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 24. Sept. 20269 Min. Lesezeit2096 Wörter

Quellen: Your Brain Is a Vector Database. It Just Doesn’t Call Itself That.

Jahre können vergehen, ohne dass man an einen Lehrer aus der Kindheit denkt. Dann bringt bereits ein Hauch von Kreidestaub, der Geruch der Schulmensa oder ein Lied, das früher auf der Heimfahrt im Bus lief, diese Person sofort und lebhaft zurück. Es wurde nichts nach Namen gesucht – etwas Ähnliches trat ein, und die Erinnerung tauchte von selbst auf.

Genau das versuchen semantische Suchsysteme, retrieval-augmented Generation (RAG)-Systeme sowie KI-Empfehlungssysteme, wenn auch unvollkommen, aber ernsthaft nachzubilden – und der entscheidende Bestandteil dafür ist die Vektordatenbank. Die Assoziationsmethode liefert ein gutes mentales Modell, um zu erklären, was Vektoren sind, wie Ähnlichkeit gemessen wird, wie die Suche nach dem nächsten Nachbarn skaliert und wie alle Komponenten zusammen ein Suchverfahren bilden. Gleichzeitig zeigt sie auf, wo die Analogie nicht mehr gilt, denn genau dort neigen Produktionsysteme dazu, Fehler zu machen.

Speichern nach Bedeutung statt nach Name

Das menschliche Gedächtnis verfügt über keinen alphabetischen Index. Es gibt kein mentales Verzeichnis namens „Essen“, das ein Unterverzeichnis „Italienisch“ enthält, welches wiederum eine Datei namens „Pizza“ beherbergt. Genau diese strenge Hierarchie ist es, nach der eine herkömmliche Datenbank Daten organisiert: Jeder Datensatz befindet sich an einer bekannten Adresse und wird über einen exakten Schlüssel gefunden.

Das Gedächtnis hingegen ist nach Bedeutung und Assoziationen organisiert – durch Kontext, durch Gefühle, durch die Beziehung zwischen den Dingen. Die Vorstellung von Pizza wird mit Freitagabenden, einem Besuch in Neapel, gemütlichem Essen, ausgedehnten Käsestreifen, dem Duft von Oregano sowie vielleicht einem Mitbewohner aus der Studentenzeit verbunden, der jede Charge selbstgemachter Teigmasse ruinierte. Wenn man an Pizza denkt, wird keine einzelne Datei geöffnet – vielmehr werden ganze Netzwerke miteinander verbundener Erinnerungen aktiviert, wobei die stärksten Verbindungen zuerst in den Vordergrund treten.

Eine Vektordatenbank nutzt genau dieses Prinzip. Elemente werden danach gespeichert, was sie bedeuten, und werden anhand ihrer Ähnlichkeit mit der Anfrage abgerufen – nicht danach, ob eine Schlüsselwerte genau übereinstimmen.

Was ein Embedding-Vektor kodiert

Um die Datenbank zu verstehen, muss man zunächst verstehen, was sie enthält. Ein Vektor ist hier einfach eine geordnete Liste von Zahlen, die eine Bedeutung darstellen.

Ein Computer hat kein tatsächliches Verständnis dafür, was Pizza ist. Was ein Embedding-Modell durch die Verarbeitung riesiger Mengen an Text lernen kann, ist das Konzept, das ein Wort vermittelt. „Pizza“ taucht in der Nähe von „Käse“, „italienisch“, „Teig“, „Ofen“ und „Scheibe“ auf. Diese Umgebung unterscheidet sich von der um „Sushi“, überschneidet sich aber stark mit der um „Fladenbrot“ oder „Calzone“.

Das Modell fasst diese Muster zu einer Liste mit fester Länge an Zahlen zusammen, meist ein paar hundert bis ein paar tausend Werte; 384 und 1.536 sind typische Größen. Keine einzelne Zahl trägt eine lesbare Beschriftung, doch zusammen positionieren sie den Eintrag präzise in einem hochdimensionalen Raum. Die entscheidende Eigenschaft ist folgende: Eingaben mit ähnlichen Bedeutungen ergeben Vektoren, die in der Nähe voneinander liegen. „Pizza“ befindet sich in der Nähe von „Fladenbrot“ und sehr weit entfernt von „Quartalsgewinnbericht“.

Anders ausgedrückt: Bedeutung wird in Entfernung umgewandelt. Alles Weitere ergibt sich aus dieser einzigen Umwandlung.

Ähnlichkeit als Spektrum, nicht als Übereinstimmung

Eine traditionelle Abfrage ist binär: Eine Zeile erfüllt die Bedingung entweder oder sie tut es nicht. Wenn man nach „Hund“ filtert, erhält man Zeilen, die genau „Hund“ enthalten, während für „Welpen“, „Golden Retriever“ oder „loyaler vierbeiniger Begleiter“ nichts angezeigt wird.

Semantische Ähnlichkeit ersetzt diese Ja-oder-Nein-Antwort durch eine Zahl, die angibt, wie ähnlich zwei Bedeutungen sind. Nach einer veranschaulichenden Skala könnte „Welpen“ gegenüber „Hund“ eine Wertung von 0,94 erhalten, „Wolf“ etwa 0,71 und „Rechnung“ rund 0,08. Die verwendete Metrik ist in der Regel die Kosinusähnlichkeit oder eine verwandte Distanz wie das Skalarprodukt oder die euklidische Distanz, wobei die richtige Wahl davon abhängt, wie das Embedding-Modell trainiert wurde.

Dies spiegelt den Kalkstaub-Effekt wider: Es handelt sich nicht um einen exakten Treffer, sondern um einen Auslöser, der nahegelegene Erinnerungen aktiviert, die wiederum ihre Nachbarn aktivieren. In einer Vektordatenbank sind die Mechanismen numerisch. Die Abfrage wird in einen Vektor umgewandelt, und die Datenbank gibt die gespeicherten Elemente zurück, deren Vektoren am nächsten daran liegen. „Nah“ bedeutet in diesem Zusammenhang ähnliche Bedeutung.

Deshalb kann eine Suche nach „Wie behebe ich eine langsame Datenbankabfrage?“ ein Dokument mit dem Titel „Optimierung der Abfrageleistung in großem Maßstab“ anzeigen, obwohl die beiden Phrasen kaum gemeinsame Wörter enthalten. Ihre Vektoren liegen nah beieinander, weil sie denselben Zweck verfolgen.

Eine Einschränkung bezüglich der Zahlen

Ähnlichkeitswerte sind relativ und nicht absolut. Ein Wert von 0,8 aus einem Embedding-Modell ist nicht mit einem Wert von 0,8 aus einem anderen Modell vergleichbar, und selbst innerhalb eines Modells hängt der typische Wertebereich vom Anwendungsbereich ab. Betrachten Sie die Werte als Möglichkeit, Kandidaten zu ranken, und falls Sie einen Schwellenwert anwenden, kalibrieren Sie diesen an Ihren eigenen Daten anstelle dessen, dass Sie eine runde Zahl wählen.

Eine damit verbundene Korrektur: Reiner, schlagwortbasierter SQL kann keine semantische Ähnlichkeit ausdrücken, doch das bedeutet nicht, dass SQL-Datenbanken ausgeschlossen wären. Erweiterungen wie pgvector, die weiter unten erläutert werden, fügen Postgres Vektorspalten sowie Ähnlichkeitsoperatoren hinzu, sodass diese Funktionen in einer relationellen Datenbank verfügbar sind.

Nachbarsuchalgorithmus in großem Maßstab

Wie findet die Datenbank eigentlich die nächsten Vektoren? Die zentrale Operation wird Nachbarsuchalgorithmus genannt, und seine Beschleunigung ist der Hauptgrund für die Existenz von Vektor-Datenbanken.

Stellen Sie sich jedes gespeicherte Element als einen Stern in einer Galaxie vor, der je nach seinem Sinn platziert wird, wobei verwandte Elemente in derselben Region zusammenkommen. Eine Abfrage fügt eine neue Stern in diese Galaxie ein und fragt, welche fünf vorhandenen Sterne am nächsten sind.

Der naive Ansatz misst die Entfernung von der Abfrage zu jedem gespeicherten Vektor, sortiert die Ergebnisse und gibt die besten wenigen zurück. Bei Tausenden von Vektoren ist das schnell und völlig ausreichend. Bei Millionen oder Milliarden wird das Vergleichen mit allem jedoch sehr schnell teuer.

Produktionsysteme verlassen sich daher auf annähernde Algorithmen des nächsten Nachbarn (ANN). Anstatt jede Sternposition zu überprüfen, nutzen sie einen Index, der die Suche auf vielversprechende Bereiche einengt, wodurch ein geringer Genauigkeitsverlust zugunsten einer erheblichen Geschwindigkeitssteigerung in Kauf genommen wird. Der heute am weitesten verbreitete Algorithmus ist HNSW, abgekürzt für Hierarchical Navigable Small World. Um eine Vektordatenbank verwenden zu können, sind die internen Abläufe nicht notwendig, man sollte jedoch wissen, dass dies der Grund dafür ist, warum eine Suche in Hunderten Millionen von Embeddings bereits in Millisekunden abgeschlossen werden kann.

„Ungefährlich“ verdient Aufmerksamkeit. Ein ANN-Index kann gelegentlich den wahren nächsten Nachbarn übersehen, und die Geschwindigkeit, mit der er die tatsächlich besten Ergebnisse findet – die sogenannte Recall-Rate – hängt von Indexparametern ab, die zwischen Speicherkapazität, Latenzzeit und Genauigkeit abwägen. Wenn die Suchqualität in großem Maßstab unerklärlicherweise ungleichmäßig erscheint, lohnt es sich, die Indexeinstellungen zu überprüfen; unser Leitfaden zu der Anpassung von HNSW-Indizes für die Produktion in RAG-Systemen behandelt diese Einstellungen ausführlich.

Im Inneren der Vektordatenbank

Im Kern ist eine Vektordatenbank eine auf Speicheroptimierung ausgerichtete Lösung für eine einzige Aufgabe: das Speichern von Vektoren sowie das sehr schnelle Durchführen von Suchen nach dem nächsten Nachbarn.

Stellen Sie sich eine Bibliothek vor, die das Dewey-Dezimalsystem ignoriert und Bücher nach ihrem „Gefühl“ einräumt. Bücher über Trauer stehen neben Büchern über Verlust, diese wiederum neben Büchern über Einsamkeit, anschließend über Isolation, und schließlich neben Memoiren von Einzelexpeditionen. Niemand hat diese Kategorien manuell zugewiesen; die Anordnung entstand, weil Leser, die zu einer bestimmten Kategorie neigen, oft auch die anderen möchten.

Pinecone, Weaviate, Chroma und Qdrant sind Beispiele für eine solche Bibliothek. Man lädt sie mit Dokument-Embeddings, Produktbeschreibungen, in Vektoren umgewandelten Bildern oder Mustern des Benutzerverhaltens, und sie halten den Index aufrecht, sodass die Abfragen auch bei wachsenden Sammlungen schnell bleiben.

Jeder gespeicherte Datensatz besteht im Allgemeinen aus drei Teilen:

Einer ID, die das Element eindeutig identifiziert.
Dem Vektor, der seine Bedeutung darstellt.
Optionalem Metadaten wie Titel, Datum, Kategorie oder Quell-URL, die zur Filterung der Ergebnisse verwendet werden können.

Metadaten sind wertvoller, als es auf den ersten Blick scheint. Eine realistische Anfrage sieht so aus: Finden Sie die fünf Dokumente, die dem Suchbegriff am ähnlichsten sind – allerdings nur solche aus den letzten 30 Tagen und ausschließlich aus der Wissensdatenbank des Ingenieurteams. Das ist eine Vektorsuche in Kombination mit einem Metadatenfilter, und die meisten Produktionsysteme verlassen sich auf diese Kombination. Auch die Art und Weise, wie der Filter angewendet wird, ist wichtig: Das Filtern nach der Ähnlichkeitssuche kann dazu führen, dass weniger Ergebnisse zurückgegeben werden, als Sie angefordert haben – überprüfen Sie daher, ob Ihre Datenbank bereits während der Suche filtert.

Der RAG-Auswertungspfad von Anfang bis Ende

Egal, ob er innerhalb eines RAG-Systems, einer semantischen Suchfunktion oder einer Anwendung liegt, die auf gespeichertem Wissen setzt – der Auswertungsvorgang folgt immer denselben vier Schritten.

Einbetten des Inhalts. Jedes Dokument, jeder Artikel, jede Produktbeschreibung oder jede Datenspur, die suchbar sein soll, wird durch ein Einbettungsmodell gegeben, wobei der resultierende Vektor zusammen mit dem ursprünglichen Inhalt gespeichert wird. Lange Dokumente werden in der Regel zunächst in Abschnitte aufgeteilt, da ein einziger Vektor für ein ganzes Handbuch zu viele Ideen miteinander vermischt.
Einbetten der Abfrage mit demselben Modell. Dies ist nicht optional. Verschiedene Einbettungsmodelle erzeugen Vektoren in unverwandten Räumen, wodurch der Vergleich einer Abfrage aus einem Modell mit Dokumenten aus einem anderen Modell sinnlose Entfernungen ergibt. Das Wechseln der Modelle bedeutet, die gesamte Sammlung erneut einzubetten.
Suchen. Der Abfragenvektor wird in die Datenbank übermittelt, eine Suche nach dem nächsten Nachbarn findet die am nächsten liegenden gespeicherten Vektoren, und die besten Ergebnisse werden zurückgegeben, in der Regel zusammen mit Ähnlichkeitswerten.

Nutzen Sie die Ergebnisse. In einem RAG-Pipeline werden die abgerufenen Abschnitte als Kontext an das Sprachmodell übergeben, sodass die Antwort auf echten Dokumenten beruht und nicht auf Vermutungen. Bei Empfehlungssystemen sind die Ergebnisse die Empfehlungen selbst. In Suchfunktionen sind es die angezeigten Treffer für den Benutzer.

Vom Standpunkt des Benutzers aus erscheint eine relevante Antwort innerhalb von Augenblicken. Im Hintergrund wurden Bedeutungen in Zahlen umgewandelt, diese Zahlen mit Millionen gespeicherter Elemente verglichen, die am nächsten liegenden Ergebnisse zurückgegeben und eine Antwort aus echtem Inhalt erstellt.

Warum Vektor-Suche heute überall zu finden ist

Vor nicht allzu langer Zeit waren Vektordatenbanken ein Nischenwerkzeug, das nur dann eingesetzt wurde, wenn semantische Suchfunktionen oder spezialisierte Empfehlungssysteme entwickelt werden sollten. Heute sind sie ein Standardbestandteil vieler KI-Anwendungen. RAG benötigt einen Ort, um Dokumenteinzüge zu speichern und abzufragen. Agenten durchsuchen Wissensbasen nach Bedeutung. Großskalige Empfehlungssysteme basieren auf Vektorähnlichkeit. Multimodale Suche, wie das Finden von Bildern anhand einer Textbeschreibung oder Produkte anhand eines hochgeladenen Fotos, funktioniert ebenfalls über Vektoren.

Falls Sie in der Produktion auf großen Sprachmodellen aufbauen, ist es sehr wahrscheinlich, dass Sie bereits auf Vektorsuche angewiesen sind oder es bald sein werden. Ermutigend ist, dass die Grundidee bereits vertraut ist: Schon seit unserem Leben wird die Erinnerung stets die nächstgelegenen Assoziationen zu dem abgerufen, was gerade unsere Sinne erreicht. Eine Vektordatenbank tut dasselbe mit Zahlen – in Millisekunden und bei Millionen von Elementen.

Wo die Erinnerungsanalogie versagt

Der Vergleich mit dem Gehirn ist für die Intuition nützlich, doch in der Praxis spielen einige Unterschiede eine Rolle:

Die Erinnerung passt sich kontinuierlich an; ein Embedding-Modell bleibt hingegen unverändert. Wenn sich das Vokabular Ihres Bereichs ändert, aktualisieren sich die Vektoren nicht von selbst.
Die Erinnerung verbindet Kontexte mühelos; ein Vektor erfasst nur das, was in ihn eingegeben wird. Schlecht aufgeteilter oder störanfälliger Quelltext führt zu schlechten „Nachbarn“-Vektoren.
Ähnlichkeit bedeutet nicht Relevanz. Zwei Abschnitte können inhaltlich ähnlich sein, während nur einer tatsächlich die Frage beantwortet – deshalb fügen viele Systeme zusätzlich eine Schlüsselwortsuche oder eine Neubewertungsschritt ein.

Praktische Anwendung

Sie können experimentieren, ohne irgendeine Infrastruktur aufbauen zu müssen:

ChromaDB läuft lokal innerhalb von Python – ohne Account, API-Schlüssel oder Bereitstellung – und erfordert nur wenige Zeilen Code zur Installation und Initialisierung. Er eignet sich gut zum Lernen sowie für kleine Projekte.
Qdrant bietet eine kostenlose Cloud-Ebene sowie einen übersichtlichen Python-Client; er ist ideal, wenn man etwas Nahezu-Produktives ohne eigenes Serverbetrieb benötigt. Überprüfen Sie vor der Nutzung die aktuellen Limitierungen dieser Ebene.
pgvector ist eine Erweiterung für Postgres. Wenn Sie bereits Postgres nutzen, fügt sie eine Vektorsuchfunktion hinzu, ohne eine separate Datenbank einzuführen, wodurch die Architektur einfach bleibt.

Egal, welche Lösung Sie wählen, der Arbeitsablauf ist identisch: Sie wählen ein Embedding-Modell, embedden Ihren Inhalt, speichern die Vektoren, embedden eingehende Abfragen und führen die Suche durch. Die Konzepte bleiben unverändert; nur die Client-Bibliothek wechselt.

Das mentale Modell in wenigen Sätzen

Durch Einbettungen wird Bedeutung in Positionen umgewandelt, sodass ähnliche Elemente in der Nähe voneinander landen.
Ähnlichkeitswerte sortieren die Kandidaten; kalibrieren Sie jeden Schwellenwert anhand Ihrer eigenen Daten.
ANN-Indizes wie HNSW tauschen etwas an Rückrufrate gegen große Geschwindigkeitsvorteile bei großen Datenmengen ein.
Metadatenfilter wandeln rohe Ähnlichkeitswerte in Antworten um, die Zeit-, Quellen- und Zugriffsregeln berücksichtigen.
Abfragen und Dokumente müssen dasselbe Einbettungsmodell teilen, und die Qualität der Suche hängt genauso stark von der Aufteilung in Blöcke und der Datenqualität wie von der Datenbank selbst ab.