Ragas: Die lokale RAG-Evaluation mit chiffres

#Warum reicht „das sieht gut aus“ nicht aus?

Ragas ist eine Open-Source-Python-Bibliothek unter der Apache-2.0-Lizenz, die die Qualität einer Dokumentensuchpipeline in Zahlen ausdrückt: die Übereinstimmung der Antwort mit den bereitgestellten Passagen, ihre Relevanz für die Frage sowie Präzision und Recall des abgerufenen Kontexts. So unterscheidet sie Fehler bei der Suche von Fehlern des Modells. Sie kann mit einem lokalen Bewertungsmodell laufen, das über Ollama bereitgestellt wird, sofern dieses Modell das von Ragas vorgeschriebene strukturierte Ausgabeformat einhält und sein Kontext die gesamte Frage, die Passagen und die Antwort umfasst. Bevor Sie Ragas einsetzen, beachten Sie drei Punkte: Die Scores dienen dazu, zwei Versionen desselben Systems zu vergleichen, nicht dazu, die absolute Qualität zu bewerten; der Testdatensatz ist wichtiger als die Bibliothek; und Online-Tutorials vermischen die alte und die neue API.

Wenn eine Antwort falsch ist, verbergen sich hinter demselben Symptom zwei sehr unterschiedliche Ursachen: Entweder enthielten die abgerufenen Passagen die Information nicht, oder sie enthielten sie, aber das Modell antwortete am Thema vorbei. Die Korrektur ist jeweils eine andere – im ersten Fall müssen die Textaufteilung und die Embeddings angepasst werden, im zweiten das Modell und der Prompt. Ohne Messung korrigiert man aufs Geratewohl, und eine Verbesserung bei drei Fragen verschlechtert fünf andere, ohne dass man es bemerkt.

Die andere Falle ist der Vergleich. „Ist das Modell mit 27B Parametern hier wirklich besser?“ lässt sich entscheiden, indem man denselben Fragenkatalog erneut abarbeitet, nicht durch Diskussion. Das ermöglicht eine reproduzierbare Bewertung. Ragas hat auf GitHub über 15 000 Sterne. Die letzte auf PyPI veröffentlichte Version ist die 0.4.3 vom 13. Januar 2026, und das Repository hat seine GitHub-Organisation gewechselt (vibrantlabsai). Fixieren Sie die Version, die Sie verwenden.

#Die vier Kennzahlen, die zählen

Die Dokumentation von Ragas stellt klar, dass die Antwortrelevanz nicht die sachliche Richtigkeit bewertet: Sie misst nur, wie gut die Antwort zur Frage passt, und wertet unvollständige Antworten oder solche mit vielen unnötigen Details ab. Deshalb ersetzt sie die Quellentreue nicht. Erst die gemeinsame Betrachtung macht diese Zahlen nützlich. Ein niedriger Recall bei hoher Quellentreue beschreibt ein ehrliches, aber unzureichend mit Informationen versorgtes System: Hier muss der Informationsabruf verbessert werden. Eine geringe Quellentreue bei gutem Recall beschreibt das Gegenteil: Die Information war vorhanden, doch das Modell hat etwas hinzugedichtet. Die beiden Probleme lassen sich an entgegengesetzten Stellen der Verarbeitungskette beheben.

#Einen Testdatensatz erstellen

Das ist der Teil, der Arbeit erfordert und sich nicht ohne Folgen automatisieren lässt. Ein nützlicher Datensatz enthält Fragen, die Nutzer tatsächlich gestellt haben, mit ihren unbeholfenen Formulierungen, ihren hausinternen Abkürzungen und ihren Tippfehlern — keine Fragen, die von der Person, die die Dokumentation geschrieben hat, sauber umformuliert wurden.

1. 01
   Von echten Fragen ausgehen

   Dreißig bis fünfzig Fragen aus der tatsächlichen Nutzung sind besser als zweihundert erfundene Fragen. Nehmen Sie auch diejenigen auf, bei denen es zu Fehlern kam: Sie sind am aufschlussreichsten.
2. 02
   Die Referenzantwort schreiben

   Für jede Frage die korrekte Antwort, formuliert in einem oder zwei Sätzen. Ragas nutzt sie, um den Kontext-Recall zu schätzen: Die LLM-basierte Version verwendet diese Referenz als Ersatz für die erwarteten Textpassagen, sodass die Passagen nicht einzeln annotiert werden müssen.
3. 03
   Fälle ohne Antwort beibehalten

   Fragen, auf die das Korpus keine Antwort gibt. Ein gutes System muss das offen sagen; ohne solche Fälle wird diese Qualität nie gemessen.
4. 04
   Den Datensatz unverändert halten

   Es darf sich nicht gleichzeitig mit dem System verändern, sonst sind Vergleiche über die Zeit hinweg nicht möglich.

