Observabilité de l’IA : confiance et contrôle pour les systèmes d'IA en production

Lorsque l'intelligence artificielle influe sur le support client, l’analyse financière, les processus de conformité ou les décisions stratégiques, une mauvaise sortie représente un risque métier. Pourtant, la plupart des déploiements d'IA en entreprise offrent étonnamment peu de visibilité sur les raisons pour lesquelles un système a produit une réponse donnée ou sur la marche à suivre lorsque quelque chose ne va pas.

L'observabilité de l'intelligence artificielle permet aux entreprises d'inspecter le comportement des systèmes d'IA une fois sortis du cadre contrôlé du prototype. À ce stade, les sorties dépendent non seulement du modèle lui-même, mais aussi des prompts, des politiques, des appels d'outils, de la latence et des données gouvernées disponibles au moment de la requête. L’observabilité aide les équipes à comprendre ce comportement et à répondre aux questions qui déterminent si l’on peut se fier à un système d’IA : Que fait réellement le système ? Pourquoi ? Pouvons-nous lui faire confiance ?

L'observabilité transforme l'IA d'une boîte noire en un système pouvant être observé, mesuré, interrogé et gouverné en continu, à grande échelle. Pour les entreprises qui exploitent l’IA sur des données stratégiques, c’est le fondement même d’une IA d’entreprise digne de confiance.

L’observabilité de l’IA consiste à instrumenter, tracer et évaluer les systèmes d’IA afin que les équipes puissent comprendre leur comportement sur l’ensemble du parcours, de l’entrée à la sortie. Pour une application d’IA générative, ce chemin peut inclure le prompt de l'utilisateur, les documents récupérés, la réponse du modèle, les appels d'outils, les étapes de raisonnement intermédiaires, la latence, l'utilisation des tokens, le coût et les scores d'évaluation. Pour un système agentique, il peut également inclure la séquence d’actions de l’agent, les outils qu’il a sélectionnés et les données auxquelles il a accédé en cours de route.

L’observabilité de l’IA repose généralement sur quatre piliers :

Transparence : Les équipes ont besoin de visibilité sur le comportement du système d’IA pour comprendre comment les prompts, le contexte récupéré, les réponses du modèle, les appels d’outils et la logique applicative interagissent au sein du flux de travail. Cette visibilité permet d’identifier l’origine d’un problème et de déterminer les mesures à prendre pour le résoudre.

Mesurabilité : Les entreprises ont besoin d'une méthode homogène pour évaluer si les sorties de l'IA sont précises, pertinentes, fondées, sûres, en temps opportun et rentables pour le processus qu'elles soutiennent. La mesurabilité permet aux équipes de comparer les prompts, les modèles, les stratégies de récupération et les configurations en se basant sur des faits plutôt que sur des suppositions.

Gouvernabilité : Les systèmes d’IA doivent fonctionner dans le respect des contrôles de l’entreprise. Cela implique de respecter les politiques d’accès, d’utiliser des sources de données approuvées, d’enregistrer les évaluations et de conserver suffisamment de traces pour enquêter sur les défaillances. À mesure que l’IA s’intègre à des processus réglementés et touche à des données sensibles, l’observabilité doit faire partie intégrante de la gouvernance, plutôt que d’être traitée comme un sujet d’ingénierie distinct.

Explicabilité : Les utilisateurs métier, les auditeurs, les développeurs et les dirigeants doivent comprendre comment un résultat a été généré avant de pouvoir lui faire confiance. L’explicabilité ne nécessite pas d’exposer chaque détail interne d’un modèle. Elle impose en revanche de présenter les entrées, le contexte, le cheminement de décision et les preuves d’évaluation qui permettent à une équipe d’enquêter, de corriger et d’améliorer le système.

L’observabilité de l’IA présente des points communs avec la supervision des modèles et la supervision du ML, mais son périmètre est plus large.

