Vektordatenbanken erklärt: das Rückgrat moderner KI-Anwendungen

Vektordatenbanken sind das stille Rückgrat moderner KI-Anwendungen. Sie machen semantische Suche und Retrieval-Augmented Generation (RAG) überhaupt erst praxistauglich. Dieser Beitrag erklärt verständlich, wie sie funktionieren, welche Entscheidungen bei der Einführung wirklich zählen – und warum ausgerechnet der Datenschutz die Frage ist, die am häufigsten zu spät gestellt wird.

Warum klassische Suche an Grenzen stößt

Eine herkömmliche Stichwortsuche findet nur, was exakt benannt ist. Sucht jemand nach „Kündigungsfrist“, findet sie keinen Treffer, wenn im Dokument „Vertragsende“ steht. Genau hier scheitern viele Wissensdatenbanken: Das Wissen ist vorhanden, aber nicht auffindbar. Wer schon einmal erlebt hat, wie ein Mitarbeiter zehn Minuten im Intranet sucht und dann doch einen Kollegen fragt, kennt das Problem aus der Praxis.

Wie Vektordatenbanken funktionieren

Statt Texte als reine Zeichenketten zu speichern, werden Inhalte in sogenannte Embeddings umgewandelt – Zahlenvektoren mit typischerweise mehreren hundert bis einigen tausend Dimensionen, die die Bedeutung eines Textes abbilden. Ähnliche Inhalte liegen im Vektorraum nahe beieinander. Eine Suchanfrage wird durch dasselbe Modell geschickt und die Datenbank liefert die Passagen, deren Vektoren am dichtesten daneben liegen.

Zwei Details daran sind für die Praxis wichtig. Erstens wird die Ähnlichkeit über ein Distanzmaß bestimmt, meist Kosinus-Ähnlichkeit – „passt inhaltlich“ ist also eine Rechengröße, keine Bewertung. Zweitens sucht die Datenbank aus Geschwindigkeitsgründen nicht exakt, sondern näherungsweise (Approximate Nearest Neighbor, in der Regel über einen HNSW-Index). Das ist der Grund, warum dieselbe Anfrage bei sehr großen Beständen gelegentlich leicht unterschiedliche Treffer liefern kann. Für die Suche ist das unproblematisch – man sollte es nur wissen, bevor man es für einen Fehler hält.

Welche Lösung? Meist die, die Sie schon haben

Der Markt wirkt unübersichtlich, die Entscheidung ist es selten. Grob gibt es drei Wege:

• Erweiterung einer vorhandenen Datenbank. pgvector macht aus PostgreSQL eine Vektordatenbank. Für die allermeisten mittelständischen Anwendungsfälle reicht das vollständig aus – und es kommt kein zusätzliches System in den Betrieb, das gesichert, überwacht und aktualisiert werden will.
• Spezialisierte Vektordatenbanken wie Qdrant, Milvus oder Weaviate. Sie lohnen sich bei sehr großen Beständen, hohen Abfrageraten oder wenn Filterung und Vektorsuche eng verzahnt sein müssen.
• Suchmaschinen mit Vektorfunktion wie Elasticsearch oder OpenSearch. Interessant, wenn ohnehin eine Volltextsuche im Haus läuft.

Die ehrliche Faustregel: Unterhalb weniger Millionen Textabschnitte ist die Wahl der Datenbank nicht das, was über die Qualität entscheidet. Wer bei fünfzigtausend Dokumenten über Milvus gegen Qdrant diskutiert, optimiert an der falschen Stelle.

Chunking: die unterschätzte Stellschraube

Denn die eigentliche Qualität entsteht davor. Dokumente müssen in Abschnitte zerlegt werden, bevor sie zu Vektoren werden – und wie man schneidet, bestimmt maßgeblich, was später gefunden wird. Zu kleine Abschnitte verlieren den Zusammenhang: Ein Absatz, in dem „die Frist beträgt 14 Tage“ steht, ohne dass darin vorkommt, um welche Frist es geht, ist als Treffer wertlos. Zu große Abschnitte verwässern den Vektor, weil ein Embedding über fünf Seiten irgendwann alles und nichts bedeutet.

Was in der Praxis funktioniert, orientiert sich an der Struktur des Dokuments statt an einer festen Zeichenzahl – Abschnitte entlang von Überschriften, mit etwas Überlappung an den Rändern und mit mitgeführtem Kontext, etwa Dokumenttitel und Kapitel im Abschnitt selbst. Das klingt banal und ist der Unterschied zwischen einem System, das benutzt wird, und einem, das nach drei Wochen wieder brachliegt.

Warum reine Vektorsuche allein nicht reicht

Semantische Suche ist stark bei Bedeutung und schwach bei Zeichenfolgen. Wer nach der Artikelnummer „TR-4471-B“, einem Aktenzeichen oder einem Nachnamen sucht, will einen exakten Treffer – und genau dort ist die Vektorsuche unzuverlässig, weil solche Zeichenketten kaum Bedeutung tragen, die ein Embedding abbilden könnte.