Ragas bietet auch eine unterstützte Generierung synthetischer Testdatensätze aus dem Korpus selbst: Die Dokumentation unterscheidet zwischen Single-Hop-Fragen (eine einzige Quelle) und Multi-Hop-Fragen (mehrere Quellen müssen miteinander verknüpft werden), die spezifisch oder abstrakt sein können. Ein offizieller Leitfaden zeigt, wie sich dies an einen nicht englischsprachigen Korpus anpassen lässt; das behandelte Beispiel ist Spanisch. So lässt sich eine erste Evaluation beginnen, bevor sich genügend echte Nutzerfragen angesammelt haben. Das ist ein praktischer Ausgangspunkt, aber niemals ein Ersatz: Ein vollständig synthetischer Testdatensatz erfasst weder unbeholfene Formulierungen noch Tippfehler, die gerade die tatsächlichen Schwächen einer Dokumentensuche aufdecken.

#Alles lokal ausführen

Ragas verwendet zur Bewertung zwei Modelle: ein Bewertungsmodell, das die Frage, die Textpassagen und die Antwort liest, und ein Embedding-Modell für Ähnlichkeitsmessungen. Der Ragas-Quickstart verwendet standardmäßig OpenAI, zeigt aber auch die Ollama-Variante: einen OpenAI-kompatiblen Client, der auf http://localhost:11434/v1 ausgerichtet ist und an die Funktion llm_factory übergeben wird. Nur die Antwortrelevanz erfordert ein Embedding-Modell: Antworttreue, Kontextpräzision und Kontext-Recall verwenden ausschließlich das Bewertungsmodell.

Zwei Voraussetzungen müssen erfüllt sein, damit ein lokaler Bewerter glaubwürdig ist. Die erste ist die strukturierte Ausgabe: Die aktuellen Metriken verlangen vom Bewerter Zwischenentscheidungen in einem vorgegebenen Format (Extraktion von Behauptungen, Bewertungen). Ein lokales Modell kann in Prosa antworten und diese Vorgaben verfehlen, was zu JSON-Fehlern oder leeren Scores (NaN) führt; ein Leitfaden von OneUptime empfiehlt, den Bewerter vor jeder Testreihe mit einem sehr kleinen Aufruf zu testen. Keine offizielle Quelle legt eine Mindestgröße für das Modell fest: Sie müssen selbst prüfen, ob es geeignet ist. Die zweite Voraussetzung ist der Kontext: Ollama verwendet bei weniger als 24 GiB VRAM standardmäßig einen Kontext von 4.000 Tokens, und die Dokumentation empfiehlt, den Wert (Variable OLLAMA_CONTEXT_LENGTH) für anspruchsvolle Aufgaben zu erhöhen. Ein Bewerter, dessen Kontextfenster überschritten wird, bewertet in Wirklichkeit einen abgeschnittenen Text.

• Die RAG-Kette aufbauen, die Sie bewerten werden
• Ein Modell für französische Embeddings auswählen
• Einen Reranker hinzufügen, wenn die Kontextpräzision gering ist
• Langfuse: Aufzeichnen und Speichern der erzielten Scores

# pip install ragas openai
from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.metrics.collections import Faithfulness, ContextRecall

# Client compatible OpenAI pointé sur Ollama (la clé est un simple libellé)
client = AsyncOpenAI(api_key="ollama", base_url="http://localhost:11434/v1")
juge = llm_factory("mistral", provider="openai", client=client)  # nom du modèle tiré avec ollama pull

fidelite = Faithfulness(llm=juge)
resultat = fidelite.score(
    user_input="Où se trouve la tour Eiffel ?",
    response="La tour Eiffel se trouve à Paris.",
    retrieved_contexts=["La tour Eiffel est située à Paris, en France."],
)
print(resultat.value)  # entre 0 et 1

#Die Ergebnisse richtig lesen

Das sind Indikatoren, keine Bewertungen

Eine Quellentreue von 0,82 bedeutet nicht „82 % richtige Antworten“. Dieser Wert dient dazu, zwei Versionen desselben Systems zu vergleichen, nicht dazu, eine absolute Qualität zu bescheinigen.

Der Bewerter weist Verzerrungen auf

Der Referenzartikel zu LLMs als Bewertern (arXiv 2306.05685) beschreibt Verzerrungen durch die Position, die Ausführlichkeit und die Bevorzugung eigener Antworten. Verwenden Sie von einer Evaluationskampagne zur nächsten denselben Bewerter, sonst messen die Unterschiede den Bewerter und nicht das System.

Eine einzige Kampagne beweist nichts

Die Textgenerierung schwankt. Bei einem kleinen Testdatensatz kann eine Abweichung von wenigen Hundertsteln auf Rauschen zurückzuführen sein.

Lesen Sie einige Beispiele manuell

Die Zahlen zeigen, wo man hinschauen sollte; sie sagen nicht, was nicht stimmt. Aus den zehn schlechtesten Fällen einer Auswertung lernt man mehr als aus dem Gesamtdurchschnitt.

#Konkrete Anwendungsfälle

Eine Abschnittsgröße wählen

Denselben Testsatz mit Abschnitten von 256, 512 und anschließend 1024 Tokens erneut durchlaufen zu lassen, liefert einen Recall-Wert pro Konfiguration statt einer ungeprüften Präferenz.

