Warum dein RAG die falschen Chunks abruft

Veröffentlicht

28. September 2026

Autor

Faizan Nadeem

Zuerst: Ist das wirklich ein Retrieval-Fehler?

Bevor du eine der vier Ursachen unten diagnostizierst, bestätige, dass der Fehler tatsächlich vor der Generierung liegt. Der schnellste Weg: Nimm die Abfrage, die eine falsche Antwort erzeugt hat, führe das Retrieval isoliert aus und prüfe manuell, ob der Chunk mit der richtigen Antwort irgendwo in den abgerufenen Ergebnissen auftaucht – nicht unbedingt an Rang 1, sondern einfach im Kandidatensatz, der ans LLM übergeben wurde.

Wenn der richtige Chunk vollständig fehlt, liegt ein Retrieval-Fehler vor – eine der vier Ursachen unten. Keine Prompt-Änderung behebt eine Antwort, die nie im Kontextfenster war.
Wenn der richtige Chunk vorhanden ist, die Antwort aber dennoch falsch ist, liegt ein Generierungsfehler vor – das Modell hatte das richtige Material und hat es nicht korrekt verwendet. Das ist ein Treue-Problem, das mit eigenen Metriken in Evaluierung einer RAG-Pipeline behandelt wird.

Selbst nur zehn oder fünfzehn fehlerhafte Antworten manuell zu prüfen, bevor man Annahmen über die Grundursache trifft, spart enorm viel verschwendete Arbeit – es ist häufig zu beobachten, dass die meisten „Das Modell hat halluziniert"-Meldungen eigentlich „Das Modell hat die Antwort nie gesehen" bedeuten.

Embedding-Mismatch

Das Symptom: Das Retrieval gibt Chunks zurück, die thematisch verwandt sind, aber konsistent nie die spezifische Antwort enthalten – bei vielen verschiedenen Abfragen, nicht als gelegentlicher Ausrutscher, sondern als Muster.

Der Mechanismus: Jedes Embedding-Modell hat eine implizite Domäne, für die es gut trainiert ist – Text außerhalb dieser Domäne wird in einen weniger aussagekräftigen Bereich des Vektorraums eingebettet. Ein allgemeines Embedding-Modell, das hauptsächlich auf Webtext und Wikipedia-ähnlicher Prosa trainiert wurde, repräsentiert die dichte Klauselstruktur eines Rechtsvertrags, die API-Oberfläche einer Codebasis oder die abkürzungsreichen Notizen einer Krankenakte merklich schlechter als normale Prosa – nicht weil das Modell defekt ist, sondern weil es nie zuverlässige Strukturen für diese Art von Text gelernt hat.

Wie du es bestätigst: Wähle fünf oder sechs fehlschlagende Abfragen und untersuche direkt die Kosinus-Ähnlichkeit zwischen dem Query-Embedding und dem Gold-Chunk-Embedding gegenüber dem Query-Embedding und einigen unverwandten Chunks. Wenn der Ähnlichkeitswert des Gold-Chunks nicht wesentlich höher ist als der der unverwandten Chunks, trennt der Embedding-Raum selbst relevante von irrelevanten Inhalten für diese Art von Text nicht gut – das ist das Kennzeichen eines Mismatches, kein Chunking- oder Metadaten-Problem.

def diagnose_embedding_gap(query_emb, gold_chunk_emb, sample_chunk_embs) -> dict:
    gold_sim = cosine_sim(query_emb, gold_chunk_emb)
    sample_sims = [cosine_sim(query_emb, e) for e in sample_chunk_embs]
    return {
        "gold_similarity": gold_sim,
        "sample_mean": sum(sample_sims) / len(sample_sims),
        "gap": gold_sim - (sum(sample_sims) / len(sample_sims)),
    }

Ein kleiner oder negativer Gap über viele Abfragen hinweg – nicht nur bei einer – ist das Signal zum Handeln.

