Die besten Open-Source-LLM-Evaluierungs-Frameworks 2026 (eines ist gar nicht Open Source)

Die besten Open-Source-LLM-Evaluierungs-Frameworks 2026 (eines ist gar nicht Open Source)

Zeile 1 der LICENSE-Datei im Arize-Phoenix-Repo lautet „Elastic License 2.0 (ELv2)". Nicht Apache. Nicht MIT. Ein häufig empfohlenes Open-Source-LLM-Evaluierungs-Framework ist nach der Definition der OSI gar nicht Open Source, und fast jede Seite, die für diese Suchanfrage rankt, wiederholt trotzdem die Behauptung. So auch eine unserer eigenen Seiten, bis heute. Am 2026-08-04 haben wir die Lizenzdatei und den Commit-Log des Default-Branch von acht Frameworks von Hand geprüft, dazu drei weitere, die Top-Seiten noch immer empfehlen, und sechs davon installiert, um dieselben 10 Testfälle durchlaufen zu lassen. Wir verkaufen kein Eval-Framework, also schützt kein Urteil unten ein eigenes Produkt.

Das Wichtigste in Kürze

• Arize Phoenix läuft unter Elastic License 2.0, was die OSI nicht als Open Source anerkennt.
• Der letzte Commit von UpTrain auf main war am 2024-07-29. Starten Sie damit kein neues Projekt.
• pip install promptfoo liefert einen Drittanbieter-Wrapper. Das echte Projekt erscheint auf npm.
• Ragas hat keine Commits seit 2026-02-24 und ist zur GitHub-Organisation vibrantlabsai umgezogen.

Welches Open-Source-LLM-Evaluierungs-Framework sollten Sie 2026 installieren?

Wählen Sie nach Anforderung, nicht nach Rang. Für pytest-artige Assertions innerhalb einer bestehenden Testsuite installieren Sie DeepEval. Für eine YAML-Konfiguration und eine CLI, die zu jedem Sprach-Stack passt, installieren Sie promptfoo. Für die sauberste Trennung zwischen guten und schlechten Antworten, die wir gemessen haben, installieren Sie Opik. Alle drei stehen unter Apache-2.0 oder MIT.

Hier das Audit. Acht Frameworks im Fokus, plus drei weitere, die die Top-Seiten für diese Suchanfrage noch immer empfehlen.

Die Daten sind der letzte Commit auf dem Default-Branch jedes Projekts, Stand 2026-08-04. Die GitHub-Repo-Seite zeigt den letzten Push auf irgendeinen Branch, der bei zwei Projekten hier später liegt: UpTrain 2024-08-18 und Deepchecks 2025-12-28. Kein Repo ist archiviert.

Die Spalte Wechselkosten ist die, die man überliest und später bereut. Scores sind nur Zahlen, ein Wechsel zwischen DeepEval, Ragas, Opik und phoenix-evals bedeutet also meist nur eine Schleife umzuschreiben. Ein Wechsel weg von promptfoo oder Inspect AI bedeutet, ein Konfig- oder Task-Format ohne Äquivalent woanders neu zu schreiben, und ein Wechsel weg von Evidently bedeutet, jeden geschriebenen Schwellenwert zu prüfen, weil die Skala andersherum läuft. Zwei der Frameworks, die Top-Seiten noch immer empfehlen, haben seit 2024 kein Release mehr veröffentlicht.

Suchen Sie Tiers, gehostete Plattformen und eine klare Reihenfolge statt dessen? Das ist ein anderes Thema, und wir haben es bereits in unserem Ranking-Vergleich von LLM-Evaluierungstools inklusive kostenpflichtiger Plattformen behandelt.

Die acht LLM-Evaluierungs-Frameworks, gruppiert nach Installationsart

Die Installationsform ist das, womit man leben muss, deshalb die Gruppierung danach.

Python-Bibliotheken, die man in Tests importiert