• La supervision des modèles se concentre sur un modèle déployé : Les équipes vérifient si les prédictions du modèle restent précises, si les données d’entrée ont dérivé, si la latence évolue et si le modèle respecte toujours les objectifs de niveau de service attendus. C’est le cœur de la supervision pour de nombreux systèmes de machine learning (ML) supervisés, en particulier ceux disposant d’une vérité terrain claire, comme la détection des fraudes, la prévision de l’attrition ou la prévision de la demande.
• La supervision du ML élargit cette vision à l’ensemble du pipeline : Un modèle peut se dégrader parce que les caractéristiques arrivent avec retard, les étiquettes sont différées, des modifications de schéma brisent une transformation ou un traitement par lots introduit des valeurs manquantes. La supervision du ML suit le chemin opérationnel autour du modèle, notamment la qualité des données, la fraîcheur des caractéristiques, l'état de santé du pipeline et le comportement des prédictions.
• L’observabilité de l’IA couvre l’ensemble du système d’IA : Dans une application de grand modèle de langage (LLM), le modèle n’est qu’un composant au sein d’une chaîne plus vaste. Une application RAG peut récupérer cinq documents, en transmettre trois dans le prompt, appeler un LLM, appliquer un garde-fou et enregistrer la réponse dans un processus. Un agent peut planifier une tâche, appeler un outil de recherche, interroger une table, synthétiser les résultats, appeler un autre outil, puis formuler une recommandation. L'observabilité doit capturer la trace, et pas seulement la réponse finale.

Lisez notre guide sur les MLOps pour découvrir comment les équipes opérationnalisent le cycle de vie du machine learning, du développement et du déploiement des modèles à leur supervision et leur gestion en production.

Les piliers classiques de l’observabilité sont les journaux, les métriques et les traces. Ils s’appliquent toujours aux systèmes d’IA, mais les objets observés sont différents. Au lieu de se limiter aux erreurs de service, à l'utilisation du processeur ou à la latence des API, les équipes doivent également inspecter les prompts, les documents récupérés, les réponses du modèle, le comportement des embeddings, l'utilisation des tokens, les appels d'outils, les scores de factualité (groundedness) et les retours des utilisateurs.

Journaux

Au niveau des événements, les journaux peuvent capturer le template de prompt, la requête de l'utilisateur, le nom du modèle, les métadonnées de réponse, la requête de récupération, les documents sélectionnés, les appels d'outils, les décisions de politique, les messages d'erreur et les retours. Dans un cadre d’entreprise, ces enregistrements nécessitent leur propre gouvernance. Les prompts et les réponses peuvent contenir des données propriétaires, des informations réglementées ou un contexte métier interne. La conservation, le masquage et les dispositifs de contrôle d'accès basés sur les rôles doivent donc faire partie de la conception.

Un journal d’événements utile fournit à l’équipe suffisamment de détails pour mener une enquête, sans pour autant transformer l’observabilité en une nouvelle source de données sensibles non gérées. Pour certains processus, cela peut consister à stocker des métadonnées par défaut et à n'autoriser qu'un accès limité au contenu complet des prompts et des réponses lors d'enquêtes approuvées.

Métriques

Au fil du temps, les métriques permettent de vérifier si le système reste stable. La latence, le débit, le taux d'erreur, le volume de requêtes, l'utilisation des tokens et le coût par requête capturent le versant opérationnel. La factualité (groundedness), la pertinence des réponses, la pertinence du contexte, l'exactitude factuelle, le taux de refus, la toxicité, l'exhaustivité et la cohérence capturent davantage le versant qualité de l'IA.

Dans les processus ML, la dérive des données, la dérive des prédictions et la dérive de concept aident les équipes à déterminer si le modèle opère toujours dans des conditions connues. L'indice de stabilité des populations (PSI), l'attribution des caractéristiques et les valeurs SHAP peuvent étayer cette analyse lorsqu'un modèle dépend de caractéristiques structurées et de résultats connus. Pour l'IA générative, dont les sorties sont basées sur le langage et souvent évaluées par rapport au contexte plutôt qu'à une étiquette unique, les métriques d'évaluation peuvent devoir mesurer dans quelle mesure une réponse exploite les informations récupérées ou satisfait une grille d'évaluation propre à la tâche.

