SAKIZLI AI
Article29. Juli 2026 · 17 Min. Lesezeit25 / 40Mitglieder · Abo

Ein RAG-System braucht mehr als eine Vektordatenbank

Eine Vektordatenbank kann ähnliche Passagen finden. Sie weiß nicht, welche Quelle verbindlich ist, welche Version gilt und welcher Treffer die Frage tatsächlich beantwortet.

RAGRetrievalObservabilityEvaluation
FFurkan SakızlıKI-Forscher & Tutor · unabhängig
Eine helle Retrieval-Architektur führt von exakter Suche über Metadaten- und Berechtigungsfilter zu einem kleinen Vektorindex und über Reranking zu einem geordneten Evidenzpaket
Der Vektorindex ist eine Suchkomponente – nicht das gesamte Retrieval-System
Bild mit KI erzeugt

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.

Nur für Mitglieder

Lies den vollständigen Artikel und lade alle Dateien mit einer Mitgliedschaft herunter.

Vollständigen Artikel + Downloads freischalten → Abonnieren

0 Kommentare

Kommentare werden geladen…

Zum Kommentieren anmelden · Mitglied werden →