Évaluations : passer des expériences d’IA à une production fiable

• Bien que les modèles de fondation se soient améliorés, le véritable changement qui permet une utilisation fiable en production vient de pratiques d’évaluation rigoureuses.

• Des évaluations bien conçues aident les gestionnaires de produits, les responsables de la gouvernance de l’IA et les chefs de la technologie à déployer des agents d’IA à grande échelle en toute sécurité, transformant l’IA d’un jouet cloisonné en avantage concurrentiel.

• Cette confiance vient de l’évaluation du comportement des agents d’IA par rapport à de vraies requêtes d’utilisateurs, à des cas limites et à des scénarios propres au domaine qui reflètent votre contexte commercial réel, et non d’un banc d’essai public affirmant que « ce modèle est le meilleur ».

• L’objectif est de justifier cette confiance par des résultats mesurables. Réussir signifie définir concrètement et de façon mesurable ce qui est « bon », conformément à vos besoins commerciaux et à votre tolérance au risque, qu’il s’agisse d’exactitude factuelle, de ton approprié, de rapidité ou de rentabilité.

• En intégrant l’évaluation à l’ensemble de votre système — instrumentation, journalisation, tests A/B et garde-fous — et en conciliant rigueur et efficacité, les équipes accéléreront les déploiements et renforceront la robustesse.

La plupart des entreprises acceptent que leurs employés expérimentent avec ChatGPT ou Gemini. Cependant, l’utilisation des LLM dans des flux de travail ou des contextes à enjeux élevés demeure moins courante.

Les raisons ont souvent été justifiées : la qualité était inégale, et le risque d’hallucinations ou de comportements indésirables l’emportait sur les avantages potentiels de la technologie.

Cet équilibre entre risques et avantages a beaucoup changé au cours de la dernière année. Une partie de ce changement découle de l’amélioration des modèles de fondation, mais une grande part vient de la rigueur croissante des pratiques d’évaluation, ou « evals ». Les évaluations nous donnent, ainsi qu’à nos clients, la confiance nécessaire pour déployer en quelques semaines des agents à grande échelle destinés à la clientèle.

Ce guide explique les éléments fondamentaux des évaluations ainsi que la façon de les concevoir, de les mettre en œuvre et de les exploiter pour des cas d’utilisation en production.

L’objectif de l’évaluation n’est pas de trouver un modèle parfait, mais d’établir une confiance justifiée dans le fait que votre modèle se comporte conformément aux besoins de votre entreprise, aux attentes de vos utilisateurs et à la tolérance au risque de votre organisation.

Toute stratégie d’évaluation repose sur une question simple : À quoi ressemble ce qui est « bon »? La réponse doit être précise. Pour une organisation, ce qui est « bon » peut signifier une exactitude factuelle respectant des tolérances strictes; pour une autre, la priorité peut être la rapidité, la rentabilité ou un ton distinctif. Chaque contrainte à laquelle vous êtes soumis, des données utilisables aux obligations réglementaires applicables, façonne cette définition.

Surtout, ce qui est « bon » doit comporter des éléments réellement mesurables. Si la réussite consiste à fournir des conseils financiers utiles, cette utilité doit s’exprimer par des attributs : exactitude factuelle, avertissements appropriés, raisonnement personnalisé et limites sûres. Une fois ce qui est « bon » défini en termes mesurables, il faut déterminer comment analyser et interpréter les résultats. C’est en agissant sur ces résultats que l’évaluation devient une méthode plutôt qu’une simple succession de jugements.

Chaque processus d’évaluation repose sur trois piliers interreliés :

1. Entrées et bancs d’essai : exemples représentatifs du monde réel pour mesurer le rendement général et jeux de données internes organisés pour vérifier la viabilité dans le domaine.

2. Comportement du modèle : façon dont le modèle est sollicité (génération augmentée par récupération, résumé, récupération d’information structurée, utilisation d’outils).

3. Mesures : façon de mesurer et d’interpréter le rendement.

Les entrées doivent représenter le monde auquel votre système sera confronté. Les observations les plus pertinentes viennent d’exemples réels : requêtes de clients, scénarios financiers ou cas propres à votre secteur. Seuls des tests fondés sur ces exemples permettent de déterminer si le modèle comprend vraiment les nuances exigées par vos utilisateurs et répond au besoin commercial.

Le comportement du modèle — la formulation de l’invite, l’orchestration de la récupération ou des outils et l’apport du contexte — compte autant que le modèle lui-même. Deux modèles identiques peuvent se comporter très différemment selon leur mode de déploiement. Cette couche doit donc faire partie de la conception de votre évaluation.

