Évaluer un LLM ou un assistant IA : qualité, latence, coût et régressions

Les modèles de langage produisent des sorties variables et leur qualité dépend du contexte, du prompt, des outils et des données. Un test manuel sur dix exemples agréables ne permet pas de choisir une architecture ni de sécuriser une mise à jour. Il faut une discipline d’évaluation comparable aux tests logiciels, adaptée aux réponses probabilistes.

L’objectif n’est pas de réduire toute qualité à une note. Il est de rendre les erreurs visibles, de comparer des versions sur les mêmes cas et de définir ce qui bloque une mise en production.

Distinguer benchmark et évaluation produit

Un benchmark public mesure des capacités générales sur un corpus donné. Il aide à comprendre un modèle, mais ne représente pas nécessairement le vocabulaire, les formats, les langues et les risques de l’entreprise.

Une évaluation produit utilise :

• tâches réelles ;
• données représentatives ;
• contraintes de format ;
• outils et RAG ;
• politique de refus ;
• seuils métier ;
• coût et latence.

Le meilleur modèle public peut être moins adapté qu’un modèle plus petit sur une tâche bornée.

Décomposer le système

Une réponse finale dépend de plusieurs composants : classification d’intention, récupération, prompt, modèle, outils et post-traitement. Les évaluer séparément aide à localiser une régression.

Pour un RAG, mesurer récupération et génération. Pour un agent, mesurer sélection d’outil, paramètres, respect des autorisations et résultat. Pour une extraction, distinguer reconnaissance du document et valeur des champs.

Construire un jeu de cas représentatif

Le jeu doit couvrir :

• cas fréquents ;
• cas à forte valeur ;
• formulations variées ;
• langues ;
• données incomplètes ;
• ambiguïtés ;
• refus attendus ;
• attaques ;
• cas historiquement défaillants.

Chaque cas possède un identifiant, une intention, des entrées, un résultat attendu ou une rubrique, un niveau de risque et des tags. Les exemples de production sont anonymisés et sélectionnés selon une politique.

Définir les dimensions de qualité

Selon la tâche, évaluer :

• exactitude des faits ou valeurs ;
• complétude des éléments nécessaires ;
• fidélité aux sources ;
• format et structure ;
• pertinence ;
• utilité pour l’action ;
• style et ton ;
• sécurité ;
• qualité du refus ;
• explicabilité ou citations.

Chaque dimension reçoit une définition et des exemples de notes. Une rubrique vague produit des juges incohérents.

Les contrôles déterministes d’abord

Avant un jugement sémantique, vérifier ce qui peut l’être par code : JSON valide, champs présents, valeurs autorisées, références existantes, calculs, longueur, langue, citations et appel d’outil.

Ces tests sont rapides, reproductibles et faciles à intégrer en CI. Ils éliminent des erreurs sans demander à un modèle de juger un format.

Construire une vérité terrain

Pour une extraction ou classification, des experts peuvent annoter le résultat correct. Pour une génération, il est souvent préférable de définir des éléments obligatoires, interdits et une rubrique plutôt qu’une phrase unique.

Les désaccords entre experts sont mesurés. S’ils ne s’accordent pas, demander au modèle une réponse unique peut être irréaliste.

La vérité terrain est versionnée et revue lorsque le métier change.

Utiliser des juges humains

Les humains restent nécessaires pour l’utilité, les nuances et les risques. L’évaluation peut être en aveugle, avec ordre aléatoire, afin de limiter le biais de marque ou de position.

Les évaluateurs reçoivent des consignes, des exemples et un mécanisme de désaccord. Un sous-ensemble est doublement noté pour mesurer la cohérence.

Utiliser un modèle comme juge avec prudence

Un juge LLM permet d’évaluer davantage de cas, mais possède ses biais. Il peut préférer les réponses longues, son propre style ou la première option. Il peut être influencé par le contenu à juger.

