Giskard v3: Evals und Red Teaming für agentische Systeme

Welches Problem Giskard adressiert und für wen

Klassische Unit-Tests gehen von deterministischen Ausgaben aus. Ein LLM-Agent liefert bei gleicher Eingabe unterschiedliche, aber jeweils gültige Antworten. Genau diese Lücke benennt das README: Evals seien, anders als traditionelle Unit-Tests, für nicht-deterministische Ausgaben gedacht. Giskard positioniert sich damit nicht als Modell-Benchmark, sondern als Prüfschicht für Systeme, die aus mehreren Schritten bestehen. Das README nennt als Zielobjekte ein einzelnes LLM, einen Black-Box-Agenten oder eine mehrstufige Pipeline. Die Zielgruppe sind demnach Teams, die Agenten betreiben und nach Änderungen wissen wollen, ob sich das Verhalten verschoben hat. Vier Anwendungsfälle listet das README auf: Regressionen abfangen, RAG-Qualität prüfen, ob Antworten im abgerufenen Kontext verankert sind, Sicherheitsregeln durchsetzen und mehrstufige Agenten über ganze Gespräche statt einzelne Austausche bewerten. Wer nur einen Prompt einmalig ausprobieren will, braucht dieses Werkzeug nicht.

Fünf Pakete, zwei Einstiegspunkte

Version 3.0.0 ist laut README ein kompletter Rewrite. Statt einer monolithischen Bibliothek gibt es nun einzelne Pakete, die jeweils nur ihre eigenen Abhängigkeiten mitbringen. Zwei davon sind als stabil gekennzeichnet: giskard-checks für Tests und Evaluation, giskard-scan für den Schwachstellen-Scanner und die RAG-Qualitätsbewertung. Darunter liegen drei Fundament-Bibliotheken: giskard-core für gemeinsame Utilities und Telemetrie, giskard-llm für providerunabhängiges LLM-Routing und giskard-agents für Agenten- und Workflow-Orchestrierung. Diese drei werden automatisch mitgezogen und laut README selten direkt benutzt. Der Rewrite hat eine sichtbare Konsequenz: Der Scan für tabellarische ML-Modelle bleibt ausschließlich in v2 verfügbar. Wer also klassische Tabellendaten auf Fairness oder Datenlecks prüfen will, landet in einer Version, die das README als nicht mehr aktiv gepflegt bezeichnet. Diese Aufteilung ist der wichtigste Punkt beim Lesen der Ankündigung, wichtiger als die neuen Funktionen.

Wie eine Eval aufgebaut ist: Target, Scenario, Check, Suite

Das Datenmodell ist klein und lässt sich in vier Begriffen fassen. Ein Target ist das System unter Test, ein beliebiges synchrones oder asynchrones Callable mit der Signatur (inputs) -> outputs, optional mit trace. Ein Scenario ist eine einzelne Eval und besteht aus Interaktionen plus Checks. Ein Check ist eine Zusicherung oder ein LLM-Richter über dem Trace. Eine Suite bündelt mehrere Szenarien zu einem Lauf. Das README gibt dazu ein kurzes Beispiel: Scenario("test_france_capital").interact(inputs="What is the capital of France?", outputs=get_answer).check(Groundedness(name="answer is grounded", context="...")). Ausgeführt wird das über await scenario.run(), das Ergebnis über result.print_report(). Eingebaute Checks nennt das README für String-Matching, Vergleiche, reguläre Ausdrücke, semantische Ähnlichkeit und LLM-as-judge, namentlich Groundedness, Conformity und LLMJudge. Wer eigene Logik braucht, schreibt einen Check selbst. Die Trennung von Target und Check ist der eigentliche Mechanismus: Der Agent bleibt eine Black Box, geprüft wird nur, was im Trace sichtbar wird.

Installation und die Extras, die tatsächlich zählen

