Du besitzt eine Million Textabschnitte.

Für jeden dieser Abschnitte hast du ein Embedding erzeugt.

Also beispielsweise:

Dokument 1
→ [0.13, -0.42, 0.81, ...]

Dokument 2
→ [0.77, 0.21, -0.18, ...]

Dokument 3
→ [-0.09, 0.67, 0.34, ...]

...

Dokument 1.000.000
→ [...]

Nun kommt eine neue Frage:

Wie kann ich mein vergessenes Passwort zurücksetzen?

Auch daraus erzeugst du ein Embedding.

Jetzt möchtest du wissen:

Welche zehn der eine Million gespeicherten Vektoren sind diesem neuen Vektor am ähnlichsten?

Genau für solche Aufgaben werden Vektordatenbanken beziehungsweise Datenbanken mit Vektorsuche eingesetzt.

Eine Vektordatenbank speichert numerische Vektorrepräsentationen und stellt Verfahren bereit, mit denen sich ähnliche Vektoren effizient finden lassen.

Vereinfacht:

Embeddings
↓
Vektordatenbank
↓
Ähnlichkeitssuche
↓
relevante Dokumente

Damit bildet sie eine typische Suchschicht hinter semantischer Suche und vielen RAG-Systemen.

Eine Vektordatenbank speichert keine Gedanken

Der Name klingt fast so, als würde darin die „Bedeutung“ eines Textes als verständliches Wissen abgelegt.

Tatsächlich sieht ein gespeicherter Datensatz eher aus wie:

ID: 4711

Embedding:
[0.18, -0.27, 0.71, ...]

Titel:
Passwort zurücksetzen

Dokument:
account-handbuch.pdf

Version:
4.2

Die eigentliche mathematische Repräsentation ist eine Zahlenreihe.

Die Bedeutung entsteht dadurch, dass ein geeignetes Embeddingmodell ähnliche Inhalte so repräsentiert, dass ihre Vektoren sinnvoll miteinander verglichen werden können.

Die Datenbank selbst muss nicht wissen:

Dieser Absatz handelt von einem Passwort.

Sie muss sehr schnell beantworten können:

Welche gespeicherten Vektoren liegen diesem neuen Vektor am nächsten?

Vektordatenbanken und Embeddings erfüllen unterschiedliche Aufgaben

Das Embeddingmodell erzeugt den Vektor.

Text
↓
Embeddingmodell
↓
Vektor

Die Vektordatenbank speichert und durchsucht diesen Vektor.

Vektor
↓
Vektordatenbank
↓
ähnliche Vektoren

Danach kann das System wieder den eigentlichen Text laden.

ähnliche Vektor-ID
↓
zugehöriger Text
↓
Sprachmodell

Diese Aufgaben sollten sauber getrennt werden.

Ein Embedding ist nicht der eigentliche Dokumentinhalt

Angenommen, ein Abschnitt lautet:

Ein Administrator kann ein Benutzerkennwort im Bereich Benutzerverwaltung zurücksetzen.

Dazu existiert ein Embedding:

[0.17, 0.61, -0.34, ...]

Der Vektor ist nicht dafür gedacht, später wieder exakt in diesen Satz zurückverwandelt zu werden.

Deshalb braucht ein reales System typischerweise eine Verbindung:

Embedding
↔
Chunk-ID
↔
Originaltext

Der Vektor hilft beim Finden.

Der Originaltext liefert die Information.

Was wird in einer Vektordatenbank gespeichert?

Eine einfache Struktur könnte enthalten:

chunk_id

document_id

embedding

text

title

source

language

version

created_at

Je nach Architektur wird der Text direkt in derselben Datenbank gespeichert.

Oder nur eine Referenz auf einen separaten Dokumentenspeicher.

Beides ist möglich.

Wichtig ist:

Der Suchtreffer muss wieder eindeutig zum Originalinhalt führen.

Metadaten sind fast genauso wichtig wie der Vektor

Nehmen wir eine Wissensbasis mit:

deutschen und englischen Dokumenten,

mehreren Produktversionen,

unterschiedlichen Kunden,

internen und öffentlichen Unterlagen.

Die semantische Suche findet einen hervorragenden Treffer.

Leider gehört dieser Treffer:

einem anderen Kunden.

Oder:

einer veralteten Softwareversion.

Oder:

einem Benutzer ohne passende Zugriffsrechte.

Darum braucht die Suche zusätzlich strukturierte Informationen.

Zum Beispiel:

language = de

product_version = 7

tenant_id = 183

visibility = public

Die Vektorähnlichkeit beantwortet:

Passt der Inhalt thematisch?

Metadaten beantworten:

Gehört dieser Inhalt überhaupt in den zulässigen Suchraum?

Eine Vektordatenbank ist deshalb meist eine Kombination aus zwei Welten

Vektorsuche
→ unscharfe semantische Ähnlichkeit

Metadatenfilter
→ exakte Bedingungen

Beispiel:

Finde semantisch passende Dokumente

ABER NUR:

language = de
product = wordpress
version = 6
tenant_id = 17

Diese Kombination macht aus einer reinen Ähnlichkeitssuche ein brauchbares Informationssystem.

Was bedeutet Similarity Search?

Wir besitzen einen neuen Query-Vektor:

Q = [ ... ]

und viele gespeicherte Dokumentvektoren:

A
B
C
D
E
...

Nun berechnen wir:

Ähnlichkeit(Q,A)
Ähnlichkeit(Q,B)
Ähnlichkeit(Q,C)
...

Danach sortieren wir die Ergebnisse.

Zum Beispiel:

B → 0,91
D → 0,87
A → 0,81
C → 0,54
E → 0,21

Das System gibt dann vielleicht die drei besten Treffer zurück.

Welche Distanz wird gemessen?

Dafür existieren unterschiedliche mathematische Verfahren.

Häufig verwendet werden beispielsweise:

Cosine Similarity

Dot Product

euklidische Distanz

Welche Methode sinnvoll ist, hängt vom verwendeten Embeddingmodell und dessen Eigenschaften ab.

Die Datenbank muss deshalb wissen:

Nach welcher mathematischen Beziehung sollen Vektoren geordnet werden?

Ähnlichkeit und Distanz sind zwei Sichtweisen

Bei Ähnlichkeit gilt vereinfacht:

höherer Wert
→ ähnlicher

Bei Distanz:

kleinerer Wert
→ näher

