- Les applications basées sur des LLM (grands modèles de langage) sont difficiles à évaluer correctement avec des méthodes de test traditionnelles en raison de leur caractère de sortie non déterministe
- Il est donc indispensable d’utiliser des méthodes d’évaluation dédiées (evals) pour maintenir et améliorer les performances des systèmes LLM
Pourquoi les evals sont importantes
- Établir des références de performance : fournir une direction pour les performances du modèle et définir des benchmarks comparables
- Assurer cohérence et fiabilité : détecter et maîtriser à l’avance les sorties imprévisibles
- Donner des axes d’amélioration : identifier clairement les points de dégradation pour permettre des améliorations ciblées
- Permettre les tests de régression : vérifier que les performances sont maintenues après des changements afin de garantir la stabilité
Éléments clés de l’évaluation avant déploiement
Pourquoi l’évaluation avant déploiement est importante
- Mesurer les performances tôt et les comparer
- Détecter à l’avance les problèmes de régression lors de changements de code, de prompt ou de paramètres
Comment réaliser l’évaluation
1. Créer un dataset de Ground Truth
- Un dataset composé de paires question-réponse rédigées par des experts est nécessaire
- Il est important d’y inclure divers scénarios reflétant les types de questions réelles des utilisateurs
Un LLM peut-il générer la Ground Truth ?
- Un LLM peut jouer un rôle d’assistant, mais il n’est pas recommandé de le laisser la produire seul
- Compréhension insuffisante du comportement utilisateur
- Les questions et réponses adaptées au contexte nécessitent une relecture humaine
- Une validation humaine est indispensable pour garantir l’adéquation métier et la qualité
2. Choisir les métriques d’évaluation
- Answer relevancy : le système fournit-il une réponse directe et pertinente à la question ?
- Coherence : flux logique et clarté de la réponse
- Contextual relevance : dans quelle mesure le contexte de la conversation est bien pris en compte
- Responsibility : caractère responsable de la sortie, notamment sur les plans éthique, nocif ou biaisé
3. Métriques d’évaluation RAG
- Métriques de génération :
- Faithfulness : fidélité aux faits
- Answer relevancy : pertinence de la réponse
- Métriques de recherche :
- Context precision : rapport signal/bruit dans les informations pertinentes
- Context recall : capacité à retrouver les informations nécessaires pour obtenir la bonne réponse
4. Métriques spécifiques à la tâche
- Des métriques sur mesure adaptées à une tâche donnée sont nécessaires
- Exemple : pour le résumé, Fluency, Coherence, Consistency, Relevance
5. Calcul des scores et tuning du système
- Pour chaque métrique, on calcule un score en comparant la sortie réelle à la Ground Truth
- Exemples :
- Recall faible : réduire la taille des chunks
- Precision faible : envisager l’introduction d’un reranking
- Exemples de bibliothèques d’évaluation : DeepEval, Relari-ai
Méthode d’évaluation LLM-as-Judge
- Évaluer sans Ground Truth à partir d’un LLM comme GPT-4
- Exemples : framework G-eval, articles sur Vicuna et QLoRA
- Inconvénients :
- Certaines métriques (ex. : Context Recall) ne peuvent pas être mesurées sans Ground Truth
- En matière de précision et de finesse, l’évaluation humaine reste supérieure
- Conclusion : l’idéal est de combiner LLM-as-Judge et Ground Truth
Comment intégrer l’évaluation à l’étape de déploiement
- Intégrer l’automatisation de l’évaluation dans le pipeline de déploiement
- Exécuter des tests automatiques avant un commit de code ou un déploiement
- Exemple : utiliser Giskard pour des tests automatiques de détection de nocivité et d’hallucinations
- Il faut aussi inclure des tests sur les étapes de prétraitement et de collecte des données
Évaluation après déploiement et data flywheel
Monitoring en production
- Suivi en temps réel des entrées/sorties
- Sessions d’évaluation régulières avec des experts métier
- Mise en place de canaux de feedback utilisateur
Stratégie de data flywheel
- Construire une boucle d’amélioration continue en exploitant les données et retours collectés en production
- Exemple : analyser les patterns de questions des utilisateurs → améliorer la méthode de recherche
- Ajuster les prompts, les paramètres d’inférence, la méthode de recherche, etc. à partir des métriques
- Il peut aussi être nécessaire de faire évoluer les métriques selon les comportements utilisateurs et les scénarios d’échec
Conclusion : la stratégie « Evals First » est au cœur des produits LLM fiables
- Il faut adopter une approche centrée sur l’évaluation dès le début du développement d’applications LLM
- L’essentiel consiste à définir tôt les bonnes métriques et les bons critères, puis à les utiliser comme point de référence pour le développement et le déploiement
- Il faut faire de l’évaluation non pas une activité a posteriori, mais un processus central de développement, afin de construire des systèmes d’IA fiables centrés sur l’utilisateur
1 commentaires
D’après mon expérience, et comme on le voit aussi dans d’autres cas comme https://blog.lawrencejones.dev/ai-mvp/, les modèles les plus récents ne garantissent pas forcément de meilleurs résultats. Chaque fois qu’on ajuste le modèle ou le prompt, il faut faire une évaluation à l’aide d’un jeu de données ; et même si un LLM peut aider à évaluer, il y a quelque chose d’un peu ironique dans le fait qu’un humain doive quand même créer manuellement, une par une, les données de vérité terrain pour le modèle de LLM haha.