RAG-Evaluation: Ragas vs. DeepEval vs. TruLens vs. LangSmith

Automatische Übersetzung

Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

Ein einzelner Score kann nicht erklären, ob ein Retrieval-Augmented-Generation-(RAG-)System funktioniert. Fehler können beim Parsen von Dokumenten, beim Aufteilen in Chunks, beim Retrieval oder Reranking von Evidenz, bei der Generierung einer Antwort, beim Hinzufügen von Zitationen oder bei der Anwendung von Filtern auftreten. Messe jede Phase separat, damit eine Regression auf einen bestimmten Teil der Pipeline zurückgeführt werden kann.

Beginne mit Retrieval-Metriken auf einem kleinen gelabelten Dataset. Wähle ein Tool für die Funktionen, die deinem bestehenden Test Runner fehlen. Ragas bietet RAG-Metriken, DeepEval bietet Prüfungen im Stil von Tests, und TruLens ordnet einzelnen Ausführungen Feedback zu. LangSmith ist eine weitere Option, wenn du Traces und Datasets gemeinsam verwalten möchtest. Ergänze eigene Prüfungen für produktspezifische Fehler.

Wähle nach den benötigten Metriken, der Integration in den Test Runner, der Prüfung von Traces und den zulässigen Verarbeitungsorten für Evaluationsdaten.

Entscheidungstabelle

BedarfAusgangspunktWarum
Günstige Regressionsprüfungen für RetrievalLokale MetrikenRecall@k, MRR, nDCG, fälschliche Ausschlüsse durch Filter sowie die Gültigkeit von Zitations-IDs und zitierten Textstellen können feste Labels oder Regeln verwenden.
RAG-MetrikbibliothekRagasBietet Context Precision, Context Recall, Response Relevancy, Faithfulness und verwandte Metriken.
CI-Prüfungen für LLM-AnwendungenDeepEvalDie Schnittstelle im Stil von Testfällen eignet sich gut, wenn Evals einen PR oder ein Deployment fehlschlagen lassen sollen.
Erklärbares App-FeedbackTruLensDie RAG Triad trennt Context Relevance, Groundedness und Answer Relevance.
Trace-zentrierte Produkt-EvalsLangSmithDatasets, Evaluators, Annotationen, Traces und Regression-Workflows befinden sich an einem Ort.
Domänenspezifische QualitätEigene EvalsGenerische Metriken kennen deine Ontologie, Filter, Zitationsregeln, Parser-Einschränkungen oder Ablehnungsregeln nur selten.

Metriken nach Pipeline-Phase

PhaseErste hinzuzufügende MetrikenWarum
ParsingVollständigkeit der Extraktion, Erhalt von Tabellen, SeitenabdeckungEin Retriever kann keinen Text liefern, den der Parser ausgelassen hat.
ChunkingBeantwortbarkeit anhand eines Chunks, Verluste an Chunk-Grenzen, DuplikatrateDurch das Aufteilen zusammengehöriger Fakten kann Retrieval nicht genügend Kontext finden.
RetrievalRecall@k, MRR, nDCG@k, Context Precision, Context RecallPrüfe, welche erwarteten Quellen das Model für die Antwort erreichen.
RerankingPrecision@1, Änderung von nDCG, zusätzliche LatencyBehalte einen Reranker, wenn die bessere Reihenfolge die zusätzliche Runtime rechtfertigt.
GenerationFaithfulness, Groundedness, Answer RelevanceFaithfulness prüft die Unterstützung durch den Kontext; Answer Relevance prüft, ob die Antwort die Frage adressiert.
ZitationenAbdeckung von Aussagen, Belege durch Zitationen, Anteil unbelegter AussagenEine durch Quellen belegte Antwort kann für das Produkt trotzdem fehlschlagen, wenn die Zitationen nicht nützlich sind.
ProductionRate der Ersatzverfahren, Korrekturrate, p95-Latency, Kosten pro AntwortOffline-Qualität ist ohne operative Telemetrie unvollständig.

Hinweise zu den Tools

