Guides

Évaluer une IA en production : métriques, tests et observabilité

Une démonstration réussie ne prouve pas qu’une IA tiendra en production. Apprenez à construire un jeu d’évaluation, choisir les métriques utiles et surveiller la dérive.

Promptique21 août 202622 min de lecture

Analyste examinant des graphiques de performance sur un écran dans un bureau

Évaluer une IA en production consiste à mesurer de façon reproductible si un système génératif produit le résultat attendu sur des cas représentatifs, puis à surveiller si cette qualité tient face au trafic réel. Une évaluation hors ligne sans observabilité mesure un monde qui n’existe plus ; une observabilité sans évaluation accumule des traces que personne ne sait interpréter.

La difficulté est méthodologique avant d’être technique. Un système à base de modèle de langage échoue rarement de façon bruyante : il répond, la phrase est bien construite, le format est correct, et la valeur est fausse. Aucune exception n’est levée. Le taux d’erreur ne se lit pas dans les journaux ordinaires : il doit être fabriqué, avec des critères écrits à l’avance et des cas dont on connaît la bonne réponse.

Ce guide couvre la chaîne complète : familles d’évaluation, jeu de cas, métriques par tâche et par RAG, discipline du modèle-juge, non-régression, instrumentation, dérive et déploiement progressif. L’écriture des critères à l’échelle d’un prompt isolé est traitée dans Évaluer un prompt ; ce guide l’étend au système complet.

L’essentiel en 60 secondes

Une démonstration réussie prouve qu’un cas favorable existe, pas que le système tient sur la distribution réelle.
Trois familles d’évaluation coexistent – mécanique, modèle-juge, humaine – avec des domaines de validité étroits et des coûts très différents.
Automatisez tout critère décidable sans interprétation : schéma, champ obligatoire, code exécuté, outil appelé.
Un jeu utile mélange cas nominaux, limites, hostiles, d’abstention et de régression, issus majoritairement d’échecs réels.
Séparez un jeu figé, contrat de non-régression, un jeu vivant alimenté par la production, et une réserve jamais consultée.
Retenez trois à cinq métriques : une de qualité, une de sûreté, une de coût, une de latence, une d’usage réel.
Le modèle-juge est un composant versionné, pas un oracle : biais de position, de verbosité et d’auto-préférence, à calibrer contre un échantillon humain.
L’unité évaluée n’est pas le prompt mais la configuration entière : prompt, modèle et version, paramètres, outils, index, grille du juge, jeu de tests.
En production, la trace est l’unité d’observation : un identifiant par exécution, un span par appel, la signature de version attachée.
La dérive se détecte sur des distributions stables – refus, abstention, format invalide, escalade – jamais sur une réponse isolée.

À retenir : un système d’IA n’est pas bon ou mauvais dans l’absolu, il est bon sur une distribution de cas mesurée, avec une version identifiée, à une date donnée.

Sommaire

Pourquoi une démonstration réussie ne prédit rien
Les trois familles d’évaluation
Construire un jeu d’évaluation représentatif
Choisir les métriques qui correspondent à la tâche
Les métriques propres au RAG
Discipliner le modèle-juge
Non-régression et versionnage conjoint
L’observabilité en production
Retours utilisateurs et détection de dérive
Miroir, canary et test A/B
La boucle incident vers cas de test
La méthode en sept étapes et la fiche d’évaluation
Ce que l’évaluation ne résout pas
Checklist d’évaluation et de surveillance
FAQ sur l’évaluation et l’observabilité des LLM
Pour aller plus loin

Pourquoi une démonstration réussie ne prédit rien

Trois écarts séparent la démonstration de l’exploitation. L’écart d’opérateur : celui qui démontre connaît la réponse attendue, emploie le vocabulaire du système et relance quand la sortie déçoit ; l’utilisateur réel arrive avec une formulation ambiguë. L’écart de distribution : les cas montrés viennent du centre, alors que le coût opérationnel se concentre dans la queue – entrées vides, langues mélangées, documents contradictoires, questions dont la bonne réponse est « je ne sais pas ». L’écart de temps : un modèle est mis à jour, un paramètre déprécié, un index reconstruit, et le comportement change sans que rien n’ait bougé chez vous.