Das Ergebnis kann dennoch dieselbe praktische Frage beantworten:

Welche gespeicherten Vektoren liegen dem Query-Vektor am nächsten?

Was bedeutet k-Nächste-Nachbarn?

Ein häufig verwendeter Begriff lautet:

k-Nearest Neighbors, kurz kNN.

Das k beschreibt einfach:

Wie viele Nachbarn sollen gefunden werden?

Bei:

k = 5

suchen wir die fünf ähnlichsten Vektoren.

Bei RAG wird dieser Wert häufig auch als:

Top-K

bezeichnet.

Die einfachste Suche wäre ein Vergleich mit jedem Vektor

Angenommen, die Datenbank besitzt nur:

100 Vektoren

Dann kann man problemlos jeden einzelnen mit dem Query vergleichen.

Query
↓
vergleiche mit 1
vergleiche mit 2
vergleiche mit 3
...
vergleiche mit 100
↓
sortieren

Das ergibt eine exakte Suche.

Bei Millionen Vektoren wird vollständiger Vergleich teuer

Jetzt besitzt die Datenbank:

100.000.000 Vektoren

Für jede Anfrage jeden einzelnen Vektor vollständig zu vergleichen, kann sehr aufwendig werden.

Genau deshalb existieren spezielle Vektorindizes.

Sie sollen die Suche drastisch beschleunigen.

Das Prinzip kennen wir aus normalen Datenbanken

Eine SQL-Tabelle besitzt zehn Millionen Kunden.

Du suchst:

customer_id = 4711

Ohne Index müsste die Datenbank theoretisch Zeile für Zeile suchen.

Mit einem geeigneten Index findet sie den Datensatz wesentlich effizienter.

Bei Vektoren ist das Problem komplizierter.

Denn wir suchen nicht:

embedding = exakt X

sondern:

welche Embeddings sind ungefähr am ähnlichsten?

ANN steht für Approximate Nearest Neighbor

Eine wichtige Technik lautet:

Approximate Nearest Neighbor Search, kurz ANN.

Der Name enthält bereits den entscheidenden Kompromiss.

Nicht unbedingt:

mathematisch garantiert absolut nächster Treffer

sondern:

mit sehr hoher Wahrscheinlichkeit
sehr gute nächste Treffer

dafür erheblich schneller.

Warum akzeptiert man eine ungefähre Suche?

Angenommen, die exakte Suche benötigt:

2 Sekunden

ANN:

20 Millisekunden

und findet bei fast allen Anfragen dieselben relevanten Top-Treffer.

Für eine Suchanwendung kann das ein hervorragender Kompromiss sein.

Insbesondere wenn Millionen Nutzer oder sehr große Datenbestände beteiligt sind.

ANN ist ein Trade-off

Typischerweise balanciert man:

Geschwindigkeit
↔
Speicher
↔
Trefferqualität

Je genauer gesucht wird, desto mehr Arbeit kann notwendig sein.

Je stärker optimiert wird, desto größer kann die Gefahr sein, einen guten Kandidaten zu übersehen.

Deshalb gehört Retrievalqualität gemessen.

Recall wird dadurch besonders wichtig

Angenommen, für eine Frage existieren zehn wirklich relevante Dokumente.

Die Suche findet neun davon.

Vereinfacht besitzt sie einen hohen Recall.

Findet sie nur zwei:

schlechten Recall.

Bei RAG ist häufig besonders wichtig:

Die relevante Information sollte überhaupt im Kandidatenset auftauchen.

Denn ein Sprachmodell kann kein Dokument verwenden, das ihm nie gegeben wurde.

Ein schneller schlechter Index löst kein Problem

Suchzeit:
3 Millisekunden

relevantes Dokument:
nicht gefunden

ist keine gute RAG-Infrastruktur.

Daher sollte Vektorsuche nicht nur anhand von Latenz bewertet werden.

Man braucht:

Geschwindigkeit
+
Retrievalqualität

Was ist HNSW?

Ein sehr verbreitetes Verfahren für ANN-Suche lautet:

Hierarchical Navigable Small World, kurz HNSW.

Die Grundidee lässt sich als Netzwerk beziehungsweise Graph vorstellen.

Statt alle Vektoren nacheinander zu prüfen, werden Beziehungen zwischen nahegelegenen Punkten aufgebaut.

Vereinfacht:

      ●────●
     /      \
    ●──●────●
       |
       ●────●

Das Suchsystem bewegt sich durch diesen Graphen zu zunehmend ähnlicheren Vektoren.

Warum „Small World“?

Die Idee erinnert an soziale Netzwerke.

Du kennst jemanden.

Der kennt jemanden.

Über relativ wenige Verbindungen kannst du erstaunlich schnell weit entfernte Bereiche erreichen.

Ein HNSW-Index nutzt mehrstufige Navigationsstrukturen, um den Suchraum schnell einzugrenzen.

Für den Anwender zählt vor allem:

HNSW kann sehr schnelle Vektorähnlichkeitssuche mit hoher Retrievalqualität ermöglichen.

HNSW braucht zusätzlichen Speicher

Der Index speichert nicht nur die Vektoren.

Zusätzlich müssen Graphbeziehungen gespeichert werden.

Dadurch kann ein HNSW-Index erheblichen Speicherbedarf besitzen.

Man tauscht also unter anderem:

mehr Speicher

gegen:

schnellere Suche

Das ist ein klassischer Datenbank-Trade-off.

HNSW besitzt Konfigurationsparameter

Solche Indizes können beeinflussen:

wie viele Nachbarschaften aufgebaut werden,

wie intensiv beim Indexbau gesucht wird,

wie breit eine Query den Graphen durchsucht.

Mehr Suchaufwand kann die Chance auf optimale Treffer erhöhen.

Kostet aber:

Zeit.

Die genauen Parameter hängen vom verwendeten Datenbanksystem ab.

Was ist IVF?

Ein anderer Ansatz gehört zur Familie Inverted File Index, häufig kurz IVF.

Die Grundidee:

Der Vektorraum wird in grobe Bereiche aufgeteilt.

Vereinfacht:

┌─────────┬─────────┐
│ Cluster │ Cluster │
│    A    │    B    │
├─────────┼─────────┤
│ Cluster │ Cluster │
│    C    │    D    │
└─────────┴─────────┘

Eine Anfrage muss anschließend nicht alle Bereiche durchsuchen.

