Ein RAG-System braucht mehr als eine Vektordatenbank

Viele RAG-Projekte beginnen mit einer Produktentscheidung: Dokumente werden eingebettet, Vektoren gespeichert und über Ähnlichkeitssuche abgerufen. Sobald eine Demo einige Fragen brauchbar beantwortet, scheint die Architektur vollständig. Im Betrieb zeigt sich jedoch, dass der Vektorindex nur eine einzelne Suchkomponente ist.

Exakte Produktcodes werden übersehen, veraltete Richtlinien erscheinen vor freigegebenen Fassungen, eine semantisch ähnliche Passage stammt aus der falschen Abteilung und vertrauliche Inhalte gelangen in die Trefferliste, bevor Zugriffsregeln greifen. Eine größere Vektordatenbank löst keines dieser Probleme. Dafür braucht es einen Retrieval-Stack, der Bedeutung, exakte Zeichenfolgen, Metadaten, Berechtigungen und Qualitätskontrolle zusammenführt.

Ein Index beantwortet nur eine begrenzte Frage

Ein Embedding-Modell bildet Anfrage und Dokumentsegmente in einem numerischen Raum ab. Eine Ähnlichkeitsfunktion ordnet Kandidaten nach Nähe. Das ist wertvoll, weil unterschiedlich formulierte Texte thematisch zusammenfinden können. Numerische Nähe ist aber keine fachliche Gültigkeit.

Ohne zusätzliche Felder kennt der Index weder Freigabestatus noch Gültigkeitsdatum, Dokumenteigentümer, Region, Sprache oder Vertraulichkeitsklasse. Er entscheidet auch nicht, ob ein Treffer eine Definition, ein Beispiel, eine Ausnahme oder nur eine beiläufige Erwähnung enthält. Diese Eigenschaften müssen als strukturierte Signale außerhalb des Vektors erhalten bleiben.

Distanzfunktion, Embedding-Version und Normalisierung beeinflussen das Ranking. Nach einem Modellwechsel sind alte und neue Repräsentationen nicht stillschweigend austauschbar. Ein Index-Build braucht deshalb eine versionierte Konfiguration und einen nachvollziehbaren Re-Indexierungsprozess.

Lexikalische Suche bleibt unverzichtbar

Dense Retrieval ist stark bei Paraphrasen und thematischer Nähe. Volltextsuche ist stark bei exakten Begriffen, seltenen Namen, Identifikatoren, Fehlercodes, Artikelnummern und zitierten Formulierungen. Eine Anfrage nach AB-17.4, einer Normbezeichnung oder einer Fehlermeldung darf nicht davon abhängen, ob deren Embedding zufällig einer allgemeinen Beschreibung ähnelt.

Lexikalische Verfahren wie BM25 gewichten Termhäufigkeit, Seltenheit und Dokumentlänge. Sie sind nicht altmodisch, sondern beantworten eine andere Relevanzfrage. Exakte Kennungen können einen lexikalischen Boost oder eine deterministische Lookup-Route auslösen.

Synonymlisten, Sprachvarianten und kontrollierte Schreibweisen ergänzen die Suche. Sie müssen fachlich gepflegt werden, denn automatische Erweiterung kann eine Anfrage verwässern. „Bank" bezeichnet je nach Kontext ein Finanzinstitut, eine Sitzgelegenheit oder ein technisches Bauteil.

Hybrid Retrieval verbindet unterschiedliche Signale

Hybrid Retrieval führt lexikalische und semantische Kandidaten zusammen. Deren Scores folgen unterschiedlichen Skalen und sollten nicht blind addiert werden. Reciprocal Rank Fusion kombiniert Rangpositionen mehrerer Ergebnislisten, ohne vergleichbare Scores vorauszusetzen. Andere Systeme verwenden trainierte oder manuell gewichtete Fusion.

Fusion ist kein Qualitätsgarant. Sie muss mit realen Fragen evaluiert werden. Ein Korpus mit Produktcodes braucht vielleicht stärkere lexikalische Gewichtung; ein Beratungsarchiv mit variabler Sprache profitiert stärker von semantischer Suche. Häufig sind Query-Klassen sinnvoller als eine globale Gewichtung.

Der Kandidatenpool sollte breiter sein als das finale Kontextpaket. Retrieval optimiert zunächst Recall: Die relevante Passage soll enthalten sein. Danach verbessert Reranking Präzision und Reihenfolge.