DeepEval (pip install deepeval, Apache-2.0) verpackt LLM-Metriken in pytest-artige Assertions: Man baut einen LLMTestCase, übergibt ihn an assert_test, und der Test schlägt unter dem gesetzten Schwellenwert fehl. Am besten geeignet, um ein Qualitäts-Gate direkt neben die Unit-Tests zu stellen, die ein Team bereits ausführt. Wählen Sie dies, wenn Ihre Evals in denselben CI-Job gehören wie alles andere.

Ein Hinweis, einmal genannt: DeepEval wird von Confident AI entwickelt, einem bezahlten Partner auf zwei weiteren Beiträgen dieser Website, einschließlich des Ranking-Vergleichs, auf den diese Seite verlinkt. Es erhält hier keine Sonderbehandlung, und jeder DeepEval-Link auf dieser Seite verweist auf das GitHub-Repo.

Ragas (pip install ragas, Apache-2.0) ist die RAG-spezifische Option: evaluate() nimmt Zeilen aus Frage, Kontext und Antwort und liefert asynchron Scores pro Metrik. Am besten geeignet für Retrieval-Qualitätsmessung innerhalb einer Python-Pipeline. Das Repo ist von explodinggradients zu vibrantlabsai umgezogen, das letzte Release war v0.4.3 am 2026-01-13, und es gibt keine Commits seit 2026-02-24. Wählen Sie dies, wenn RAG-Metriken die ganze Aufgabe sind und ein ruhiges Repo akzeptabel ist, und sehen Sie sich den breiteren RAG-Tooling-Stack an.

Opik (pip install opik, Apache-2.0, von Comet) liefert Metriken, die man einzeln aufrufen kann. Mit OPIK_TRACK_DISABLE=true läuft AnswerRelevance().score() ohne Account, ohne lokalen Server und ohne Konfigurationsdatei — etwas, das die Produktdarstellung nicht bewirbt. Am besten geeignet, um mit möglichst wenigen Zeilen einen echten Score zu bekommen. Wählen Sie dies, wenn Sie die Metriken jetzt wollen und die Plattform vielleicht später.

Evidently (pip install evidently, Apache-2.0) behandelt Evals als Deskriptoren über ein Dataset und schreibt als Nebeneffekt einen HTML-Report. Am besten geeignet für Batch-Reporting über viele Zeilen statt für ein binäres Gate. Die LLM-Scores sind invertiert: 1.0 bedeutet unfaithful. Wählen Sie dies, wenn Sie jemandem einen teilbaren Report schulden, keinen roten Build.

Giskard (pip install giskard, Apache-2.0) scannt ein Modell auf Schwachstellen, statt ein selbst geschriebenes Dataset zu bewerten. Das PyPI-Paket löst die v2-Linie auf, und das eigene README des Projekts erklärt, dass v2 „is no longer actively maintained" sei. Am besten geeignet für automatisierte Red-Team-artige Scans. Wählen Sie dies, wenn Sie Schwachstellen für sich finden lassen wollen statt selbst definierte LLM-as-a-Judge-Metriken.

CLI-und-Konfig-Tools, die man gegen eine YAML-Datei laufen lässt

promptfoo (npm install promptfoo, MIT) ist eine CLI, die eine YAML-Datei liest: Providers, Testfälle und Assertions deklarieren, npx promptfoo eval ausführen und Pass/Fail pro Fall plus eine lokale Ergebnis-UI erhalten. Am besten geeignet, um Prompts zu evaluieren, wenn Ihre App nicht in Python geschrieben ist. Wählen Sie dies, wenn Ihr Qualitäts-Gate eine Konfigurationsdatei sein soll, die auch ein Nicht-Python-Teammitglied bearbeiten kann.

Harness-Klasse und plattformgebündelt

