AI Architecture · 10 Min.
Vector Database fuer KI-Agenten: Wie du Kontext so baust, dass Agenten nicht im Datennebel laufen
Eine Vector Database ist kein magischer Wissensspeicher. Sie ist nur so gut wie Chunking, Metadaten, Rechte und Retrieval-Tests.
SYSTEMS Grafik zu Vector Database KI Agenten: Data -> Agent -> Outcome. Fokus: Wie Unternehmen Vector Databases fuer KI-Agenten sinnvoll strukturieren und testen.
Kurzfassung
Eine Vector Database loest kein Kontextproblem automatisch. Entscheidend sind Chunking, Metadaten, Berechtigungen und Retrieval-Evals. Agenten sollten nur den Kontext bekommen, der fuer ihre Aufgabe relevant und erlaubt ist.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum viele RAG-Systeme enttaeuschen Teams laden Dokumente hoch, verbinden eine Suche und erwarten praezise Antworten. Dann kommen halbrichtige Ergebnisse, veraltete Ausschnitte oder Kontext, der fuer den Nutzer gar nicht sichtbar sein duerfte.
Das Problem ist selten die Vector Database allein. Das Problem ist eine fehlende Kontextstrategie.
Stand Mai 2026: Vector Stores werden Kontext-Infrastruktur OpenAI beschreibt Vector Stores als Container fuer semantische Suche, die Dateien automatisch in Chunks zerlegen, einbetten und indexieren. Jede `vector_store.file` kann Attribute tragen, die fuer Filter genutzt werden. Google Vertex AI RAG Engine liefert Retrieval- und Grounding-Metadaten, damit Antworten auf Quellen zurueckgefuehrt werden koennen.
Das ist die zentrale Erkenntnis: Die Vector Database ist nicht "das Gehirn". Sie ist eine Infrastrukturkomponente fuer kontrollierten Kontextabruf. Das Gehirn bleibt die Architektur aus Quellen, Metadaten, Rechten, Retrieval-Parametern, Evals und Betrieb.
OpenAI nennt als aktuellen Default beim Retrieval 800 Tokens pro Chunk mit 400 Tokens Overlap. Das ist kein universelles Optimum, sondern ein Startwert. Gute Teams messen, ob dieser Default fuer ihre Dokumentstruktur funktioniert.
Chunking ist Produktdesign Chunking wirkt technisch, ist aber fachlich entscheidend. Wenn Abschnitte zu gross sind, bekommt der Agent zu viel Rauschen. Wenn sie zu klein sind, fehlt Zusammenhang.
Gutes Chunking folgt der Struktur des Wissens: Prozesse, Entscheidungen, FAQ, Spezifikationen, Richtlinien, Beispiele. Der Agent braucht Antworten, nicht zufaellige Textscheiben.
Eine gute Chunking-Regel beantwortet:
Welche Einheit ist fachlich sinnvoll? Welche Ueberschrift gehoert immer dazu? Welche Tabelle darf nicht auseinanderfallen? Welche Version und Quelle muss am Chunk bleiben? Welche Dokumentteile sind nur Navigation oder Boilerplate? Wie werden alte Chunks geloescht oder ersetzt? Metadaten machen Retrieval steuerbar Metadaten sind der Hebel fuer Praezision: Dokumenttyp, Kunde, Produkt, Version, Freigabestatus, Sprache, Aktualitaet, Rolle. Ohne Metadaten kann das System kaum entscheiden, welche Treffer wirklich passen.
Metadaten sind auch wichtig fuer Rechte. Ein Agent darf nicht alles abrufen, nur weil es technisch im Index liegt.
Pinecone und Weaviate zeigen denselben Grundsatz: Suche wird erst mit Metadatenfiltern und hybriden Verfahren steuerbar. Vector Similarity findet semantische Naehe. Filter bestimmen, ob ein Treffer ueberhaupt zulaessig ist. Hybrid Search kombiniert semantische und Keyword-Signale, wenn reine Vektorsuche zu weich ist.
OpenAI begrenzt Attribute pro Vector-Store-Datei; das zwingt zu Disziplin. Metadaten muessen die wichtigsten Filter tragen, nicht jedes beliebige CRM-Feld. Die Frage ist: Welche Attribute entscheiden ueber Relevanz, Rechte und Aktualitaet?
Rechte sind kein Prompt-Problem Multi-Tenant- und Rollenlogik gehoert nicht in den Prompt. Sie gehoert in Index-Design, Attribute, Filter, Namespaces oder getrennte Stores. Ein Agent darf private Kundendaten nicht deshalb sehen, weil der Prompt sagt: "Bitte nur erlaubte Daten nutzen."
Ein Rechtekonzept braucht:
Pinecone empfiehlt fuer Multi-Tenancy typischerweise Namespaces pro Tenant. Weaviate isoliert Tenants ueber Tenant-Shards, bei denen die Query den Tenant angeben muss. Qdrant empfiehlt haeufig payload-basierte Partitionierung fuer Tenants und Use Cases. Die konkrete Technik unterscheidet sich, aber das Prinzip ist gleich: Mandanten- und Rollenlogik muss in die Retrieval-Schicht.
Google Agent Search zeigt zudem eine harte Planungsregel: Access Control muss bei der Data-Store-Erstellung aktiviert werden und ist nicht einfach nachtraeglich ein Schalter. Berechtigungen gehoeren deshalb in die erste Architekturentscheidung.
Tenant- oder Workspace-Grenze. Rolle und Zweck des Agenten. Dokumentstatus wie draft, approved, archived. Vertraulichkeitsklasse. Ablaufdatum oder Review-Datum. Quellen-Owner. Loesch- und Reindex-Prozess. Retrieval testen RAG braucht eigene Evals. Welche Frage muss welche Quelle finden? Welche veraltete Quelle darf nicht erscheinen? Welche Rollen duerfen welche Antwort sehen?
Diese Tests sind wichtiger als Prompt-Feinschliff. Wenn der falsche Kontext geliefert wird, kann der beste Prompt das Problem nur verdecken.
Ein Retrieval-Eval sollte mindestens messen:
OpenAI Agent Evals und Trace-Grading sind hier nuetzlich, weil nicht nur die Antwort, sondern auch Tool Calls und Retrieval-Entscheidungen bewertet werden koennen.
Auch Loeschungen brauchen Tests. OpenAI weist darauf hin, dass das Entfernen von Dateien aus einem Vector Store eventual consistent ist. In sensiblen Systemen muss man deshalb wissen, wie lange alte Inhalte noch in Suchtreffern auftauchen koennen und welche Sperrmechanismen davor liegen.
Recall: Wird die richtige Quelle gefunden? Precision: Werden falsche Quellen vermieden? Freshness: Werden veraltete Dokumente ausgeschlossen? Permission: Sieht jede Rolle nur erlaubte Treffer? Grounding: Kann die Antwort auf konkrete Quellen verweisen? Cost: Wie viele Chunks landen im Kontext? Kontextbudget und Tool-Strategie Agenten muessen nicht jeden relevanten Chunk sofort im Prompt haben. Oft ist es besser, mit leichten Referenzen, Suchtools und gezielten Nachlade-Schritten zu arbeiten. So bleibt der Kontext klein und der Agent kann bei Bedarf vertiefen.
Die schlechte Architektur lautet: "Pack alles Relevante rein." Die bessere lautet: "Gib dem Agenten ein gutes Suchwerkzeug, klare Filter und ein Budget."
Die fuenf haeufigsten Fehler Eine gemeinsame Datenbank fuer alle Rollen ohne harte Filter. keine Versionierung und kein Reindex-Prozess. Chunks ohne Quelle, Datum oder Owner. reine Vektorsuche ohne Keyword-/Hybrid-Fallback. keine Retrieval-Evals vor dem Go-live. Der SYSTEMS-Blick Wir bauen Vector Databases nicht als Datenablage, sondern als Kontextprodukt. Jede Quelle hat Zweck, Rechte, Aktualitaet und Tests.
Erst dann kann ein Agent mit Unternehmenswissen arbeiten, ohne in Datennebel oder Berechtigungsprobleme zu laufen.
