RAG: Richtige Daten, falsche Antworten? Wissens-Konflikte in der Enterprise-Retrieval lösen

Zuletzt geprüft: 16. Mai 2026 von Martin Benes.

Eine CFO öffnet den Unternehmens-KI-Assistenten und fragt nach dem Jahresumsatz 2023. Das System ruft zwei Dokumente ab – beide technisch über den Umsatz 2023, beide aus dem firmeneigenen SharePoint. Das eine ist eine vorläufige Ergebnis-Meldung mit 4,2 Mio. $; das andere ist die geprüfte Korrektur auf 3,97 Mio. $. Das Modell wählt eines aus und liefert es selbstbewusst zurück. Die Retrieval war perfekt. Die Antwort ist falsch.

TL;DR: Wenn RAG auf Enterprise-Korpora versagt, ist es meistens kein Retrieval-Miss. Es ist ein Wissens-Konflikt – das richtige Dokument wird zusammen mit einem widersprüchlichen Dokument abgerufen, und das Modell hat keinen prinzipiellen Weg, zwischen beiden zu wählen. Unten: warum das passiert, und vier konkrete Fixes, die kein neues Modell erfordern.

Das Problem: richtige Daten, falsche Antworten

Die meisten RAG-Fehler in Produktion sind nicht das Modell, das aus dem Nichts erfindet. Es ist das Modell, das eine selbstbewusste Synthese über widersprüchlichen, aber plausibel-relevanten Kontext fabriziert. Der Retrieval-Layer macht seinen Job – er zieht die top-k semantisch nächsten Chunks – aber das Korpus selbst enthält überlappende, versionierte, gegenseitig unvereinbare Wahrheit.

In Enterprise-Korpora zeigt sich das in vier Formen:

• Versionierte Wahrheit – eine vorläufige Ergebnis-Meldung und eine geprüfte Korrektur liegen im selben Data Lake. Beide handeln "vom Umsatz 2023". Nur eines ist maßgeblich.
• Zeitliche Staleness – die Preispolitik des Vorjahrs und die des aktuellen Quartals verweisen beide auf "aktuelle Tarife". Ohne Valid-from / Valid-until-Anker beim Retrieval gewinnt das ältere häufig auf lexikalischer Ähnlichkeit.
• Source-Authority-Drift – ein Entwurfs-Memo des einen Teams und eine unterzeichnete Richtlinie des anderen treffen unterschiedliche Aussagen über denselben Workflow. Beide sehen für den Retriever wie vernünftige Unternehmensdokumente aus.
• Mehrdeutige Entity-Referenzen – "der Helsinki-Vertrag" passt auf einen Lieferantenvertrag von 2021 und einen Kundenvertrag von 2024. Andere Entitäten, gleicher String-Match.

Die Forschung hat diese Fehlerklasse unter mehreren Namen untersucht. Kortukov et al. (2024) beschreiben "knowledge conflicts" zwischen dem parametrischen Wissen eines LLM und dem abgerufenen Kontext. Liu et al. (2024) charakterisieren "Lost-in-the-Middle"-Effekte, wenn sich widersprüchliche Passagen den Prompt teilen. Mishra et al. (2024) schlagen eine feinkörnige Halluzinations-Taxonomie vor, in der die durch Retrieval-Konflikt induzierte Konfabulation eine eigene Kategorie ist. Die verbindende Beobachtung: Vektor-Ähnlichkeit ist das falsche Optimierungsziel, wenn das Korpus versionierte Wahrheit enthält.

Warum semantische Ähnlichkeit nicht reicht

Embeddings kodieren thematische Nähe. Sie kodieren nicht, welches Dokument aktuell ist, welches maßgeblich ist, oder welches ersetzt wurde. Wenn also zwei Chunks beim Cosine-Score gleichauf liegen, ist der Tie-Break im Wesentlichen willkürlich – Chunk-Reihenfolge, Position im Prompt, lexikalischer Overlap mit dem Query. Das Modell schreibt dann einen selbstbewussten Satz, der zwischen den beiden abgerufenen Werten mittelt, und die CFO geht mit einer Zahl, die in keinem realen Quelldokument existiert.

Der Fix ist kein größeres Modell und kein längeres Kontextfenster. Sowohl 4o-Klasse- als auch Claude-Sonnet-Klasse-Modelle liefern bei zwei widersprüchlichen Chunks weiterhin in rund der Hälfte der Fälle eine selbstbewusste falsche Antwort, weil der Prompt kein Signal darüber gibt, welchem Chunk zu trauen ist. Der Fix muss in Retrieval und Kontextaufbau liegen, nicht in der Generation.

Vier Fixes, die tatsächlich funktionieren

Fix 1 – Source-Authority-Weighting beim Indexieren

Versehen Sie jedes Dokument beim Ingest mit strukturierten Metadaten: ausgebendes System, Versionsnummer, Valid-from / Valid-until, "signed-off" Boolean, Supersedes-/Superseded-by-Relationen zu anderen Dokumenten. Backen Sie diese Signale in Ihren Ranker – typischerweise als gelernte Re-Weighting über dem Cosine-Score oder als harte Filter beim Retrieval ("nur Chunks mit signed=true und valid_until > now()").

Das ist die einzelne Änderung mit dem höchsten Hebel. In unserer Arbeit mit regulierten Kunden eliminiert allein das Gating auf signed_off=true für Policy-Dokumente rund zwei Drittel der "Richtige-Daten-falsche-Antwort"-Vorfälle – weil die unsignierten Entwürfe, die früher bei der Ähnlichkeit gleichauf lagen, nie in den Prompt geraten.