S’y ajoute la variabilité intrinsèque : même à température nulle, deux appels identiques peuvent diverger selon le routage et les optimisations d’inférence. Une conclusion tirée d’une exécution unique n’est pas une mesure, c’est un tirage.

Les trois familles d’évaluation

Famille	Mesure bien	Mesure mal	Coût	Fréquence
Mécanique	Schéma, champ présent, valeur exacte, code exécuté, outil appelé, latence, coût	Pertinence, nuance, qualité rédactionnelle	Très faible	À chaque exécution
Modèle-juge	Questions fermées : fidélité à la source, respect d’une consigne, complétude, ton	Notes globales, jugement expert métier	Faible à moyen	À chaque changement de configuration
Humaine	Vérité de référence, cas ambigus, validation de la grille, préjudice perçu	Volume, fréquence, reproductibilité	Élevé	Sur échantillon, pour calibrer

La règle de décision tient en trois branches. Si un programme peut trancher sans interprétation, écrivez le programme. Sinon, si le critère se reformule en question fermée sur une propriété observable – « chaque affirmation chiffrée figure-t-elle dans le document fourni ? » –, un modèle-juge est légitime, à condition d’être calibré. Sinon, seul un humain tranche, sur échantillon. L’erreur courante consiste à passer directement au juge : il coûte plus cher qu’une assertion et ajoute une source d’erreur dans la mesure.

Construire un jeu d’évaluation représentatif

D’abord les échecs réels

Un jeu inventé mesure votre imagination. Les sources utiles, dans l’ordre : échecs observés en production, cas traités par les experts métier, tickets d’escalade, retours négatifs. Le synthétique n’intervient qu’en dernier, pour combler une catégorie sous-représentée. Anthropic recommande de démarrer avec « vingt à cinquante tâches simples issues d’échecs réels » (page d’ingénierie Demystifying evals for AI agents, consultée le 21 août 2026) : un jeu petit mais authentique suffit à détecter les écarts importants.

Cinq catégories, pas une

Distinguez les cas nominaux, limites (entrée vide, document tronqué, langue inattendue), hostiles (injection de prompt, exfiltration de consigne système, demande hors périmètre), d’abstention (la bonne réponse est un refus) et de régression, issus d’incidents passés. La catégorie d’abstention est la plus souvent oubliée, alors qu’elle porte la mesure la plus utile face aux hallucinations des IA génératives : un système incapable de dire « information insuffisante » remplace l’abstention par une réponse plausible, et l’erreur devient invisible. Pour les cas hostiles, appuyez-vous sur le Top 10 OWASP pour les applications à base de LLM, dont l’édition 2026, publiée en août 2026, maintient l’injection de prompt en première position (LLM01).

Taille, jeu figé et réserve

La taille dépend de l’écart à détecter, pas d’une règle. Un taux de réussite est une proportion : encadrez-le par un intervalle de confiance binomial, et comparez deux variantes sur le même jeu avec un test apparié, celui de McNemar par exemple. Maintenez ensuite trois ensembles : un jeu figé, qui ne change que par ajout daté et sert de contrat de non-régression ; un jeu vivant, alimenté par échantillonnage de la production ; une réserve jamais consultée pendant l’optimisation, sans laquelle l’équipe finit par ajuster ses prompts sur le jeu de test.

Choisir les métriques qui correspondent à la tâche

Une métrique n’est utile que si elle peut changer une décision : trois à cinq suffisent. Publiez une distribution plutôt qu’une moyenne, segmentez par cohorte – langue, canal, type de document –, et affichez le dénominateur : un pourcentage sans effectif n’est pas une mesure.

