L'observabilité de l'IA devient une exigence en production

Les logiciels traditionnels fournissent aux équipes techniques un ensemble familier d'indicateurs opérationnels. Les ingénieurs peuvent vérifier si une application répond, combien de temps prend une requête de base de données, si un serveur est à court de mémoire et quelle erreur a entraîné l'échec d'une requête. Les applications d'IA se comportent différemment, car le système peut rester techniquement en bon état tout en produisant une réponse inexacte, non pertinente ou inadaptée au processus métier dans lequel il opère.

L'adoption de cette technologie par les entreprises met en évidence cette lacune, à mesure que celles-ci font passer l'IA générative du stade expérimental à une utilisation à grande échelle. Un chatbot utilisé par dix employés peut être supervisé de manière informelle, tandis qu'un système d'IA traitant des milliers d'interactions avec les clients nécessite un moyen d'identifier les défaillances sans demander à un humain de vérifier chaque résultat.

L'observabilité de l'IA étend la surveillance de l'infrastructure au comportement des modèles. Les entreprises ont toujours besoin d'indicateurs classiques tels que la latence, la disponibilité et le coût de calcul, mais elles ont également besoin d'informations sur les données reçues par le modèle, les documents qu'il a récupérés, les outils qu'il a utilisés et la manière dont la réponse finale a été générée.

Les systèmes de recherche illustrent bien ce problème, car une réponse erronée peut trouver son origine plusieurs étapes avant même que le modèle linguistique ne génère le moindre texte. La couche de recherche peut extraire une politique obsolète, un filtre d’autorisations peut exposer le mauvais document, ou un système de classement peut sélectionner des informations techniquement liées à la requête tout en omettant la section pertinente. Se contenter de surveiller le modèle final oblige les équipes d'ingénieurs à tenter de diagnostiquer une erreur sans avoir de visibilité sur la chaîne qui l'a générée.

Les agents renforcent cette nécessité, car ils interviennent sur plusieurs systèmes. Un agent peut par exemple interpréter une requête, effectuer une recherche dans une base de données, appeler une API, modifier un enregistrement et envoyer un message ; l'entreprise doit donc comprendre l'enchaînement des événements lorsqu'un problème survient. Se contenter d'enregistrer la requête initiale et la réponse finale n'est guère utile lorsque la défaillance s'est produite lors du quatrième appel à un outil.

La traçabilité permet aux équipes de reconstituer cette séquence. Chaque exécution peut enregistrer les données d'entrée, le modèle, les informations récupérées, les actions, les autorisations et les résultats, fournissant ainsi aux développeurs suffisamment de contexte pour vérifier si le système a bien suivi le processus prévu. Ces données répondent également aux exigences d'audit lorsque les organisations doivent expliquer comment une décision ou une action automatisée a été prise.

La qualité est plus difficile à contrôler, car le langage ne génère pas de code d’erreur simple lorsqu’il présente des anomalies subtiles. Les entreprises peuvent développer des ensembles d’évaluation basés sur des tâches réelles, noter des résultats représentatifs et vérifier si les performances évoluent lorsque les modèles, les invites ou les sources de données sont mis à jour. L’objectif n’est pas tant d’attribuer un indice de qualité universel que de déterminer si un système continue à remplir la mission spécifique pour laquelle l’organisation l’a déployé.

Les modifications apportées aux modèles rendent l'évaluation continue indispensable, car les entreprises font de plus en plus appel à des prestataires externes qui améliorent ou remplacent ces modèles au fil du temps. Une mise à jour peut améliorer le raisonnement général tout en modifiant le ton, la mise en forme ou le comportement au sein d'un flux de travail spécialisé. Sans tests de régression, les équipes ne peuvent détecter ces différences qu'une fois que les collaborateurs ou les clients commencent à les signaler.

Les coûts relèvent de la même couche d'observabilité, car les applications d'IA consomment des ressources variables. Un workflow peut continuer à fournir des réponses correctes alors même que sa consommation de jetons augmente progressivement, suite à une modification de la consigne ou parce qu'un agent commence à faire appel à des outils superflus. En établissant un lien entre la qualité et le coût, les équipes peuvent déterminer si la puissance de calcul supplémentaire améliore suffisamment le résultat pour se justifier.

Les équipes de sécurité doivent elles aussi avoir accès aux traces. Les injections soudaines, les accès inappropriés aux données et les comportements inhabituels des outils se manifestent souvent sous forme de schémas récurrents dans l'activité des agents, plutôt que sous la forme d'alertes classiques liées à des logiciels malveillants. Un agent qui tente soudainement d'accéder à des informations en dehors de son flux de travail habituel devrait attirer l'attention, même si tous les systèmes sous-jacents restent techniquement disponibles.

La protection de la vie privée complique la mise en place de journaux d'activité, car les informations nécessaires au diagnostic de l'IA peuvent elles-mêmes contenir des données sensibles. L'enregistrement sans restriction de chaque requête, document récupéré et résultat généré pourrait donner lieu à la création d'un nouveau référentiel contenant des informations sur les clients, des documents internes et des décisions commerciales. Les entreprises doivent donc mettre en place des politiques de conservation, des mécanismes de masquage et des contrôles d'accès concernant les données d'observabilité, plutôt que de considérer ces traces comme de simples journaux techniques inoffensifs.

Les chefs d'entreprise devraient s'impliquer, car de nombreuses défaillances de l'IA ne peuvent pas être identifiées uniquement par les ingénieurs. Une équipe du service client sait reconnaître lorsqu'une réponse techniquement cohérente enfreint une politique, tandis qu'un service financier est en mesure de détecter quand une erreur d'extraction modifie la signification économique d'un document. Une surveillance efficace combine la télémétrie technique et une évaluation spécifique au domaine concerné.

Le modèle opérationnel Cela s'apparente finalement davantage à un contrôle qualité qu'à une surveillance classique des applications. Les entreprises définissent les comportements acceptables, échantillonnent les résultats, analysent les écarts et ajustent le processus, tandis que l'automatisation prend en charge une part suffisante des mesures pour rendre la supervision réalisable à grande échelle.

Les systèmes d'IA continueront à produire des résultats probabilistes, ce qui signifie que les organisations ne peuvent pas éliminer toutes les réponses inattendues par des tests avant le lancement. La surveillance en production devient alors le mécanisme qui leur permet de fonctionner malgré cette incertitude.

Au cours de la première phase de l'adoption de l'IA en entreprise, les sociétés se sont demandé quel modèle offrait les meilleures performances. À mesure que ces modèles sont intégrés dans des flux de travail réels, une deuxième question, tout aussi concrète, se pose : l'entreprise est-elle en mesure de suivre suffisamment bien le fonctionnement du système pour savoir quand celui-ci cesse de fonctionner comme prévu ?