Traces

Au sein d’une même requête, une trace suit le système d’une étape à l’autre. Dans un chatbot de base, cela peut se limiter au prompt, à l’appel du modèle et à la réponse. Dans une application RAG, la trace peut inclure la question initiale, la requête de récupération, les fragments classés, l’assemblage du prompt, l’appel d’inférence, les résultats d’évaluation et la réponse finale. Dans un processus agentique, les étapes peuvent couvrir la planification, la sélection des outils, les réponses des outils, les tentatives de correction et les résultats intermédiaires.

La valeur de la trace réside dans le fait qu’elle préserve la séquence des événements. Si une réponse cite la mauvaise politique, l'équipe peut déterminer si le mauvais document a été récupéré, si le bon document a été récupéré mais ignoré, ou si le modèle a généré un texte non étayé malgré la réception du bon contexte. Si un agent met 45 secondes à répondre à une question simple, la trace peut révéler si ce temps a été consacré à l’inférence du modèle, à un outil lent, à des récupérations répétées ou à une boucle dans la planification de l’agent.

Regardez Anahita Tafvizi, Chief Data & Analytics Officer chez Snowflake, décrypter l’architecture d’une IA générative de confiance :

À mesure que les systèmes d'IA combinent des données structurées, des documents non structurés, des embeddings et un contexte d'exécution, la dérive peut apparaître à plusieurs endroits.

• Dérive des données : Les données d’entrée évoluent au fil du temps. Un classificateur de support client entraîné sur les tickets de l'année dernière peut être confronté à de nouvelles catégories de produits, une nouvelle terminologie ou de nouvelles régularités d'escalade.
• Dérive de concept : La relation entre les entrées et les résultats change. Un modèle de détection des fraudes peut apprendre à partir d'une certaine régularité d'abus, puis faire face à une nouvelle tactique qui rend les corrélations passées moins fiables.
• Dérive de prédiction : La distribution des sorties change. Par exemple, un modèle qui classait auparavant 10 % des cas comme présentant un risque élevé classe désormais 35 %, même si l’entreprise ne s’attendait pas à un tel changement.
• Dérive des embeddings : Les représentations vectorielles changent à mesure que les données, les modèles ou les stratégies d’embedding évoluent. Dans un système RAG, cela peut affecter les documents récupérés et la similarité perçue entre deux contenus.
• Dérive de la qualité des données : Des valeurs manquantes, des mises à jour retardées, des modifications de schéma et des enregistrements en double affectent les données utilisées par le système, même lorsque le modèle lui-même n'a pas changé.
• Dérive d’équité et de biais : Le comportement du modèle peut varier selon les groupes d'utilisateurs, les régions, les gammes de produits ou les régularités linguistiques. L'observabilité aide les équipes à détecter si la qualité, le comportement de refus ou les taux d'erreur sont répartis de manière inégale.

L'observabilité des LLM porte sur le comportement des systèmes qui utilisent des grands modèles de langage, notamment les chatbots, les assistants documentaires, les processus de synthèse, les assistants de codage, les interfaces texte-vers-SQL et les applications RAG. Dans ces systèmes, la qualité ne dépend pas uniquement de la réponse du modèle. Les équipes doivent savoir si l'application a récupéré le bon contexte, assemblé le bon prompt, respecté les bons dispositifs de contrôle et produit une réponse utile, factuelle et gouvernée.

Tracer le pipeline RAG

Dans un pipeline RAG, la réponse est façonnée avant même que le modèle ne la génère. La requête peut être ambiguë, la couche de récupération peut renvoyer des documents non pertinents, ou le prompt peut inclure le bon document mais omettre l’instruction de le citer. Le modèle peut générer une réponse qui semble plausible mais qui n’est pas étayée par le contexte récupéré.

