RAG-Evaluierung: Testen der Retrieval-Funktion vor der Feinabstimmung des LLM

RAG-Evaluierung sollte mit dem Retrieval beginnen. Wenn die richtigen Beweise das Modell nie erreichen, macht die Anpassung der Eingabeaufforderung und Modell-Upgrades nur den falschen Kontext überzeugender. Testen Sie Retrieval, Generierung und Operationen als separate Phasen. Halten Sie ein kleines, versioniertes Regression-Set, das fehlschlägt, wenn eine Phase schlechter wird.

Leserniveau: Mittelstufe. Dieser Leitfaden geht davon aus, dass Sie wissen, dass retrieval-augmented generation, oder RAG, Dokumente findet, bevor ein Sprachmodell um eine Antwort gebeten wird.

In diesem Leitfaden

RAG-Evaluierung hat drei separate Fehlerflächen

Eine RAG-Anwendung ist eine Pipeline. Ein Punkt für die endgültige Antwort verbirgt, welches Element verbessert werden muss.

Die Reihenfolge ist wichtig. Retrieval ist upstream. Ein Generator kann keinen Paragraphen einer Richtlinie zitieren, der nie in seinen Kontext gelangt ist, und eine fließende Antwort beweist nicht, dass der Retriever funktioniert hat.

Die aktuelle RAG-Evaluator-Dokumentation von Microsoft macht dieselbe Trennung in Implementierungsbegriffen. Sie bietet Dokumentenabrufmaßnahmen für eingestufte Beweise und bewertet dann Verankertheit, Relevanz und Vollständigkeit der Antwort auf der Antwortebene. Der Dokumentenabruf-Evaluator umfasst Treue, NDCG, XDCG, maximale Relevanz und fehlende Relevanzurteile.

_Ein nützliches RAG-Scorecard hält Retrieval-, Generierungs- und Betriebsprüfungen sichtbar als separate Schichten._

Warum eine End-to-End-Punktzahl schwache Debugging-Beweise liefert

Mehrere Forschungsrahmen kommen aus unterschiedlichen Richtungen zu demselben praktischen Schluss.

RAGChecker bewertet das Verhalten von Retriever und Generator separat. Die Autoren verglichen acht RAG-Systeme über zehn Domänen hinweg. Ihre Metriken umfassen Anspruchs-Rückruf und Kontext-Präzision für Retrieval sowie Kontextnutzung, Geräuschsensitivität, Halluzination und Treue für die Generierung. In einer Meta-Evaluation mit 280 Paaren hatte die Gesamtbewertung von RAGChecker eine Spearman-Korrelation von 0,609 mit menschlicher Präferenz. Die beiden menschlichen Annotatoren erreichten 0,689. Die automatisierte Bewertung war nützlich, beseitigte jedoch nicht die menschliche Lücke.

Ragas schlug referenzfreie Maße für Treue, Antwortrelevanz und Kontextrelevanz vor. In seinen WikiEval-Vergleichen betrug die Übereinstimmung mit menschlichen Präferenzen 0,95 für Treue, 0,78 für Antwortrelevanz und 0,70 für Kontextrelevanz. Die Autoren fanden es am schwierigsten, die Kontextrelevanz zu beurteilen. Behandeln Sie diese Zahlen als Ergebnisse dieser Studie, nicht als universelle Genauigkeitsraten für jeden Richter, Datensatz oder jede Domäne.

Ein neuerer Rahmen, RAGe, fügt die Auswahl von Komponenten und Hardware-Telemetrie hinzu. Er bewertet Pipeline-Konfigurationen über Chunking, Einbettung, Retrieval, Speicherung und Generierung, während Kombinationen, die Latenz- oder VRAM-Grenzen überschreiten, beschnitten werden. Das Papier verwendet standardmäßig Natural Questions, NewsQA und TriviaQA und unterstützt benutzerdefinierte CSV- oder JSON-Datensätze. Sein Hauptbeitrag ist eine Möglichkeit, Qualität mit Ressourcenbeschränkungen zu vergleichen; es etabliert keine Konfiguration, die in allen Domänen gewinnt.

Zusammen unterstützen diese Papiere einen diagnostischen Ansatz. Sie beweisen nicht, dass eine bestimmte Metrik oder Bibliothek für die Produktion ausreichend ist.