Sie konzentriert sich auf vermutlich passende Cluster.

Damit verkleinert IVF den Suchraum

Statt:

100 Millionen Vektoren

zu prüfen:

erst passende Bereiche bestimmen
↓
nur Teilmenge durchsuchen

Auch hier entsteht ein Trade-off zwischen:

Geschwindigkeit

und:

Recall.

HNSW und IVF lösen dasselbe Grundproblem unterschiedlich

Beide versuchen:

großer Vektorbestand
↓
schnelle Suche nach ähnlichen Nachbarn

Welche Indexart sinnvoller ist, hängt unter anderem ab von:

Datenmenge,

Arbeitsspeicher,

Updatehäufigkeit,

Suchlast,

gewünschtem Recall.

Man sollte die Auswahl nicht anhand eines allgemeinen Rankings treffen.

Sondern anhand des eigenen Workloads.

Muss eine Vektordatenbank immer approximate suchen?

Nein.

Für kleinere Datenbestände kann eine exakte Vektorsuche völlig ausreichend sein.

Das kann sogar Vorteile besitzen:

einfacher,

vollständiger Recall,

kein zusätzlicher ANN-Index.

Erst wenn:

Datenmenge

oder:

Anfragevolumen

wachsen, wird ANN zunehmend interessant.

Das ist ein wichtiges Prinzip für den Einstieg

Nicht:

Embeddings
↓
sofort kompliziertesten HNSW-Cluster bauen

Sondern:

kleines System
↓
exakte Suche messen
↓
erst bei Bedarf ANN hinzufügen

Viele KI-Projekte werden unnötig kompliziert, weil für hypothetische Skalierung gebaut wird.

Brauche ich überhaupt eine spezielle Vektordatenbank?

Nicht unbedingt.

Das ist eine der wichtigsten praktischen Fragen.

Viele bestehende Datenbanksysteme können heute Vektordaten über Erweiterungen oder entsprechende Datentypen speichern und durchsuchen.

Ein verbreitetes Beispiel ist:

PostgreSQL
+
pgvector

Damit können normale relationale Daten und Embeddings innerhalb derselben Datenbank liegen.

Warum ist PostgreSQL mit Vektorerweiterung so interessant?

Angenommen, eine Anwendung verwendet ohnehin PostgreSQL.

Dort liegen:

Benutzer,

Dokumente,

Berechtigungen,

Metadaten.

Nun kommen Embeddings hinzu.

Dann kann dieselbe Datenbank beispielsweise speichern:

documents
│
├── id
├── title
├── tenant_id
├── language
├── version
├── content
└── embedding

Das ist architektonisch sehr angenehm.

Besonders Filter lassen sich dann elegant verbinden

Beispiel:

tenant_id = 17
AND
language = 'de'
AND
version = 4

und innerhalb dieser Datensätze:

sortiere nach Vektorähnlichkeit

Relationale Daten und semantische Suche befinden sich in einem System.

Das reduziert Infrastruktur

Alternative:

PostgreSQL
+
separate Vektordatenbank
+
Synchronisationsdienst

Nun müssen Daten zwischen zwei Systemen konsistent gehalten werden.

Mit einer einzigen Datenbank entfällt möglicherweise ein Teil dieser Komplexität.

Weniger Systeme bedeuten weniger Betriebsarbeit

Jedes zusätzliche Datenbanksystem braucht:

Updates,

Backups,

Monitoring,

Berechtigungen,

Netzwerk,

Restore-Tests.

Wenn ein vorhandenes relationales System die Anforderungen erfüllt, kann das sehr attraktiv sein.

Wann reicht PostgreSQL mit Vector Extension häufig aus?

Typische Situationen:

Du betreibst bereits PostgreSQL.

Deine Datenmenge ist überschaubar.

Vektorsuche ist nur eine Funktion unter mehreren.

Metadatenfilter sind wichtig.

Du möchtest möglichst wenig Infrastruktur.

Du brauchst keine extrem hohe verteilte Suchlast.

Dann ist eine integrierte Lösung häufig ein sehr sinnvoller Ausgangspunkt.

Was bedeutet „überschaubar“?

Es gibt keine seriöse universelle Zahl wie:

bis 1 Million
→ PostgreSQL

ab 1.000.001
→ Spezialdatenbank

Die tatsächliche Grenze hängt ab von:

Vektordimension,

Index,

RAM,

CPU,

Speicher,

Queryrate,

Filtern,

Latenzanforderung.

Ein gut gebautes SQL-System kann große Mengen bewältigen.

Ein schlecht konfiguriertes spezialisiertes System kann dagegen langsam sein.

Messen ist wichtiger als Marketinggrenzen.

Wann wird eine spezialisierte Vektordatenbank interessant?

Zum Beispiel wenn Vektorsuche die zentrale Aufgabe der Plattform ist.

Oder wenn:

sehr viele Vektoren,

sehr hohe Queryraten,

verteilte Infrastruktur,

automatisches Sharding,

hohe horizontale Skalierung

benötigt werden.

Spezialisierte Systeme können Funktionen rund um Vektorsuche besonders tief integrieren.

Eine spezialisierte Vector Database kann beispielsweise optimiert sein für

Milliarden Vektoren

verteilte Indizes

Replica-Sets

Sharding

ANN-Suche

Metadatenfilter

Hybrid Search

skalierbare Ingestion

Ob diese Fähigkeiten wirklich gebraucht werden, ist die entscheidende Frage.

„Vector Database“ ist keine geschützte technische Kategorie

Unter diesem Begriff werden sehr unterschiedliche Produkte angeboten.

Manche sind:

vollständige Datenbanken.

Andere eher:

spezialisierte Suchsysteme.

Andere:

verwaltete Cloud-Dienste.

Andere:

Erweiterungen normaler Datenbanken.

Man sollte daher nicht nur auf das Etikett schauen.

Die bessere Frage lautet:

Welche Anforderungen besitzt mein Retrievalsystem?

Zum Beispiel:

Wie viele Vektoren?

Wie viele Queries pro Sekunde?

Welche Latenz?

Welche Metadatenfilter?

Wie häufig Updates?

Welche Verfügbarkeit?

Welche Backups?

Lokal oder Cloud?

Welche Kosten?

Danach lässt sich Technologie auswählen.

Eine Vektordatenbank ersetzt keine SQL-Datenbank

Angenommen, du möchtest wissen:

