Von Text zu Zahlen: Embeddings
Grundlage ist ein sogenanntes Embedding-Modell. Es verwandelt einen Text, etwa einen Absatz, in eine lange Reihe von Zahlen, einen Vektor mit oft mehreren hundert bis einigen tausend Stellen. Das Modell ist so trainiert, dass Texte mit ähnlicher Bedeutung ähnliche Zahlenreihen bekommen, auch wenn sie ganz andere Wörter verwenden. „Rechnung bezahlen“ und „Zahlung der Faktura“ landen nah beieinander, „Rechnung“ im Sinne von Mathematikaufgabe weiter weg.
Das aktuelle Embedding-Modell von Google liefert zum Beispiel bis zu 3.072 Stellen. Es ist so trainiert, dass auch gekürzte Vektoren mit 768 oder 1.536 Stellen brauchbar bleiben. Kürzere Vektoren sparen Speicher und Rechenzeit.
Man kann sich das als Landkarte mit sehr vielen Dimensionen vorstellen: Jeder Text ist ein Punkt, und inhaltlich verwandte Texte liegen in derselben Gegend.
Wie die Ähnlichkeitssuche funktioniert
Eine Vektordatenbank speichert diese Punkte und findet zu einer Suchanfrage die nächstgelegenen. Dazu wird auch die Frage in einen Vektor verwandelt. Die Nähe wird mathematisch gemessen, häufig über den Winkel zwischen zwei Vektoren (Kosinus-Ähnlichkeit).
Bei Millionen von Einträgen wäre es zu langsam, jeden einzeln zu vergleichen. Vektordatenbanken nutzen deshalb Näherungsverfahren, die sehr schnell sehr gute, aber nicht garantiert perfekte Treffer liefern. Verbreitet ist das HNSW-Verfahren (Hierarchical Navigable Small World), das 2016 von Yury Malkov und Dmitry Yashunin veröffentlicht wurde. Es baut ein Netz aus Verbindungen zwischen ähnlichen Einträgen in mehreren Ebenen auf, durch das die Suche sich vom Groben ins Feine bewegt.
Wofür Betriebe sie nutzen
- KI-Assistent für interne Dokumente: Die Frage eines Mitarbeiters wird zuerst in der Vektordatenbank gesucht, die passenden Abschnitte gehen zusammen mit der Frage an ein Sprachmodell, das daraus eine Antwort mit Quellenangabe formuliert. Dieses Verfahren heißt Retrieval-Augmented Generation (RAG).
- Bessere Suche im Intranet: Treffer auch dann, wenn die Suchenden andere Begriffe verwenden als die Verfasser.
- Ähnliche Fälle finden: frühere Tickets, Reklamationen oder Angebote, die einem neuen Fall gleichen.
- Doppelte Einträge erkennen, etwa Kunden, die unter leicht unterschiedlichen Namen zweimal angelegt sind.
Eigene Datenbank oder Erweiterung
Es gibt spezialisierte Vektordatenbanken als eigene Produkte. Für viele Betriebe reicht aber eine Erweiterung der vorhandenen Datenbank. Für PostgreSQL gibt es etwa die quelloffene Erweiterung pgvector, die Vektoren neben den übrigen Daten speichert und HNSW als Suchindex unterstützt. Der Vorteil: Rechte, Sicherung und Verwaltung laufen wie bei allen anderen Daten, und es kommt kein weiteres System hinzu.
Die Dokumentation von pgvector nennt als aktuelle Version 0.8.7. Für die Planung ist eine Grenze wichtig: Ein Index ist für normale Vektoren auf 2.000 Stellen begrenzt, mit halber Genauigkeit auf 4.000. Für ein Modell mit 3.072 Stellen braucht es also die halbe Genauigkeit oder kürzere Vektoren. Für die kombinierte Suche empfiehlt die Dokumentation, pgvector mit der Volltextsuche von PostgreSQL zu verbinden.
Wichtig für die Planung: Werden Dokumente geändert, müssen ihre Vektoren neu berechnet werden. Und wird das Embedding-Modell gewechselt, sind alle gespeicherten Vektoren neu zu erzeugen, weil Vektoren verschiedener Modelle nicht vergleichbar sind. Google verlangt das beim Wechsel auf sein neues Embedding-Modell ausdrücklich.
Zugriffsrechte: die wichtigste Frage
Im Dateisystem darf nicht jeder Mitarbeiter jeden Ordner öffnen. Werden alle Dokumente in eine gemeinsame Vektordatenbank geladen, gehen diese Grenzen leicht verloren: Der KI-Assistent findet dann auch für einen Auszubildenden den Abschnitt aus der Gehaltsliste oder dem Personalgespräch, und das Sprachmodell gibt ihn bereitwillig wieder.
OWASP führt Schwächen bei Vektoren und Embeddings deshalb als eigenes Risiko für KI-Anwendungen. Sicher ist nur ein Aufbau, bei dem jeder gespeicherte Abschnitt die Rechte seines Ursprungsdokuments mitträgt und die Suche nur Abschnitte liefert, die der fragende Nutzer auch im Original lesen dürfte. Dazu kommt: Auch aus Vektoren lassen sich unter Umständen Teile des Originaltexts zurückgewinnen. Sie sind deshalb so zu schützen wie die Dokumente selbst.
In der Fassung 2026 der OWASP-Liste steht dieses Risiko auf Platz neun (LLM09:2026). OWASP verlangt dort, die Rechte schon in der Suchabfrage selbst durchzusetzen und nicht erst die fertige Trefferliste zu filtern. Eine Einschränkung, die das Programm des Nutzers mitschickt, gilt nicht als Schutz, die Prüfung gehört auf den Server. Der OWASP-Leitfaden zur Sicherheit von RAG-Anwendungen empfiehlt, die Rechte an jedem einzelnen Abschnitt zu speichern und bei jeder Suche neu zu prüfen, weil sich Berechtigungen seit dem Einlesen geändert haben können.
Bei pgvector ist dabei eine Eigenheit zu beachten. Mit einem Näherungsindex wie HNSW werden Bedingungen erst nach dem Durchsuchen des Index angewandt. Eine Abfrage mit Rechtefilter kann dann weniger Treffer liefern als erwartet. Seit Version 0.8.0 lässt sich die Suche so einstellen, dass sie weitersucht, bis genug passende Treffer gefunden sind.
Wie weit sich Text aus Vektoren zurückgewinnen lässt, zeigten John X. Morris und weitere Autoren 2023: Kurze Texte von 32 Token ließen sich in 92 Prozent der Fälle wörtlich wiederherstellen.
Grenzen
- Exakte Angaben: Bei Rechnungsnummern, Artikelnummern oder Namen ist die klassische Stichwortsuche oft besser. Viele Anwendungen kombinieren deshalb beide Verfahren.
- Zerlegung: Wie Dokumente in Abschnitte geteilt werden, beeinflusst die Trefferqualität stark. Zu kleine Abschnitte verlieren den Zusammenhang, zu große verwässern ihn.
- Aktualität: Die Suche kennt nur, was eingelesen wurde. Veraltete Fassungen liefern veraltete Antworten.
- Untergeschobene Inhalte: Wer Dokumente in den Bestand einbringen kann, kann Texte so formulieren, dass sie bei bestimmten Fragen bevorzugt gefunden werden. Enthalten sie versteckte Anweisungen an das Sprachmodell, wird daraus eine Prompt Injection. Was eingelesen wird, gehört deshalb geprüft.
Fazit
Eine Vektordatenbank macht Wissen auffindbar, das in Dokumenten steckt, aber mit Stichworten nicht zu finden ist. Technisch ist sie heute gut beherrschbar, oft als Erweiterung einer vorhandenen Datenbank. Die eigentliche Arbeit liegt in der Aufbereitung der Dokumente und darin, dass die Suche dieselben Zugriffsrechte beachtet wie das Original.
Quellen
- Yu. A. Malkov, D. A. Yashunin: Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs, 2016, veröffentlicht in IEEE Transactions on Pattern Analysis and Machine Intelligence 2018.
- pgvector: Open-Source-Erweiterung für Vektorsuche in PostgreSQL.
- OWASP GenAI Security Project: OWASP Top 10 for LLM Applications 2025, LLM08 Vector and Embedding Weaknesses (Vorgängerfassung).
- OWASP GenAI Security Project: LLM09:2026 Vector and Embedding Weaknesses, Teil der OWASP Top 10 for LLM Applications 2026, 3. August 2026.
- OWASP Cheat Sheet Series: RAG Security Cheat Sheet.
- John X. Morris u. a.: Text Embeddings Reveal (Almost) As Much As Text, 2023.
- Google AI for Developers: Embeddings, Gemini-API-Dokumentation, abgerufen am 18.10.2026.