Métrique	Tâches concernées	Mode de mesure	Piège
Exactitude	Extraction, classification, calcul	Comparaison à une référence, exécution, assertion	Inapplicable aux sorties ouvertes
Complétude	Synthèse, compte rendu, rapport	Liste d’éléments obligatoires vérifiée un à un	Confondue avec la longueur
Fidélité à la source	Réponse ancrée sur documents	Chaque affirmation vérifiée contre le contexte	Une réponse fidèle peut être hors sujet
Taux d’abstention	Support, conseil, assistance	Part des cas d’abstention effectivement refusés	Trop élevé, il rend le système inutile
Respect du format	Sortie structurée, appel d’outil	Validation de schéma	Un JSON valide peut porter une valeur fausse
Latence p50 et p95	Tout usage interactif	Histogramme par span	La moyenne masque la queue
Coût par tâche résolue	Tout usage facturé au jeton (token)	Coût total divisé par les tâches abouties	Le coût par appel ignore les reprises
Taux d’escalade	Support, agents opérationnels	Part des exécutions passées à un humain	Baisse si l’escalade est peu accessible
Réussite de bout en bout	Agent multi-étapes	Vérification de l’état final, pas du texte	Récompenser un chemin, pas un résultat
pass@k et pass^k	Agent non déterministe	Réussite au moins une fois sur k essais, et aux k essais	Publier pass@k seul

Le coût par tâche résolue

Le prix au million de jetons ne dit rien du coût d’un résultat. L’exemple qui suit est une hypothèse de calcul, pas une mesure. Tarif retenu : le tarif promotionnel de Claude Sonnet 5 documenté au 21 août 2026, soit 2 $ le million de jetons d’entrée et 10 $ le million en sortie, valable jusqu’au 31 août 2026 ; le tarif standard annoncé ensuite est de 3 $ et 15 $ (notes de version Anthropic, détail Promptique). Hypothèses posées : 3 000 jetons d’entrée, 600 en sortie, 1,4 tentative par exécution, 70 % d’exécutions abouties sans intervention humaine. Au tarif promotionnel, une tentative coûte 0,012 $, une exécution 0,0168 $, et la tâche résolue environ 0,024 $ de modèle, plus le traitement humain des 30 % restants. Reprenez la formule avec vos propres relevés et le tarif du jour, jamais ces trois nombres.

Les métriques d’un agent

Pour un système qui agit, le résultat est l’état final, pas le texte. Mesurez l’aboutissement (ticket clos, fichier écrit, enregistrement créé), le nombre de pas, les boucles improductives, le taux d’appel d’outil correct et le coût par exécution. Le couple pass@k et pass^k, mis en avant par Anthropic, sépare deux profils : un agent capable mais instable présente un pass@k élevé et un pass^k faible. Sans supervision, c’est pass^k qui décide, comme le détaille notre guide des agents IA et de MCP.

Les métriques propres au RAG

Un système de récupération augmentée échoue à deux endroits distincts, et une métrique globale ne dit pas lequel. Côté récupération, le rappel mesure la part des passages nécessaires présents parmi les k retournés, la précision la part des passages retournés réellement utiles. Côté génération, la fidélité vérifie que chaque affirmation est soutenue par les passages fournis, la pertinence que la réponse traite bien la question. La bibliothèque Ragas formalise ce découpage sous les noms context precision, context recall, faithfulness et response relevancy, en distinguant les métriques qui exigent une référence humaine de celles qui s’en passent.

Une réponse fausse malgré une fidélité élevée invite d’abord à contrôler les passages récupérés : ils peuvent être faux, incomplets ou contradictoires. Un rappel élevé n’innocente pas la récupération, car la précision et le reclassement comptent aussi. Attribuez la cause en inspectant séparément les passages requis, les passages retournés et les affirmations générées. Les leviers diffèrent selon le diagnostic, avec le découpage, l’index et le reclassement côté récupération, puis le prompt et le contrat de sortie côté génération, comme détaillé dans notre guide du RAG en 2026.

Discipliner le modèle-juge

Lorsque le volume dépasse la capacité de revue humaine, un modèle-juge devient souvent utile, sans être obligatoire ni suffisant. Il reste exposé à des biais systématiques. Les travaux de Lianmin Zheng et de ses coauteurs, présentés à NeurIPS 2023 sous le titre « Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena », ont documenté les biais qui structurent encore la discussion.

Biais	Manifestation	Correctif
Position	La réponse placée en premier est favorisée	Évaluer les deux ordres, ne conclure que si le verdict est stable
Verbosité	La réponse la plus longue est jugée meilleure à contenu égal	Apparier les longueurs ; tester une variante redondante
Auto-préférence	Le juge favorise les sorties de son propre modèle	Calibrer contre l’humain ; une autre famille peut réduire les biais corrélés sans les éliminer
Format	Titres, listes et gras améliorent la note sans le fond	Neutraliser la mise en forme ou l’évaluer à part
Échelle	Sur une note de 1 à 10, le juge se réfugie au milieu	Questions binaires, une par dimension
Formulation	Un changement mineur de consigne déplace la note	Versionner la grille, rejouer l’étalonnage

Calibrer contre un échantillon humain

Un juge non calibré est une opinion automatisée. Faites annoter un échantillon par deux personnes indépendantes, sur les mêmes questions fermées que le juge. Mesurez d’abord l’accord entre les deux humains : s’il est faible, la définition est en cause, pas le modèle. Mesurez ensuite l’accord entre le juge et le consensus humain, avec un accord brut et un coefficient corrigé du hasard, le kappa de Cohen par exemple. Lisez les désaccords un par un : ils signalent presque toujours une dimension mal définie.

Repère utile : Zheng et ses coauteurs rapportaient en 2023 un accord de 85 % entre GPT-4 employé comme juge et les évaluateurs humains, contre 81 % entre humains eux-mêmes. Ces valeurs sont celles de leur article, avec leur protocole et un modèle qui n’existe plus sous cette forme : elles ne définissent pas un niveau d’accord attendu chez vous, elles montrent seulement qu’un juge calibré peut approcher l’accord inter-humain. Le juge est lui-même un artefact versionné : en changer invalide les comparaisons historiques.

Non-régression et versionnage conjoint

Ce qui produit un résultat n’est pas le prompt, mais une configuration complète : texte du prompt, modèle et version exacte, paramètres, définitions d’outils, index documentaire et sa date, grille du juge, jeu de tests. Un score n’a de sens que rattaché à cette signature.

Ne modifiez qu’un élément à la fois, archivez chaque campagne avec sa signature et ses sorties brutes, et posez une porte de non-régression en intégration continue, bloquante sur les cas de régression et les assertions. Les plateformes s’y mettent, comme le montre le versionnage des prompts et des Skills de Mistral Studio, mais un dépôt Git suffit.

Une régression peut venir du fournisseur, mais aussi du prompt, des données, des outils, du routage ou de votre code. Les changements d’API de Gemini 3.6 Flash, où temperature, top_p et top_k cèdent la place à thinking_level illustrent la règle : traitez toute migration comme une nouvelle version de produit et rejouez le jeu complet avant de basculer, y compris quand le changement annoncé est une baisse de prix.

L’observabilité en production

Une trace représente une exécution de bout en bout ; elle se décompose en spans, un par opération – appel de modèle, appel d’outil, récupération, garde-fou. Elle répond à la seule question utile pendant un incident : à quelle étape la chaîne a dévié.

Les conventions sémantiques GenAI d’OpenTelemetry normalisent ce vocabulaire : spans invoke_agent, chat et execute_tool, attributs gen_ai.request.model ou gen_ai.usage.input_tokens, instruments gen_ai.client.operation.duration et gen_ai.client.token.usage. Au 21 août 2026, elles ne sont pas déclarées stables et ont quitté le dépôt principal des conventions pour un dépôt dédié : vérifiez-y les noms exacts avant d’instrumenter, et isolez le nommage derrière une couche interne pour absorber les renommages.