Welche Kunden haben diesen Monat mehr als drei Rechnungen nicht bezahlt?

Das ist eine strukturierte Abfrage.

SQL ist hervorragend dafür.

Kunden
JOIN Rechnungen
WHERE ...
GROUP BY ...

Vektorsuche wäre dafür unnötig.

Umgekehrt ist SQL-Gleichheit schlecht für semantische Fragen

Frage:

Welche Supporttickets behandeln ungefähr dasselbe Problem wie dieses Ticket?

Nun ist Vektorähnlichkeit sehr nützlich.

Die richtige Architektur kombiniert beides.

Ein typisches Produkt kann daher so aussehen

PostgreSQL
│
├── Kunden
├── Rechte
├── Dokumente
├── Versionen
└── Metadaten

Vector Index
│
└── semantische Ähnlichkeit

Darüber:

RAG
↓
LLM

Was ist Hybrid Search?

Wie bereits bei RAG gesehen, besitzt semantische Suche Grenzen.

Frage:

ERR_SSL_PROTOCOL_ERROR

Eine Keyword-Suche kann diesen exakten Ausdruck hervorragend finden.

Vektorsuche findet vielleicht ähnliche SSL-Probleme.

Beide Signale können sinnvoll sein.

Hybrid Search kombiniert deshalb typischerweise lexikalische und semantische Suche.

Ein vereinfachter Ablauf

Frage
↓
├── Volltextsuche
│
└── Vektorsuche
↓
Ergebnislisten
↓
zusammenführen
↓
Ranking

Damit erhalten wir:

exakte Begriffe

und:

semantisch ähnliche Inhalte.

Das ist besonders bei technischen Inhalten wertvoll

Nehmen wir:

RTX 4060 Ti

Semantische Suche könnte auch:

RTX 4060,

RTX 4070

finden.

Vielleicht ist das hilfreich.

Vielleicht möchte der Nutzer aber exakt die 4060 Ti.

Keyword-Suche sorgt dafür, dass der exakte Modellname stark berücksichtigt wird.

Dasselbe gilt für Artikelnummern

ABC-17283-X

hat kaum semantische Bedeutung.

Es ist eine technische Kennung.

Exakte Suche ist hier viel stärker.

Hybrid Search lässt unterschiedliche Signale zusammenkommen

Beispielsweise:

semantische Ähnlichkeit
+
Keywordscore
+
Aktualität
+
Quellenqualität

Ein späteres Ranking bestimmt die Reihenfolge.

Damit wird Suche zunehmend zu einem Mehrsignal-System.

Was ist Reciprocal Rank Fusion?

Eine Möglichkeit, unterschiedliche Ergebnislisten zu kombinieren, ist eine Rangfusionsmethode wie Reciprocal Rank Fusion, kurz RRF.

Die Grundidee:

Nicht unbedingt die völlig verschiedenen Rohscores miteinander vergleichen.

Sondern betrachten:

Auf welchem Rang steht ein Dokument in jeder Ergebnisliste?

Beispielsweise:

Dokument A

Keyword-Suche:
Rang 1

Vektorsuche:
Rang 4

kann dadurch einen hohen kombinierten Wert erhalten.

Für das Grundverständnis genügt:

Mehrere Suchverfahren können zunächst unabhängig arbeiten und ihre Ranglisten anschließend zusammengeführt werden.

Danach kann Reranking folgen

Hybrid Retrieval findet vielleicht:

50 Kandidaten

Nun bewertet ein genaueres Modell:

Welcher Abschnitt beantwortet diese konkrete Frage tatsächlich?

50 Kandidaten
↓
Reranker
↓
Top 5

Die Vektordatenbank muss damit nicht zwingend die endgültige Reihenfolge bestimmen.

Sie kann vor allem eine schnelle Kandidatenauswahl liefern.

Retrieval ist also oft eine Pipeline

Query
↓
Filter
↓
Keyword Search
+
Vector Search
↓
Fusion
↓
Reranking
↓
Top-K Kontext
↓
LLM

Das zeigt:

Eine gute RAG-Suche besteht nicht unbedingt nur aus:

vector.search()

Wie speichert man mehrere Embeddingmodelle?

Angenommen, du verwendest heute:

Embeddingmodell A.

Später kommt Modell B.

Die Vektoren beider Modelle leben normalerweise in unterschiedlichen mathematischen Räumen.

Darum sollte man sie nicht ungeprüft gemeinsam vergleichen.

Eine Datenstruktur könnte enthalten:

embedding_a

embedding_b

oder getrennte Tabellen beziehungsweise Indizes.

Das Embeddingmodell gehört zur Datenversion

Beispielsweise:

embedding_model:
model-a

embedding_version:
3

Damit weiß das System später:

Mit welchem Modell wurde dieser Vektor erzeugt?

Das wird bei Migrationen sehr wichtig.

Modellwechsel kann Re-Embedding erfordern

Bei einer Million Chunks:

1.000.000 alte Embeddings

Neues Modell:

alle relevanten Chunks
↓
erneut berechnen

Das kann erhebliche Rechenzeit und Kosten verursachen.

Der Embeddingmodellwechsel sollte deshalb nicht leichtfertig passieren.

Eine Migrationsstrategie kann parallel arbeiten

Zum Beispiel:

altes Embedding
+
neues Embedding

für eine Übergangszeit.

Neue Dokumente erhalten beide.

Bestehende werden schrittweise neu eingebettet.

Danach wechselt die Suche vollständig auf den neuen Index.

Das verhindert einen harten Big-Bang-Wechsel.

Dokumentänderungen brauchen ebenfalls neue Embeddings

Artikelversion 1:

maximal 10 Benutzer

Artikelversion 2:

maximal 50 Benutzer

Das alte Embedding repräsentiert den alten Text.

Darum:

Dokument geändert
↓
betroffene Chunks neu erzeugen
↓
neue Embeddings
↓
Index aktualisieren

Nicht jede kleine Änderung muss zwingend alles neu berechnen

Bei einem 300-seitigen Handbuch wurde nur Kapitel 12 geändert.

Dann reicht häufig:

Chunks aus Kapitel 12 neu erstellen.

Der Rest bleibt unverändert.

Eine gute Datenpipeline erkennt Änderungen möglichst granular.

Content Hashes können dabei helfen

Ein Chunk erhält beispielsweise einen Hash seines Originalinhalts.

alter Hash
=
neuer Hash?

