Wie man zuverlässige RAG-Systeme aufbaut: Eine tiefe Analyse von 7 Fehlerpunkten und Evaluationsframeworks

Retrieval-Augmented Generation (RAG) ist für moderne KI-Architekturen von entscheidender Bedeutung und dient als grundlegendes Framework für den Aufbau von kontextbewussten Agenten.

Aber der Übergang von einem grundlegenden Prototyp zu einem produktionsreifen System beinhaltet die Überwindung erheblicher Hürden bei der Datenrückgewinnung, Kontextkonsolidierung und Antwortsynthese.

Dieser Artikel bietet eine tiefe Analyse von sieben typischen RAG-Fehlerpunkten und Evaluationsmetriken mit praktischen Code-Beispielen.

Die Anatomie des RAG-Zusammenbruchs – 7 Fehlerpunkte (FPs)

Laut den Forschern Barnett et al. stoßen Retrieval Augmented Generation (RAG) Systeme auf sieben spezifische Fehlerpunkte (FPs) im gesamten Prozess.

Das folgende Diagramm veranschaulicht diese Stadien:

Abbildung A. Indexierungs- und Abfrageprozesse, die für die Erstellung eines RAG-Systems erforderlich sind. Der Indexierungsprozess wird während der Entwicklung durchgeführt und die Abfragen zur Laufzeit. Die in dieser Studie identifizierten Fehlerpunkte sind in roten Kästchen dargestellt (Quelle)

Lassen Sie uns jeden FP in der Reihenfolge des Prozesses erkunden, beginnend mit der oberen linken Ecke und fortschreitend in Richtung der unteren rechten Ecke, wie in Abbildung A gezeigt.

FP1. Fehlendes Inhalt

Fehlender Inhalt tritt auf, wenn das System eine Frage gestellt wird, die nicht beantwortet werden kann, weil die relevanten Informationen nicht im verfügbaren Vektor-Speicher vorhanden sind.

Der Fehler tritt auf, wenn ein LLM eine plausibel klingende, aber falsche Antwort liefert, anstatt zu sagen, dass es es nicht weiß.

FP2. Verpasste Top-Ranked-Dokumente

Dies ist eine Situation, in der ein korrektes Dokument im Vektor-Speicher vorhanden ist, aber der Abruf-Algorithmus es nicht hoch genug bewertet, um es in die Top-k-Dokumente aufzunehmen, die als Kontext an ein LLM weitergegeben werden.

Infolgedessen erreicht die korrekte Information niemals das LLM.

FP3. Nicht im Kontext (Konsolidierungsstrategie-Beschränkungen)

Dies ist eine Situation, in der ein korrektes Dokument vorhanden ist und aus dem Vektor-Speicher abgerufen wird, aber während des Konsolidierungsprozesses ausgeschlossen wird.

Dies geschieht, wenn zu viele Dokumente zurückgegeben werden und das System sie filtern muss, um sie innerhalb des Kontextfensters eines LLM, der Token-Grenzwerte oder Rate-Grenzwerte zu passen.

FP4. Nicht extrahiert

Dies ist eine Situation, in der ein LLM es nicht schafft, die korrekte Information im Kontext zu identifizieren, obwohl die korrekte Information im Vektor-Speicher vorhanden war und erfolgreich abgerufen und konsolidiert wurde.

Dies geschieht, wenn der Kontext zu laut oder widersprüchliche Informationen enthält, die das LLM verwirren.

FP5. Falsches Format

Dies ist eine Situation, in der die Speicherung, Abruf, Konsolidierung und LLM-Interpretation erfolgreich durchgeführt werden, aber das LLM die spezifischen Formatierungsanweisungen im Prompt nicht befolgt, wie z. B. eine Tabelle, eine Aufzählung oder ein JSON-Schema.

FP6. Falsche Spezifität

Die Ausgabe eines LLM ist technisch vorhanden, aber entweder zu allgemein oder zu komplex im Vergleich zu den Bedürfnissen des Benutzers.

Zum Beispiel generiert ein LLM einfache Antworten auf eine Benutzeranfrage mit einem komplexen professionellen Ziel.

