Ragas-Review: der Standard fur RAG-Evaluation

Ragas ist eine Apache-2.0-Python-Bibliothek zur Bewertung von LLM-Anwendungen und inzwischen die Sprache, in der man sich uber RAG-Evaluation streitet: Faithfulness, Context Precision und Context Recall stammen alle aus ihrem Metrik-Set. Als erstes Bewertungswerkzeug fur eine Retrieval-Pipeline ist sie sehr nutzlich, als Produktions-Monitoring ist sie praktisch wertlos, denn sie berechnet Zahlen uber einen Datensatz, den man ihr reingibt, und uberlasst Speicherung, Dashboards, Sampling und Alerting jemand anderem.

Sie liegt zwischen dem Retrieval-Stack und dem Build: nachdem LlamaIndex, LangChain oder ein selbst geschriebener Retriever Antworten erzeugt, bewertet Ragas sie, und die Zahlen landen neben dem Commit. Konkurrenz sind DeepEval, TruLens und Phoenix sowie die Eval-Features in Langfuse, LangSmith und Braintrust; der Unterschied: Ragas bleibt eine Bibliothek, ohne Dienst zum Betreiben und ohne Anbieter, der die Testdaten hait.

Was es ist

Das Paket installiert sich mit pip install ragas von PyPI und lauft im Prozess; Version 0.4.3 erschien am 13. Januar 2026 und verlangt Python 3.9 oder neuer. Metriken gibt es in zwei Formen: LLM-basiert, wobei ein Judge-Modell eine Zeile liest und einen Wert mit schriftlicher Begrundung zuruckliefert, und klassisch, wo Zeichenketten direkt verglichen werden, etwa BLEU, ROUGE, Exact Match und Semantic Similarity. Darum herum gibt es einen Experiments-Workflow, Datensatz, Lauf, Aufzeichnung, Vergleich, der aus einer Sammlung von Metrikfunktionen eine wiederholbare Evaluation macht.

• Lizenz und Tragerschaft: Apache-2.0, betreut von VibrantLabs; das Repository zeigt etwa 16.000 Stars und 1.700 Forks.
• RAG-Metriken: Context Precision, Context Recall, Context Entities Recall, Noise Sensitivity, Response Relevancy und Faithfulness, dazu multimodale Varianten von Faithfulness und Relevance.
• Agenten-Metriken: Tool Call Accuracy, Tool Call F1, Agent Goal Accuracy und Topic Adherence.
• Belegung und Vergleich: Factual Correctness, Semantic Similarity, BLEU, CHRF, ROUGE, String Presence und Exact Match.
• SQL und Zusammenfassung: ausfuehrungsbasierter DataCompy-Score, SQL-Query-Äquivalenz und ein Summarisation Score.
• Testdaten und Geruest: synthetische Testset-Generierung aus eigenen Dokumenten sowie eine ragas quickstart rag_eval-Vorlage, die ein lauffahiges Projekt schreibt.
• Ausgabe: Experiment-Ergebnisse als CSV-Dateien im Repository, diffbar wie jedes andere Build-Artefakt.

Wie es funktioniert

Ein Lauf arbeitet die Zeilen nacheinander ab. Jede Zeile enthalt die Nutzereingabe, die Antwort der Anwendung und den Kontext, den der Retriever geliefert hat. Eine Metrik nimmt diese Zeile, macht einen oder mehrere LLM-Aufrufe mit einem Prompt, das das Kriterium genau benennt, und liefert einen Wert samt Begrundung des Judges; klassische Metriken uberspringen den Aufruf und vergleichen Zeichenketten. Zeilen werden unabhangig bewertet, das heisst, der Satz parallelisiert sauber, und eine einzelne Zeile laisst sich wiederholen, wenn der Mittelwert falsch aussieht.

Dass sich diese Art der Evaluation durchgesetzt hat, liegt an der Lesbarkeit der Ausgabe. Ein niedriger Faithfulness-Score kommt mit dem Satz, den der Judge uber den nicht gestutzten Behauptung geschrieben hat, also mit einem Diff, auf den ein Mensch reagieren kann, statt mit einer Zahl zum Streiten.

Erste Schritte

Der kleinste sinnvolle Test ist eine Metrik auf einer Zeile, und so stellt die README die Bibliothek auch vor.

import asyncio
from ragas.metrics.collections import AspectCritic
from ragas.llms import llm_factory

# The judge: llm_factory() takes OpenAI by default, Anthropic and others as options
llm = llm_factory("gpt-4o")

metric = AspectCritic(
    name="summary_accuracy",
    definition="Verify if the summary is accurate and captures key information.",
    llm=llm,
)

row = {
    "user_input": "summarise given text: the company reported an 8% rise in Q3 2024.",
    "response": "The company saw an 8% increase in Q3 2024.",
}

async def main():
    score = await metric.ascore(user_input=row["user_input"], response=row["response"])
    print(score.value, score.reason)

asyncio.run(main())

Fur ein ganzes Projekt ist das Geruest schneller: uvx ragas quickstart rag_eval schreibt ein Paket mit rag.py, evals.py, einem Datasets- und einem Experiments-Ordner, uv sync installiert es, und uv run python evals.py laadt den Datensatz, fragt die Anwendung ab, bewertet jede Zeile und hangt das Ergebnis ans CSV an. Die Dokumentation setzt die Vorlage standardmassig auf OpenAI und zeigt dieselben drei Zeilen umgestellt auf Anthropic, Google Gemini, Ollama oder eine beliebige OpenAI-kompatible Endpunkt-Adresse.

Performance und Kosten

