Pourquoi la fiabilité des agents IA commence par les données

Une stack d’IA en bon état peut malgré tout fournir des réponses erronées avec assurance

Un chatbot d’IA peut passer des semaines en réglage, répondre avec une précision suffisante pour obtenir l’approbation des parties prenantes, puis se mettre à donner des réponses erronées avec assurance trois mois après son lancement alors même que personne n’a modifié son modèle ni ses prompts. Dans le scénario illustratif, environ un tiers des questions finissent par recevoir de mauvaises réponses parce que le monde a changé : les prix ont évolué, une politique a été mise à jour ou une spécification produit a reçu une nouvelle version tandis que la base de connaissances est restée inchangée. Ces chiffres décrivent le scénario plutôt qu’une prévalence mesurée à l’échelle du secteur.

La même défaillance peut persister dans différentes architectures de retrieval, car le retrieval et l’exactitude ne répondent pas à la même question. Que l’information parvienne à l’application via un vector store, un index documentaire ou un appel API, un retrieval standard peut déterminer qu’une information est pertinente ou disponible sans établir qu’elle reste correcte. Un document tarifaire obsolète peut encore être très bien classé, tandis qu’un enregistrement dont un champ a disparu silencieusement peut continuer son chemin en aval. Le modèle reçoit alors des informations en apparence faisant autorité et répond en conséquence, tandis que les tableaux de bord opérationnels restent au vert.

C’est actuellement l’un des modes de défaillance en production les plus courants dans l’IA d’entreprise. Le mécanisme derrière ce constat est clair : un système en production peut fonctionner exactement comme prévu alors même que ses informations se dégradent. Lorsque la supervision considère qu’une exécution réussie est une preuve de bon fonctionnement, les équipes peuvent consacrer leurs efforts de diagnostic à des parties de la stack d’IA qui n’ont jamais été à l’origine du changement sous-jacent.

Le parcours habituel de diagnostic peut viser la mauvaise couche

Ce symptôme trompeur oriente naturellement d’abord l’attention vers le LLM. Une équipe constate que les réponses sont devenues moins exactes, essaie un autre modèle et modifie les prompts, car ce sont les composants qui génèrent visiblement la réponse. Lorsque ces changements ne rétablissent pas l’exactitude, l’attention se déplace vers le retrieval et l’infrastructure de contexte. L’équipe peut alors examiner ou remplacer le système qui décide quelles informations entrent dans le contexte du modèle.

Cette deuxième investigation traite une véritable catégorie de problèmes, et les fournisseurs ont une raison commerciale de vendre des technologies pour y répondre. AWS est entré dans la course à la « couche de contexte » avec un graphe de connaissances qui apprend à partir de l’usage des agents, tandis que Horizon Context et Cortex Sense de Snowflake traitent les cas où des agents produisent des réponses erronées avec assurance lorsque la logique métier sous-jacente manque de gouvernance. AWS et Snowflake bénéficient des investissements des entreprises dans ces services de contexte et d’IA ; leurs produits doivent donc être lus dans ce cadre commercial. Leur présence montre aussi que les équipes d’ingénierie disposent d’outils visant spécifiquement à contrôler les informations fournies aux agents.

Ces contrôles de contexte dépendent malgré tout de la qualité de leurs entrées. Un graphe de connaissances peut organiser les relations et un système de contexte peut améliorer ce qu’un agent reçoit, mais des entrées périmées ou incorrectes conservent ces défauts. Un meilleur retrieval peut améliorer la sélection sans prouver que le fait sélectionné est toujours vrai. Diagnostiquer une réponse erronée donnée avec assurance exige donc de remonter davantage en amont avant de conclure qu’il faut changer le modèle ou l’architecture de retrieval.

L’achèvement du pipeline n’établit pas l’exactitude des données

Remonter en amont change ce que doit signifier la bonne santé d’un pipeline. Un job réussi établit qu’un calcul ou un transfert attendu a bien été exécuté, tandis que la qualité des données exige de tester les valeurs transportées par le job au regard des exigences de leurs consommateurs. La pertinence et la disponibilité sont de la même manière des signaux limités, car un système peut récupérer des informations disponibles et très pertinentes pour une question tout en fournissant une mauvaise réponse à partir d’informations dégradées.

