Warum Evaluation bei RAG wichtig ist

Ein RAG-System kann den Eindruck erwecken, zu funktionieren, weil es flüssige und plausibel klingende Antworten zurückgibt. Ohne Messungen wissen Sie jedoch nicht, ob es wirklich die richtigen Chunks abruft oder verlässliche Antworten erzeugt. Teams, die auf Evaluierung verzichten, verbringen oft Monate damit, Chunking-Strategien und Prompt-Formate nach Gefühl anzupassen, nur um festzustellen, dass sie die Ergebnisse verschlechtert haben. Eine rigorose Evaluierung macht aus der Entwicklung von RAG kein Raten, sondern Engineering.

RAG umfasst zwei voneinander unabhängige Phasen, in denen Fehler auftreten können: Retrieval und Generierung. Beim Retrieval tritt ein Fehler auf, wenn die relevanten Chunks nicht in den Top-K-Ergebnissen auftauchen – das LLM kann keine gute Antwort generieren, wenn die richtigen Informationen gar nicht abgerufen wurden. Bei der Generierung tritt ein Fehler auf, wenn die richtigen Chunks abgerufen wurden, das LLM sie jedoch ignoriert, falsch interpretiert oder halluzinierte Informationen hinzufügt. Sie benötigen separate Metriken für jede Phase, um genau zu bestimmen, welche Komponente das Problem verursacht.

Wenn Sie nur die Qualität der endgültigen Antwort messen, bleibt verborgen, woher die Fehler stammen. Angenommen, Ihr System liefert in 30 % der Fälle falsche Antworten. Liegt das daran, dass beim Retrieval die richtigen Chunks fehlen, oder daran, dass das LLM gute Chunks ignoriert? Wenn Sie nur die endgültige Fehlerrate kennen, können Sie nicht feststellen, welche Komponente Sie korrigieren müssen. Instrumentieren Sie beide Phasen getrennt: Messen Sie die Retrieval-Qualität anhand von Golden Datasets und die Generierungsqualität anhand von Faithfulness-Werten.

Für die Evaluierung benötigen Sie ein Golden Dataset: eine Menge von Frage-Antwort-Paaren, bei denen Sie die richtige Antwort kennen und idealerweise auch wissen, aus welchem Dokument und Chunk die Antwort stammt. Für einen minimalen, aber funktionsfähigen Evaluierungssatz sammeln Sie 50–100 Fragen, die typische echte Benutzeranfragen repräsentieren. Beantworten Sie sie manuell oder indem Sie die Quelldokumente lesen. Berücksichtigen Sie verschiedene Fragetypen: das Nachschlagen von Fakten, Vergleiche, Multi-Hop-Schlussfolgerungen und Fragen außerhalb des Fachgebiets, die das System ablehnen sollte.

100 Fragen manuell zu erstellen, ist mühsam. Beschleunigen Sie diesen Prozess mit einem LLM zur Datengenerierung: Übergeben Sie jeden Dokument-Chunk an GPT-4o und bitten Sie es, 3–5 vielfältige Fragen zu generieren, deren Antworten in diesem Chunk zu finden sind, sowie den erwarteten Antworttext. Prüfen Sie manuell eine Stichprobe, um Qualitätsprobleme zu erkennen. Dieser Ansatz lässt sich schnell auf Tausende von Fragen skalieren, übersieht jedoch möglicherweise Sonderfälle, die nur echte Benutzer stellen würden.

Hit Rate@K ist der Anteil der Fragen, bei denen mindestens ein relevanter Chunk in den Top-K-Retrieval-Ergebnissen erscheint. Dies ist die einfachste und intuitivste Retrieval-Metrik. Eine Hit Rate@5 von 85 % bedeutet, dass sich bei 85 von 100 Fragen der relevante Chunk unter den fünf besten Ergebnissen befand. Erfassen Sie die Hit Rate getrennt für verschiedene Dokumenttypen, Abfragelängen und Themenkategorien, um herauszufinden, wo Ihr Retriever die größten Schwierigkeiten hat.