Ragas bringt dem Produkt keine Latenz; es bringt dem Build Kosten und Wandzeit. Die Rechnung ist Zeilen mal Metriken mal Judge-Aufrufe pro Zeile, und die teuren Metriken sind die, die eine Antwort in Behauptungen zerlegen und jede einzeln prufen.

Ein Datensatz mit 500 Zeilen und vier LLM-Metriken bedeutet pro Lauf tausende Judge-Aufrufe. Teams drosseln das mit Caching, wo die Bibliothek es zulasst, mit einem kleinen Judge-Modell fur die billigen Metriken und mit einem vollen Lauf nur kurz vor dem Merge.

• Die billigen Metriken bei jedem Push bewerten; Faithfulness und die Agenten-Metriken beim Merge oder auf Zeitplan laufen lassen.
• Den Datensatz klein und adversarial halten statt gross und zufallig: 200 Zeilen, die schon einmal versagt haben, schlagen 5.000 Zeilen, die nie versagen.
• Synthetische Zeilen fur Abdeckung erzeugen und danach einfrieren; das Testset in jedem Zyklus neu zu erzeugen, laisst jedes Ergebnis wie Rauschen aussehen.

Nichts davon ist Ragas-spezifisch: jede LLM-as-a-Judge-Konstruktion rechnet pro Aufruf ab und erbt die Blindstellen des Judges. Ragas entscheidet, wie viel dieser Mechanik man gratis bekommt und wie viel man drumherum selbst bauen muss.

Preise

Die Bibliothek ist frei und Apache-2.0, ohne Seat-Zahl und ohne Nutzungslimite. Die kommerzielle Seite, die gehostete Plattform und direkter Support, wird von den Betreuern per Kontakt und Office Hours verkauft, und dafur gibt es keinen publizierten Preislist. Die Kosten, die also zaehlen, sind das Judge-Modell: jede LLM-Metrik wird von dem Provider abgerechnet, auf den man sie zeigt, und die synthetische Testset-Generierung lauft auf demselben Zaehler.

• Bibliothek: frei, Apache-2.0, Installation von PyPI, kein Konto noetig.
• Judge-Modell: pro Aufruf beim Provider berechnet, typischerweise die groesste Posten eines Eval-Budgets.
• Synthetische Testdaten: ebenfalls LLM-Arbeit, genau wie das Scoring abgerechnet.
• Gehostete Plattform und Support: direkt verkauft, kein oeffentlicher Preis; vor der Zusage klaeren, was enthalten ist.

Wo es scheuert

Ragas bewertet Zeilen, keine Systeme. Es zieht keinen Produktionsverkehr, speichert keine Traces und sagt nicht, wenn sich p95-Latenz verschoben hat, und es kann nicht sagen, ob die Testfragen reprasentativ sind, genau der Fehler, der eine grune Pipeline nutzlos macht. Das Release-Tempo ist hoch, 0.3.0 im Juli 2025, 0.4.0 im Dezember 2025, 0.4.3 im Januar 2026, Versionen mussen also gepinnt werden. Zum Zeitpunkt der Recherche hatte das Repository 381 offene Issues, der uebliche Preis dafur, der Standard zu sein, und die Dokumentation von stable hinterhergehinkt.

Die eigentliche Entscheidung ist, wo die Zahlen wohnen. Ragas ist die richtige Motorik, wenn etwas anderes die Laufe speichert, ein CSV im Repository, eine Tabelle im Warehouse, ein Observability-Werkzeug, das importierte Scores annimmt. Das falsche Produkt fur ein Team, das eine URL oeffnen will und sehen will, ob die Qualitat zurueckgegangen ist.

Fazit

Ragas verdient seinen Status als Standard fur Retrieval-Arbeit: die Metriken sind sauber definiert, die Ausgabe liefert Begruendungen, und ein Projekt ist einen Befehl entfernt. Man sollte es als Scoring-Motor in einen Workflow nehmen, den man ohnehin besitzt, nicht als Evaluations-Plattform.

1. Nutzen, wenn eine Retrieval-Pipeline existiert und noch kein Golden Set: synthetische Testset-Generierung plus referenzfreie Metriken liefert am ersten Tag einen ersten Messwert.
2. Nutzen, wenn Evaluation im CI laufen muss, wo ein CSV-Diff pro Pull Request genau die richtige Menge an Signal ist.
3. Nicht waehlen als einziges Evaluationswerkzeug fur ein Agenten-Produkt: Agenten-Metriken gibt es, aber Trajektorien, Werkzeug-Nebenwirkungen und Kosten pro Aufgabe brauchen einen Harness, der Laufe speichert.
4. Nicht waehlen, wenn eine Antwort gegenueber Regulator oder Kunde aus gespeicherten Belegen begruendet werden muss; gespeichert wird nichts, was man nicht selbst speichert.
5. Das Judge-Modell vor der Lizenz budgetieren: ein gepinntes kleines Modell fur die billigen Metriken und ein faehiges fur Faithfulness ist die uebliche Aufteilung.

Ragas ist der billigste Weg, aufzuhoren, daruber zu streiten, ob eine Änderung geholfen hat: Judge festschreiben, Zeilen einfrieren, den Diff lesen. Alles, was es nicht tut, ist Arbeit, die man trotzdem bezahlen muss.

Quellen

1. Ragas-Dokumentation: Einfuhrung
2. Ragas-Dokumentation: Quick Start
3. Ragas-Dokumentation: verfugbare Metriken
4. Ragas auf GitHub
5. Ragas auf PyPI
6. Ragas-Webseite