Inspect AI (pip install inspect-ai, MIT) stammt vom UK AI Safety Institute und evaluiert Modelle gegen in Python definierte Tasks, mit echten Solver- und Scorer-Abstraktionen und einem Run-Viewer. Am besten geeignet für Modell-Level-Benchmarking mit reproduzierbaren Task-Definitionen. Wählen Sie dies, wenn das Testobjekt ein Modell ist, nicht Ihre Anwendung.

Arize Phoenix (pip install arize-phoenix-evals) liefert vorgefertigte Evaluatoren wie FaithfulnessEvaluator und CorrectnessEvaluator, die ein binäres Label plus einen Score zurückgeben. Am besten geeignet für deterministische Labels, auf die man ohne eigene Schwellenwertwahl gaten kann. Die Lizenz ist der Grund für den Klammerzusatz im Titel dieses Artikels, dem gleich ein eigener Abschnitt gewidmet ist.

Ist Arize Phoenix Open Source?

Nein, nicht nach der Definition, die die Open Source Initiative vertritt. Arize Phoenix läuft unter der Elastic License 2.0 (ELv2). Zeile 1 der LICENSE-Datei des Repos sagt das aus, und PyPI erklärt unabhängig davon license: Elastic-2.0 bei v19.15.0. Der Quellcode ist lesbar, forkbar und selbst hostbar (source-available). Nur eine Nutzungsart ist eingeschränkt.

Die entscheidende Einschränkung: ELv2 verbietet es, die Software Dritten als gehosteten oder verwalteten Dienst anzubieten. Das gilt es genau zu lesen, denn es betrifft weit weniger Leute, als es klingt. Wer arize-phoenix-evals installiert, um die eigene Anwendung zu bewerten, ist von ELv2 nie betroffen. Wer als Beratung oder Plattformteam Phoenix in einen Eval-Dienst verpackt, den man an externe Kunden verkauft, ist betroffen. Das ist der gesamte Unterschied, und die Open Source Definition ist das, woran ELv2 scheitert, konkret an den Klauseln zu Field-of-Use-Einschränkungen.

Jede Seite, die aktuell für diese Suchanfrage rankt, führt Phoenix unter „Open Source", und das taten wir auch. Unser eigener Ranking-Vergleich von LLM-Evaluierungstools beschreibt Phoenix als vollständig Open Source, was falsch ist und korrigiert wird. Phoenix ist source-available, nicht Open Source, und der Unterschied wird nur relevant, wenn Sie planen, es als Dienst zu verkaufen. Wenn eher Tracing als Scoring Ihr eigentlicher Bedarf ist, gehört das zu AI-Observability-Plattformen, nicht hierher.

Welche davon werden noch aktiv gepflegt?

Die meisten. Sechs der elf geprüften Repos erhielten am 2026-08-03 oder 2026-08-04 einen Commit auf main: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI und Giskard. Zwei haben seit 2024 kein Release mehr veröffentlicht. Eines ist 2026 nach einem Wechsel der GitHub-Organisation still geworden.

Frameworks, mit denen wir 2026 kein neues Projekt starten würden

UpTrain ist tot. Der letzte Commit auf main erfolgte am 2024-07-29, das letzte Release, v0.7.1, war am 2024-05-14 — nach beiden Maßstäben zwei Jahre alt. Das Repo existiert noch und steht weiterhin unter Apache-2.0, nichts hindert Sie also daran, aber ein neues Projekt auf einer aufgegebenen Evaluierungsbibliothek zu starten, ist eine Entscheidung, die man später erklären muss.

Deepchecks verdient die präzise Formulierung. Es hat seit 0.19.1 am 2024-12-15 kein Release mehr gegeben, obwohl das Repo weiterhin Commits erhält, der letzte auf main am 2025-11-24. Es wird also noch daran gearbeitet; nur hat seit über achtzehn Monaten niemand eine Version geschnitten. Weder UpTrain noch Deepchecks ist auf GitHub archiviert, und keines der beiden hat sich für Beiträge geschlossen.