Wenn ja:

kein Re-Embedding notwendig.

Wenn nein:

neu berechnen.

So lässt sich eine große Wissensbasis effizient aktualisieren.

Löschen ist genauso wichtig wie Hinzufügen

Ein Dokument wurde entfernt.

Dann müssen gegebenenfalls verschwinden:

Originaltext,

Chunks,

Embeddings,

Caches,

Suchindexeinträge.

Sonst kann das System gelöschte Information weiterhin finden.

Soft Delete kann problematisch sein

Die relationale Tabelle markiert:

deleted = true

aber die Vektorsuche ignoriert dieses Feld.

Dann erscheint der Inhalt weiterhin.

Jede Retrievalquery muss Berechtigungs- und Statusbedingungen konsequent berücksichtigen.

Was passiert mit dem ANN-Index nach vielen Änderungen?

Indizes müssen ebenfalls gepflegt werden.

Je nach System können:

viele Inserts,

Updates,

Deletes

Auswirkungen auf:

Indexgröße,

Suchqualität,

Speichernutzung

haben.

Manche Systeme benötigen gelegentliche Wartung, Optimierung oder Rebuilds.

Das ist normale Datenbankarbeit.

Eine Vektordatenbank braucht Backups

Auch wenn Embeddings theoretisch aus den Originaldaten erneut erzeugt werden können, ist ein kompletter Neuaufbau möglicherweise teuer.

Bei Millionen Chunks kostet Re-Embedding:

Zeit,

Rechenleistung,

API-Geld.

Deshalb sollten relevante Datenbestände nach normaler Backupstrategie gesichert werden.

Was ist wirklich unersetzbar?

In einer gut geplanten Architektur kann man unterscheiden:

Originaldokumente
→ Source of Truth

Chunks
→ daraus reproduzierbar

Embeddings
→ daraus reproduzierbar

ANN-Index
→ aus Embeddings reproduzierbar

Das bedeutet nicht, dass man nur Originaldokumente sichern sollte.

Aber es hilft, Recovery-Prioritäten zu verstehen.

Der ANN-Index ist häufig eher abgeleitete Infrastruktur

Wenn die gespeicherten Embeddings noch vorhanden sind, kann ein Index gegebenenfalls neu aufgebaut werden.

Verliert man dagegen:

die einzigen Originaldokumente

und:

die Embeddings enthalten nicht den vollständigen Inhalt,

kann der ursprüngliche Informationsbestand nicht einfach rekonstruiert werden.

Das kennen wir aus Backup richtig planen:

Nicht jede Komponente besitzt denselben Wiederherstellungswert.

Restore-Tests gelten auch hier

Backup vorhanden:

gut.

Kann daraus die Datenbank samt Vektoren und Metadaten erfolgreich wiederhergestellt werden?

Besser.

Bei einer produktiven Wissens-KI sollte ein Restore-Verfahren nicht erst beim ersten Serverausfall ausprobiert werden.

Vektordatenbanken brauchen Monitoring

Mindestens interessant sind beispielsweise:

Anzahl Vektoren

Indexgröße

Querylatenz

Fehlerrate

Insert-Rate

Speichernutzung

Für RAG zusätzlich:

Retrievalqualität

Ein technisch schneller Index kann fachlich schlecht suchen.

Beides muss beobachtet werden.

P95 und P99 sind häufig aussagekräftiger als Durchschnitt

Angenommen:

durchschnittliche Query:

20 ms.

Aber jede hundertste:

3 Sekunden.

Der Durchschnitt sieht hervorragend aus.

Nutzer erleben trotzdem regelmäßig Verzögerungen.

Darum betrachtet man bei produktiven Systemen häufig Perzentile wie:

P95

oder:

P99.

Das gilt für Vektorsuche genauso wie für andere Backenddienste.

Vektorsuche braucht Lasttests

Ein Entwickler testet:

eine Query.

Antwortzeit:

10 ms.

In Produktion kommen gleichzeitig:

500 Nutzer.

Nun steigt:

CPU,

RAM,

Latenz.

Eine Datenbank sollte unter realistischer Parallelität getestet werden.

Das gilt besonders für lokale KI-Infrastruktur

Ein lokaler Server kann gleichzeitig betreiben:

Vektordatenbank,

Embeddingmodell,

LLM,

Automatisierungssoftware.

Bei geringer Nutzung funktioniert alles hervorragend.

Unter Last konkurrieren die Dienste um:

RAM,

CPU,

SSD-I/O,

GPU.

Ressourcenplanung sollte deshalb das Gesamtsystem betrachten.

Vektordatenbanken brauchen nicht unbedingt eine GPU

Die eigentliche Similarity Search kann je nach System und Größe sehr gut auf CPUs laufen.

Eine GPU kann für bestimmte Workloads oder Systeme Vorteile besitzen.

Aber:

Vektordatenbank
=
GPU zwingend

ist falsch.

Das Embeddingmodell und insbesondere das generative LLM haben häufig deutlich stärkeren GPU-Bedarf.

RAM kann für Vektorsuche sehr wichtig sein

ANN-Indizes profitieren häufig davon, wenn relevante Indexstrukturen im Arbeitsspeicher verfügbar sind.

Ein großer Index, der ständig langsamen Massenspeicher nachladen muss, kann höhere Latenzen verursachen.

Bei Hardwareplanung sollte deshalb nicht nur auf GPU-VRAM geschaut werden.

SSD-Leistung kann ebenfalls relevant sein

Bei großen Datenbeständen passen nicht alle Informationen dauerhaft in RAM.

Dann werden:

schnelle SSDs,

Caching,

Indexarchitektur

wichtig.

Ein RAG-Server ist nicht nur eine Grafikkartenmaschine.

Er ist ein komplettes Datenbanksystem.

Vektordatenbanken können verteilt werden

Wächst der Datenbestand über einen einzelnen Server hinaus, kann er auf mehrere Knoten verteilt werden.

Das nennt man häufig:

Sharding.

Vereinfacht:

Shard 1
→ Vektoren A–F

Shard 2
→ Vektoren G–M

Shard 3
→ Vektoren N–Z

Die tatsächliche Aufteilung funktioniert je nach System anders.

Queries müssen dann mehrere Shards berücksichtigen

Query
↓
Shard 1
Shard 2
Shard 3
↓
lokale Top-Treffer
↓
zusammenführen
↓
globale Top-K

