Les entreprises doivent cesser de tester l'IA avec des questions que personne ne pose

L'évaluation de l'IA en entreprise commence souvent par des tests comparatifs, car ceux-ci offrent un moyen apparemment objectif de comparer les modèles. Un système obtient de meilleurs résultats en raisonnement mathématique, un autre se distingue dans un test comparatif de programmation et un troisième affiche de meilleures performances lors d'un test académique général : cela permet aux équipes chargées des achats d'attribuer des notes aux modèles, dont les résultats seraient autrement difficiles à comparer. Le problème survient lorsque les entreprises partent du principe qu’un avantage constaté lors d’un test de référence permet de prédire les performances au sein de leur propre activité.

Une compagnie d'assurance n'a pas besoin d'un modèle capable d'exceller dans toutes les questions scientifiques de niveau universitaire si sa mission principale consiste à extraire des informations des dossiers de sinistres. Un fabricant qui déploie un agent pour diagnostiquer des problèmes d'équipement se soucie de savoir si le système respecte les procédures de maintenance et prend en compte l'incertitude, tandis qu'une banque peut privilégier le traitement fiable des informations relatives aux polices et à la conformité plutôt que les capacités conversationnelles générales.

Une évaluation pertinente commence donc par le travail lui-même plutôt que par le modèle. Les équipes doivent identifier les tâches que les employés accomplissent réellement, les erreurs qui ont des conséquences et le niveau de qualité requis avant que l'automatisation ne génère plus de valeur que les coûts de supervision.

Les exemples concrets constituent un meilleur support de test que les cas fictifs, car le langage organisationnel comporte des ambiguïtés que les tests de référence génériques ne prennent pas en compte. Les noms de clients ressemblent à des codes produit, les abréviations ont des significations différentes d'un service à l'autre et les politiques internes reposent sur des hypothèses que les employés ont acquises par l'expérience plutôt que par la documentation.

Un ensemble de données de test constitué à partir de cas concrets permet de détecter ces problèmes à un stade précoce. Les entreprises peuvent ainsi supprimer les informations sensibles, conserver la structure du problème et évaluer si les différents modèles produisent des résultats que les employés utiliseraient réellement.

La justesse doit également être définie en fonction du processus de travail. Une extraction de données chiffrées peut souvent être notée de manière précise, tandis qu’un résumé stratégique peut comporter plusieurs réponses acceptables. Le fait d’évaluer ces deux tâches à l’aide du même critère d’évaluation donne l’impression d’une précision qui n’est qu’apparente, sans pour autant mesurer la qualité qui importe réellement aux employés.

L'évaluation humaine reste utile pour les tâches subjectives, même si les organisations ont besoin de critères clairs lorsque plusieurs évaluateurs interviennent. Demander si une réponse est “ bonne ” donne lieu à des jugements incohérents ; demander si elle a omis un risque significatif, utilisé des informations non étayées ou n'a pas respecté le format requis permet d'obtenir des éléments d'évaluation plus comparables.

Les comparaisons par paires peuvent s’avérer utiles lorsque l’évaluation absolue s’avère difficile. Les évaluateurs peuvent examiner deux résultats anonymisés et déterminer lequel serait le plus utile dans le cadre d’un flux de travail réel, ce qui permet aux entreprises de comparer des systèmes sans prétendre que la qualité rédactionnelle peut toujours se résumer à un pourcentage objectif.

Le coût doit être pris en compte dans l'évaluation, car une amélioration n'a de valeur économique que par rapport à ce qu'elle exige. Un modèle qui produit des synthèses légèrement plus précises, mais dont le coût d'inférence est cinq fois plus élevé, peut rester un investissement rentable pour la recherche financière, tout en étant difficile à justifier pour des millions d'interactions courantes avec les clients.

La latence revêt une importance similaire pour des raisons analogues. Les employés peuvent accepter un délai d'une minute lorsque le système analyse un contrat complexe, tandis qu'un conseiller du service client risque de susciter de l'agacement si chaque demande simple prend plusieurs secondes de plus que ce à quoi l'utilisateur s'attend.

Les systèmes à agents nécessitent une évaluation tant du processus que de la réponse finale. Un agent peut parvenir au résultat correct après avoir effectué des appels d'outils superflus, accédé à des informations hors de son champ d'action attribué ou pris une mesure qui s'est avérée inoffensive dans l'environnement de test.

Les entreprises ont donc besoin de traces indiquant les étapes qui ont été franchies. Le résultat final peut paraître parfait, alors que le chemin parcouru pour y parvenir révèle un problème de sécurité, de coût ou de fiabilité qui s'aggravera lorsque le système fonctionnera à grande échelle.

Les tests de défaillance méritent d'être pris davantage en compte que les performances moyennes. Un système qui fonctionne correctement pour 98 % des factures peut tout de même s'avérer inadapté si les 2 % restants concernent précisément les documents correspondant aux montants les plus élevés, tandis qu'un workflow médical ou de conformité peut comporter des risques concentrés sur des cas rares.

Les tests doivent délibérément inclure des numérisations de mauvaise qualité, des documents contradictoires, des informations manquantes et des instructions malveillantes, car les environnements de production contiennent tous ces éléments. Les modèles évalués uniquement sur des exemples « propres » sembleront plus fiables que les systèmes auxquels les utilisateurs seront finalement confrontés.

L'incertitude doit elle aussi être mesurée. Un système d'IA qui reconnaît ne pas disposer d'informations suffisantes peut s'avérer plus utile qu'un système présentant une précision moyenne plus élevée mais qui donne des réponses avec certitude alors que des éléments de preuve font défaut, en particulier dans les processus où un humain peut résoudre les cas incertains.

Les entreprises peuvent orienter ces cas vers d'autres services plutôt que d'exiger une automatisation parfaite. Le système traite automatiquement les tâches courantes, transmet les cas ambigus à un niveau supérieur et élargit progressivement son champ d'application à mesure que les évaluations démontrent que les nouvelles catégories fonctionnent de manière fiable.

Les mises à jour des modèles rendent ce processus continu. Les prestataires changent de systèmes, les entreprises modifient leurs invites et les données internes évoluent, ce qui signifie qu'une application ayant passé l'évaluation avec succès il y a six mois peut se comporter différemment sans que personne n'ait modifié son interface visible.

Les tests de régression permettent de détecter ces changements en exécutant des cas représentatifs chaque fois qu'un composant sous-jacent est modifié. Il s'agit là d'un principe classique du génie logiciel, même si les résultats sont probabilistes.

Les équipes de direction devraient également s'abstenir de rechercher un score d'IA unique à l'échelle de l'entreprise. Des applications différentes nécessitent des seuils différents, car la synthèse d'une réunion interne et la validation d'une transaction financière ne méritent pas le même niveau de tolérance à l'erreur.

Même le modèle bénéficiant de la meilleure réputation auprès du grand public peut s'avérer être un mauvais choix si un autre système permet de mener à bien la tâche spécifique de l'entreprise de manière plus fiable, plus rapide ou moins coûteuse. Dès lors que l'IA d'entreprise dépasse le cadre de expérimentation, l'évaluation doit répondre à une question moins prestigieuse que celle de savoir quel modèle est le plus compétent : celui qui accomplit systématiquement le travail dont l'organisation a réellement besoin.