Enfin, il y a les mesures. Les chiffres seuls racontent rarement toute l’histoire, mais des mesures bien choisies rendent le comportement du système interprétable. Latence, exactitude, sécurité, cohérence, biais, coût et satisfaction des utilisateurs forment ensemble un portrait multidimensionnel d’un système en production. L’art consiste à choisir des mesures qui correspondent aux indicateurs clés de votre projet ou de votre entreprise et éclairent les qualités les plus importantes pour vos utilisateurs. Les mesures simples sont souvent plus exactes et moins coûteuses, tandis que de mauvais choix peuvent induire les équipes en erreur. Voici comment aborder le choix des mesures :

Exemples de bons choix de mesures :

• Robot conversationnel de service à la clientèle : taux de résolution au premier contact (le problème a-t-il été résolu sans transfert?), durée moyenne de traitement, satisfaction des utilisateurs, taux de transfert à des agents humains.

• Outil de recherche financière : exactitude des citations (% d’affirmations correctement sourcées), précision factuelle validée par rapport aux données de référence, pertinence de la récupération (a-t-il trouvé les bons documents?), cohérence du raisonnement évaluée par des spécialistes du domaine.

• Assistant de génération de code : validité de la syntaxe, taux de réussite des tests, nombre de vulnérabilités de sécurité, délai d’obtention d’une solution fonctionnelle.

Exemples de mauvais choix de mesures :

• Utiliser uniquement la longueur de la réponse comme indicateur de qualité (plus long ≠ meilleur).

• Mesurer la rapidité sans tenir compte des compromis en matière d’exactitude.

• Suivre les indices de confiance du modèle sans les comparer à l’exactitude réelle.

• Se fier uniquement à la perplexité interne du modèle sans validation auprès des utilisateurs.

Pièges courants liés aux mesures :

• Mesures contradictoires : optimiser simultanément la rapidité et l’exhaustivité sans reconnaître le compromis.

• Surajustement aux bancs d’essai : obtenir 95 % sur le jeu de test, mais échouer en production parce que les vrais utilisateurs se comportent autrement.

Pour un client du secteur des services financiers fortement réglementé, l’exactitude de sa solution de recherche approfondie était primordiale. Nous avons conçu des jeux de données de questions-réponses créés par des spécialistes et d’autres générés par des outils afin d’évaluer la précision, la capacité du système à choisir les bons outils et à récupérer la bonne information, et ainsi d’obtenir une vue équilibrée de l’exactitude et de la qualité du raisonnement. L’essentiel consistait à mesurer plusieurs dimensions : exactitude factuelle (validation par des spécialistes), qualité de la récupération (précision et rappel des documents pertinents) et cohérence du raisonnement (évaluation structurée du cheminement logique).

Quand utiliser un LLM comme juge pour évaluer une qualité nuancée

L’approche du LLM comme juge utilise un second modèle d’IA comme évaluateur, remplaçant l’examen humain par une notation automatisée de la qualité pouvant être mise à l’échelle. L’approche du LLM comme juge est souvent utilisée à tort lorsque des mesures plus simples offrent l’exactitude requise. Elle peut être utile lorsque des vérifications déterministes ne peuvent saisir la qualité, notamment quand la mesure est sémantique — utilité, ancrage factuel, qualité du raisonnement, ton ou interprétation des politiques — et qu’une notation déterministe est impossible. Vous pourriez avoir besoin de rétroaction à grande échelle sur de nombreuses variantes d’invites et de modèles, ainsi que d’une grille claire et d’un schéma de sortie structurée. Pour que cette approche fonctionne, suivez ces étapes :

• Définissez explicitement les dimensions de la grille : exactitude, ancrage factuel, respect des politiques, caractère exploitable et ton.

• Utilisez des sorties structurées (schéma JSON) pour les réponses du juge.

• Consignez les résultats binaires des contrôles et le texte diagnostique pour analyser les échecs.

• Étalonnez les sorties du juge avec des échantillons étiquetés par des humains à chaque cycle de publication.

• Utilisez deux juges ou des vérifications périodiques du consensus dans les domaines à enjeux élevés.

• Suivez au fil du temps la dérive du juge et le taux de désaccord.

Un jeu de données de référence est un ensemble fixe et organisé d’exemples de test dont les réponses sont connues, utilisé pour évaluer les modèles de façon uniforme et comparer équitablement les résultats entre les versions. Il comprend généralement des entrées, comme des requêtes d’utilisateurs, des sorties attendues ou des jugements de référence, ainsi que des critères ou des étiquettes d’évaluation pour la notation. Les tests publics servent à comparer le rendement des modèles de pointe et peuvent fournir une première indication, lors de la conception du système, du modèle qui pourrait être un bon candidat.

Pour votre propre système, vous ne pouvez toutefois pas vous y fier comme indicateur du rendement dans votre contexte commercial, car ces bancs d’essai présentent des problèmes connus :