Faithfulness misst, ob die generierte Antwort ausschließlich Informationen enthält, die sich anhand des abgerufenen Kontexts überprüfen lassen. Eine nicht faithful Antwort fügt Fakten hinzu, die vom Kontext nicht gestützt werden – das ist eine Halluzination. Bewerten Sie Faithfulness, indem ein LLM als Prüfinstanz (oder ein menschlicher Evaluator) jeden Satz der Antwort mit dem Kontext abgleicht und alle Aussagen kennzeichnet, die nicht durch die abgerufenen Chunks gestützt werden. Für produktive Systeme ist ein Faithfulness-Wert von mindestens 95 % das Ziel.

Antwortrelevanz misst, ob die generierte Antwort tatsächlich auf die Frage des Benutzers eingeht. Eine sehr faithful Antwort kann dennoch am Kern vorbeigehen, indem sie eine verwandte, aber andere Frage beantwortet. Messen Sie die Relevanz getrennt von Faithfulness. Lassen Sie ein LLM als Prüfinstanz auf einer Skala von 1 bis 5 bewerten, ob die Antwort direkt auf die gestellte Frage eingeht. Eine geringe Antwortrelevanz weist häufig auf ein Problem in der Prompt-Struktur hin oder darauf, dass der abgerufene Kontext die Antwort gar nicht enthält.

Eine Evaluierung ist besonders wertvoll, wenn Sie Metriken im Zeitverlauf und bei Ihren Änderungen erfassen. Speichern Sie die Evaluierungsergebnisse mit Zeitstempeln und Versionsbezeichnungen in einer Datenbank oder Tabelle (z. B. chunk_size=500, embed=3-small, k=5). Wenn Sie eine neue Chunking-Strategie oder ein neues Embedding-Modell ausprobieren, führen Sie dieselbe Evaluierung durch und vergleichen Sie die Ergebnisse. So verhindern Sie Regressionen – möglicherweise verbessern Sie Faithfulness, senken aber versehentlich die Hit Rate. Führen Sie immer die vollständige Evaluierung durch, bevor Sie Änderungen in die Produktion übernehmen.

Über konkrete Metriken hinaus erfordert die Evaluierung einen Perspektivwechsel: Betrachten Sie RAG als Machine-Learning-System mit messbarer Leistung und nicht als Chatbot, den Sie durch Gespräche subjektiv bewerten. Legen Sie Erfolgskriterien im Voraus fest (z. B. Hit Rate@5 > 85 %, Faithfulness > 95 %). Richten Sie einen Testsatz ein, der unverändert bleibt und niemals für Entwicklungsentscheidungen verwendet wird. Reservieren Sie einen separaten Dev-Satz für Iterationen. Diese Disziplin unterscheidet Teams, die zuverlässige RAG-Systeme ausliefern, von Teams, die beeindruckende Demos veröffentlichen, die in der Produktion scheitern.

Eine wichtige Disziplin im Machine Learning, die auch für die RAG-Evaluierung gilt, ist die Aufteilung in Train-, Dev- und Testsatz. Ihr Testsatz sollte vollständig unverändert bleiben – verwenden Sie ihn niemals für Entwicklungsentscheidungen. Nutzen Sie einen separaten Dev-Satz, um mit Chunking-Strategien, Prompt-Änderungen und Embedding-Modellen zu experimentieren. Führen Sie den Testsatz erst aus, wenn Sie überzeugt sind, dass eine Änderung produktionsreif ist. Diese Trennung verhindert, dass Sie Ihre RAG-Pipeline an den Testsatz überanpassen, und stellt sicher, dass Ihre abschließend gemeldeten Metriken eine echte Generalisierung widerspiegeln.

Testen Sie Ihr Verständnis der Konzepte des AI Engineering aus dieser Lektion.

In dieser Lektion haben Sie gelernt: die zwei unabhängigen Fehlerarten von Retrieval und Generierung, die separate Metriken erfordern, wie Sie ein Golden Dataset aus Frage-Antwort-Chunk-Tripeln für eine objektive Evaluierung erstellen, die Hit Rate als zentrale Retrieval-Metrik sowie Faithfulness und Antwortrelevanz als zentrale Generierungsmetriken und wie wichtig es ist, Metriken im Zeitverlauf zu erfassen, um Regressionen zu verhindern. Als Nächstes implementieren wir konkrete Retrieval-Metriken wie MRR und NDCG.