Die Lösung: Bei einem wirklich domänenspezifischen Corpus (Recht, Medizin, Code, tiefgreifende technische interne Dokumentation) schließt ein domänenspezifisch angepasstes oder feinabgestimmtes Embedding-Modell diese Lücke in der Regel zuverlässiger als der Wechsel zwischen allgemeinen Modellen. Kurzfristig gibt die Kombination von Vektorsuche mit BM25 dem Exact-Term-Matching einen Weg rund um einen schwachen Embedding-Raum – das ist oft die schnellere Lösung, die man deployen kann, während eine langfristige Embedding-Lösung evaluiert wird.

Chunk-Grenzen teilen die Antwort auf

Das Symptom: Das richtige Dokument wird abgerufen, manchmal sogar der richtige allgemeine Bereich davon – aber die spezifische Tatsache, die nötig ist, um die Frage zu beantworten, fehlt im eigentlichen Chunk, der in die Top-Ergebnisse geschafft hat.

Der Mechanismus: Das ist eine direkte Konsequenz davon, wie der Corpus gechunkt wurde – nicht wie er durchsucht wurde. Ein Chunker mit fester Größe oder naive Aufteilung weiß nicht, dass die Bedeutung einer Tabelle vom einleitenden Absatz abhängt oder dass eine Definition und der Satz, der sie verwendet, zusammengehören – er splittet nach Token-Anzahl. Wenn der Split genau zwischen Setup und Pointe landet, repräsentiert das Embedding für den Chunk mit nur der Pointe das Konzept, nach dem die Abfrage eigentlich fragt, nicht vollständig.

Wie du es bestätigst: Öffne das Quelldokument direkt und schau genau, wo die Chunk-Grenzen relativ zu dem Satz oder der Tabelle fallen, die die Gold-Antwort enthält. Wenn die Antwort auf zwei benachbarte Chunks aufgeteilt ist oder wenn ihr wesentlicher Kontext (eine Variablendefinition, eine Einschränkungsbedingung) im vorherigen Chunk gelandet ist, liegt ein Grenzproblem vor, kein Embedding-Problem.

Die Lösung: Das ist das Hauptthema des Pillar-Posts dieser Serie – siehe Chunking-Strategien für RAG, auf echten Dokumenten benchmarkt für einen vollständigen Vergleich von festen, rekursiven, semantischen und hierarchischen Ansätzen sowie für die spezifischen Mechanismen von Overlap und hierarchischem Parent-Child-Chunking, die beide genau dazu dienen, diesen Fehlermodus zu reduzieren.

Query-Dokument-Asymmetrie

Das Symptom: Fragen, die als Fragen formuliert sind („Wie setze ich ein vergessenes Passwort zurück?"), retrieven schlechter als dasselbe zugrunde liegende Bedürfnis als Aussage formuliert („Passwort-Reset-Prozess"), obwohl ein Mensch beides als gleich valide Wege ansehen würde, dasselbe zu fragen.

Der Mechanismus: Eine Frage und ihre Antwort liegen im Embedding-Raum nicht natürlicherweise nah beieinander, obwohl sie semantisch verknüpft sind – „Wie lange dauert die Verarbeitung meiner Rückerstattung?" und „Rückerstattungen werden innerhalb von 5–7 Werktagen verbucht" teilen kaum gemeinsamen Oberflächenvokabular. Ein Bi-Encoder, der hauptsächlich auf symmetrischer Ähnlichkeit trainiert wurde (zwei ähnliche Aussagen, kein Frage-Antwort-Paar), lernt nicht automatisch, dass eine Frage und ihre Antwort nah beieinander eingebettet sein sollten. Das ist eine strukturelle Eigenschaft der Embedding-Aufgabe, kein Bug in einem bestimmten Modell.

Wie du es bestätigst: Formuliere einige fehlschlagende Abfragen als deklarative Aussagen um, die der wahrscheinlichen Formulierung der Antwort im Quelldokument ähneln, und führe das Retrieval erneut aus. Wenn die deklarative Version den Gold-Chunk zuverlässig abruft und die Frageform nicht, ist das Query-Dokument-Asymmetrie, kein Embedding-Mismatch – der Embedding-Raum ist für Prosa-zu-Prosa-Matching in Ordnung; speziell die Frage-zu-Antwort-Richtung ist schwach.