Un pipeline fintech montre le même mécanisme en dehors de l’IA. Un système amont a modifié un champ sans en informer les utilisateurs en aval, et pourtant le pipeline aval a continué à se terminer normalement. Sa supervision vérifiait si le job s’achevait, de sorte que de mauvaises valeurs se sont propagées dans les tableaux de bord sans déclencher de défaillance opérationnelle. Un client a fini par détecter une incohérence, alors que les valeurs avaient déjà circulé en aval.

L’absence d’erreur n’est pas synonyme d’exactitude. Ce principe couvre à la fois le changement de champ dans la fintech et les exemples d’IA, car un document peut devenir obsolète sans devenir inaccessible, et un champ peut disparaître sans empêcher un enregistrement de circuler. Tant que la validation ne teste pas l’information elle-même, la supervision de l’exécution n’a aucune raison de classer l’un ou l’autre événement comme une défaillance.

Redéfinir la santé du pipeline autour de quatre propriétés de données fiables

Une fois qu’une exécution réussie cesse d’être la définition complète de la bonne santé, l’observabilité des données doit couvrir ce qui arrive à l’information tout au long de son parcours. Le modèle pratique comporte quatre dimensions : exactitude, fraîcheur, cohérence et lineage. Chaque dimension répond à une question de défaillance différente et nécessite sa propre mesure. Ensemble, elles rendent la supervision sensible aux défaillances sémantiques que de simples vérifications de statut de job peuvent laisser invisibles.

L’exactitude commence au niveau de l’enregistrement : les données entrantes respectent-elles les structures et les règles exigées par leurs consommateurs ? La validation doit vérifier les types de champs, les valeurs nulles inattendues, les plages autorisées et les autres conditions requises à mesure que les données arrivent. Great Expectations et Soda sont des exemples commerciaux d’outils qui automatisent la validation au niveau des lignes et des colonnes ; les deux entreprises bénéficient donc lorsque les équipes investissent dans des contrôles automatisés de qualité des données. Une mesure opérationnelle consiste à suivre le pourcentage d’enregistrements qui passent la validation à chaque exécution du pipeline.

La fraîcheur pose une autre question, car des informations parfaitement structurées peuvent malgré tout être obsolètes. Une vérification récente du pipeline en dit peu lorsque la source sous-jacente ne s’est pas mise à jour avec succès dans la période exigée par ses consommateurs. Les équipes peuvent suivre le temps écoulé depuis la dernière mise à jour réussie de chaque source et établir un accord de niveau de service, ou SLA, pour chaque dataset. Des SLA propres à chaque dataset sont importants, car une source peut nécessiter des rafraîchissements horaires tandis qu’une autre peut rester utile avec un rythme plus lent.

La cohérence vient après la fraîcheur en demandant si plusieurs copies d’un fait concordent toujours une fois que les données ont atteint plusieurs destinations ou index. Deux systèmes alimentés par la même source peuvent diverger sans qu’aucun des deux ne paraisse défaillant pris isolément, laissant l’écart passer inaperçu jusqu’à ce qu’un utilisateur les compare. Des vérifications périodiques entre systèmes rendent ce désaccord mesurable. Une équipe peut calculer le taux d’écart entre les destinations en aval et déclencher une alerte lorsque ce taux dépasse le seuil défini.

Le lineage concerne l’investigation qui suit la détection d’un problème. Le lineage enregistre l’origine d’une sortie et les transformations qu’elle a traversées avant d’atteindre un consommateur, ce qui permet aux ingénieurs d’interroger directement cet historique. Lorsqu’une réponse d’IA est erronée, l’équipe peut utiliser le lineage pour localiser la source des informations qui l’étayent et déterminer comment ces informations ont acquis leur forme actuelle. L’investigation dépend alors moins d’employés qui reconstituent le pipeline de mémoire.

