Retrieval by Association: Ein auf dem Gedächtnis basierendes mentales Modell für Vektorabfragen

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 auf dem Heimweg mit dem Bus gespielt wurde, diese Person sofort und lebhaft zurück. Es musste nichts nach Namen gesucht werden – etwas Ähnliches trat auf, und die Erinnerung tauchte von selbst auf.

Das ist das Verhalten, das semantische Suchsysteme, retrieval-augmented Generation (RAG) sowie KI-Empfehlungssysteme versuchen, wenn auch unvollkommen, aber ernsthaft nachzuahmen. Der entscheidende Bestandteil dafür ist die Vektordatenbank. Dieser Artikel verwendet das Konzept des „Recall durch Assoziation“ als mentales Modell, um zu erklären, was Vektoren sind, wie Ähnlichkeit gemessen wird, wie die Suche nach dem nächsten Nachbarn skaliert und wie all diese Elemente zu einem Suchprozess zusammenwirken. Zudem weist er darauf hin, wo diese Analogie nicht mehr gilt – schließlich sind genau das die Bereiche, in denen Produktionsysteme oft Fehler 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 eine Unterordnerstruktur mit dem Namen „Italien“ enthält, in der wiederum eine Datei namens „Pizza“ liegt. Genau diese strenge Hierarchie ist es, die herkömmliche Datenbanken zum Organisieren von Daten verwenden: Jeder Datensatz befindet sich an einer bekannten Adresse und wird über einen exakten Schlüssel aufgespürt.

Das Gedächtnis hingegen ist nach Bedeutung und Assoziationen organisiert – durch Kontext, Gefühle sowie 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 Assoziationen zuerst in den Vordergrund treten.

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

Was ein Vektor kodiert

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

Maschinen haben 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 vom „Quartalsgewinnbericht“.

Anders ausgedrückt: Bedeutung wird in Entfernung umgewandelt. Alles Weitere in diesem Artikel folgt aus dieser einzigen Umwandlung.

Ahnlichkeit 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 damit verbundene Distanz wie das Skalarprodukt oder die euklidische Distanz; die richtige Wahl hängt davon ab, 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 gespeicherte 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 Abfragedatenrate 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 statt auf eine runde Zahl zu setzen.

Eine damit verbundene Korrektur: Reiner, schlagwortbasierter SQL kann keine semantische Ähnlichkeit ausdrücken, doch das bedeutet nicht, dass SQL-Datenbanken ausschlossen 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.

Bilden Sie sich jedes gespeicherte Element als einen Stern in einer Galaxie vor, der je nach seiner Bedeutung 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 – dabei wird ein geringer Genauigkeitsverlust in Kauf genommen, um eine erhebliche Geschwindigkeitssteigerung zu erreichen. 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 genau dieser Algorithmus dafür sorgt, dass 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 – 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 zur Anpassung von HNSW-Indizes für die Produktion in RAG-Umgebungen behandelt diese Einstellungen ausführlich.

Hinter den Kulissen des Embedding-Speichers

In seinem Kern ist eine Vektordatenbank ein Speicher, der für eine einzige Aufgabe optimiert ist: Vektoren zu speichern und sehr schnell Nachbarsuchungen an ihnen durchzuführen.

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 den Eintrag 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 gesamte Abrufprozess von Anfang bis Ende

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

1. Einbetten des Inhalts. Jedes Dokument, jeder Artikel, jede Produktbeschreibung oder jedes Datensatz, der 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 Teile aufgeteilt, da ein einziger Vektor für ein ganzes Handbuch zu viele Ideen miteinander vermischt.
2. 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 sinnlose Entfernungen ergibt. Das Wechseln der Modelle bedeutet, die gesamte Sammlung erneut einzubetten.
3. 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 empfohlenen Inhalte. In Suchfunktionen sind es die dem Benutzer angezeigten Treffer.

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 von der Vektorsuche abhängig sind oder es bald sein werden. Ermutigend ist, dass die Grundidee bereits vertraut ist: Schon seit unserem Leben wird das Gedächtnis stets die nächstgelegenen Assoziationen zu dem, was gerade unsere Sinne erreicht, abgerufen. 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.
• Ahnlichkeit 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 einen Neurankingschritt hinzu.

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.
• pgvector ist eine Erweiterung für Postgres. Wenn Sie bereits Postgres nutzen, fügt sie Vektorabfragen hinzu, ohne eine separate Datenbank einzuführen – dadurch bleibt die Architektur einfach.

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

Dasselbe Modell auf beiden Seiten der Bewertung

Kosinus-Ähnlichkeit gilt nur, wenn Anfrage und Passage vom selben Modell eingebettet wurden.

def cosine(a: list[float], b: list[float]) -> float:
    dot = sum(x * y for x, y in zip(a, b))
    na = sum(x * x for x in a) ** 0.5
    nb = sum(y * y for y in b) ** 0.5
    if na == 0 or nb == 0:
        return 0.0
    return dot / (na * nb)

# query and passage must come from the same embedding model
score = cosine(embed(query), embed(passage))

Ein Metadatenfilter steht vor der Nächstes-Nachbar-Suche und entscheidet, wer in die Kandidatenmenge darf.

hits = collection.query(
    query_embeddings=[embed(query)],
    n_results=8,
    where={"tenant_id": tenant_id},
)

Haupterkenntnisse

• Durch Einbettungen wird Bedeutung in Positionen umgewandelt, sodass ähnliche Elemente in der Nähe voneinander landen.
• Ahnlichkeitswerte sortieren die Kandidaten; kalibrieren Sie jeden Schwellenwert anhand Ihrer eigenen Daten.
• ANN-Indizes wie HNSW opfern etwas an Trefferquote ein, um bei großen Datenmengen erhebliche Geschwindigkeitsvorteile zu erzielen.
• 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 vom Datenbanksystem selbst ab.