Bauen Sie ein Testset auf, bevor Sie Metriken auswählen

Beginnen Sie mit 40 bis 60 Fragen aus dem Bereich, den Sie bedienen. Dieser Bereich ist ein praktischer Ausgangspunkt und kein statistisches Gesetz. Er ist groß genug, um mehrere Fehlertypen aufzudecken, und klein genug, damit ein Mensch nach jeder wesentlichen Änderung überprüfen kann.

Schließen Sie mindestens fünf Abfrageklassen ein:

Produktionsprotokolle können Fragen vorschlagen, aber entfernen Sie persönliche Daten und Geheimnisse, bevor Sie Beispiele zu einem Evaluationsset hinzufügen. Eine aktuelle Diskussion von Praktikern über die Produktionsevaluierung von RAG betont ebenfalls feste Abfragen, versionierte Konfigurationen und separate Prüfungen von Retrieval und Generierung. Diese Diskussion ist anekdotische Evidenz über Workflow-Probleme, nicht der Beweis, dass der Ansatz in jedem System funktioniert.

Speichern Sie Urteile gegen stabile Dokumenten-IDs zusammen mit jedem kopierten Text. Chunk-Grenzen ändern sich, wenn Sie einen Splitter anpassen. Eine kanonische Quell-ID lässt denselben Test diese Änderung überstehen.

{ "query_id": "refund-window-01", "query": "Wie lange hat ein Kunde Zeit, um einen ungeöffneten Artikel zurückzugeben?", "relevant_document_ids": ["returns-policy-v4"], "required_claims": ["Ungeöffnete Artikel können innerhalb von 30 Tagen zurückgegeben werden."], "must_abstain": false, "allowed_roles": ["customer", "support"], "as_of": "2026-07-01" }

Für einen unbeantwortbaren Fall setzen Sie `relevant_document_ids` auf eine leere Liste und `must_abstain` auf `true`. Für einen eingeschränkten Fall führen Sie dieselbe Abfrage unter zwei Rollen aus. Der autorisierte Benutzer sollte das Dokument abrufen; der nicht autorisierte Benutzer sollte nicht erfahren, was der Inhalt dieses Dokuments ist.

Teams, die ihr eigenes Korpus und Anwendungsschicht aufbauen, sollten den Inhaltsvertrag zusammen mit dem Testset versionieren. Dieselbe Regel gilt für benutzerdefinierte Datensysteme, die mit Next.js und AI erstellt wurden: Eine Schema- oder Inhaltsänderung kann das Retrieval verändern, ohne die Eingabeaufforderung zu berühren.

Schritt 1: Bewerten Sie das Retrieval, ohne eine Antwort zu generieren

Führen Sie jede Abfrage durch den Retriever und speichern Sie die eingestuften Ergebnis-IDs, Punktzahlen, Zeitstempel und Zugriffsentscheidungen. Rufen Sie das Sprachmodell noch nicht auf.

Wählen Sie Metriken, die zur Form der Beweise passen

Verwenden Sie Trefferquote@k, wenn ein korrektes Dokument ausreicht. Es fragt, ob mindestens eine relevante Quelle in den ersten `k` Ergebnissen erscheint.

Verwenden Sie Recall@k, wenn die Antwort mehrere Quellen erfordert. Es misst, wie viele bekannte relevante Dokumente in den ersten `k` erschienen sind.

Verwenden Sie Precision@k, wenn irrelevanter Kontext teuer oder ablenkend ist. Hoher Recall mit niedriger Precision kann den Generator mit Rauschen überfluten.

Verwenden Sie MRR, wenn das erste relevante Ergebnis am wichtigsten ist. Verwenden Sie NDCG, wenn mehrere bewertete Ergebnisse in einer nützlichen Reihenfolge erscheinen sollten. Microsoft dokumentiert NDCG und verwandte eingestufte Retrieval-Metriken in seinem Evaluator, während RAGChecker Anspruchs-Rückruf und Kontext-Präzision verwendet, um abgerufene Beweise mit den Ansprüchen zu verbinden, die eine Antwort benötigt.

