L’évaluation humaine reste la méthode la plus précise pour évaluer les résultats de l’apprentissage tout au long de la vie, mais elle n’est pas suffisamment évolutive.

À mesure que nous intégrons l’IA générative dans des produits du monde réel, la nécessité d’obtenir des résultats fiables devient cruciale. À l’heure actuelle, le moyen le plus précis d’évaluer si une réponse générée par l’IA est correcte, biaisée ou tout simplement absurde est de demander à un humain de le faire. de demander à un humain de le faire. En effet, les humains comprennent encore des choses que l’IA ne comprend pas, comme la nuance, l’intention, le contexte du domaine et la pertinence. C’est particulièrement vrai dans les secteurs où le coût d’une mauvaise réponse est élevé : finance, santé, droit, ingénierie. Vous ne voulez pas que des hallucinations se glissent dans votre produit, à moins que votre objectif ne soit d’embrouiller vos utilisateurs.

Mais le problème est le suivant : les humains ne s’adaptent pas bien à l’échelle. Embaucher des experts du domaine pour lire chaque résultat de l’IA est inefficace, coûteux et lent. Si vous gérez des produits qui génèrent des milliers, voire des millions, de réponses d’IA chaque jour, le fait de dépendre d’une révision humaine pour chacune d’entre elles casse votre modèle avant même qu’il ne passe à l’échelle supérieure. Il y a aussi l’incohérence. Les gens ne sont pas toujours d’accord sur ce qui est « précis » ou « approprié », et cette variation peut être un problème si votre objectif est de construire des systèmes qui sont à la fois fiables et reproductibles.

C’est la raison pour laquelle les entreprises investissent dans des processus d’évaluation plus intelligents qui combinent l’intuition humaine et l’automatisation. Mais le principe de base reste le même : si vous voulez avoir la plus grande confiance dans votre système de gestion du cycle de vie, vous aurez toujours besoin de l’implication des humains, mais pas pour tout.

Si vous êtes un dirigeant qui développe des solutions d’IA, vous allez prendre des décisions en fonction du coût, de la rapidité et de la précision. L’examen humain est essentiel dans les scénarios à haut risque ou en contact avec les clients, mais il n’est pas nécessaire dans tous les cas. Fixez des seuils pour savoir quand il est nécessaire. Élaborez des stratégies d’évaluation qui placent des humains aux points de contrôle clés plutôt qu’à chaque porte. Votre structure de validation reste ainsi solide, sans pour autant épuiser inutilement les ressources.

Les cadres d’évaluation de l’apprentissage tout au long de la vie sont une méthode efficace mais imparfaite pour étendre les évaluations de l’apprentissage tout au long de la vie.

Les LLM évaluant d’autres LLM peuvent sembler circulaires, mais dans la pratique, cette méthode fonctionne mieux que vous ne le pensez. Nous avons atteint un point où certains grands modèles peuvent raisonnablement juger de la qualité des résultats générés par d’autres IA. Entraînés sur les mêmes données que les humains, voire plus dans certains cas, ils peuvent reconnaître une bonne structure, des arguments cohérents, la pertinence d’un message et même le ton.

Cette approche résout le problème d’évolutivité dont nous venons de parler. Elle est rapide, rentable et cohérente. Mais elle n’est pas parfaite. Ces modèles, bien qu’entraînés sur des ensembles massifs de données écrites par des humains, présentent leurs propres faiblesses. Ils préfèrent souvent les réponses verbeuses, évaluent mal l’exactitude mathématique et choisissent parfois par défaut la première réponse qu’ils voient. Ces biais sont intégrés dans les systèmes à partir des données sur lesquelles ils ont été formés.

Néanmoins, ces défauts sont gérables. Vous pouvez les atténuer en associant soigneusement les modèles générés et évalués, en les alignant sur des critères de référence spécifiques et en vérifiant les principaux résultats à l’aide de données humaines. Il ne s’agit pas de remplacer entièrement les humains, mais de déployer l’IA là où elle est utile. Utilisez l’évaluation automatisée lorsque la vitesse et le volume sont prioritaires. Faites appel à des personnes lorsque la qualité ou les cas particuliers nécessitent un jugement plus approfondi.