Un score de factualité peut aider à signaler ce type d’erreur, mais la trace montre précisément où elle s’est introduite dans le système. En capturant la requête, les documents récupérés, les fragments classés, l’assemblage du prompt, la réponse du modèle et le résultat de l’évaluation, les équipes peuvent identifier si le problème provient de la récupération, de la sélection du contexte, de la conception du prompt ou du comportement du modèle.

Surveiller les prompts, les réponses, les coûts et la latence

Le traçage des prompts et des réponses offre aux développeurs un moyen d'inspecter le chemin de la requête. Les spans peuvent capturer la récupération, les appels de modèles, les appels d'outils et d'autres opérations au sein d'une seule trace, permettant ainsi aux équipes d'examiner chaque étape sans avoir à reconstruire le processus à partir de journaux distincts.

La supervision de l'utilisation des tokens aide les équipes à comprendre les coûts et les performances, en particulier lorsqu'une application envoie des prompts longs, récupère trop de contexte ou effectue des boucles d'appels d'outils répétés. Les métriques de latence indiquent si les réponses lentes proviennent de la récupération, de l'inférence, de l'orchestration ou d'un service externe. Ensemble, ces signaux aident les équipes à optimiser l'application sans traiter la qualité, la rapidité et le coût comme des problèmes distincts.

Capturer les étapes de l’agent et les appels d’outils

L'observabilité de l'IA agentique ajoute une couche supplémentaire, car les agents ne se contentent pas de répondre à un prompt. Un agent peut effectuer toute une série d'actions : appeler un outil de recherche, interroger une table structurée, ouvrir un document, synthétiser des résultats et décider de poser une question de suivi.

L'observabilité doit capturer cette séquence pour que les équipes puissent vérifier si l'agent a sélectionné les bons outils, accédé aux bonnes données et su s'arrêter au bon moment. Sans cet enregistrement pas à pas, la réponse finale d'un agent peut sembler acceptable, même lorsque le processus sous-jacent était inefficace, non étayé ou en dehors des limites de politique prévues.

Standardiser la télémétrie de l’IA générative

OpenTelemetry s’impose comme un standard incontournable pour l’observabilité des LLM et de l’IA agentique. Ses conventions sémantiques d'IA générative définissent comment les opérations d'IA générative peuvent être enregistrées, notamment les appels de modèles, les comptages de tokens et, lorsque les organisations l'activent, le contenu des prompts, les complétions, les appels d'outils et les résultats d'outils.

Les applications d'IA s'étendant souvent sur plusieurs frameworks, modèles et couches d'infrastructure, un modèle de télémétrie commun est essentiel pour comparer le comportement entre les systèmes, réutiliser les pratiques d'instrumentation et éviter une pile d'observabilité fragmentée.

Avant d'instrumenter une application d'IA, les équipes doivent définir ce que le système doit démontrer en production. Par exemple, un assistant de support client doit prouver que sa réponse provient bien des politiques actuelles, tandis qu’un assistant financier doit montrer quels tableaux, définitions de métriques et périodes de reporting ont structuré l’explication d’un écart.

Les exigences du processus déterminent les données à capturer. Pour les processus à faible risque, des retours légers, des échantillons de traces et des contrôles de qualité de base peuvent suffire. Dans le cadre de processus réglementés ou stratégiques, l'application requiert généralement un traçage plus approfondi, des jeux de données d'évaluation plus stricts, des enregistrements soumis à un contrôle d'accès et des critères de validation clairs avant qu'un changement de prompt, de modèle ou de récupération ne soit déployé en production.

Instrumenter le chemin d’exécution avec la télémétrie

L’instrumentation permet de capturer les journaux, les métriques et les traces qui rendent le système observable. Pour les systèmes d’IA, cela consiste à instrumenter le parcours de l’application autour du modèle : prompts, récupération, appels d’outils, réponses du modèle, scores d’évaluation, latence, utilisation des tokens et retours des utilisateurs.

Pour un agent, cela inclut également la planification, les appels d'outils, les résultats intermédiaires, les nouvelles tentatives et les conditions d'arrêt.