Sammeln Sie nicht standardmäßig jede Metrik. Wählen Sie eine Abdeckungsmaßnahme und eine Ranking- oder Geräuschmaßnahme aus. Fügen Sie eine Metrik nur hinzu, wenn sie eine Entscheidung ändert.

Klassifizieren Sie Fehlschläge, bevor Sie das Modell ändern

Retrieval-Fehler fallen normalerweise in eine kleine Gruppe:

Jeder Fehler hat einen anderen Eigentümer. Das erneute Einbetten kann ein fehlendes Dokument nicht reparieren. Ein größeres Sprachmodell kann einen Berechtigungsfilter nicht reparieren. Ein Nachbearbeiter kann helfen, wenn die Beweise vorhanden, aber schlecht geordnet sind.

Für an Werkzeug angeschlossene Anwendungen bewahren Sie die Retrieval-Anfrage, Filter, Ergebnis-IDs und Werkzeugantwort im Trace auf. Das passt zum breiteren Kontrollmuster, das in MCP-Entwickler-Workflows beschrieben ist: Überprüfen Sie den Vertrag, den Statusübergang und den endgültigen Text.

Schritt 2: Bewerten Sie die Generierung über feste Beweise

Sobald das Retrieval seine Schwelle erreicht, frieren Sie die abgerufenen Kontexte ein und spielen Sie sie gegen den Generator ab. Dies isoliert Änderungen an der Eingabeaufforderung oder dem Modell von Änderungen am Index.

Messen Sie vier Verhaltensweisen:

Eine Referenzantwort kann bei der Vollständigkeit helfen. Sie ist weniger nützlich als einzige Wahrheitsquelle, da mehrere Formulierungen korrekt sein können. Speichern Sie erforderliche Ansprüche und unterstützende Dokumenten-IDs, wenn möglich.

Führen Sie einen zweiten Generierungstest mit absichtlich unvollständigem Kontext durch. Ein zuverlässiges System sollte Unsicherheit aufzeigen, anstatt Lücken aus dem Modellgedächtnis zu füllen. Dies ist wichtig, wenn der Korpus private, sich ändernde oder domänenspezifische Fakten enthält.

Die Wahl des Modells beeinflusst weiterhin die Antwortqualität, Latenz und Kosten, aber sie kommt nach den Retrieval-Beweisen. Wenn derselbe feste Kontext über Generatoren hinweg fehlschlägt, vergleichen Sie Modell- und API-Abwägungen. Wenn der Kontext selbst falsch ist, ist es eine verschwendete Bewegung, den Generator zu ändern.

Fügen Sie Sicherheits- und Konfliktfälle zum Retrieval-Set hinzu

Ordentliche Relevanztests übersehen gegnerische oder widersprüchliche Beweise.

Ein Papier aus Juli 2026 über polymorphe Sybil-Vergiftung in RAG testete Gruppen von lexikalisch unterschiedlichen Absätzen, die dieselbe vom Angreifer ausgewählte Antwort unterstützten. Unter dem erzwungenen Expositionssetup des Papiers produzierten polymorphe Absätze eine Hijack-Rate von 22,8 % im Vergleich zu 4,0 % für wiederholte monomorphe Absätze. Die Token-Überlappungsfilter erfassten alle monomorphen Cluster und keines der polymorphen Cluster.

Das Ergebnis misst nicht, wie oft dieser Angriff in der Produktion erfolgreich ist. Die Autoren fixierten die abgerufene Mischung auf sechs Angriffsabsätze, zwei Goldabsätze und zwei Füller, um das Verhalten der Leser zu isolieren. Sie berichten auch über Einschränkungen in Bezug auf eine Angriffsart, das Risiko der Datensatzkontamination, eine Ablation mit 500 Fragen und LLM-basierte Verifizierung.

Die nützliche Evaluationslektion ist enger: Klassifizieren Sie mehr als "korrekt" und "Angreiferziel". Das Papier verfolgt vier Ergebnisse:

Fügen Sie Konfliktfälle zu Ihrem eigenen Set hinzu. Schließen Sie duplizierte Ansprüche mit unterschiedlicher Formulierung, eine veraltete Quelle, die der aktuellen Richtlinie widerspricht, und eine weniger vertrauenswürdige Quelle, die mit einer autoritativen Quelle in Konflikt steht, ein. Zeichnen Sie auf, ob das System antwortet, sich enthält oder abdriftet.