FP7. Unvollständige Antworten

Dies ist eine Situation, in der ein LLM eine Ausgabe generiert, die nicht unbedingt falsch ist, aber wichtige Informationen fehlen, die im Kontext verfügbar waren.

Zum Beispiel, wenn ein Benutzer eine komplexe Frage wie “Was sind die wichtigsten Punkte in den Dokumenten A, B und C?” stellt, beantwortet das LLM nur einen oder zwei der Quellen.

Wie FPs die Leistung von RAG-Pipelines beeinträchtigen

Jeder dieser FPs beeinträchtigt die Leistung von RAG-Pipelines:

Datenintegrität und Vertrauensfehler

Wenn fehlende oder falsche Informationen vorhanden sind, ist das System nicht länger eine zuverlässige Informationsquelle. Primäre FPs sind:

• FP1 (Fehlendes Inhalt): Die Antwort ist nicht im Dokument vorhanden.
• FP4 (Nicht extrahiert): Das LLM ignoriert die korrekte Antwort im Dokument.
• FP7 (Unvollständig): Das LLM liefert Halbwahrheiten, wichtige Teile fehlen.

Abruf- und Effizienzbottlenecks

Die RAG-Pipeline kann ineffizient sein, wenn sie wichtige Informationen in den Abruf- und Konsolidierungsstadien verpasst. Primäre FPs sind:

• FP2 (Verpasste Top-Ranked): Das Embedding-Modell kann die Top-k-Embeddings nicht auswählen.
• FP3 (Konsolidierungsstrategie): Das Skript, das Dokumente auf die LLM-Grenzwerte filtert, entfernt die wichtigsten Teile.

Benutzererfahrung und Formatierungsfehler

Obwohl korrekt, kann eine Ausgabe mit schlechter Lesbarkeit oder im falschen Format die Benutzererfahrung beeinträchtigen. Primäre FPs sind:

• FP5 (Falsches Format): Das LLM folgt nicht dem spezifischen Ausgabeformat wie JSON.
• FP6 (Falsche Spezifität): Das LLM generiert eine umfangreiche Ausgabe für eine einfache Ja/Nein-Frage oder umgekehrt (zu kurze Antwort für eine komplexe Frage).

Die Evaluations-Stack: Frameworks zur Minderung von FPs

Evaluationsmetriken sind darauf ausgelegt, diese FPs systematisch zu mindern.

Dieser Abschnitt erforscht wichtige Evaluationsmetriken mit praktischen Anwendungsbeispielen.

Wichtige RAG-Evaluationsmetriken:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Der Unit-Test vor der Bereitstellung

DeepEval berechnet eine gewichtete Punktzahl basierend auf den Kriterien.

Ein LLM-as-a-Richter (z. B. GPT-4o) bewertet jedes Kriterium gegen die Ausgabe eines LLM:

DeepEval nutzt G-eval, ein chain-of-thought (CoT)-Framework, das einen mehrstufigen Ansatz zur Ausgabe-Bewertung verwendet:

1. Definieren Sie ein Kriterium zur Messung (z. B. “Kohärenz”, “Flüssigkeit” oder “Relevanz”).
2. Erstellen Sie Bewertungsschritte (mit einem Bewertungs-LLM).
3. Folgen Sie dem Bewertungsschritt und analysieren Sie die Eingabe und die LLM-Ausgabe.
4. Berechnen Sie eine erwartete gewichtete Summe der Punktzahl jedes Kriteriums.

Übliches Szenario in der Praxis

• Situation: Ein technischer Dokumentations-Assistent (Bot) für ein komplexes Software-Produkt scheint jedes Mal zu funktionieren, wenn das Ingenieur-Team die Code-Basis aktualisiert.
• Problem: Kein quantitativer Beweis, ob der Bot immer noch die Benutzeranfrage beantworten kann (Sie denken nur, dass es funktioniert…).
• Lösung: Integrieren Sie eine PyTest-Funktion als CI/CD-Regressionstest in Github Action, in der DeepEval G-Eval und andere Metriken über einen Testfall ausführt:

