Vektordatenbank: Ähnlichkeit suchen, Treffer prüfen
Eine Vektordatenbank speichert Vektoren und sucht ähnliche Einträge. Bei Textsuche entstehen diese Vektoren durch ein Embedding-Modell; Text und Metadaten können zusätzlich gespeichert werden. Die Suche verwendet Ähnlichkeits- oder Distanzmaße und kann je nach Index exakt oder näherungsweise arbeiten.
Vektorsuche: So läuft der Abruf ab
Drei Schritte, von denen der erste außerhalb der Datenbank passiert.
Die Anfrage wird mit einem zum Bestand kompatiblen Embedding-Verfahren in einen Vektor übersetzt. Häufig wird dasselbe Modell mit passenden Einstellungen für Anfrage und Dokument verwendet. Die Datenbank sucht dann ähnliche Vektoren, etwa über Kosinus-Ähnlichkeit, Skalarprodukt oder euklidische Distanz. Welche Metrik passt, hängt vom Modell und Index ab.
Was dabei nicht passiert: Es wird nichts verstanden und nichts bewertet. Die Datenbank misst Nähe. Ob der nächstliegende Eintrag die Frage beantwortet, weiß sie nicht.
Exakt oder näherungsweise: Geschwindigkeit und Treffervollständigkeit
Eine exakte Suche vergleicht alle in Frage kommenden Vektoren. Ihr Aufwand wächst mit Bestand, Vektordimension und Anfragelast. Eine Million Einträge ist keine feste Grenze: Hardware, Filter und erlaubte Antwortzeit entscheiden, ob ein Näherungsverfahren sinnvoll ist.
Ein verbreitetes ANN-Verfahren heißt HNSW. Es organisiert Vektoren in einem mehrschichtigen Nachbarschaftsgraphen. Die Suche nähert sich über diese Verbindungen relevanten Bereichen, statt jeden Vektor zu vergleichen. Weitere Ansätze sind beispielsweise IVF-Indizes.
Näherung tauscht einen Teil der Treffervollständigkeit gegen Geschwindigkeit. Wie groß der Verlust ist, hängt von Daten und Indexparametern ab und sollte gegen eine exakte Suche gemessen werden. Vollständige Listen aller Datensätze mit einer Eigenschaft benötigen eine passende Filter- oder Datenbankabfrage; semantische Nähe allein definiert keine vollständige Ergebnismenge.
Metadaten-Filter
Der Teil, der bei der Auswahl am häufigsten übersehen und im Betrieb am dringendsten gebraucht wird. Eine Vektorsuche allein kann nicht sagen: nur aus diesem Mandanten, nur neuer als ein Jahr, nur auf Deutsch, nur öffentlich sichtbar.
Solche Einschränkungen brauchen Metadaten am Eintrag und eine Datenbank, die beim Suchen danach filtern kann. Ob das vor, während oder nach der Ähnlichkeitssuche geschieht, macht dabei einen Unterschied: Wird erst gesucht und dann gefiltert, bleiben von zehn Treffern womöglich zwei übrig.
Mandantentrennung muss serverseitig erzwungen werden. Ein vom Client frei wählbarer oder versehentlich weggelassener Filter reicht als Zugriffsschutz nicht. Abhängig vom System kommen getrennte Indizes, Namespaces oder verbindliche Zugriffskontrollen wie Row-Level Security in Betracht. Die konkrete Sicherheitsgarantie muss auch für alternative Abfragewege geprüft werden.
Brauchst du überhaupt eine?
Nicht jedes Projekt braucht dafür einen eigenständigen Dienst. Entscheidend sind neben der Datenmenge auch gleichzeitige Anfragen, Aktualisierungen, Betrieb und vorhandene Infrastruktur.
Bei kleinen Beständen kann eine exakte Suche im Arbeitsspeicher ausreichen. Ob sie schnell genug ist, zeigt ein Lasttest mit realistischen Vektordimensionen. Auch diese Lösung braucht Aktualisierung, Zugriffsschutz und eine verlässliche Speicherung.
Wer bereits PostgreSQL betreibt, kann Vektorsuche etwa mit pgvector ergänzen. Bestehende Transaktionen, Backups und Berechtigungen lassen sich nutzen; Indexwartung und Last müssen trotzdem geplant werden.
Ein verwalteter Vektordienst kann bei hoher Last, speziellen Funktionen oder wenig eigener Betriebskapazität sinnvoll sein – auch bei kleinen Beständen. Vergleiche Gesamtkosten und Betriebsaufwand statt nur die Anzahl der Vektoren.
Modellwechsel: Kompatibilität prüfen
Embeddings inkompatibler Modelle sollten nicht im selben Suchraum gemischt werden. Gleiche Dimension bedeutet noch keine Vergleichbarkeit. Auch Modellversion, Normalisierung und Einstellungen für Anfrage und Dokument gehören zur Konfiguration.
Beim Wechsel auf ein inkompatibles Modell muss der betroffene Bestand neu eingebettet werden. Unterschiedliche Dimensionen können zu einer ausdrücklichen Fehlermeldung führen; inkompatible Vektoren gleicher Dimension können unauffällig schlechte Treffer liefern. Ein neuer Index mit kontrollierter Umschaltung erleichtert Prüfung und Rückkehr zur vorherigen Version.
Zwei Konsequenzen fürs Datenmodell: Das verwendete Modell samt Version gehört als Metadatum an jeden Eintrag. Und die Neuberechnung des gesamten Bestands sollte ein Skript sein, das jederzeit läuft, kein einmaliger Vorgang, den niemand mehr nachvollziehen kann.
Betriebsfragen
Geänderte Inhalte müssen ihre veralteten Abschnitte ersetzen. Stabile Dokumentkennungen, Inhaltsversionen und eine Zuordnung aller Chunks zu ihrer Quelle helfen dabei. Eine reine Positionsnummer reicht nicht: Verschiebt sich die Aufteilung, müssen auch nicht mehr vorhandene Chunks entfernt werden.
Gelöschte Inhalte müssen tatsächlich verschwinden. Ein Abschnitt zu einer entfernten Seite erzeugt Antworten, die auf nichts mehr verweisen.
Die Kosten verteilen sich auf Embedding, Speicherung, Indexbetrieb, Abfragen und gegebenenfalls Re-Ranking. Welche Position überwiegt, hängt vom Projekt ab. Inhalts-Hashes können unveränderte Abschnitte erkennen und unnötiges erneutes Einbetten vermeiden.