Drei Befehle nennt das README. pip install giskard zieht checks samt agents, llm und core. pip install "giskard[scan]" ergänzt den Schwachstellen- und Qualitäts-Scan. pip install "giskard[openai]" liefert das Provider-SDK für LLM-Richter und Generatoren. Voraussetzung ist Python 3.12 oder neuer. Die Extras sind nicht optional im rhetorischen Sinn: Groundedness und LLMJudge sind LLM-Richter, ohne ein Provider-Extra und den passenden API-Key laufen sie nicht. Das README nennt openai/gpt-4o-mini als Standardmodell. Neben openai existieren weitere Provider-Extras, deren genaue Namen auf die optionalen Abhängigkeiten in pyproject.toml verweisen. Ein Detail, das in CI-Umgebungen schnell übersehen wird: Die Telemetrie von giskard-core lässt sich über DO_NOT_TRACK=1 oder GISKARD_TELEMETRY_DISABLED=1 abschalten, beides auch als Eintrag in einer .env im Arbeitsverzeichnis. Werden die Variablen vor dem Import gesetzt, entfällt sogar das Anlegen von ~/.giskard/id. Nachträglich gesetzt, stoppen sie laut README nur weitere Sendungen. Versprochen wird, dass keine Prompts und keine Ausgaben übertragen werden.

Wo die Beschreibung dünn bleibt

Das README ist an einer Stelle ungewöhnlich ausführlich: Es grenzt giskard.agents.Generator von den Eingabe-Generatoren in giskard.checks ab. Ersteres sei ein LLM-Client für Workflows und Richter, nicht dasselbe wie LLMGenerator, der Nutzernachrichten synthetisiert. Diese Klarstellung ist nötig, weil beide Namen nach derselben Sache klingen, und sie ist ein Hinweis darauf, dass die Namensgebung über die Paketgrenzen hinweg nicht selbsterklärend ist. Deutlich dünner ist die Dokumentation dort, wo es um Betrieb geht. Der Abschnitt zu giskard-scan bricht im vorliegenden Material nach einem Satz ab. Wie ein Scan konfiguriert wird, welche Angriffsvektoren abgedeckt sind, wie lange ein Lauf dauert, wie viel ein Lauf kostet und wie reproduzierbar die Ergebnisse sind, lässt sich daraus nicht beantworten. Auch zu den Fundament-Paketen giskard-agents und giskard-llm gibt das README nur die Einzeiler aus der Tabelle. Wer diese Schicht direkt nutzen will, muss in die jeweiligen READMEs und die Doku unter docs.giskard.ai/oss wechseln.

Grenzen und der Fall, in dem Giskard das falsche Werkzeug ist

Die härteste Einschränkung ist der Bruch zwischen den Hauptversionen. Giskard v2 bleibt laut README verfügbar, wird aber nicht mehr aktiv gepflegt. Gleichzeitig ist der Scan für tabellarische ML-Modelle ausschließlich in v2 vorhanden. Wer heute auf v3 umsteigt, tauscht also ein gepflegtes Paket gegen eines, das für diesen Anwendungsfall nicht mehr weiterentwickelt wird. Ein zweiter Punkt ist Python 3.12 oder neuer. Projekte, die auf älteren Interpretern festsitzen, können v3 nicht ohne Weiteres einsetzen. Drittens: Die LLM-Richter erzeugen laufende Kosten und eine Abhängigkeit von einem externen Anbieter. Eine Eval-Suite, die hunderte Szenarien über einen Richter prüft, ist kein kostenloser CI-Schritt. Viertens: Wer deterministische Software testet, für den ist der ganze Ansatz überdimensioniert. Für einen Parser mit festen Ein- und Ausgaben reicht pytest, und zwar ohne API-Key und ohne Netzwerkzugriff.

Alternative: DeepEval und der Unterschied im Ansatz

