rag retrieval semantic-search llm ai-engineering

Wie man leere Ergebnisse bei einem RAG-System behebt, das nichts zurückgibt.

Ein RAG-System, das nichts zurückgibt, Schritt für Schritt debuggt: Eingabe, Schwellenwerte für die Bewertung, Filter, Umformulierung von Abfragen, hybrider Suchvorgang, Neubewertung und Fallback-Möglichkeiten.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 23. Okt. 20269 Min. Lesezeit2016 Wörter

Quellen: **Part II — When RAG Returns Nothing**

Retrieval-augmented Generation stellt einem Sprachmodell externe Kenntnisse zur Verfügung, sodass es nicht ausschließlich auf Basis der Trainingsdaten antworten muss. Das bedeutet, die Endantwort ist nur so gut wie die Informationen, die durch das Abrufen bereitgestellt werden. Wenn eine Suche nichts Nützliches ergibt, verfügt das Modell über kaum oder gar keine Hinweise. Es kann darauf zurückgreifen, eine allgemeine Antwort zu geben, abzulehnen oder Details zu erfinden. Im Folgenden wird erläutert, woher leere oder fast leere Ergebnisse stammen und wie man sie aufspüren kann.

Retrieval kann an vielen Stellen versagen

Ein leeres Ergebnis ist keine einzige Art von Fehler. Ein Kandidat kann während der Aufnahme, des Embeddings, der Vektorsuche, des Metadatenfilters, der Schwellenwertbestimmung oder der Rangliste verschwinden. Das Debuggen geht schneller, wenn man jede Phase einzeln überprüft und den gesamten RAG-Stack nicht mehr als schwarze Box betrachtet.

1. Beginnen Sie mit Indexierung und Embeddings

Bevor Sie den Retriever verwenden, überprüfen Sie, ob die Wissensdatenbank tatsächlich die Informationen enthält, von denen Sie ausgehen. Ein erfolgreicher Verarbeitungsvorgang zeigt einen logischen Ablauf von den Quelldokumenten über den parsierten Text bis hin zu Blöcken, Embeddings und gespeicherten Vektoren. Wenn 2.000 Blöcke erzeugt wurden, aber nur 200 Vektoren im Speicher landeten, wird keine Anpassung des Retrievers helfen.

Öffnen Sie manuell einige gespeicherte Blöcke. Sie sollten lesbaren Text, stabile IDs, Embeddings sowie alle Metadaten enthalten, auf denen Ihre Filter beruhen.
Verwenden Sie für Dokumente und Benutzerabfragen identische Embedding-Modelle und -dimensionen. Wechseln Sie das Abfragemodell ohne Neubau des Index, dann verlieren die Ähnlichkeitswerte ihre Bedeutung.
Bewerten Sie auch den Parser. PDFs, Scans, Tabellen und HTML-Seiten können zu leeren oder fehlerhaften Blöcken werden, obwohl der Vorgang weiterhin als erfolgreich angezeigt wird.

2. Prüfen Sie Schwellenwerte, Bedeutung der Scores und Filter

Aggressive Schwellenwerte für die Bewertung sind eine häufige Ursache für keine Ergebnisse. Die Embedding-Bewertungen sind keine Zuverlässigkeitsprozentsätze, und der nützliche Bereich variiert je nach Modell, Distanzmessmethode, Daten sowie Vektordatenbank. Beim Debuggen sollten Sie die 10 oder 20 besten Kandidaten ohne jegliche Schwellenwerte heranziehen und ihre Rohbewertungen prüfen:

results = vector_store.search(query_embedding, top_k=10)
for r in results:
    print(r.score, r.metadata.get('source'))

Prüfen Sie anschließend, in welche Richtung die Bewertungswerte verlaufen. Einige APIs liefern die Kosinusähnlichkeit, wobei höhere Werte besser sind. Andere liefern die Kosinus- oder Euclidean-Distanz, wobei niedrigere Werte besser sind. Die Verwendung der falschen Vergleichsmethode führt stillschweigend dazu, dass die stärksten Kandidaten ausgeschlossen und die schwächeren behalten werden. Als Regel sollten Sie keine Schwellenbedingungen festlegen, bevor Sie die Bewertungskonvention der Datenbank bestätigt und tatsächliche Wertverteilungen aus repräsentativen Abfragen untersucht haben.

Filter können gute Ergebnisse entfernen

Die Filterung von Metadaten ist für Mehr-Mieter-Systeme, Berechtigungen, Produktbereiche, Datumsangaben, Sprachen und Dokumenttypen von entscheidender Bedeutung – und gehört zugleich zu den einfachsten Ursachen dafür, dass am Ende nur ein leeres Ergebnismenge übrig bleibt. Typische Probleme sind der Vergleich von Zeichenketten mit Zahlen, inkonsistente Großschreibung, ältere Datensätze ohne Metadaten, falsche Mieter-ID-Nummern sowie Filter, die für sich genommen gültig sind, aber gemeinsam nicht anwendbar sind.