Die Lösung: Drei Ansätze, grob nach Aufwand geordnet:

Embedding-Modelle, die mit instruktions- oder abfragespezifischen Präfixen trainiert wurden (viele moderne Embedding-Modelle unterstützen separate query:- und passage:-Kodierungsmodi speziell zur Adressierung dieser Asymmetrie) – prüfe, ob dein aktuelles Modell das unterstützt, bevor du davon ausgehst, dass es das nicht tut.
Query-Umformulierung oder -Erweiterung vor dem Retrieval: Lass ein LLM eine Frage in eine plausible deklarative Form umformulieren oder generiere eine hypothetische Antwort auf die Frage (die HyDE-Technik) und embedde stattdessen diese hypothetische Antwort – da eine plausible Antwort viel näher an der echten Antwort liegt als die Frage selbst.

HYDE_PROMPT = "Write a short, plausible passage that would answer this question: {query}"

def hyde_retrieve(query: str, llm_fn, embed_fn, vector_search_fn, k: int = 5):
    hypothetical_answer = llm_fn(HYDE_PROMPT.format(query=query))
    hyde_embedding = embed_fn(hypothetical_answer)
    return vector_search_fn(hyde_embedding, k=k)

Das kostet einen zusätzlichen LLM-Aufruf pro Abfrage, weshalb es sich lohnt, es gegen deinen Eval-Set zu messen statt anzunehmen, dass es immer hilft – bei Corpora, wo Fragen und Antworten bereits Vokabular teilen, kann der Gewinn im Verhältnis zur hinzugefügten Latenz gering sein.

Hybride Suche hilft auch hier, aber auf andere Weise als beim Embedding-Mismatch – wenn die Frage und das Dokument auch nur ein paar exakte Begriffe teilen, kann BM25 den richtigen Chunk finden, auch wenn der Dense-Retrieval-Pfad durch Phrasierungsasymmetrie gestört wird.

Fehlende oder falsche Metadaten

Das Symptom: Das Retrieval gibt Inhalte zurück, die thematisch korrekt sind, aber zur falschen Dokumentversion, dem falschen Produkt-Tier, der falschen Region oder – in einem Multi-Tenant-System – den Daten des falschen Kunden gehören.

Der Mechanismus: Vektorähnlichkeit hat kein inhärentes Konzept von „aktuell", „gilt für diesen Kunden" oder „korrekte Version". Wenn dein Corpus sowohl die aktuelle Preisseite als auch die archivierte Version vom letzten Jahr enthält und beide ohne Metadaten-Feld indexiert wurden, das sie unterscheidet, kann eine Abfrage über Preise jede der beiden ohne Signal zur Bevorzugung der aktuellen Version abrufen – die Embeddings für beide sind legitim ähnlich, weil der Inhalt es tatsächlich ist. Der Fehler liegt nicht in der Ähnlichkeitssuche; es ist, dass eine Information, von der die Abfrage eigentlich abhängt (Aktualität, Geltungsbereich, Tenant), nie als filterbare Metadaten an den Chunk angehängt wurde.

Wie du es bestätigst: Wenn ein falscher, aber plausibler Chunk abgerufen wird, prüfe, ob er sich vom richtigen entlang einer Dimension unterscheidet, die ein Filter hätte sein sollen – eine andere document_version, ein anderes product_tier, eine andere tenant_id – statt wirklich irrelevanter Inhalt zu sein. Wenn der abgerufene Chunk „richtig außer dem Geltungsbereich" ist, liegt ein Metadaten-Problem vor, kein semantisches.

Die Lösung: Hänge die relevanten Geltungsbereich-Felder (Version, Tenant, Region, Zugangs-Tier) bei der Ingestion an jeden Chunk an und wende sie als harten Pre-Filter an, bevor die Ähnlichkeitssuche läuft – nicht als nachträgliche Prüfung der Ergebnisse:

