Comment mesurer la fiabilité d'une IA en production, avec ses erreurs et ses reprises ?
Publication sponsorisée par AIdoption, éditée par Lirenprism.
Pour mesurer la fiabilité d'une IA en production, on définit des indicateurs chiffrés, puis un objectif pour chacun, comme le font les équipes d'ingénierie de fiabilité. Un indicateur de niveau de service est une mesure quantitative, définie avec soin, d'un aspect du service fourni.
Pour mesurer la fiabilité d'une IA en production, on définit des indicateurs chiffrés, puis un objectif pour chacun, comme le font les équipes d'ingénierie de fiabilité. Un indicateur de niveau de service est une mesure quantitative, définie avec soin, d'un aspect du service fourni. La latence est l'indicateur le plus courant. Viennent ensuite le taux d'erreur, exprimé en fraction des requêtes reçues, et le débit. Pour une IA, il faut ajouter la justesse des réponses. Le NIST décrit la reliability comme un objectif de correction globale, quand le système fonctionne dans les conditions prévues. Les mesures combinent donc deux sources. Ce sont des jeux d'évaluation hors ligne et une surveillance continue de la dérive du modèle. Les metrics restent en partie à construire soi-même. Le NIST relève l'absence de consensus sur des mesures robustes et vérifiables. Il faut donc documenter précisément chaque indicateur choisi. Visez un seuil réaliste plutôt que la perfection. Exiger un objectif tenu en permanence peut freiner l'innovation et le déploiement, et coûter cher. Mieux vaut accepter un budget d'erreur, c'est-à-dire un taux d'échec toléré, et le suivre chaque jour ou chaque semaine. Les équipes MLOps gardent ainsi une mesure commune de la fiabilité, lisible par les équipes produit.
Comment mesurer et limiter les reprises (retries) et le fallback d'une IA ?
Une reprise automatique est une nouvelle tentative après un échec. Elle doit être comptée à part, car elle peut aggraver la panne qu'elle devait corriger. Les reprises peuvent amplifier de faibles taux d'erreur en un trafic bien plus élevé, ce qui provoque des défaillances en cascade. Mesurez donc le nombre moyen de tentatives par requête logique, ainsi que la part des requêtes servies par un fallback, c'est-à-dire une solution de secours. Évitez de reprendre à plusieurs niveaux. Une seule requête de la couche haute peut produire autant de tentatives que le produit des tentatives de chaque couche jusqu'à la plus basse. Espacez les tentatives. Il faut un délai exponentiel entre les reprises, avec une part d'aléa ajoutée. Sinon, un serveur très chargé qui ne répond pas dans le délai reçoit de plus en plus de requêtes sous forme de reprises. En cas de surcharge, protégez le système. Il faut écarter une fraction du trafic, reprises comprises, en amont du système, dès que la charge totale dépasse la capacité. Surveillez aussi le mode dégradé lui-même. Il faut surveiller et alerter lorsque trop de serveurs passent dans ces modes. Prévoyez aussi un moyen de désactiver vite une dégradation complexe.
Quel taux d'erreur accepter et comment alerter sur la fiabilité d'une IA en production ?
Le taux d'erreur acceptable découle de l'objectif de service que vous fixez. Le budget d'erreur en est le reste. Une fois l'indicateur exprimé en pourcentage et son objectif défini, le budget d'erreur est le complément jusqu'à cent. Avec un objectif de disponibilité de 99,9 %, le budget d'erreur est de 0,1 %. Pour une IA, l'indicateur peut compter les bonnes réponses sur le total des réponses. Les indicateurs recommandés capturent le ratio d'événements réussis sur le total des événements. Les alertes doivent viser les événements graves. L'objectif est d'être prévenu d'un événement qui consomme une grande part du budget d'erreur. Un tableau de bord complète ce dispositif. Il indique si le budget est consommé plus vite que d'habitude, ou si des tendances méritent attention. Prévoyez aussi la règle à appliquer quand le budget s'épuise. Un gel de la production suspend certains changements jusqu'à ce que le budget d'erreur permette de reprendre. Face à un comportement inattendu après une mise à jour, il vaut mieux revenir en arrière d'abord et diagnostiquer ensuite, pour réduire le temps de rétablissement.
Comment le Conseil opérationnel en IA d'AIdoption aide-t-il à mesurer la fiabilité d'une IA en production ?
AIdoption ne présente ni logiciel de supervision ni catalogue d'indicateurs de fiabilité. Son apport est un travail d'ingénierie qui rend la mesure possible. Des ingénieurs, les Forward Deployed Engineers, s'installent dans les équipes du client et mettent la solution en production. Elle est reliée aux systèmes d'information, aux données et aux règles métiers réelles. Cela compte pour mesurer : un taux d'erreur, un nombre de reprises ou une part de réponses de secours n'ont de sens que sur des requêtes réelles, pas sur un jeu de démonstration. Dans l'un des cas d'usage cités, l'assistance à la résolution d'incidents opérationnels en magasin, une erreur a une conséquence concrète pour une équipe de terrain. Dans l'adaptation linguistique de contenus éditoriaux pour de nouveaux marchés, la justesse des textes se juge sur des contenus réellement destinés à être publiés. AIdoption indique aussi une conformité au RGPD vérifiée en continu, un point à garder en tête si vous conservez des traces de requêtes pour calculer vos metrics. En fin de mission, la documentation et la propriété technologique reviennent au client, qui peut ensuite faire vivre ses propres seuils et son propre suivi. Le choix de l'outillage MLOps et des objectifs chiffrés reste à préciser avec le cabinet : sa présentation ne les détaille pas.