Il s’agit de concevoir un écosystème dans lequel votre pipeline d’évaluation bénéficie de l’automatisation sans en abuser. Cela signifie qu’il faut tester régulièrement vos modèles de jugement, limiter leur utilisation aux domaines dans lesquels ils sont fiables et prévoir une surveillance humaine lorsque des lacunes apparaissent. Si l’IA doit s’autocontrôler, le système qui l’entoure doit être bien géré, en particulier si votre produit touche à des interactions réelles avec les clients ou à des décisions commerciales.

L’évaluation basée sur la référence à l’aide d’ensembles de données en or améliore la performance des juges LLM

Lorsque vous donnez à un LLM l’accès à un ensemble de données de haute qualité, étiqueté à la main, ce que beaucoup dans l’industrie appellent un « ensemble de données en or », sa capacité à juger les résultats s’améliore considérablement. Ces ensembles de données représentent ce à quoi doit ressembler une réponse correcte et établissent une norme que les modèles de génération et d’évaluation peuvent apprendre à respecter. Avec des repères clairs en place, les évaluateurs formés peuvent repérer les inexactitudes, les réponses vagues ou les hallucinations avec une plus grande précision.

La raison pour laquelle cela fonctionne est simple. Un LLM fonctionnant sans norme s’appuie sur des probabilités et des modèles antérieurs. Mais lorsque vous ajoutez une référence, quelque chose de concret, il commence à ancrer ses évaluations dans quelque chose de vérifiable. Cela réduit l’influence des biais du modèle et améliore la cohérence. Dans de nombreuses entreprises, cette technique fait désormais partie de la routine parce qu’elle affine à la fois la formation au modèle et les boucles de rétroaction internes.

Mais vous ne pouvez pas vous contenter d’un seul ensemble de données. Les ensembles de données en or sont puissants, mais ils deviennent rapidement obsolètes. Les technologies évoluent. L’utilisation de la langue change. De nouveaux types de requêtes apparaissent. Par conséquent, si un ensemble de données de référence bien sélectionné améliore la qualité de vos évaluations, il doit être entretenu. Si vous ne le mettez pas à jour activement, la précision de votre évaluation va dériver.

Si vous gérez les opérations ou la direction des produits, n’oubliez pas que les ensembles de données en or ne sont pas seulement un outil technique, mais aussi un atout stratégique. Leur qualité a un impact sur les modèles de formation, les modèles de jugement et la confiance des utilisateurs. Allouez des ressources à la création et à l’actualisation régulière de ces ensembles de données. Rendez-les spécifiques à un domaine si nécessaire. Une base de référence solide améliore les performances dans tous les domaines, mais seulement si elle reste à jour.

Les références publiées sont sujettes à la contamination et à l’exposition des ensembles de données.

Une fois que les critères de référence sont rendus publics, il est inévitable que les gestionnaires du droit d’auteur commencent à s’y former, que ce soit directement ou par l’exposition à un contenu similaire. À ce stade, vous perdez la fiabilité de vos évaluations. Les modèles commencent à s’optimiser en fonction des critères de référence et non des résultats. Essentiellement, vous finissez par évaluer les performances en fonction de la familiarité, et non de la compréhension ou de la capacité réelle.

Cela pose un véritable problème pour mesurer la compréhension du monde réel. Si un modèle connaît le point de référence à l’avance, il ne fait que répéter le contenu appris, sans raisonner ni généraliser. En formation, cela conduit à un surajustement. En production, cela gonfle votre perception de la précision du modèle. Le problème s’intensifie si vous utilisez ce point de référence non seulement pour mesurer, mais aussi pour ajuster vos modèles.

Les dirigeants doivent en comprendre les limites. Les références publiques sont utiles mais imparfaites. Dès lors que vous vous en remettez exclusivement à eux, votre boucle de rétroaction se rétrécit et vous risquez de développer une IA qui semble bonne sur le papier, mais dont les performances sont médiocres dans les interactions réelles.