Capturez l’identifiant de trace, la signature de version, les compteurs de jetons, la latence par span, le motif d’arrêt, les erreurs d’outil et les documents récupérés avec leur score. Capturez les entrées et sorties selon une politique écrite « masquage, conservation, base légale », sujet traité dans notre guide de l’IA générative en entreprise, RGPD et AI Act. Pour les systèmes à haut risque, l’article 72 impose aux fournisseurs une surveillance après commercialisation documentée et proportionnée aux risques, intégrée au système de gestion de la qualité. Depuis le règlement (UE) 2026/1744, son paragraphe 3 ne prévoit plus d’acte d’exécution ni de modèle harmonisé obligatoire : la Commission doit publier, au plus tard le 2 septembre 2027, des lignes directrices comprenant un modèle de plan. Construisez votre plan à partir du texte consolidé en vigueur et réévaluez-le lorsque ces orientations seront publiées.

Échantillonnez sans perdre l’information utile : conservez toutes les exécutions en erreur, en escalade, signalées négativement ou ayant déclenché un garde-fou, plus un échantillon fixe du trafic nominal et un échantillonnage adaptatif sur anomalie.

Retours utilisateurs et détection de dérive

Les retours explicites – pouce, note, « cette réponse a-t-elle résolu votre problème » – sont peu coûteux et biaisés : ils captent les extrêmes et manquent l’insatisfaction tiède. Les retours implicites sont plus informatifs : reformulation immédiate, abandon, copie ou édition du texte, escalade, réouverture d’un ticket. Instrumentez-en au moins deux dès le premier jour, reliés aux traces.

La dérive touche les entrées, les sorties et la performance à jeu constant. N’alertez jamais sur une réponse isolée : alertez sur un déplacement de distribution mesuré sur fenêtre glissante. En pratique, les indicateurs les plus stables sont le taux de format invalide, le taux d’abstention, le taux de refus, le taux d’escalade et la latence p95. Rejouez enfin périodiquement le jeu figé contre le système déployé : c’est le seul moyen de distinguer une dégradation du système d’un changement de population.

Miroir, canary et test A/B

Stratégie	Ce qu’elle mesure	Risque utilisateur	Prérequis
Miroir (shadow)	Qualité, coût et latence de la candidate sur le trafic réel	Nul	Coût doublé, aucun effet de bord
Canary	Comportement réel sur une fraction du trafic	Limité à la fraction exposée	Garde-fous et retour arrière automatisés
Test A/B	Effet sur le comportement utilisateur et l’issue métier	Réel sur un bras	Métrique principale et horizon fixés à l’avance

Le mode miroir est le moins employé des trois, alors qu’il est le seul à comparer deux configurations sur la distribution réelle sans exposer un seul utilisateur, à condition que la candidate ne produise aucun effet de bord. Pour un test A/B, fixez la métrique principale et la durée avant de lancer, sinon vous arrêterez l’expérience au moment qui vous arrange, et prévoyez des garde-fous capables d’invalider un gain. Un test A/B mesure un effet sur les utilisateurs, pas la justesse.

La boucle incident vers cas de test

C’est le mécanisme qui fait progresser un système sur la durée, et c’est un rituel plus qu’un outil. Chaque incident suit le même trajet : isoler une reproduction minimale (entrée exacte, signature de version, trace) ; formuler l’assertion qui l’aurait détecté, non pas « la réponse doit être meilleure » mais « le champ montant doit être absent quand le document ne le mentionne pas » ; ajouter le cas au jeu figé ; corriger ; rejouer le jeu complet. Un incident n’est clos que lorsque son cas de test existe. Prévoyez un tri hebdomadaire sur trois files : escalades, retours négatifs, alertes de dérive.

La méthode en sept étapes et la fiche d’évaluation