Das erhöht Architekturkomplexität.

Darum sollte horizontale Skalierung nicht eingebaut werden, solange ein einzelner Server problemlos reicht.

Replikation löst wieder ein anderes Problem

Sharding:

Daten aufteilen

Replikation:

Daten mehrfach vorhalten

Replikate können helfen bei:

Verfügbarkeit,

Leselast,

Ausfallsicherheit.

Beide Konzepte können kombiniert werden.

Eine spezialisierte Vector Database kann solche Funktionen leichter bereitstellen

Genau hier liegt ein Vorteil spezialisierter Systeme.

Wer:

sehr große Datenmengen,

weltweit verteilte Anwendungen,

hohe Verfügbarkeit

braucht, möchte nicht jede verteilte Suchkomponente selbst entwickeln.

Ein Managed Vector Service kann diese Betriebsarbeit übernehmen.

Dafür entsteht Anbieterabhängigkeit

Ein verwalteter Dienst ist bequem.

Aber die Anwendung wird stärker abhängig von:

API,

Preismodell,

Verfügbarkeit,

Datenexport,

Regionen.

Darum sollte Portabilität bereits bei der Architektur berücksichtigt werden.

Embeddings selbst sind relativ portabel

Wenn du speicherst:

chunk_id
embedding
metadata

lassen sich diese Daten grundsätzlich in andere Suchsysteme übertragen.

Problematischer können proprietäre:

Indexstrukturen,

Filtersprachen,

Hybrid-Search-Funktionen

sein.

Eine saubere Abstraktionsschicht kann Migration erleichtern.

Vektordatenbanken können teuer werden

Kosten entstehen beispielsweise durch:

Speicher.

RAM.

Requests.

Rechenleistung.

Replikation.

Datentransfer.

Managed Services können zusätzlich nach:

Vektoren,

Speicherkapazität,

Suchoperationen

abrechnen.

Bei großen Datenmengen sollte deshalb vorab überschlagen werden:

Wie viele Vektoren entstehen eigentlich?

Ein Beispiel

Du besitzt:

100.000 Artikel

Jeder wird durchschnittlich in:

10 Chunks

geteilt.

Dann:

1.000.000 Embeddings

Nun wächst die Website auf:

1.000.000 Artikel

Schon sind wir bei:

10.000.000 Embeddings

Chunkingentscheidungen wirken direkt auf die Infrastruktur.

Dazu kommen mehrere Embeddingversionen

Während einer Migration liegen möglicherweise gleichzeitig:

10 Mio. alte Vektoren
+
10 Mio. neue Vektoren

Schon verdoppelt sich der Speicherbedarf.

Solche Übergangsphasen sollten eingeplant werden.

Kleinere Embeddingdimensionen können Speicher sparen

Ein Vektor mit weniger Dimensionen benötigt grundsätzlich weniger Speicher als ein wesentlich größerer.

Ob die Retrievalqualität für die eigene Aufgabe darunter leidet, muss getestet werden.

Wie beim LLM gilt:

größer
≠
automatisch wirtschaftlicher

Quantisierung ist auch bei Vektoren möglich

Vektorwerte können in bestimmten Systemen kompakter dargestellt werden.

Dadurch sinkt:

Speicherbedarf

und möglicherweise:

Suchaufwand.

Der Preis kann eine gewisse Genauigkeitseinbuße sein.

Auch hierbei handelt es sich um einen Trade-off zwischen:

Ressourcen

und:

Retrievalqualität.

Nicht jeder Vektor muss dauerhaft exakt in voller Präzision vorliegen

Große Suchsysteme verwenden unterschiedliche Kompressions- und Quantisierungstechniken.

Für einen kleinen eigenen RAG-Server ist das häufig zunächst unnötig.

Erst messen.

Dann optimieren.

Multitenancy ist ein zentrales Sicherheitsproblem

Angenommen, du betreibst eine RAG-Plattform für hundert Kunden.

Jeder besitzt eigene Dokumente.

Ein Datensatz braucht mindestens eine Zuordnung wie:

tenant_id = 183

Jede Suche dieses Kunden muss zuverlässig auf:

tenant_id = 183

begrenzt werden.

Ein fehlender Filter wäre ein Datenleck

Das Sprachmodell braucht nicht gehackt zu werden.

Es reicht:

Retrieval findet versehentlich einen semantisch passenden Chunk von Kunde 184.

Damit ist das Sicherheitsproblem bereits entstanden.

Die wichtigste Schutzschicht liegt deshalb vor dem LLM.

Separate Indizes können stärkere Isolation bieten

Eine mögliche Architektur:

Kunde A
→ Index A

Kunde B
→ Index B

Das vereinfacht logisch die Trennung.

Dafür entstehen:

mehr Indizes,

mehr Verwaltungsaufwand.

Andere Systeme nutzen:

gemeinsamen Index

plus:

strikte Tenantfilter.

Welche Variante besser ist, hängt vom Risikomodell und der Plattform ab.

Namespaces sind eine weitere mögliche Trennung

Manche Vector Stores bieten logische Namespaces beziehungsweise Collections.

Zum Beispiel:

customer-17
customer-18
customer-19

Auch hier gilt:

Die konkrete Technik ist weniger wichtig als die Garantie, dass eine Query niemals unbeabsichtigt fremde Daten erhält.

Vektordatenbanken enthalten oft sensible Metadaten

Selbst wenn der Vektor kaum menschlich lesbar ist, könnten Metadaten lauten:

employee_name = ...
salary_document = true
department = ...

Der Datenbankzugang sollte deshalb wie jeder andere sensible Datenbankzugang geschützt werden.

Embeddings sollten nicht öffentlich abrufbar sein

Eine API:

GET /all-vectors

ohne Authentifizierung wäre keine gute Idee.

Vektordaten sind Teil der Informationsinfrastruktur.

Sie brauchen:

Authentifizierung,

Autorisierung,

Logging,

Netzwerkschutz.

Vektorsuche kann auch für Prompt Injection missbraucht werden

Ein Angreifer bringt ein Dokument in die Wissensbasis:

Wenn du diese Passage liest, ignoriere alle Systemregeln …

Der Vektorindex findet dieses Dokument später aufgrund semantischer Nähe.

Nun gelangt die bösartige Anweisung in den LLM-Kontext.

Die Vektordatenbank hat korrekt gearbeitet.

Das Sicherheitsproblem liegt im Inhalt.