D’un point de vue stratégique, cela signifie que vous avez besoin d’un panel de références, et non d’une seule, et que vous devez partir du principe que tout ensemble de données largement utilisé est déjà ancré dans les corpus de formation. Créez des références internes, faites-les tourner et générez des données synthétiques le cas échéant. Ne considérez pas l’étalonnage comme une ligne d’arrivée, mais comme une cible en mouvement. C’est ainsi que vous préserverez l’intégrité tout en améliorant les performances.

Le contenu de Stack Overflow, créé par la communauté, fournit une base réaliste pour des tests d’évaluation de codage évolutifs.

Lorsqu’il s’agit d’évaluer les performances du LLM dans des scénarios de codage réels, Stack Overflow offre l’une des sources de données les plus pratiques et les plus pertinentes. Ce sont de vraies personnes qui posent de vraies questions de programmation et qui obtiennent des réponses votées qui reflètent ce sur quoi les développeurs compétents s’accordent. Ce type de structure évaluée par des pairs est précieux car il reflète des connaissances actives, et pas seulement de la théorie ou de la documentation.

Prosus, la société mère de Stack Overflow, a utilisé cette idée pour créer deux indices de référence, StackEval et StackUnseen. StackEval s’appuie sur le contenu historique de Stack Overflow où les questions avaient des réponses acceptées et où les réponses étaient approuvées. Cet ensemble de données s’est avéré utile pour évaluer les LLM, avec un taux de réussite de 84 % dans la détection des bonnes réponses. Mais comme il se concentre sur le contenu passé, il a ses limites.

StackUnseen résout ce problème. Il utilise les questions les plus récentes de Stack Overflow, couvrant des éléments qui n’ont probablement pas été inclus dans une formation LLM antérieure. Les résultats ont montré une baisse annuelle de 12 à 14 % des performances lorsque les modèles tentent de répondre à des questions impliquant des langages de programmation plus récents, des frameworks ou des scénarios de pointe. Essentiellement, même les LLM très avancés ont des difficultés lorsque leurs données de formation sont anciennes ou ne couvrent pas les conversations récentes des développeurs.

Si vous investissez dans l’IA pour soutenir les flux de travail des ingénieurs, les assistants de codage, les résumés de documentation, les outils de débogage, sachez que les performances peuvent sembler bonnes dans les évaluations historiques, mais s’effondrer lorsqu’il s’agit de traiter des tâches nouvelles, spécifiques à un domaine. Utilisez des repères réels et actuels tels que StackUnseen pour tester les performances de votre IA dans les conditions d’aujourd’hui, et non dans celles de l’année dernière. C’est essentiel si votre plateforme prend en charge des développeurs utilisant des outils qui évoluent rapidement.

Les LLM obtiennent de bons résultats avec des contenus objectifs et structurés (comme le codage) mais peinent à répondre à des requêtes nouvelles ou subjectives.

Dans les environnements où les réponses suivent une logique claire, comme l’exactitude du code, il est plus facile pour un LLM d’émettre des jugements solides. Les tâches de codage ont souvent une structure définie et une gamme limitée de résultats acceptables. Cette prévisibilité joue en faveur des modèles de langage. C’est pourquoi les benchmarks construits à partir de données de codage, tels que l’ensemble de données StackEval, montrent des performances LLM supérieures.

Cependant, lorsque nous déplaçons les données vers du matériel nouveau, moins connu ou purement conceptuel, les performances commencent à diminuer. Dans StackUnseen, où les questions reflètent les tendances émergentes et les nouvelles technologies, les modèles ne sont pas seulement plus lents, ils se trompent plus souvent. Ils n’ont pas vu suffisamment de contenus de ce type pour développer des schémas de réponse utiles. La baisse de la précision, qui peut atteindre 14 % par an, le montre clairement.

Cet écart se creuse dans les domaines plus ambigus ou interprétatifs. Les tâches impliquant des réponses créatives, des domaines techniques de niche ou des formulations non standard révèlent les limites du modèle. Sa capacité de généralisation n’a pas été adaptée à la rapidité avec laquelle les sujets évoluent dans des domaines dynamiques tels que les logiciels, la finance ou le développement de produits.