Recall@k misst, wie viele als relevant gelabelte Einträge unter den ersten k Ergebnissen erscheinen. MRR misst den Rang des ersten relevanten Eintrags; nDCG berücksichtigt auch unterschiedliche Relevanzstufen. Diese Retrieval-Metriken benötigen Relevanzlabels. Ein LLM Judge, der eine Antwort als konsistent mit dem Kontext bewertet, kann sie nicht ersetzen.

Ragas bietet Metriken für Context Precision, Context Recall, Faithfulness und Response Relevance. Sein Context Recall benötigt eine Referenzantwort oder Referenzkontexte. Für Context Precision gibt es Varianten mit und ohne Referenzen. Faithfulness prüft die Antwort gegen den abgerufenen Kontext; eine Referenzantwort ist dafür nicht erforderlich. Prüfe vor der Vorbereitung eines Datasets, welche Eingaben jede Metrik benötigt. Kalibriere Model Judges anhand geprüfter Beispiele und dokumentiere ihre Prompts, Model-Versionen und Kosten.

DeepEval passt zu Engineering-Workflows, in denen sich Evaluation wie Tests verhalten soll. Es eignet sich für CI-Regressionsprüfungen, insbesondere für bekannte Fehlerfälle. Zu beachten ist, dass Evals im Stil von Tests nur so gut sind wie die Fälle, die du pflegst.

TruLens eignet sich gut, wenn du Feedback-Funktionen an Anwendungsdaten binden möchtest. Die RAG Triad ist nützlich, weil sie Context Relevance, Groundedness und Answer Relevance getrennt hält, statt sie in eine undurchsichtige Zahl zu komprimieren.

LangSmith ist praktisch, wenn deine Traces, Runs, Datasets und dein Review-Workflow bereits im LangChain-/LangGraph-Ökosystem liegen. Es unterstützt auch andere Frameworks. Ein lokaler Runner kann einfacher sein, wenn sämtliche Evaluation-Daten und die Ausführung auf deiner Maschine bleiben müssen.

Ergänze eigene Prüfungen für Anforderungen, die generische Metriken nicht abdecken. Wenn dein RAG-System Dokumente nach Berechtigung, Rechtsraum, Datum, Produktlinie oder Ontologie filtert, miss fälschliche Ausschlüsse und Fehler bei der Anwendung von Regeln direkt.

Ein sinnvoller erster Stack

  1. Erstelle ein Referenzset, das wichtige Abfragegruppen und die erwarteten Quellen-IDs abdeckt. Einige Dutzend Fälle können frühe Regressionen sichtbar machen; erweitere das Set, bis Konfidenzintervalle und Abdeckung von Fehlerfällen die Release-Entscheidung unterstützen.
  2. Erfasse deterministische Retrieval-Metriken lokal, bevor du LLM Judges hinzufügst.
  3. Wähle eine Bibliothek oder Plattform, wenn du einen Groundedness Judge, Test-Integration oder Trace Review benötigst, die dein Runner nicht bietet.
  4. Verwende sie zusammen mit eigenen Prüfungen für Filter, Zitationen, Parser-Qualität und Ablehnungsverhalten.
  5. Speichere Ergebnisse und prüfe Stichproben. Füge ein weiteres Tool erst hinzu, wenn du eine fehlende Funktion konkret benennen kannst.

Zu prüfen, ob eine Zitations-ID existiert oder eine zitierte Textstelle vorkommt, ist ein deterministischer Test. Er beweist nicht, dass die Quelle die Aussage tatsächlich unterstützt. Dafür solltest du geprüfte Aussage-Quelle-Labels oder einen kalibrierten semantischen Judge verwenden. Wie die TruLens RAG Triad unterscheidet, kann eine Antwort die Frage adressieren und dennoch keine Unterstützung im bereitgestellten Kontext haben.

Ein häufiger Fehler

Höre nicht nach der Messung von Faithfulness auf. Faithfulness stellt eine enge Frage: Stimmt die Antwort mit dem abgerufenen Kontext überein? Die Metrik kann nicht feststellen, ob der Retriever die richtige Quelle gefunden hat. Außerdem erkennt sie verlorene Tabellen, fehlerhafte Berechtigungsfilter und Zitationen, die auf die falsche Passage verweisen, nicht.

Weiterführende Lektüre

Referenzen