3. Überprüfung der Abfragenumformung und der Qualität der Fragmente

Die Umformung einer Abfrage kann bei der Suche helfen, kann aber auch genau den Begriff entfernen, der ursprünglich dazu führte, dass die Abfrage gefunden werden konnte. Stellen Sie sich vor, jemand fragt nach der Wiederherstellung des X500, während das Umformungsprogramm dies in „Standardkonfiguration für die X-Serie wiederherstellen“ umwandelt. Falls das Handbuch „Wiederherstellung des X500“ heißen soll, wird die eigene Formulierung des Benutzers wahrscheinlich besser passen. Protokollieren Sie sowohl die ursprüngliche als auch die umformte Abfrage und testen Sie jede davon. Bei exakten Identifikatoren, Fehlercodes, Produktnamen und API-Parametern behalten Sie die wörtlichen Ausdrücke bei, selbst wenn der Rest der Abfrage normalisiert wird.

Das Chunking versagt auf ähnliche Weise. Ein Überschriftstext wie „X500-Router zurücksetzen“ darf nicht von den darunterstehenden Anweisungen getrennt werden. Teilen Sie den Dokumentinhalt entsprechend der Struktur auf, damit Überschrift, ihre Absätze, Listeinträge sowie der umgebende Kontext zusammenbleiben. Die richtige Größe der Blöcke hängt von der Arbeitslast ab; ein angemessener Ausgangsbereich liegt bei etwa 500 bis 1.000 Tokens mit geringer Überlappung, gefolgt von einer Bewertung anhand echter Abfragen.

Was zu messen ist: Nehmen Sie eine kleine Anzahl von beschrifteten Abfragen und notieren Sie, ob die erwartete Quelle in den Top-k-Ergebnissen erscheint. Dieser auf die Trefferquote ausgerichtete Test ist besser als das Entscheiden über die Blockgrößen oder Schwellenwerte allein aufgrund von Intuition.

4. Kombination aus lexikalischer und vektorbasierter Suche

Die Vektorsuche ist besonders nützlich, wenn Benutzer und Dokumente dieselbe Idee unterschiedlich ausdrücken. Die lexikalische Suche wie BM25 eignet sich hingegen, wenn genaue Token entscheidend sind. Da schwierige Abfragen selten ausschließlich einer bestimmten Art angehören, verwenden Produktionsysteme oft beide Methoden. Bei Dingen wie Fehlercodes (zum Beispiel ERR-XK-1042), SKUs, Rechnungsnummern, Produktnamen, Klassennamen, Konfigurationschlüsseln und API-Parameternamen hat BM25 in der Regel die Nase vorn. Die Vektorsuche liefert zudem konzeptionell ähnliche Ergebnisse in der Nähe, während BM25 sicherstellt, dass genaue lexikalische Hinweise nicht übersehen werden. Ein typisches Design erstellt zunächst eine breite Liste von Kandidaten und wendet anschließend einen stärkeren Neurankierer an, um die Genauigkeit zu erhöhen.

5. Breit suchen, dann neu ranken

Der Erstschritt-Retriever und der Neurangier übernehmen unterschiedliche Aufgaben. Der Retriever sollte die Trefferquote maximieren, indem er alles sammelt, was die Frage beantworten könnte. Der Neurangier sollte die Genauigkeit maximieren, indem er die Abfrage mit diesen Kandidaten vergleicht und die besten Belege an die Spitze bringt.

Ein gängiges Muster besteht darin, 20 bis 50 Kandidaten aus vektorbasierten und lexikalischen Suchen zu sammeln, sie zu verschmelzen und zu duplizieren, um anschließend die besten 5 bis 10 Ergebnisse auszuwählen. Cross-Encoder sind effizient und für die Relevanzbewertung konzipiert, während ein LLM-Neurangier zwar anspruchsvollere Anweisungen befolgen kann, in der Regel aber langsamer und teurer ist.

Vermeiden Sie es, Kandidaten bereits früh auszuschließen. Wenn ein strenger Schwellenwert dem Neurangier vorausgeht, könnte ein Ergebnis, das tatsächlich geholfen hätte, vom leistungsfähigeren Relevanzmodell nie berücksichtigt werden. Oft funktioniert ein erster, lockerer Durchgang gefolgt von einer Neurangierung besser, als die vektorbasierte Bewertung die gesamte Rangliste bestimmen zu lassen.

Fusion und Deduplizierung