Ragas bekommt Daten und sonst nichts. Letztes Release v0.4.3 am 2026-01-13, keine Commits seit 2026-02-24, und das Repo ist von explodinggradients zu vibrantlabsai umgezogen. Wir haben keine verifizierbare Erklärung für den Organisationswechsel gefunden und erfinden daher keine. Ein ruhiges Repo ist kein kaputtes: Apache-2.0-Code, der heute einen Faithfulness-Score berechnet, berechnet ihn auch nächstes Jahr noch. Das Risiko sind ungepatchte Abhängigkeiten, genau das, was uns im Test unten getroffen hat.

Andere Seiten auf Seite eins dieser Suchanfrage empfehlen weiterhin sowohl UpTrain als auch Deepchecks, ohne dass ein Datum an der Empfehlung hängt. Ein Framework ohne Release seit Dezember 2024 ist eine Abhängigkeitsentscheidung, keine Feature-Entscheidung.

Brauchen Sie ein Eval Framework oder eine Eval Harness?

Ein Application-Eval-Framework (Anwendungs-Evaluierungs-Framework) bewertet die eigenen Ausgaben Ihrer App gegen Ihre eigenen Daten. DeepEval, Ragas, promptfoo, Opik, phoenix-evals und Evidently tun genau das. Eine Model-Eval-Harness (Modell-Evaluierungs-Harness) benchmarkt stattdessen ein Modell gegen standardisierte öffentliche Tasks. lm-evaluation-harness und Inspect AI tun das. Die falsche Kategorie zu wählen ist der teuerste Fehler auf dieser Seite.

Der Fehlerfall ist konkret. Jemand verkabelt lm-evaluation-harness, um seinen RAG-Chatbot zu testen, bekommt eine Reihe von MMLU-Scores zurück und lernt dabei präzise nichts darüber, ob der eigene Retriever die richtigen Passagen liefert. Die Scores sind echt. Sie messen nur das Basismodell, um das sich ohnehin niemand gesorgt hat.

Die Form von Inspect AI folgt aus seiner Herkunft: Es wurde am UK AI Safety Institute unter MIT entwickelt, um Frontier-Modelle zu evaluieren, daher sind Solver, Scorer und Tasks erstklassige Konzepte, Ihre Anwendung dagegen ist eines, das es nicht kennt. Das ist ein guter Grund, es für genau diesen Zweck zu nutzen. Wenn Ihr Problem eher Agenten als einzelne Turns betrifft, ist die Evaluierung von Agenten in Produktion noch einmal eine andere Disziplin, und Tool-Calling-Server erhalten eine eigene Behandlung in unserem Leitfaden zur Evaluierung von MCP-Servern und -Tools.

Was passierte, als wir sechs davon installierten und dieselben 10 Fälle durchlaufen ließen

Am 2026-08-04 haben wir sechs davon in frischen Python-3.11.14-venvs installiert (plus npm für promptfoo) und ein identisches 10-teiliges RAG-Set mit einem Judge bewertet, openai/gpt-4o-mini über OpenRouter bei Temperatur 0. Sieben Items waren korrekt. Drei waren auf drei verschiedene Arten fehlerhaft: eines widerspricht seinem Kontext, eines erfindet Details, eines ist flüssige Prosa, die die Frage nie beantwortet. Jedes Framework lief zweimal hintereinander.

Fünf der sechs Grounding-Metriken erkannten alle drei Fehler. Die drei folgenden Befunde sind der Grund für diesen Abschnitt.