Fix 2 – Temporale Awareness im Ranker

Für jedes Korpus, in dem dieselbe Tatsache über die Zeit neu formuliert werden kann (Finanzen, Preise, Policies, Kundendaten), nehmen Sie einen Freshness-Term in den Retrieval-Score auf. Übliches Muster: score = α · cosine_similarity + β · recency_decay(doc.timestamp), wobei recency_decay ein exponentielles Half-Life ist, das auf die Dokumentenklasse abgestimmt wird. Ergebnis-Korrekturen haben ein Half-Life von Wochen; Referenz-Architektur-Dokumente von Jahren.

Der Detail, das zählt: "Aktualität" heißt "ab wann das Dokument wahr ist", nicht "wann es hochgeladen wurde". Eine gescannte PDF des Vorjahres-Vertrags, gestern hochgeladen, ist kein frisches Dokument. Der Valid-from-Zeitstempel muss aus dem Dokumenteninhalt (oder dem Quellsystem-Metadatum) kommen, nie aus der Storage-mtime.

Fix 3 – Explizite Widerspruchs-Erkennung vor der Generierung

Zwischen Retrieval und Generierung laufen Sie einen Contradiction-Check über die top-k Chunks. Zwei günstige Optionen:

1. NLI-Cross-Check – ein kleines Natural-Language-Inference-Modell (z. B. ein destilliertes DeBERTa oder ein feinjustiertes 7B-Llama) bewertet jedes Paar abgerufener Chunks auf Entailment / Contradiction / Neutrality. Wenn ein Paar hoch auf Widerspruch scort, branchen Sie.
2. Self-Check mit dem Generator – fragen Sie dasselbe Generierungs-Modell, abgerufene Chunks vor der Antwort gegeneinander zu prüfen ("Treffen einige dieser Passagen unvereinbare Aussagen über dieselbe Entität? Falls ja, listen Sie sie."). Schneller zu verdrahten; verzerrt durch dasselbe Prompt-Following-Verhalten, das Sie eindämmen wollen – verifizieren Sie auf Held-out-Beispielen.

Wenn ein Widerspruch feuert, hat das System prinzipielle Optionen: den Konflikt dem Nutzer offenlegen, den Chunk mit dem stärkeren Metadaten-Signal bevorzugen, oder zu einem strikteren Retrieval-Pass eskalieren. Die falsche Reaktion ist, den Generator stillschweigend wählen zu lassen.

Fix 4 – Citation-aware Prompting und Antwort-Grounding-Constraints

Auch nach sauberem Retrieval zählt der Prompt-Aufbau. Zwei Muster, die Konfabulation über widersprüchlichen Kontext deutlich reduzieren:

• Pro-Chunk-Zitate im Prompt – nummerieren Sie jeden abgerufenen Chunk und weisen Sie das Modell an, die Chunk-Nummer an jede faktische Aussage anzuhängen. Reviewer (menschlich oder automatisch) können dann prüfen, ob der zitierte Chunk die Aussage tatsächlich stützt. Self-RAG (Asai et al., 2023) und Corrective-RAG (Yan et al., 2024) formalisieren das.
• Abstinenz als First-Class-Output – weisen Sie das Modell explizit an, "Ich habe nicht genug maßgebliche Quelldaten für eine Antwort" zurückzugeben, wenn der abgerufene Kontext in Konflikt steht und der Konflikt-Erkennungs-Schritt feuert. Im Unternehmenskontext schlägt "Ich weiß nicht" mit Verweis aufs System-of-Record eine selbstbewusste falsche Zahl jedes Mal.

Was Sie das im Bau kostet

Die unglamouröse Wahrheit: Die meisten Fixes oben sind Data-Engineering-Arbeit, keine ML-Arbeit. Strukturierte Metadaten in die Ingest-Pipeline einbauen, einen metadaten-bewussten Ranker verdrahten, und einen Contradiction-Check-Pass zwischen Retrieval und Generierung schalten – zusammen ein paar Wochen Arbeit für ein kleines Team. Das Modell ändert sich nie. Das Korpus ändert sich nie. Was sich ändert, ist wie das Korpus dem Retriever beschrieben wird und wie der Output des Retrievers dem Generator beschrieben wird.

Das ist auch der Grund, warum der Wechsel zu einem leistungsfähigeren LLM "Richtige-Daten-falsche-Antwort"-Fehler selten behebt. Das Modell hatte nie die Information, die es zur korrekten Wahl gebraucht hätte. Die Information liegt in Metadaten, die Sie noch nicht ausgespielt haben.

Weiterführende Artikel auf dieser Site

• Observability und Tracing für KI-Agenten 2026 – wie Sie den Pfad von Retrieval zu Generierung so instrumentieren, dass Konflikt-Ereignisse in Produktion sichtbar werden.
• Lokale Inference-Engine: Guide für Unternehmen 2026 – Embedder, Vector Store und Generator on-prem betreiben, damit sensible Korpora und Queries souverän bleiben.

Quellen

• Asai et al. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection.
• Kortukov et al. (2024). Studying Large Language Model Behaviors Under Context-Memory Conflicts.
• Liu et al. (2024). Lost in the Middle: How Language Models Use Long Contexts.
• Mishra et al. (2024). Fine-grained Hallucination Detection and Editing for Language Models.
• Yan et al. (2024). Corrective Retrieval-Augmented Generation (CRAG).