Sie haben ein RAG-System geliefert. Es funktioniert... meistens. Manchmal sind die Antworten beeindruckend gut. Manchmal wird selbstbewusst etwas behauptet, das völlig falsch ist, und ein Dokument zitiert, das nicht das sagt, was das Modell behauptet. Und manchmal fehlt die Antwort völlig, obwohl sich das richtige Dokument genau dort in Ihrer Wissensdatenbank befindet.
Dies ist der normale Zustand eines RAG-Produktionssystems. Die Frage ist nicht, ob Sie Qualitätsprobleme haben – das tun Sie –, sondern ob Sie eine systematische Möglichkeit haben, diese zu finden und zu beheben. Dafür sind RAG-Retrospektiven da: Regelmäßig prüfen, wo Ihre Pipeline ausfällt, und gezielte Verbesserungen vornehmen, statt zu raten.
Warum RAG-Systeme ihre eigenen Retrospektiven brauchen
RAG ist kein einheitliches System. Es handelt sich um eine Kette von Komponenten, und die Qualität jedes Glieds bestimmt das Endergebnis. Wenn die Antwort schlecht ist, könnte der Fehler an einer beliebigen Stelle liegen:
- Ingestion: Dokumente wurden falsch analysiert, Teile wurden an fehlerhaften Stellen aufgeteilt, Metadaten gingen verloren
- Abruf: Die Suchabfrage stimmte nicht mit den richtigen Dokumenten überein, das Einbettungsmodell hat die semantische Verbindung verpasst, Ihr Top-K war zu klein oder zu groß
- Kontextassembly: Abgerufene Chunks waren einzeln relevant, widersprachen sich jedoch, oder das Kontextfenster war mit Rauschen gefüllt
- Generation: Das Modell halluzinierte trotz gutem Kontext oder ignorierte den relevanten Kontext zugunsten seines parametrischen Wissens
Standard-Software-Retrospektiven sind nicht in der Lage, diese Fehlermodi zu entschlüsseln. Sie benötigen ein Format, das fehlerhafte Ausgaben über die Pipeline zurückverfolgt, um die tatsächliche Fehlerquelle zu finden. Andernfalls „reparieren“ Sie am Ende den Abruf, wenn das eigentliche Problem das Chunking war, oder schreiben Prompts neu, wenn das eigentliche Problem der Abruf war.
Kennzahlen, die es wert sind, verfolgt zu werden
Bevor Sie eine RAG-Retrospektive durchführen, benötigen Sie Daten. Nicht alle möglichen Metriken – gerade genug, um die häufigsten Fehlermodi zu diagnostizieren.
Abrufqualität
Precision@K: Wie viele der K-Dokumente waren tatsächlich relevant? Wenn Sie 10 Blöcke zurückziehen und nur 2 nützlich sind, überfluten Sie das Kontextfenster mit Rauschen.
Recall@K: Wie viele aller relevanten Dokumente in Ihrer Wissensdatenbank landeten in Ihren Top-K-Ergebnissen? Eine geringe Erinnerung bedeutet, dass die richtigen Antworten vorhanden sind, Ihr Abruf sie jedoch nicht finden kann.
MRR (mittlerer reziproker Rang): Wo erscheint das erste relevante Ergebnis in Ihrem Ranking? Wenn sich das beste Dokument durchweg auf Position 5 statt auf Position 1 befindet, muss Ihr Ranking verbessert werden, auch wenn die Erinnerung in Ordnung ist.
Sie müssen diese nicht für Ihre gesamte Wissensdatenbank berechnen. Probieren Sie 50–100 aktuelle Abfragen aus, lassen Sie einen menschlichen Richter beurteilen, welche abgerufenen Dokumente relevant waren, und berechnen Sie daraus. Tun Sie dies monatlich.
Generationsqualität
Treue: Spiegelt die generierte Antwort tatsächlich das wider, was in den abgerufenen Dokumenten steht? Das ist die Halluzinationsfrage. Sie können dies stichprobenartig überprüfen, indem Sie die Ausgaben mit dem bereitgestellten Kontext vergleichen.
Antwortrelevanz: Beantwortet die Antwort tatsächlich die gestellte Frage? Es ist möglich, eine vollkommen getreue Zusammenfassung der abgerufenen Dokumente zu erstellen, die die Absicht des Benutzers völlig verfehlt.
Kontextnutzung: Wenn sich die richtigen Informationen im abgerufenen Kontext befinden, nutzt das Modell sie dann tatsächlich? Wenn Sie regelmäßig gute Dokumente abrufen und das Modell sie ignoriert, handelt es sich um ein generationsseitiges Problem (normalerweise ein Eingabeaufforderungsproblem).
Betriebsmetriken
Latenz: Wie lange dauert die gesamte Pipeline von der Anfrage bis zur Antwort? Teilen Sie dies nach Komponenten auf, damit Sie wissen, ob der Abruf oder die Generierung den Engpass darstellt.
Kosten pro Abfrage: Verfolgen Sie die Token-Nutzung und API-Kosten. Einige Qualitätsverbesserungen (z. B. die Erweiterung des Kontextfensters oder die Neubewertung) erhöhen die Kosten erheblich.
Durchführung der Retrospektive
Vorbereitung (vor dem Treffen)
Beauftragen Sie jemanden mit der Erstellung einer „Fehlerstichprobe“ – 10–15 aktuelle Abfragen, bei denen die Ausgabe falsch oder von schlechter Qualität war. Erfassen Sie für jede einzelne den vollständigen Pipeline-Status: die ursprüngliche Abfrage, was abgerufen wurde, welcher Kontext an das Modell gesendet wurde und was das Modell generiert hat. Diese Spur ist wichtig. Ohne sie debuggen Sie blind.
Bereiten Sie auch Ihre metrischen Trends vor. Wird es seit der letzten Retro besser oder schlechter? Irgendwelche drastischen Änderungen?
Das Treffen (60 Minuten)
Metriküberprüfung (10 Minuten). Gehen Sie die Abruf- und Generierungsmetriken durch. Konzentrieren Sie sich auf Trends und Überraschungen, nicht auf eine Zahlen-für-Zahlen-Rezitation. „Precision@5 ist diesen Monat von 0,72 auf 0,58 gesunken“ ist nützlich. Das Ablesen aller Kennzahlen aus einem Dashboard ist nicht der Fall.
Fehleranalyse (35 Minuten). Dies ist der Kern der Retro. Nehmen Sie die Fehlerprobe und klassifizieren Sie jeden Fehler danach, wo die Pipeline kaputt gegangen ist:
- Abruffehler: Die richtigen Dokumente wurden nicht abgerufen. Warum? Nichtübereinstimmung zwischen Abfrage und Dokument? Einschränkung des Einbettungsmodells? Metadatenfilterung zu aggressiv?
- Chunking-Fehler: Das richtige Dokument wurde abgerufen, aber die Blockgrenzen teilen die Antwort auf zwei Blöcke auf und nur einer wurde zurückgegeben. Oder der Brocken war zu groß und mit irrelevantem Inhalt verdünnt.
- Kontextfehler: Gute Blöcke wurden abgerufen, aber durch die Reihenfolge oder Kürzung des Kontextfensters gingen die wichtigen Informationen verloren. Oder widersprüchliche Teile verwirrten das Modell.
- Generierungsfehler: Es wurde ein guter Kontext bereitgestellt, aber das Modell halluzinierte trotzdem, ignorierte den Kontext oder gab eine vage Antwort anstelle der in den Dokumenten verfügbaren spezifischen Antwort.
Fragen Sie bei jedem Fehler: „Welche Lösung hätte diesen Fehler am günstigsten beheben oder verhindern können?“ Manchmal ist es eine schnelle Änderung. Manchmal geht es darum, ein bestimmtes Dokument neu aufzuteilen. Manchmal ist es eine systemische Veränderung.
Priorisierung und Maßnahmen (15 Minuten). Gruppieren Sie die Fehler nach Grundursache. Das Muster, das die meisten Fehler verursacht hat, erhält die meiste Aufmerksamkeit. Wählen Sie 2-3 Verbesserungen aus, die Sie vor der nächsten Retro umsetzen möchten.
Häufige Fehlermuster und Fehlerbehebungen
Hier sind die Muster, die Sie am häufigsten sehen, und praktische Ansätze für jedes:
„Das richtige Dokument befindet sich in unserer Wissensdatenbank, wird aber beim Abrufen übersehen.“ Dies ist normalerweise ein Einbettungsähnlichkeitsproblem. Die Abfrage des Benutzers verwendet ein anderes Vokabular als das Quelldokument. Korrekturen: Fügen Sie einen Schritt zur Abfrageerweiterung hinzu (schreiben Sie die Abfrage des Benutzers in mehrere Formulierungen um), implementieren Sie eine Hybridsuche (kombinieren Sie semantische Einbettungen mit Schlüsselwortübereinstimmung wie BM25) oder verbessern Sie Ihre Metadatenfilterung, um den Suchraum einzugrenzen.
„Wir rufen das richtige Dokument ab, aber den falschen Chunk.“ Ihre Chunking-Strategie ist wichtiger, als den meisten Teams bewusst ist. Wenn Sie Chunking mit fester Größe (z. B. 500 Token) verwenden, teilen Sie mit ziemlicher Sicherheit wichtige Inhalte über Grenzen hinweg auf. Korrekturen: Verwenden Sie semantisches Chunking (Aufteilung basierend auf Themenverschiebungen), fügen Sie Chunk-Überlappung hinzu, versuchen Sie es mit hierarchischem Chunking, bei dem größere übergeordnete Chunks den Kontext für kleinere untergeordnete Chunks bereitstellen.
„Das Modell ignoriert guten Kontext und erfindet Dinge.“ Dies ist ein Problem mit der Aufforderung und dem Verhalten des Modells. Das parametrische Wissen des Modells widerspricht dem bereitgestellten Kontext und das parametrische Wissen gewinnt. Korrekturen: Passen Sie Ihre Systemaufforderung an, um das Modell explizit anzuweisen, nur den bereitgestellten Kontext zu verwenden. Fügen Sie die Anweisung „Wenn der Kontext die Antwort nicht enthält, sagen Sie es“ hinzu. Erwägen Sie eine Reduzierung der Temperatur des Modells.
„Antworten sind richtig, aber zu langsam.“ Latenzprobleme entstehen normalerweise aus einem von drei Gründen: zu viele Abrufaufrufe, ein zu großes Kontextfenster (mehr Token = langsamere Generierung) oder Schritte zur Neuordnung, die die Verarbeitungszeit verlängern. Profilieren Sie Ihre Pipeline Komponente für Komponente. Die Lösung hängt davon ab, wohin die Zeit geht.
„Die Qualität ist inkonsistent – großartig für einige Themen, schrecklich für andere.“ Dies bedeutet normalerweise, dass einige Teile Ihrer Wissensdatenbank besser indiziert sind als andere. Möglicherweise wurden bestimmte Dokumente schlecht geparst oder bestimmte Themen werden nicht ausreichend behandelt. Ordnen Sie Ihre Fehler nach Themenbereichen zu und Sie werden die Lücken finden.
Aufbau einer kontinuierlichen Verbesserungsschleife
Die effektivsten RAG-Teams behandeln ihr System wie ein Produkt, nicht wie ein Projekt. Es ist nie „fertig“. Jede Retrospektive sollte inkrementelle Verbesserungen hervorbringen, und diese Verbesserungen sollten bei der nächsten Retrospektive messbar sein.
Eine praktische Kadenz:
- Wöchentlich: Schnelle Überprüfung automatisierter Qualitätsmetriken (kann asynchron sein, überprüfen Sie einfach das Dashboard)
- Zweiwöchentlich oder monatlich: Vollständige Retrospektive mit Fehleranalyse
- Vierteljährlich: Größere Architekturentscheidungen – sollten wir Einbettungsmodelle ändern, unsere Wissensbasis umstrukturieren, eine neue Chunking-Strategie einführen?
Führen Sie ein fortlaufendes Dokument darüber, was Sie versucht haben und welche Auswirkungen es hatte. Die RAG-Optimierung ist iterativ und nichtlinear – manchmal greift man auf Ansätze zurück, die vorher nicht funktionierten, weil sich der Rest der Pipeline so weit verändert hat, dass sie jetzt funktionieren.
Vermeiden Sie die Falle für glänzende Objekte
Jede Woche gibt es ein neues Papier oder Framework, das angeblich RAG-Qualität löst. Widerstehen Sie dem Drang, Ihre Pipeline anhand eines Blogbeitrags neu zu gestalten. Nutzen Sie stattdessen Ihre retrospektiven Daten, um Ihr tatsächlich größtes Qualitätsproblem zu identifizieren und dieses spezifische Problem zu lösen. Vielleicht ist die Antwort ein schickes neues Re-Ranking-Modell. Wahrscheinlicher ist, dass dadurch die Aufteilung Ihrer Produktdokumentation korrigiert wird.
Die Teams, die sich am schnellsten verbessern, sind nicht diejenigen, die die ausgefeilteste Architektur verwenden. Sie sind diejenigen mit der engsten Rückkopplungsschleife zwischen „Diese Ausgabe war schlecht“ und „Hier ist der genaue Grund dafür und hier ist, was wir geändert haben.“
Probieren Sie NextRetro kostenlos aus – Kategorisieren Sie RAG-Fehlermuster mit Spalten und stimmen Sie darüber ab, welche Pipeline-Verbesserungen priorisiert werden sollen.
Letzte Aktualisierung: Februar 2026
Lesezeit: 7 Minuten