Relevanz-Metriken sind keine Qualitätsmetriken, und zwei von ihnen bewerteten eine überzeugende Falschaussage höher als eine korrekte Antwort. Ragas' ResponseRelevancy bewertete das Item, das behauptet, HTTP 404 sei ein 5xx-Serverfehler, mit 0.777 — höher als zwei der sieben korrekten Antworten — und das Item mit erfundenen Rate-Limits mit 0.813, höher als vier. promptfoo answer-relevance tat dasselbe: 0.800 für das 404-Item, ein sauberer Pass gegen einen 0.7-Schwellenwert, während die korrekte Antwort q01 mit 0.679 durchfiel. Kein Bug. Eine überzeugende Falschaussage adressiert die Frage perfekt. Aber wenn Relevanz die Zahl auf Ihrem Dashboard ist, sieht eine flüssige Halluzination wie Ihre beste Ausgabe aus.

Ein reines Faithfulness-Gate übersieht die irrelevante Antwort. DeepEval bewertete das Item, das die Frage nie beantwortet, mit 1.000 Faithfulness — ein sauberer Pass, was durchaus vertretbar ist: Eine Antwort, die nichts über den Kontext behauptet, widerspricht auch nichts darin. Nur Relevancy erkannte das, mit 0.000. Das ist der einzige Grounding-Fehler in der obigen Tabelle. Jede Metrik allein hat eine Lücke; das Paar deckt beides ab.

Binäre Evaluatoren waren bei Temperatur 0 stabil. Graduelle Metriken waren es nicht. Phoenix und DeepEval bewegten über zwei identische Läufe null von zehn Items. Opik bewegte vier, alle bei AnswerRelevance, auf einem 0.05-Raster; Evidently bewegte ebenfalls vier. Kein Drift kippte hier ein Urteil, aber die korrekte Antwort q01 landete bei promptfoo bei 0.679, dann bei 0.642 gegen einen 0.700-Schwellenwert — das Muster eines instabilen CI-Gates.

Zwei kleinere Anmerkungen: Drei von sechs (DeepEval, Opik, Phoenix) installierten und liefen beim ersten Versuch sauber, während Ragas erst importierte, nachdem wir langchain-community<0.4 gepinnt hatten. Nur promptfoo meldete den Token-Verbrauch des Judges, 16.011 Assertion-Tokens in Lauf 1 und 16.010 in Lauf 2.

Die Grenzen dieses Tests, klar benannt. n = 10 ist ein Smoke-Test, kein Benchmark: Er sagt etwas über Ergonomie und blinde Flecken, nicht über Metrikgenauigkeit. Ein Judge-Modell hat alles bewertet, und ein größerer Judge würde jede Zahl verschieben, wahrscheinlich auch die beiden falsch-positiven Ergebnisse, die DeepEval und Ragas beide beim selben korrekten Item produzierten. Zwei Läufe beweisen, dass Drift existiert, können ihn aber nicht charakterisieren. Die Antworten waren vorformuliert, nichts hier prüft also Generierung, Tracing oder Dataset-Management, was promptfoos 337.9-Sekunden-Installation schlechter aussehen lässt, als sie ist. „Am besten" heißt immer am besten für eine bestimmte Anforderung: ein CI-Gate, RAG-Metriken oder eine UI verändern jeweils die Antwort, ebenso wie die Trennung zwischen Offline- und Online-Evaluierung.

Derselbe Check, dreimal geschrieben

Der schnellste Weg, eine Interface-Form zu wählen, ist, dieselbe Assertion dreimal zu lesen. Hier ein Grounding-Check auf einem Item in DeepEval, Ragas und promptfoo, gekürzt aus den Skripten, die wir tatsächlich ausgeführt haben. Die Metriknamen unterscheiden sich; wir verlinken auf wie LLM-as-a-Judge-Metriken tatsächlich funktionieren, statt sie hier neu zu definieren.

# DeepEval 4.1.5: pytest-artig, lässt den Test unter dem Schwellenwert fehlschlagen
from deepeval import assert_test
from deepeval.models import GPTModel
from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase

judge = GPTModel(
    model="openai/gpt-4o-mini",
    base_url="https://openrouter.ai/api/v1",
    api_key=OPENROUTER_KEY,
)