DeepEval ist eine verbreitete Python-Bibliothek für LLM-Evaluation und verfolgt einen anderen Aufbau. Der Ansatz dort ist metrikzentriert: Ein Testfall besteht aus Eingabe, tatsächlicher Ausgabe und einem oder mehreren Metrik-Objekten wie AnswerRelevancyMetric oder FaithfulnessMetric, die jeweils einen Score zwischen 0 und 1 samt Begründung liefern und gegen einen Schwellenwert geprüft werden. Giskard Checks setzt stattdessen auf Szenarien. Ein Scenario kann mehrere Interaktionen enthalten, also einen mehrstufigen Dialog abbilden, und die Checks laufen über den Trace des gesamten Ablaufs. Das ist der praktische Unterschied: Bei DeepEval steht die Bewertung eines einzelnen Austauschs im Vordergrund, bei Giskard die Abfolge. Dafür ist das Metrik-Arsenal bei DeepEval breiter und die Scores sind über Läufe hinweg vergleichbar, während Giskards LLM-Richter qualitative Urteile liefert. Wer ein Dashboard mit Kennzahlen über Zeit braucht, wird bei Giskard mehr selbst bauen müssen. Wer dagegen prüfen will, ob ein Agent nach fünf Gesprächsschritten noch im Kontext bleibt, findet dort das passendere Modell.

Wartung, Versionen und Lizenz

Das Repository ist nicht archiviert, der letzte Push datiert auf den 9. September 2026. Die drei Releases v3.0.0, giskard-scan/v1.0.0 und giskard-llm/v1.0.0 stammen alle vom 26. August 2026. Die Pakete werden also einzeln versioniert, giskard-scan und giskard-llm starten bei 1.0.0, während der Sammelname giskard bei 3.0.0 steht. Wer Abhängigkeiten pinnt, sollte das beachten: Ein festes giskard==3.0.0 sagt nichts über die Version von giskard-scan aus, die mitinstalliert wird. Für Upgrades bedeutet das mehr Beweglichkeit, aber auch mehr Stellen, an denen sich etwas ändern kann. Die Lizenz ist Apache-2.0, wie die Badge im README und die Lizenzangabe des Repositories zeigen. Das erlaubt kommerzielle Nutzung und Modifikation unter den Bedingungen dieser Lizenz, üblicherweise inklusive Beibehaltung von Copyright- und Lizenzhinweisen. Das ist keine Rechtsberatung. Wer die Bibliothek in ein Produkt einbettet oder modifiziert weiterverbreitet, sollte die konkreten Pflichten aus der LICENSE-Datei im Repository selbst prüfen. Ein Hinweis zum Schluss: Aussagen zur Reife lassen sich aus Release-Zeitpunkten und Versionsnummern nicht ableiten. Wer wissen will, ob ein Scan-Lauf in seiner Umgebung reproduzierbar ist, muss ihn selbst ausführen.

Redaktionelles Fazit

Wer agentische Systeme mit mehrstufigen Dialogen testet und Python 3.12 oder neuer einsetzt, findet in giskard-checks und giskard-scan eine schlanke Basis mit Apache-2.0-Lizenz. Wer tabellarische ML-Modelle scannen muss, bleibt auf v2, das laut README nicht mehr aktiv gepflegt wird, und sollte vor jedem Umstieg klären, ob dieser Pfad für ihn noch trägt. Vor dem ersten produktiven Lauf lohnt ein Blick auf drei Dinge: ob die installierte Version tatsächlich 3.0.0 oder neuer ist, ob ein Provider-Extra wie giskard[openai] samt API-Key gesetzt ist, weil Groundedness und LLMJudge sonst nicht laufen, und ob DO_NOT_TRACK oder GISKARD_TELEMETRY_DISABLED vor dem ersten Import in der Umgebung stehen, falls die Analytics von giskard-core nicht erwünscht sind.

Offizielle Quellen

1. Giskard-AI/giskard-oss on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases