LLMs und Vektordatenbanken: Wie funktioniert semantische Suche?

Ob eine KI-Anwendung korrekte Antworten liefert, hängt nicht allein vom verwendeten großen Sprachmodell ab. Entscheidend ist auch, wie das Modell auf die benötigten Informationen zugreift. Die Fragen der Nutzer stimmen möglicherweise nicht genau mit den Formulierungen in den gespeicherten Datensätzen überein. Hier wird der Unterschied zwischen einer Suche nach übereinstimmenden Wörtern und einer Suche nach semantischer Ähnlichkeit wichtig. Bei der Auswahl einer Datenbank für LLM-Anwendungen lautet die Ausgangsfrage daher nicht, welches Produkt leistungsfähiger ist, sondern welche Informationen auf welchem Weg zugänglich sein müssen.

SQL- und NoSQL-Datenbanken pauschal als ungeeignet für KI einzustufen, wäre nicht zutreffend. Die Grenze liegt häufig weniger bei der Datenbank selbst als bei der verwendeten Suchmethode. Ein Datensatz mit der Beschreibung roter Sportwagen wird beispielsweise nicht von einer SQL-LIKE-Abfrage gefunden, die nach der exakten Formulierung schnelles Auto sucht. Eine Volltextsuche kann den wortbasierten Zugriff verbessern. Reine Wortübereinstimmungen reichen jedoch nicht immer aus, um ähnliche Konzepte zu erkennen, die unterschiedlich formuliert sind.

Die Grundlage der semantischen Suche bilden Embedding-Modelle, die Inhalte in numerische Vektoren umwandeln. Mithilfe eines geeigneten Modells werden Texte in mehrdimensionale Koordinaten überführt, die semantische Beziehungen abbilden. Auch die Frage des Nutzers wird mit demselben oder einem kompatiblen Modell vektorisiert. Anschließend wird der Abfragevektor mit den Vektoren der Datensätze verglichen. So kann eine Suche nach schnelles Auto einen Datensatz zu einem roten Sportwagen unter den relevanten Ergebnissen anzeigen, obwohl er nicht dieselben Wörter enthält. Der Erfolg hängt von der Qualität des Modells und der Daten ab.

Mit zunehmender Anzahl an Vektoren kann es aufwendig werden, jede Abfrage einzeln mit sämtlichen Datensätzen zu vergleichen. ANN, die approximative Nächste-Nachbarn-Suche, soll ähnliche Vektoren effizienter finden. HNSW ist eines der dafür eingesetzten Indexierungsverfahren. Der Begriff approximativ ist dabei wichtig: Es gilt, ein Gleichgewicht zwischen Suchgeschwindigkeit, Ressourcenverbrauch und dem Auffinden relevanter Ergebnisse herzustellen. Der Wert eines Index sollte daher nicht allein anhand seiner Geschwindigkeit beurteilt werden, sondern auch anhand der von der Anwendung benötigten Ergebnisqualität.

Dieser Ansatz zur Informationsabfrage spielt in RAG-Architekturen eine wichtige Rolle. RAG ruft Inhalte, die zur Frage des Nutzers passen, aus einer Informationsquelle ab und stellt sie dem Sprachmodell als Kontext bereit. Die Vektorsuche ist eine der Methoden, mit denen diese Inhalte ausgewählt werden können; sie ist nicht mit dem Training des Modells gleichzusetzen. Sind die abgerufenen Dokumente fehlerhaft, unvollständig oder irrelevant, kann dies auch die Antwortqualität beeinträchtigen. Bei der Gestaltung einer RAG-Architektur muss deshalb neben der Modellauswahl auch auf die Aufbereitung der Quellinhalte und die Relevanz der Suchergebnisse geachtet werden.

In der Praxis muss die bestehende Datenbank nicht zwangsläufig ersetzt werden. Erweiterungen mit Vektorunterstützung wie pgvector sowie vektororientierte Lösungen wie Pinecone, Weaviate oder Milvus kommen je nach Bedarf infrage. Bei der Entscheidung sollten die Integration in bestehende Systeme, das Datenvolumen, die Filteranforderungen und die Betriebsbedingungen gemeinsam betrachtet werden. Bei X Mind Solutions verstehen wir dies als Aufgabe, eine Architektur zu schaffen, die den Anforderungen der KI an den Informationszugriff entspricht, statt traditionelle Datenbanken auszuschließen.