Wenn Vektor- und BM25-Ergebnisse kombiniert werden, kann derselbe Datensatz in beiden Listen auftauchen, wodurch sich die Skalen der Bewertungen nicht übereinanderlegen. Verwenden Sie eine Fusionsmethode wie die rekursive Rangfusion, normalisierte gewichtete Scores oder eine einfache Rangzusammenführung, und entfernen Sie Duplikate mithilfe stabiler Datensatz- oder Dokument-ID vor dem Neubewertungsmechanismus. Das Ziel der Konzeption ist es, die erste Stufe auf die Trefferquote auszurichten und den Neubewertungsmechanismus sowie die Logik zur Auswahl des Kontexts für die Genauigkeit zu nutzen, was die Anpassung und Bewertung des gesamten Prozesses erleichtert.

6. Die Abfrage erweitern – mit einem geplanten Ersatzplan

Menschen und Dokumente teilen selten denselben Wortschatz. Jemand, der „Ich kann mich nicht einloggen“ eingibt, benötigt möglicherweise Seiten mit den Titeln „Authentifizierungsfehler“, „Lösen von Einlogproblemen“ oder „Kontozugang“. Die Erweiterung erzeugt einige alternative Suchanfragen, führt sie alle aus, entfernt anschließend Duplikate und ordnet die Ergebnisse neu. Halten Sie dies unter Kontrolle: Lassen Sie benannte Entitäten und exakte Identifikatoren unberührt, erzeugen Sie nicht viele nahezu identische Abfragen und begrenzen Sie die Wiederholungsversuche, damit eine schwierige Frage keinen kostspieligen Kreislauf auslöst.

Lockern Sie nur das, was sicher gelockert werden kann. Sicherheits-, Mieter- und Berechtigungsfilter sind niemals optional und bleiben aktiv. Etwas wie eine optionale Dokumentenkategorie, ein enges Zeitfenster oder sekundäre Tags kann gelockert werden, sofern Ihre Anwendungsregeln es zulassen. Eine einfache Abfolge:

docs = retrieve(query)
if not useful(docs): docs = retrieve(expand(query), hybrid=True)
if not useful(docs): return ask_for_clarification_or_no_answer()

Leeres Ergebnis versus fehlerhafte Suche

Die beiden Fälle erfordern unterschiedliche Lösungsansätze. Wenn nichts zurückkommt, sollten Sie auf Probleme mit der Eingabe, Filtern, Berechtigungen, Schwellenwerten, der Interpretation der Bewertung oder auf einen nicht erreichbaren Index schließen. Wenn Ergebnisse vorliegen, aber nicht zum Thema passen, prüfen Sie die Aufteilung in Abschnitte, die Qualität der Embeddings, Lücken im Wortschatz, eine unzureichende lexikalische Abdeckung oder die Ranking-Logik.

7. Eine widerstandsfähigere Produktionsarchitektur

Ein ausgereiftes RAG-System verwendet nicht für jede Anfrage denselben Suchweg. Es klassifiziert die Anfrage und wählt eine passende Suchstrategie aus: Genaue Identifikatoren nutzen die lexikalische Suche, umfassende konzeptionelle Fragen die Vektor Suche, während unklare oder gemischte Anfragen beides nutzen.

Danach ermöglicht ein Aggregierungs Schritt es, Quellen an einem Ort zusammenzuführen, doppelte Abschnitte zu entfernen, die erforderlichen Metadaten- und Berechtigungsregeln anzuwenden und eine einheitliche Kandidatenliste an den Neubewertungsmechanismus zu senden. Die Zuverlässigkeit sollte nicht allein auf einem Vektorwert beruhen. Bessere Anhaltspunkte sind der Score des Neubewertungsmechanismus, die Streuung der besten Ergebnisse, wie viele Quellen beitragen, ob die für eine Antwort benötigten Entitäten tatsächlich im Kontext erscheinen und ob mehrere Abschnitte übereinstimmen.

Die Zuverlässigkeit bestimmt den nächsten Schritt

Bei ausreichender Zuverlässigkeit wird das am höchsten bewertete Beweismittel an das große Sprachmodell übermittelt. Bei geringer Zuverlässigkeit kann das System die Anfrage erweitern oder umformulieren, es erneut versuchen oder den Benutzer um eine Klärungsfrage bitten. Das ist besser als stets eine Antwort zu geben, denn dem Modell wird klar mitgeteilt, wenn die Beweise zu dürftig sind, um eine fundierte Antwort zu ermöglichen.

Halten Sie die Sicherheit außerhalb des Wiederholungszyklus

Jedes Ersatzdesign muss die Regeln zur Relevanz von den Autorisierungsregeln trennen. Erweiterungen können die Formulierungen lockern, und optionale Thema-Filter können manchmal weggelassen werden, doch Grenzen zwischen Nutzern, ACLs, Berechtigungen auf Zeileebene sowie Datenschutzrichtlinien bleiben bei jeder erneuten Anfrage unverändert. Der Weg der erneuten Anfrage darf niemals zu einer Umgehung der Zugriffskontrolle werden.

