Was eine Vektordatenbank tatsächlich tut
Nimmt man den Kategorienamen weg, bleibt genau eine Aufgabe übrig: Zu einer Liste von Zahlen die anderen Listen finden, die ungefähr in dieselbe Richtung zeigen. Diese Listen sind Embeddings — ein Textabschnitt, übersetzt in ein paar hundert oder tausend Koordinaten, so angeordnet, dass inhaltlich Verwandtes nah beieinander liegt. Eine Vektordatenbank speichert sie und beantwortet diese Nachbarschaftsfrage schnell.
Das entscheidende Wort ist dabei ungefähr. Jeden Vektor im Bestand mit der Anfrage zu vergleichen, wäre exakt und langsam. Produktive Systeme nutzen stattdessen einen Näherungsindex (Approximate Nearest Neighbour): HNSW baut einen navigierbaren Graphen durch die Vektoren, IVFFlat sortiert sie in Zellen und durchsucht nur die nächstgelegenen. Beide tauschen Korrektheit gegen Tempo — sie antworten in Millisekunden und übersehen dabei stillschweigend einige wirklich gute Treffer. Über einen Parameter stellen Sie ein, wie viel Suchaufwand Sie dafür einkaufen wollen.
Genau diese Eigenschaft wird regelmäßig übersehen. Ihr Suchindex ist verlustbehaftet, und er sagt Ihnen nie, was er verloren hat. Es gibt keine Fehlermeldung, wenn ausgerechnet der Abschnitt mit der Antwort auf Rang 51 landet und die Pipeline die besten 50 nimmt. Das Modell bekommt einen plausiblen Kontext und formuliert daraus eine flüssige Antwort. Vektorsuche fällt nicht laut aus, sie wird leise schlechter.
Die ehrliche Antwort heißt meistens pgvector
pgvector ist eine Erweiterung für PostgreSQL. Sie bekommen eine Vektorspalte, die üblichen Distanzfunktionen und HNSW-Indizes — und zwar in der Datenbank, in der die Zeile zum Textabschnitt sowieso schon liegt, mit Transaktionen, Backups, Rollen und einem Monitoring, das Ihr Team kennt. Für die meisten Bestände ist das kein Kompromiss, sondern schlicht die richtige technische Entscheidung.
Rechnen Sie kurz nach, bevor Sie einkaufen gehen — die Sizing-Seiten der Anbieter sind für eine Größenordnung geschrieben, die nicht Ihre ist. Ein Vektor mit 1024 Dimensionen in float32 belegt rund 4 KB, eine Million Abschnitte also etwa 4 GB reine Vektordaten plus Overhead für den Graphen. Und eine Million Abschnitte sind viel: bei vielleicht zwanzig Abschnitten je Dokument entspricht das rund 50.000 Dokumenten — jedem Angebot, Handbuch, Vertrag und jeder Richtlinie aus zehn Jahren. Das passt in den Arbeitsspeicher eines einzelnen, unspektakulären Servers.
Wenn ein Anbieter von „Skalierung“ spricht, meint er Milliarden Vektoren und tausende Anfragen pro Sekunde — denn nur dieses Problem rechtfertigt ein verteiltes System. Sie haben Millionen Vektoren und ein paar Anfragen pro Minute von Kolleginnen und Kollegen, die nebenbei noch anderes zu tun haben. Nur eines davon ist Ihr Problem. Einen selbst betriebenen Milvus-Cluster für 200.000 Abschnitte würde ich nicht aufsetzen: Sie kaufen sich damit die Ausfallmodi eines verteilten Systems — Sharding, Rebalancing, Knotenbetrieb — für eine Aufgabe, die ein einzelner Postgres-Server nicht einmal bemerkt.
Die Kriterien, die wirklich entscheiden
Drei Dinge stechen diesen Standardfall. Nur eines davon hat mit Größe zu tun — und es ist nicht das, mit dem die Produktseiten werben.
Größe — aber die Zahl, die wirklich weh tut
pgvector wird im Bereich zweistelliger Millionen unangenehm, und der Schmerz zeigt sich beim Aufbau des Index und beim Speicherbedarf während eines Neuaufbaus — lange bevor die Abfragelatenz auffällt. Unter etwa fünf Millionen Abschnitten mit überschaubarer Parallelität hören Sie am besten auf zu vergleichen; Sie optimieren ein Problem, das Sie nicht haben. Bei fünfzig Millionen mit steigender Tendenz — ein großes Dokumentenarchiv, ein Produktkatalog über viele Märkte — verdient ein spezialisierter Speicher sein Geld. Das ist dann eine echte technische Entscheidung und keine Geschmacksfrage.
Filter — hier bricht Vektorsuche leise weg
Dieses Kriterium entscheidet in der Praxis die meisten Auswahlen, und fast niemand bringt es im ersten Termin zur Sprache.
Nehmen Sie einen Regionalversicherer, der einen Assistenten über Bedingungswerke und Schadenrichtlinien bauen will. Keine Anfrage lautet je „durchsuche alles“. Jede Anfrage lautet: „durchsuche die Dokumente, die dieser Nutzer sehen darf, in dieser Sparte, gültig zum heutigen Stichtag“. Die Pipeline braucht also neben der Vektorsuche einen Metadatenfilter — und die Frage, wo dieser Filter greift, entscheidet über Funktionieren oder Nichtfunktionieren.
Holen Sie die besten 50 nach Ähnlichkeit und filtern danach im Anwendungscode, bleibt bei einem Filter, der 2 % des Bestands durchlässt, ungefähr ein brauchbarer Abschnitt von fünfzig übrig. Das Modell antwortet aus dieser einen mittelmäßigen Fundstelle — souverän. Das System sieht aus, als funktioniere es. Auf genau diesem Weg wird aus der Demo, die alle beeindruckt hat, ein Produktivassistent mit dünnen, subtil falschen Antworten.
Die Lösung ist ein Filter, der während der Indexdurchquerung greift, sodass die Suche nur zulässige Vektoren betritt. Spezialisierte Speicher wie Qdrant oder Weaviate behandeln gefilterte Suche als Kernfunktion; Elasticsearch und OpenSearch erledigen es als Erweiterung des Filterns, das sie ohnehin seit jeher beherrschen. pgvector kann das ebenfalls — Sie müssen aber wissen, wie sich der Query-Planer verhält und ob er Ihren Index wählt oder auf einen Scan zurückfällt. Ist das Berechtigungsmodell eine harte Anforderung — und bei einem Versicherer ist es nicht verhandelbar —, dann ist das Filterverhalten das Auswahlkriterium, vor Durchsatz und weit vor dem Markennamen.
Hybride Suche — Ihre Nutzer tippen Teilenummern
Semantische Suche ist bei exakten Zeichenketten ausgesprochen schlecht. „DIN 933“, „4-2291-B“, „§ 34c“ — ein Embedding bildet das auf eine vage Nachbarschaft ähnlich aussehender Zeichenfolgen ab, weil in einer Teilenummer keine Bedeutung steckt, die man einfangen könnte. Ein Zulieferer, dessen Konstrukteure über Teilenummern suchen, wird reine Vektorsuche als Zumutung empfinden — zu Recht.
Die Antwort ist hybride Suche: Stichwortsuche (BM25) und Vektorsuche parallel laufen lassen und die Ranglisten zusammenführen. Das ist ein echtes Argument für Postgres, das Volltextsuche seit Jahren mitbringt — beides in einer Abfrage gegen ein System. Und es ist ein Argument für Elasticsearch oder OpenSearch bei textlastigen Beständen: Eine gereifte Stichwortmaschine, die Vektorsuche ergänzt hat, ist für dieses Problem oft die passendere Bauform als eine Vektormaschine, die Stichwörter nachgerüstet hat. Welche Mischung Sie brauchen, ist eine Frage des Pipeline-Entwurfs — und sie gehört geklärt, bevor jemand etwas unterschreibt.
Der Posten, den niemand einplant: Neuindizierung
Ein Vektorindex ist abgeleitete Datenhaltung. Er ist kein führendes System, und ihn wie eines zu behandeln, ist der Fehler, der aus einer kleinen Entscheidung eine teure macht.
Warum das mehr zählt als jede Benchmark-Tabelle: Vektoren aus einem Embedding-Modell sind im Raum eines anderen Modells bedeutungslos. Es gibt keine Umrechnung, keinen Migrationspfad, keinen Trick — wechseln Sie das Modell, embedden Sie jeden Abschnitt neu. Und Sie werden wechseln: Es erscheint ein besseres oder günstigeres Modell, oder — sehr viel häufiger — Sie ändern Ihre Chunking-Strategie, nachdem Sie gesehen haben, wie sich die Suche auf Ihren echten Dokumenten verhält. Neuindizierung ist kein Sonderfall. Sie ist ein Dienstag.
Warum das selten die spannende Entscheidung ist
Die Qualität der Suche entscheidet sich jedes Mal vor der Datenbank. Was überhaupt eingelesen wurde, wie es geschnitten ist, ob die Metadaten den Import überlebt haben, ob zwischen Suche und Prompt ein Reranker sitzt — daran hängt, ob die richtige Stelle überhaupt auffindbar ist. Die Datenbank führt die Suche nur aus. Sie hat keine Meinung dazu, ob die Antwort enthalten ist.
Ich habe noch kein Projekt scheitern sehen, weil jemand die falsche Vektordatenbank gewählt hat. Ich habe mehrere straucheln sehen, weil die Abschnitte falsch geschnitten waren, weil die Berechtigungen nachträglich angeflanscht wurden oder weil niemand den Index ohne ein verlorenes Wochenende neu aufbauen konnte. Der Vektorspeicher ist zudem eine der besser umkehrbaren Entscheidungen im Stack: Abschnitte, Embeddings und Metadaten sind portabel, ein Wechsel ist eine Sache von Tagen, kein Neubau. Umkehrbare Entscheidungen verdienen angemessene Beratungszeit — also wenig.
Also: Nehmen Sie die langweilige Option, die Filter und hybride Suche beherrscht, die Ihr Team sichern und zurückspielen kann und die Sie jederzeit aus der Quelle neu aufbauen können. Und streiten Sie dann über das Chunking — dort entstehen die Antworten.
Wo Tippel ins Spiel kommt
Die Frage nach der Vektordatenbank löst sich meist auf, sobald jemand Ihren Bestand angesehen hat: wie viele Abschnitte es wirklich sind, wie selektiv die Berechtigungsfilter sein müssen und ob Ihre Leute nach Bedeutung oder nach Teilenummer suchen. Diese drei Fakten wählen den Speicher an einem Nachmittag aus. Unser KI-Readiness-Check ist genau das: ein bezahlter, zeitlich begrenzter Blick auf Ihre echten Dokumente, ein lauffähiger Suchausschnitt und ein ehrliches Urteil darüber, was ein Produktivbau erfordern würde. Wenn Sie zuerst den größeren Rahmen sehen möchten, beschreiben die Leistungen & Pakete, wie wir solche Systeme zuschneiden und bauen — oder schreiben Sie einfach und beschreiben Sie Ihren Bestand.