• Erwartete Ergebnisse: Wenn die Punktzahl einer der Metriken unter die Schwelle (0,85) fällt, löst PyTest einen AssertionError aus – der CI-Build wird sofort fehlschlagen und verhindert, dass der stille Regressionsfehler in die Produktion gelangt.

Entwickler-Hinweis – Der Testfall für DeepEval
Ein Satz von LLMTestCase-Objekten definiert den Testfall, den DeepEval ausführt.

In der Praxis sollte dieser Testfall die meisten wichtigen Benutzeranfragen und gelabelte Ausgaben mit dem abgerufenen Kontext enthalten.

Diese können aus einer JSON- oder CSV-Datei abgerufen werden.

RAGAS – Der Nadel-im-Heuhaufen-Optimierer

Retrieval Augmented Generation Assessment (Ragas) zielt darauf ab, RAG ohne menschlich annotierte Datensätze zu bewerten, indem synthetische Testsets generiert werden.

Dann werden Flaggschiff-Metriken berechnet:

Abbildung B. Das RAGAS-Evaluations-Triade-Diagramm, das Frage, Kontext und Antwort über Präzision, Recall, Treue und Relevanz-Metriken verbindet (Erstellt von Kuriko IWAI)

Die Flaggschiff-Metriken sind in drei Gruppen unterteilt:

• Abfrage-Pipeline (schwarze, durchgezogene Linie, Abbildung B): Kontext-Präzision, Kontext-Recall.
• Generierungs-Pipeline (schwarze, gepunktete Linie, Abbildung B): Treue, Antwort-Relevanz.
• Ground-Truth (roter Kasten, Abbildung B): Antwort-Semantik-Ähnlichkeit, Antwort-Korrektheit.

Übliches Szenario in der Praxis

• Situation: Das RAG-System für Rechtsverträge fehlt wichtige Klauseln. Sie sind sich nicht sicher, ob das Problem im Such- (Abruf-) oder Leseprozess (Generator) liegt.
• Problem: Keine Ahnung von der optimalen Top-k (Anzahl der abgerufenen Chunks).
• Lösung: Verwenden Sie RAGAS, um ein synthetisches Testset mit 100 Paaren von Fragen und Beweisen zu erstellen. Dann führen Sie die RAG-Pipeline gegen das Testset aus, um Kontext-Recall und Kontext-Präzision zu berechnen:
• Erwartetes Ergebnis: Je nach Metrik-Ergebnis kann der Aktionsplan wie folgt aussehen:

Tabelle 1. RAGAS-Diagnose-Aktionsplan – Zuordnung von Punktzahlen zu System-Anpassungen.

TruLens – Der Feedback-Schleifen-Spezialist

TruLens konzentriert sich auf die internen Mechanismen des RAG-Prozesses und nicht nur auf die endgültige Ausgabe, indem es Feedback-Funktionen verwendet.

Es verwendet auch eine LLM-basierte Punktzahl, die widerspiegelt, wie gut die Antwort den Intent der Anfrage erfüllt, mit einer 4-Punkt-Likert-Skala (0-3), was es für die Bewertung der Qualität verschiedener Suchergebnisse überlegen macht.

Übliches Szenario in der Praxis

• Situation: Ein medizinischer Berater-Bot beantwortet eine Benutzeranfrage korrekt, aber fügt einen Pro-Tipp hinzu, der nicht in der geprüften PDF-Basis enthalten ist.
• Problem: Der hinzugefügte Pro-Tipp kann hilfreich sein, aber nicht fundiert.
• Lösung: Verwenden Sie TruLens, um eine Grundierungs-Feedback-Funktion mit einer Schwelle wie Punktzahl > 0,8 zu implementieren.

• Erwartete Ergebnisse: Wenn das LLM eine Antwort generiert, die Informationen enthält, die nicht im abgerufenen Chunk vorhanden sind, markiert TruLens den Eintrag in Ihrem Dashboard.

Arize Phoenix – Die stille Fehlerkarte