Eine Änderung des Embedding-Modells validieren

Ein neues Embedding-Modell kann die Genauigkeit des Kontexts bei Ihrem konkreten Korpus verschlechtern, selbst wenn es laut Ankündigung bei einem allgemeinen Benchmark besser abschneidet; nur eine lokale Testreihe zeigt dies.

Das Hinzufügen eines Rerankers begründen

Ein Vergleich der Kontextpräzision vor und nach dem Reranking beziffert einen Zugewinn, der sonst nur ein in einer Besprechung geteilter Eindruck bleibt.

Eine Regression nach einer Aktualisierung des Korpus verfolgen

Die Hinzufügung neuer Dokumente kann die Suche verdrängen; das Wiederholen des festen Testsets nach jedem Import erkennt die Abnahme bereits vor dem Zeitpunkt, an dem ein Benutzer sie bemerkt.

Wahl zwischen zwei Anbietern oder Architekturen

Bei zwei konkurrierenden Vorschlägen für den Aufbau derselben Dokumentenverarbeitungspipeline ermöglicht ein auf demselben Testdatensatz und demselben Korpus erzielter Score eine schnellere Entscheidung als eine Verkaufsdemo.

#Kampagnen organisieren

Frequenz der Kampagnen

Nach jeder Änderung der Aufteilung, des Embedding-Modells oder des Generierungsmodells. Bei einem stabilen System ist keine tägliche Evaluierungskampagne nötig.

Größe des Testkorpus

Der Fragenkatalog bleibt klein; der evaluierte Dokumentenkorpus hingegen muss eine realistische Kopie des Produktionskorpus sein – oder diesen vollständig umfassen.

Tatsächliche Kosten einer Evaluierungskampagne

Jede Metrik ruft das Bewertungsmodell mehrmals auf (für die Antworttreue: Extraktion der Aussagen, dann Überprüfung jeder einzelnen Aussage). Die Kosten steigen daher mit der Anzahl der Fragen multipliziert mit der Anzahl der Metriken: Messen Sie die benötigte Zeit für fünf Fragen, bevor Sie alle fünfzig auswerten lassen, und planen Sie die Auswertung entsprechend.

#Grenzen der Methode

Mit einem Modell zu evaluieren bedeutet, eine künstliche Intelligenz eine andere künstliche Intelligenz beurteilen zu lassen: Die Methode ist nützlich, kostengünstig und unvollkommen. Sie erkennt Regressionen und ordnet Varianten nach ihrer Qualität; sie ersetzt keine menschliche Prüfung in einem Bereich, in dem viel auf dem Spiel steht und sachliche Fehler Verantwortungsfragen aufwerfen. Schließlich benötigt jede Evaluierungskampagne Rechenzeit: Auf einem Rechner, der auch Nutzer bedient, startet man sie bei geringer Auslastung, nachts oder am Wochenende statt mitten in der Hauptnutzungszeit.

Die Bevorzugung ausführlicher Antworten verdient etwas mehr Erklärung, weil sie kontraintuitiv ist. Ein Artikel von OneUptime erklärt, dass ein Bewertungsmodell in einer langen Antwort mehr Gelegenheiten hat, die Schlüsselwörter des Bewertungsrasters zu nennen, umfassend zu wirken und eine überzeugende Begründung anzuführen. Ein Prompt, der das bewertete Modell zu ausführlicheren Antworten anregt, kann daher den Score erhöhen, ohne die Antwort für den Nutzer zu verbessern. Für die Quellentreue erwähnt die Ragas-Dokumentation außerdem eine Variante auf Basis von HHEM-2.1-Open, einem kleinen, kostenlosen Klassifikator von Vectara zur Erkennung von Halluzinationen: Er ersetzt den Überprüfungsschritt durch ein spezialisiertes Modell. Diese Variante können Sie ausprobieren, wenn Ihr lokales Bewertungsmodell instabil ist.

Die einfachste Gegenmaßnahme ist methodischer Natur: Niemals einen mit einem Bewerter ermittelten Faithfulness-Score mit einem Score vergleichen, der mit einem anderen Bewerter ermittelt oder von einem Dritten veröffentlicht wurde. Die Zahl ist nur innerhalb derselben Messkonfiguration aussagekräftig – derselbe Bewerter, derselbe Bewertungs-Prompt, dieselbe Version der Metriken. Es handelt sich um ein Werkzeug für interne Vergleiche, nicht um eine universelle Rangliste.

• Quelle: offizielles Ragas-Repository auf GitHub
• Quelle: Bevorzugung ausführlicher Antworten durch automatische Bewerter
• Quelle: offizielle Dokumentation zur Faithfulness-Metrik
• Quelle: Ragas-Quickstart, Ollama-Variante
• Quelle: Standardkontextlänge von Ollama
• Quelle: Ein RAG-System mit einem lokalen Bewerter evaluieren, der ungültiges JSON erzeugt
• Quelle: Referenzartikel zu LLMs als Bewertern

#FAQ