Startseite / Artikel

Debuggen von RAG, indem man die erste fehlerhafte Stufe findet

Führen Sie eine Fehlerbehebung für einen RAG-Pipeline durch, indem Sie die erste fehlerhafte Stufe finden: Quelle, Abruf, Erstellung oder Operationen. Jedes Experiment behebt anschließend ein klar identifiziertes Problem.

3 Min. Lesezeit655 Wörter

Wenn ein Wissensassistent eine schlechte Antwort gibt, ist es eine einfache Reaktion, die Anfrage zu ändern. Das ist nur nützlich, wenn das Modell ausreichende Belege erhalten hat und diese anschließend falsch verarbeitet hat.

Ein fehlendes Dokument, eine unvollständige Extraktion und ein nicht gestütztes Fazit sind unterschiedliche Fehler. Sie als einen einzigen Qualitätswert zu betrachten, verlangsamt das Debuggen, da der Wert nicht angeben kann, welcher Teil geändert werden muss.

Ein praktischer Bewertungslauf sollte den Weg vom Quellmaterial bis zur von dem Benutzer gesehenen Antwort beibehalten.

Bilde Beispiele mit Belegen statt nur mit Antworten

Für jede Testfrage sollten die Abschnitte aufgezeichnet werden, die eine akzeptable Antwort stützen. Enthalte außerdem Angaben dazu, welche Aspekte die Antwort beibehalten muss und welche Aussagen sie vermeiden sollte.

Ein illustratives Beispiel könnte so aussehen:

{
  "question": "When should this deployment be rolled back?",
  "required_evidence": ["handbook-v3:section-8"],
  "must_include": ["the failed health-check condition"],
  "must_not_claim": ["every warning requires rollback"],
  "answerable": true
}

Diese Aufzeichnung ist nützlicher als ein einzelner erwarteter Satz. Sie ermöglicht mehrere gut formulierte Antworten, während die Bedingungen beibehalten werden, die sie korrekt machen.

Fügen Sie Fragen hinzu, auf die das Korpus keine Antwort geben kann. Andernfalls mag ein System, das stets etwas generiert, stärker erscheinen als eines, das fehlende Beweise korrekt anerkennt.

Überprüfen Sie zunächst den frühesten Fehler

Beginnen Sie mit der Quelle. Existiert die erforderliche Information im indizierten Text, und gehört sie zum angegebenen Dokument? Falls nicht, beheben Sie die Quellenerfassung.

Anschließend prüfen Sie die Extraktion. Ist der relevante Beweis in den Kandidatenpool gelangt? Falls ja, hat er das Filtern, die Neubewertung und den Kontextaufbau überstanden? Das sind getrennte Überprüfungspunkte. Ein Abschnitt, der durch die Suche gefunden wurde, aber vor der Generierung entfernt wurde, kann die endgültige Antwort nicht stützen.

Zum Schluss sollte die Antwort überprüft werden. Hat sie die Beweise genau wiedergegeben, Ausnahmen berücksichtigt und unbegründete Behauptungen vermieden? Wenn der Kontext ausreichend war, aber die Antwort fehlerhaft war, werden das Anregungs- oder Generierungsverhalten zu einem sinnvollen Ziel.

Diese Reihenfolge verhindert, dass ein leistungsstarkes Modell schwache Ergebnisse bei einfachen Fragen überdeckt und anschließend unvorhersehbar bei Fragen versagt, die es aufgrund seines bisherigen Wissens nicht beantworten kann.

Nutzen Sie Metriken, die verschiedene Fehler aufzeigen

Die bei einer gewählten Schwellenwertgrenze ermittelte Recall-Wert gibt den Anteil der markierten, relevanten Elemente an, die abgerufen wurden. Die Präzision misst den Anteil der zurückgegebenen Elemente, die tatsächlich relevant sind. Ein Hit-Rate-Wert prüft, ob zumindest ein relevantes Element vorhanden war; dieser Wert ist schwächer als das Wiederherstellen aller Beweise, die für eine mehrteilige Antwort erforderlich sind.

Rangierungsmetriken helfen dabei, Belege an erster Stelle von solchen zu unterscheiden, die nahe am Schwellenwert liegen. Doch bei den Relevanzlabeln ist Vorsicht geboten: Ein Abschnitt kann das Thema nur erwähnen, während ein anderer die Frage direkt beantwortet. Sie als gleich nützlich zu betrachten kann falsches Verhalten belohnen.

Zur Erstellung von Antworten sollten Unterstützung, Korrektheit, Vollständigkeit sowie Übereinstimmung der Zitate getrennt bewertet werden. Eine Antwort kann eine veraltete Quelle genau wiedergeben – sie kann aber auch eine korrekte Aussage enthalten, die von den bereitgestellten Belegen nicht gestützt wird. In solchen Fällen sind unterschiedliche Korrekturmaßnahmen erforderlich.

Bewahren Sie die Betriebsqualität im selben Experiment bei

Erhalten Sie die Reaktionszeit, Fehler sowie Ressourcennutzung zusammen mit den Qualitätsbeurteilungen auf. Bewahren Sie außerdem die Version des Korpus, die Sucheinstellungen, die Prompt-Version sowie den Modellidentifikator auf, damit Vergleiche interpretierbar bleiben.

Beim Diagnostizieren einer Regression sollte man jeweils nur eine wichtige Variable ändern. Vergleichen Sie beispielsweise das Ein- und Ausschalten des Rerankings, während der Kandidatenpool unverändert bleibt. Die gleichzeitige Änderung von Chunking, Abrufmethode und Prompt kann die Bewertung verbessern, ohne die Ursache klarzustellen.

Automatisierte Bewertungssysteme können dabei helfen, viele Ergebnisse zu überprüfen, doch abweichende Entscheidungen sowie sensible Randfälle müssen manuell geprüft werden. Die Bewertung eines Systems ist eine weitere, mit Einschränkungen verbundene Messgröße und ersetzt keine explizite Bewertungskriterienliste.

Bewerten Sie, was beim Benutzer ankommt

Auch eine korrekte Antwort des Backends kann unter der falschen Abfrage angezeigt werden, wenn die Schnittstelle veraltete Anfragen akzeptiert. Beinhaltet in den End-to-End-Prüfungen die React-Suchinteraktion.

Das nützliche Ergebnis der Bewertung ist eine konkrete weitere Maßnahme: Reparatur der Extraktion, Erweiterung der Suche, Beibehaltung des Kontexts, Überarbeitung der Generierung oder Korrektur der Übermittlung. Das ist ein viel stärkeres Ergebnis als nur zu wissen, dass eine Antwort „falsch wirkte“.