Écrire la définition de réussite et le coût de l’erreur. Le second détermine l’effort de vérification.
Rassembler vingt à cinquante cas réels, couvrant les cinq catégories, avec un critère d’acceptation chacun.
Instrumenter avant d’optimiser : traces, spans, signature de version, jetons, latence.
Choisir trois à cinq métriques – qualité, sûreté, coût, latence, usage – et dater les seuils retenus.
Automatiser le décidable, calibrer le reste : assertions d’abord, modèle-juge étalonné ensuite.
Poser une porte de non-régression en intégration continue.
Déployer progressivement et boucler : miroir, canary, généralisation, surveillance, réinjection des incidents.

La fiche ci-dessous rassemble dans un fichier versionné ce qu’une campagne doit déclarer.

fiche_evaluation:
  id: support-n1-remboursement
  version_fiche: 4
  date: 2026-08-21
  definition_reussite: "cite la politique fournie, indique le delai,
    demande une precision si la date d'achat est absente"
  cout_erreur: eleve          # faible | moyen | eleve

  systeme_evalue:
    modele: "<fournisseur>/<modele>"
    version_modele: "<identifiant exact renvoye par l'API>"
    parametres: { temperature: 0, max_output_tokens: 800 }
    prompt_ref: prompts/support_n1.md@a1b2c3d
    outils: [[email protected], [email protected]]
    index_rag: { nom: politiques-fr, construit_le: 2026-08-14 }

  jeu_de_tests:
    fige: tests/fige.jsonl          # non-regression
    vivant: tests/vivant.jsonl      # issu de la production
    reserve: tests/holdout.jsonl    # jamais lu en optimisation
    repartition: { nominal: 20, limite: 8, hostile: 6, abstention: 6, regression: 12 }

  metriques:
    - { nom: exactitude_delai, type: mecanique, seuil_bloquant: aucune_regression }
    - { nom: format_valide, type: mecanique, seuil_bloquant: 100_pourcent }
    - { nom: fidelite_source, type: juge, mesure: grille_v3_Q1 }
    - { nom: abstention_correcte, type: juge, mesure: grille_v3_Q3 }
    - { nom: latence_p95, type: observabilite, mesure: span_chat_7j }
    - { nom: cout_par_tache_resolue, type: observabilite }

  juge:
    modele: "<juge calibre contre annotations humaines>"
    grille: evals/grilles/fidelite_v3.md    # questions binaires
    calibration: { echantillon: 40, annotateurs: 2, accord: kappa_de_Cohen, date: 2026-08-11 }

  production:
    echantillonnage: { erreurs: tout, escalades: tout, nominal: taux_fixe }
    alertes_derive: [format_invalide, abstention, escalade, latence_p95]
    deploiement: miroir -> canary -> generalisation

Ce que l’évaluation ne résout pas

Elle ne mesure que ce que vous avez pensé à mesurer. Les défaillances les plus coûteuses sont souvent hors grille : un ton inadapté, une réponse exacte mais juridiquement risquée. Rien ne remplace la lecture de transcriptions réelles.
Un score agrégé ne dit rien du préjudice individuel. Un taux de réussite élevé reste compatible avec un échec grave concentré sur une population. Traitez à part les erreurs à conséquence lourde.
Le juge hérite des angles morts du modèle. Quand les modèles se trompent de façon corrélée, il valide l’erreur avec assurance. L’échantillon humain reste indispensable.
Le jeu figé vieillit pendant que l’équipe s’y ajuste. Renouvelez-le et documentez chaque retrait.
Les seuils sont des décisions, pas des vérités. Déclarer un taux acceptable est un arbitrage de risque, porté par une personne identifiée et daté.

Checklist d’évaluation et de surveillance