def test_faithfulness():
    case = LLMTestCase(
        input=question,
        actual_output=answer,
        retrieval_context=[context],
    )
    assert_test(case, [FaithfulnessMetric(threshold=0.7, model=judge)])

# Ragas 0.4.3: auf den Importpfad achten. `from ragas.metrics import Faithfulness`
# wirft in dieser Version ImportError; die konkrete Metrik ist umgezogen.
from ragas import evaluate, EvaluationDataset
from ragas.metrics._faithfulness import Faithfulness
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

judge = LangchainLLMWrapper(
    ChatOpenAI(model="openai/gpt-4o-mini",
               base_url="https://openrouter.ai/api/v1")
)

result = evaluate(
    dataset=EvaluationDataset.from_list(rows),
    metrics=[Faithfulness(llm=judge)],
)

# promptfoo 0.121.20: npm install promptfoo, dann npx promptfoo eval
providers:
  - id: echo          # wir bewerteten vorformulierte Antworten, statt sie zu generieren
defaultTest:
  assert:
    - type: context-faithfulness
      threshold: 0.7
tests:
  - vars:
      query: "Is HTTP 404 a client error or a server error?"
      context: "HTTP 404 Not Found is in the 4xx class, which denotes client errors."
      output: "HTTP 404 is a server error in the 5xx class."

Die Installationszeilen bergen mehr Fallstricke als der Code, und jeder Kommentar unten hat uns am 2026-08-04 Zeit gekostet:

# Das echte promptfoo erscheint auf npm. Das PyPI-Paket gleichen Namens ist
# ein Drittanbieter-Wrapper: https://pypi.org/project/promptfoo/ vs
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard löst die v2-Linie auf, die das eigene README des
# Projekts als "no longer actively maintained" kennzeichnet.
pip install giskard

# lm-evaluation-harness installiert sich unter dem Paketnamen lm-eval.
pip install lm-eval

# Evidently zieht kein openai nach, und der Judge stürzt erst beim Aufruf
# ab, nicht beim Import, nachdem man bereits das Dataset gebaut hat.
pip install evidently openai

# Ragas 0.4.3 lässt sich nicht gegen langchain-community 0.4.x importieren.
pip install ragas "langchain-community<0.4"

Kann man einen Build anhand eines Eval-Scores scheitern lassen?

Ja. Jedes hier vorgestellte Framework liefert einen numerischen oder binären Score, und jedes beendet sich mit einem Exit-Code ungleich null, wenn eine Schwellenwert-Assertion fehlschlägt — genau das, was GitHub Actions braucht, um einen Build rot zu markieren. Den Exit-Code zu verkabeln ist der einfache Teil. Einen Schwellenwert zu wählen, den Ihr Judge-Modell nicht versehentlich überschreitet, ist der Teil, der eine Woche dauert.

So sieht der Workflow aus, den wir fahren, gepinnt auf die Versionen aus unserem 2026-08-04-Test:

name: evals
on: [pull_request]

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11.14"
      - run: pip install deepeval==4.1.5

      - name: Score the golden set
        env:
          # Judge pinnen. Ein Modell-Upgrade mitten im Quartal verschiebt jeden Score.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Schwellenwerte an einer Stelle halten, gelesen von den Metrik-Konstruktoren.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Zwei Stolperfallen greifen vor dem Schwellenwert. Erstens: Judge-Aufrufe sind Netzwerkaufrufe. Unser 10-Item-DeepEval-Lauf brauchte 126.8 Sekunden, weil .measure() sequenziell läuft, und ein 200-Item-Golden-Set auf diesem Codepfad ist bei jedem Pull Request eine Kaffeepause. Jedes andere Framework im Test parallelisiert standardmäßig, was der größte einzelne Hebel für die CI-Laufzeit ist.