Les décideurs de la suite doivent segmenter clairement la couverture des cas d’utilisation : là où les LLM fonctionnent de manière fiable aujourd’hui et là où une atténuation des risques est nécessaire. Pour les processus standardisés, l’intégration des LLM est un avantage évident. Pour les domaines de contenu émergents ou fluides, les performances du modèle doivent être testées fréquemment et soutenues par une supervision humaine ou des fonctions d’orientation supplémentaires. Se contenter de supposer que l’IA polyvalente peut gérer un domaine spécialisé qui évolue rapidement est une erreur stratégique.

La définition d’un contexte et de critères d’évaluation clairs est essentielle pour une évaluation significative du programme LLM.

Les LLM ne sont pas bien évalués s’ils ne sont pas structurés. Si vous ne définissez pas le contexte, ils dérivent. Si vous ne définissez pas de critères, ils devinent. C’est un problème lorsque ces modèles sont chargés d’évaluer des éléments tels que le ton, l’exactitude ou la partialité. Il ne s’agit pas de résultats de type « oui ou non », ils nécessitent un cadre. Et la plupart des LLM ne sont pas formés pour appliquer une logique d’évaluation rigoureuse dès le départ.

Pour que les évaluations soient significatives, vous avez besoin de deux choses : un message-guide étroitement défini qui fixe des limites et une grille d’évaluation avec des catégories claires. Cela transforme une tâche ouverte en quelque chose de mesurable. Sans ces filtres, vous obtiendrez des résultats incohérents, des évaluations différentes pour les mêmes données, même à partir de la même session de modélisation.

Les questions complexes et spécifiques à un domaine, courantes dans des domaines tels que l’ingénierie logicielle, la conformité réglementaire ou l’analyse scientifique, exigent également une base contextuelle. Ce contexte peut provenir d’ensembles de données antérieurs, d’insertions dans la documentation ou de métadonnées structurées. Sans contexte, les modèles réagissent comme des généralistes. Vous ne voulez pas d’un comportement général dans les évaluations de niveau expert.

Les dirigeants de la suite devraient penser à la conception de l’évaluation de la même manière qu’ils pensent aux attentes en matière de produits. Si le modèle n’est pas clair sur la façon dont vous voulez qu’il juge le succès, il adoptera par défaut un comportement de moindre effort, des raccourcis, des résultats vagues ou un modèle de pensée. Concevoir votre couche d’évaluation avec des attentes précises permet non seulement d’obtenir de meilleures informations, mais aussi de former les futures itérations de vos modèles grâce à un retour d’information utilisable. Il ne s’agit pas de frais généraux. Il s’agit d’une infrastructure.

Les LLM doivent continuellement intégrer de nouvelles données pour rester efficaces dans les évaluations en temps réel.

Les performances se dégradent lorsque les modèles s’exécutent sur des informations périmées. Vous pouvez suivre ce déclin : dans StackUnseen, la précision des modèles a chuté d’environ 12 à 14 % par an sur le nouveau contenu de programmation. Cela signifie que les LLM actuels, même s’ils sont très performants au départ, dérivent en l’absence de nouvelles données. Les boucles de rétroaction s’interrompent, en particulier lorsque le contenu qu’ils évaluent évolue plus rapidement que leurs cycles de formation.

Ceci est particulièrement important dans les domaines techniques. Le génie logiciel évolue rapidement. Les cadres de travail publient des mises à jour tous les mois. Les nouveaux paradigmes et les conversations au sein de la communauté évoluent en permanence. Un modèle formé il y a un an peut ne plus être à jour en ce qui concerne les détails du langage ou les modèles de conception. Il en va de même pour les modèles qui évaluent d’autres modèles sur ces nouveaux modèles : ils ne font que deviner s’ils n’ont jamais rien vu de tel auparavant.

Pour résoudre ce problème, vous avez besoin d’un pipeline qui alimente vos processus d’évaluation et de mise au point avec un contenu actualisé et représentatif. Les ensembles de données statiques ne suffisent pas. Les données en temps réel provenant de plateformes en direct, de forums ou d’interactions avec les clients aident les modèles à rester alignés sur la façon dont les gens travaillent et parlent aujourd’hui.