Arize Phoenix ist ein Open-Source-Beobachtungs- und Evaluations-Tool, um LLM-Ausgaben, einschließlich komplexer RAG-Systeme, zu bewerten.

Basierend auf OpenTelemetry von Arize AI konzentriert es sich auf Beobachtbarkeit, indem es die LLM-Evaluierung als Teil von MLOps behandelt.

Im Kontext der RAG-Evaluierung exceliert Phoenix bei der Einbettungs-Analyse, indem es Uniform Manifold Approximation and Projection (UMAP) verwendet, um hochdimensionale Vektor-Einbettungen in 2D/3D-Raum zu reduzieren.

Diese Einbettungs-Analyse zeigt mathematisch, ob die fehlgeschlagenen Abfragen semantisch gruppiert sind, was auf eine Lücke im Vektor-Datenbestand hinweist.

Übliches Szenario in der Praxis

• Situation: Ein Kunden-Support-Bot funktioniert großartig für Rückerstattungen, aber liefert unsinnige Antworten auf Garantie-Ansprüche.
• Problem: Datenlücke im Vektor-Datenbestand (Kann nicht in den Protokollen gefunden werden).
• Lösung: Verwenden Sie Arize Phoenix, um eine Umap-Einbettungs-Visualisierung (UEV) zu erstellen, eine 3D-Karte für den Vektor-Datenbestand – um Benutzeranfragen auf die Dokument-Chunks zu überlagern.
• Erwartete Ergebnisse: Visualisieren Sie einen Cluster von Benutzeranfragen, die in der dunklen Zone landen, in der keine Dokumente existieren, was darauf hinweist, dass einige Dokumente vergessen wurden, in den Vektor-Speicher hochzuladen.

Braintrust – Das Prompt-Regression-Sicherheitsnetz

Braintrust ist für Hochfrequenz-Iterierungszyklen konzipiert und verwendet Modell-zu-Modell-Vergleiche.

Gemeinsames Szenario in der Praxis

• Situation: Ein Ingenieur-Team aktualisiert den Prompt von “Antworten Sie auf die Frage” (Fall A) auf eine komplexere 500-Wörter-Systemanweisung (Fall B).
• Problem: Die Verbesserung des Prompts für Fall B könnte versehentlich Fall A brechen.
• Lösung: Verwenden Sie Braintrust, um einen Goldenen Datensatz mit einem Satz von N perfekten Beispielen (z. B. N = 50) zu erstellen. Lassen Sie Braintrust eine side-by-side-Vergleich jederzeit ausführen, wenn das Team ein einzelnes Wort im Prompt aktualisiert:

• Erwartetes Ergebnis: Ein Differenzbericht, der genau zeigt, welche Fälle besser oder schlechter geworden sind für jeden der Goldenen Datensatz (N = 50).

Zusammenfassung

Wenn RAG mit geeigneten Evaluationsframeworks gehandhabt wird, kann es ein wettbewerbsfähiges Tool sein, um einen LLM den Kontext zu liefern, der für die Benutzeranfrage am relevantesten ist.

Implementierungsstrategie: Zuordnung von Metriken zu Fehlerpunkten

Obwohl es keine universelle Lösung gibt, zeigt Tabelle 2, welche Evaluationsmetriken für jeden FP verwendet werden sollten, den wir in diesem Artikel besprochen haben:

Tabelle 2. Die Fehlerpunkt-Minderungs-Matrix – Welches Tool löst welchen FP?

DeepEval und RAGAS können ihre Treue-Metriken nutzen, um Datenintegritätsfehler (FP1, FP4, FP7) zu messen.

TruLens nutzt seine Kontext-Präzision/Recall, um die Kontext-Relevanz für die Ausgabe zu messen – effektiv bewertend FP2.

Arize Phoenix bietet eine visuelle Verfolgung des Abrufprozesses, was es einfach macht, zu sehen, ob das abgerufene Dokument während der Konsolidierung verloren ging (FP3).

Bei UX-Fehlern erstellt DeepEval benutzerdefinierte Metriken, um UX-Fehler zu bewerten, während Braintrust bei der Ground-Truth-Datensatz-Vergleich hervorragt.