Ingestion braucht deshalb ebenfalls Vertrauensebenen

Ein RAG-System sollte wissen:

offizielle Dokumentation
→ vertrauenswürdig

interner Nutzerupload
→ eingeschränkt

öffentliche Webseite
→ untrusted

Diese Information kann als Metadatum gespeichert werden.

Das spätere Retrieval beziehungsweise Prompting kann sie berücksichtigen.

Quellenqualität kann sogar Teil des Rankings werden

Zwei Dokumente sind ähnlich.

Dokument A:

offizielle aktuelle Richtlinie.

Dokument B:

alter Forenkommentar.

Dann kann das Ranking berücksichtigen:

semantische Ähnlichkeit
+
Quellenstatus

Der mathematisch ähnlichste Treffer muss nicht der beste Retrievaltreffer sein.

Aktualität kann ebenfalls Metadatum sein

valid_from
valid_until
revision
status

Damit lassen sich alte Dokumente gezielt ausschließen oder niedriger gewichten.

Das verbessert RAG erheblich.

Vektordatenbanken können damit mehr sein als reine Ähnlichkeitsspeicher

In guten Systemen treffen zusammen:

Embedding Similarity

Metadaten

Berechtigung

Aktualität

Quellenqualität

Keywordscore

Die endgültige Retrievalentscheidung kann all diese Signale berücksichtigen.

Der ANN-Index ist nur ein Teil des Suchsystems

Das wird häufig übersehen.

Ein schönes Architekturdiagramm wäre:

                 Query
                   ↓
            Query Embedding
                   ↓
        ┌──────────┴──────────┐
        ↓                     ↓
    Vector Search        Keyword Search
        ↓                     ↓
        └──────────┬──────────┘
                   ↓
             Metadata Filter
                   ↓
               Reranking
                   ↓
                Top-K
                   ↓
                 LLM

Das ist wesentlich näher an einem leistungsfähigen Suchsystem als:

Embedding
↓
Vector DB
↓
fertig

Wie findet man die richtige Vektordatenbank?

Nicht mit:

Welche ist die beste?

Sondern anhand eines Anforderungskatalogs.

Zum Beispiel:

Wie viele Vektoren?

Welche Dimension?

Wie viele Queries pro Sekunde?

Wie häufige Updates?

Welche Metadatenfilter?

Hybrid Search nötig?

Self-hosted oder Managed?

Welche Backupstrategie?

Welche Datenregion?

Welche Kosten?

Dann können Systeme sinnvoll verglichen werden.

Für einen kleinen lokalen RAG-Server ist Einfachheit besonders wertvoll

Wenn:

einige hunderttausend Chunks,

wenige Nutzer,

moderate Suchlast

vorliegen, kann eine vorhandene Datenbanklösung vollständig ausreichen.

Dann ist ein zusätzlicher verteilter Vector-Cluster häufig nur weitere Betriebsarbeit.

PostgreSQL kann deshalb ein hervorragender Startpunkt sein

Besonders wenn du ohnehin brauchst:

Benutzerverwaltung,

Dokumenttabellen,

Berechtigungen,

Metadaten.

Dann liegt es nahe, Embeddings nicht sofort in ein zweites System auszulagern.

Die Architektur bleibt übersichtlich:

PostgreSQL
├── User
├── Dokumente
├── Rechte
├── Metadaten
└── Embeddings

Ab einer gewissen Größenordnung kann Trennung sinnvoll werden

Wenn die Vektorsuche:

den Großteil der Datenbanklast erzeugt,

sehr hohe horizontale Skalierung benötigt

oder:

spezialisierte Suchfunktionen entscheidend werden,

kann ein eigener Vector Store sinnvoll sein.

Dann lautet die Architektur:

PostgreSQL
→ Source of Truth

Vector Database
→ Retrievalindex

Diese Trennung besitzt einen großen Vorteil

Die Vektordatenbank muss nicht mehr die einzige Wahrheit sein.

Sie wird zu einem abgeleiteten Suchindex.

Originalinformationen bleiben im primären Datensystem.

Wenn nötig:

Source of Truth
↓
Vector Index neu aufbauen

Das macht Migration und Disaster Recovery einfacher.

Das ist ähnlich wie ein Suchmaschinenindex

Eine Website besitzt ihre Inhalte im CMS.

Eine Suchmaschine baut daraus einen Index.

Der Index hilft beim Finden.

Das CMS bleibt die primäre Quelle.

Bei RAG:

Dokumentenquelle
↓
Embedding-Index
↓
Retrieval

Dasselbe Prinzip.

Die Vektordatenbank sollte deshalb möglichst keine isolierte Schattenwelt werden

Problematisch wäre:

Niemand weiß mehr, aus welchem Dokument Vektor 81723 stammt.

Kein Revisionsbezug.

Kein Löschprozess.

Kein Source-of-Truth-Link.

Dann wird Wartung schwierig.

Jeder Vektor sollte nachvollziehbare Herkunft besitzen.

Provenienz ist ein wichtiges Metadatum

Zum Beispiel:

chunk_id: 8712

document_id: 191

revision: 4

source_url: ...

embedding_model: ...

created_at: ...

content_hash: ...

Damit ist der komplette Lebenszyklus nachvollziehbar.

RAG-Zitate profitieren direkt davon

Die Vektorsuche findet:

chunk_id 8712

Damit kennt das System:

Dokument.

Überschrift.

URL.

Nun kann das LLM schreiben:

Laut Abschnitt „Backup wiederherstellen“ …

und die Anwendung setzt technisch den korrekten Link.

Das Modell muss die Quelle nicht erfinden.

Das reduziert Halluzinationen bei Quellenangaben

Wie unter KI-Halluzinationen beschrieben, können Sprachmodelle überzeugend aussehende Quellen erfinden.

Wenn die Quelleninformationen aus der Datenbank kommen, muss das Modell nur vorhandene IDs referenzieren.

LLM:
[Q3]

Die Anwendung ersetzt:

[Q3]
→ echte URL

Das ist wesentlich robuster.

Wie funktioniert eine Anfrage in einem vollständigen System?

Nutzer:

Wie kann ich ein WordPress-Backup zurückspielen?

Schritt 1:

Frage
↓
Query-Embedding

Schritt 2:

Vector Search
+
Keyword Search

Schritt 3:

Filter:
language = de
status = published

Schritt 4:

