Guide
DeepEval : écrire des tests d'IA comme des tests pytest
DeepEval en pratique : installer, écrire un test avec G-Eval, choisir le modèle juge, lancer deepeval test run. Exemple de code d'après la documentation.
Mis à jour le
DeepEval est une bibliothèque Python qui fait des tests d'une application d'IA des tests comme les autres : on écrit une fonction de test, on décrit l'entrée, la réponse obtenue et la réponse attendue, on choisit une métrique, et la commande deepeval test run dit ce qui passe et ce qui échoue. Son dépôt le résume ainsi : « semblable à Pytest, mais spécialisé dans les tests unitaires d'applications LLM ». Licence Apache 2.0, Python 3.10 ou plus.
Installer
pip install -U deepeval
Le test le plus utile : G-Eval
G-Eval est la métrique la plus polyvalente de DeepEval : un modèle juge note la réponse selon un critère que vous écrivez en langage naturel. Elle reprend la méthode G-Eval publiée par Liu et al. (article soumis le 29/03/2023, arXiv 2303.16634) : un modèle de langage qui raisonne étape par étape, puis remplit un formulaire d'évaluation.
D'après la documentation, le calcul se déroule ainsi :
- si vous n'avez pas écrit d'étapes d'évaluation, le juge les génère à partir de votre critère ;
- ces étapes et les champs du test sont assemblés en un formulaire ;
- le juge attribue une note, que DeepEval ramène entre 0 et 1, en la pondérant par les probabilités des jetons quand le modèle le permet.
Un test d'exactitude, d'après l'exemple du dépôt et de la documentation :
from deepeval import assert_test
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, SingleTurnParams
exactitude = GEval(
name="Exactitude",
evaluation_steps=[
"Vérifier que la sortie ne contredit aucun fait de la sortie attendue",
"Pénaliser fortement l'oubli d'une information de la sortie attendue",
"Accepter une formulation différente si le sens est le même",
],
evaluation_params=[
SingleTurnParams.INPUT,
SingleTurnParams.ACTUAL_OUTPUT,
SingleTurnParams.EXPECTED_OUTPUT,
],
threshold=0.7,
)
def test_horaires():
cas = LLMTestCase(
input="Quels sont vos horaires d'ouverture ?",
actual_output=repondre("Quels sont vos horaires d'ouverture ?"),
expected_output="Du lundi au vendredi, de 9 h à 18 h.",
)
assert_test(cas, [exactitude])
repondre est votre propre fonction, celle qui appelle l'assistant. Les horaires sont un exemple à remplacer par les vôtres. On lance le fichier avec deepeval test run test_assistant.py.
Les paramètres qui comptent
| Paramètre | Rôle | Défaut |
|---|---|---|
name |
nom de la métrique dans les rapports | obligatoire |
criteria ou evaluation_steps |
le critère en une phrase, ou les étapes détaillées (l'un ou l'autre, pas les deux) | obligatoire |
evaluation_params |
champs du test que le juge lit ; n'y mettez que ceux que citent vos étapes | obligatoire |
threshold |
score minimal pour réussir | 0,5 |
strict_mode |
rend le score binaire (0 ou 1) | désactivé |
model |
le modèle juge | modèle d'OpenAI |
La documentation signale que G-Eval n'est pas déterministe. Écrire les étapes à la main au lieu d'un simple critère rend les scores plus reproductibles ; pour un contrôle plus strict, elle oriente vers une autre métrique, DAGMetric, qui suit un arbre de décision.
Choisir le modèle juge
Le juge par défaut est un modèle d'OpenAI, qui demande la clé correspondante. La documentation décrit des commandes pour changer de juge pour toutes les métriques : deepeval set-gemini, deepeval set-ollama (un modèle qui tourne sur votre machine), deepeval set-azure-openai, et côté TypeScript npx deepeval set-anthropic. Pour tout autre modèle, on hérite de la classe DeepEvalBaseLLM et l'on implémente quatre méthodes (get_model_name, load_model, generate, a_generate).
Deux mises en garde de la documentation : un modèle personnalisé doit être passé à chaque métrique, et le bon fonctionnement n'est pas garanti avec un modèle qui raisonne mal ou produit un JSON invalide. Choisissez un juge solide, différent du modèle évalué, et vérifiez-le : voir LLM as a judge.
Les autres métriques
Le dépôt liste des métriques prêtes à l'emploi pour la recherche documentaire (pertinence de la réponse, fidélité, précision et rappel du contexte), pour les agents (réussite de la tâche, justesse des appels d'outils), et des contrôles d'hallucination, de biais, de toxicité ou de format JSON. Leur sens est expliqué sur les métriques.
Quand préférer DeepEval
Quand votre équipe écrit déjà des tests en Python et veut que l'évaluation tourne au même endroit que les autres tests. Si vous préférez décrire les cas dans un fichier sans écrire de code, promptfoo est plus direct ; pour comparer les outils, voir le comparatif.
Questions fréquentes
Quel modèle juge DeepEval utilise-t-il par défaut ?
La documentation indique qu'un modèle d'OpenAI est le juge par défaut. Des commandes permettent d'en changer (Gemini, Ollama, Azure), et une classe DeepEvalBaseLLM permet de brancher n'importe quel modèle.
Peut-on donner à G-Eval à la fois des critères et des étapes ?
Non : la documentation précise qu'on fournit soit criteria, soit evaluation_steps. Des étapes écrites à la main rendent les scores plus reproductibles.
Sources
Pages consultées pour écrire cet article :