Vektordatenbanken und Embeddings

Vektordatenbanken und Embeddings: das Fundament für semantische Suche und RAG

Embeddings übersetzen Bedeutung in Vektoren, eine Vektordatenbank macht daraus eine semantische Suche nach Ähnlichkeit statt nach Stichworten. Zusammen bilden sie die technische Grundlage, auf der RAG und semantische Suche laufen.

Klassische Suche findet, was wörtlich übereinstimmt. Wer nach "Kündigungsfrist" sucht, verfehlt das Dokument, das von "Vertragsende" spricht, obwohl beide dasselbe meinen. Semantische Suche löst genau dieses Problem, indem sie Bedeutung statt Zeichenketten vergleicht. Diese Seite beschreibt, wie ein Embedding Bedeutung in einen Vektor übersetzt, wie eine Vektordatenbank darin die nächsten Nachbarn findet, welches Spektrum an Datenbanken zur Auswahl steht und worauf bei der Wahl zu achten ist. Sie ist die technische Schicht unter GenAI und RAG; die allgemeine Datenbankstrategie behandelt Modern Databases.

Was ein Embedding ist

Ein Embedding ist ein numerischer Vektor, eine Liste von typischerweise einigen hundert bis einigen tausend Zahlen, die die Bedeutung eines Texts, eines Bildes oder eines anderen Inhalts kodiert. Ein darauf trainiertes Modell, das Embedding-Modell, ordnet ähnliche Inhalte nahe beieinander an und unverwandte weit auseinander. So liegen "Kündigungsfrist" und "Vertragsende" im Vektorraum dicht zusammen, "Kündigungsfrist" und "Gartenzaun" weit auseinander, ganz ohne ein gemeinsames Stichwort.

Damit Vektoren verschiedener Quellen vergleichbar bleiben, müssen alle mit demselben Embedding-Modell erzeugt werden; ein Wechsel des Modells macht eine Neuberechnung des gesamten Bestands nötig. Welches Modell am besten passt, ist messbar: Vergleichsrahmen wie das Massive Text Embedding Benchmark stellen Modelle über viele Aufgaben und Sprachen gegenüber. Für den souveränen Betrieb zählt dabei, dass starke Embedding-Modelle auch als offene Gewichte verfügbar sind und lokal laufen, statt jeden Text an eine fremde API zu schicken.

Semantische Suche als Nächste-Nachbarn-Suche

Steht eine Sammlung von Inhalten als Vektoren bereit, wird Suche zu Geometrie. Die Anfrage wird mit demselben Embedding-Modell in einen Vektor übersetzt; die Datenbank sucht dann die nächsten Nachbarn, also jene gespeicherten Vektoren mit dem kleinsten Abstand zur Anfrage. Der Abstand wird über ein Distanzmass bestimmt, in der Praxis meist die Kosinus-Ähnlichkeit, daneben der euklidische Abstand oder das innere Produkt.

flowchart TD
    A["Text<br/>Dokument oder Anfrage"] --> B["Embedding-Modell<br/>Bedeutung in Zahlen"]
    B --> C["Vektor<br/>einige hundert Dimensionen"]
    C --> D["Vektorraum<br/>Ähnliches liegt nah beieinander"]
    D --> E["Nächste-Nachbarn-Suche<br/>kleinster Abstand zur Anfrage"]
    E --> F["Treffer<br/>nach Bedeutung, nicht nach Stichwort"]

Bei wenigen tausend Vektoren lässt sich jeder Abstand exakt berechnen. Mit Millionen von Vektoren wird das zu langsam, und die Datenbank greift auf eine näherungsweise Suche zurück. Ein Index wie HNSW, ein mehrschichtiger Nachbarschaftsgraph, findet sehr schnell sehr gute, aber nicht garantiert perfekte Nachbarn. Dieser Tausch zwischen Geschwindigkeit und Treffergüte ist der Kern jeder Vektordatenbank; mehr Genauigkeit kostet Rechenzeit und Speicher.

Das Spektrum an Datenbanken

Vektorsuche ist heute keine Nische mehr, sondern eine Funktion mit mehreren Bauformen:

• Erweiterung einer bestehenden Datenbank. Mit pgvector wird PostgreSQL selbst zur Vektordatenbank. Vektoren liegen neben den Geschäftsdaten in derselben Datenbank, mit denselben Transaktionen, Backups und Zugriffsrechten. Das spart eine separate Komponente und hält verwandte Daten zusammen.
• Spezialisierte Vektordatenbank. Systeme, die ausschliesslich auf Vektoren ausgelegt sind, bringen verteilte Indizes und sehr grosse Bestände mit. Den Gewinn an Skalierung erkauft man sich mit einer zusätzlichen Komponente im Betrieb.
• Eingebettete oder Edge-Variante. Schlanke Bibliotheken, die direkt in der Anwendung oder am Gerät laufen, ohne eigenen Serverdienst. Sie passen, wo der Bestand klein und die Nähe zu den Daten wichtig ist.

Diese Bauformen schliessen einander nicht aus. Viele Projekte beginnen mit Postgres und pgvector, weil die Daten ohnehin dort liegen, und wechseln erst dann auf ein spezialisiertes System, wenn Bestand oder Last es erzwingen. Die generelle Frage, für welche Aufgabe welcher Datenbanktyp passt, ordnet Modern Databases ein, die Einbettung in eine Gesamtarchitektur die Data Architecture.

