Chaque modification de votre IA doit passer des tests
Un changement de prompt anodin qui divise par deux la qualité des réponses. Une mise à jour du modèle fournisseur qui casse le format de sortie. Un ajout de documents dans l'index qui pollue les résultats existants. Ces régressions sont fréquentes et silencieuses dans les applications LLM. La solution : un protocole de tests de non-régression adapté aux spécificités des LLM — évaluation sémantique plutôt qu'égalité exacte, seuils de tolérance configurables, et automatisation CI/CD. Nos clients qui testent avant chaque déploiement détectent 92% des régressions avant la mise en production.
Le problème
Les applications LLM sont par nature fragiles. Contrairement à un logiciel classique où les entrées et sorties sont déterministes, un assistant IA est sensible à des dizaines de paramètres interconnectés : le contenu du prompt, la version du modèle, la composition de l'index vectoriel, les paramètres de retrieval, la temperature, et même l'ordre des chunks dans le contexte.
Les causes de régression les plus courantes :
- Modification du prompt — Un développeur ajoute une instruction au prompt système pour corriger un cas edge. La correction fonctionne, mais dégrade 15% des réponses sur d'autres catégories de questions. Sans suite de tests, la régression passe inaperçue pendant des semaines.
- Mise à jour du modèle fournisseur — OpenAI, Anthropic et Google mettent à jour leurs modèles régulièrement (nouvelles versions, dépréciations). Chaque mise à jour peut modifier le comportement du modèle sur vos cas d'usage spécifiques. Un prompt optimisé pour GPT-4o-2025-05 peut produire des résultats différents sur GPT-4o-2025-08.
- Évolution de l'index documentaire — L'ajout de 500 nouveaux documents dans votre base vectorielle peut polluer le retrieval pour les requêtes existantes. Les nouveaux chunks entrent en compétition avec les anciens dans le top-K. Le retriever remonte des documents moins pertinents pour des questions qui fonctionnaient bien avant.
- Changement de configuration — Modifier le nombre de chunks récupérés (de 5 à 10), le modèle d'embedding, ou les paramètres de reranking impacte toute la chaîne en cascade. Chaque paramètre interagit avec les autres de manière non linéaire.
La solution IA
Un protocole de tests de non-régression pour LLM s'articule autour de trois composants : un jeu de tests de référence, des assertions sémantiques, et une intégration CI/CD.
Suite de tests de référence (Golden Set)
Constituez un jeu de 200 à 500 cas de test couvrant vos catégories de requêtes : factuelles (40%), comparatives (20%), procédurales (20%), multi-documents (10%), hors scope (10%). Chaque cas inclut : la question, la réponse attendue, les sources pertinentes, et les critères d'évaluation spécifiques. Versionnez le Golden Set dans Git et mettez-le à jour trimestriellement.
Assertions sémantiques
Remplacez les assertEqual par des assertions sémantiques : la réponse contient-elle les points clés attendus (recall sémantique) ? Est-elle fidèle aux sources (faithfulness > 0.85) ? Respecte-t-elle le format attendu (JSON valide, citations présentes) ? Utilisez DeepEval ou Ragas comme framework d'assertion. Définissez des seuils par catégorie de test : plus strict pour les questions réglementaires, plus tolérant pour les résumés.
Automatisation CI/CD
Intégrez la suite de tests dans votre pipeline CI/CD. Déclenchement automatique sur chaque PR qui modifie un prompt, un paramètre du pipeline ou la configuration du modèle. Exécution sur un environnement de staging avec un index de test stable. Le pipeline bloque le merge si une métrique passe sous le seuil. Rapport détaillé avec les cas de test échoués et les scores comparatifs avant/après.
Mise en oeuvre
La mise en place d'une suite de non-régression LLM prend 3 à 5 semaines. Voici les trois phases clés.
Construction du Golden Set (semaines 1-2)
Collectez les 200 questions les plus représentatives de vos utilisateurs (logs de production). Pour chaque question, générez une réponse avec votre pipeline actuel et faites-la valider par un expert métier. Annotez : la réponse est-elle correcte, complète, bien sourcée ? Stockez le tout dans un fichier JSON versionné. Catégorisez par type de requête et par criticité (bloquant, majeur, mineur). Prévoyez 20% de questions pièges pour tester le refus.
Framework d'assertions (semaines 3-4)
Implémentez les assertions avec DeepEval : assert_test() pour chaque cas, avec des métriques de faithfulness, relevance et format. Configurez les seuils par catégorie : réglementaire (faithfulness > 0.90), informatif (> 0.80), conversationnel (> 0.70). Ajoutez des assertions de format : présence de citations, longueur min/max, pas de données personnelles. Exécutez la suite complète et corrigez les faux positifs (cas de test mal formulés).
Intégration CI/CD et maintenance (semaine 5+)
Intégrez dans GitHub Actions ou GitLab CI : exécution automatique sur chaque PR touchant le dossier prompts/, config/ ou models/. Parallélisez l'exécution des tests (5 workers, 200 tests en ~10 minutes). Configurez un rapport de comparaison avant/après visible dans la PR. Maintenez le Golden Set : ajoutez 10 nouveaux cas par mois, retirez les cas obsolètes, recalibrez les seuils trimestriellement.
Résultats
Résultats mesurés après mise en place de tests de non-régression sur des assistants IA en production.
Questions fréquentes
Pourquoi les tests classiques ne suffisent-ils pas pour un LLM ?
Les tests unitaires classiques vérifient des sorties déterministes (assertEqual). Un LLM produit des sorties non déterministes : la même question peut générer deux réponses différentes, toutes deux correctes. Les tests de non-régression LLM doivent évaluer la qualité sémantique (la réponse est-elle fidèle, pertinente, complète ?) plutôt que l'égalité exacte. Cela nécessite des métriques spécifiques (embeddings similarity, LLM-as-Judge) et des seuils de tolérance.
Que tester avant de changer de modèle LLM ?
Exécutez votre suite de non-régression complète (200+ cas de test) sur le nouveau modèle et comparez les scores de faithfulness, relevance et format compliance avec l'ancien modèle. Seuils recommandés : aucune métrique ne doit baisser de plus de 3 points. Testez aussi la latence et le coût par requête. Prévoyez un déploiement canary (10% du trafic) pendant 1 semaine avant le basculement complet.
Comment automatiser les tests de non-régression dans un pipeline CI/CD ?
Intégrez les tests dans votre pipeline GitHub Actions, GitLab CI ou Jenkins. À chaque pull request qui modifie un prompt, un modèle ou la configuration du RAG, le pipeline exécute automatiquement la suite de tests sur un environnement de staging. Utilisez DeepEval ou Ragas en mode pytest pour les assertions. Le pipeline bloque le merge si une métrique passe sous le seuil. Temps d'exécution typique : 5 à 15 minutes pour 200 cas de test.
Pour les profils tech
Implémentation technique des tests de non-régression LLM
L'implémentation repose sur DeepEval (framework pytest pour LLM) ou Ragas avec un wrapper pytest. Chaque test case est défini comme un tuple (input, expected_output, context) et évalué par des métriques sémantiques plutôt que par égalité exacte.
Structure du Golden Set (JSON) :
Chaque entrée contient : id, category (factual/comparative/procedural/out_of_scope), question, expected_answer, expected_sources (array de doc_ids), evaluation_criteria (métriques et seuils spécifiques), severity (critical/major/minor).
Types d'assertions recommandés :
- Faithfulness — La réponse est-elle fidèle au contexte ? Seuil configurable par catégorie. Implémentation : Ragas faithfulness ou DeepEval FaithfulnessMetric.
- Semantic similarity — La réponse est-elle sémantiquement proche de la réponse attendue ? Cosinus sur embeddings, seuil > 0.75. Utile pour vérifier la complétude.
- Format compliance — La réponse respecte-t-elle le format attendu ? JSON valide, citations présentes, longueur dans les bornes. Assertions classiques (assertEqual, assertContains).
- Toxicity / Safety — La réponse ne contient-elle pas de contenu dangereux ? Guardrails AI ou modèle de classification toxicité. Seuil : 0 tolérance.
Comparatif des frameworks de test LLM
| Critère | DeepEval | Ragas + pytest | Promptfoo | Custom (maison) |
|---|---|---|---|---|
| Facilité d'intégration CI/CD | Excellent (pytest natif) | Bon | Bon (CLI) | Variable |
| Nombre de métriques | 14 métriques | 8 métriques | 5 métriques | Sur mesure |
| Rapports de comparaison | Confident AI | Basique | Web UI | À développer |
| Coût | Open source | Open source | Open source | Temps dev |
| Courbe d'apprentissage | Faible | Moyenne | Faible | Élevée |