Reranking

Schritt 5:

Top 5 Chunks

Schritt 6:

Frage
+
Chunks
+
Quellenmetadaten
↓
LLM

Schritt 7:

Antwort
+
Quellenlinks

Damit ist die Vektordatenbank nur eine Stufe innerhalb des gesamten RAG-Prozesses.

Vektordatenbanken sind besonders wertvoll bei großen Wissensbeständen

Zum Beispiel:

Unternehmenswiki.

Supportarchiv.

Forschungsdatenbank.

juristische Dokumentensammlung.

Produktkatalog.

große Contentplattform.

Dort wird die Frage:

Welche Inhalte behandeln ungefähr dasselbe Thema?

ständig relevant.

Für zehn Dokumente braucht man möglicherweise überhaupt keine

Ein Ordner enthält:

zehn kurze PDFs.

Man könnte sie vielleicht bei jeder Anfrage komplett in ein großes Kontextfenster geben.

Oder normale Volltextsuche verwenden.

Eine Vektordatenbank wäre technisch möglich.

Aber nicht zwingend sinnvoll.

Ein gutes Architekturprinzip lautet deshalb

Problemgröße
↓
einfachste ausreichende Lösung

Nicht:

neue KI-Technologie
↓
wir müssen sie irgendwo einsetzen

Das schützt vor unnötiger Komplexität.

Vektorsuche kann sogar vollständig in einer Anwendung beginnen

Für einen Prototyp mit wenigen tausend Embeddings kann man Vektoren theoretisch sogar im Arbeitsspeicher halten und direkt vergleichen.

Das ist kein langfristiges Produktionsdesign für große Datenmengen.

Aber hervorragend, um zunächst zu testen:

Funktionieren Embeddings für diese Aufgabe überhaupt?

Erst die Retrievalidee validieren, dann Infrastruktur optimieren

Schritt 1:

100 echte Fragen

Schritt 2:

Embeddings erzeugen

Schritt 3:

exakte Similarity Search

Schritt 4:

Qualität messen

Erst wenn die Treffer gut sind, lohnt sich:

ANN,

verteilte Datenbanken,

Reranking.

Sonst optimiert man sehr schnell ein System, das fachlich das falsche Problem löst.

Die Wahl des Embeddingmodells ist oft wichtiger als die Vector Database

Wenn Modell A die Fachsprache nicht versteht, findet die schnellste Datenbank die falschen Kandidaten nur besonders schnell.

Das Embeddingmodell bestimmt:

welche Beziehungen im Vektorraum überhaupt entstehen.

Die Datenbank optimiert:

wie schnell darin gesucht wird.

Beides sind verschiedene Qualitätsdimensionen.

Chunking ist ebenfalls häufig wichtiger als Datenbankwahl

Schlechter Chunk:

"Dies gilt jedoch nicht in diesem Fall."

Das beste Vector-System der Welt weiß nicht, worauf „dies“ verweist.

Gute Ingestion und gutes Chunking können die Retrievalqualität stärker verändern als der Wechsel zwischen zwei Datenbankprodukten.

Man sollte deshalb die Optimierungsreihenfolge beachten

Dokumentqualität
↓
Chunking
↓
Embeddingmodell
↓
Retrievallogik
↓
Reranking
↓
erst dann Infrastrukturfeintuning

Nicht:

Welche Vektordatenbank ist am schnellsten?

als allererste Frage.

Was du dir über Vektordatenbanken merken solltest

Eine Vektordatenbank beziehungsweise ein Datenbanksystem mit Vektorsuche speichert Embeddings und ermöglicht es, mathematisch ähnliche Vektoren effizient zu finden.

Der Grundprozess lautet:

Dokument
↓
Embedding
↓
Vektordatenbank

Bei einer Suche:

Frage
↓
Query-Embedding
↓
Ähnlichkeitssuche
↓
passende Dokumentvektoren
↓
zugehörige Inhalte

Eine Vektordatenbank speichert dabei typischerweise nicht nur Vektoren.

Sie braucht ebenso:

IDs

Dokumentreferenzen

Metadaten

Versionen

Berechtigungen

Besonders wichtig ist die Kombination:

semantische Ähnlichkeit
+
exakte Filter

Denn:

thematisch passend

bedeutet nicht automatisch:

aktuell
berechtigt
richtige Version
richtiger Kunde

Für kleine Datenbestände kann eine exakte kNN-Suche völlig ausreichen.

Bei großen Mengen werden häufig Approximate-Nearest-Neighbor-Indizes verwendet.

Zum Beispiel:

HNSW

oder Verfahren aus der:

IVF-Familie

Sie tauschen einen Teil mathematischer Exaktheit gegen erheblich schnellere Suche.

Entscheidend ist deshalb nicht nur:

Wie schnell?

sondern auch:

Findet das System zuverlässig
die relevanten Dokumente?

Eine spezialisierte Vektordatenbank ist dabei nicht immer notwendig.

Eine vorhandene relationale Datenbank wie PostgreSQL kann mit einer Vektorerweiterung sehr gut geeignet sein, insbesondere wenn:

relationale Daten,

Metadaten,

Zugriffsrechte

und:

Embeddings

eng zusammengehören.

Eine spezialisierte Vector Database wird zunehmend interessant, wenn:

sehr große Vektormengen

sehr hohe Querylast

verteilte Infrastruktur

horizontale Skalierung

spezialisierte Vector-Search-Funktionen

benötigt werden.

Eine besonders robuste Architektur behandelt die Vektordatenbank nicht zwingend als primäre Wissensquelle.

Sondern als Suchindex:

Originaldaten
→ Source of Truth

Embeddings
→ abgeleitete Repräsentation

Vector Index
→ Retrievalbeschleunigung

Dadurch können:

Dokumente aktualisiert,

Vektoren neu berechnet,

Indizes neu aufgebaut

werden, ohne dass das Wissenssystem seine eigentliche Grundlage verliert.

Und gerade bei RAG sollte man sich eine Sache merken:

Vektordatenbank
→ findet Kandidaten

Reranker
→ priorisiert Kandidaten

Sprachmodell
→ verarbeitet Kandidaten

Die Vektordatenbank muss also nicht perfekt verstehen.

Sie muss den Suchraum so gut verkleinern, dass die wirklich relevanten Informationen zuverlässig im nächsten Verarbeitungsschritt landen.

Genau darin liegt ihre Stärke.