• Contamination : les modèles peuvent avoir été entraînés sur les données du banc d’essai; les évaluer avec le même jeu de données revient à les noter avec une feuille de réponses.

• Saturation : tous les meilleurs modèles atteignent déjà les notes maximales. L’amélioration ou la dégradation se limite donc à quelques points de pourcentage, souvent dans la variabilité naturelle des résultats.

• Portée étroite : les données des bancs d’essai ne reflètent pas vos tâches réelles, car elles sont très soigneusement sélectionnées et nettoyées. Certaines sont même générées par des LLM et ne reflètent ni la complexité ni les cas limites de vos données, comme les fautes de frappe, les tournures inhabituelles et les images bruitées.

Un élève demande à l’application de l’aider à résoudre des problèmes écrits.

Exemple de banc d’essai public utilisable : GSM8K (raisonnement mathématique de niveau primaire).

• Ensemble plus difficile facultatif : MATH.

Pourquoi ce banc d’essai est utile :

• Comparer rapidement les modèles pour déterminer lequel maîtrise le mieux le raisonnement mathématique général.

• Un bon premier filtre avant d’investir dans des évaluations complètes du produit.

Pourquoi vous avez tout de même besoin de votre propre jeu de données :

Votre application comporte des exigences que GSM8K ne teste pas :

• La formulation de votre programme d’études et l’ordre des sujets.

• Le style d’explication adapté au groupe d’âge visé.

• La façon de traiter les questions ambiguës ou remplies de fautes de frappe.

• Les règles de politique, par exemple quand donner des indices plutôt que des réponses complètes.

Une validation efficace repose sur la création de bancs d’essai propres à votre application. Ces jeux de données doivent provenir d’interactions réelles, de cas limites courants et de modes de défaillance plausibles. Cette tâche peut être difficile lors de la mise en œuvre d’un nouveau produit ou processus. Toutefois, il est généralement possible de recueillir des données d’un produit existant ou de commencer le plus tôt possible, même pendant une première phase de test. Après le développement de votre application, ces bancs d’essai doivent évoluer avec votre produit et devenir plus riches et représentatifs au fil du temps.

Le lien entre le banc d’essai propre à votre application et le choix du modèle est essentiel. Votre banc d’essai indique non seulement si une solution fonctionne, mais aussi quelle combinaison de taille de modèle et de techniques de post-entraînement fournit le rendement nécessaire au meilleur coût. Les améliorations les plus puissantes des modèles préentraînés — le « PT » de ChatGPT — ne viennent pas d’un nouvel entraînement, mais de méthodes de « post-entraînement ».

Ces méthodes visent à déterminer l’information accessible au modèle, sa structure et la façon dont le modèle est guidé et orchestré lors de l’inférence. Techniques de post-entraînement telles que :

• Invites de raisonnement détaillé (« chain-of-thought ») et allocation dynamique des ressources de calcul (réfléchir davantage aux problèmes difficiles).

• Autocohérence, où plusieurs sorties sont générées avant de sélectionner la meilleure.

• Construction et orchestration du contexte, comme la génération augmentée par récupération (RAG), les exemples few-shot et les flux de travail agentiques.

• Utilisation d’outils et accès à des connaissances externes, permettant au modèle d’agir au-delà de ses paramètres internes.

• Stratégies de représentation et de stockage des connaissances conçues pour une récupération et un raisonnement efficaces sur des données structurées et non structurées.

Bien que ces techniques de post-entraînement puissent améliorer considérablement le rendement du système, elles imposent aussi des compromis. Chaque couche supplémentaire d’orchestration, de récupération ou de raisonnement accroît la complexité du système, le temps d’inférence et les coûts d’exploitation. Lorsqu’elle est appliquée judicieusement, la bonne combinaison de techniques de post-entraînement permet souvent d’utiliser des modèles plus petits, plus rapides et moins coûteux tout en respectant les exigences de rendement. Au lieu d’augmenter la taille du modèle, on atteint le rendement voulu grâce à une meilleure conception du système.

Cet équilibre est propre à chaque application et doit reposer sur vos évaluations particulières afin de déterminer la combinaison optimale de techniques. Elles vous permettront de repérer le point où une orchestration supplémentaire n’apporte plus de gains significatifs, afin de choisir le degré minimal de complexité de post-entraînement requis pour atteindre le rendement cible.

Une solution d’IA doit être considérée comme un système complet : bases de données, API, interfaces utilisateur, couches d’orchestration, infrastructure de surveillance et plus encore. L’évaluation doit donc couvrir l’ensemble de la pile technologique. Vous devez surveiller les principales composantes du système pour conserver une visibilité sur les problèmes potentiels et accélérer de façon responsable.