Il s’agit d’une question tournée vers l’avenir. Les dirigeants doivent considérer l’évaluation continue comme un processus vivant. Si vos équipes utilisent des LLM dans les pipelines de produits, assurez-vous que les données d’évaluation reflètent ce que vos clients et utilisateurs utilisent aujourd’hui, et non pas il y a six mois. Plus cette boucle de rétroaction est proche des flux de travail actuels, plus l’alignement de votre modèle et l’impact sur l’entreprise seront importants. Les validations statiques conduisent à des systèmes à la traîne. Les systèmes de retour d’information dynamiques assurent la pertinence de l’ensemble.

La supervision humaine reste cruciale dans les pipelines d’évaluation de l’IA malgré les progrès de l’automatisation.

L’évaluation automatisée à l’aide de LLM peut réduire les frictions, les coûts et s’étendre rapidement, mais elle est incomplète. Les modèles ont encore des hallucinations. Ils évaluent toujours positivement les réponses incorrectes et renforcent occasionnellement leurs propres hypothèses erronées. Ces défaillances passent inaperçues à moins qu’un être humain ne soit présent dans la boucle.

La supervision humaine est essentielle, non pas parce que les modèles sont inutiles, mais parce qu’ils ne s’auto-corrigent pas. Un générateur défectueux associé à un évaluateur défectueux aggrave le problème, à moins qu’un système externe, généralement humain, ne signale et ne résolve ces problèmes. L’examen manuel permet d’identifier la cause profonde des erreurs d’appréciation récurrentes, d’améliorer la structure des messages et de réinjecter de meilleures données dans la formation.

La vérification ponctuelle est un outil. Un autre consiste à permettre aux utilisateurs finaux ou aux équipes d’assurance qualité de marquer les erreurs dans les environnements de production. Chaque élément de contenu marqué doit avoir une fonction, qu’il s’agisse d’affiner les modèles d’invite, d’ajuster le comportement de l’évaluateur ou de recycler les modèles de base. Sans cette couche humaine, les systèmes automatisés dérivent et la confiance diminue.

Si vous allouez un budget ou des effectifs, ne supprimez pas les réviseurs humains dans l’espoir d’une automatisation totale. C’est une vision à court terme. Un modèle hybride, qui place stratégiquement le retour d’information humain dans les zones d’incertitude ou de risque commercial, vous donne un système stable sans sacrifier l’échelle. Les humains n’ont pas besoin d’être partout dans la boucle, mais ils doivent absolument être présents là où l’automatisation seule ne permet pas de détecter les défaillances.

Une dépendance excessive à l’égard d’un seul critère de référence peut conduire à un surajustement du modèle et à des mesures de performance trompeuses.

L’utilisation d’un seul point de référence comme principale mesure d’évaluation oriente les modèles vers ce point. Ils commencent à optimiser pour ce test, en reprenant les formats, les solutions et les styles qu’ils ont appris au cours du processus d’évaluation lui-même. Le problème est que vous cessez de mesurer l’efficacité et commencez à mesurer la familiarité. Dès lors, toute amélioration n’est qu’une illusion de progrès.

Ce n’est pas théorique. Il se produit rapidement, en particulier lorsque les benchmarks sont visibles par les chercheurs ou les pipelines de données de formation. Une fois qu’il a été suffisamment répété, le modèle considère les problèmes de référence non pas comme des défis, mais comme un contenu mémorisé. Le processus d’évaluation devient une formalité.

Le pire, c’est lorsque les entreprises alignent les objectifs du produit ou les paramètres de lancement sur ce point de référence. Vous obtenez alors un modèle très performant sur le papier, mais dont les résultats pour l’utilisateur sont médiocres dans la pratique. Si les résultats ne résolvent pas les problèmes du monde réel simplement parce qu’ils ont été réglés pour obtenir de bons résultats, votre IA n’est pas prête.

Pour les dirigeants qui prennent des décisions en matière de feuille de route ou d’investissement dans l’IA, il ne s’agit pas seulement d’un détail technique, mais d’une question stratégique. Les critères de référence doivent informer, et non définir, vos systèmes d’évaluation. Utilisez des ensembles d’évaluation multiples et tournants. Introduisez des critères de référence privés qui sont moins vulnérables à la contamination des modèles. Et établissez une corrélation entre les performances des repères et les données d’utilisation réelles. C’est ainsi que vous construirez des systèmes qui resteront utiles au fur et à mesure que leur environnement évoluera.