Metadaten sind Teil der Suchlogik

Metadatenfilter sind keine Dekoration für die Quellenanzeige. Sie begrenzen den gültigen Suchraum. Typische Felder sind Dokumenttyp, Status, Version, Gültigkeitszeitraum, Organisationseinheit, Produkt, Region, Sprache, Datenklasse und Owner.

Filter können vor oder nach der Vektorsuche angewandt werden. Diese Reihenfolge verändert Recall und Laufzeit. Bei Approximate-Nearest-Neighbour-Indizes werden Filter je nach Implementierung nach einem begrenzten Indexscan ausgewertet. Die pgvector-Dokumentation weist darauf hin, dass dadurch zu wenige Ergebnisse übrig bleiben können, und beschreibt iterative Scans, Partial Indexes und Partitionierung als mögliche Strategien.

top_k=10 bedeutet daher nicht automatisch zehn zulässige Treffer. Entfernen Status- oder Berechtigungsfilter neun Kandidaten, muss der Retriever kontrolliert weiter suchen. Sonst entsteht ein leeres oder fachlich schwaches Kontextpaket.

Berechtigungen müssen vor der Antwort greifen

Zugriffskontrolle darf nicht nur in der Benutzeroberfläche stattfinden. Ein nicht berechtigter Chunk sollte weder in Kandidatenpool noch Logs, Caches oder Kontextfenster gelangen. Die Retrieval-Schicht benötigt Identität und Rolle der anfragenden Person sowie dokument- oder segmentbezogene Regeln.

Dokumentberechtigungen gehen verloren, wenn Chunks ohne Herkunft gespeichert werden. Jede Einheit braucht deshalb eine stabile Verbindung zum Quellobjekt und dessen Access-Control-Informationen. Änderungen an Gruppen oder Freigaben müssen zuverlässig in den Suchbestand propagiert werden.

Das Prinzip lautet „security trimming before generation". Ein Modell kann eine vertrauliche Passage nicht wieder vergessen, nachdem sie ihm als Kontext übergeben wurde.

Query Processing bestimmt, wonach gesucht wird

Nutzerfragen sind oft kurz, mehrdeutig oder gesprächsabhängig. Query Processing kann Rechtschreibung normalisieren, Abkürzungen auflösen, Sprache erkennen, Zeitbezüge konkretisieren oder eine Folgefrage mit Gesprächskontext in eine eigenständige Suchanfrage umformen.

Diese Transformation ist nützlich, aber riskant. Sie darf keine fachliche Annahme still hinzufügen. Originalanfrage und transformierte Varianten sollten protokolliert werden; kritische Mehrdeutigkeit verlangt eine Rückfrage.

Query Routing wählt gegebenenfalls eine andere Quelle: Volltextindex, strukturierte Datenbank, Wissensgraph, API oder Dokumentarchiv. Eine Frage nach einem aktuellen Kontostand gehört nicht in einen statischen Vektorindex, wenn ein autoritatives Transaktionssystem existiert.

Reranking beurteilt Kandidaten im Anfragekontext

Ein Bi-Encoder verdichtet Anfrage und Passage getrennt und ermöglicht schnelle Suche. Diese Verdichtung kann feine Beziehungen verlieren. Reranker bewerten eine kleinere Kandidatenmenge genauer, häufig indem sie Anfrage und Passage gemeinsam betrachten.

Cross-Encoder sind präzise, aber rechenintensiver. Late-Interaction-Ansätze wie ColBERT behalten Repräsentationen auf Tokenebene und verschieben einen Teil der Interaktion in die Suchphase. Die geeignete Methode hängt von Latenz, Korpusgröße und Qualitätsziel ab.

Reranking darf fachliche Regeln nicht ersetzen. Eine veraltete Quelle wird nicht verbindlich, nur weil ein Modell sie hoch bewertet. Zuerst gelten harte Filter; danach ordnen Relevanzmodelle die zulässigen Kandidaten.

Kontextaufbau ist mehr als Top-k

Die ersten fünf Treffer unverändert an die Generation zu senden ist selten optimal. Treffer können sich wiederholen, denselben Parent haben, widersprüchliche Versionen enthalten oder notwendige Nachbarpassagen vermissen. Context Assembly dedupliziert, erweitert Beziehungen, wahrt Quellenvielfalt und ordnet Inhalte innerhalb eines Budgets.

