Évaluer les modèles d’IA au-delà du classement
Comprenez la mesure d’un benchmark et créez des cas propres au produit. Comparez résultats, erreurs, coût et effort de revue.
Deux modèles sont proches dans un classement. L’un peut mieux convenir parce qu’il respecte un format ; l’autre parce qu’il examine une erreur difficile. Une position générale ne révèle pas la capacité qui manque au travail.
Un benchmark aide à formuler une hypothèse. Pour en faire une décision de produit, il faut des tâches, outils et critères représentatifs de votre activité.
Lire d’abord ce qui est mesuré
SWE-bench présente plusieurs variantes et des résultats par tâches résolues. Une note s’interprète avec le jeu et l’environnement utilisés.
Vérifiez si le système a reçu un énoncé seul ou des fichiers, un terminal et un navigateur. Examinez durée, tentatives, version et sélection de la réponse. Plusieurs essais ne doivent pas être comparés silencieusement à une réponse unique.
Distinguez modèle et agent complet. Un même modèle peut agir différemment avec d’autres instructions, récupération du contexte et outils. Quand tout change ensemble, le résultat décrit le système.
Créer des cas liés aux décisions
Pour un assistant de code, réunissez corrections, petites extensions, lecture et tâches devant s’arrêter faute de contexte ou de permission. Incluez des erreurs discrètes, comme interroger le mauvais compte client.
Écrivez le résultat attendu avant l’exécution. Pour un export, vérifiez filtres, tri, colonnes, absence de données et autorisation. « Le fichier a été créé » ne suffit pas s’il contient les informations d’un autre client.
Séparer les types d’erreur
| Critère | Vérification |
|---|---|
| Correction | Le cas et ses variantes sont-ils traités ? |
| Contraintes | Accès, périmètre et données sont-ils respectés ? |
| Utilité | Peut-on utiliser le livrable sans le refaire ? |
| Effort | Combien coûtent essais, attente et revue ? |
Définissez les erreurs bloquantes malgré une bonne moyenne. Un modèle classant presque tout correctement mais divulguant une donnée interdite demande une réponse différente d’une étiquette erronée soumise à validation.
Conserver le résultat, pas seulement l’explication
La référence d’Anthropic sur les évaluations distingue trace d’exécution et état final. Affirmer qu’un élément a changé ne prouve pas que le bon enregistrement a été modifié.
Répétez les cas pour observer la variation et conservez toutes les tentatives prévues. Ne cachez pas un essai raté parce que le suivant fonctionne. Si un autre modèle note les sorties, calibrez ses critères avec des revues humaines et des erreurs connues.
En faire une routine
Réservez des cas qui ne serviront pas à ajuster les instructions. Rejouez-les après un changement de modèle, configuration ou outils. Un ancien résultat ne décrit plus exactement le système modifié.
Le choix d’un modèle pour SaaS fournit une décision concrète. Le cycle de développement avec l’IA intègre l’évaluation à la livraison. Le classement présélectionne ; le comportement observé détermine l’acceptation.
À propos de l’auteur
Tiago F SantiagoCommentaires
Aucun commentaire pour le moment
Partagez une question ou une expérience en lien avec cet article.
Articles sur le même sujet