Les évaluations automatisées du LLM permettent des tests évolutifs de la GenAI mais se heurtent à des difficultés

Les évaluations automatisées utilisant les LLM sont utiles lorsque vous avez affaire à des systèmes génératifs à grande échelle. Elles offrent rapidité, rentabilité et reproductibilité. Si vous utilisez un produit qui génère des milliers de réponses d’IA par heure, vous avez besoin de l’automatisation. Mais les modèles GenAI ne sont pas déterministes. Leurs réponses varient, même à partir de la même entrée. Cela complique les tests et l’évaluation.

Les LLM font une chose mieux que les personnes à l’échelle : ils critiquent. Il est plus facile de noter une réponse générée que d’en produire une. Mais c’est là que la complexité apparaît. Pour que les évaluations soient cohérentes et utiles, vous avez besoin de critères solides, d’invites d’évaluation structurées et d’un alignement sur le jugement humain. L’évaluation de la qualité de la production, de l’exactitude des faits, du ton, de la partialité ou de l’adéquation à un domaine est incohérente en l’absence de ces contrôles.

Même si l’automatisation est en place, les résultats ne sont pas toujours fiables. Les modèles d’évaluation peuvent noter les réponses avec indulgence simplement parce qu’elles correspondent à des modèles issus de leur propre formation. De plus, la variabilité entre les séries compromet l’idée d’avoir des mesures comparables et reproductibles, à moins que les mécanismes de notation du modèle ne soient verrouillés et reproductibles.

Les dirigeants qui exploitent des produits d’IA à grande échelle devraient adopter l’évaluation automatisée, mais ne pas trop s’y fier. Intégrez-la dans vos processus d’assurance qualité et de surveillance avec des mesures de protection appropriées. Utilisez des messages d’incitation à l’évaluation forts. Vérifiez régulièrement les scores par rapport à des échantillons évalués par des humains. Vérifiez les incohérences dans le comportement de notation au fil du temps. Et surtout, mettez en place un système dans lequel les réponses inattendues, en particulier celles qui concernent des domaines à haut risque, sont signalées et font l’objet d’un examen humain. Les boucles de rétroaction rapide ne sont utiles que si les signaux d’évaluation sur lesquels elles s’appuient sont fiables.

Le bilan

Si vous dirigez des équipes qui construisent ou déploient des outils de GenAI, l’évaluation n’est pas facultative, c’est une infrastructure. La façon dont vous validez les résultats détermine si vos systèmes d’IA restent utiles, fiables et alignés sur les besoins du monde réel. L’automatisation vous aide à évoluer, mais elle a des limites. Les LLM évaluant d’autres LLM peuvent couvrir le volume, mais vous avez toujours besoin d’une supervision humaine, de données de référence mises à jour et de repères diversifiés pour éviter les dérives, les biais et les fausses confiances.

Le marché évolue rapidement. Ce qui fonctionnait il y a six mois peut être dépassé aujourd’hui, en particulier dans des domaines techniques tels que le développement de logiciels, la finance et les applications juridiques de l’IA. Les modèles se dégradent. Les données changent. Les attentes des utilisateurs évoluent plus rapidement que vos évaluations existantes, à moins que vous n’ayez mis au point un système qui s’adapte à ces attentes.

Faire des économies sur l’évaluation peut sembler efficace à court terme, mais cela introduit un risque à long terme, des erreurs de produit, la méfiance des utilisateurs ou des mesures de performance trompeuses. Considérez plutôt les évaluations comme la couche de signal entre l’innovation et l’intégrité. C’est ainsi que l’on obtient une IA qui fonctionne, à grande échelle, en production et sous pression.

Investissez là où c’est important : des ensembles de données en or, des panels de référence mixtes, des évaluations rigoureuses, des contrôles humains ponctuels et des voies d’escalade claires en cas de dérapage. Vous contrôlez la boucle de rétroaction. Veillez à ce qu’elle soit adaptée à ce qui est important aujourd’hui et à ce qui le sera demain.

Alexander Procter

novembre 7, 2025

23 Min