Zum Inhalt springen

// journal / field-notes / rag-failure-modes

Sieben Wege, wie RAG in Produktion stillschweigend versagt

RAG funktioniert im Demo-Code beeindruckend gut und in Produktion oft nicht. Sieben konkrete Versagensmuster, die wir in Audits regelmäßig finden — und wie man sie testet, bevor sie auffallen.

Von createIF Labs
Veröffentlicht am
  • RAG
  • Eval
  • Retrieval
  • Production
Diagramm: Sieben Versagensmuster einer RAG-Pipeline in Produktion
Visualisierung typischer RAG-Fehlermuster in produktiven Pipelines: Zwischen Dokument-Datenbank und LLM bricht die Retrieval-Pipeline unbemerkt — durch falsche Chunk-Grenzen, Embedding-Drift, fehlendes Re-Ranking, Context-Überhang, ignorierte Metadaten und versteckte Halluzinationen. Eine systematische Eval-Suite misst Faithfulness, Relevanz, Robustheit, Aktualität und Abdeckung und macht die Lücken sichtbar, bevor Vertrauen verloren geht.

Retrieval-Augmented Generation ist 2026 die Default-Architektur für domänenspezifische Frage-Antwort-Systeme. Sie hat im Workshop einen sehr guten Tag und in Produktion oft einen sehr schlechten Monat. Hier sind sieben Muster, die wir bei Audits regelmäßig finden — sortiert nach Häufigkeit.

1. Chunk-Grenzen schneiden Bedeutung weg

Klassische 512-Token-Chunks schneiden Tabellen mittendrin, trennen Definitionen von ihren Beispielen, und teilen Listenpunkte. Wir nutzen 2026 standardmäßig:

  • Semantisches Chunking (z. B. mit Embedding-Differenzen als Bruchstellen).
  • Überlappung von 15–25%, nicht 5%.
  • Hierarchisches Chunking — der Chunk weiß, in welchem Abschnitt er liegt.

Test: Gibt es eine Anfrage, deren Antwort über zwei aufeinander folgende Chunks gehört? Wenn ja: Treffer der zweiten Hälfte messen.

2. Embedding-Drift

Embeddings altern. Wenn Sie das Embedding-Modell wechseln und nur neue Dokumente re-embedden, haben Sie zwei Vektorräume in derselben Datenbank. Die Ähnlichkeit zwischen alt und neu ist nicht definiert.

Versteckter Indikator: Sie wechseln das Modell und plötzlich performen alte Dokumente “irgendwie schlechter”.

3. Fehlendes Re-Ranking

Pure Dense-Retrieval gibt Ihnen plausible Treffer, aber selten die besten. Ein Cross-Encoder als Re-Ranker auf den Top-20 verbessert die Trefferqualität in unseren Messungen typischerweise um 18–30%. Wenn Sie kein Re-Ranking haben, kostet das messbar Genauigkeit.

4. Keine Eval-Suite

Wir sehen oft RAG-Systeme in Produktion ohne reproduzierbare Eval. Das bedeutet: niemand weiß, ob das System heute besser oder schlechter funktioniert als letzte Woche. Minimum:

  • 50 hand-gelabelte Q&A-Paare pro Domäne.
  • Reproduzierbarer Eval-Run vor jedem Deploy.
  • Metriken: Hit@K, MRR, Faithfulness, Answer Relevance.

Promptfoo, Inspect-AI oder Ragas — irgendetwas. Hauptsache eingebaut.

5. Context-Überhang

Zu viele Chunks in den Context-Window zu stopfen klingt logisch und macht es schlechter. Models zeigen messbar “lost-in-the-middle” — der relevante Chunk an Position 7 von 12 wird oft ignoriert. Wir liefern selten mehr als 5 Chunks an das Modell.

6. Ignorierte Metadaten

Dokumente haben Strukturen, die in reinem Text verloren gehen: Veröffentlichungsdatum, Version, Status, Autor. Eine RAG-Pipeline, die diese Felder nicht filtert, antwortet aus alten Verträgen, deprecierten Versionen oder Entwürfen. Strukturierte Filter vor dem Vector-Search sind kein Luxus.

7. Versteckte Halluzinationen

Das gefährlichste Muster: das Modell erfindet eine korrekt-klingende Antwort, die sich plausibel auf die abgerufenen Dokumente bezieht — aber den Inhalt verfälscht. Ohne Faithfulness-Eval bemerken Sie es nicht.

Lösung: Validieren Sie systematisch, ob die Antwort vom Quelldokument gestützt wird. Ragas, RAGAS-Faithfulness oder ein eigener Cross-Encoder reichen.


Wenn Sie ein RAG-System in Produktion betreiben und sich bei diesen Punkten unsicher sind: wir machen Audits. Zwei Tage, klares Ergebnis, kein Aufwand für Ihr Team.

// Weiterlesen

Weiterlesen