Deshalb kombinieren produktive Systeme beides: Hybride Suche aus klassischer Stichwortsuche und Vektorsuche, deren Ergebnisse zusammengeführt und neu sortiert werden. Wer nur auf Vektoren setzt, baut ein System, das bei Fließtext brilliert und bei Stammdaten versagt. Wo Beziehungen zwischen Objekten wichtiger sind als deren Beschreibung, lohnt zusätzlich der Blick auf Wissensgraphen und GraphRAG.

Was Embeddings über Ihre Dokumente verraten

Hier liegt der Punkt, der in Projekten regelmäßig zu spät auftaucht. Ein Embedding wirkt wie eine harmlose Zahlenreihe – es ist aber eine verdichtete Kodierung des Ausgangstextes. Forschungsarbeiten zur sogenannten Embedding-Inversion zeigen, dass sich aus Vektoren ein erheblicher Teil des ursprünglichen Inhalts rekonstruieren lässt, und dass ausgerechnet die heiklen Bestandteile besonders zuverlässig zurückkommen: Namen, Zahlen, Adressen, Kennungen.

Praktisch heißt das: Wer Embeddings vertraulicher Dokumente an einen externen Dienst gibt, gibt die Dokumente weiter. Ein Vektorindex ist genauso schutzbedürftig wie der Bestand, aus dem er entstanden ist.

Daraus folgen zwei konkrete Anforderungen. Erstens gehört der Vektorbestand unter dasselbe Schutzniveau wie die Quelldokumente – bei personenbezogenen oder geschäftskritischen Inhalten spricht das klar für Betrieb im eigenen Haus oder in einem privaten Deployment. Zweitens braucht es ein Löschkonzept: Wird ein Dokument gelöscht, weil eine Aufbewahrungsfrist abläuft oder jemand sein Recht auf Löschung geltend macht, müssen die zugehörigen Vektoren mitgelöscht werden. Das passiert nicht von selbst, und wer es nicht von Anfang an einplant, hat später eine Datenbank, die Inhalte vorhält, die es offiziell nicht mehr gibt. Wie sich das insgesamt einordnet, beschreiben wir im Beitrag zur Einführung eines RAG-Systems im Mittelstand.

Einsatz in der Praxis: RAG

Bei Retrieval-Augmented Generation sucht die Vektordatenbank zunächst die relevantesten Passagen aus Ihren eigenen Daten. Erst diese werden der KI als Kontext mitgegeben. Das Ergebnis: faktenbasierte Antworten mit Quellenangabe statt erfundener Aussagen.

Die Vektordatenbank ist dabei die Komponente, die über Qualität und Geschwindigkeit entscheidet – allerdings nicht allein. Findet das Retrieval die falschen Passagen, kann auch das beste Sprachmodell keine richtige Antwort daraus bauen. Genau deshalb muss man Retrieval und Antwortqualität getrennt messen; welche Kennzahlen sich dafür eignen, steht im Beitrag zur Evaluierung von RAG-Systemen. Ein Anwendungsbeispiel mit hohen Anforderungen an Belegbarkeit zeigt der Beitrag zu RAG im Rechtswesen.

Wann Sie keine Vektordatenbank brauchen

Nicht jede Suchaufgabe verlangt semantische Suche. Wenn Ihr Bestand klein und gut strukturiert ist, wenn Nutzer ohnehin nach eindeutigen Kennungen suchen, oder wenn eine saubere Volltextsuche mit gepflegten Metadaten das Problem löst – dann ist eine Vektordatenbank zusätzlicher Betriebsaufwand ohne Gegenwert. Der Bedarf entsteht dort, wo Menschen in eigenen Worten fragen und die Antwort in Fließtext steckt, der anders formuliert ist als die Frage.

Fazit

Vektordatenbanken sind kein exotisches Spezialwerkzeug mehr, sondern eine Erweiterung, die in vielen Fällen in der vorhandenen PostgreSQL-Installation Platz findet. Über den Erfolg entscheidet selten das Produkt, sondern die Arbeit drumherum: sinnvoll geschnittene Abschnitte, eine hybride Suche für exakte Treffer, gemessene Qualität – und ein Datenschutzkonzept, das Embeddings so behandelt, wie sie sind, nämlich als Kopie Ihrer Inhalte. Wenn Sie einschätzen wollen, was davon für Ihren Dokumentenbestand nötig ist, sprechen Sie uns an. Wie wir RAG-Systeme aufsetzen, steht auf unserer Seite zu KI-Beratung und RAG-Systemen – DSGVO-konform und auf Wunsch vollständig on-premise.

Weiterführende Quellen

• Morris et al. – Text Embeddings Reveal (Almost) As Much As Text
• pgvector – Vektorsuche für PostgreSQL