L'évaluation en IA est d'une difficulté trompeuse parce que ce qu'on essaie de mesurer — « est-ce que cette sortie est bonne? » — est souvent subjectif, dépendant du contexte et multidimensionnel. La réponse d'un modèle à « explique l'intrication quantique » pourrait être précise mais trop technique pour le public, ou accessible mais légèrement fausse, ou parfaitement correcte mais ennuyeuse. Les tests logiciels traditionnels ont des critères de réussite/échec clairs. L'évaluation en IA en a rarement. C'est pourquoi le domaine a développé plusieurs approches complémentaires : des bancs d'essai automatisés pour la mesure de capacités larges, l'évaluation humaine pour le jugement de qualité, le LLM-comme-juge pour des approximations évolutives du jugement humain, et des métriques spécifiques à une tâche pour des domaines étroits. Aucune approche seule ne suffit. Les équipes qui évaluent bien les utilisent toutes en couches.
Les bancs d'essai publics comme MMLU, HumanEval, MATH et GPQA vous donnent un moyen standardisé de comparer des modèles sur des tâches bien définies. Ils sont utiles pour avoir une idée approximative des capacités d'un modèle et pour suivre les progrès au fil du temps. Mais ils ont des limitations sérieuses qu'il faut comprendre avant de s'y fier. La contamination des bancs d'essai est répandue — les données d'entraînement incluent souvent des questions des bancs d'essai, donc des scores élevés peuvent refléter de la mémorisation plutôt qu'une capacité réelle. La saturation des bancs d'essai signifie que lorsque la plupart des modèles de pointe dépassent 90 % sur un test, il cesse d'être informatif. Et le problème le plus fondamental est que les bancs d'essai testent des compétences étroites et bien définies, alors que les applications réelles nécessitent un raisonnement large, désordonné et dépendant du contexte. Un modèle qui obtient 92 % sur MMLU et 87 % sur HumanEval pourrait être terrible pour votre cas d'utilisation spécifique — écrire des contrôleurs Symfony, résumer des documents juridiques en français, ou générer du SQL pour votre schéma particulier. Les bancs d'essai vous disent ce qu'un modèle peut faire en général. Vos propres évaluations vous disent ce qu'il peut faire pour vous.
Le travail d'évaluation le plus précieux que vous puissiez faire est de construire une suite de tests spécifique à votre application. Commencez par collecter 50 à 100 exemples réels d'entrées que votre système verra, avec ce à quoi une bonne sortie ressemble. Ceux-ci peuvent être de vraies requêtes d'utilisateurs, des cas limites synthétiques, ou des entrées adverses qui sondent des modes de défaillance connus. Pour chaque exemple, définissez ce que « correct » signifie aussi concrètement que possible — mots-clés attendus, structure requise, affirmations factuelles qui doivent être présentes ou absentes, critères de ton. Puis automatisez l'évaluation : exécutez votre prompt contre chaque exemple, notez les sorties (en utilisant la correspondance exacte, des expressions régulières ou un LLM-comme-juge), et suivez les résultats dans le temps. Des outils comme Braintrust, Langfuse et Promptfoo facilitent la tâche, mais vous pouvez aussi le faire avec un tableur et un script. L'important est d'avoir un processus reproductible pour que lorsque vous changez un prompt, remplacez un modèle ou mettez à jour votre pipeline de récupération, vous puissiez voir immédiatement si les choses se sont améliorées ou dégradées.
Utiliser un LLM pour évaluer la sortie d'un autre LLM — le pattern « LLM-comme-juge » — est devenu l'approche par défaut pour une évaluation évolutive. On donne à un modèle puissant (typiquement GPT-4 ou Claude) la question originale, la réponse du modèle et une grille d'évaluation, et on lui demande de noter la réponse sur des critères comme la précision, l'utilité et la sécurité. Cela fonctionne étonnamment bien pour de nombreuses tâches, surtout quand on fournit des grilles détaillées et des exemples de calibration. Mais cela a des angles morts : les juges LLM tendent à préférer les réponses plus longues, ils peuvent manquer des erreurs factuelles subtiles, et ils exhibent un biais de position (favorisant la réponse qui apparaît en premier dans une comparaison par paires). L'évaluation humaine reste la référence pour les applications sensibles à la qualité. Des services comme Scale AI et Surge fournissent des annotateurs formés, mais même une revue humaine informelle — demander à trois membres de l'équipe de noter indépendamment 50 sorties — détecte des modes de défaillance que l'évaluation automatisée manque. Les pipelines d'évaluation les plus robustes utilisent des métriques automatisées comme filtre rapide, le LLM-comme-juge pour les décisions de confiance moyenne, et la revue humaine pour les cas à enjeux élevés ou ambigus.
La partie la plus difficile de l'évaluation n'est pas technique — c'est culturel. Les équipes qui livrent d'excellents produits IA traitent l'évaluation comme une discipline d'ingénierie de premier ordre, pas comme une réflexion après coup. Elles écrivent les évaluations avant d'écrire les prompts, de la même façon que les bons développeurs écrivent les tests avant d'écrire le code. Elles maintiennent des suites d'évaluation vivantes qui grandissent à mesure qu'elles découvrent de nouveaux modes de défaillance en production. Et elles résistent à la tentation d'optimiser pour les scores de bancs d'essai au détriment de la performance en conditions réelles. Si votre modèle obtient d'excellents résultats sur votre suite d'évaluation mais que les utilisateurs se plaignent, ce sont vos évaluations qui ont tort, pas vos utilisateurs. Les meilleurs cadres d'évaluation sont ceux qui vous gardent honnête sur ce que votre système fait réellement, surtout dans les cas où il échoue.