Établir des références et des alertes

Une fois les traces et les métriques opérationnelles, les valeurs de référence fournissent aux équipes une plage normale pour la qualité et les performances, notamment pour la latence, le coût, la factualité, le taux de refus, la pertinence des réponses, les métriques de dérive et d'autres signaux. Ces références varient selon le processus. Elles doivent donc refléter la tâche en question plutôt qu’une norme générique.

Les alertes doivent se concentrer sur les changements significatifs plutôt que sur la moindre variation. Une légère augmentation de l’utilisation des tokens après l’ajout d’un contexte plus riche est tout à fait prévisible, alors qu’une baisse soudaine de la pertinence par rapport au contexte après la modification d’un prompt mérite une analyse approfondie.

Créer des boucles de rétroaction

L’observabilité de l’IA doit servir à alimenter l’amélioration continue. Les résultats d’évaluation peuvent guider les modifications de prompts, le réglage de la récupération, le choix du modèle, l’ajustement des garde-fous et la correction de la qualité des données. Les retours des utilisateurs permettent d’identifier les lacunes dans les données de test. L’analyse des traces peut révéler si un agent répète des tâches, choisit le mauvais outil ou ne parvient pas à exploiter le contexte récupéré.

Cette boucle est particulièrement cruciale pour l’IA générative, car la qualité s’évalue souvent de manière comparative. Les équipes doivent savoir si un nouveau prompt, modèle, stratégie d'embeddings ou configuration d'inférence a amélioré l'application pour la tâche prévue. L'observabilité de l'IA de Snowflake prend en charge la comparaison côte à côte des évaluations entre les LLM, les prompts et les configurations d'inférence, ce qui aide les équipes à évaluer la qualité des réponses avant de promouvoir une configuration en production.

Standardiser partout où cela est possible

À mesure que les applications d’IA se généralisent au sein des équipes, l’observabilité peut rapidement se fragmenter. Une équipe peut enregistrer les prompts dans la base de données d’une application, une autre suivre les coûts sur un tableau de bord, et une troisième conserver les résultats d’évaluation dans des notebooks. La standardisation de la télémétrie, des jeux de données d'évaluation, des métriques et des formats de traces aide l'organisation à comparer les systèmes et à réutiliser les pratiques opérationnelles.

OpenTelemetry peut s'avérer utile pour la couche de télémétrie, tandis que les plateformes de données gouvernées facilitent la gestion des données d'évaluation, des dispositifs de contrôle d'accès, des enregistrements de supervision et du stockage des traces. L’objectif n’est pas d’imposer une architecture unique à toutes les applications d’IA, mais de veiller à ce que chaque système d’IA en production fournisse suffisamment d’éléments pour que les équipes puissent l’évaluer et l’améliorer.

Pour l’IA d’entreprise, les données utilisées pour générer une réponse et les éléments requis pour évaluer cette même réponse doivent rester étroitement liés. Lorsque les données sources, les prompts, les traces, les évaluations et les politiques d’accès sont dispersés dans des systèmes déconnectés, chaque analyse commence par un travail de reconstruction : quelle version était active, quel contexte a été récupéré, quelle politique s’appliquait et quelle configuration a été modifiée.

Au sein de l’AI Data Cloud de Snowflake, Snowflake Cortex AI permet aux équipes d’accéder à des capacités d’IA générative sur des données d’entreprise gouvernées, tandis que la solution d’observabilité de l’IA de Snowflake assure l’évaluation systématique, la comparaison et la traçabilité des applications d’IA générative et des agents.

À mesure que les systèmes d’IA s’intègrent dans les processus métier, la confiance reposera sur la capacité de l’entreprise à inspecter le cheminement qui mène à chaque résultat. Une trace, un score d’évaluation, un document récupéré et une configuration de modèle ne sont pas de simples détails techniques a posteriori. Ce sont les enregistrements qui permettent aux équipes d'améliorer les systèmes d'IA sans perdre le contrôle des données, des politiques et des processus sur lesquels ils reposent.