Zweitens: Instabilität. Bei Temperatur 0 bewegten Opik und Evidently jeweils vier von zehn Items zwischen zwei aufeinanderfolgenden Läufen, und promptfoos korrekte Antwort lag bei 0.679, dann bei 0.642 gegen ein 0.700-Gate. Die Gegenmaßnahmen sind unspektakulär und funktionieren: einen festen Golden-Datensatz fahren, der sich nur pro Pull Request ändert, das Judge-Modell pinnen, binäre Evaluatoren bevorzugen, wo ein Label genügt, und auf ein Delta statt auf eine absolute Untergrenze gaten. Letzteres ist besonders wichtig bei der Multi-Turn-Evaluierung, wo eine einzige Konversation viele Scores erzeugt, die jeweils schwanken können.

Zur Einordnung: LangChains State of Agent Engineering Survey (1.340 Antworten, erhoben vom 18. November bis 2. Dezember 2025, veröffentlicht am 12. Juni 2026) fand heraus, dass 89 % der Organisationen irgendeine Form von Observability für ihre Agenten implementiert haben, während nur 52.4 % Offline-Evaluierungen auf Testsets durchführen. Beobachten ist verbreitet. Gaten nicht.

Was wir diese Woche installieren würden

Vier Dinge zum Mitnehmen. Arize Phoenix ist source-available unter Elastic License 2.0 und keine OSI-anerkannte Open-Source-Software — das ändert für die meisten Leser nichts und für alle, die Eval-Tooling weiterverkaufen, alles. UpTrain ist tot, und Seiten ohne Datumsangabe empfehlen es trotzdem noch. Deepchecks hat ebenfalls seit Dezember 2024 kein Release mehr geschnitten, obwohl das Repo weiterhin Commits erhält. Eine Grounding-Metrik und eine Relevanz-Metrik haben jeweils eine Lücke, die die andere abdeckt, also auf beide gaten. Und graduelle Scores driften bei Temperatur 0, also den Judge pinnen und den Schwellenwerten etwas Spielraum geben.

Würde ich diese Woche eine neue Eval-Suite starten, würde ich DeepEval für das CI-Gate installieren, weil Assertions neben Tests gehören (Hinweis oben), und Opiks eigenständige Metriken für die sauberste Trennung ergänzen, die wir gemessen haben. Wäre unser Stack nicht Python, dann promptfoo, ohne zu zögern. Wenn Sie lieber jemand anderen das Golden-Set und den Workflow verkabeln lassen würden: Darüber sprechen wir gerne.

Häufig gestellte Fragen

Was ist das beste Open-Source-LLM-Evaluierungs-Framework?

Es gibt keinen einzelnen Gewinner, nur die beste Passung pro Anforderung. Für ein Pass/Fail-Gate innerhalb einer Python-Testsuite: DeepEval. Für ein sprachunabhängiges YAML-und-CLI-Setup: promptfoo. Für RAG-Retrieval-Metriken: Ragas, sofern man ein Repo ohne Commits seit 2026-02-24 akzeptieren kann. Für die sauberste Trennung zwischen guten und schlechten Antworten in unserem 2026-08-04-Test: Opik.

Ist Arize Phoenix Open Source?

Nicht nach der Definition der Open Source Initiative. Arize Phoenix läuft unter der Elastic License 2.0, die PyPI als license: Elastic-2.0 bei v19.15.0 deklariert und die Zeile 1 der LICENSE-Datei des Repos direkt aussagt. Es ist source-available: Man kann es lesen, forken, verändern und selbst hosten. Die einzige Einschränkung ist, die Software Dritten als gehosteten oder verwalteten Dienst anzubieten.

Wird Ragas noch gepflegt?