SELECT id, body, embedding <=> :query_embedding AS distance
FROM documents
WHERE tenant_id = :tenant_id
  AND document_version = 'current'
ORDER BY embedding <=> :query_embedding
LIMIT 5;

Das Filtern in der WHERE-Klausel, bevor die Ähnlichkeitssortierung läuft, bedeutet, dass ein archivierter oder nicht geltungsbereichsbezogener Chunk gar kein Kandidat ist – statt darauf zu verlassen, dass das Ähnlichkeits-Ranking ihn weit genug nach unten schiebt, um keine Rolle mehr zu spielen. Das ist oft nicht der Fall, da ein veraltetes Dokument dem aktuellen legitim und wirklich ähnlich sein kann. Das ist noch wichtiger in Systemen, die mehrere Kunden oder Tenants aus einem gemeinsamen Index bedienen – siehe Multi-Tenant RAG: Metadaten-Filterung ohne Datenlecks für die spezifischen Mechanismen von Pre- vs. Post-Filterung und warum die Wahl zwischen beiden echte Korrektkeits- und Performance-Konsequenzen hat.

Eine ausgearbeitete Fallstudie: Eine fehlerhafte Antwort verfolgen

Um die Checkliste konkret zu machen, hier ist ein hypothetischer, aber repräsentativer Trace einer fehlerhaften Antwort durch die Diagnoseschritte.

Der Bericht: Ein Benutzer fragt „Unterstützt der Jahresplan Seat-Downgrades mitten im Zyklus?" und das System antwortet „Nein, die Sitzanzahl kann nach dem Kauf des Jahresplans nicht geändert werden" – was falsch ist; Downgrades sind mit Proratierung zum nächsten Abrechnungszyklus erlaubt.

Schritt 1 – Retrieval oder Generierung? Das Abrufen des rohen Kandidatensatzes für diese Abfrage zeigt, dass die Top-5-Chunks alle über das Upgraden von Seats handeln, aus einem Abschnitt „Plan skalieren". Der Chunk, der tatsächlich Downgrades behandelt – in einem separaten Abschnitt „Abrechnungszyklus-Anpassungen" – erscheint nicht in den Top-10. Das schließt Generierung aus: Das Modell hat nie den richtigen Inhalt gesehen und antwortete daher aus dem Nächstbesten, das es gesehen hat, was zufällig über die entgegengesetzte Operation handelt.

Schritt 2 – Den Ähnlichkeits-Gap prüfen. Das Einbetten der Abfrage gegen den fehlenden Gold-Chunk versus die abgerufenen upgrade-bezogenen Chunks zeigt, dass der Ähnlichkeitswert des Gold-Chunks nur marginal niedriger ist als der der Top-False-Positives – kein großer Gap, was gegen einen schwerwiegenden Embedding-Mismatch spricht.

Schritt 3 – Chunk-Grenzen prüfen. Der Gold-Chunk selbst ist intakt – die Downgrade-Policy ist vollständig in einem Chunk enthalten, nicht aufgeteilt. Das schließt ein Grenzproblem aus.

Schritt 4 – Als deklarative Aussage umformulieren. Die erneute Ausführung des Retrievals mit „Mid-Cycle Seat Downgrade Policy für Jahrespläne" statt der ursprünglichen Frage bringt den richtigen Chunk auf Rang 2. Das ist das Signal: Es war Query-Dokument-Asymmetrie – „Unterstützt X Y?" als Frageformulierung embedded näher an anderen fragenförmigen und upgrade-bezogenen Inhalten als an dem deklarativen Policy-Text, der sie tatsächlich beantwortet.

Die angewandte Lösung: Das Hinzufügen von HyDE-ähnlicher Query-Umformulierung vor dem Retrieval für diesen Corpus (Support- und Abrechnungsdokumentation, die stark zu deklarativen Policy-Aussagen statt Q&A-formatiertem Inhalt tendiert) brachte den Gold-Chunk dieser spezifischen Abfrage von ungerankt auf Rang 1 und verbesserte Recall@5 bei einer Stichprobe ähnlich formulierter Fragen im Eval-Set um eine bedeutende Marge – die Art von gezieltem, gemessenem Fix, den der obige Diagnoseprozess produzieren soll, statt einer pauschalen Prompt-Änderung ohne Wissen, welche der vier Ursachen tatsächlich vorlag.