La surveillance des principales composantes du système implique ce qui suit :

• Instrumenter vos processus afin d’obtenir des résultats mesurables.

• Journaliser les expériences pour observer l’effet de chaque ajustement.

• Effectuer de simples comparaisons A/B avant de déployer des changements majeurs afin de détecter les régressions possibles.

L’itération fondée sur les données raccourcit le passage du prototype à la production, sans angles morts. La journalisation et la surveillance sont également importantes pour comprendre l’utilisation réelle de l’application. Voici un exemple pour assurer l’observabilité :

• Étape 1 : la requête de l’utilisateur arrive avec request_id, user_segment et intent.

• Étape 2 : la trace consigne la version du modèle, la version de l’invite, les documents récupérés et les appels d’outils.

• Étape 3 : le LLM juge note la réponse (exactitude, ancrage factuel, policy_risk).

• Étape 4 : le moteur de règles évalue les seuils.

• Étape 5 : si un seuil est enfreint, déclencher une alerte et acheminer le cas vers une solution de repli ou un examen humain.

• Étape 6 : l’échec est ajouté à la file de triage, puis à la liste des éléments à intégrer au banc d’essai.

Les vrais utilisateurs se comportent rarement exactement comme le prévoient les concepteurs. Certains comprendront mal les instructions. D’autres sonderont délibérément les points faibles. Ces cas limites ne sont pas des anomalies, mais des signaux précieux. Un processus d’évaluation bien mis en œuvre les saisit, les analyse et les intègre aux tests futurs. Une itération rapide sans angles morts n’est possible que lorsque l’évaluation est intégrée au système, plutôt qu’ajoutée après le développement.

Nous recommandons d’intégrer des garde-fous et une surveillance dès le premier jour :

• Suivez régulièrement les mesures et les régressions du modèle à l’aide du banc d’essai propre à votre application.

• Consignez et examinez les cas limites ou les entrées antagonistes, puis ajoutez-les au jeu de données du banc d’essai propre à votre application.

• Assurez-vous que ces mesures d’évaluation correspondent à vos principaux indicateurs clés.

• Remettez régulièrement en question votre jeu de données et votre banc d’essai pour éviter d’ignorer de nouveaux risques ou de subir des biais.

• Mettez en place des alertes automatisées en cas de dégradation des mesures (p. ex., si l’exactitude passe sous 85 %, déclenchez un examen).

• Maintenez un processus d’examen humain pour les décisions à enjeux élevés (conseils juridiques, conseils médicaux, transactions financières).

Chaque exécution d’un banc d’essai consomme des ressources informatiques et de l’énergie. Chaque expérience redondante augmente les coûts. Une évaluation responsable doit concilier rigueur et efficacité.

Certaines mesures pratiques permettent d’éviter l’explosion de la consommation d’énergie et des coûts :

• Utilisez de plus petits modèles lorsque possible, en menant les premières expériences sur des modèles moins coûteux et en augmentant l’échelle seulement après avoir validé l’approche.

• Mettez en cache les invites et les appels d’API.

• Planifiez les tâches en fonction de l’énergie (traitement par lots, instances ponctuelles, priorité flexible).

• Suivez l’utilisation des ressources informatiques en parallèle avec le rendement.

Restez également à l’affût des nouvelles réglementations sur l’IA. Même en l’absence d’une loi particulière, les cadres existants et les mesures nécessaires s’appliquent toujours, notamment :

Protection des données :

• Assurez-vous que les jeux de données des bancs d’essai ne contiennent aucun renseignement personnel sans consentement approprié.

• Mettez en œuvre des politiques de conservation des données pour les requêtes journalisées.

• Prévoyez des mécanismes pour les demandes de suppression de données.

Égalité et biais :

• Testez le rendement auprès de différents groupes démographiques.

• Assurez une représentation diversifiée lors de la création du banc d’essai.

Droits de la personne et transparence :

• Documentez clairement les limites du modèle pour les utilisateurs.

• Expliquez les décisions à enjeux élevés.

• Permettez une supervision humaine pour les applications critiques.

L’évaluation n’est pas un événement ponctuel, mais un système évolutif. Dans un domaine en rapide évolution, votre avantage réside dans votre capacité à tester, à apprendre et à vous adapter rapidement afin de déployer plus efficacement des modèles et de nouvelles solutions.

En intégrant l’évaluation comme activité centrale de l’ingénierie et de la gestion de produits, les équipes peuvent innover plus rapidement et de façon plus sûre. Commencez par définir ce qui est « bon » dans le contexte de votre application d’IA, mettez en place une plateforme d’évaluation, puis faites-la évoluer afin de disposer d’un banc d’essai propre à votre application qui confirme, à chaque itération, qu’elle est prête pour la production.