Les garde-fous incluent :

• critères précis ;
• sortie structurée ;
• anonymisation des modèles ;
• ordre aléatoire ;
• comparaison avec notes humaines ;
• plusieurs répétitions ;
• surveillance des désaccords.

Le juge accélère le triage ; il ne transforme pas une opinion en vérité absolue.

Comparer deux versions

La comparaison appariée exécute A et B sur les mêmes cas. Le rapport montre gains, pertes et cas critiques, pas seulement une moyenne globale.

Les résultats sont segmentés par intention, langue et risque. Une amélioration sur les résumés peut masquer une régression sur les refus. La taille de l’échantillon et l’incertitude sont visibles.

Mesurer la variabilité

Une même entrée peut produire plusieurs sorties. Pour les tâches sensibles, exécuter plusieurs répétitions et mesurer stabilité du format, du choix d’outil ou de la réponse.

La température, le seed lorsque disponible, la version du modèle et les paramètres sont enregistrés. Un système peut être en moyenne correct mais trop instable pour la production.

Latence et disponibilité

Mesurer temps total et temps de chaque étape : récupération, modèle, outils, post-traitement. Suivre médiane et percentiles, pas seulement moyenne.

Les erreurs, timeouts, quotas et retries font partie de l’évaluation. Un modèle légèrement meilleur mais souvent indisponible peut être moins utile.

Coût par tâche réussie

Le coût inclut tokens, embeddings, reranking, outils, stockage et validation humaine. Il doit être rapporté au cas réussi, pas seulement à la requête.

Une sortie incorrecte peut déclencher une reprise coûteuse. Les scénarios de volume et de pic aident à comparer routage et cache.

Évaluer la sécurité

Le jeu inclut prompt injection, exfiltration, données interdites, contournement de politique, outils non autorisés et contenus toxiques selon l’usage. Les tests sont exécutés dans un environnement sûr.

Une erreur de sécurité critique bloque le lancement indépendamment du score moyen.

Définir les seuils

Chaque dimension possède :

• objectif ;
• minimum acceptable ;
• seuil critique ;
• propriétaire de l’exception.

Les seuils viennent du risque métier. Une extraction financière peut exiger une exactitude et un contrôle très élevés ; un brouillon créatif accepte davantage de variation.

Intégrer les évaluations à la livraison

Un petit jeu rapide s’exécute à chaque modification. Une suite complète tourne avant version ou périodiquement. Les coûts sont maîtrisés par échantillonnage et cache des composants inchangés.

Le rapport compare à une baseline et bloque les régressions critiques. Les changements de prompt, modèle, RAG, outil ou politique sont tous versionnés.

Surveiller en production

Les évaluations hors ligne ne couvrent pas toutes les requêtes. La production suit erreurs, refus, feedbacks, escalades, latence et coût. Des échantillons sont revus selon une politique de confidentialité.

Les incidents réels deviennent des cas de régression. Les données de suivi ne doivent pas collecter plus d’informations que nécessaire.

Éviter la contamination du jeu

Si le jeu est utilisé pour régler constamment le prompt, il devient un jeu d’entraînement implicite. Conserver un ensemble caché et renouveler les cas protège la capacité de généralisation.

Les fournisseurs et modèles peuvent aussi avoir vu certains benchmarks publics, raison supplémentaire de privilégier des cas propres.

Une évaluation comme actif produit

Le jeu de cas, les rubriques, les seuils et les rapports deviennent une propriété stratégique. Ils permettent de changer de modèle, d’optimiser le coût et de prouver qu’une version est meilleure.

Partitech peut construire les jeux d’évaluation, automatiser les contrôles, comparer les modèles et intégrer les régressions à la chaîne de livraison. L’objectif est de piloter la qualité sur des preuves, non sur l’impression d’une démonstration.

Parlons de votre projet

Mettre en place une plateforme d’évaluation IA avec Partitech. Contactez Partitech.