☐ La définition de réussite et le coût de l’erreur sont écrits d’avance.
☐ Le jeu couvre les cas nominaux, limites, hostiles, d’abstention et de régression.
☐ Jeu figé, jeu vivant et réserve non consultée sont séparés.
☐ Tout critère décidable par un programme est vérifié par une assertion.
☐ Le juge est calibré contre des annotations humaines et sa grille est versionnée ; une autre famille de modèles est un garde-fou complémentaire.
☐ L’accord juge/humain est mesuré avec un coefficient corrigé du hasard.
☐ Chaque campagne est archivée avec sa signature et ses sorties brutes.
☐ Une porte de non-régression bloque l’intégration continue.
☐ Les traces portent un identifiant, un span par opération et la signature de version.
☐ La politique de capture est écrite : masquage, conservation, base légale.
☐ Les alertes portent sur des distributions, jamais sur une réponse isolée.
☐ Chaque incident clos a produit un cas de test dans le jeu figé.

FAQ sur l’évaluation et l’observabilité des LLM

Combien de cas de test faut-il pour évaluer une IA ?

Aucun nombre n’est universel : la taille dépend de l’écart minimal à détecter. Commencez avec vingt à cinquante tâches issues d’échecs réels, puis encadrez le taux de réussite par un intervalle de confiance et comparez les variantes avec un test apparié.

Peut-on faire évaluer un LLM par un autre LLM ?

Oui, avec trois garde-fous recommandés : des questions fermées sur des propriétés observables plutôt qu’une note globale, une calibration périodique contre un échantillon annoté par des humains et, lorsque cela réduit les biais corrélés, un juge d’une autre famille que le système évalué. Sans calibration humaine, vous automatisez une opinion plutôt que de construire une mesure fiable.

Quelle différence entre évaluation hors ligne et observabilité ?

L’évaluation hors ligne rejoue des cas connus contre une configuration donnée : « cette version est-elle meilleure que la précédente ». L’observabilité enregistre ce qui se passe réellement : « que vit l’utilisateur maintenant ».

Faut-il tout réévaluer quand le fournisseur met à jour son modèle ?

Oui, y compris quand la mise à jour est présentée comme une amélioration ou une baisse de prix. Un changement de version déplace la répartition des erreurs, la longueur des sorties et le comportement de refus. Rejouez le jeu figé avant la bascule.

Comment mesurer les hallucinations en production ?

Sans référence, pas directement. Trois approximations se suivent en continu : la fidélité à la source, le taux d’abstention sur les cas où la bonne réponse est un refus, et le taux de citations invalides.

Quels outils d’observabilité pour un système à base de LLM ?

Le format des données compte plus que l’outil. Instrumentez avec les conventions sémantiques GenAI d’OpenTelemetry, indépendantes du fournisseur, en isolant le nommage derrière une couche interne.

Que faire si le score baisse sans changement de notre côté ?

Vérifiez la version renvoyée par l’API, la date de l’index, les erreurs d’outil, puis la population d’entrées. Rejouez ensuite le jeu figé contre le système déployé : s’il se dégrade, la cause est en aval ; s’il tient, ce sont vos données ou vos utilisateurs qui ont changé.

Pour aller plus loin

Sur ce site : Évaluer un prompt pour l’échelle du prompt isolé, le guide du RAG en 2026, le guide des agents IA et de MCP, le guide du prompt engineering et le guide du fine-tuning en 2026.

Sources externes de référence :

Anthropic, Demystifying evals for AI agents – familles d’évaluations, pass@k et pass^k.
OpenAI, Evaluation best practices et Trace grading.
Lianmin Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023.
OpenTelemetry, conventions sémantiques GenAI et le dépôt dédié où elles sont maintenues.
OWASP, GenAI LLM Top 10 2026 – les cas hostiles à couvrir dans le jeu de tests.
AI Act consolidé au 27 juillet 2026 : article 72 sur la surveillance après commercialisation.
Règlement (UE) 2026/1744 : suppression de l’acte d’exécution et calendrier des futures lignes directrices.
Anthropic, notes de version Claude : échéance du tarif promotionnel de Sonnet 5.