8. Die Abfrageverarbeitung sichtbar machen

Wenn nur die endgültige Antwort in den Protokollen gespeichert wird, wird das Debuggen von RAG zur Vermutung. Die Abfrageverarbeitungsschicht sollte genügend Daten liefern, um genau nachvollziehen zu können, was bei jeder Anfrage geschah. Erfassen Sie zumindest: die ursprüngliche Anfrage, überarbeitete oder erweiterte Versionen, Filter, das Embedding-Modell mit seinen Dimensionen, welcher Retriever verwendet wurde, die Top-k-Liste, wie viele Rohkandidaten zurückkamen, ihre Bewertungen, die ausgewählten Abschnitte, die Bewertungen des Rerankers, die Latenzzeit sowie welches Ersatzdesign angewendet wurde.

log({
  'query': query, 'rewritten': rewritten_query, 'filters': filters,
  'candidate_count': len(raw_results), 'scores': scores,
  'selected_chunk_ids': selected_ids, 'fallback': fallback_stage
})

Eine sinnvolle Reihenfolge beim Debuggen

Wenn ein Problem bei der leeren Ergebnisabrufung auftritt, sollte man von den günstigsten und zuverlässigsten Überprüfungen zu den subjektiveren Methoden übergehen. So vermeidet man, dass Teams an Prompten oder Embeddings anpassen, obwohl das eigentliche Problem ein fehlender Index oder ein undurchführbarer Filter ist.

Zuerst die Eingabe überprüfen: Anzahl der Dokumente, analysierter Text, Anzahl der Blöcke, gespeicherte Vektoren sowie einige Datensätze, von denen man weiß, dass sie vorhanden sein sollten.
Dann den Rohabruf testen: Die ursprüngliche Abfrage mit allen optionalen Filtern und Schwellenwerten deaktiviert senden und anschließend die besten Ergebnisse sowie deren Bewertungen auslesen.
Filter nacheinander wieder aktivieren, um den genauen Filter zu ermitteln, der die Ergebnismenge leert.
Die Semantik der Bewertungen überprüfen: Ist eine höhere oder niedrigere Wertung besser, und wird eine Normalisierung angewendet?
Ursprüngliche und umgeschriebene Abfragen unter Beibehaltung der exakten Identifikatoren vergleichen, um herauszufinden, ob eine Umformulierung die Ergebnisqualität verbessert oder verschlechtert.
Bewerten Sie die hybride Suchmethode sowie das Neuranking anhand eines gelabelten Abfragesatzes und überprüfen Sie, ob die erwarteten Quellen nach dem Neuranking in den Top-k- und Top-n-Listen erscheinen.
Testen Sie den Fallback-Modus, indem Sie leere oder schwache Ergebnisse erzwingen, um sicherzustellen, dass das System klar antwortet oder ablehnt und keine Halluzinationen erzeugt.

Was zu messen ist

Allein die Antwortqualität sagt nicht genug über die Suchleistung aus. Verfolgen Sie Recall@k (hat die erwartete Quelle es in die Kandidatenliste geschafft?), die Präzision nach dem Neuranking, den Anteil an leeren Ergebnissen, den Anteil an Fallback-Fällen, die Latenz sowie den Anteil der Abfragen, die Erweiterung oder Klärung benötigten. Aufteilen Sie diese Werte nach Abfruchtypen – wie semantischen Fragen im Vergleich zu exakten Identifikatoren – sowie nach Nutzergruppen, Sprache und Dokumentensammlung, da Gesamtdurchschnitte fehlerhafte Bereiche verbergen können.

Verurteilen Sie zunächst nicht das LLM

Wenn RAG nichts zurückgibt, sollte man vermeiden, das Modell dafür verantwortlich zu machen. Die Ursache liegt in der Regel früher im Suchprozess: unvollständige Einpflege der Daten, inkompatible Embeddings, strenge Schwellenwerte, fehlerhafte Metadatenfilter, falsch interpretierte Bewertungen, aggressive Umformulierung der Abfragen oder eine Suchstrategie, die nicht zur Abfrage passt. Zuverlässige Systeme kombinieren eine solide Indizierung mit hybriden Suchverfahren, der Erstellung einer breiten Liste von Kandidaten, Neubewertung der Ergebnisse, kontrollierter Erweiterung der Abfragen, explizitem Fallback-Verhalten sowie umfassender Telemetrie. Ein nützliches Denkmodell ist, dass RAG in erster Linie ein Such- und Ranking-Problem und erst in zweiter Linie ein Generierungsproblem darstellt. Wenn die Suchschicht zuverlässig relevante, autorisierte Belege liefert und erkennt, wann dies nicht möglich ist, wird das Modell genauer, leichter erklärbar und weniger anfällig für Halluzinationen.