Kalibrieren Sie LLM-Richter, bevor Sie ihren Punktzahlen vertrauen

LLM-Richter machen Regressionstests günstiger, insbesondere für Verankertheit und Anspruchsabdeckung. Sie bleiben Softwareabhängigkeiten mit Eingabeaufforderungen, Modellversionen, Parsing-Verhalten und bekannten blinden Flecken.

Verwenden Sie vier Kontrollen:

Die Studien von Ragas und RAGChecker zeigen beide, warum Kalibrierung wichtig ist. Die Übereinstimmung variiert je nach Dimension, und automatisierte Korrelationen bleiben unter der menschlichen Übereinstimmung. Eine numerische Punktzahl sollte eine Inspektion auslösen, nicht beenden.

Aktuelle Open-Source-Versionen zeigen auch aktive Arbeiten rund um Evaluatoren. DeepEval 4.1.3, veröffentlicht am 12. Juli 2026, fügte deterministische Prüfungen für Agentenschleifen und Werkzeugberechtigungen hinzu, während die Ragas-Integration behoben wurde. TruLens 2.9.0, veröffentlicht am 23. Juli, fügte Richter-Ensembles, A/B-Kriterientests, Punktzahlverteilungsanalysen und die Generierung von Goldensets hinzu. Die Veröffentlichungsaktivität ist ein Beweis für aufrechterhaltene Ingenieurarbeit, nicht der Beweis, dass eine der Bibliotheken die richtige Wahl für Ihren Stack ist.

Ein minimaler RAG-Regression-Workflow

Verwenden Sie dieselbe Reihenfolge für jede wesentliche Pipeline-Änderung:

Ein kompaktes Ergebnisprotokoll könnte so aussehen:

{ "run_id": "rag-2026-07-26-b", "test_set": "support-v7", "corpus_snapshot": "2026-07-25T22:00:00Z", "retrieval": { "recall_at_5": 0.91, "ndcg_at_5": 0.84, "unauthorized_hits": 0 }, "generation": { "grounded_pass_rate": 0.94, "complete_pass_rate": 0.87, "abstention_pass_rate": 0.90 }, "operations": { "p95_ms": 1380, "cost_per_query_usd": 0.0042 } }

Diese Zahlen sind illustrativ. Setzen Sie Schwellenwerte basierend auf Ihrem Risiko, Ihrer Basislinie und Ihren Fehlerkosten. Ein medizinischer Wissensassistent und ein Produkt-Suchhelfer sollten nicht dasselbe Freigabetor teilen.

Entscheiden Sie die Lösung aus der fehlgeschlagenen Schicht

Diese Tabelle ist der Punkt der RAG-Evaluierung: Eine fehlgeschlagene Punktzahl sollte das nächste Experiment identifizieren. Wenn sie das nicht kann, ist die Metrik zu weit von der Komponente entfernt, die Sie ändern müssen.

Was die Beweise unterstützen

Die Papiere maßen spezifische Systeme und Datensätze. RAGChecker stellte fest, dass modulare Metriken mit menschlichen Präferenzen korrelieren und die Trade-offs zwischen Retriever und Generator aufdecken können. Ragas stellte fest, dass die Übereinstimmung der Richter je nach Treue, Antwortrelevanz und Kontextrelevanz variierte. RAGe demonstrierte einen Rahmen, der Qualitätsmetriken mit Latenz- und Speicherbeschränkungen kombiniert. Der Vergiftungsbenchmark zeigte, dass ein eingeschränktes Angriffssetup unterschiedliche Muster von Hijack, Abstinenz und Drift erzeugte.

Die Beweise legen keine universellen Schwellenwerte, keinen universell besten Evaluator oder die Häufigkeit von Produktionsangriffen fest. Meine praktische Interpretation ist, die Phasen zu trennen, eine menschlich kalibrierte Teilmenge zu behalten und zu verlangen, dass jede Metrik auf eine Ingenieurtätigkeit hinweist.

Anspruchsprüfungen

| DeepEval und TruLens haben kürzlich Evaluierungsfunktionen veröffentlicht | Offizielle GitHub-Veröffentlichungsnotizen | Wartungssignal, kein Beweis für Annahme oder Qualität