Auswahl-Kriterien

Vier Fragen entscheiden, welche Bauform passt:

• Bestandsgrösse und Last. Für viele sechsstellige Bestände ist eine Postgres-Erweiterung geeignet, abhängig von Dimensionen, Index, RAM, Filtern und Last; Hunderte Millionen mit hoher Abfragerate sprechen für ein spezialisiertes, verteiltes System.
• Hybride Suche. Reine Vektorsuche verfehlt exakte Treffer wie eine Bestellnummer oder einen Eigennamen. Eine hybride Suche, die Vektorähnlichkeit mit klassischer Stichwortsuche und Metadatenfiltern verbindet, liefert in der Praxis die robusteren Ergebnisse; nicht jede Datenbank beherrscht beides gleich gut.
• Betriebsaufwand. Eine vorhandene Datenbank zu erweitern, ist weniger Aufwand als einen neuen Dienst zu betreiben, zu sichern und zu überwachen. Diese laufenden Kosten gehören in die Rechnung, nicht nur der reine Funktionsumfang.
• Datenresidenz. Wo die Vektoren und die zugrundeliegenden Dokumente physisch liegen, ist in der Schweiz eine Compliance-Frage. pgvector auf der eigenen oder einer Schweizer Postgres hält Vektoren, Index und Dokumentbezug unter eigener Kontrolle, ohne Abfluss in eine fremde Cloud.

Gerade das letzte Kriterium verbindet die technische Wahl mit der strategischen. Eine lokale Vektorinfrastruktur ist die technische Grundlage einer souveränen RAG-Architektur; ob ein konkreter Anwendungsfall hält, klärt ein abgegrenztes Erstprojekt der KI-Werkbank, bevor in Skalierung investiert wird.

Wo es bricht

• Falsche Erwartung an Genauigkeit. Embeddings erfassen Bedeutung, nicht Wahrheit. Zwei Sätze können semantisch nah liegen und sich inhaltlich widersprechen. Vektorsuche liefert die plausibelsten Kandidaten, nicht die geprüfte Antwort; die Prüfung leistet erst die RAG-Schicht darüber mit Quellenbezug.
• Veralteter Bestand nach Modellwechsel. Wird das Embedding-Modell getauscht, ohne den Bestand neu zu berechnen, vergleicht die Suche Vektoren aus zwei unvereinbaren Räumen. Die Treffer wirken zufällig, ohne dass ein Fehler im Code sichtbar wäre.
• Nur Vektor, keine Filter. Wer ausschliesslich auf Vektorähnlichkeit setzt, verliert die harten Treffer und die Zugriffsgrenzen. Metadaten und Berechtigungen gehören in dieselbe Abfrage, sonst liefert die Suche auch, was der Nutzende nicht sehen darf.

Vektorsuche unter eigener Kontrolle

Embeddings und Vektordatenbanken sind die Stelle, an der die Datenhoheit technisch konkret wird. Jeder Text, der zur Berechnung eines Embeddings an eine fremde API geht, verlässt das Haus, und das gilt für die Suchanfrage genauso wie für den indexierten Bestand. Ein offenes Embedding-Modell auf eigener Hardware und pgvector auf der eigenen Postgres halten beide Wege im Haus. Damit wird aus einer Architekturentscheidung eine Datenschutzentscheidung: Vektoren, Suchindex und Dokumentbezug bleiben unter eigener Kontrolle, statt über eine fremde Cloud zu laufen. Wie diese Schicht zur belegbaren Antwort wird, beschreibt GenAI und RAG; wer entscheidet, welches Modell auf welchen Daten laufen darf, klärt die KI-Governance. Für Schweizer Organisationen ist das zugleich die Souveränitätsfrage, weil so weder Anfrage noch Bestand das Land verlässt.

Referenzen

• pgvector Open-Source-Vektorsuche für PostgreSQL. PostgreSQL-Erweiterung für Vektorähnlichkeit mit HNSW- und IVFFlat-Index und mehreren Distanzmassen. (2026). github.com/pgvector/pgvector
• Hugging Face Massive Text Embedding Benchmark (MTEB). Vergleichsrahmen für Embedding-Modelle über viele Aufgaben und Sprachen. (19.10.2022). huggingface.co/blog/mteb
• Pinecone Vector Database, Einführung. Lernressource zu Aufbau und Funktionsweise von Vektordatenbanken und Nächste-Nachbarn-Suche. (2026). www.pinecone.io/learn/vector-database/
• Malkov, Yashunin Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs. Die Originalarbeit zum HNSW-Index hinter schneller näherungsweiser Vektorsuche. (30.03.2016). arxiv.org/abs/1603.09320

---

Verwandte Themen

• GenAI und RAG, die Architektur, die Vektorsuche für belegbare Antworten nutzt.
• Modern Databases, die allgemeine Datenbankstrategie und Polyglot Persistence.
• PostgreSQL, die relationale Datenbank, die mit pgvector zur Vektordatenbank wird.
• Data Architecture, die Einbettung in eine Gesamtarchitektur.
• KI-Governance, die Kontrolle darüber, welche Daten in welches Modell fliessen.
• KI-Werkbank, der abgegrenzte Aufbau einer belegbaren Wissensbasis.