Evidently: Reports, Test Suites und ein Monitoring-UI für ML- und LLM-Pipelines
Evidently is an open-source ML and LLM observability framework. Evaluate, test, and monitor any AI-powered system or data pipeline. From tabular data to Gen AI. 100+ metrics.
Auf einen Blick
- Was ist das?
- Evidently ist eine Python-Bibliothek, die tabellarische Daten und LLM-Ausgaben mit über 100 Metriken bewertet, aus jedem Report eine Test Suite mit Pass/Fail-Bedingungen macht und optional ein eigenes Monitoring-UI startet. Die Stärke liegt in der Modularität, die Grenze in der Datenhaltung.
- Für wen ist es gedacht?
- Sinnvoll ist Evidently für Teams, die Daten-Drift und LLM-Ausgaben in Notebooks oder in einer CI-Stufe prüfen wollen und die Auswertung selbst speichern. Wer eine fertige Plattform mit Alerting, Nutzerverwaltung und ohne Betriebsaufwand sucht, sollte zuerst die OSS-gegen-Cloud-Gegenüberstellung in der Dokumentation lesen und prüfen, ob die selbst gehostete UI die benötigten Funktionen überhaupt enthält.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Jupyter Notebook, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Evidently adressiert
Modelle und Prompts verändern sich, die Eingabedaten ebenfalls. Evidently setzt an der Stelle an, an der diese Veränderung sichtbar wird: bei den Daten und den Ausgaben. Das Projekt beschreibt sich selbst als Open-Source-Framework zum Evaluieren, Testen und Überwachen von ML- und LLM-Systemen, von Experimenten bis zum Produktivbetrieb. Der Anwendungsbereich reicht laut README von tabellarischen Daten bis zu generativen Aufgaben wie RAG.
Die Zielgruppe sind nicht Endanwender, sondern Menschen, die Pipelines bauen: Data-Science- und ML-Engineering-Teams, die nach dem Training weiter Verantwortung für ein Modell tragen. Für sie ist die relevante Frage nicht, ob ein Modell einmal gut abgeschnitten hat, sondern ob sich die Verteilung der Eingaben verschoben hat und ob die Antworten eines Sprachmodells noch den Erwartungen entsprechen. Evidently liefert dafür einen Baukasten statt einer fertigen Plattform. Das ist die zentrale Designentscheidung des Projekts und erklärt sowohl die Flexibilität als auch die offenen Enden.
Report, Dataset und Descriptor: der Datenfluss
Die Architektur besteht aus wenigen, klar getrennten Objekten. Ein Report ist eine Sammlung von Metriken oder Presets, die auf Daten ausgeführt werden. Ein Dataset ist die Evidently-eigene Hülle um einen pandas-DataFrame, ergänzt um ein DataDefinition-Objekt, das beschreibt, welche Spalten welche Rolle spielen, und um Descriptors. Descriptors sind zeilenweise Auswerter: Sie erzeugen pro Datensatzzeile einen Wert, der anschließend im Report als Verteilung erscheint.
Das README zeigt das an einem LLM-Beispiel. Ein DataFrame mit den Spalten question und answer wird über Dataset.from_pandas in ein Dataset überführt. Als Descriptors kommen Sentiment auf der Spalte answer, TextLength auf derselben Spalte und Contains mit den Suchbegriffen sorry und apologize im Modus any hinzu. Danach liefert eval_dataset.as_dataframe() den DataFrame mit den angehängten Bewertungen, und ein Report mit dem Preset TextEvals fasst die Verteilung dieser Werte zusammen. Der Ablauf ist also zweistufig: erst Zeilenbewertung, dann Aggregation im Report.
Für tabellarische Daten ist der Weg kürzer. Im Iris-Beispiel wird ein Report mit DataDriftPreset(method="psi") erzeugt und mit include_tests="True" ausgeführt. Als current dienen die ersten 60 Zeilen, als reference der Rest. Damit ist auch das Referenzkonzept benannt: Drift wird relativ zu einem Referenzdatensatz gemessen, nicht absolut. Wer keinen sauberen Referenzstand hat, bekommt hier kein sinnvolles Ergebnis.
Von der Auswertung zum Pass/Fail-Test
Der interessanteste Teil des Designs ist die Umwandlung eines Reports in eine Test Suite. Laut README lässt sich jeder Report durch das Hinzufügen von Pass/Fail-Bedingungen in eine Test Suite überführen. Die Bedingungen werden über Operatoren wie gt (greater than) und lt (less than) formuliert. Damit wird aus einer explorativen Analyse ein prüfbares Artefakt, das sich in CI/CD-Stufen oder Datenvalidierung einsetzen lässt.
Bemerkenswert ist die Option, Testbedingungen automatisch aus dem Referenzdatensatz abzuleiten. Das README nennt sie einen Zero-Setup-Weg. Der Vorteil ist offensichtlich: Man muss sich keine Schwellenwerte ausdenken, bevor man die Datenverteilung überhaupt kennt. Der Nachteil ist genauso offensichtlich und wird im Material nicht aufgelöst. Automatisch abgeleitete Schwellen erben jede Eigenheit der Referenzstichprobe. Ist der Referenzdatensatz klein oder nicht repräsentativ, schlagen die Tests entweder ständig fehl oder nie an. Wer diesen Weg wählt, sollte die generierten Bedingungen als Ausgangspunkt lesen und nicht als fertige Qualitätsdefinition.
Die Ausgabeformate sind breit: Der Report lässt sich im Notebook anzeigen und als JSON, Python-Dictionary oder HTML exportieren. Im Iris-Beispiel erzeugt save_html("file.html") eine Datei, die aus dem Zielordner heraus geöffnet wird. Das ist praktisch für Weitergabe, aber es ist ein statischer Schnappschuss. Wer Verläufe sehen will, braucht das Monitoring-UI.
Installation und Start des Monitoring-UI
Die Installation ist unspektakulär. Aus PyPI mit pip install evidently, alternativ über conda install -c conda-forge evidently. Für das UI nennt das README zwei Wege. Mit uv genügt ein Befehl: uv run --with evidently evidently ui --demo-projects all. Ohne uv wird eine virtuelle Umgebung angelegt, danach evidently installiert und der Dienst mit evidently ui --demo-projects all gestartet. Erreichbar ist er unter localhost:8000.
Der Schalter --demo-projects all ist ein Detail, das man nicht überlesen sollte. Er lädt Demo-Projekte in die lokale Instanz. Das ist für eine erste Orientierung gedacht, nicht als Produktionskonfiguration. Wer eigene Daten über die UI auswerten will, muss den Dienst ohne diese Beispieldaten betreiben und die Daten selbst einspeisen. Wie das im Detail geht, lässt sich aus dem vorliegenden README nicht ableiten; dafür verweist das Projekt auf die Dokumentation unter docs.evidentlyai.com.
Für die Nutzung ohne UI ist keine Serverkomponente nötig. Ein Report läuft im Notebook oder in einem Skript, das Ergebnis ist ein Python-Objekt. Das ist der Pfad mit der geringsten Betriebslast und für viele Teams der einzig notwendige.
Wo Evidently an seine Grenzen stößt
Die Bibliothek ist ausdrücklich modular, und Modularität bedeutet hier: Ein Teil der Verantwortung bleibt beim Nutzer. Das selbst gehostete UI ist ein Dienst, der betrieben, aktualisiert und mit Daten versorgt werden muss. Das README nennt ihn eine Option und empfiehlt daneben Evidently Cloud mit Funktionen wie Dataset- und Nutzerverwaltung, Alerting und No-Code-Evals. Die Existenz dieser Empfehlung ist ein ehrlicher Hinweis darauf, wo die Open-Source-Version aufhört.
Ein zweiter Punkt betrifft die Datenhaltung. Referenzdaten sind die Grundlage jeder Drift-Messung. Evidently liefert Metriken und Tests, aber keine Aussage darüber, welcher Referenzstand der richtige ist und wann er neu eingefroren werden muss. Diese Entscheidung ist inhaltlich und nicht technisch, und sie ist meistens die schwierigere.
Drittens: Wer eine vollständige Observability-Plattform mit Tracing über einzelne LLM-Aufrufe, Kostenverfolgung und Prompt-Versionierung sucht, findet hier einen anderen Schwerpunkt. Evidently bewertet Daten und Ausgaben anhand von Metriken und Descriptors. Es ist kein Tracing-Backend für einzelne Anfragen.
Schließlich die Sprache. Das Repository ist als Jupyter Notebook ausgewiesen. Das sagt nichts über die Qualität der Bibliothek aus, aber es bedeutet, dass die Beispiele und Teile der Dokumentation notebook-förmig sind. Wer Evidently in eine bestehende Python-Anwendung einbettet, muss den Code aus dem Notebook-Kontext herauslösen.
Der Unterschied zu einem reinen pandas-Check
Die naheliegende Alternative ist kein anderes Observability-Produkt, sondern eigener Code: ein paar pandas-Zeilen, die Mittelwerte vergleichen, und ein assert in der Pipeline. Der Unterschied liegt nicht in der Rechenleistung, sondern in der Struktur. Evidently bringt benannte Presets wie DataDriftPreset und TextEvals mit, dazu über 100 eingebaute Metriken und eine Schnittstelle für eigene. Ein selbst geschriebener Check liefert eine Zahl; Evidently liefert einen Report mit Verteilungen, den man als HTML weitergeben oder als JSON in ein anderes System einspeisen kann.
Der zweite Unterschied ist die Testschicht. Eigener Code prüft meist genau die Bedingung, an die man beim Schreiben gedacht hat. Die Test Suite von Evidently erlaubt es, denselben Report unter mehreren Bedingungen laufen zu lassen und die Bedingungen aus dem Referenzdatensatz zu generieren. Das verschiebt den Aufwand von der Implementierung zur Interpretation der Ergebnisse.
Wer bereits eine Plattform für Modell-Monitoring im Einsatz hat, wird Evidently eher als Metrik-Schicht denn als Ersatz betrachten. Das README nennt eine offene Architektur und den Export von Daten als Ziel, was diesen Einsatz als Zulieferer ausdrücklich vorsieht.
Pflege, Versionen und Lizenz
Die Release-Historie im vorliegenden Material zeigt drei Veröffentlichungen: v0.7.19 im Januar 2026, v0.7.20 ebenfalls im Januar 2026, v0.7.21 im März 2026. Der letzte Push ins Repository datiert auf August 2026. Die Versionsnummern bleiben im 0.7-Zweig, es gibt also keine stabile 1.x-Linie. Für adoptierende Teams heißt das: Die öffentliche API kann sich zwischen Minor-Releases ändern. Wer die Bibliothek in eine Produktionspipeline einbaut, sollte die Version pinnen und Upgrades als eigenen Arbeitsschritt behandeln, nicht als Nebenwirkung einer Installation.
Die Lizenz ist Apache-2.0. Das ist eine permissive Lizenz, die kommerzielle Nutzung, Veränderung und Weitergabe erlaubt und eine Klausel zu Patenten enthält. Wer Evidently in ein eigenes Produkt einbettet, muss die Bedingungen der Lizenz selbst prüfen; das README und die Repository-Metadaten ersetzen keine Rechtsberatung. Wichtig für die Planung: Das Open-Source-Projekt und Evidently Cloud sind zwei getrennte Angebote. Die Dokumentation enthält eine eigene Seite, die beide gegenüberstellt. Diese Seite ist die erste Stelle, an der sich klären lässt, ob die selbst gehostete Variante die benötigten Funktionen abdeckt.
Ein Kostenfaktor, der leicht übersehen wird, ist der Betrieb des UI. Ein lokal gestarteter Dienst ist kein Monitoring. Dauerhafte Auswertung braucht einen Ort, an dem die Metriken über die Zeit liegen, und jemanden, der diesen Ort wartet.
Redaktionelles Fazit
Sinnvoll ist Evidently für Teams, die Daten-Drift und LLM-Ausgaben in Notebooks oder in einer CI-Stufe prüfen wollen und die Auswertung selbst speichern. Wer eine fertige Plattform mit Alerting, Nutzerverwaltung und ohne Betriebsaufwand sucht, sollte zuerst die OSS-gegen-Cloud-Gegenüberstellung in der Dokumentation lesen und prüfen, ob die selbst gehostete UI die benötigten Funktionen überhaupt enthält. Vor dem Einsatz im Pipeline-Betrieb ist zu klären, wie die Referenzdaten versioniert werden und wer den UI-Dienst samt Datenbank betreibt; beides löst die Bibliothek nicht.
Community-Notizen