Évaluer la qualité de l'IA (évaluations)
Si vous mettez en production quoi que ce soit reposant sur l'IA, les évaluations sont ce qui vous permet de savoir que cela fonctionne — et de savoir qu'un changement l'a amélioré, et non dégradé. Sans elles, vous volez à l'aveugle : un ajustement de prompt qui aide un cas peut silencieusement en casser dix autres.
L'évaluation minimale viable
Vous n'avez pas besoin d'un framework pour démarrer :
- Constituez un jeu de référence. 20 à 100 entrées réelles avec les sorties correctes ou acceptables (ou des critères clairs). Couvrez les cas faciles, les cas délicats et les cas limites qui vous ont déjà mordu.
- Définissez ce que « bon » signifie par tâche — correspondance exacte, contient les faits clés, schéma JSON valide, aucun chiffre halluciné, ton, etc.
- Exécutez et notez votre configuration actuelle face au jeu.
- Changez une seule chose (prompt, modèle, récupération), réexécutez, comparez. Ne conservez le changement que si le score s'améliore.
Choisir les métriques
- Contrôles déterministes lorsque c'est possible : le schéma est-il valide ? contient-il la bonne valeur ? le code passe-t-il les tests ? Ils sont peu coûteux et dignes de confiance.
- LLM comme juge pour la qualité floue (utilité, ton) : faites noter les sorties par un modèle selon une grille. Utile mais calibrez-le — les juges ont des biais (longueur, position). Validez le juge face à des notes humaines sur un échantillon.
- Relecture humaine pour la tranche aux plus forts enjeux.
Quand les exécuter
- Avant/après tout changement de prompt ou de modèle.
- Lors d'une migration de modèle — un nouveau modèle peut modifier le comportement (Erreurs et migration).
- En CI pour les systèmes en production, comme garde-fou.
:::tip Séparez les étapes Pour le RAG et les agents, évaluez chaque étape (la récupération a-t-elle trouvé le bon document ? l'outil a-t-il été appelé correctement ?) — pas seulement la réponse finale. Cela localise les défaillances. :::