Ein gutes Paket enthält nicht möglichst viel Text, sondern die kleinste hinreichende Evidenz. Dazu gehören gegebenenfalls Definition, Regel, Ausnahme und Gültigkeitsangabe. Quellen-IDs und Positionen bleiben erhalten, damit Aussagen später belastbar gebunden werden können.

Bei Widersprüchen sollte das System nicht heimlich eine Passage wählen. Es kann beide Versionen zeigen, ihre Gültigkeit vergleichen oder an eine verantwortliche Rolle eskalieren. Retrieval ist auch Konflikterkennung.

Betrieb braucht kontrollierte Indexgenerationen

Produktionssysteme besitzen mehrere Zustände: Quelldokumente, Parse-Ergebnisse, Chunks, Embeddings, Indizes, Caches und Replikate. Wird ein Dokument zurückgezogen, muss klar sein, wann es aus jeder Stufe verschwindet. Sonst beantwortet ein aktueller Dienst eine Frage aus einem alten Cache.

Eine Indexgeneration verbindet Korpus-Snapshot, Parser-Version, Chunking-Regeln, Embedding-Modell, Metadataschema und Build-Zeitpunkt. Deployments wechseln kontrolliert zwischen Generationen. Rollback und Löschanforderungen werden getestet, nicht nur beschrieben.

Observability erfasst Query, Route, Filter, Kandidaten, Scores, Reranking, ausgewählten Kontext und Latenz – unter Beachtung von Datenschutz und Datenminimierung. Ohne diese Spuren ist nicht erkennbar, ob ein Fehler aus Suche, Filterung oder Generation stammt.

Evaluation braucht mehr als eine Antwortbewertung

Ein flüssiger Text kann auf schlechtem Retrieval beruhen. Deshalb werden Stufen getrennt gemessen. Recall@k prüft, ob relevante Evidenz im Kandidatenpool liegt. Precision@k bewertet den Anteil relevanter Treffer. MRR oder nDCG berücksichtigen Position und abgestufte Relevanz.

Zusätzlich braucht es Berechtigungs-, Filter- und Freshness-Tests, Latenzbudgets und Kostenmessung. Ein Golden Query Set enthält exakte Kennungen, Paraphrasen, mehrdeutige Fragen, Versionskonflikte, leere Ergebnisse und nicht berechtigte Inhalte.

Ablation Tests schalten Komponenten ab: nur Vektor, nur lexikalisch, hybrid ohne und hybrid mit Reranker. Erst der Vergleich zeigt, ob zusätzliche Komplexität messbaren Nutzen bringt. Architektur soll nicht maximal, sondern begründet sein.

Methode: ROUTE → FILTER → RETRIEVE → FUSE → RERANK → ASSEMBLE → VERIFY

ROUTE wählt die geeignete Quelle. FILTER begrenzt auf zulässige und gültige Inhalte. RETRIEVE erzeugt lexikalische und semantische Kandidaten. FUSE verbindet Ergebnislisten. RERANK ordnet genauer. ASSEMBLE baut ein vollständiges Evidenzpaket. VERIFY testet Relevanz, Quellenbindung, Berechtigung und Aktualität.

Die Vektordatenbank bleibt wichtig. Sie wird nur dann überschätzt, wenn sie mit dem gesamten Retrieval-System verwechselt wird.

Übung: Entwirf einen Retrieval Stack Canvas

1. Wähle zehn reale Fragen mit Kennungen, Paraphrasen und Versionsbezügen.

2. Bestimme pro Frage autoritative Quelle und Query-Route.

3. Definiere harte Metadaten- und Berechtigungsfilter.

4. Lege lexikalische und semantische Kandidatenmengen fest.

5. Beschreibe Fusion, Reranking und Context Assembly.

6. Definiere Recall-, Ranking-, Freshness- und Security-Tests.

7. Vergleiche den Stack gegen reine Vektorsuche.

Reflexion: Welche Frage braucht exakte Suche statt semantischer Ähnlichkeit? Welcher Treffer wäre relevant, aber wegen Status oder Berechtigung unzulässig?

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Die geeignete Architektur hängt von Korpus, Anfragearten, Berechtigungsmodell, Qualitätsziel und Betrieb ab. Kein einzelnes Verfahren garantiert fachliche Richtigkeit. Redaktionell geprüft am 17. Juli 2026.