Wenn sich Ursachen überlagern

Diese vier Ursachen schließen sich nicht gegenseitig aus, und bei einem unordentlichen realen Corpus ist es üblich, dass zwei bei derselben Abfrage überlappen. Eine asymmetrisch formulierte Frage und eine über eine Chunk-Grenze aufgeteilte Antwort erzeugen einen Ähnlichkeits-Gap, der wie ein einfacher Embedding-Mismatch aussieht, bis man Grenzen und Formulierung separat prüft – die unten stehende Checkliste ist genau deshalb in einer Reihenfolge geordnet, die jede Ursache ausschließt und eingrenzt, was übrig bleibt, statt alle vier gleichzeitig aus einem einzigen Symptom zu diagnostizieren.

Eine praktische Gewohnheit: Wenn ein Fix für eine Ursache eine fehlschlagende Abfrage nicht vollständig auflöst, schlussfolgere nicht, dass die Diagnose falsch war – führe die Checkliste gegen den Residual-Fehler erneut durch. Es ist üblich, dass ein Metadaten-Scoping-Fix ein zugrunde liegendes Asymmetrie-Problem enthüllt, das zuvor dadurch verdeckt war, dass irrelevante-Tenant-Ergebnisse die Top-Ränge völlig verdrängt haben.

Eine Diagnose-Checkliste

Wenn die Retrieval-Qualität nachlässt oder eine bestimmte Abfrage immer wieder fehlschlägt, arbeite diese in der Reihenfolge durch – jede schließt eine der oben genannten Ursachen aus oder bestätigt sie, bevor du zur nächsten gehst:

Bestätige, dass es Retrieval ist, nicht Generierung. Prüfe, ob der Gold-Chunk überhaupt im Kandidatensatz war.
Prüfe den Ähnlichkeits-Gap. Ist der Ähnlichkeitswert des Gold-Chunks wesentlich höher als der unverwandter Chunks, oder trennt der Embedding-Raum sie nicht gut?
Untersuche Chunk-Grenzen rund um die Gold-Antwort. Ist die benötigte Tatsache auf Chunks aufgeteilt oder fehlt wesentlicher vorausgehender Kontext?
Formuliere die Abfrage als deklarative Aussage um und teste erneut. Behebt das allein das Problem? Falls ja, ist es Asymmetrie, keine Embedding-Qualität.
Prüfe, ob das falsche Ergebnis sich durch eine Geltungsbereich-Dimension unterscheidet (Version, Tenant, Region) statt durch Thema. Falls ja, ist es ein fehlender Metadaten-Filter.
Erst nachdem alle vier ausgeschlossen wurden, schau dir die Generierung an. Wenn der richtige Chunk vorhanden und angemessen gerankt war und die Antwort noch immer falsch ist, ist das ein Treue-Problem – messe es explizit statt den Prompt nach Gefühl zu tunen.

Fazit

„Das Modell hat halluziniert" ist selten die ganze Geschichte, und direkt zu Prompt-Tuning zu springen überspringt den Diagnoseschritt, der die eigentliche Ursache in Minuten hätte zeigen können. Embedding-Mismatch, aufgeteilte Chunk-Grenzen, Query-Dokument-Asymmetrie und fehlende Metadaten sind vier strukturell verschiedene Probleme, die zufällig dasselbe Symptom erzeugen – eine falsche Antwort – und sie zu vermischen, verschwendet genau die Engineering-Zeit, die eine fünfzehnminütige manuelle Prüfung der abgerufenen Kandidaten eingespart hätte. Arbeite die Checkliste durch, bevor du den Prompt anfasst; es ist fast immer schneller, die eigentliche Ursache zu finden, als sie zu erraten.