Die verifizierbaren Fakten, Stand 2026-08-04: Das letzte Release war v0.4.3 am 2026-01-13, es gab keine Commits seit 2026-02-24, und das Repository ist von der Organisation explodinggradients zu vibrantlabsai umgezogen. Das Repo ist nicht archiviert. Wir fanden keine verlässliche öffentliche Erklärung für den Organisationswechsel und spekulieren daher nicht. Der Apache-2.0-Code läuft weiterhin; das Risiko sind ungepatchte Abhängigkeiten.

Brauche ich ein Eval-Framework oder eine Observability-Plattform?

Beides, irgendwann, aber sie beantworten unterschiedliche Fragen. Ein Eval-Framework sagt Ihnen, ob eine Änderung Ihre Ausgaben besser oder schlechter gemacht hat, bevor Sie sie ausliefern, auf einem Datensatz, den Sie kontrollieren. Eine Observability-Plattform sagt Ihnen, was in Produktion tatsächlich passiert ist, nachdem Sie ausgeliefert haben. Starten Sie mit dem Eval-Framework, wenn Sie eine CI-Pipeline haben; für die Produktionsseite siehe AI-Observability-Plattformen.

Kann ich LLM-Evals in CI/CD ausführen?

Ja. Jedes hier vorgestellte Framework beendet sich mit einem Exit-Code ungleich null bei einer fehlgeschlagenen Schwellenwert-Assertion, mehr braucht ein GitHub-Actions-Job nicht. Die praktischen Einschränkungen sind die Laufzeit (Judge-Aufrufe sind Netzwerkaufrufe, unser sequenzieller DeepEval-Lauf brauchte 126.8 Sekunden für 10 Items) und die Nicht-Determinismus des Judges. Die Workflow-Form und die Gegenmaßnahmen finden Sie im CI-Abschnitt oben.

Was ist der Unterschied zwischen DeepEval und Ragas?

Interface-Form und Umfang, nicht Qualität. DeepEval ist pytest-artig und allgemein einsetzbar: Man schreibt Testfälle und assert't auf Metrik-Schwellenwerte, und es deckt Anwendungsausgaben vieler Arten ab. Ragas ist eine RAG-spezifische Bibliothek, deren evaluate() asynchron über ein Dataset aus Frage-, Kontext- und Antwortzeilen läuft. DeepEval passt natürlicher in ein CI-Gate; Ragas geht tiefer bei Retrieval.

Warum liefert pip install promptfoo das falsche Paket?

Weil promptfoo ein Node-Projekt ist. Das echte Projekt wird auf npm unter MIT veröffentlicht und installiert sich mit npm install promptfoo. Das PyPI-Paket gleichen Namens ist ein Drittanbieter-Wrapper, nicht das Upstream-Projekt, und es zu installieren ist ein üblicher Weg, am Ende eine CLI zu debuggen, die nicht die in der Dokumentation beschriebene ist.

Ist lm-evaluation-harness ein LLM-Evaluierungs-Framework?

Es ist eine Model-Evaluation-Harness, eine verwandte, aber andere Aufgabe. lm-evaluation-harness (installiert als pip install lm-eval) benchmarkt ein Modell gegen standardisierte öffentliche Tasks wie MMLU. Es sagt Ihnen nicht, ob Ihre Retrieval-Pipeline die richtige Passage geliefert hat, weil Ihre Anwendung für dieses Tool kein Konzept ist. Siehe den Abschnitt Framework versus Harness oben für die Trennung.

Sind diese Frameworks kostenlos nutzbar?

Lizenzseitig ja. DeepEval, Ragas, Opik, Evidently und Giskard stehen unter Apache-2.0; promptfoo, Inspect AI und lm-evaluation-harness unter MIT. Beide Lizenzen erlauben kommerzielle Nutzung, Veränderung und Weiterverbreitung. Arize Phoenix ist die Ausnahme: Die Elastic License 2.0 erlaubt Self-Hosting, aber nicht, die Software Dritten als verwalteten Dienst anzubieten. Die API-Nutzung des Judge-Modells wird von Ihrem Anbieter separat berechnet.