L’utilisateur veut comprendre l’évaluation dans le contexte de l’évaluation et du suivi des modèles, et l’appliquer à un travail pratique de gouvernance ou de conformité de l’IA.
L’évaluation est le processus qui consiste à mesurer la qualité, le comportement ou la performance d’un modèle, d’un système ou d’un changement par rapport à des critères définis. En apprentissage automatique, elle peut utiliser des données de validation et de test, tandis que l’évaluation des LLM peut aussi inclure la sécurité, la factualité, la robustesse et l’impact sur les utilisateurs.
L’évaluation de modèle est le processus structuré qui consiste à vérifier dans quelle mesure un modèle d’IA ou un système d’IA fonctionne par rapport à des critères définis avant et après son déploiement. Elle peut mesurer la qualité prédictive, la robustesse, l’équité, la sécurité, la factualité, la latence, l’utilisabilité et l’impact opérationnel. L’évaluation est plus large qu’un seul benchmark ou qu’une seule métrique, car elle demande si le système est adapté à un objectif, à un groupe d’utilisateurs et à un contexte de risque précis. Dans Caesar AI Atlas, cette page doit relier les notions d’évaluation, de benchmark et de métrique.
L’évaluation est l’étape de collecte de preuves qui répond à la question suivante : ce modèle fonctionne-t-il réellement assez bien pour la tâche que nous voulons lui confier ? Un modèle de détection de fraude, un modèle de triage médical et un chatbot ne peuvent pas être jugés par le même test unique. Chacun a besoin de critères correspondant à son usage prévu, aux conséquences des erreurs et à l’environnement dans lequel des personnes s’appuieront sur lui.
Analogie
C’est comme tester un véhicule non seulement sur sa vitesse, mais aussi sur son freinage, sa tenue de route, sa sécurité et son adéquation à la route sur laquelle il circulera.
L’évaluation de modèle est importante parce que de nombreuses défaillances de l’IA viennent d’une confiance accordée à un modèle qui a bien réussi un test étroit, mais qui a échoué dans des conditions réelles. Les équipes juridiques, risques et conformité ont besoin de dossiers d’évaluation pour comprendre si les affirmations relatives à la performance, à la sécurité, aux biais ou à la fiabilité sont étayées par des preuves. L’évaluation aide aussi à décider si un système peut passer du prototype au pilote, du pilote à la production, ou de la production au réentraînement ou au retrait.
Urgence
Les équipes devraient définir les critères d’évaluation avant le déploiement, et non après que des réclamations, constats d’audit ou incidents ont révélé des lacunes.
Un plan d’évaluation pratique doit définir l’usage prévu, les questions d’évaluation, les jeux de données, les benchmarks, les métriques, les seuils d’acceptation, les responsables de revue et les limites. Il doit distinguer, lorsque c’est possible, la validation de développement des tests indépendants, en particulier pour les usages à risque plus élevé. Le plan doit inclure des vérifications relatives au déséquilibre des classes, aux performances par sous-groupe, aux cas limites, aux comportements adversariaux, à la dérive des données et à l’efficacité de la supervision humaine. Pour les systèmes génératifs, l’évaluation doit également couvrir les hallucinations, le comportement de refus, la résistance à l’injection de prompt, l’ancrage dans les sources, les fuites de données personnelles et l’usage dangereux d’outils. Les résultats doivent être documentés sous une forme compréhensible par les équipes gouvernance, ingénierie, produit et juridique.
Une erreur fréquente consiste à traiter l’évaluation de modèle comme un score unique dans un classement public. Une autre erreur consiste à évaluer uniquement l’exactitude technique tout en ignorant l’impact sur les utilisateurs, l’équité, les usages abusifs, la sécurité, la confidentialité ou les contraintes opérationnelles. Les équipes s’appuient aussi trop sur des données de test trop propres, trop anciennes ou trop similaires aux données d’entraînement. Pour les LLM, il est particulièrement risqué de tester seulement des prompts idéaux et d’ignorer les erreurs de récupération, les défaillances d’outils, l’injection de prompt et la factualité propre au domaine.
Utiliser la seule accuracy pour une tâche déséquilibrée
Tester uniquement en anglais alors que le produit prend en charge plusieurs langues
Réutiliser des données de benchmark contaminées
Ignorer la performance après le déploiement
Cette réponse doit renvoyer aux contenus Atlas sur les benchmarks, les métriques, la précision, le rappel, l’accuracy, le score F1, le suivi, la dérive de modèle et l’évaluation des risques liés à l’IA. Elle doit aussi soutenir les pages de comparaison qui distinguent l’évaluation du benchmark et de la métrique. Lorsque des exemples d’incidents sont disponibles, ils doivent être utilisés pour montrer comment une évaluation faible peut devenir un problème de gouvernance et de sécurité.