Giskard v3 : évaluer et attaquer des agents LLM avec des paquets séparés
🐢 Open-Source Evaluation & Testing library for LLM Agents
En bref
- De quoi s’agit-il ?
- La réécriture v3 de Giskard découpe l'évaluation d'agents en paquets indépendants : giskard-checks pour les scénarios et les juges LLM, giskard-scan pour le red teaming et la qualité RAG. Voici ce que la documentation permet réellement de vérifier, et ce qu'elle laisse dans l'ombre.
- À qui s’adresse-t-il ?
- Giskard v3 s'adresse aux équipes Python 3.12+ qui testent des agents ou des pipelines RAG non déterministes et qui veulent écrire leurs scénarios dans du code plutôt que dans une interface. Passez votre chemin si votre besoin porte sur des modèles tabulaires : le README indique que seul le scan tabulaire reste en v2, et que la v2 n'est plus activement maintenue.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : tester des sorties qui ne se répètent pas
Un test unitaire classique compare une sortie à une valeur attendue. Un agent LLM ne produit pas la même chaîne deux fois pour la même entrée, et deux formulations différentes peuvent être également correctes. Giskard v3 vise ce cas précis : fournir des évaluations (le projet écrit evals) capables de juger une réponse non déterministe, puis de rejouer ces évaluations après un changement de prompt, de modèle ou d'outil. La cible annoncée n'est pas seulement un LLM isolé. Le README parle de systèmes agentiques, et précise que l'architecture est conçue pour envelopper n'importe quoi : un LLM, un agent en boîte noire, ou un pipeline à plusieurs étapes. Le public visé est donc une équipe qui a déjà un agent en production ou en préproduction et qui veut détecter les régressions, contrôler l'ancrage des réponses RAG, appliquer une politique de contenu, et tester des conversations multi-tours. Les sujets déclarés du dépôt couvrent à la fois l'évaluation, le red teaming, la sécurité, l'équité et le MLOps, ce qui donne une idée de l'étendue revendiquée.
Cinq paquets, deux surfaces stables
La v3 est une réécriture, et le README insiste sur le découpage : chaque paquet ne porte que les dépendances dont il a besoin. Deux paquets sont marqués stables. giskard-checks contient l'API de scénarios, les vérifications intégrées et le LLM-as-judge. giskard-scan contient le scanner de vulnérabilités d'agents et l'évaluation de qualité RAG. Trois bibliothèques de base sont tirées automatiquement et rarement utilisées directement : giskard-core pour les utilitaires partagés et la télémétrie, giskard-llm pour le routage multi-fournisseurs, giskard-agents pour l'orchestration d'agents et de workflows. Cette séparation a un effet concret sur l'installation : pip install giskard n'installe pas giskard-scan, il faut l'extra scan. Elle a aussi un effet sur les versions. Les notes de version listent giskard-scan/v1.0.0 et giskard-llm/v1.0.0 à côté du giskard v3.0.0, ce qui suggère que ces paquets sont versionnés séparément. Le README ne détaille pas la politique de compatibilité entre ces versions ; c'est un point à vérifier dans votre gestionnaire de dépendances plutôt qu'à supposer.
Scenario, Target, Check, Suite : le vocabulaire à retenir
Quatre notions structurent giskard-checks. La cible (Target) est le système testé : n'importe quel callable synchrone ou asynchrone de la forme (inputs) -> outputs, éventuellement accompagné d'une trace. Un scénario (Scenario) est une évaluation : une ou plusieurs interactions, puis des vérifications. Une vérification (Check) est une assertion ou un juge LLM appliqué à la trace. Une suite (Suite) regroupe plusieurs scénarios exécutés ensemble. Le README signale une ambiguïté de nommage qui peut coûter du temps : giskard.agents.Generator est un client LLM destiné aux workflows et aux juges, et n'a rien à voir avec les générateurs d'entrées de giskard.checks, comme LLMGenerator, qui synthétisent des messages utilisateur. Deux objets portent le mot Generator dans la même bibliothèque avec des rôles opposés. C'est le genre de détail qui fait perdre une heure à la première lecture d'une trace d'exécution.
Un scénario complet, du câblage à l'exécution
Le README donne un exemple minimal qu'on peut reprendre tel quel. On importe asyncio, Scenario et Groundedness depuis giskard.checks. On définit une fonction get_answer qui prend une chaîne et renvoie une chaîne. On construit le scénario avec Scenario("test_france_capital"), on enchaîne .interact(inputs=..., outputs=get_answer), puis .check(Groundedness(name="answer is grounded", context="France is in Western Europe. Its capital is Paris.")). L'exécution se fait avec await scenario.run(), et le résultat expose result.print_report(). Tout est asynchrone, ce qui est cohérent avec l'annonce async-first, et impose un asyncio.run(main()) dans un script classique. Groundedness est un juge LLM : il faut donc installer un extra de fournisseur, par exemple pip install "giskard[openai]", et définir la clé d'API correspondante. Le modèle par défaut indiqué est openai/gpt-4o-mini. Autrement dit, le premier exemple du README ne fonctionne pas hors ligne : il consomme un appel à un fournisseur externe dès la première vérification.
Le scan de vulnérabilités et l'évaluation RAG
giskard-scan s'installe par pip install "giskard[scan]" ou directement par pip install giskard-scan. Le README le présente comme la couche de red teaming et de scan de vulnérabilités pour systèmes agentiques, et mentionne vulnerability_scan comme successeur du Scan de la v2, ainsi que quality_scan comme successeur de RAGET, l'outil v2 de génération de jeux de test. Les thèmes cités incluent l'injection de prompt, les jailbreaks et les contenus nuisibles. Le README de la version fournie s'interrompt au milieu de la phrase de présentation de giskard-scan, avant toute description de l'API, des paramètres ou du format de rapport. Je ne peux donc pas décrire la façon dont un scan se déclenche, ce qu'il renvoie, ni combien de temps il prend. C'est une lacune du matériau, pas une caractéristique du projet, et il faut aller sur docs.giskard.ai pour trancher. Un point est en revanche explicite : la réécriture supprime des dépendances lourdes, et le scan comme l'évaluation RAG sont désormais livrés nativement dans giskard-scan, sans dépendance à la v2.
La rupture v2 vers v3, et ce qu'elle laisse derrière
Le README est direct : Giskard v2 reste disponible mais n'est plus activement maintenu. La v3 est une réécriture complète, pas une évolution incrémentale. Cela signifie que du code écrit contre l'API v2 ne se transposera pas par un simple changement de version, et que les deux branches de documentation coexistent, la v2 renvoyant vers legacy-docs.giskard.ai. Une exception notable subsiste : seul le scan historique pour modèles tabulaires et ML reste en v2. Si votre usage est la validation de modèles tabulaires, la v3 ne le couvre pas, et vous dépendez d'une branche dont le README dit elle-même qu'elle n'est plus activement maintenue. C'est la limitation la plus nette du projet, et elle n'est pas présentée comme temporaire. Le maintien d'une double documentation et d'une branche gelée a un coût pour l'équipe, et un coût de migration pour les utilisateurs existants.
Alternative : DeepEval et la différence de découpage
DeepEval, également en Python, part d'une autre hypothèse : une bibliothèque unique qui fournit des métriques prêtes à l'emploi et s'intègre aux frameworks de test existants comme pytest, avec une couche d'observabilité associée. Giskard v3 fait le choix inverse. Il éclate la surface en paquets installables séparément, garde le scan de vulnérabilités et l'évaluation RAG dans un paquet distinct des vérifications, et centre son API sur l'objet Scenario plutôt que sur la métrique. La conséquence pratique : avec giskard-checks, une vérification est un objet attaché à une interaction dans un scénario, exécuté par un run asynchrone, alors qu'une approche par métrique évalue généralement une entrée et une sortie sans modéliser la conversation. Pour du multi-tours avec trace, la structure de Giskard est plus explicite. Pour une assertion rapide sur un seul appel de modèle, elle demande plus de câblage. Aucune des deux n'est meilleure dans l'absolu ; le critère est de savoir si votre unité de test est un échange ou une conversation.
Installation, télémétrie et licence
Le prérequis est Python 3.12 ou supérieur, ce qui exclut les environnements encore en 3.10 ou 3.11 sans mise à niveau. Trois commandes couvrent l'essentiel : pip install giskard pour les vérifications et les paquets de base, pip install "giskard[scan]" pour ajouter le scan, et pip install "giskard[openai]" pour le SDK d'un fournisseur utilisé par les juges et les générateurs. La télémétrie est présentée comme optionnelle et agrégée, via giskard-core, sans envoi de prompts ni de sorties. Deux variables permettent de la couper : DO_NOT_TRACK=1 ou GISKARD_TELEMETRY_DISABLED=1, dans l'environnement ou dans un fichier .env du répertoire de travail. Le README précise que les définir avant l'import évite la création de ~/.giskard/id, et que les définir plus tard arrête les envois suivants. Le projet est sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'état des modifications. Je ne suis pas juriste et cette lecture ne remplace pas un avis juridique. Sur la maintenance, les notes de version montrent des publications rapprochées fin août 2026 pour giskard v3.0.0, giskard-scan et giskard-llm, ce qui indique un rythme actif mais aussi une API encore jeune, où les ruptures entre versions mineures restent possibles.
Conclusion éditoriale
Giskard v3 s'adresse aux équipes Python 3.12+ qui testent des agents ou des pipelines RAG non déterministes et qui veulent écrire leurs scénarios dans du code plutôt que dans une interface. Passez votre chemin si votre besoin porte sur des modèles tabulaires : le README indique que seul le scan tabulaire reste en v2, et que la v2 n'est plus activement maintenue. Avant d'adopter, vérifiez deux points précis : que votre version de Python est bien 3.12 ou supérieure, et que le paquet giskard-scan installé correspond à une version publiée, car les notes de version listent giskard-scan/v1.0.0 et giskard-llm/v1.0.0 comme des versions indépendantes du giskard v3.0.0.
Notes de la communauté