Vector Database

Eine Vektordatenbank speichert Embeddings, also numerische Vektoren, die Modelle für Text, Bilder, Audio oder Video erzeugen, zusammen mit einer ID und Metadaten für jedes Element. Außerdem beantwortet sie in Millisekunden über Millionen oder Milliarden von Elementen hinweg die Frage: „Welche gespeicherten Vektoren liegen diesem Vektor am nächsten?“ Sie ergänzt einen Vektorsuch-Index um Datenbankfunktionen: Einfügen, Aktualisieren und Löschen, Filtern nach Metadaten, dauerhafte Speicherung, Zugriffskontrolle und Replikation auf mehreren Rechnern. Vektordatenbanken übernehmen den Abrufschritt bei Retrieval-Augmented Generation (RAG), semantischer Suche und Empfehlungssystemen.

So funktioniert eine Vektordatenbank#

Beim Schreibvorgang wandelt ein Embedding-Modell, das entweder außerhalb der Datenbank läuft oder in sie integriert ist, jedes Element in einen Vektor um. Die Datenbank speichert diesen Vektor zusammen mit einer ID und einer Metadaten-Nutzlast, etwa Quelldatei, Datum, Kamera oder Kunde. Ein Abgleich einer Suchanfrage mit jedem gespeicherten Vektor ist exakt, aber bei großen Datenmengen langsam. Deshalb erstellt die Datenbank einen Index für ungefähre nächste Nachbarn (ANN). HNSW verknüpft jeden Vektor in einem geschichteten Graphen mit seinen Nachbarn. Die Suche durchläuft den Graphen schrittweise auf gierige Weise. Invertierte Dateiindizes (IVF) gruppieren Vektoren mit k-Means-Clustering und durchsuchen nur die Cluster, die der Suchanfrage am nächsten liegen. Methoden zur Vektorquantisierung, etwa Produktquantisierung, komprimieren jeden Vektor auf wenige Bytes. Beim Lesevorgang wird die Suchanfrage mit demselben Modell in ein Embedding umgewandelt und anhand einer Metrik wie Kosinusähnlichkeit, Skalarprodukt oder euklidischer Distanz verglichen. Die Datenbank gibt die IDs, Werte und Nutzdaten der k nächsten Treffer zurück. Viele Systeme führen diese Ergebnisse bei der hybriden Suche mit Keyword-Treffern zusammen.

Dieses Beispiel verwendet Chroma, eine quelloffene Vektordatenbank, die im Arbeitsspeicher eines Python-Prozesses läuft:

import chromadb

# Client im Arbeitsspeicher; chromadb.PersistentClient(path="db") speichert die Daten auf der Festplatte
client = chromadb.Client()
collection = client.create_collection("inspection_notes")

# Chroma erstellt für jedes Dokument mit seinem standardmäßigen Embedding-Modell ein Embedding und indiziert die Vektoren
collection.add(
    ids=["n1", "n2", "n3"],
    documents=[
        "Hairline crack found near the weld on bracket B7",
        "Paint scratch on the left door panel",
        "Porosity in the weld seam of the frame rail",
    ],
    metadatas=[{"line": "A"}, {"line": "B"}, {"line": "B"}],
)

# Suche nach nächsten Nachbarn, beschränkt auf eine Produktionslinie
results = collection.query(query_texts=["welding defects"], n_results=1, where={"line": "B"})
print(results["ids"][0], results["documents"][0])

Die Suchanfrage liefert den Hinweis n3 zurück: die Porosität der Schweißnaht in Linie B. Der Metadatenfilter schließt den Hinweis zum Riss in Linie A aus, obwohl sein Text „welding defects“ genauso ähnlich ist.

Vektordatenbanken im Vergleich zu ähnlichen Systemen#

• Vektorsuchbibliotheken wie FAISS: Indizes innerhalb eines Prozesses, darunter HNSW, IVF und Produktquantisierung, ohne Server, Metadatenspeicherung oder Replikation. Mehrere Vektordatenbanken bauen darauf auf.
• Zweckgebundene Vektordatenbanken: Pinecone als verwalteter Dienst sowie Milvus, Qdrant, Weaviate und Chroma als quelloffene Projekte, die von Anfang an auf Embeddings ausgelegt sind.
• Vektorerweiterungen wie pgvector: Ergänzen PostgreSQL um Vektorspalten mit HNSW- und IVFFlat-Indizes, sodass Embeddings neben relationalen Daten gespeichert werden. Elasticsearch, OpenSearch, MongoDB Atlas und Redis bieten ähnliche Vektorfelder neben ihrer Keyword-Suche.
• Feature Stores: Stellen Eingabemerkmale für Modelle anhand eines Entitätsschlüssels zum Training und für die Inferenz bereit. Sie suchen Datensätze anhand der ID und nicht anhand der Ähnlichkeit.
• Data Lakes: Speichern Rohdateien wie Bilder und Protokolle, auf die eine Vektordatenbank anhand einer ID oder eines Pfads verweist.

Anwendungen in der Praxis#

• Gedächtnis für KI-Agenten: RAG-Pipelines und Agenten speichern Dokumentabschnitte und frühere Gespräche, damit ein großes Sprachmodell sie bei Bedarf abrufen kann.
• Visuelle Suche im Einzelhandel: Bei Funktionen wie „Ähnliche Artikel anzeigen“ werden für jedes Produktfoto Embeddings erstellt und die dem gerade betrachteten Produkt ähnlichsten Artikel zurückgegeben.
• Anomalieerkennung: Eine neue Probe, deren nächste gespeicherte Nachbarn alle weit entfernt sind, wird als ungewöhnlich markiert, etwa eine Transaktion oder ein Sensorwert.

Für Bildsammlungen wird ein Bildverarbeitungsmodell benötigt, um die Vektoren zu erzeugen. Ultralytics YOLO26 bietet dies über model.embed(): Das Modell wird auf jedes Bild angewendet und gibt einen aus der vorletzten Schicht zusammengefassten Merkmalsvektor zurück. Dieser lässt sich neben Bildpfad und Aufnahmemetadaten für die Erkennung nahezu identischer Bilder oder die Suche nach ähnlichen Bildern speichern – wie bei Ähnliche Bilder finden in der Ultralytics Platform.

Dimensionierung und Abstimmung#

Indexeinstellungen bestimmen den Kompromiss zwischen Trefferquote und Inferenzlatenz: Die Suchtiefe von HNSW (ef_search) und die Anzahl der von IVF geprüften Cluster (nprobe) erhöhen beide die Zahl der tatsächlich benachbarten Treffer, verlangsamen jedoch die Suchanfragen. Deshalb stimmen Teams die Einstellungen anhand von Stichproben-Suchanfragen mit einer exakten Suche ab. Der Speicherbedarf bestimmt die Hardwarekosten. Eine Million 768-dimensionale float32-Embeddings benötigen vor jeglichem Index-Overhead 3,07 GB (1.000.000 x 768 x 4 bytes). Eine int8-Skalarquantisierung der Vektoren verringert den Bedarf auf 768 MB, und Matryoshka-Embeddings lassen sich auf weniger Dimensionen kürzen, um ihn weiter zu reduzieren.