Comme le lineage doit permettre cette investigation, une couverture utile dépend de la capacité des ingénieurs à l’interroger pour les datasets critiques. Un dataset peut être bien compris par l’ingénieur qui a construit son pipeline tout en restant opaque sur le plan opérationnel pour tous les autres. Les équipes peuvent donc mesurer la part des datasets critiques dont le lineage est interrogeable. Cette mesure transforme la provenance en capacité système qui reste disponible lorsqu’un ingénieur particulier est absent.

Ces contrôles peuvent s’appuyer sur une infrastructure déjà présente dans une organisation data. Le changement d’ingénierie porte sur ce que ces systèmes testent et imposent : les enregistrements par rapport à des règles d’exactitude, les temps de mise à jour par rapport à des SLA propres à chaque source, les destinations les unes par rapport aux autres, et les sorties par rapport à une provenance enregistrée. La supervision du pipeline décrit alors l’état des données en plus de l’exécution qui les a déplacées.

Uber et Netflix ont construit des éléments clés de cette réponse avant l’ère du RAG

Cette définition plus large de la bonne santé est antérieure à la retrieval-augmented generation, ou RAG, dans laquelle une application récupère des informations externes et les fournit à un modèle génératif pour répondre. Uber a construit sa plateforme Unified Data Quality avant l’existence du RAG, en utilisant un système dédié à la qualité des données et à l’observabilité. La plateforme prend en charge plus de 2 000 datasets critiques et détecte environ 90 % des incidents de qualité des données avant que les consommateurs en aval ne les reçoivent. Ces résultats montrent ce que des contrôles de qualité en amont peuvent accomplir à grande échelle.

L’expérience d’Uber est importante parce que la détection intervient avant la consommation. Une fois que des informations incorrectes ont atteint un tableau de bord, un modèle ou une application orientée client, l’organisation doit réagir après la propagation du problème. Des contrôles de qualité automatisés identifient au contraire un problème alors qu’il est encore possible d’empêcher les données concernées d’atteindre les consommateurs. L’IA en accroît les conséquences, car une réponse générée peut présenter les informations fournies avec un haut niveau d’assurance.

Là où Uber illustre la détection précoce de la qualité, Netflix a développé une autre partie du modèle de fiabilité grâce à un lineage des données à l’échelle de l’entreprise. Son système permet aux utilisateurs de déterminer l’origine d’un dataset et quels systèmes ou processus l’ont traité, en couvrant les dépendances entre les topics Kafka, les modèles de ML, l’expérimentation et les tables d’entrepôt de données. Le système a été conçu pour des utilisateurs humains et a gagné en importance avec la prolifération des applications d’IA et de LLM. Son rôle pratique est de rendre la provenance explicable à travers un patrimoine de données complexe.

Ensemble, les exemples d’Uber et de Netflix montrent que la validation de la qualité et une provenance interrogeable étaient des besoins d’ingénierie avant que les entreprises ne commencent à placer des modèles génératifs au-dessus de leurs données. Le RAG donne à ces contrôles établis un autre consommateur important, car les applications d’IA s’appuient sur les mêmes informations sous-jacentes. Lorsque ces informations se dégradent, le modèle peut transformer un ancien problème de qualité des données en une réponse fluide orientée client.

Socure montre à quoi ressemble en pratique un flux de données centré sur l’exactitude

Ce besoin de contrôles avant consommation apparaît concrètement chez Socure, où les données clients pouvaient arriver dans n’importe quel format choisi par chaque client et pouvaient parfois être silencieusement erronées. Socure devait identifier les mauvaises informations entrantes avant qu’elles ne se propagent dans les systèmes en aval, tout en conservant une provenance suffisante pour comprendre d’où elles venaient. Great Expectations est devenu une partie de la base de ce contrôle ; en tant que fournisseur d’outils de qualité des données, Great Expectations a un intérêt commercial à une adoption plus large de la validation automatisée. La validation a été rapprochée de l’ingestion, là où une défaillance pouvait encore être contenue.

Socure a appliqué chacune des quatre dimensions à un point précis du flux de données. Les vérifications de schéma et de plage testaient l’exactitude lorsque l’information entrait dans le système, tandis que des SLA par source établissaient des attentes de fraîcheur reflétant les caractéristiques de chaque entrée. Des vérifications inter-systèmes testaient la cohérence après l’apparition des données à plusieurs endroits. Un lineage au niveau des fichiers préservait la provenance afin que les informations concernées puissent ensuite être retracées jusqu’à ce qui était arrivé.

Ces contrôles fonctionnaient derrière un modèle write-audit-publish, qui fait de la validation une porte entre l’arrivée et l’usage en aval. Les données entrantes arrivaient d’abord dans une zone de staging, où la validation requise s’exécutait avant toute diffusion plus loin en aval. Seules les données ayant passé les contrôles requis passaient de cet état contrôlé vers les systèmes qui en dépendaient. La décision de publier dépendait donc à la fois de preuves sur les données et d’une ingestion réussie.

Comme le reporting, les modèles de ML et le retrieval d’IA consommaient les données contrôlées, l’amélioration est apparue dans ces trois catégories de consommateurs en aval. Le reporting est devenu plus exact, tout comme les modèles de ML et le retrieval d’IA opérant sur les mêmes données. Ces applications peuvent sembler être des problèmes technologiques distincts lorsque des résultats inexacts apparaissent, mais leurs résultats peuvent partager la même entrée défectueuse. La validation avant publication traite ce point de défaillance commun.

Tester la couche de données avant de changer le modèle ou l’infrastructure de contexte

La mise en œuvre de Socure fournit un ordre de diagnostic pratique lorsque l’IA fondée sur le retrieval commence à produire des erreurs avec assurance. Les équipes peuvent d’abord établir si les informations qui parviennent au modèle et aux composants de contexte satisfont aux exigences attendues. Les quatre dimensions se traduisent directement en quatre questions :

• Les données sous-jacentes sont-elles validées par rapport aux standards exigés par leurs consommateurs ?
• Quel est le contenu le plus ancien actuellement servi avec un haut niveau d’assurance ?
• Deux chunks d’une même source pourraient-ils un jour se contredire dans un même résultat de retrieval ?
• Pourriez-vous retracer son origine s’il s’avérait erroné ?

La première question teste l’exactitude, tandis que la deuxième met en évidence la fraîcheur dans des termes qui comptent pour un consommateur d’IA au lieu de s’appuyer sur la date de la dernière exécution d’un pipeline. La troisième teste la cohérence là où le retrieval peut faire apparaître des représentations contradictoires d’une même source. La quatrième teste le lineage au moment où une investigation en a besoin. Une équipe incapable de répondre à ces questions présente une lacune de diagnostic entre ses systèmes source et les informations disponibles pour son agent.

Identifier cette lacune donne à l’équipe une raison d’examiner l’ingénierie data avant de s’engager dans un changement de modèle ou une migration de fournisseur. Des défaillances propres au modèle peuvent toujours se produire, et un système de retrieval peut toujours sélectionner un mauvais contexte ; AWS et Snowflake traitent ces véritables problèmes de couche de contexte. La tâche de diagnostic consiste à établir quelle couche a violé ses exigences avant d’en modifier une autre. Sinon, un composant de remplacement peut hériter des mêmes informations périmées, incomplètes, incohérentes ou intraçables.

Recap

Pour les dirigeants, le risque central n’est pas simplement qu’un modèle d’IA puisse se tromper. C’est que l’ensemble de la stack d’IA puisse sembler opérationnellement sain alors même que les informations derrière ses réponses sont déjà devenues peu fiables. Cela fait de la qualité des données un enjeu de gouvernance de l’IA et de fiabilité métier, pas seulement une préoccupation d’ingénierie data.

Avant d’approuver une nouvelle montée de version du modèle, une refonte du retrieval ou un investissement dans la couche de contexte, les dirigeants devraient demander si les équipes peuvent démontrer l’exactitude, la fraîcheur, la cohérence et le lineage des données consommées par leurs systèmes d’IA. Ces capacités apportent des preuves sur l’origine des défaillances et aident à éviter que des changements technologiques coûteux ne traitent le mauvais problème.

Les organisations les mieux placées pour exploiter une IA fiable traiteront les données de confiance comme une partie du système de production lui-même. Les modèles et les architectures de retrieval continueront d’évoluer, mais chaque génération d’IA restera dépendante de la qualité des informations qu’elle reçoit.