Ein Vector Store ist kein gewöhnlicher Datenspeicher. Er bewahrt nicht die Daten selbst auf – zumindest nicht primär. Was er speichert, sind Abbilder dieser Daten in einem hochdimensionalen Raum. Diese Abbilder nennen wir Embeddings oder Vektorrepräsentationen. Sie sind der semantische Fingerabdruck des Inhalts.
Stellen wir uns vor, jedes Dokument, jeder Textabschnitt, jedes Bild würde auf einen Punkt in einem mehrdimensionalen Raum projiziert. Dieser Raum hat oft 384, 768 oder gar 1536 Dimensionen – abhängig vom verwendeten Embedding-Modell. In diesem Raum gilt eine einfache, aber mächtige Regel: Ähnliche Inhalte liegen nahe beieinander. Ein Text über Klimawandel und ein Text über Umweltschutz würden als Punkte im Raum dicht beieinander platziert. Ein Text über Kuchenrezepte wäre weit entfernt.
Die eigentliche Information bleibt außen vor.
Das ist der entscheidende Punkt. Der Vector Store kennt die semantische Nachbarschaft, aber nicht zwingend den ursprünglichen Text. Deshalb brauchen wir Metadaten. Sie verknüpfen den abstrakten Vektor mit der konkreten Information: Wo kam der Text her? Welches Dokument? Welche Seite? Welcher Zeitstempel? Die Metadaten sind die Brücke zwischen der geometrischen Ähnlichkeit und der nutzbaren Information.
Wie misst man Ähnlichkeit in diesem hochdimensionalen Raum? Die intuitivste Antwort wäre: Abstand. Zwei Punkte, die nahe beieinander liegen, sind ähnlich. Das führt uns zur euklidischen Distanz – dem geraden Abstand zwischen zwei Punkten, wie wir ihn aus der Geometrie kennen.
Doch in der Praxis hat sich eine andere Metrik als Standard durchgesetzt: die Kosinus-Ähnlichkeit. Warum? Weil sie nicht die absolute Länge der Vektoren betrachtet, sondern nur deren Richtung. Sie misst den Kosinus des Winkels zwischen zwei Vektoren. Bei normierter Vektorlänge (Länge 1) entspricht diese Metrik dem Skalarprodukt der beiden Vektoren.
Ein kleiner Winkel bedeutet: Die Vektoren zeigen in eine ähnliche Richtung. Der Kosinus ist nahe bei 1. Ein großer Winkel bedeutet: Die Richtungen divergieren. Der Kosinus sinkt gegen 0 oder wird sogar negativ. Diese Normierung auf die Richtung macht das Verfahren robust gegenüber Längenschwankungen, die durch unterschiedliche Textlängen oder Formulierungsintensität entstehen können.
Die Wahl der Ähnlichkeitsmetrik ist nicht immer frei. Viele Vector Stores legen sich bei der Initialisierung fest. OpenAI-Embeddings werden beispielsweise typischerweise mit Kosinus-Ähnlichkeit verwendet, während andere Modelle auch die euklidische Distanz oder das Dot Product favorisieren. Die LangChain-Dokumentation verweist auf die jeweiligen Anbieter, um die optimale Metrik für ein gegebenes Embedding-Modell zu ermitteln.
Ein Vector Store besteht aus drei Komponenten. Erstens: die Vektorrepräsentationen selbst. Sie werden beim Hinzufügen von Dokumenten erzeugt, indem ein Embedding-Modell den Inhalt verarbeitet. Zweitens: die Metadaten. Sie transportieren Kontext, Herkunft und Filterkriterien. Drittens: ein Index, der die effiziente Suche ermöglicht.
Dieser Index ist oft komplexer, als man zunächst denkt. Bei kleinen Datenmengen genügt eine einfache lineare Suche: Man vergleicht den Query-Vektor mit allen gespeicherten Vektoren und wählt die besten k Treffer. Doch bei Millionen von Vektoren wird das unpraktikabel. Deshalb nutzen moderne Vector Stores Algorithmen wie HNSW (Hierarchical Navigable Small World). HNSW baut eine graphbasierte Indexstruktur auf, die eine approximative, aber extrem schnelle Suche ermöglicht. Man verliert etwas Präzision, gewinnt aber Geschwindigkeit um Größenordnungen.
Die Metadaten verdienen besondere Aufmerksamkeit. Sie sind nicht nur Beiwerk. In produktiven Systemen sind sie oft der Schlüssel zur Brauchbarkeit. Metadaten erlauben es, die semantische Suche mit strukturierten Kriterien zu kombinieren: “Finde mir ähnliche Dokumente, aber nur aus der Kategorie ‘Vertragsdokumente’ und aus dem Jahr 2024.” Diese Kombination – semantische Ähnlichkeit plus Metadaten-Filter – macht Vector Stores für reale Anwendungen so wertvoll.
Vector Stores kommen in zwei Geschmacksrichtungen: lokal und
gehostet. Ein lokaler Vector Store wie LangChains
InMemoryVectorStore oder ChromaDB läuft direkt in der
Anwendung oder auf einem eigenen Server. Die Daten bleiben unter eigener
Kontrolle. Die Kosten sind fix. Die Skalierung ist
Eigenverantwortung.
Ein gehosteter Vector Store wie Pinecone, Weaviate Cloud oder Qdrant Cloud lagert die Infrastruktur aus. Die Skalierung übernimmt der Anbieter. Die Kosten sind nutzungsabhängig. Die Daten verlassen die eigene Infrastruktur. Die Wahl hängt von Anforderungen an Datenschutz, Skalierbarkeit und Betriebsaufwand ab.
Für Prototypen und Experimente sind lokale Lösungen ideal. Sie starten schnell, haben keine externen Abhängigkeiten und kosten nichts. Für Produktionsanwendungen mit hohem Durchsatz und großen Datenmengen sind gehostete Lösungen oft praktikabler. LangChain abstrahiert diese Unterschiede weitgehend – das Interface bleibt konsistent.
LangChain bietet eine einheitliche Schnittstelle für alle Vector Store-Integrationen. Diese Standardisierung erlaubt es, zwischen verschiedenen Implementierungen zu wechseln, ohne die Anwendungslogik anzupassen. Das Interface konzentriert sich auf drei Kernoperationen: Dokumente hinzufügen, Dokumente löschen, ähnliche Dokumente suchen.
Jeder Vector Store in LangChain wird mit einem Embedding-Modell initialisiert. Dieses Modell ist die Brücke zwischen Text und Vektor. Ohne Embedding-Modell bleibt der Vector Store leer und funktionslos.
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import OpenAIEmbeddings
# Ein Embedding-Modell definieren
embedding_model = OpenAIEmbeddings(model="text-embedding-3-small")
# Den Vector Store mit diesem Modell initialisieren
vector_store = InMemoryVectorStore(embedding=embedding_model)Dokumente werden als Document-Objekte hinzugefügt.
Dieses Objekt ist LangChains universelle Datenstruktur für
unstrukturierte Inhalte. Es hat zwei zentrale Attribute:
page_content für den eigentlichen Text und
metadata für die beschreibenden Zusatzinformationen.
from langchain_core.documents import Document
# Dokumente mit unterschiedlichen Metadaten erstellen
dokument_1 = Document(
page_content="Ich hatte heute Morgen Pfannkuchen mit Schokoladenstückchen und Rührei zum Frühstück.",
metadata={"quelle": "tweet", "datum": "2025-10-19", "kategorie": "persönlich"}
)
dokument_2 = Document(
page_content="Die Wettervorhersage für morgen sagt bewölkten Himmel voraus, mit Höchsttemperaturen um 17 Grad.",
metadata={"quelle": "nachrichten", "datum": "2025-10-19", "kategorie": "wetter"}
)
# Dokumente zum Vector Store hinzufügen
# Best Practice: IDs vergeben, um Duplikate zu vermeiden
vector_store.add_documents(
documents=[dokument_1, dokument_2],
ids=["dok1", "dok2"]
)Die IDs sind wichtig. Ohne IDs würde dasselbe Dokument bei wiederholtem Hinzufügen mehrfach gespeichert. Mit IDs kann LangChain prüfen, ob ein Dokument bereits existiert, und es gegebenenfalls aktualisieren statt duplizieren. Diese Logik reduziert Speicherverbrauch und verhindert redundante Ergebnisse bei Suchanfragen.
Die Suche ist der Moment, in dem der Vector Store seine Stärke ausspielt. Eine Suchanfrage – ein einfacher String – wird durch das gleiche Embedding-Modell geschickt, das auch die Dokumente verarbeitet hat. Das Ergebnis ist ein Query-Vektor. Dieser wird mit allen gespeicherten Vektoren verglichen. Die ähnlichsten Dokumente werden zurückgegeben.
# Eine semantische Suche durchführen
query = "Was gibt es morgen für Wetter?"
ergebnisse = vector_store.similarity_search(query, k=2)
# Die Ergebnisse sind Document-Objekte
for doc in ergebnisse:
print(f"Inhalt: {doc.page_content}")
print(f"Metadaten: {doc.metadata}\n")Der Parameter k steuert die Anzahl der zurückgegebenen
Dokumente. Standardmäßig ist k=4, aber je nach
Anwendungsfall kann man mehr oder weniger Ergebnisse anfordern. Ein
kleines k liefert nur die besten Treffer – präzise, aber
möglicherweise zu eng. Ein großes k bringt mehr Kontext,
aber auch mehr Rauschen.
Die wahre Kraft entfaltet sich, wenn semantische Suche und Metadaten-Filter kombiniert werden. Man sucht nicht nur nach ähnlichem Inhalt, sondern schränkt die Suche auf bestimmte Quellen, Kategorien oder Zeiträume ein.
# Nur in Tweets suchen
ergebnisse_tweets = vector_store.similarity_search(
"Frühstück",
k=2,
filter={"quelle": "tweet"}
)Diese Kombination ist mächtig. Sie erlaubt präzise Kontrolle über den Suchraum, ohne die semantische Flexibilität aufzugeben. In Produktionsanwendungen wird Metadaten-Filterung zur Regel, nicht zur Ausnahme. Man filtert nach Dokumenttyp, Autor, Veröffentlichungsdatum, Zugriffsrechten oder anderen geschäftsrelevanten Kriterien.
Allerdings: Nicht jeder Vector Store unterstützt Metadaten-Filterung gleich gut. Manche bieten komplexe Abfragesprachen, andere nur einfache Gleichheitsprüfungen. Die LangChain-Dokumentation listet auf, welche Integrationen fortgeschrittene Filterung unterstützen. Bei der Wahl eines Vector Stores sollte man dies berücksichtigen.
Dokumente werden nicht nur hinzugefügt und abgefragt. Sie müssen auch gelöscht werden können – sei es, weil sie veraltet sind, rechtlich entfernt werden müssen oder aus anderen Gründen nicht mehr relevant sind.
# Ein Dokument per ID löschen
vector_store.delete(ids=["dok1"])Das Löschen ist unkompliziert, solange man IDs verwendet hat. Ohne
IDs wird es schwierig, gezielt einzelne Dokumente zu entfernen. Das ist
ein weiterer Grund, bei add_documents stets IDs zu
vergeben.
Obwohl wir uns hier auf die Grundlagen konzentrieren, lohnt ein kurzer Blick auf erweiterte Techniken. Hybrid Search kombiniert semantische Vektorsuche mit traditioneller Keyword-Suche. Das Beste aus beiden Welten: Die Präzision von Keywords und die Flexibilität von Embeddings. Maximal Marginal Relevance (MMR) ist ein Re-Ranking-Verfahren, das nach der initialen Suche die Ergebnisse diversifiziert. Es verhindert, dass alle Treffer nahezu identisch sind, und sorgt für inhaltliche Breite.
Diese Techniken bauen auf dem fundamentalen Vector Store-Konzept auf. Sie erweitern es, ohne es zu ersetzen. In späteren Kapiteln – etwa zu Retrieval-Strategien – werden wir darauf zurückkommen.
Ein Vector Store ist die unsichtbare Infrastruktur hinter semantischer Suche. Er transformiert unstrukturierte Daten in durchsuchbare Geometrie. Er macht Sprache zu Mathematik und Bedeutung zu Distanz. Dabei bleibt er pragmatisch: Metadaten erden die Abstraktion. IDs ermöglichen Kontrolle. Das LangChain-Interface abstrahiert die Komplexität.
Was bleibt, ist ein Werkzeug. Ein Werkzeug, das Entwickler:innen in die Lage versetzt, intelligente Suchanwendungen zu bauen, ohne sich in den Details von Vektoralgebra und Indexstrukturen zu verlieren. Das ist der eigentliche Wert von Vector Stores in LangChain: Sie demokratisieren eine Technologie, die vor wenigen Jahren noch Forschungsdomäne war.
Im nächsten Schritt werden wir tiefer in Embeddings eintauchen – wie sie entstehen, welche Modelle es gibt und wie man sie optimiert. Doch das fundamentale Verständnis ist gelegt: Vector Stores speichern keine Texte. Sie speichern deren semantischen Fingerabdruck.